From nobody Tue Oct 1 00:58:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DCA1200FB; Tue, 1 Oct 2019 00:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 uOKQ06_H3sdD; Tue, 1 Oct 2019 00:58:05 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50077.outbound.protection.outlook.com [40.107.5.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206481200FE; Tue, 1 Oct 2019 00:58:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q4WAkZvf5T0HUJfB9tSwH6lfWFuyM4FM3rXot6fXd3aekU1jEdI3EEeLRAYPwVeA910r8iZy6kQUuio5zvuGt4dTTPwDawOxZws5yAY4DgeLUfJrqaJBtw5+sNWS4jtMSmrEcSLTa3m9i4dQJZV2OyK9CSluu9UoLfg3ye7bJtCtpZaH0bgaQrcixiNfwmKwaENwf5JQJQJL8LM3WW/M15BrArLb5rtlllPoHcPQVFmCUEVEBw0ddlJo3D0XdV/j2fUJypWUi9IpZewb+IYa5jGFfKSBoR6eJ0XDRs8MY5ldg8CYtw5eUG8YqeVnxHpTGPZcMvrRQjqKqKdHblmHgg== 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=zkXciIVR0FP6L+X/GXVrquNICC9dYPh1b3+6tbJ0oaM=; b=Edpt0noizwqjayXaocdwqCl9o8F+abowL1T/97cgD5w6tCvl1tvgaFtQ+DXZz6OTIyOrXn298FX1gxDzI7piAElJ6TMEQvNzUgK3Sufkkap3J78sXW8xAZHxb+fHlMmcvKC6T5FQKMMCTbPeDyX7kZVm7pX8NZ1qK7CWb5mF8HN/DYyGJDP9oqwT7BJjtKBlN0Y+30eB+yj8ttpto1MUWB/JChdb94ryHIu9jPFE/GiI53IratrgPTFG3qlS3da79P9aOdsEBgCOp/x92y0nvI1mfqkAf346gZKYfxiHBVUZs5mR6P242O/gEa/U/9Rc7zbF7kKTkm09FPWSJ26dXw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zkXciIVR0FP6L+X/GXVrquNICC9dYPh1b3+6tbJ0oaM=; b=mq+oXqSfjMe6DQQ9yTOnje9Yyx10aRw5j4OFPCa58xwnYjDK/0d7K0eRBWnHNSmdXz02zgicrqbkh/UzheGJsDjjuf8Tgw6saAdtCx8j2nNExFoVne2uDV9EXReO5mh5VGaYUxCcLa72Rwv2F561MRfxtO/wPSvG0OJ9zJzSKJM= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3148.eurprd07.prod.outlook.com (10.170.247.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Tue, 1 Oct 2019 07:58:02 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 07:58:02 +0000 From: John Mattsson To: Kathleen Moriarty , "Salz, Rich" CC: "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGqrOKnGYrSipku+oSGSF7Gj3ac9+dkAgAeauwA= Date: Tue, 1 Oct 2019 07:58:01 +0000 Message-ID: References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> In-Reply-To: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8d8f73d1-4d64-4c00-d112-08d746451549 x-ms-traffictypediagnostic: HE1PR07MB3148: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(4636009)(396003)(376002)(346002)(366004)(39860400002)(136003)(199004)(189003)(51444003)(13464003)(71190400001)(26005)(316002)(99286004)(966005)(33656002)(6436002)(229853002)(478600001)(76176011)(5660300002)(256004)(25786009)(14444005)(14454004)(71200400001)(86362001)(6486002)(44832011)(486006)(476003)(8936002)(64756008)(102836004)(2616005)(76116006)(66066001)(54906003)(6116002)(446003)(6246003)(11346002)(110136005)(53546011)(6506007)(305945005)(7736002)(66946007)(58126008)(66574012)(66556008)(4326008)(186003)(6512007)(2906002)(81156014)(81166006)(6306002)(8676002)(36756003)(3846002)(66476007)(66446008)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3148; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Bg0Q5ow2Twoka25D7eEpNCm/+arujI6ODo7GG3rz5urmA7kdFK/iVwaH0bGd7zf6aJ9zNWSU1xjZVU9G89SW1vbfALQdSZYzrz0wXLYvQ1NtR3LuQ9I8ugd0CIPE3mm5/RFkBZKhC2khOxv0z2V9ohXXQiSY4rzYcFzpmx79j/nYFHQR+7rlsWJwOznQ5TOORHGfp6aknVNNRx8WeXzhQT7rwO43q8ecWt19ueJwdH+Xvnk0DU+tZhliHVCO8D8C38MGuEI11Zbcwl08q+5+NLKaSldRMZcQa4EcDdkF/MxqZ3TcSNEdD4/hhOs5ctYdZgm9UsqqJrsmHqaCRkUhV9VjrqRGiQtVISYWCuTTuNE2blOv1LeJRH9Rwkjy5+C1ta6jY49MrziEMfvHYjgGa2P2rCUwy+FNEEEDgIYWWXXT+eF1z4kEzGRilA40HAxTwTEHJGUVwtIvM7HFDtF6tA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <680BB3D61A9F014187F8E81463EAD89D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8d8f73d1-4d64-4c00-d112-08d746451549 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 07:58:01.8152 (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: iokg4aoxuc40s2fZLE9OhnixQ1bSiujPc8b7NUaAmWyvCwF2wmzaos+cjWfgMRgkSjlZzaR/pbk19rE7ASDSlzNtTRXp1IigcSBohOQyM7o= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3148 Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 07:58:09 -0000 S2F0aGxlZW4gTW9yaWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90 ZToNCg0KPk5JU1QgaGFzIHB1c2hlZCBiYWNrIHRoZWlyIGRhdGUgZm9yIFVTIGdvdmVybm1lbnQg b3JnYW5pemF0aW9ucyB0byBoYXZlIGEgcGxhbiB0byBzdXBwb3J0IFRMU3YxLjMsIHdoYXTigJlz IHRoZSBkcml2ZXIgdG8gZ2V0IGFoZWFkIG9mIHRoYXQ/DQoNCk5JU1QgU1AgODAwLTUyIHJldiAy IHJlcXVpcmVzIHN1cHBvcnQgZm9yIFRMUyAxLjMgYnkgSmFudWFyeSAxLCAyMDI0LiBJIHRoaW5r IHRoYXQgaXMgYSBnb29kIGFuZCBhbWJpdGlvdXMgcGxhbi4gSW4gZmFjdCBpdCB3b3VsZCBiZSB2 ZXJ5IGdvb2QgaWYgSUVURiBhZ3JlZWQgb24gdGhlIHNhbWUgcmVxdWlyZW1lbnQuDQoNCj4gSSB0 aGluayBlbmNvdXJhZ2luZyBpbXBsZW1lbnRhdGlvbiBvZiBUTFN2MS4zIGlzIGdvb2QgYW5kIGlt cG9ydGFudCwgYnV0IGFyZSB0aGVyZSBvdGhlciB3YXlzIGJlc2lkZXMgZGVwcmVjYXRpb24/DQoN ClllcywgSSB0aGluayB0aGVyZSBpcyBhdCBsZWFzdCB0d28gdGhpbmdzIElFVEYgY2FuIGRvOg0K DQotIFRoZSBmaXJzdCB0aGluZyBpcyB0byBkbyBsaWtlIE5JU1QgYW5kIGFscmVhZHkgbm93IGdp dmUgaW1wbGVtZW50b3JzIGEgZGF0ZSB3aGVuIHN1cHBvcnQgZm9yIFRMUyAxLjMgaXMgcmVxdWly ZWQuDQoNCi0gVGhlIHNlY29uZCB0aGluZyBpcyB0byBkbyBsaWtlIDNHUFAgYW5kIG1hbmRhdGUg c3VwcG9ydCBmb3IgVExTIDEuMyBpbiBuZXcgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50 cy4NCg0KVGhpcyB3b3VsZCBhdm9pZCB0d28gdGhpbmcgdGhhdCBoYXBwZW5lZCBpbiB0aGUgcGFz dC4gRmlyc3QsIElFVEYgcHVibGlzaGVkIFJGQyA4MjYxIHRoYXQgbWFuZGF0ZWQgc3VwcG9ydCBm b3IgRFRMUyAxLjAgYW5kIG5vdCBEVExTIDEuMiBhbG1vc3QgNiB5ZWFycyBhZnRlciBSRkMgNjM0 NyBtYWRlIERUTFMgMS4wIG9ic29sZXRlLiBTZWNvbmRseSwganVzdCA3IG1vbnRocyBhZnRlciBw dWJsaXNoaW5nIGEgZHJhZnQgcmVseWluZyBvbiBEVExTIDEuMCwgSUVURiBzdGFydGVkIHdvcmtp bmcgb24gYSBkcmFmdCBmb3JiaWRkaW5nIGl04oCZcyB1c2UuDQoNCkNoZWVycywNCkpvaG4NCg0K 77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEthdGhsZWVuIE1vcmlhcnR5IDxr YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAyNiBTZXB0 ZW1iZXIgMjAxOSBhdCAxNTo1MA0KVG86ICJTYWx6LCBSaWNoIiA8cnNhbHpAYWthbWFpLmNvbT4N CkNjOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sICJUTFNAaWV0 Zi5vcmciIDxUTFNAaWV0Zi5vcmc+LCAic2FhZ0BpZXRmLm9yZyIgPHNhYWdAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW1RMU10gTGVzc29ucyBsZWFybmVkIGZyb20gVExTIDEuMCBhbmQgVExTIDEu MSBkZXByZWNhdGlvbg0KDQogICAgDQogICAgDQogICAgU2VudCBmcm9tIG15IG1vYmlsZSBkZXZp Y2UNCiAgICANCiAgICA+IE9uIFNlcCAyNiwgMjAxOSwgYXQgOTowMiBBTSwgU2FseiwgUmljaCA8 cnNhbHpAYWthbWFpLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IFRoZXNlIGFyZSBleGNlbGxl bnQgcG9pbnRzLiAgUGVyaGFwcyB0aGV5IGNhbiBiZSBzcXVlZXplZCBpbnRvIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0 ZS8gID8gIEl0J3MgYmVlbiB3YWl0aW5nIDkwIGRheXMsIGEgYnJpZWYgcmVzZXQgbWlnaHQgbm90 IGh1cnQgOikNCiAgICA+IA0KICAgIFRoaXMgd291bGQgbm90IGJlIGEgYnJpZWYgcmVzZXQgYW5k IEnigJlkIHByZWZlciBub3QgdG8gc2VlIHRoZW0gY29tYmluZWQgaW50byB0aGUgZXhpc3Rpbmcg ZHJhZnQgd2l0aCBXRyBhZ3JlZW1lbnQuDQogICAgDQogICAgV2l0aCBSRkM3NTI1LCBUTFN2MS4y IGNhbiBiZSBjb25maWd1cmVkIHRvIGJlIHNlY3VyZS4gIEkgc2VlIHRoZSBwb2ludHMgbWFkZSwg YnV0IGRvbuKAmXQgc2VlIHRoZSB1cmdlbmN5IGFzIG9ic29sZXRlIGlzIGRpZmZlcmVudCBmcm9t IGRlcHJlY2lhdGlvbi4NCiAgICANCiAgICBJIHRoaW5rIGVuY291cmFnaW5nIGltcGxlbWVudGF0 aW9uIG9mIFRMU3YxLjMgaXMgZ29vZCBhbmQgaW1wb3J0YW50LCBidXQgYXJlIHRoZXJlIG90aGVy IHdheXMgYmVzaWRlcyBkZXByZWNhdGlvbj8NCiAgICANCiAgICBOSVNUIGhhcyBwdXNoZWQgYmFj ayB0aGVpciBkYXRlIGZvciBVUyBnb3Zlcm5tZW50IG9yZ2FuaXphdGlvbnMgdG8gaGF2ZSBhIHBs YW4gdG8gc3VwcG9ydCBUTFN2MS4zLCB3aGF04oCZcyB0aGUgZHJpdmVyIHRvIGdldCBhaGVhZCBv ZiB0aGF0Pw0KICAgIA0KICAgIEEgdnVsbmVyYWJpbGl0eSB3b3VsZCBzcGVlZCB0aGluZ3MgdXAs IGJ1dCBJIGRvIGhvcGUgdGhhdCBkb2VzIG5vdCBoYXBwZW4uDQogICAgDQogICAgQmVzdCByZWdh cmRzLA0KICAgIEthdGhsZWVuIA0KICAgIA0KICAgID4gT24gOS8yNi8xOSwgODoxOCBBTSwgIkpv aG4gTWF0dHNzb24iIDxqb2huLm1hdHRzc29uPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3Jn PiB3cm90ZToNCiAgICA+IA0KICAgID4gICAgSGksDQogICAgPiANCiAgICA+ICAgIEhvcGVmdWxs eSwgd2UgaGF2ZSBsZWFybmVkIHNvbWUgbGVzc29ucyBmcm9tIHRoZSBUTFMgMS4wIGFuZCBUTFMg MS4xIGRlcHJlY2F0aW9uLiBUTFMgMS4wIGFuZCBUTFMgMS4xIGFyZSAodG8gY2l0ZSBNYXJ0aW4g VGhvbXNvbikgYnJva2VuIGluIGEgbXlyaWFkIHN1YnRsZSB3YXlzIGFuZCBzaG91bGQgYWNjb3Jk aW5nIHRvIG1lIG9wdGltYWxseSBoYXZlIGJlZW4gZGVwcmVjYXRlZCB5ZWFycyBhZ28uDQogICAg PiANCiAgICA+ICAgIDNHUFAgbWFuZGF0ZWQgc3VwcG9ydCBvZiBUTFMgMS4yIGluIFJlbC0xMyAo MjAxNSkgYnV0IGNvdWxkIGF0IHRoYXQgdGltZSBub3QgZm9yYmlkIHVzZSBvZiBUTFMgMS4xIGFz IHRoYXQgd291bGQgcG90ZW50aWFsbHkgYnJlYWsgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHNvbWUg UmVsLTEyIG5vZGVzICh0aGF0IGhhZCBUTFMgMS4yIGFzIHNob3VsZCBzdXBwb3J0KS4gVGhlIGxl c3NvbiAzR1BQIGxlYXJuZWQgZnJvbSB0aGlzIHdhcyB0aGUgbmVlZCB0byBhcyBlYXJseSBhcyBw b3NzaWJsZSBtYW5kYXRlIHN1cHBvcnQgb2YgbmV3IHByb3RvY29sIHZlcnNpb25zLiBXaXRoIFRM UyAxLjMsIDNHUFAgdG9vayBhY3Rpb24gZWFybHkgYW5kIFRMUyAxLjMgc3VwcG9ydCB3YXMgbWFu ZGF0ZWQgZm9yIG5ldHdvcmsgbm9kZXMgaW4gUmVsLTE1ICgyMDE4KSBhbmQgZm9yIG1vYmlsZSBw aG9uZXMgaW4gUmVsLTE2ICgyMDE5KS4NCiAgICA+IA0KICAgID4gICAgQXQgc29tZSBwb2ludCBp biB0aW1lIHdlIHdpbGwgd2FudCB0byBkZXByZWNhdGUgVExTIDEuMi4gVG8gZW5hYmxlIHRoYXQs IFRMUyAxLjMgc3VwcG9ydCBzaG91bGQgYmUgbWFuZGF0ZWQgb3IgZW5jb3VyYWdlZCBhcyBtdWNo IGFzIHBvc3NpYmxlLiBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgYSBzaXR1YXRpb24gd2hlcmUgd2Ug d2FudCB0byBkZXByZWNhdGUgVExTIDEuMiBidXQgcmVhbGl6ZSB0aGF0IGl0IGNhbm5vdCBiZSBk b25lIGJlY2F1c2Ugc29tZSBpbXBsZW1lbnRhdGlvbnMgb25seSBzdXBwb3J0IFRMUyAxLjIuIEhv dyBjYW4gSUVURiBlbmFibGUgc21vb3RoZXIgYW5kIGZhc3RlciBkZXByZWNhdGlvbnMgaW4gdGhl IGZ1dHVyZT8gVGhlIGJyb3dzZXIgaW5kdXN0cnkgaGFzIGEgZGVjZW50IHRyYWNrIHJlY29yZCBv ZiBhbGdvcml0aG0gZGVwcmVjYXRpb24gYW5kIEkgaG9wZSB0byBzb29uIHNlZSB0aGUgZm9sbG93 aW5nIHdhcm5pbmcgaW4gbXkgYnJvd3NlcjoNCiAgICA+IA0KICAgID4gICAg4oCcVExTIDEuMiBp cyBvYnNvbGV0ZS4gRW5hYmxlIFRMUyAxLjMgb3IgbGF0ZXIu4oCdDQogICAgPiANCiAgICA+ICAg IE90aGVyIGluZHVzdHJpZXMgaGF2ZSBsZXNzIHN0ZWxsYXIgdHJhY2sgcmVjb3JkcyBvZiBhbGdv cml0aG0gZGVwcmVjYXRpb24uDQogICAgPiANCiAgICA+ICAgIEhvdyBjYW4gSUVURiBiZSBtb3Jl IHByby1hY3RpdmUgcmVnYXJkaW5nIGRlcHJlY2F0aW9ucyBpbiB0aGUgZnV0dXJlPyBJbiB0aGUg YmVzdCBvZiB3b3Jkcywgbm9ib2R5IHNob3VsZCBiZSBzdXJwcmlzZWQgd2hlbiBJRVRGIGRlcHJl Y2F0ZXMgYSBwcm90b2NvbCB2ZXJzaW9uIG9yIGFsZ29yaXRobS4gTklTVCBhbmQgc2ltaWxhciBv cmdhbml6YXRpb25zIGluIG90aGVyIGNvdW50cmllcyBoYXZlIHRoZSBwcmFjdGljZSB0byBsb25n IHRpbWUgaW4gYWR2YW5jZSBwdWJsaXNoIGRlYWRsaW5lcyBmb3Igc2VjdXJpdHkgbGV2ZWxzLCBh bGdvcml0aG1zLCBhbmQgcHJvdG9jb2wgdmVyc2lvbnMuIENhbiB0aGUgSUVURiBkbyBzb21ldGhp bmcgc2ltaWxhciwgbm90IGp1c3QgZm9yIFRMUyBidXQgaW4gZ2VuZXJhbD8gRm9yIFRMUywgdGhl cmUgYXJlIHNldmVyYWwgdGhpbmdzIHRvIGRlcHJlY2F0ZSwgaW4gYWRkaXRpb24gdG8gTUQ1IGFu ZCBTSEEtMSwgYWxzbyBQS0NTMS12MV81LCBSU0EtMjA0OCwgMjI0LWJpdCBFQ0MsIGZmZGhlMjA0 OCwgYW5kIG5vbi1yZWNvbW1lbmRlZCBjaXBoZXIgc3VpdGVzIChTdGF0aWMgUlNBLCBDQkMsIERI LCBOVUxMLCBldGMuKSBzaG91bGQgYmUgZGVwcmVjYXRlZCBpbiB0aGUgZnV0dXJlLg0KICAgID4g DQogICAgPiAgICBDaGVlcnMsDQogICAgPiAgICBKb2huDQogICAgPiANCiAgICA+ICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICBUTFMg bWFpbGluZyBsaXN0DQogICAgPiAgICBUTFNAaWV0Zi5vcmcNCiAgICA+ICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAgPiANCiAgICA+IA0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IFRMUyBt YWlsaW5nIGxpc3QNCiAgICA+IFRMU0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90bHMNCiAgICANCg0K From nobody Tue Oct 1 01:00:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5C1200FE for ; Tue, 1 Oct 2019 01:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ORWxE8ICof8J for ; Tue, 1 Oct 2019 01:00:14 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0610.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::610]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C598F1200FF for ; Tue, 1 Oct 2019 01:00:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jffjc5YNda5cuJK7AWeF1X+W8H/5a6zn+Qo9p1RHPk9ZBWbaehkjSNaGzJLKTaHccydJLnqpv7PYgptl+6HZxq53qFVHq/Hm+Eb/tVNbJSdmUJDV6Sp3gjX4lyl/dfjx7VR7K9+maZ8dh82gjbICUtM2bz1vrzOhpoGGHUno7G/zXbFSQGh6B7o5OfolgUvVMA1MhH6Mt2JNvB0ZvNZFOsN7a3wcBYlrxT24QeoLimBFPOHYBRMv/YXxU6pV9s5zdxtG6uWEs33y88t+ySQS00zIY3chNzr3gnQ86o/Hxt+B356aTwYehjFMq3/MbdolXh5u0G1N24+aOTs4mTh87g== 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=PzikZB7mUqkv7vkm+/BmHm4D+pRpbsgBc/hpff1pFL0=; b=KLC3X6+yXlPfTPiYJg4zuhuZAMByJcVu7BFJxRKx4jtU1t/OUdPEMTqby2LGyHs/WODUz+viXb6lWf6Uk3KaAqNdm3obREeZyIdD1ze80cvgdEZvae5LKTmpdC2GKovgnum/qQTpCh12y4pw8egj+6BncaSMnhVsu7Y0tsGDcStGlWlrgX3V2Q8Lo7PXJb5iQw6tv3Xn3LBYpeRpFwQHqFIJhUiHVSnbOqvFod+eLQqmrsYsherVWT6d8HqGZxxNRtXl2weUXENpu8Lj/7u8qalo+Fi5lfuUsRP/soCDs5tVTsHu9rWmdD/U8V4H8Q7xSYgxZdDXLyyJxHFzmwGUyQ== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PzikZB7mUqkv7vkm+/BmHm4D+pRpbsgBc/hpff1pFL0=; b=HVBlA4BsUWODqE1uvYY/7rSqXK1yjqdkNjy77jd3ZmnqvYXekO7NWzYe4wNuBsLZ1KN+eAfEwyJf2ApPZpaiQJsyM3jhv899/i4z9HiAMpGVwSUPxcxO5fAa0dVPnVG2zHQYeokvj6G2JqbPJJ8l1+K7VLhviOya8magZ2CzJXU= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4316.eurprd07.prod.outlook.com (20.176.168.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.13; Tue, 1 Oct 2019 08:00:11 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 08:00:11 +0000 From: John Mattsson To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdMcGqKrsDzXR9ESLhc3TP2SShqdFlHcA Date: Tue, 1 Oct 2019 08:00:11 +0000 Message-ID: <4DE775B5-B15B-469F-A50C-3DB5B86AA5D4@ericsson.com> References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e08f0af-a661-43ac-53be-08d746456272 x-ms-traffictypediagnostic: HE1PR07MB4316: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(39860400002)(346002)(396003)(366004)(13464003)(51444003)(199004)(189003)(305945005)(476003)(66446008)(316002)(110136005)(58126008)(76116006)(66946007)(66574012)(44832011)(66556008)(66066001)(26005)(102836004)(7736002)(256004)(53546011)(6506007)(186003)(5660300002)(486006)(76176011)(2616005)(64756008)(11346002)(66476007)(446003)(2906002)(71200400001)(86362001)(36756003)(25786009)(6436002)(99286004)(6306002)(6512007)(966005)(14454004)(71190400001)(2501003)(81166006)(81156014)(8936002)(6246003)(229853002)(6486002)(33656002)(3846002)(478600001)(6116002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4316; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RQiT7g816OY//IZCY39p31xnw4HTmzbpirfU9AqemzFbGX/HxCL1fKsISC3BX6Bm2U7slIxz4uBDVvIP52xN8xJEc8EAHR3AUqjBkt1tp/E/afX9aq5MEcou5GMiLY27nWQ0mE/ienLvIMuaMJSaNMp9ShEjwyIxa/zOLWY59pUwOzjpQWNUCQE2SbSwjAa8b1oui4x9lCFG94ozJRZ6R30dPkZPsTOdufCW7msRL0BgllEJ9Mbp1j7g9ILs3xHfi0KOZH5UNNG0yeWXr2AYErM0i/bY7sDqeGi9evWY5TI7cwIIoJ+sLjNZP2mo1Ke0kJTdMZV8uhHdCrHAhi1qHG1hYTpmsoM+r/HZp8KA4RSIzKYSgu49FctPBls3kDhPlO6PIR/E+7nT3iqP9YYMYRMxyZjobYpDSo5VSc4GXobvMNGZ/ZhFRRZ1QTgpwjOFgnpPaHNWHilKeevs1K+d/A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <93A00A3617709D47AD9F805895FD4BCE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e08f0af-a661-43ac-53be-08d746456272 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 08:00:11.3392 (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: n1C9xpOe2hnn92YHBsrQDhXJoljYaeKNoV13F2SNKsqeQk2uJu//2jVvw3KoqUYoF3gelLKL1dsD9rnDzSfAuOrrn0Dc3TVYzJHlzfWollw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4316 Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 08:00:17 -0000 TWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0Pjsgd3JvdGU6DQoNCj5XaGVuIHdlIHJl bGVhc2UgYSBuZXcgdmVyc2lvbiBvZiBzb21ldGhpbmcsIHdlIGFyZSBzZW5kaW5nIGEgbWVzc2Fn ZToNCj4NCj4xLiBuZXcgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50cyBNVVNUIGluY2x1 ZGUgc3VwcG9ydCBmb3IgbmV3ZXIgdmVyc2lvbnMNCj4yLiBleGlzdGluZyBpbXBsZW1lbnRhdGlv bnMgYW5kIGRlcGxveW1lbnRzIFNIT1VMRCBiZSB1cGRhdGVkIHRvIHN1cHBvcnQgbmV3ZXIgdmVy c2lvbnMNCg0KSSBhZ3JlZSB2ZXJ5IG11Y2ggd2l0aCB0aGlzIHN1bW1hcnkgYW5kIEkgd291bGQg bGlrZSB0byBoYXZlIGl0IHB1Ymxpc2hlZCBzb21ld2hlcmUuIFRha2UgZm9yIGV4YW1wbGUgUkZD IDgyNjEuIEl0IHdhcyBwdWJsaXNoZWQgYWxtb3N0IDYgeWVhcnMgYWZ0ZXIgUkZDIDYzNDcgbWFk ZSBEVExTIDEuMCBvYnNvbGV0ZSBhbmQgc3RpbGwgbWFuZGF0ZWQgc3VwcG9ydCBmb3IgRFRMUyAx LjAgYW5kIG5vdCBEVExTIDEuMi4gSSB0aGluayB0aGlzIGlzIG9uZSBvZiB0aGUgbGVzc29ucyBJ RVRGIHNob3VsZCBsZWFybiBmcm9tIHRoZSBUTFMgMS4wIGFuZCBUTFMgMS4xIGRlcHJlY2F0aW9u LiBIb3cgZG8gd2Ugc3RvcCB0aGlzIGZyb20gaGFwcGVuaW5nIGluIHRoZSBmdXR1cmU/IEZvciBh biBleHRlcm5hbCB2aWV3ZXIgaXQgbXVzdCBsb29rIHByZXR0eSBzdHJhbmdlIHRoYXQgSUVURiBp biBOb3YgMjAxNyBwdWJsaXNoZWQgYW4gUkZDIHJlbHlpbmcgb24gRFRMUyAxLjAgYW5kIHRoZW4g NyBtb250aHMgbGF0ZXIgc3RhcnRlZCB3b3JraW5nIG9uIGEgZHJhZnQgZm9yYmlkZGluZyBpdHMg dXNlLi4uLg0KDQpJIHdvdWxkIGxpa2UgdG8gc2VlIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dp bmcgc3RhdGVtZW50cyBwdWJsaXNoZWQ6DQoNCiJOZXcgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBs b3ltZW50cyBNVVNUIGluY2x1ZGUgc3VwcG9ydCBmb3IgVExTIDEuMyINCiJFeGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1lbnRzIFNIT1VMRCBiZSB1cGRhdGVkIHRvIHN1cHBvcnQg VExTIDEuMyINCiJFeGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYW5kIGRlcGxveW1lbnRzIFNIQUxM IHN1cHBvcnQgVExTIDEuMyBieSBKYW51YXJ5IDEsIDIwMjQiDQoNCj4+ICIiIlRoZSBleHBlY3Rh dGlvbiBpcyB0aGF0IFRMU3YxLjIgd2lsbCBjb250aW51ZSB0byBiZSB1c2VkIGZvciBtYW55IA0K Pj4geWVhcnMgYWxvbmdzaWRlIFRMU3YxLjMuIiIiDQo+DQo+U29tZSBwZW9wbGUgaGF2ZSB0aGF0 IGV4cGVjdGF0aW9uLCBidXQgSSB0aGluayB0aGF0IEpvaG4gaXMgcmlnaHQgdG8gY2hhbGxlbmdl IGl0LiAgPlRoZXJlIHJlbWFpbiByZWFzb25zIHRoYXQgcGVvcGxlIGFyZSBzdGlja2luZyB3aXRo IDEuMiBmb3Igbm93LCBidXQgdGhvc2UgcmVhc29ucyA+YXJlIG1vc3RseSB0byBkbyB3aXRoIGFs bG93aW5nIHRpbWUgdG8gZmx1c2ggb3V0IHRoZSB2ZXN0aWdlcyBvZiBhIGRlcGVuZGVuY3kgb24g PnNvbWUgb2YgdGhlIFRMUyAxLjIgaWRpb3N5bmNyYXNpZXMuDQoNCkkgYWdyZWUgd2l0aCBNYXJ0 aW4sIGFuZCBpcnJlc3BlY3RpdmVseSBvZiB3aGV0aGVyIGl0IGlzIHRydWUgb3Igbm90LCBJIGRv IG5vdCBzZWUgYW55IG5lZWQgdG8gaGF2ZSB0aGlzIHNlbnRlbmNlIGluIGFuIElFVEYgZHJhZnQu IA0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgTWFydGluIFRob21zb24g PG10QGxvd2VudHJvcHkubmV0Pg0KRGF0ZTogRnJpZGF5LCAyNyBTZXB0ZW1iZXIgMjAxOSBhdCAw MjowMw0KVG86ICJUTFNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RM U10gTGVzc29ucyBsZWFybmVkIGZyb20gVExTIDEuMCBhbmQgVExTIDEuMSBkZXByZWNhdGlvbg0K DQogICAgU28gSSBhZ3JlZSB3aXRoIEthdGhsZWVuJ3MgY29uY2x1c2lvbjogbm90IHRvIGNoYW5n ZSB0aGUgZ29hbHMgb2YgdGhlIGN1cnJlbnQgZG9jdW1lbnQuICBCdXQgdGhlcmUgYXJlIGNoYW5n ZXMgdGhhdCBJIHRoaW5rIGFyZSBuZWNlc3NhcnkgKGFuZCB0aGFua3MgdG8gRGFuaWVsIGFuZCBK b2huIGZvciBoaWdobGlnaHRpbmcgdGhlc2UpLg0KICAgIA0KICAgIEJUVywgSSd2ZSBtb3ZlZCB0 aGlzIHRvIHRoZSBUTFMgd29ya2luZyBncm91cCwgYmVjYXVzZSB0aGlzIGlzIGFuIGFjdGl2ZSB0 b3BpYyB0aGVyZSBhbmQgSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gbXkgZW1haWwgdGhhdCBTQUFH IG5lZWRzIHRvIGNvbmNlcm4gaXRzZWxmIHdpdGguDQogICAgDQogICAgT24gRnJpLCBTZXAgMjcs IDIwMTksIGF0IDAxOjAwLCBEYW5pZWwgTWlnYXVsdCB3cm90ZToNCiAgICA+IE15IHVuZGVyc3Rh bmRpbmcgb2YgZGVwcmVjYXRpbmcgb2YgVExTMS4wIFRMUyAxLjEgaXMgdGhhdDogDQogICAgPiBh KSBuZXcgc29mdHdhcmUgZG8gbm90IHVzZSB0aGVzZSB2ZXJzaW9ucyANCiAgICA+IGIpIGV4aXN0 aW5nIHNvZnR3YXJlIHN0b3Agc3VwcG9ydGluZyB0aGVzZSB2ZXJzaW9ucy4gDQogICAgDQogICAg VGhhdCBkaWZmZXJzIGZyb20gbXkgcGVyc3BlY3RpdmUuDQogICAgDQogICAgV2hlbiB3ZSByZWxl YXNlIGEgbmV3IHZlcnNpb24gb2Ygc29tZXRoaW5nLCB3ZSBhcmUgc2VuZGluZyBhIG1lc3NhZ2U6 DQogICAgDQogICAgMS4gbmV3IGltcGxlbWVudGF0aW9ucyBhbmQgZGVwbG95bWVudHMgTVVTVCBp bmNsdWRlIHN1cHBvcnQgZm9yIG5ld2VyIHZlcnNpb25zDQogICAgMi4gZXhpc3RpbmcgaW1wbGVt ZW50YXRpb25zIGFuZCBkZXBsb3ltZW50cyBTSE9VTEQgYmUgdXBkYXRlZCB0byBzdXBwb3J0IG5l d2VyIHZlcnNpb25zDQogICAgDQogICAgV2hlbiB3ZSBkZXByZWNhdGUgYW4gb2xkIHZlcnNpb24g b2Ygc29tZXRoaW5nLCB3ZSBhcmUgc2VuZGluZyBhIG1lc3NhZ2U6DQogICAgDQogICAgMy4gb25s eSB1c2UgdGhpcyBvbGQgdmVyc2lvbiBpZiB5b3UgYWJzb2x1dGVseSBoYXZlIHRvDQogICAgNC4g eW91IGFyZSBlbmNvdXJhZ2VkIHRvIHRha2UgYWN0aXZlIG1lYXN1cmVzIHRvIHJlbW92ZSB0aGUg bmVlZCB0byB1c2UgdGhlIG9sZCB2ZXJzaW9uDQogICAgNS4geW91IGhhdmUgb3VyIHN1cHBvcnQg aWYgeW91IGRlY2lkZSBub3QgdG8gc3VwcG9ydCB0aGlzIG9sZCB2ZXJzaW9uDQogICAgDQogICAg Tm93LCAic3VwcG9ydCIgZnJvbSB0aGUgSUVURiBpcyBhYm91dCBhcyBtZWFuaW5nZnVsIGFzIHlv dSB0aGluayBpdCBpcy4gIEFuZCB5b3UgY2FuIHMvTVVTVC9yZWFsbHkgb3VnaHQgdG8vIGFuZCBz L1NIT1VMRC9tYXkgd2lzaCB0by8gW1JGQzY5MTldLg0KICAgIA0KICAgIEluIGJyb3dzZXItbGFu ZCwgd2UndmUgZGVjaWRlZCB0byBmb3JtIGEgY29hbGl0aW9uIHdoZW4gaXQgY29tZXMgdG8gcmVt b3ZpbmcgVExTIDEuMC8xLjEuICAzR1BQIGhhdmUgb2J2aW91c2x5IGdvdCB0aGVpciBvd24gc3Vw cG9ydCBncm91cCwgd2hpY2ggc2VlbXMgdG8gYmUgZnVuY3Rpb25pbmcgZWZmZWN0aXZlbHksIHdo aWNoIGlzIGdyZWF0Lg0KICAgIA0KICAgID4gIiIiVGhlIGV4cGVjdGF0aW9uIGlzIHRoYXQgVExT djEuMiB3aWxsIGNvbnRpbnVlIHRvIGJlIHVzZWQgZm9yIG1hbnkgDQogICAgPiB5ZWFycyBhbG9u Z3NpZGUgVExTdjEuMy4iIiINCiAgICANCiAgICBTb21lIHBlb3BsZSBoYXZlIHRoYXQgZXhwZWN0 YXRpb24sIGJ1dCBJIHRoaW5rIHRoYXQgSm9obiBpcyByaWdodCB0byBjaGFsbGVuZ2UgaXQuICBU aGVyZSByZW1haW4gcmVhc29ucyB0aGF0IHBlb3BsZSBhcmUgc3RpY2tpbmcgd2l0aCAxLjIgZm9y IG5vdywgYnV0IHRob3NlIHJlYXNvbnMgYXJlIG1vc3RseSB0byBkbyB3aXRoIGFsbG93aW5nIHRp bWUgdG8gZmx1c2ggb3V0IHRoZSB2ZXN0aWdlcyBvZiBhIGRlcGVuZGVuY3kgb24gc29tZSBvZiB0 aGUgVExTIDEuMiBpZGlvc3luY3Jhc2llcy4NCiAgICANCiAgICBJIHdvdWxkIGFkdm9jYXRlIGZv ciByZW1vdmluZyB0aGlzIHN0YXRlbWVudCBhbmQgYW55IHJlc2lkdWUgb2YgdGhhdCBzZW50aW1l bnQgZnJvbSB0aGUgZHJhZnQuICBJdCdzIHNwZWN1bGF0aW9uIGFuZCwgZXZlbiBpZiBpdCB3ZXJl IHRydWUsIGl0IGNvbnZleXMgdGhlIHdyb25nIG1lc3NhZ2UuICBUaGUgb25seSBtZXNzYWdlIEkg d291bGQgaW5jbHVkZSBpcyB0aGF0IG9uZSB0aGF0IGlzIGZ1cnRoZXIgZG93biB0aGUgZG9jdW1l bnQ6ICJBbnkgbmV3ZXIgdmVyc2lvbiBvZiBUTFMgaXMgbW9yZSBzZWN1cmUgdGhhbiBUTFN2MS4x LiINCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Tue Oct 1 01:04:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D740E1200FE; Tue, 1 Oct 2019 01:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 RSal5Zq2eXoK; Tue, 1 Oct 2019 01:04:02 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0600.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::600]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAB71200FB; Tue, 1 Oct 2019 01:04:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Kl+Sja2TWr3fOfJ/slpdQ6CtAdV5txnD+Q/T/TcGxHTZtH10uM+WbI68gvquWAwg5Fyru+6CQerRH8qta5xG8jcTXd72k3ExdUaFV0hCE5dsqeWFXJ0pOzK61co7tT/g/ZeENR5iokuy7hz2QBX1aSSPG9S0T7nN76bBFK3EiDUvAVPze30szj37qunInjqexr5wLL0UBZwVXyLA0JLtl3M1sdxwoLJFiRjN0RZVLuOxxW3ktBU/uS8WrhWdGu3CmsVpc47zQsEnaiSh8Ua6oGdrq67CeQFj5oL5/7CRTKnDamxUo4CNqRoF56CXJ+Y2JvsHQc3EhxHvWZN8HGVv4Q== 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=MDd9Aw2nthNrs4sNT/gMErPZ+kdvlapbZ9SPUjScUOM=; b=TNQAzsyFvvQN6256/skVaWv6neb3Bt+laisD3zslMe/XWNnHM8TP6jWR4DAvbZH6r7LBH6gwMKxnkIkAiB4qHzgZYYGTt7J310W0xDfJ+TuMiVp7f/9Z1C6ydRUkYM/x/Ki4jjOwxBqvfNdmpuLnhlaeksvbu8IAh0bpYwaUn61ZIVPn5Mo9jOZVLkAExe1A0LZtFJWBe8kR28Ctm8B0ozNyAexut+agkyILEjY7uH1K7ipB6gbe7lk91vkdw2wkwlvvDDKdFmwIAwedoLrgxvYpWyDdIopUQMpp/GmCsWLgpSbSmEa6/KKG9mBw1XNSUlHeZuUUdLWgCkMz6HY7Eg== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MDd9Aw2nthNrs4sNT/gMErPZ+kdvlapbZ9SPUjScUOM=; b=hx6blJaSQEO/B7JHkU7LS6YF7HIc4o3FEcr5DT0dMkO7dvROWuW+OwMaY19PIO0Jc69gBWL+ckc/he2PKYBfLl2pIK7gOVTtYaZV40ZZJy62a+wjQAox5R5kw84FgVjZ3mCPPudkg/yk2QmSmhiOgH0CFsi5/XgZ7AtA7Ul3384= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3419.eurprd07.prod.outlook.com (10.170.244.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.12; Tue, 1 Oct 2019 08:04:00 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 08:04:00 +0000 From: John Mattsson To: Sean Turner via Datatracker , "kaduk@mit.edu" CC: "iesg-secretary@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVLbNwka9w/WHllUqjsaoZBuXNvKdGI6+A Date: Tue, 1 Oct 2019 08:03:59 +0000 Message-ID: <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> In-Reply-To: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9dcc0271-7863-4b4c-970d-08d74645eac1 x-ms-traffictypediagnostic: HE1PR07MB3419: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(136003)(396003)(346002)(376002)(189003)(199004)(13464003)(81156014)(8936002)(66066001)(5660300002)(110136005)(54906003)(76116006)(6116002)(256004)(66446008)(478600001)(71200400001)(64756008)(86362001)(8676002)(966005)(66556008)(81166006)(66476007)(71190400001)(316002)(99286004)(76176011)(58126008)(6246003)(6306002)(7736002)(14444005)(305945005)(6512007)(36756003)(476003)(33656002)(2616005)(14454004)(4326008)(66946007)(3846002)(446003)(6506007)(11346002)(486006)(53546011)(25786009)(2171002)(186003)(229853002)(6436002)(44832011)(26005)(2906002)(2501003)(6486002)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3419; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4Etk1FGLXKhyw9tIqvw47uTAcoSwjHOLUHfx1VBIE4OgA86CUZ4O86ln5HCoF/hQC24t0oTurCcwTDcR0QTEG8rBUlqsUPr6qTQxO0NTFnoB8BbkKB4eCTvM3Qe4bVQzhJE/vByq3RKKj9CPmqRcB+DUlIjiz3CFKScKXNnolTmvxQyGsxe4yleiyabh2fSMvMu6aduUuflty2uTuysW0T5JO8JjAmkazF0x8ocuM5Gz5u5o8H/0l8KPlXVPnaof/cJG5P8u0KzULh0MCJfZ4obmOO/r2HS8Ftvuco5HvpitXwZvXWewRIU2MkFPX7ZK0jjIgzYWVHVTm8XbYsUIVawMQaP4/z8bVs6yGI3gGmSLpR2NRKMVZO8NO5adXQUSUHLfHr+R9rfdU5EM0yafSAWuzcc+T1QIPvN+ZTwIoXz0tafaFY4cRVGZM4uBb+ohFHtgrzMuoKNF9L9X2Y8VHg== 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-Network-Message-Id: 9dcc0271-7863-4b4c-970d-08d74645eac1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 08:04:00.0088 (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: 3xo0AcGamRcGOgrvnUvKcsd5MGz7qs8p9ee0hewNMLbJlXBCqhL7nXNM/oeIwb6zYNjBKPOs8N0yS5Rz7qC8MAUOlyn8je1AbV1Q6kaHoVw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3419 Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 01 Oct 2019 08:04:04 -0000 SGksDQoNCkkgdGhpbmsgZHJhZnQtaWV0Zi10bHMtb2xkdmVyc2lvbnMtZGVwcmVjYXRlIG5lZWRz IHRvIHVwZGF0ZSBkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoIGFzIHdlbGwuDQoNCmRy YWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMjAgdXNlcyBEVExTIGFuZCBldmVuIHRhbGtz IGFib3V0IHN1cHBvcnQgb2YgRFRMUyAxLjAuDQoNCiAgIkVhcmxpZXIgZHJhZnRzIG9mIHRoaXMg c3BlY2lmaWNhdGlvbiByZXF1aXJlZCBEVExTDQogIDEuMCB3aXRoIHRoZSBjaXBoZXIgc3VpdGUg VExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBLCBhbmQNCiAgYXQgdGhlIHRpbWUg b2YgdGhpcyB3cml0aW5nIHNvbWUgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBzdXBwb3J0IERUTFMN CiAgMS4yOyBlbmRwb2ludHMgd2hpY2ggc3VwcG9ydCBvbmx5IERUTFMgMS4yIG1pZ2h0IGVuY291 bnRlcg0KICBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4iDQoNCllvdSBzaG91bGQgY2hlY2sgaWYg dGhlcmUgYXJlIG1vcmUgZHJhZnRzIGluIHRoZSBwdWJsaWNhdGlvbiBwcm9jZXNzIHRoYXQgbmVl ZHMgdG8gYmUgdXBkYXRlZC4NCg0KQ2hlZXJzLA0KSm9obg0KDQrvu78tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IFNlYW4gVHVybmVyIHZpYSBEYXRhdHJhY2tlciA8bm9yZXBseUBpZXRmLm9yZz4NCkRhdGU6IEZy aWRheSwgMjggSnVuZSAyMDE5IGF0IDE1OjE0DQpUbzogImthZHVrQG1pdC5lZHUiIDxrYWR1a0Bt aXQuZWR1Pg0KQ2M6ICJpZXNnLXNlY3JldGFyeUBpZXRmLm9yZyIgPGllc2ctc2VjcmV0YXJ5QGll dGYub3JnPiwgInRscy1jaGFpcnNAaWV0Zi5vcmciIDx0bHMtY2hhaXJzQGlldGYub3JnPiwgIlRM U0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtUTFNdIFB1YmxpY2F0aW9uIGhh cyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi10bHMtb2xkdmVyc2lvbnMtZGVwcmVjYXRl LTA1DQoNCiAgICBTZWFuIFR1cm5lciBoYXMgcmVxdWVzdGVkIHB1YmxpY2F0aW9uIG9mIGRyYWZ0 LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZS0wNSBhcyBCZXN0IEN1cnJlbnQgUHJhY3Rp Y2Ugb24gYmVoYWxmIG9mIHRoZSBUTFMgd29ya2luZyBncm91cC4NCiAgICANCiAgICBQbGVhc2Ug dmVyaWZ5IHRoZSBkb2N1bWVudCdzIHN0YXRlIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZS8NCiAgICANCiAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBt YWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Tue Oct 1 02:25:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6120812006A for ; Tue, 1 Oct 2019 02:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 lTe9L3LMgKka for ; Tue, 1 Oct 2019 02:25:30 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0603.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::603]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B28B120122 for ; Tue, 1 Oct 2019 02:25:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VyjX+bpCSFSO63mXz80qvAJK5XnVhPZszDBvB6hiJe/s+dm+lQVexFI/MMgrYKMRz6FRFYEfIJnAXzUgf3QgCjyWRI1ASl/z1832U+wpqQejmIEnAWh7c0zX8f0lObdTG0I4StRJFQXnUY36bs0iA/J6gOHff+03aDwv77PWPbJWHuo63QQBjTL7WTr0e0nSD+7P1di8xhfDtvOgYL5vjTWRhK5CFutY3/RKJjQ8fN1jmsCcryLX8cdcyUeQeiZmigBibhAyYU45RDDpnbHGUf1GzTXWt9XKq6Ju0lrSA/4fLdRQexm7laA3Ns4cwDUePJdo8LfpRP8A1rFWccUq/Q== 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=lfGr48uqz0furxZ55dZbGXmLOC+b3odHxcIv4ZePpJA=; b=Igdxf4PYLdp6ZG++XnZ9UXn3PRc3nMffVuQbFJmd53rKpU3ZqHuemtdLjPMwfmMUfHVC2FAM13EGweazvgrIJBwLWRljw6hDqaLtVKHtCoX5acMMxqwl4YSAnhU0FD8KFtbd8BklAdyh676agZW9cvWh7q2/k6M++wG96Sd6YZqRyxnv+d3nwsQWOpexe87Z5UPI2JtfHtw5IRSYAPDFyBMsIN2lF4w+iWJFvaVbq2RafkAVSRntWhNkalUYgj+AAC3iHqEb2FGbhepvPz8F2NZAU00smvu6ZA6ETInsZwLxYXiMgPXfG9MGMDkOxQUL696UczEWhSNkMY7VsXjSag== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lfGr48uqz0furxZ55dZbGXmLOC+b3odHxcIv4ZePpJA=; b=l16KWxYS6GpF2nUogvGmch4m5kF062wBvHKOm7KGHeG/cpg2Of2d3cB+6OO1UU9SycyZKtC9rDepSONdjcKpNz7J177BdR6CG1sxSul6K/EPx4SwQeGEFKDaOVYpHQcjw+Pn8sShwlqkGPzXSzaqJkRGStSDzO+eAnScRrIJJpE= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4331.eurprd07.prod.outlook.com (20.176.167.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Tue, 1 Oct 2019 09:25:25 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 09:25:25 +0000 From: John Mattsson To: Peter Gutmann , Hubert Kario , "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZv?= =?utf-8?Q?r_erratum=3F?= Thread-Index: AQHVd/qgiyjnpsmL4ES+HvQhRBeDQqdFpeAA Date: Tue, 1 Oct 2019 09:25:25 +0000 Message-ID: <4461A9C1-2164-4000-BDCF-76BC51375D62@ericsson.com> References: <1803994.nvTnDQYtSi@pintsize.usersys.redhat.com> <1569894614783.19143@cs.auckland.ac.nz> In-Reply-To: <1569894614783.19143@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a2f9915e-70af-43e0-4dd3-08d746514aaf x-ms-traffictypediagnostic: HE1PR07MB4331: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(136003)(376002)(366004)(189003)(199004)(5660300002)(446003)(8936002)(305945005)(81166006)(81156014)(25786009)(11346002)(486006)(33656002)(86362001)(44832011)(6436002)(2616005)(6246003)(476003)(58126008)(102836004)(6506007)(7736002)(4744005)(6512007)(76176011)(71190400001)(316002)(71200400001)(26005)(3846002)(14454004)(36756003)(2501003)(186003)(66446008)(6486002)(229853002)(6116002)(66476007)(478600001)(14444005)(2906002)(76116006)(64756008)(66556008)(110136005)(256004)(66066001)(99286004)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4331; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: rBzYvFr0mKqSBe9r4Ff+Pbe/C8Sr4K4eVqLANZA/6dMbtmtaZBcImus51OgJvbbNdTmORcu4TTSk3mCFEOVgdv6/MlxPKUl0s63YY8Qx+rKIaXMNOF+EgLmouTFwsIDA/G46qJezZtX+SIuoOG/F+JzF6nPpATPdxNWbCWGCV9bs/a6SUWa0XuhT36pm/kkCSyC2OIgNYtHSMnTAGaWV42JZtUKVTVl5lFAq4hdCv2VpQ0qw7cN7r1wbLw9MBSlg8riFyTHl/AnpwXK9roRzZ3IFUVYVTKEdYE0J/oVQM7R2ub/AClZmAKzC9fv6oH9g8qDsboPRUFSE7utwGywdBHZr9WP4rb8V1I3iHI3iolMKY6JHUzW8IBdcxLzTP3utfAgPDijQnl7Lv8P7DLWODWJD7McgFeRHnqti7XeVUzE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <937CB38C1C01F346BE112717DAED4409@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2f9915e-70af-43e0-4dd3-08d746514aaf X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 09:25:25.3433 (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: 6tvhwYh/J8238o3H6Zyvvm01q1uDavizcF38vdMY7jcNvYmK/ZnzItHoA7BUwtF6V3nMc3iciDzrvZ1tyupXufTwYZcGAAB3xgZRgI/CUIM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4331 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 09:25:31 -0000 SHViZXJ0IEthcmlvIDxoa2FyaW9AcmVkaGF0LmNvbT4gd3JvdGU6DQogICAgDQo+IE5vdywgSSBk b24ndCBoYXZlIGFjY2VzcyB0byBYOS42Mi0yMDA1LCBidXQgdGhlcmUncyBhIHBvc3NpYmlsaXR5 IG9mIGNvbmZ1c2lvbi4NCg0KSSB0aGluayByZWZlcmVuY2VzIHRvIHNwZWNpZmljYXRpb25zIGJl aGluZCBwYXl3YWxscyBhbmQgb3RoZXIgdHlwZXMgb2YgbGltaXRlZCBhY2Nlc3MgaXMgYSBtYWpv ciBwcm9ibGVtLiBOb3Qgb25seSBmb3IgdGhlIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzLCBidXQg YWxzbyBmb3IgcmVzZWFyY2hlcnMgYW5kIGltcGxlbWVudG9ycy4gSW4gZ2VuZXJhbCwgSSB0aGlu ayBwZW9wbGUgc2hvdWxkIGJlIGFibGUgdG8gaW1wbGVtZW50IGFuZCBhbmFseXplIElFVEYgc3Rh bmRhcmRzIHdpdGhvdXQgaGF2aW5nIHRvIHBheSBmb3IgYWNjZXNzLg0KDQpPcGVuLWFjY2VzcyBp cyBldmVuIG1vcmUgaW1wb3J0YW50IGZvciBzZWN1cml0eSBzcGVjaWZpY2F0aW9ucy4gQU5TSSBY LjYyIGlzIGhvcGVmdWxseSBxdWl0ZSB3ZWxsLXN0dWRpZWQsIGJ1dCBmb3Igb3RoZXIgcmVmZXJl bmNlcywgdGhlIGxhY2sgb2YgYW5hbHlzaXMgb2Z0ZW4gbGVhZHMgdG8gbWlzdGFrZXMgYW5kIHVu a25vd24gd2Vha25lc3Nlcy4NCg0KSSB3b3VsZCBsaWtlIHRoZSBJRVRGIHRvIHRha2UgYSBtdWNo IHN0cm9uZ2VyIHN0YW5jZSBhZ2FpbnN0IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIHBheXdhbGxz LiANCg0KQ2hlZXJzLA0KSm9obg0KDQo= From nobody Tue Oct 1 03:47:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEC9120137 for ; Tue, 1 Oct 2019 03:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 yLbKUkocFy8B for ; Tue, 1 Oct 2019 03:47:28 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.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 0814412001A for ; Tue, 1 Oct 2019 03:47:27 -0700 (PDT) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2019 06:47:20 -0400 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 1 Oct 2019 06:47:20 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0415.000; Tue, 1 Oct 2019 06:47:19 -0400 From: Dan Brown To: John Mattsson , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZv?= =?utf-8?Q?r_erratum=3F?= Thread-Index: AdV4RZj0/krq7yA89EekKREnIpqJfw== Date: Tue, 1 Oct 2019 10:47:19 +0000 Message-ID: <20191001104718.8626261.12105.36904@blackberry.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0227786736==" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 10:47:30 -0000 --===============0227786736== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Re ECDSA specs and paywells: ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 year= s, despite my weak effort. A revival, ANSI X9.142, with almost the same content is under way, though e= ven its fate is unsure. Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA a= nd EdDSA (not ASN.1?), which many may like (even better than ANSI). Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or not, d= espite my weak effort. IETF has specs for sigs and their formats already, no? Then there's ISO, IEEE, ... =C2=A0 Original Message =C2=A0 From: John Mattsson Sent: Tuesday, October 1, 2019 5:25 AM To: Peter Gutmann; Hubert Kario; TLS@ietf.org Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erratum? Hubert Kario wrote: > Now, I don't have access to X9.62-2005, but there's a possibility of conf= usion. I think references to specifications behind paywalls and other types of lim= ited access is a major problem. Not only for the standardization process, b= ut also for researchers and implementors. In general, I think people should= be able to implement and analyze IETF standards without having to pay for = access. Open-access is even more important for security specifications. ANSI X.62 i= s hopefully quite well-studied, but for other references, the lack of analy= sis often leads to mistakes and unknown weaknesses. I would like the IETF to take a much stronger stance against normative refe= rences to paywalls.=20 Cheers, John _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DDwICAg&c=3DyzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r= =3DqkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=3DA-9JTBh7dU_hCbOrrx-iACEm= GPbjipnEohllYGLju6I&s=3Dp2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=3D --===============0227786736== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg6QMIIH RDCCBiygAwIBAgIKcjhm+AABAAJMhDANBgkqhkiG9w0BAQsFADBWMRMwEQYKCZImiZPyLGQBGRYD bmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJ c3N1aW5nIENBIDEwHhcNMTkwMzE5MDM1MTE4WhcNMjAwMjI2MjIzNjU1WjCBgDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTENMAsGA1UECxMEQU1FUjELMAkGA1UECxMC Q0ExFDASBgNVBAsTC01pc3Npc3NhdWdhMQ4wDAYDVQQLEwVVc2VyczESMBAGA1UEAxMJRGFuIEJy b3duMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkNMTd/lq8fjk77f6KlOwNglIotfS bGFfyXroxfD9tYltVP6QuHgfrTO7GmPaUTEEtyqCLgY91Md6DBmT0Wq6NdXxa+IOjLP9aH5I3haf GKYeKpLYgwhXO9vuiEMpTH84kFIvs7FM+NRCfZOB9NCCpQ3aJHjGC6OB2g/FaJi0sHLLj2D5KjbQ 0dAN5vHp2yaaR86+SihIUeUJAem+r4tDFD3xmAwE0oKAMiAdWtK0bx5AJwfiMnQixw+r1WrTS2zy HQ+dMBbhln07ZbG6irGKV59ecMfdFe5q5sb3pAfVoyjCiwT2jiTQbegT7OxsyV1gGXh8j+Uf7RMF L6IEG9eBgwIDAQABo4ID5zCCA+MwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBsAwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFCAICBggrBgEFBQcDBDBbBgNVHREEVDBShgxQSU46MkMwREI2RTWg KAYKKwYBBAGCNxQCA6AaDBhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb22BGGRhbmlicm93bkBibGFj a2JlcnJ5LmNvbTAdBgNVHQ4EFgQUrbrWl1b9yJwwqTQAIwCtdHIcaowwHwYDVR0jBBgwFoAUGi9L S9sHyUk7idYyCCeingvzD2swggEyBgNVHR8EggEpMIIBJTCCASGgggEdoIIBGYZAaHR0cDovL2Ny bC5yaW0ubmV0L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIwQ0ElMjAxLmNybIaB 1GxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3VpbmclMjBDQSUyMDEsQ049 TUNBMDEwQ05DLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9u TGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBAwYIKwYBBQUHAQEE gfYwgfMwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnJpbS5uZXQvb2NzcDCBygYIKwYBBQUHMAKG gb1sZGFwOi8vL0NOPUJsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIwQ0ElMjAxLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNl cnRpZmljYXRpb25BdXRob3JpdHkwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh7+XS4a5gSSG wYEyg9vyJYLc2AGBAIbM/AOegDICAWQCAQ0wTwYDVR0gAQH/BEUwQzBBBgorBgEEAZtKEwMCMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L0NQUy9DUFN0YXRlbWVudC5odG0wMwYJKwYB BAGCNxUKBCYwJDAKBggrBgEFBQcDAjAKBggrBgEFBQgCAjAKBggrBgEFBQcDBDANBgkqhkiG9w0B AQsFAAOCAQEAoS8FKnl/YLW/XYbvshSD0GGdjzM+vXGXnYMaH+xB8YOqVPZfaPm+MZMX5eE2HgzE ePeH7c6YQBCRNCuTcX7ZtiOuU3L0p1MKaVmNmNVeb3y2bdS1CO4v4DFEk1VDavnarXXoXWYJNPQt MYQ9biVXNds8Cq2TJA3YkU385210cMN3dvus/3/yiIHZqY6GJr6eYQiB2kz3IomkqwMjQSup73c7 bREBgX2wKXfTJBzoH6RNz0gAckkNQbchb3Mv5BXUicCoyMsgM1CKIGqBttGMQNFhVYwyEYOJoCFd F9cAN3H62vgxYohnQkVH4FFKDa8+H/A7ZkKmKsbdiFtfp7+MZjCCB0QwggYsoAMCAQICCnI4ZvgA AQACTIQwDQYJKoZIhvcNAQELBQAwVjETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixk ARkWA3JpbTEqMCgGA1UEAxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUgSXNzdWluZyBDQSAxMB4XDTE5 MDMxOTAzNTExOFoXDTIwMDIyNjIyMzY1NVowgYAxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJ kiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYDVQQLEwtNaXNz aXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJDTE3f5avH45O+3+ipTsDYJSKLX0mxhX8l66MXw/bWJbVT+kLh4 H60zuxpj2lExBLcqgi4GPdTHegwZk9FqujXV8WviDoyz/Wh+SN4WnximHiqS2IMIVzvb7ohDKUx/ OJBSL7OxTPjUQn2TgfTQgqUN2iR4xgujgdoPxWiYtLByy49g+So20NHQDebx6dsmmkfOvkooSFHl CQHpvq+LQxQ98ZgMBNKCgDIgHVrStG8eQCcH4jJ0IscPq9Vq00ts8h0PnTAW4ZZ9O2Wxuoqxilef XnDH3RXuaubG96QH1aMowosE9o4k0G3oE+zsbMldYBl4fI/lH+0TBS+iBBvXgYMCAwEAAaOCA+cw ggPjMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgbAMCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEF BQgCAgYIKwYBBQUHAwQwWwYDVR0RBFQwUoYMUElOOjJDMERCNkU1oCgGCisGAQQBgjcUAgOgGgwY ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20wHQYDVR0O BBYEFK261pdW/cicMKk0ACMArXRyHGqMMB8GA1UdIwQYMBaAFBovS0vbB8lJO4nWMggnop4L8w9r MIIBMgYDVR0fBIIBKTCCASUwggEhoIIBHaCCARmGQGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0Jl cnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENBJTIwMS5jcmyGgdRsZGFwOi8vL0NOPUJsYWNr QmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIwQ0ElMjAxLENOPU1DQTAxMENOQyxDTj1DRFAs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RD bGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQMGCCsGAQUFBwEBBIH2MIHzMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwgcoGCCsGAQUFBzAChoG9bGRhcDovLy9DTj1CbGFj a0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIw S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERD PWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgBgQCGzPwD noAyAgFkAgENME8GA1UdIAEB/wRFMEMwQQYKKwYBBAGbShMDAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9DUFMvQ1BTdGF0ZW1lbnQuaHRtMDMGCSsGAQQBgjcVCgQmMCQwCgYIKwYB BQUHAwIwCgYIKwYBBQUIAgIwCgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAKEvBSp5f2C1 v12G77IUg9BhnY8zPr1xl52DGh/sQfGDqlT2X2j5vjGTF+XhNh4MxHj3h+3OmEAQkTQrk3F+2bYj rlNy9KdTCmlZjZjVXm98tm3UtQjuL+AxRJNVQ2r52q116F1mCTT0LTGEPW4lVzXbPAqtkyQN2JFN /OdtdHDDd3b7rP9/8oiB2amOhia+nmEIgdpM9yKJpKsDI0Erqe93O20RAYF9sCl30yQc6B+kTc9I AHJJDUG3IW9zL+QV1InAqMjLIDNQiiBqgbbRjEDRYVWMMhGDiaAhXRfXADdx+tr4MWKIZ0JFR+BR Sg2vPh/wO2ZCpirG3YhbX6e/jGYxggH2MIIB8gIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQx EzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3Vp bmcgQ0EgMQIKcjhm+AABAAJMhDALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xOTEwMDExMDQ3MTdaMC8GCSqGSIb3DQEJBDEiBCAJd93pDGI0 Y8ds1c3Ah+ZAfktZFUM4yS8wFaZbltGKxjALBgkqhkiG9w0BAQEEggEAU1vqB3moEzTgeo9SNuJG HZ98sSrERDYiYaXacJCY3obMOF0wD/jrEYwTCUvgjmk1aTRj27C6cBQjolaE6ga/hiiu4oU5i9oy VsaQkXcls1bhTIslWO91/vAzSxVMgjfljudPtHKYEgGgxFKpLAAr8exT1jgQxkHxzQVlYhYTpJNP TngVxGKpybmU9XODk/eWj6R3Wm23JBSjYXZYAUKmWVzil0X2HDOaKUUL40nAlFje54OzC5y1ENuQ fuNeCDM9PFf4LHv8jWPoUmdyVGuXIjNf477F8AHRSfCtHEB0Rg006IMrzik+JsPAxBKu2PeThNcC pKpHUscM71lSlWjy9AAAAAAAAA== --===============0227786736==-- From nobody Tue Oct 1 03:51:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2C3120137; Tue, 1 Oct 2019 03:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AqkhbQiXkuWm; Tue, 1 Oct 2019 03:51:31 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 B960912001A; Tue, 1 Oct 2019 03:51:31 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 41so11084602oti.12; Tue, 01 Oct 2019 03:51:31 -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=aKf6RPCYFYMH5+0LrOBjApLuSGVXw+eeM96ww9hyKZE=; b=o/j8uLGwKiZefAOv30XLyIt2EgECB9c1T1y6fUxJjVc69RJFgfDbqG3N6E8Wf+7Vnw FJYdCZbYN2IYiv6dHiUxhrojEOS2VuU3npX8q0iCC09UukhtbW2COfDCEqdtO8b1jxg/ rEpW0gpCOhCKprwN8gje4Y+p8tvN+2HQCbRuYBNGWUif/Ldfld9dRpaYzjxAn+KfRcBQ R6TAfZUy990VnjslMJ8rPcOBaO86DCcS9+rMW8HFn0fQNwBCVXrwBmlrKmL4FaEzID1R 0vAtVFbamY2RfoiF7SQP2EvvPThBFPf2jhvzZvu50pvDXvP7l7PqytExR11po1wnjff0 KS2g== 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=aKf6RPCYFYMH5+0LrOBjApLuSGVXw+eeM96ww9hyKZE=; b=GYhI+J1G3sicRIU6OY/u1jStDSufNn4/ZbBQ+Un5c9Lapmmd3/+I1PdP4fXpXnTTyN hsaxNM+mQPXZPX1Pa5nToIxtL43Jv7oVMZXUhAmmdXh++/YS6eVTY/5UvEcmi0ZxwwDM 4HvmIIb0audoaSZXXR/T6y+G9+eg07n8StyzZ4MwCotseUbKbUvyuKG7HPffHqQh4OFm cIjtCL+hkaQKfvsy2GYGLg8FiNUzSLmNT8BCDvps7ebxMBiT2xdhCLO3HZoOsnxnEOg2 P4YY4wF/ZLxaOYkqhkC5E1escdhkJihE7TgKS52jdXA6tZmCYRLf/BWvJ4plsBSfWNN3 +iyw== X-Gm-Message-State: APjAAAUr5QslZhEnUcB0suGJyFyWM/98h+hKfvpfITexmP4HarL0Ssdo Y580hb8knfb2Atab7YWBaQQqEK+rRz5Kn46yLIg= X-Google-Smtp-Source: APXvYqzIEyLuIlz6GB8iH9ZIP/ECafGAetl6Za7gDIq2rfKwIhynj4G64iGI5KdIUAl3yqhBK3XgJsWDk8cQKF0mEZ4= X-Received: by 2002:a9d:8a7:: with SMTP id 36mr17852206otf.114.1569927091066; Tue, 01 Oct 2019 03:51:31 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> In-Reply-To: <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> From: Kathleen Moriarty Date: Tue, 1 Oct 2019 06:50:55 -0400 Message-ID: To: John Mattsson Cc: Sean Turner via Datatracker , "kaduk@mit.edu" , "iesg-secretary@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000961dbe0593d722f4" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 01 Oct 2019 10:51:34 -0000 --000000000000961dbe0593d722f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2019 at 4:04 AM John Mattsson wrote: > Hi, > > I think draft-ietf-tls-oldversions-deprecate needs to update > draft-ietf-rtcweb-security-arch as well. > > draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support > of DTLS 1.0. > > "Earlier drafts of this specification required DTLS > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > at the time of this writing some implementations do not support DTLS > 1.2; endpoints which support only DTLS 1.2 might encounter > interoperability issues." > > Good catch. > You should check if there are more drafts in the publication process that > needs to be updated. > This is something the security directorate should be watching for to check in reviews prior to publication. The ADs will also be adding this to their list of things to look for in drafts that are in the publication queue as that's been the practice for some time. A proactive search could be helpful, but having the stop gap in place is likely best as it could come in in drafts that have not been written yet. Best regards, Kathleen > > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: TLS on behalf of Sean Turner via Datatracker > > Date: Friday, 28 June 2019 at 15:14 > To: "kaduk@mit.edu" > Cc: "iesg-secretary@ietf.org" , " > tls-chairs@ietf.org" , "TLS@ietf.org" > Subject: [TLS] Publication has been requested for > draft-ietf-tls-oldversions-deprecate-05 > > Sean Turner has requested publication of > draft-ietf-tls-oldversions-deprecate-05 as Best Current Practice on behal= f > of the TLS working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > _______________________________________________ > 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 > --=20 Best regards, Kathleen --000000000000961dbe0593d722f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 1, 2019 at 4:04 AM John M= attsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:
Hi,

I think draft-ietf-tls-oldversions-deprecate needs to update draft-ietf-rtc= web-security-arch as well.

draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support o= f DTLS 1.0.

=C2=A0 "Earlier drafts of this specification required DTLS
=C2=A0 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and<= br> =C2=A0 at the time of this writing some implementations do not support DTLS=
=C2=A0 1.2; endpoints which support only DTLS 1.2 might encounter
=C2=A0 interoperability issues."

Good catch.
=C2=A0
You should check if there are more drafts in the publication process that n= eeds to be updated.

This is something t= he security directorate should be watching for to check in reviews prior to= publication.=C2=A0 The ADs will also be adding this to their list of thing= s to look for in drafts that are in the publication queue as that's bee= n the practice for some time.=C2=A0 A proactive search could be helpful, bu= t having the stop gap in place is likely best as it could come in in drafts= that have not been written yet.

Best regards,
Kathleen=C2=A0
tls= -bounces@ietf.org> on behalf of Sean Turner via Datatracker <noreply@ietf.org><= br> Date: Friday, 28 June 2019 at 15:14
To: "kaduk@mit.edu<= /a>" <kaduk@mit.= edu>
Cc: "iesg= -secretary@ietf.org" <iesg-secretary@ietf.org>, "tls-chairs@ietf.org" <= tls-chairs@ietf.or= g>, "TLS@ietf= .org" <tls@ie= tf.org>
Subject: [TLS] Publication has been requested for draft-ietf-tls-oldversion= s-deprecate-05

=C2=A0 =C2=A0 Sean Turner has requested publication of draft-ietf-tls-oldve= rsions-deprecate-05 as Best Current Practice on behalf of the TLS working g= roup.

=C2=A0 =C2=A0 Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-o= ldversions-deprecate/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 TLS@ietf.or= g
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tls=


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


--

Best regards,
Kathleen
--000000000000961dbe0593d722f4-- From nobody Tue Oct 1 04:03:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C1212013B; Tue, 1 Oct 2019 04:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vE_QP9Yp6C1W; Tue, 1 Oct 2019 04:03:03 -0700 (PDT) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 06BFB120071; Tue, 1 Oct 2019 04:03:03 -0700 (PDT) Received: by mail-ot1-x32d.google.com with SMTP id o44so11128246ota.10; Tue, 01 Oct 2019 04:03: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=Tt5JSGL8IoLk8TkPLnWeY0SHhz4cm0yCRXCE8210c30=; b=PWZg1vBcVTtLrpy8mRVcPJ0wFYyh4u5ErWdMIzcexiUp7uShc6tvcpiWUPinMqde08 ZVeNz9cweOgWSWKy+FTkPJbOtF+qgMw823+JLZvFWFhurgLG8Q8oJOQAujb5lkF1J7uo LYESAmKh2OArkJ33ExmeSng0aF5dd0sob/LhdL5p/mtJzsLiOnIUcZ+J7Aiok/sgYu5/ 2uEWp3Ve9c2sXG+4qSbdMnFSKKAzOT9TfFgT5RLZCdc1L8+3PeVjEpILAnhsV4hpta4P Bz33kJgYccEeNycs2MZerVYmTjALzlli4A3Y4/9xO12Xj8NM5ZqKF/t0wjW5seqM+Zc6 YdfQ== 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=Tt5JSGL8IoLk8TkPLnWeY0SHhz4cm0yCRXCE8210c30=; b=K7LoKiILE9tFqPppStjwYvwT9C1Is7L7Kqy+gWrp7mDP7LN7kSskJOMBzXMvhHMEAT xuMC1iWpezKKtePX7Npok+Qw1AUxc6SFe0us90C0llmWi4iWlf5LlnIWCf3UDh4AnnQb N8hAIEBwii7jmChrIL3iL2xdohxDea4eOCQRtLvjuy2MWocdps7rcwb61qBk0bD1ZhgP RoeHjk4GCiwJHCg+BWKcuTSnS7jJLcbEEPJm0IS7oaijp8iXvo2fdcZdSztFZdl/Xt3h BxMGp+wdFNzSJdjvS5CpQKOYgRsHW1wYb1UGsgz4voXfL2V361MwIDIKc5IySWoavhkr NMYg== X-Gm-Message-State: APjAAAWm7u7wmGjvEGbnCzK6etMB55u6t6bOqI+7ZecN6ziKPEWvOFGz eqe71JTwcwVZ9lwtNGkYEoNc7B8OPBnfayh3ye0= X-Google-Smtp-Source: APXvYqyy5tCxVGK5N5CMxtQ3yPu3t2Lw1B9u8tg21b7pz+0/26vzCwGCIld18MlXUlXvU/YOXemixvOshGcoZRPXCng= X-Received: by 2002:a9d:6642:: with SMTP id q2mr15957115otm.250.1569927782332; Tue, 01 Oct 2019 04:03:02 -0700 (PDT) MIME-Version: 1.0 References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> In-Reply-To: From: Kathleen Moriarty Date: Tue, 1 Oct 2019 07:02:26 -0400 Message-ID: To: John Mattsson Cc: "Salz, Rich" , "TLS@ietf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9fe540593d74bb1" Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 11:03:07 -0000 --000000000000c9fe540593d74bb1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2019 at 3:58 AM John Mattsson wrote: > Kathleen Moriarty wrote: > > >NIST has pushed back their date for US government organizations to have = a > plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of that? > > NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I > think that is a good and ambitious plan. In fact it would be very good if > IETF agreed on the same requirement. > Right, so they are not saying TLSv1.2 can't be used at that time, only that TLSv1.3 must be supported. "It requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and requires support for TLS 1.3 by January 1, 2024. " This is a good goal and fairly reasonable given that a number of customers are asking for TLSv1.3. Government customers will drive this further in the US. > > > I think encouraging implementation of TLSv1.3 is good and important, bu= t > are there other ways besides deprecation? > > Yes, I think there is at least two things IETF can do: > > - The first thing is to do like NIST and already now give implementors a > date when support for TLS 1.3 is required. > We've never done that as far as I know? SHould we? Or should this be left to documents like NIST's and other regulatory requirements that drive customer purchasing decisions? > > - The second thing is to do like 3GPP and mandate support for TLS 1.3 in > new implementations and deployments. > The second is typical from the point of publication. So back when I was an AD, we were already looking for TLS mentions in drafts and once TLSv1.3 was published, is when you switch from the prior version being required to support for TLSv1.3 being required. I'm guessing this continued (especially with Eric as an AD for another year after I stepped down), but I am not watching closely. > This would avoid two thing that happened in the past. First, IETF > published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 > almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 > months after publishing a draft relying on DTLS 1.0, IETF started working > on a draft forbidding it=E2=80=99s use. > Unfortunately, things like that do happen, but shouldn't. In some instances, an explanation is made as to why an older version is required and it's an exception. Was that the case? (Sorry I don't have the time to research the old discusses and history of the RFC at the moment). It's not the right thing, but with TLS versions, they usually stick out a bit when you read a draft and it's an easy thing to catch if you're skimming a draft as an AD with 400 pages of reading to get through for a telechat. Bets regards, Kathleen > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: Kathleen Moriarty > Date: Thursday, 26 September 2019 at 15:50 > To: "Salz, Rich" > Cc: John Mattsson , "TLS@ietf.org" < > TLS@ietf.org>, "saag@ietf.org" > Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation > > > > Sent from my mobile device > > > On Sep 26, 2019, at 9:02 AM, Salz, Rich wrote: > > > > These are excellent points. Perhaps they can be squeezed into > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > ? It's been waiting 90 days, a brief reset might not hurt :) > > > This would not be a brief reset and I=E2=80=99d prefer not to see the= m > combined into the existing draft with WG agreement. > > With RFC7525, TLSv1.2 can be configured to be secure. I see the > points made, but don=E2=80=99t see the urgency as obsolete is different f= rom > depreciation. > > I think encouraging implementation of TLSv1.3 is good and important, > but are there other ways besides deprecation? > > NIST has pushed back their date for US government organizations to > have a plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of= that? > > A vulnerability would speed things up, but I do hope that does not > happen. > > Best regards, > Kathleen > > > On 9/26/19, 8:18 AM, "John Mattsson" 40ericsson.com@dmarc.ietf.org> wrote: > > > > Hi, > > > > Hopefully, we have learned some lessons from the TLS 1.0 and TLS > 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken = in > a myriad subtle ways and should according to me optimally have been > deprecated years ago. > > > > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at > that time not forbid use of TLS 1.1 as that would potentially break > interoperability with some Rel-12 nodes (that had TLS 1.2 as should > support). The lesson 3GPP learned from this was the need to as early as > possible mandate support of new protocol versions. With TLS 1.3, 3GPP too= k > action early and TLS 1.3 support was mandated for network nodes in Rel-15 > (2018) and for mobile phones in Rel-16 (2019). > > > > At some point in time we will want to deprecate TLS 1.2. To > enable that, TLS 1.3 support should be mandated or encouraged as much as > possible. I would like to avoid a situation where we want to deprecate TL= S > 1.2 but realize that it cannot be done because some implementations only > support TLS 1.2. How can IETF enable smoother and faster deprecations in > the future? The browser industry has a decent track record of algorithm > deprecation and I hope to soon see the following warning in my browser: > > > > =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D > > > > Other industries have less stellar track records of algorithm > deprecation. > > > > How can IETF be more pro-active regarding deprecations in the > future? In the best of words, nobody should be surprised when IETF > deprecates a protocol version or algorithm. NIST and similar organization= s > in other countries have the practice to long time in advance publish > deadlines for security levels, algorithms, and protocol versions. Can the > IETF do something similar, not just for TLS but in general? For TLS, ther= e > are several things to deprecate, in addition to MD5 and SHA-1, also > PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher > suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the futu= re. > > > > Cheers, > > John > > > > _______________________________________________ > > 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 > > > --=20 Best regards, Kathleen --000000000000c9fe540593d74bb1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 1, 2019 at 3:58 AM John M= attsson <john.mattsson@eri= csson.com> wrote:
Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:=

>NIST has pushed back their date for US government organizations to have= a plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of that?=

NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024. I thi= nk that is a good and ambitious plan. In fact it would be very good if IETF= agreed on the same requirement.

Right,= so they are not saying TLSv1.2 can't be used at that time, only that T= LSv1.3 must be supported.=C2=A0=C2=A0

"I= t requires that TLS 1.2 configured with FIPS-based cipher suites be support= ed by all government TLS servers and clients and requires support for TLS 1= .3 by January 1, 2024.=C2=A0"

<= div>This is a good goal and fairly reasonable given that a number of custom= ers are asking for TLSv1.3.=C2=A0 Government customers will drive this furt= her in the US.
=C2=A0

> I think encouraging implementation of TLSv1.3 is good and important, b= ut are there other ways besides deprecation?

Yes, I think there is at least two things IETF can do:

- The first thing is to do like NIST and already now give implementors a da= te when support for TLS 1.3 is required.

We've never done that as far as I know?=C2=A0 SHould we?=C2=A0 Or sho= uld this be left to documents like NIST's and other regulatory requirem= ents that drive customer purchasing decisions?
=C2=A0

- The second thing is to do like 3GPP and mandate support for TLS 1.3 in ne= w implementations and deployments.

The = second is typical from the point of publication.=C2=A0 So back when I was a= n AD, we were already looking for TLS mentions in drafts and once TLSv1.3 w= as published, is when you switch from the prior version being required to s= upport for TLSv1.3 being required.=C2=A0 I'm guessing this continued (e= specially with Eric as an AD for another year after I stepped down), but I = am not watching closely.=C2=A0


This would avoid two thing that happened in the past. First, IETF published= RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 almost 6 year= s after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 months after publ= ishing a draft relying on DTLS 1.0, IETF started working on a draft forbidd= ing it=E2=80=99s use.

Unfortunately, th= ings like that do happen, but shouldn't.=C2=A0 In some instances, an ex= planation is made as to why an older version is required and it's an ex= ception.=C2=A0 Was that the case?=C2=A0 (Sorry I don't have the time to= research the old discusses and history of the RFC at the moment).=C2=A0

It's not the right thing, but with TLS versions,= they usually stick out a bit when you read a draft and it's an easy th= ing to catch if you're skimming a draft as an AD with 400 pages of read= ing to get through for a telechat.

Bets regards,
Kathleen


Cheers,
John

=EF=BB=BF-----Original Message-----
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Thursday, 26 September 2019 at 15:50
To: "Salz, Rich" <rsalz@akamai.com>
Cc: John Mattsson <john.mattsson@ericsson.com>, "TLS@ietf.org" <TLS@ietf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation



=C2=A0 =C2=A0 Sent from my mobile device

=C2=A0 =C2=A0 > On Sep 26, 2019, at 9:02 AM, Salz, Rich <rsalz@akamai.com> wrote: =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > These are excellent points.=C2=A0 Perhaps they can be sq= ueezed into https://datatracke= r.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/=C2=A0 ?=C2=A0 It&#= 39;s been waiting 90 days, a brief reset might not hurt :)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 This would not be a brief reset and I=E2=80=99d prefer not to= see them combined into the existing draft with WG agreement.

=C2=A0 =C2=A0 With RFC7525, TLSv1.2 can be configured to be secure.=C2=A0 I= see the points made, but don=E2=80=99t see the urgency as obsolete is diff= erent from depreciation.

=C2=A0 =C2=A0 I think encouraging implementation of TLSv1.3 is good and imp= ortant, but are there other ways besides deprecation?

=C2=A0 =C2=A0 NIST has pushed back their date for US government organizatio= ns to have a plan to support TLSv1.3, what=E2=80=99s the driver to get ahea= d of that?

=C2=A0 =C2=A0 A vulnerability would speed things up, but I do hope that doe= s not happen.

=C2=A0 =C2=A0 Best regards,
=C2=A0 =C2=A0 Kathleen

=C2=A0 =C2=A0 > On 9/26/19, 8:18 AM, "John Mattsson" <john.= mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Hi,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Hopefully, we have learned some lessons fro= m the TLS 1.0 and TLS 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Mar= tin Thomson) broken in a myriad subtle ways and should according to me opti= mally have been deprecated years ago.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 3GPP mandated support of TLS 1.2 in Rel-13 = (2015) but could at that time not forbid use of TLS 1.1 as that would poten= tially break interoperability with some Rel-12 nodes (that had TLS 1.2 as s= hould support). The lesson 3GPP learned from this was the need to as early = as possible mandate support of new protocol versions. With TLS 1.3, 3GPP to= ok action early and TLS 1.3 support was mandated for network nodes in Rel-1= 5 (2018) and for mobile phones in Rel-16 (2019).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 At some point in time we will want to depre= cate TLS 1.2. To enable that, TLS 1.3 support should be mandated or encoura= ged as much as possible. I would like to avoid a situation where we want to= deprecate TLS 1.2 but realize that it cannot be done because some implemen= tations only support TLS 1.2. How can IETF enable smoother and faster depre= cations in the future? The browser industry has a decent track record of al= gorithm deprecation and I hope to soon see the following warning in my brow= ser:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.= 3 or later.=E2=80=9D
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Other industries have less stellar track re= cords of algorithm deprecation.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 How can IETF be more pro-active regarding d= eprecations in the future? In the best of words, nobody should be surprised= when IETF deprecates a protocol version or algorithm. NIST and similar org= anizations in other countries have the practice to long time in advance pub= lish deadlines for security levels, algorithms, and protocol versions. Can = the IETF do something similar, not just for TLS but in general? For TLS, th= ere are several things to deprecate, in addition to MD5 and SHA-1, also PKC= S1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suite= s (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the future.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 John
=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/mailma= n/listinfo/tls
=C2=A0 =C2=A0 >
=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




--

Best regards,
Kathleen
--000000000000c9fe540593d74bb1-- From nobody Tue Oct 1 04:07:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2656B12013C for ; Tue, 1 Oct 2019 04:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lERzKl9ap3sj for ; Tue, 1 Oct 2019 04:07:15 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 7A2D112006D for ; Tue, 1 Oct 2019 04:07:15 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id i185so13964665oif.9 for ; Tue, 01 Oct 2019 04:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/Ap5RNMC0CVPZqjxiMU28eCpV//gWUJ0sESeZWXfWzA=; b=iTNy++7EMQeQZe0FZls/zRJEcm/PhCGCuVXUdeRzMO0rAVEKkLj9aB61QdwtuJvZ55 OvsLy6aTOayssTPTF2OLTzNLIuV71Y80C1GNnr2LAoImoEnqEd9YuWLHRCji4078AgEp AkSBCLIa5ESXNxhlzobqJIouAXqaOnL5us0s8SIqTAT67i9qcjcg9sQ7ZqoLglOGKBZU 11lrzXZx/MAHnlLXamUsZAwmDxZZ2APPYCzzGY3XWSB1QZDL0zp+4HRTKzzosW8U2V2I 8p6MnQ59j8foM2o/+fmdKq5j96PdWm7TDyfQSM6G5h3qd+tEylAVmIuCvelASk/t7lh/ SfUQ== 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=/Ap5RNMC0CVPZqjxiMU28eCpV//gWUJ0sESeZWXfWzA=; b=eyMV+Uc5W86uJBb5Qggd50Y24dOf4q6IBWGGasTaogv7gmQtFrIcUR3S/jhro5djhA A9go5N9lj2zB92DmvpZrW4ORS1pN/QzP1GLro/Rxtl/bDDQYOKhmH/nAhOS5OUT71n2o +AGhcckaPyh7DQBoTvfqeAH2rsY5opuGsrYPo9GdAvnT60CJ1FPjIyVIElEDa3Ux0jbd kGkUNYn/AbMAbRo6uDC6AWMhCBnIqI45wBPBYcXoYaErNhQgtEDXKOfamEN5+dUe+O08 d6h8mNkKSS13ddcKpGBHb+IsuA81EmkKy7kkkK6YSEYuySjj3zj5PoUNExkqRG41d6RG dOmA== X-Gm-Message-State: APjAAAW5TBK6Mp2ROJu6t27plUohf1JLlnuuGkqhz6f2K+rv6I3qMbBY MxAk3c2KVaZSGgJKXP80mpxkLAVkaH/2k01RKqE= X-Google-Smtp-Source: APXvYqxDEPs51T3Hs9sLZkk/4+bjNtoNIr7qVFnz9YdzXyxxX3vISaYRo0l6QYR4QGtMMiwOLlOgGE1qGauj4xcAc3o= X-Received: by 2002:aca:4c46:: with SMTP id z67mr1969961oia.158.1569928034740; Tue, 01 Oct 2019 04:07:14 -0700 (PDT) MIME-Version: 1.0 References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <4DE775B5-B15B-469F-A50C-3DB5B86AA5D4@ericsson.com> In-Reply-To: <4DE775B5-B15B-469F-A50C-3DB5B86AA5D4@ericsson.com> From: Kathleen Moriarty Date: Tue, 1 Oct 2019 07:06:38 -0400 Message-ID: To: John Mattsson Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d56e6e0593d75a1b" Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 11:07:18 -0000 --000000000000d56e6e0593d75a1b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2019 at 4:00 AM John Mattsson wrote: > Martin Thomson ; wrote: > > >When we release a new version of something, we are sending a message: > > > >1. new implementations and deployments MUST include support for newer > versions > >2. existing implementations and deployments SHOULD be updated to support > newer versions > > I agree very much with this summary and I would like to have it published > somewhere. Take for example RFC 8261. It was published almost 6 years aft= er > RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 a= nd > not DTLS 1.2. I think this is one of the lessons IETF should learn from t= he > TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in th= e > future? For an external viewer it must look pretty strange that IETF in N= ov > 2017 published an RFC relying on DTLS 1.0 and then 7 months later started > working on a draft forbidding its use.... > > I would like to see something like the following statements published: > > "New implementations and deployments MUST include support for TLS 1.3" > We have this already, I believe in new drafts. > "Existing implementations and deployments SHOULD be updated to support TL= S > 1.3" > "Existing implementations and deployments SHALL support TLS 1.3 by Januar= y > 1, 2024" > Are you proposing a draft to state this? If agreeable, this could be a quick draft and support for 1.3 is a reasonable request to align with requirements in industry. I'm not sure if our statement will drive the date as much as NIST's, but it couldn't hurt and I would be surprised if there were any objections to this. I don't think anything other than an RFC is the right approach, unless there is an avenue I am not thinking about as having IETF consensus would be what you'd want for it. > > >> """The expectation is that TLSv1.2 will continue to be used for many > >> years alongside TLSv1.3.""" > > > >Some people have that expectation, but I think that John is right to > challenge it. >There remain reasons that people are sticking with 1.2 fo= r > now, but those reasons >are mostly to do with allowing time to flush out > the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies. > > I agree with Martin, and irrespectively of whether it is true or not, I d= o > not see any need to have this sentence in an IETF draft. > As for this sentence, we'll see where the discussion settles out - removing or altering it. Best regards, Kathleen > > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: TLS on behalf of Martin Thomson < > mt@lowentropy.net> > Date: Friday, 27 September 2019 at 02:03 > To: "TLS@ietf.org" > Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation > > So I agree with Kathleen's conclusion: not to change the goals of the > current document. But there are changes that I think are necessary (and > thanks to Daniel and John for highlighting these). > > BTW, I've moved this to the TLS working group, because this is an > active topic there and I don't see anything in my email that SAAG needs t= o > concern itself with. > > On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote: > > My understanding of deprecating of TLS1.0 TLS 1.1 is that: > > a) new software do not use these versions > > b) existing software stop supporting these versions. > > That differs from my perspective. > > When we release a new version of something, we are sending a message: > > 1. new implementations and deployments MUST include support for newer > versions > 2. existing implementations and deployments SHOULD be updated to > support newer versions > > When we deprecate an old version of something, we are sending a > message: > > 3. only use this old version if you absolutely have to > 4. you are encouraged to take active measures to remove the need to > use the old version > 5. you have our support if you decide not to support this old version > > Now, "support" from the IETF is about as meaningful as you think it > is. And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ > [RFC6919]. > > In browser-land, we've decided to form a coalition when it comes to > removing TLS 1.0/1.1. 3GPP have obviously got their own support group, > which seems to be functioning effectively, which is great. > > > """The expectation is that TLSv1.2 will continue to be used for man= y > > years alongside TLSv1.3.""" > > Some people have that expectation, but I think that John is right to > challenge it. There remain reasons that people are sticking with 1.2 for > now, but those reasons are mostly to do with allowing time to flush out t= he > vestiges of a dependency on some of the TLS 1.2 idiosyncrasies. > > I would advocate for removing this statement and any residue of that > sentiment from the draft. It's speculation and, even if it were true, it > conveys the wrong message. The only message I would include is that one > that is further down the document: "Any newer version of TLS is more secu= re > than TLSv1.1." > > _______________________________________________ > 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 > --=20 Best regards, Kathleen --000000000000d56e6e0593d75a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 1, 2019 at 4:00 AM John M= attsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:
Martin Thomson <mt@lowentropy.net>; wrote:

>When we release a new version of something, we are sending a message: >
>1. new implementations and deployments MUST include support for newer v= ersions
>2. existing implementations and deployments SHOULD be updated to suppor= t newer versions

I agree very much with this summary and I would like to have it published s= omewhere. Take for example RFC 8261. It was published almost 6 years after = RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and= not DTLS 1.2. I think this is one of the lessons IETF should learn from th= e TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in th= e future? For an external viewer it must look pretty strange that IETF in N= ov 2017 published an RFC relying on DTLS 1.0 and then 7 months later starte= d working on a draft forbidding its use....

I would like to see something like the following statements published:

"New implementations and deployments MUST include support for TLS 1.3&= quot;
We have this already, I believe in new drafts.
=C2=A0
"Existing implementations and deployments SHOULD be updated to support= TLS 1.3"
"Existing implementations and deployments SHALL support TLS 1.3 by Jan= uary 1, 2024"

Are you proposing a = draft to state this?=C2=A0 If agreeable, this could be a quick draft and su= pport for 1.3 is a reasonable request to align with requirements in industr= y.=C2=A0 I'm not sure if our statement will drive the date as much as N= IST's, but it couldn't hurt and I would be surprised if there were = any objections to this.

I don't think anything= other than an RFC is the right approach, unless there is an avenue I am no= t thinking about as having IETF consensus would be what you'd want for = it.
=C2=A0

>> """The expectation is that TLSv1.2 will continue to= be used for many
>> years alongside TLSv1.3."""
>
>Some people have that expectation, but I think that John is right to ch= allenge it.=C2=A0 >There remain reasons that people are sticking with 1.= 2 for now, but those reasons >are mostly to do with allowing time to flu= sh out the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasi= es.

I agree with Martin, and irrespectively of whether it is true or not, I do = not see any need to have this sentence in an IETF draft.
<= div>
As for this sentence, we'll see where the discussion= settles out - removing or altering it.

Best regar= ds,
Kathleen=C2=A0

Cheers,
John

=EF=BB=BF-----Original Message-----
From: TLS <tls= -bounces@ietf.org> on behalf of Martin Thomson <mt@lowentropy.net>
Date: Friday, 27 September 2019 at 02:03
To: "TLS@ietf.org" <tls@ietf.org<= /a>>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

=C2=A0 =C2=A0 So I agree with Kathleen's conclusion: not to change the = goals of the current document.=C2=A0 But there are changes that I think are= necessary (and thanks to Daniel and John for highlighting these).

=C2=A0 =C2=A0 BTW, I've moved this to the TLS working group, because th= is is an active topic there and I don't see anything in my email that S= AAG needs to concern itself with.

=C2=A0 =C2=A0 On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote:
=C2=A0 =C2=A0 > My understanding of deprecating of TLS1.0 TLS 1.1 is tha= t:
=C2=A0 =C2=A0 > a) new software do not use these versions
=C2=A0 =C2=A0 > b) existing software stop supporting these versions.
=C2=A0 =C2=A0 That differs from my perspective.

=C2=A0 =C2=A0 When we release a new version of something, we are sending a = message:

=C2=A0 =C2=A0 1. new implementations and deployments MUST include support f= or newer versions
=C2=A0 =C2=A0 2. existing implementations and deployments SHOULD be updated= to support newer versions

=C2=A0 =C2=A0 When we deprecate an old version of something, we are sending= a message:

=C2=A0 =C2=A0 3. only use this old version if you absolutely have to
=C2=A0 =C2=A0 4. you are encouraged to take active measures to remove the n= eed to use the old version
=C2=A0 =C2=A0 5. you have our support if you decide not to support this old= version

=C2=A0 =C2=A0 Now, "support" from the IETF is about as meaningful= as you think it is.=C2=A0 And you can s/MUST/really ought to/ and s/SHOULD= /may wish to/ [RFC6919].

=C2=A0 =C2=A0 In browser-land, we've decided to form a coalition when i= t comes to removing TLS 1.0/1.1.=C2=A0 3GPP have obviously got their own su= pport group, which seems to be functioning effectively, which is great.

=C2=A0 =C2=A0 > """The expectation is that TLSv1.2 will c= ontinue to be used for many
=C2=A0 =C2=A0 > years alongside TLSv1.3."""

=C2=A0 =C2=A0 Some people have that expectation, but I think that John is r= ight to challenge it.=C2=A0 There remain reasons that people are sticking w= ith 1.2 for now, but those reasons are mostly to do with allowing time to f= lush out the vestiges of a dependency on some of the TLS 1.2 idiosyncrasies= .

=C2=A0 =C2=A0 I would advocate for removing this statement and any residue = of that sentiment from the draft.=C2=A0 It's speculation and, even if i= t were true, it conveys the wrong message.=C2=A0 The only message I would i= nclude is that one that is further down the document: "Any newer versi= on of TLS is more secure than TLSv1.1."

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 TLS@ietf.or= g
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tls=


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


--

Best regards,
Kathleen
--000000000000d56e6e0593d75a1b-- From nobody Tue Oct 1 04:39:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A9A120074 for ; Tue, 1 Oct 2019 04:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 udisp_fS7Ho2 for ; Tue, 1 Oct 2019 04:39:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85C4120072 for ; Tue, 1 Oct 2019 04:39:53 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 90928317529D; Tue, 1 Oct 2019 11:39:53 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 13D425D9D5; Tue, 1 Oct 2019 11:39:52 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 01 Oct 2019 13:39:46 +0200 Message-ID: <1730830.Bn5YTEkoct@pintsize.usersys.redhat.com> In-Reply-To: <7775c911-5355-ba17-b8b3-7c3e00c03043@wizmail.org> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com> <7775c911-5355-ba17-b8b3-7c3e00c03043@wizmail.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6334097.ZeJvepXUkB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.49]); Tue, 01 Oct 2019 11:39:53 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 11:39:57 -0000 --nextPart6334097.ZeJvepXUkB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 30 September 2019 15:56:19 CEST Jeremy Harris wrote: > On 30/09/2019 14:36, Christopher Wood wrote: > > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote: > >> Clients must therefore > >> bound the number of parallel connections they initiate by the > >> number of tickets in their possession, or risk ticket re-use. > >>=20 > >> ``` > >>=20 > >> I'm not a native speaker, but shouldn't it be "...therefore bind the > >> number..."? > >=20 > > Yes, we can fix it in the next version. >=20 > "Bound" reads correctly to me. You could spell it out in detail > if it is thought confusing: >=20 > "Clients must therefore not start a number of parallel connections > larger than the number of tickets in their possession" "bound" would work also like this: "The number of parallel connections the clients can initiate is bound by the number of tickets in their possession." =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart6334097.ZeJvepXUkB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2TOwIACgkQkqjRuAHS 9fURxw/+OkJcnexnCjycSnXk15K8Gso2elgavFVLYqOvob+HNFp4ZBBvxlnFfyDL WM2G7Ph2p+bziiemqWVarJ0kNfGH+aCcHnlr2cCkELuyZtP1Za/MBiF7VaedPqBp U0+Atu2+fXQW8uMOsedta6vYzt8kYkRpq9cD+N2Aeel+X0rPLwAYgMLeYb8QEj+G QPfBxgfrHNDprwTRj3RFc+AogO6FlwAoiR1Yxo4MuDOe/+kXyd6A+/V7gELHd/sF qXoLLPR+bfItsQQxTStN9TfwgIazr1kmtMw3k0BlUxLiy2Oz6Ar0tNz3kKUur0Nq BeHrsIPTCRCWvb0FtgUAd1nl/JfOM+p2IXM5wq1AUOhTHbtoF7zHjnvZwMwgZMtr /QneG9N6awNnjZ3IUaLhKMZZkedvQBCdUdBuBd/0Cq9NNhq7HbheagjioKRj537Q VWxdRzw63bkMTDH79CrpT5BsSIGMbxecs/qp8oq5j3YPQqg/GpP+ey5kRQst4Kzm 7KlqWx8FjC6Kl0KZ9OygTvemuzvlVSQB16Z0JJhDhrwMnNmotDmgnCSLs03y4Dm5 3xkx2UafppJ2YTxw4lcRuwk7TJp30Stf4Tm0Q4xjEP7unlS5N/VX9Ql7h0EtivJ3 p+zSqWegXpm6ZAKJWhbswvkANb6sP6/gpNQMGAJVFwr6Lw/I8Zk= =Dy9P -----END PGP SIGNATURE----- --nextPart6334097.ZeJvepXUkB-- From nobody Tue Oct 1 05:18:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44AA120154 for ; Tue, 1 Oct 2019 05:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 HX-SxbnKjQ0Y for ; Tue, 1 Oct 2019 05:18:13 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E08120142 for ; Tue, 1 Oct 2019 05:18:12 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 87DBE30842A8; Tue, 1 Oct 2019 12:18:12 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id B61DC5D713; Tue, 1 Oct 2019 12:18:11 +0000 (UTC) From: Hubert Kario To: Christopher Wood Cc: "TLS@ietf.org" Date: Tue, 01 Oct 2019 14:18:10 +0200 Message-ID: <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> In-Reply-To: <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1765606.IRqicVgrGs@pintsize.usersys.redhat.com> <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1795895.jXyq4bQGy8"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Tue, 01 Oct 2019 12:18:12 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 12:18:15 -0000 --nextPart1795895.jXyq4bQGy8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 30 September 2019 15:36:36 CEST Christopher Wood wrote: > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote: > > On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote: > > > This version addresses some of the comments we received from Hubert a > > > while > > > back. We think it's ready to go for WGLC, modulo whatever nits folks > > > find. > > >=20 > > > :-) > >=20 > > I still see the "vend" instead of "send" typos... Same for "vended" >=20 > It's not a typo! We chose to use vend. then you're not consistent: As per [RFC5077], and as described in [RFC8446], TLS servers send :) =20 > > ``` > >=20 > > Clients must therefore > > bound the number of parallel connections they initiate by the > > number of tickets in their possession, or risk ticket re-use. > >=20 > > ``` > >=20 > > I'm not a native speaker, but shouldn't it be "...therefore bind the > > number..."? >=20 > Yes, we can fix it in the next version. >=20 > > ``` > > Servers MUST NOT send more than 255 tickets to clients. > > ``` > >=20 > > per what? session? at a time? connection? >=20 > This is all per session. We can state it explicitly in the next version. so this count needs to be kept as part of session and impacts connections t= hat=20 perform resumption? =20 > > what's the expected behaviour with tickets and post-handshake > > authentication? Are tickets sent after PHA also bound by this limit? >=20 > As mentioned earlier, there is no effect, so we left it out. We're happy = to > accept text should you think it's needed. If the I-D states that servers should not send more tickets than the client= =20 asked for, and then send exactly that amount, then they won't be able to se= nd=20 new tickets after PHA and remain compliant. Yes, it's completely up to the server to decide if to send tickets after PH= A=20 or not, and I'm not suggesting that the client should request for tickets i= n=20 one of its PHA messages, much less expect or require them, but sending tick= ets=20 after PHA is reasonable and explicitly stated behaviour: RFC 8446 Section 4.6.1: For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the additional client authentication state. so the I-D should explicitly state what's the expected behaviour in that ca= se. IMHO, the extension should be used for the tickets sent right after the=20 handshake, it should not put an upper bound for the tickets that a server c= an=20 send in a single connection. For a very long lived connection (especially i= f=20 the connection uses KeyUpdate messages regularly), the initial tickets may= =20 expire. Server may notice that and send a new group of tickets then. > > ``` > >=20 > > Clients MUST NOT change the value of TicketRequestContents.count in > > second ClientHello messages sent in response to a HelloRetryRequest. > >=20 > > ``` > >=20 > > 'A server MUST abort the connection with an "illegal_parameter" if the > > value of the extension changed, it was added or removed in second > > ClientHello.' ? > I don't think this is necessary. given past discussions on this mailing list, I don't think this is entirely= =20 obvious.... Then what about the addition or removal of extension being forbidden? Can w= e=20 add something like this?: ``` The presence or absence of the extension MUST be maintained in second= =20 ClientHello message when compared to first ClientHello in connection. ``` =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1795895.jXyq4bQGy8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2TRAIACgkQkqjRuAHS 9fWyKw/9GtQQxHUXd8LDoRUEYk8QpYCjNxwzd9mQieEQP/sWwgHyqBrLIzgcy6X2 1g5nIqNlpfR4K/JpcjukWkcuDS2i3ClzkrMWviXE3HeO8kl+gJ4arHJvfbjprcwU 67iHx/LoS86VVcwz7F8vLz4I7KXXO21nXPima0uHiec9kZdLWqtWhpQBRYmvB8PG 3yrw9qiotBdgCsipPefIgAqJENwKVMlnQSI5NaTuPACXiF/Y3FRZayBGTykNbIAZ 4++q7gzpU4TtIulFzQJEh2jT+iBi0zQWkglsimtKySuLY6pz/t4PcRNLKW5gHeIL 9Bg3U5fJ3x9ZrbDkuMjt05p/Lr5y7ruQRgOVOP7R6KyG4vHMD9dacrRvXNItVyAF b6I1dE/KXtkzso2ClO1e2wkoc2G/ccAfnlBtid+tWDlxkrVmnS1Puwc3YBARwv8m uHMFX31WWSnpLB0SWhJe0K1WR41RKe01KqDj+TT0kU8KJG85HVPq9OgsHSHjmgSU 8+wBEKn0cbKYr0ql1njoPg49JjJlJdTjsuaV8X/B1jcSt5MrDJvZcr4268ccyD5B S0WdpoJxwr0vlGNpb1OCwH31hP17mdMBo2PzQDJWVIE4g5fB73VGVLexBSNLpZBD ahDP4E7k6xpxb+2X3+5jzIlhlp7br0VWGjz8OUwBmEkxhv396gk= =vD63 -----END PGP SIGNATURE----- --nextPart1795895.jXyq4bQGy8-- From nobody Tue Oct 1 05:26:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C96012016E for ; Tue, 1 Oct 2019 05:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 x3tHWvZM-Stz for ; Tue, 1 Oct 2019 05:26:51 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00081.outbound.protection.outlook.com [40.107.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB84120142 for ; Tue, 1 Oct 2019 05:26:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gV3NynhSxOEWKnu37wzdrNPQirNySBtjS3e2Pd7sjvsfWyEvwo9FEwEcCTX2SI1whWDBjtGFgt6kllOByymBC2tolTgRCXYfegn1JMyQD/1AVHO1P6AfJl8e1xKJ4u4oYOyURCcIfJscbcZxUG0zqeB/lU6Ic/XTLI03mXULCJrGxwK1SqtW/WpU87/kHnegtHQXSsn8C1g1YkEPaP88S7tqdlf/i1AQQRksL7mSlaYLHwIGW+gPreLyNSpnOGPESqQ5M5VZ/taoc/dsWwvo2hwL5p82zEv88HiqbtfJHhLnh5m1F6jWaXG0+1uODi8OECUmBl+56LZbzy66Fipm1g== 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=xWcJuO+pVO72xINlqzZEkcX7kZvu60zMjA5Nch2SL4M=; b=oP7StU+QcLhzzpUUU0Y608tPNl4COjtD5De9MBZ6vERc6gnli+yqd/oQEyN7WhD7ir2LvVLUJwnX8dFJ60VL1mOabwynBktyZhupD2pUSEIppk75Z4eGt59vlGOgRKpJSFql2AKFA4jODWSlSNIc/usPZqf+8Od1yoYKUjeCdcQB2NZcq25JzVoNiexBPFSA7LNjZ8WnviwD4nIhLpAbDd4BnA/srjAPsgMw5MJ69K/zMIhz/uCpYz/aLP6gnlrmuXOeLkOWEmP7nE80sug6OTTnfnauBB6xDzqT2FQJ583DVllfG66Hf7WiRzZwVObK+Y35kavcP08NORRoyMs57g== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xWcJuO+pVO72xINlqzZEkcX7kZvu60zMjA5Nch2SL4M=; b=mN+BsgAtbi9ZSXL7r7qWt+b1VbRKuwwV1NwgPcSY5eaCp0jDscoUmB+4HkGTYjrhI2atZejIEF6QYs4fWpZysTeFsY3fzcis2iGimy3iSaOh0Hpg1qCQ0oC+EMbmpyN2T7VGJSw+JsrVgX7wh35KPnuHBUloe/qWtUrFLb9S1zw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3340.eurprd07.prod.outlook.com (10.170.245.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Tue, 1 Oct 2019 12:26:43 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Tue, 1 Oct 2019 12:26:43 +0000 From: John Mattsson To: Dan Brown , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZv?= =?utf-8?Q?r_erratum=3F?= Thread-Index: AdV4RZj0iyjnpsmL4ES+HvQhRBeDQgAHqWoA Date: Tue, 1 Oct 2019 12:26:42 +0000 Message-ID: <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> References: <20191001104718.8626261.12105.36904@blackberry.com> In-Reply-To: <20191001104718.8626261.12105.36904@blackberry.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c1b44f97-1007-4c6f-cd2b-08d7466a9e2c x-ms-traffictypediagnostic: HE1PR07MB3340: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(136003)(39860400002)(366004)(376002)(189003)(199004)(13464003)(8936002)(14444005)(2906002)(256004)(6116002)(305945005)(3846002)(316002)(5660300002)(66616009)(966005)(66446008)(71200400001)(64756008)(66556008)(66476007)(66946007)(99936001)(71190400001)(81166006)(14454004)(58126008)(110136005)(7736002)(76116006)(25786009)(81156014)(476003)(2616005)(6306002)(486006)(2501003)(11346002)(446003)(102836004)(229853002)(66066001)(186003)(6246003)(6436002)(44832011)(478600001)(86362001)(76176011)(6506007)(53546011)(26005)(36756003)(6512007)(33656002)(6486002)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3340; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dBJlh23P7bbx4mErKy6fqKzgS1H3GVfPXv/xt9ADZZMsp4Ib2PO4g64+1vtZoWa+6aDKQyZdAWTSS2lZY70vbPXmnrIkDmwFlIYJM0M6rkokIYsUSj5PYQiOG7B34NQ2WZe2mPHNXJWiZBhBk4GIEOH4fdjAWvXmO1uKUubC8kAB/oDIpGfXLiQL/SYI+76fpmw6BzNdLSYltzm9e8Wf4/CsASbdKNuzlRBG6nbuCA+oV/iEIZbP/vE7wiOyKFTOXysWcocMe4KKTFZNw1A2BtStG/P32ZnSxmHPEjHctV93/9VrRzIxhy1+JySWhX+y1xVGghmOzWOj7gwQoxfAhxqxbbqrCj/Mgy2C+q7ietwmTPNmOyTRpQKlbr18oP1swTckKxbYdGGUtKZji483NdyHMa7pLV3IFj0o7FN/vPY= x-ms-exchange-transport-forked: True Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3652784802_1812430122" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: c1b44f97-1007-4c6f-cd2b-08d7466a9e2c X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2019 12:26:42.8759 (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: tRnVCq9PzWA0GlnVcxNXuj0lG8vEUlwEUkagxVF1Ud0m7/nupb2qYmPOPrZFvv3JaPzcAmQzlMEEFW3KFCbSYvg0fVS0Dlr4j9U8RR/sTRw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3340 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 12:26:54 -0000 --B_3652784802_1812430122 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dan Brown wrote: > ANSI X9.62-2005 was withdrawn in 2015 Ok, that TLS 1.3 is relying on a withdrawn publication that used to be behi= nd a paywall is even worse.=20 > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA= =20 That NIST FIPS 186-5 will include all the details needed to implement ECDSA= is great.=20 >IETF has specs for sigs and their formats already, no? At the time when RFC 8446 was published, there was probably no quick and ea= sy solution to the problem. But the fact that IETF has historically been fin= e with relying on specifications behind paywalls is part of the problem. If = IETF had implemented a strong open-access policy a long-time ago, there woul= d probably be an open-access version of ECDSA (NIST or IETF) a long time ago= . Cheers, John =EF=BB=BF-----Original Message----- From: Dan Brown Date: Tuesday, 1 October 2019 at 12:47 To: John Mattsson , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erratum? Re ECDSA specs and paywells: ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 = years, despite my weak effort. A revival, ANSI X9.142, with almost the same content is under way, thou= gh even its fate is unsure. Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECD= SA and EdDSA (not ASN.1?), which many may like (even better than ANSI). Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or no= t, despite my weak effort. IETF has specs for sigs and their formats already, no? Then there's ISO, IEEE, ... =20 =20 Original Message =20 From: John Mattsson Sent: Tuesday, October 1, 2019 5:25 AM To: Peter Gutmann; Hubert Kario; TLS@ietf.org Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erratum? =20 Hubert Kario wrote: =20 > Now, I don't have access to X9.62-2005, but there's a possibility of = confusion. =20 I think references to specifications behind paywalls and other types of= limited access is a major problem. Not only for the standardization process= , but also for researchers and implementors. In general, I think people shou= ld be able to implement and analyze IETF standards without having to pay for= access. =20 Open-access is even more important for security specifications. ANSI X.= 62 is hopefully quite well-studied, but for other references, the lack of an= alysis often leads to mistakes and unknown weaknesses. =20 I would like the IETF to take a much stronger stance against normative = references to paywalls.=20 =20 Cheers, John =20 _______________________________________________ TLS mailing list TLS@ietf.org https://protect2.fireeye.com/url?k=3D749c6dba-280e60e6-749c2d21-0cc47ad93= d46-3da924ab2cfe57e8&q=3D1&u=3Dhttps%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Fur= l%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_tls%26d%3DDwICAg%26c%3DyzoHO= c_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE%26r%3DqkpbVDRj7zlSRVql-UonsW647lYqnsr= bXizKI6MgkEw%26m%3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I%26s%3Dp2p9Y_h= h-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU%26e%3D =20 =20 --B_3652784802_1812430122 Content-type: application/pkcs7-signature; name="smime.p7s" Content-transfer-encoding: base64 Content-disposition: attachment; filename="smime.p7s" MIIIKgYJKoZIhvcNAQcCoIIIGzCCCBcCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggX+MIIF+jCCA+KgAwIBAgIPAWGe20hWO3XK63MODhTlMA0GCSqGSIb3DQEBCwUAMEcx CzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MzAeFw0xODAyMTYxMzQzNDZaFw0yMTAyMTYxMzQzNDZaMGgxETAP BgNVBAoMCEVyaWNzc29uMRYwFAYDVQQDDA1Kb2huIE1hdHRzc29uMRAwDgYDVQQFEwdlbWFu am9uMSkwJwYJKoZIhvcNAQkBFhpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANFmbvcACZgwA8g1CNfc9E87aEt8J4qVDqkkqRRJ RZPOF41ayLZY5Lsy7DzzbwpdNf0/PDWe9zqBcJq2Rlrq4zP/yQMd+GNxoYDuCeJnuAwx02aC aoNbcleGCMuTj5RnKkzdKUbH9RYohzLYl+IoBKVPBODnTcH4NEytLc4UfvnqEHEPEkQ8dSHP ZoT9qwQoIPeYvSgAuTVe/HeSRjQfGEgrlbRCJuLvKd7TFMOeZP8w4YevOPJ9/GRKqsqh0UfG +I+Y3ujFKHC0Ep5QOmyYK69j4w8UrQfuyOYg0Gk2LZLlZafHqztMvdZwPfpTdz1HshQHG9A7 eZrjH0oT7vKRx/MCAwEAAaOCAcAwggG8MB8GA1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPb LaZTMB0GA1UdDgQWBBTnD7GpQlhL7QT4S4+rtisHTub1NzAOBgNVHQ8BAf8EBAMCBaAwVQYD VR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0 b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJQYDVR0RBB4wHIEaam9obi5tYXR0c3Nv bkBlcmljc3Nvbi5jb20wSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxp YS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNybDAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwgYIGCCsGAQUFBwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3Ay LnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29u ZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjMuY2VyMA0GCSqGSIb3DQEBCwUAA4IC AQBeEGaLp4Owu4YQAYJBxYRVJ97znjhiLNR3YuE+OrqgjSjOgLmV/hGa2KSts6ALOVat+3jh H1xa6yJ8fYTWZJUw7+WAgp4twVCiVL51obRdPCZFF/P2WyJCbEdj/t6DqFCLHVeNqSOFwdX2 G3uDVEkwPIpcTwaJzW8ff8lBRykAi1vY1cQWwadeaBYihvKGk7RVswO8SBMLHUwKXEy+DSGy Iw3IsG2JFQ/yBF6Y2kn/C8pCLk2nibGxGlYvtj+HKdgK87FC4vKN1aI6yIaM/TWeZy2xnEwZ yUZp4TwV82uN886miOOVl3PRze0SdKiNaNatWfbI8DqauX1p2R+WeDXd5LQ/aC6PL5mSwNq7 uhY/fqK2J5IApzM6dE8CefWrLkpOhiempA+hdultixq2JE8B5hBRq3X5oPLsIW4NsmUj7Z5q VeDPMdhLYxI2drBKokGPEOO7Nz07HIp5yvgqtFOl2ySJQdONESh9JAtO4umk/wb8tWgZvIcB jBJpY7xf2dW43x2y6rsh8O39sFNwyQG5cQ5RdLy7keiTN51iefMQIugWSpM29QbbcTZ5w+97 VJP8Z8LugrAMsIGYI4ZtnWmMce8A1HcZLYOewB3qdKkVPNhdDXCpWVbcNWsLQgMNmibPH634 /SkhVt/N8MV7N8fNFkBpClHLR6+BHli2CiLByTGCAfAwggHsAgEBMFowRzELMAkGA1UEBhMC U0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFs IENBIHYzAg8BYZ7bSFY7dcrrcw4OFOUwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQx IgQgVMaCBLQ/Ry/8q3YNwFiy9IgiLiQAj4xo77b87GaDzBcwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkxMDAxMTIyNjQyWjANBgkqhkiG9w0BAQEFAASC AQCOoKHmaGkM4xjd0pNtXYd0iWcS8oN5UWx9TebDECiUAckQr2Ujfy3NnhYu/CLEZb39oJcj PEWRk1hzFeiCkGEy6GHBlfhQxtXmPaRlMF7nZJbY8fkDddbwH33JhheHrBTk40BsXj5aIBKa j6yQWWfRISLuFh23mBroUExH4Z5sBqJs9qz6yQ8XI8Lff8hF62VwV24yqY5r4vv1kVJhR0J0 wChOIxx6YBLA3vf7OCZmVzu4/lTRgq1VqH21xexZlWdDoGwdKdHKN3bZcjgRm5S11bUfzAYL RO7bFrEoLvtuwtWkMcJxIb37bLa3TyERHc0vsJ4HKoR8myAdvatHYIcT --B_3652784802_1812430122-- From nobody Tue Oct 1 05:33:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A2E1201A3; Tue, 1 Oct 2019 05:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 ywwwjLMbmo_M; Tue, 1 Oct 2019 05:33:54 -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 B1A1A120142; Tue, 1 Oct 2019 05:33:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2C868BE2F; Tue, 1 Oct 2019 13:33:51 +0100 (IST) 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 dzeVUdZnBEW4; Tue, 1 Oct 2019 13:33:51 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AC8A5BE24; Tue, 1 Oct 2019 13:33:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1569933230; bh=DgUWimX5HI3IaAZo05l/9IBtJrv2xNmohob86vwJFqA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kEDY+68xwLn6f6RVK+YCgZEnKMQUyckuo7wM1TlEy/Nw29Z2LqDu/OmhbM42Vn1tm cIAsvgnqVJkIUMFZrvyuwSwxiWh9FcloWO3VOfF1RVA8sAYVdizXFo08GcB3g8ZC5V 1UQPVhdDBO2IHt6yubBNyigNYI9mgnNaPaDQq924= To: Kathleen Moriarty , John Mattsson Cc: Sean Turner via Datatracker , "iesg-secretary@ietf.org" , "kaduk@mit.edu" , "tls@ietf.org" , "tls-chairs@ietf.org" References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <42cb3e85-0694-dbd5-9283-9a87d60668bb@cs.tcd.ie> Date: Tue, 1 Oct 2019 13:33:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5xAWqj3QzAbJuzh7H8Wt0j8Awncw14X5I" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 01 Oct 2019 12:33:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5xAWqj3QzAbJuzh7H8Wt0j8Awncw14X5I Content-Type: multipart/mixed; boundary="DIOOhSUgFfLE84dqysJWVphzdrRUivWpb"; protected-headers="v1" From: Stephen Farrell To: Kathleen Moriarty , John Mattsson Cc: Sean Turner via Datatracker , "iesg-secretary@ietf.org" , "kaduk@mit.edu" , "tls@ietf.org" , "tls-chairs@ietf.org" Message-ID: <42cb3e85-0694-dbd5-9283-9a87d60668bb@cs.tcd.ie> Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> In-Reply-To: --DIOOhSUgFfLE84dqysJWVphzdrRUivWpb Content-Type: multipart/mixed; boundary="------------837352C2AD1E41D091E9491F" Content-Language: en-GB This is a multi-part message in MIME format. --------------837352C2AD1E41D091E9491F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 01/10/2019 11:50, Kathleen Moriarty wrote: > On Tue, Oct 1, 2019 at 4:04 AM John Mattsson 40ericsson.com@dmarc.ietf.org> wrote: >=20 >> Hi, >> >> I think draft-ietf-tls-oldversions-deprecate needs to update >> draft-ietf-rtcweb-security-arch as well. >> >> draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about supp= ort >> of DTLS 1.0. >> >> "Earlier drafts of this specification required DTLS >> 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and >> at the time of this writing some implementations do not support DTLS= >> 1.2; endpoints which support only DTLS 1.2 might encounter >> interoperability issues." >> > Good catch. I'm not sure what that'd mean for our draft (meaning draft-ietf-tls-oldversions-deprecate) as we can't "UPDATE" an I-D. draft-ietf-rtcweb-security-arch-20 is in the RFC editor queue, but is part of a giant cluster IIRC so I suspect nobody will want to touch anything there:-) I think something like this (or maybe exactly this) did come up before and the answer was that it was best to leave it as-is for now. (But I'm open to correction on that and/or maybe things have changed.) Cheers, S. --------------837352C2AD1E41D091E9491F 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----- --------------837352C2AD1E41D091E9491F-- --DIOOhSUgFfLE84dqysJWVphzdrRUivWpb-- --5xAWqj3QzAbJuzh7H8Wt0j8Awncw14X5I Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2TR60ACgkQWrL68XsX K+q96xAAi6U+Oa60AGPbOfKQpbQuLd6e31Uwvg6ApaRtAHw+16Rz1FK7hdOcFUNk cO7+SeUPwvzsT+SkhYg0jHyeHnpn7FURAHg6EOIHpDx6bdUonEpbmybF0PNxt8ZS hVGovefx9o8S7N6OQHeWHS8c8FTSxFDHwqzjXTjIv1yT3r48xDg+BvSsfebovNsa /PCTkoaR3Tjj3GmjfkhMdHbOzrcuWHmgiT/Ujsb4NCQWI5u+fmafc9T9wPnSfhxF /hZijmMyMws/YrNUV1WKPrVTbQCdHwFDqRDoolagMaRg7ozP5FNCq+e57ozCM56s iNX+Z0G3zfJGpUpWpHeMV+qfmM0I4OfmvFgrd0kG9VEVbsgEU3D1lJdBhlYoec0S N+qVIvGvpwEE+JXVilZEB92X9qV/2c8mXvSxq8oAo8jAIMQEfjNsUXdUE+QDFRay B7LVul+ylqfCztLlqkhqFQy3rrMlDzfPtyE7brvqLqDIAS3ChJe+wF3bbAybziAa vxWpjiw9eH7OErvgBFeqD0jIPPdUs30Mr0umNe4v+31vfjc37mMwd41Qbb6YpQLI 6oBA0avNxZxxa6geNvBF7Mcuc1WrmHlYuImz3KWF8I0OM2/A29nf7Jh5s39Hlumc //hr5qd89xYubJRzi5a82Kt6wZnS08Z/6Bg+R3drvRjzNRwXNwY= =LEkP -----END PGP SIGNATURE----- --5xAWqj3QzAbJuzh7H8Wt0j8Awncw14X5I-- From nobody Tue Oct 1 05:49:50 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D426A1201A3 for ; Tue, 1 Oct 2019 05:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 JvFsAAwO0OiU for ; Tue, 1 Oct 2019 05:49:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AACB9120142 for ; Tue, 1 Oct 2019 05:49:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 57669C059B7C; Tue, 1 Oct 2019 12:49:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id CD4FA60464; Tue, 1 Oct 2019 12:49:43 +0000 (UTC) From: Hubert Kario To: Dan Brown Cc: "TLS@ietf.org" Date: Tue, 01 Oct 2019 14:49:37 +0200 Message-ID: <2211799.0F6m8LsVZW@pintsize.usersys.redhat.com> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501E44E12@XMB116CNC.rim.net> References: <1803994.nvTnDQYtSi@pintsize.usersys.redhat.com> <810C31990B57ED40B2062BA10D43FBF501E44E12@XMB116CNC.rim.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20131096.QqXdQT4Jjt"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 01 Oct 2019 12:49:44 +0000 (UTC) Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 12:49:48 -0000 --nextPart20131096.QqXdQT4Jjt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 30 September 2019 16:40:57 CEST Dan Brown wrote: > A brief reminder below about 2 new extra elements of ECDSA-Sig-Value. >=20 > > -----Original Message----- > > From: TLS On Behalf Of Hubert Kario > > Sent: Monday, September 30, 2019 8:56 AM >=20 > ... >=20 > > At the same time SEC 1 v2.0[1] defines that structure as follows: > > ECDSA-Sig-Value ::=3D SEQUENCE { > > =20 > > r INTEGER, > > s INTEGER, > > a INTEGER OPTIONAL, > > y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL > > =20 > > } [snip]=20 > At the ASN.1 and DER formatting level, the intent was that > (1) old syntax signatures (r,s only) would be compatible with the new > syntax since optional fields are DER-encoded as empty strings, to empty > string should DER-decode (is this right?), and yes, in DER, OPTIONAL field that has no value results in a string of 0 octe= t=20 length so the above quoted structure with "a" and "y" omitted will be bit for bit= =20 identical with the ECDSA-sig-value structure defined in X9.62-2005 (Thanks= =20 Peter for providing the relevant section). So for "traditional" format of=20 signatures, they will be compatible, it's when an implementation starts to = be=20 "helpful" by providing those additional values that SEC1 implementation wil= l=20 start to fail to interoperate with X9.62 implementation. > (2) a lax, liberal implementation of the old syntax would understand the > new syntax, simply by ignoring the new values a and y, (and ignoring the > total length of the DER encoding). >=20 > Of course, the strictly proper way to do (2) was to have put an ASN.1 "..= =2E" > placeholder in the old syntax, thereby accommodating for future extension= s. > Alas, this was not put in. So a strict, literal implementation of the old > syntax should reject the new syntax. a lax DER parser sounds like an oxymoron to me... :) And I've checked, the TLS since the beginning was specifying signature as=20 encoded with DER, not BER =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart20131096.QqXdQT4Jjt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2TS2EACgkQkqjRuAHS 9fUAGxAAl8FpTBLThPGJ9+KiQ67gCmzz3NLr5OXkHCta48lS3WBVCT7lluHrRbG9 +fjuUZnDkFT5518H2p5aX4X+S72YD7A9zn/okwTaKMoaA6nZC011qYpSlucrHOmK BZpSIGYzO9CEZJWt+ANuh5QkzVy7hFWyZCK1iCbXY5IuunQih4s9ygemZm1ar8dR 3eonN96AHZh6qdsFVzgrMaoMeVYQ65rD1yX0KohxvJYrQD2kWXBNs7tk8o7kdQrv o3PN7WTgsdfLVIu22Vk/lVkNZwiMWIdi20rJOw/i6u9poR5367Ojum/YP9fdw6q7 5xi2B6fimUDBG+ePWqtOP6FkmayFZayCyaedApKeN8e+I0mix+8rD2xHlvtwvqAW KvY0h1Whs5RNItq3CBx761QR7YgJzXiQqXadTWkf7duRc5iafgLOcgU7Rfest08s 1VwiqVR1FSFtAvQYOK00nkYSfUNfxqy3BQpM4gtixWrFDIkDhhScOevVhrfHGuVh t9084RLibDUgsBgJ0V+UhXegrhS6k0BjVwUm797hD5NhqH4OKVLi/gQyDBWQfRtS 4M5wCQ5J7rZTzNnaPHy5KBuEwTVfbbw1RzDfESnRDskVUoLjLt5V3iA6ppUsgaXF C54FY5NPdkKzL5f4TOQXbxzZpM/w94f0e0R44OVuf6QaWfZAAq0= =ux+S -----END PGP SIGNATURE----- --nextPart20131096.QqXdQT4Jjt-- From nobody Tue Oct 1 06:29:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9B3120024 for ; Tue, 1 Oct 2019 06:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ivj1n180meKr for ; Tue, 1 Oct 2019 06:29:35 -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 003431200CE for ; Tue, 1 Oct 2019 06:29:34 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id n197so47837617iod.9 for ; Tue, 01 Oct 2019 06:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=pP/hywZKnXPNjuqxgNwMVvMoovxye9BrLr5Ws65TPFQ=; b=iI4qyYziDJB2as9M6WUwYdQIk5sS/Vni52iY7Xf+desuHHRBCnfYcbHpw6vdJbyN3v eBhBLhVEGr+h71aO3G4R40Y9IbmrzhNX98m8ByRanB3qCZSy/1LxbsFLr0yTuoVDGMbA a5HTXU6rWpkci2t6qgIMi4L8gOezEWsWtZZ/OQF6zxHj1aL5WY853Fepr5yZRSI19NnL 5rmEczDE2lv0Tv06W8xc9Z2mXLj5WuB3HQRa4f+mXoo8PooCsJ6DhptPFhHV0U0aFs0n feXUJup4NOtcBmA5Ng7aLW5Sx2+FwYzoK8iagVso3Y69+PXM7/lucQVyhwLuYVVs7FQw Mphw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=pP/hywZKnXPNjuqxgNwMVvMoovxye9BrLr5Ws65TPFQ=; b=QqTVQJCai35BWRnI7Yv8WDERkGNLKjHB/oF4HTJbkrVMPLM/4rOpam4VLpyVGWgLL7 Hdz4dF64vf4aUlpOqZpbB4AL3ELK+qxykKDXPgyB/pOtm81OhTNILI+yfC4Lgmta181h x4Inpr4X8qoC2A0Wg7vrF4uWwyI3WLAGWcKCihZcHaGuJJ6yfdD+yoW1uZPkC+bETseh s1MGjlW1vnIGm9CBdGjrRBs7Gpo3ND3BomCddmzjWxzFfDGcbyPDfP/dUyhEoEIBj990 3gvnODNJdYrmUKrt8Xy5NgYvzEsuY3gGmEJiFdS9rvjdyAKtEp7suGD4UwcaaWz+uGj6 YXiA== X-Gm-Message-State: APjAAAX+Rp87fe+s17baqY3fYNd+HfO3ZzvyAMbJBV6WPOWF9Km3Mq24 wTbCMq2tELltBN/WY250rtc1tD9z X-Google-Smtp-Source: APXvYqwGC7881O8V5BuoqfjcufOVQ+IDhF9/S1hUAyeM8XxGJdC3JsKXa5frFgK/7GjxZu0RaOo9Zw== X-Received: by 2002:a92:8990:: with SMTP id w16mr23991862ilk.15.1569936573962; Tue, 01 Oct 2019 06:29:33 -0700 (PDT) Received: from ?IPv6:2607:fea8:69f:f5eb:39c0:18c9:32e8:e9f7? ([2607:fea8:69f:f5eb:39c0:18c9:32e8:e9f7]) by smtp.gmail.com with ESMTPSA id d18sm8112958ild.63.2019.10.01.06.29.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Oct 2019 06:29:33 -0700 (PDT) To: Dan Brown , John Mattsson , Peter Gutmann , Hubert Kario , "TLS@ietf.org" References: <20191001104718.8626261.12105.36904@blackberry.com> From: Rene Struik Message-ID: <3f715f6a-f660-f2e4-544f-583063aa6238@gmail.com> Date: Tue, 1 Oct 2019 09:29:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191001104718.8626261.12105.36904@blackberry.com> Content-Type: multipart/alternative; boundary="------------76B2084801F8DB8217DD4AD9" Content-Language: en-US Archived-At: Subject: [TLS] =?utf-8?q?=28question_on_ANSI_X9=2E62-2005=29_Re=3A__Ecdsa?= =?utf-8?q?-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 13:29:38 -0000 This is a multi-part message in MIME format. --------------76B2084801F8DB8217DD4AD9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Dan: Just curious about the fate of ANSI X9.62-2005: On the website below, this specification is still listed as "active" (whereas ANSI X9.62-1998 is labelled historic). I purchased that spec for a project on Nov 22, 2016 from the ANSI webstore (when, surely, it was not labelled as expired) [see purchase info below]. What happened? Was someone sleeping at the wheel? Why would there be a completely differently named "revival", ANSI X9.142, with almost the same content, under way, and why would its fate, 4 years after 2015, be unsure? Is there a technical reason ANSI did not wish to pursue this, or admin mishaps? Rene Note: purchase info RS from ansi store below: Subject: Your Order Confirmation for X_458150 From: ess@ansi.org Date: 11/22/2016, 2:57 PM To: [snip] 25 West 43 Street New York, NY 10036 Tel: 212.642.4900 Fax: 212.398.0023 Sold To Rene Struik [snip] CANADA Order ID X_458150 Card Received Mastercard Charged to Account ****[snip] Date 11/22/2016 Quantity Product Unit Price Total Price 1 ANSI X9.62:2005 $100.00 $100.00 Download Total $100.00 THANK YOU FOR USING THE ANSI STANDARDS STORE. The American National Standards Institute (ANSI) is a private non-profit organization that administers and coordinates the U.S. voluntary standardization and conformity assessment system. The standards you purchased were added to your Alerts Profile, which will allow you to receive an automatic notification via email when the documents are revised or amended. You may manage your alerts at any time. https://standards.globalspec.com/std/1955141/ANSI%20X9.62 On 10/1/2019 6:47 AM, Dan Brown wrote: > Re ECDSA specs and paywells: > ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 years, despite my weak effort. > A revival, ANSI X9.142, with almost the same content is under way, though even its fate is unsure. > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA and EdDSA (not ASN.1?), which many may like (even better than ANSI). > Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or not, despite my weak effort. > IETF has specs for sigs and their formats already, no? > Then there's ISO, IEEE, ... > > >   Original Message > From: John Mattsson > Sent: Tuesday, October 1, 2019 5:25 AM > To: Peter Gutmann; Hubert Kario; TLS@ietf.org > Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum? > > Hubert Kario wrote: > >> Now, I don't have access to X9.62-2005, but there's a possibility of confusion. > I think references to specifications behind paywalls and other types of limited access is a major problem. Not only for the standardization process, but also for researchers and implementors. In general, I think people should be able to implement and analyze IETF standards without having to pay for access. > > Open-access is even more important for security specifications. ANSI X.62 is hopefully quite well-studied, but for other references, the lack of analysis often leads to mistakes and unknown weaknesses. > > I would like the IETF to take a much stronger stance against normative references to paywalls. > > Cheers, > John > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I&s=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e= > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------76B2084801F8DB8217DD4AD9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
Hi Dan:

Just curious about the fate of ANSI X9.62-2005: On the website below, this specification is still listed as "active" (whereas ANSI X9.62-1998 is labelled historic).
I purchased that spec for a project on Nov 22, 2016 from the ANSI webstore (when, surely, it was not labelled as expired) [see purchase info below].

What happened? Was someone sleeping at the wheel? Why would there be a completely differently named "revival", ANSI X9.142, with almost the same content, under way, and why would its fate, 4 years after 2015, be unsure? Is there a technical reason ANSI did not wish to pursue this, or admin mishaps?

Rene

Note: purchase info RS from ansi store below: 
Subject: Your Order Confirmation for X_458150
From: ess@ansi.org
Date: 11/22/2016, 2:57 PM
To: [snip]
25 West 43 Street
New York, NY 10036
Tel: 212.642.4900
Fax: 212.398.0023
Sold To
Rene Struik
[snip]
CANADA
Order ID X_458150
Card Received Mastercard
Charged to Account ****[snip]
Date 11/22/2016
Quantity Product Unit Price Total Price
1 ANSI X9.62:2005 $100.00 $100.00 Download
Total $100.00
THANK YOU FOR USING THE ANSI STANDARDS STORE.
The American National Standards Institute (ANSI) is a private non-profit organization that administers and
coordinates the U.S. voluntary standardization and conformity assessment system.
The standards you purchased were added to your Alerts Profile, which will allow you to receive an automatic
notification via email when the documents are revised or amended. You may manage your alerts at any time.

https://standards.globalspec.com/std/1955141/ANSI%20X9.62
On 10/1/2019 6:47 AM, Dan Brown wrote:
Re ECDSA specs and paywells:
ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 years, despite my weak effort.
A revival, ANSI X9.142, with almost the same content is under way, though even its fate is unsure.
Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA and EdDSA (not ASN.1?), which many may like (even better than ANSI).
Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or not, despite my weak effort.
IETF has specs for sigs and their formats already, no?
Then there's ISO, IEEE, ...


  Original Message  
From: John Mattsson
Sent: Tuesday, October 1, 2019 5:25 AM
To: Peter Gutmann; Hubert Kario; TLS@ietf.org
Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

Hubert Kario <hkario@redhat.com> wrote:


Now, I don't have access to X9.62-2005, but there's a possibility of confusion.

I think references to specifications behind paywalls and other types of limited access is a major problem. Not only for the standardization process, but also for researchers and implementors. In general, I think people should be able to implement and analyze IETF standards without having to pay for access.

Open-access is even more important for security specifications. ANSI X.62 is hopefully quite well-studied, but for other references, the lack of analysis often leads to mistakes and unknown weaknesses.

I would like the IETF to take a much stronger stance against normative references to paywalls. 

Cheers,
John

_______________________________________________
TLS mailing list
TLS@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=A-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I&s=p2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------76B2084801F8DB8217DD4AD9-- From nobody Tue Oct 1 06:38:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9031200CE; Tue, 1 Oct 2019 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 HiKBuu4NXKeP; Tue, 1 Oct 2019 06:37:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 37E87120024; Tue, 1 Oct 2019 06:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1569937065; bh=5hPbXsq/aYiq0TmayXlY/PFDCT8a/arWi74oPfr0YhU=; h=X-UI-Sender-Class:From:To:References:In-Reply-To:Subject:Date; b=j9pQ2UTDzNK9AQ+hZMiLqbd+WirvwsQdREZqc2de9/cTsX49Hq5jFQIsMDZ9Xe1Hp gZ/Ilv7y9PfoaUxf2kCxPsHJeFzkvJ6Gb9GjL+zem+MZIn3oeg4cBOSPODa3E2HKZo kUrm6k0me9FX1wHHerh05gx6X5so64JOqAqowN6k= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from E108678 ([80.92.116.217]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M1po0-1iHVGj38X2-002If7; Tue, 01 Oct 2019 15:37:45 +0200 From: To: "'John Mattsson'" , , References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> In-Reply-To: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> Date: Tue, 1 Oct 2019 15:37:05 +0200 Message-ID: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQDADKbUP4/3gAM9SAzHCUgPUKIoKalwn67A Content-Language: de X-CheckRecipientChecked: true x-ts-tracking-id: 71b26417-e9f7-43f0-aea7-971ab7e956ae.1 X-Provags-ID: V03:K1:YXavmIPscQmXVHU8cmwy3sUoUbpf9/cFySyAMVFVFBnjxboMUIx SkSPV0IxG37EEUz0GVDmyj7ah4V56XgFSeN+/++jU5sqHMubYvLpqhYIiG09KYav+cH6hXf wSVkwkhsT2qVDxRnophyyU1l4s3zEHbkYEJTX0qUAueYua08E4k2PDQfBMZ3zZaCVxAT5R9 /+kbpeV4juqZYTFdPHc+A== X-UI-Out-Filterresults: notjunk:1;V03:K0:y1H40qmI3A0=:EqIKCepVNvv6OzOnSGE+mA FGJajWba3bm8CH05fDlQhY5W7KSG+50tDiFnUvgkTWOqYku5U9wU2ha/VV/fMk+Sc4CnpT9vz 4bJamvify3N6/CDmly2eBMlr8mB+5vDvBh9fQjtsoEXd4tQjHR8z+/7/AXofxwxEdN3KknAkP qnI0JncnXb2EH3tsh6pLDMUBCFZGhovl5QAoYn5RyT4AaWgpAfAifEmiIzW/MQo1heox3+9fj fT5lZb4xru2E3rxdrlxCOZ8c3lKjB2V+p/RGZclasBjQJcd24wybiMSTRk2sxUiaadrBJLdqz hQIfiNJybO7NJnq+rH+YWeE7z1eMLgKjDBnLei3BmG4wC3Opajttz+IXV9thH1QKlzXHmZVnP wRIf8g+rkmojoed1E7i3Bmd3Qf/EgbVqq2gm1v6DvSunZ0XfFccVErAKU7G8S9BMD/v0Y2bQv LtAC2bzQ4S+F6EzAvufQ2wJk9j6mh7he459HXhQaAhbxtDvwI2MkfiboqqpknoodOLZBBPISb cCCvVi/bv+1ZONk3uUuSvfN8fYusQYIkX4yaEC3kCtAIPwPhyM8cJEmYs9t6hAf6zQvUdFcp5 rty11QNNQQ/I9WOVgURoN/6KA9gS1vVXWiu3nWb/c8euNZ2vNdb3JrbRhZ6hYU/scaR9dfbOs FTgERN3i+kNcTxqjL5vrc4CHHswfF6j0u6e7skA0pJjgi2dqPbKWGGWHUZbXxrFsMOsq66tp3 DETn0wNvJBG7YSkMchmlhN8SKQCSiWGEs9M3rNWGQr1Y2Gh4SRDf3ZYfyLqHZnxN4MDe6IoAH 3GIvi4+1Ft3Fal4NrRHnSLVGuaLjAYg7gCL31F/hd8mc15vxvs7ng8lGANUeWOkW9VhwTcyc2 eUcr0NBEZrVjyXhMTNXK0aNsBMY7Q6T1TJp70rUkcCVAECqu0mvKF5zxhvBJbzHoaBOv2icgz 8T3PibTW2sCyI3H6EfORrHA2L5gAACY/Uqdk33K6xfSCnf834JW0qRapgi4tuCDQE+hPiFlZp WjaJLROix/ShNVr9UdUYSJKLPPmPWeQW7fkoGQSvAnkGcY2O38fprvyjixsLN6H6qiKQOpjyJ z0ErSg5u73pubICmbBEOi4nqzzSX4nPiIbCtxpEYDds09T9cyRrSJtPAMBeUvrHrL0+kNcHsd 1uiF9quTIZgzbv2qKB1jBhQeQmxQDbKA4FmuFkfuexdgDpaBm274Y5kSY4iMnU8rFzLv64fj7 2XZ1Fsc08wu3s2ieyMBXrfc7GGqhTLFpbdGS83ee5IFAmrI0A23tXvV9Y7sM= Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 13:37:59 -0000 IMHO the problem with deprecation is not in the IETF but rather with the = deployments.=20 Ciao Hannes PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you = follow RFC 7925/7525. -----Original Message----- From: TLS On Behalf Of John Mattsson Sent: Donnerstag, 26. September 2019 14:18 To: TLS@ietf.org; saag@ietf.org Subject: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Hi, Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 = deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in = a myriad subtle ways and should according to me optimally have been = deprecated years ago. 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time = not forbid use of TLS 1.1 as that would potentially break = interoperability with some Rel-12 nodes (that had TLS 1.2 as should = support). The lesson 3GPP learned from this was the need to as early as = possible mandate support of new protocol versions. With TLS 1.3, 3GPP = took action early and TLS 1.3 support was mandated for network nodes in = Rel-15 (2018) and for mobile phones in Rel-16 (2019). At some point in time we will want to deprecate TLS 1.2. To enable that, = TLS 1.3 support should be mandated or encouraged as much as possible. I = would like to avoid a situation where we want to deprecate TLS 1.2 but = realize that it cannot be done because some implementations only support = TLS 1.2. How can IETF enable smoother and faster deprecations in the = future? The browser industry has a decent track record of algorithm = deprecation and I hope to soon see the following warning in my browser: =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D Other industries have less stellar track records of algorithm = deprecation. How can IETF be more pro-active regarding deprecations in the future? In = the best of words, nobody should be surprised when IETF deprecates a = protocol version or algorithm. NIST and similar organizations in other = countries have the practice to long time in advance publish deadlines = for security levels, algorithms, and protocol versions. Can the IETF do = something similar, not just for TLS but in general? For TLS, there are = several things to deprecate, in addition to MD5 and SHA-1, also = PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher = suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the = future. Cheers, John _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Oct 1 06:52:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E765C1201DB for ; Tue, 1 Oct 2019 06:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 i47LhDFFuLOP for ; Tue, 1 Oct 2019 06:52:22 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 7634B120024 for ; Tue, 1 Oct 2019 06:52:21 -0700 (PDT) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2019 09:52:21 -0400 Received: from XCT113CNC.rim.net (10.65.161.213) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 1 Oct 2019 09:52:20 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0415.000; Tue, 1 Oct 2019 09:52:19 -0400 From: Dan Brown To: John Mattsson , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZv?= =?utf-8?Q?r_erratum=3F?= Thread-Index: AdV4RZj0/krq7yA89EekKREnIpqJfwAL2k0AAAY+MAA= Date: Tue, 1 Oct 2019 13:52:19 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501E4532F@XMB116CNC.rim.net> References: <20191001104718.8626261.12105.36904@blackberry.com> <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> In-Reply-To: <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.2.27.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00BC_01D5783D.E9AC77B0" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 13:52:25 -0000 ------=_NextPart_000_00BC_01D5783D.E9AC77B0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: John Mattsson > > Dan Brown wrote: > > > ANSI X9.62-2005 was withdrawn in 2015 > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > behind a > paywall is even worse. [DB] Have mercy on TLS: I expect they had plenty of working code, and archived ECDSA specs for documentation, so it's not at all their fault that another organization's specs expired while they were undertaking a major improvement. > > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of ECDSA > > That NIST FIPS 186-5 will include all the details needed to implement ECDSA > is > great. [DB] I think I also said that I was not sure if it will have any ASN.1 (i.e. resolution of ECDSA-Sig-Value). > > >IETF has specs for sigs and their formats already, no? > > At the time when RFC 8446 was published, there was probably no quick and > easy solution to the problem. But the fact that IETF has historically been > fine > with relying on specifications behind paywalls is part of the problem. If > IETF had > implemented a strong open-access policy a long-time ago, there would > probably be an open-access version of ECDSA (NIST or IETF) a long time ago. > [DB] SECG was created, among several other reasons, to provide a kind of open-read-access ECC specifications. I think some IETF docs even refer to SECG, maybe SEC2? Doesn't IETF have RFC 5480, 6090, 6979, which cover a fair amount of ground in specifying (some variation of) ECDSA? Although, that's not a policy, and maybe was not even an easy enough solution for RFC 8446, etc. ------=_NextPart_000_00BC_01D5783D.E9AC77B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCIdUw ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwggdJMIIGMaADAgECAgpyAx1HAAEAAlASMA0GCSqGSIb3DQEBCwUAMFYxEzARBgoJkiaJk/Is ZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9y YXRlIElzc3VpbmcgQ0EgMTAeFw0xOTA0MTcyMDU4MjRaFw0yMDAyMjYyMjM2NTVaMIGpMRMwEQYK CZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYDVQQLEwRBTUVSMQswCQYD VQQLEwJDQTEUMBIGA1UECxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVzZXJzMRIwEAYDVQQDEwlE YW4gQnJvd24xJzAlBgkqhkiG9w0BCQEWGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQHoYbI3q25dSCAl6YGPubc51/jvsRg5VZl6f8cADT/ N6anVBzRl77zYVSEmqlrHG2/x++rOxdzcAi/LP+L7IEiU/TX+EyPR4OSLf3sQTJg/CzZLhKT+ouR CH1jn0QgFviHE4Ni0no/E4x+N0zjmhWpF7WcoaNbY0ZVW5g1jy7KtEoLwDGFylPVsrwLMzud4wjJ 32R/McoCAqaWr/vgUOoHYY6K+5fGp7wNyvhhc0sG+8ku2vNWhBo7sufwdehGISQsaBXS+Wqgy7g1 qNePiR/5i8OFgEFjO//iozFIeTPoFbSd+k4y/jv7wD+yLvVy84q9LteXpv92aFR+aTJxkEkCAwEA AaOCA8MwggO/MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgB gQCxwyqHn/RAAgFkAgELMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMC BsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAnBgkrBgEEAYI3FQoEGjAY MAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTb4N+ts9rY1LbQOi40ca8/M4cXVTAf BgNVHSMEGDAWgBQaL0tL2wfJSTuJ1jIIJ6KeC/MPazCCATIGA1UdHwSCASkwggElMIIBIaCCAR2g ggEZhkBodHRwOi8vY3JsLnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vpbmcl MjBDQSUyMDEuY3JshoHUbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWlu ZyUyMENBJTIwMSxDTj1NQ0EwMTBDTkMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw ggEDBggrBgEFBQcBAQSB9jCB8zAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3Nw MIHKBggrBgEFBQcwAoaBvWxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vp bmclMjBDQSUyMDEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBNBgNVHREERjBEoCgGCisGAQQBgjcU AgOgGgwYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20w DQYJKoZIhvcNAQELBQADggEBAEoWAOg0VEQNS86VaoPS9opseSqdMyxa/SyUNcoqeTRgadtmv1FX zUPytJUDgHQrMAmpHCurdPASknaqoHOaOyTf2AfJO9a36jIq+yC+7ybZFfiXOaFKOvAcDOpS0O25 PVZdG202Nt/g5hrOyd/hUplu0xz4h8CvihzW7AuUsBOBJn7vW5dvggrRx28FSBUARj4plfhNoGoI XJfFghQ1fWmjg8o9NjhTpXKDTy7kMNkUX2g+HACq4tzf0sjthqTFpGsAq+PhqFxKQLZ8GRAq67F+ mHWEvZArnHnDAk4JpqlGMZTVXRWZzW+21feqnog1FU6kgtM5/8uvtrEMQSe8Dn8wgggFMIIF7aAD AgECAgRDFVhfMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0Jl cnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMM I0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTE0MDIyNjE2MjM1NloXDTI0 MDIyNjE2MjM1NloweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGltaXRlZDEi MCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcGA1UEAwwgQmxhY2tCZXJyeSBD b3Jwb3JhdGUgUG9saWN5IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggIIAoICAQC6JvZA kPpT2uIOJ8w4/hBW8IhdwmDtvzMEVmnYEmmr1cnQaD3NVSIxDfNFG2dVVeZJB4qmLwLkjMf0dgDo LtaPRaqZ2kW+fWuEeWqG4sRxCIWMgrdppkQoCenWGIiW7Q59bdNLk9MsiP2FPgFMVhSvXN38vl9t AEssQDmwPVnr9nBbBhW4OnaM2JDw0B5YEnMyXBJwslA+n4YDOTfzbIB5rzdzkG/Cy+Ss7NtOEIG1 Hfeur5RzruqaVRINsbk884T1TjR4q2BMhTE2uSjaANXkl+IM1YsfmIgCj/AKr4KhEAeM4to10mA8 3fUVLZzn5YPo8/jikzQ0qTge/7Yj2veffvkYkWG1pZGJvlofl/bi/62vrmrTkx9lDKLMl5zuK8qF znvSWVhntGsHWO0ZI+uSz5h7Alr0dOTdTOr1+SR2SzqL+uReyf2ViywiAEf7JtZj4QU2rlN7rxOi Suf7mz0D8RelA6TXaGlAe/q35kqAcciJZjMugO7+XG2chzjci5c/q+LJJTwz3M+QgSI21MhTcytC itBl0WFSg/vmE26nQnuryhWUoNvryGEP2xarae/oCiKZo41nc6LcVXCoJfq/pE5OKUhAi1N/RH26 OdDb3kOjdDdLIKY/yVThed1zESsuCUNkgy9APj5LgS95nSG/oQ9LlLL5g4YQd8WrwdFIZQIBA6OC ApIwggKOMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ7uMF3 DZ6tQ1j8Ja4V0LfykTKFmzAfBgNVHSMEGDAWgBT4aYn4Y57vaF6BMGJwUqMO3bKWCDCBhgYIKwYB BQUHAQEEejB4MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwUAYIKwYBBQUH MAKGRGh0dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJv b3QlMjBDQSUyMDEuY3J0MIIBNwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwu cmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3Js hoHVbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUy MDEsQ049Um9vdENBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDcGA1UdIAQwMC4w LAYEVR0gADAkMCIGCCsGAQUFBwIBFhZodHRwOi8vY3AucmltLm5ldC9jcHMvMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBDQUAA4ICAQC38TN+ EWKxTPBOf+yu0+eJD75HI0K1/VbX+/gkxxxthB+0rhaBVrJzU3j/ifE8ST9Icc+JgORZzCjZYUz7 Lj9DbvxbtUdaJGi7CHjjxgFm7aQkPX2BvpYHjjYeQ0349boayww1AG6iX42F/Gm+P4/UT4Jv5lo5 UepzMz8mgnOnAEqpzo7NFUixXZnLTTML6g8Co+Kpwl/gDOtTcXdit2SE4qugUCI9+4UIdO5cIFUK 2vkuev3JsjuUCl0p8g/591PyDxIUoRWt9I+8nkeDmdhr/Lyuh2OY82OXqCc7TdPPRdJdo0nWCJZu OxPrK1cJPPM/FMM7EwSruS1mFbMsHyXcmUBdfm8LudkPHPpszGlQ2cAcENzgyGCd2OWlggpp+y35 JIo9eKnLC5BGio6eno6MvfNMM5DzIr5hoVfLsbJUvlIIwOaqhWWPIjiQJgS8vAAZBONh6AXXs8TA smu0yt2cSp00HvUWAyJi8eOVUOiu+f7iXXUw+xhEcOyggo4JmJ4g+qM8wzx8pc4soKVMx4SLXXlR /uO3RNZ5ZNaVc3+qIqg4EbhGNQxyCGChFYemYvRdLmjqO0sGfofYaqRdhIBpKZYk7vDOwj0ZStzg TT55OAYF0jY+A9RXSiu6xm04F3C/2G7S19sHlhK28Prjf1Ahu5NwTnpaKdM5UiX4/SrKLTCCDK4w ggqWoAMCAQICBAsRTXAwDQYJKoZIhvcNAQELBQAweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJs YWNrQmVycnkgTGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcG A1UEAwwgQmxhY2tCZXJyeSBDb3Jwb3JhdGUgUG9saWN5IENBIDEwHhcNMTkwMjI2MjIzNjU1WhcN MjAwMjI2MjIzNjU1WjBWMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJc3N1aW5nIENBIDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDVHL/KEgF8NzTToTzGn4ZzdjfvMRN9YG1zaPkekwXrknWRKOTw 30fjw6bP7CF60nnJwGSVhoQ1DkNqVz0ZPI35dJW3EBEUyNVAtOGb+fiNmDsOKk2gbe+zwLb1ttrN 7BOgIDuqJKlujUBYxBk6Cl44KOoKwSzuvxuFHP7T6oev23Jh+DZmkm7M60iVLDzHjchFru696K8b vSiczJw0AVqWymaupeFveprrdJUz1y/G0Q0GoeZ3NFH0azM8JS6MB7Sz1zO/9SdlxvrRu0mCEN8E OgUTfG1l1sDILs7IhM9gUBF+tHJpeFc+xuSHpx7spkRzhESmuFD4h+6IIJ/B7SofAgMBAAGjgghf MIIIWzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUGi9LS9sH yUk7idYyCCeingvzD2swHwYDVR0jBBgwFoAUO7jBdw2erUNY/CWuFdC38pEyhZswgYEGCCsGAQUF BwEBBHUwczAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3NwMEsGCCsGAQUFBzAC hj9odHRwOi8vY3J0LnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENB JTIwMS5jcnQwggEsBgNVHR8EggEjMIIBHzCCARugggEXoIIBE4Y/aHR0cDovL2NybC5yaW0ubmV0 L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEuY3JshoHPbGRhcDovLy9D Tj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAxLENOPVN1YkNBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIGEgYDVR0gBIIGCTCCBgUwQQYKKwYBBAGbShQC ATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEG CisGAQQBm0oTAQMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVt ZW50Lmh0bTBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nw cy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3Au cmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgMwMzAxBggrBgEFBQcCARYl aHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwICMDMwMQYI KwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGb ShMCATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRt MEEGCisGAQQBm0oTAwMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3Rh dGVtZW50Lmh0bTBBBgorBgEEAZtKEwMCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0 L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMDATAzMDEGCCsGAQUFBwIBFiVodHRwOi8v Y3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBAAwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwUDMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMFAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTBQEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgEwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwcD MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMHAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTBwEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIAjAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAEwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAQBgkrBgEEAYI3 FQEEAwIBATAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQsFAAOCAgEAbML2 XftFHnmxEj1R+YXOw1IvY2cr3KtA2X5HweMk8WeDorircFlDGIP09Dgj2eEn7F8yg4vevOjtOj/O u+nMfxe2XdsxqbkOfOGncy2IQY0jp8Dznqg7iTJm2q5Rz+RhyICipwRhXVGhPz+UaBqzgPMRbOCy GVJFOfzIvI6IAARtWbFpDCIkIliQ36kd8UlXuAeCOqwLOQSenuL4kV+oaCKu1mNz3hC5jurnrTrt gPDYG0koEg40cxd4rv7Dy78U9jps82PFiMiA+yomtYZEsveyHHdsPupz8BN2Q6Oww99nR1ME+ING FK9r7dhEj6xAMVJ/eS2JHwtNSU3gxhhcQm/ZaP8Isfc7JKSI86II78DCyVVAJrMrt+pkNYWw8KDi yxuN5HxfGTBykx9H4lxdDTYT8AS1kf3GJUXo3/8+09g8ZIfbiSm5l96jvAL62ix/aSwFT01T7sTn CgPAcutQSnWoONApDZvqzDSJRwAtdkX+DMn2lDlocTpw99a8WkWJpNyyImvV5OeO/ra5RMCH9f2V /SerRLOQDBIjss7S3x48Fw0VsYxEIBxMV45X47lpwGfXK5oi9OuLGHBkLFavyFpLvbSDpFHfhUiD Ae2DviaDWkyLVZJXWdrujxEW2tchEcuytZw6i9k41/4mgOiy6HYwhRJhknXr5YQJ5wu5rwQxggI8 MIICOAIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMQIKcgMdRwABAAJQEjANBglg hkgBZQMEAgEFAKCBqjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x OTEwMDExMzUyMThaMC8GCSqGSIb3DQEJBDEiBCDQ/H8BY80r+mMnH5DnjjAuOHVIKj7w0Rzgmxxs /l6h1TA/BgkqhkiG9w0BCQ8xMjAwMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBAERWT6DOTqj5iEZqJKNo1Duo8glA6KRqjQua fKJPqe12e71ztnpfwDGWCTB33VC+MGKKumK8FbAuoKStNo/13//mRz/ilhtom0Q+8WZR13tbqCIX JiF652NxNi0LC/Gk3ZIrh9jskwH3jF3E9M7zGyBKA/o2DKaBDQQXJMHIR8LWuKfOZEjlOdaehQje vNSQFMyvz8rO9dI+V9lK3dOhXornPBFFjXRnEYZDckCJ9j4QxlY9/yVkGos6heKrkCSPPXtaRbPM XMqbldRdw9YqzhOAIFhaazdm5pv9Pw2RAGKxiaQMotceu7gPi3yfyUAc86ktJTMkPTAG1mg1x4Gr kLsAAAAAAAA= ------=_NextPart_000_00BC_01D5783D.E9AC77B0-- From nobody Tue Oct 1 07:02:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB3120824 for ; Tue, 1 Oct 2019 07:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=fM5+btKn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0GAaqNjT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayvUUoIFZBaO for ; Tue, 1 Oct 2019 07:01:54 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF4F120251 for ; Tue, 1 Oct 2019 07:01:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2CD3220C69; Tue, 1 Oct 2019 10:01:53 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 01 Oct 2019 10:01:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=RsEWahNArKCgIJHYFsOIyUVKxgTR xebjuL2Eq9cMurc=; b=fM5+btKn00gKBCf8ps66ZN8/tCgz0q/IHhsw5kGD1awN wCrOBWfzHsPYjIiXXChBDrsEm09QFhSwUoQfyGY5b4B9EdoLDWVcjZqp33gwMfXS ICznIzEx5KI74hC9FsHiUlY1lrcxrb5htNQ/ak5YklmwRBh67ZBffydhelw9BHgh EtaYCgCOZHB0xdlr8Sjp0A866MFJcfeJk0m5g7VwL41uykQ8T5PPp7btkjX9lHjx ll/hQELi1E76sKbWYiiDRk1aqiCPRb5sz/zOKJwhK8+1FrQGxEhZmDbx3f1Qk9nA I8nIwWYh95Qyn/4lDw2HiELPr4QvWlpVr9ehYhEoYg== 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=RsEWah NArKCgIJHYFsOIyUVKxgTRxebjuL2Eq9cMurc=; b=0GAaqNjTwIqhwD2aAGPVac 0F/FcSw1yDQfmgr5vk53VFfOhiLPBZOIcmxm8yuGWDCUsRuE7ervBjHUqvXmJdUG 8sg4Y4FooVybOEXt8LStfYkN9PPFJMDJe8/Bq6/Ui/bOmknk8H1VfGnPnBfyfwOZ omTF0SWt/hHsGTgeE1j11yuXip+ej2/fiZv1mUo+tVpi9d9t0neDsQifB4g8cdua mgv9vbUXJQeB+Vt8RocB6zok/xLLX8Z1onw6JZRmNJkENM5JNCbOCtMGeO3GykdU QQw5iBXIU7q4ztR/sqXw1sxmvk5UwFiKgUi/Fw87VaBk0lAGlZbxbO9UMnFDFXfw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeggdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CB8BC3C00A1; Tue, 1 Oct 2019 10:01:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-334-g7f5110b-fmstable-20191001v2 Mime-Version: 1.0 Message-Id: <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> In-Reply-To: <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1765606.IRqicVgrGs@pintsize.usersys.redhat.com> <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> Date: Tue, 01 Oct 2019 07:01:32 -0700 From: "Christopher Wood" To: "Hubert Kario" Cc: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 14:02:05 -0000 On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > ``` > > > Servers MUST NOT send more than 255 tickets to clients. > > > ``` > > > > > > per what? session? at a time? connection? > > > > This is all per session. We can state it explicitly in the next version. > > so this count needs to be kept as part of session and impacts connections that > perform resumption? Sorry, I meant connection: "Clients may indicate to servers their desired number of tickets for *a single connection* via the following "ticket_request" extension" This is a simple hint for servers. Nothing more. No state needs to be stored past connection establishment. > > > what's the expected behaviour with tickets and post-handshake > > > authentication? Are tickets sent after PHA also bound by this limit? > > > > As mentioned earlier, there is no effect, so we left it out. We're happy to > > accept text should you think it's needed. > > If the I-D states that servers should not send more tickets than the client > asked for, and then send exactly that amount, then they won't be able to send > new tickets after PHA and remain compliant. > > Yes, it's completely up to the server to decide if to send tickets after PHA > or not, and I'm not suggesting that the client should request for tickets in > one of its PHA messages, much less expect or require them, but sending tickets > after PHA is reasonable and explicitly stated behaviour: > > RFC 8446 Section 4.6.1: > For instance, the server might send a new > ticket after post-handshake authentication in order to encapsulate > the additional client authentication state. > > so the I-D should explicitly state what's the expected behaviour in that case. > > IMHO, the extension should be used for the tickets sent right after the > handshake, it should not put an upper bound for the tickets that a server can > send in a single connection. For a very long lived connection (especially if > the connection uses KeyUpdate messages regularly), the initial tickets may > expire. Server may notice that and send a new group of tickets then. Since these hints are not mandatory to honor I don't think we need to describe this case. In particular, this is a valid case where ignoring the SHOULD is fine, in my opinion. If the draft required that servers MUST NOT send more tickets than what's requested, then yes, I think these details would be important. > > > > ``` > > > > > > Clients MUST NOT change the value of TicketRequestContents.count in > > > second ClientHello messages sent in response to a HelloRetryRequest. > > > > > > ``` > > > > > > 'A server MUST abort the connection with an "illegal_parameter" if the > > > value of the extension changed, it was added or removed in second > > > ClientHello.' ? > > I don't think this is necessary. > > given past discussions on this mailing list, I don't think this is entirely > obvious.... > > Then what about the addition or removal of extension being forbidden? Can we > add something like this?: > > ``` > The presence or absence of the extension MUST be maintained in second > ClientHello message when compared to first ClientHello in connection. > ``` That works for me. We can add it in the next version. Best, Chris From nobody Tue Oct 1 07:18:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981EF12021C for ; Tue, 1 Oct 2019 07:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 waEzJr-xKA_K for ; Tue, 1 Oct 2019 07:18:33 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 9FF45120835 for ; Tue, 1 Oct 2019 07:18:19 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs212cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2019 10:18:12 -0400 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 1 Oct 2019 10:18:12 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0415.000; Tue, 1 Oct 2019 10:18:11 -0400 From: Dan Brown To: Rene Struik , John Mattsson , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Thread-Topic: =?utf-8?B?KHF1ZXN0aW9uIG9uIEFOU0kgWDkuNjItMjAwNSkgUmU6IFtUTFNdIEVjZHNh?= =?utf-8?B?LXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZvciBlcnJhdHVtPw==?= Thread-Index: AQHVeFxIhkIbnWQYYkq4BSiWK0uouKdFzvrQ Date: Tue, 1 Oct 2019 14:18:10 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501E453DE@XMB116CNC.rim.net> References: <20191001104718.8626261.12105.36904@blackberry.com> <3f715f6a-f660-f2e4-544f-583063aa6238@gmail.com> In-Reply-To: <3f715f6a-f660-f2e4-544f-583063aa6238@gmail.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.2.27.110] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_00CE_01D57841.861024F0" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] =?utf-8?q?=28question_on_ANSI_X9=2E62-2005=29_Re=3A__Ecdsa?= =?utf-8?q?-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 14:18:39 -0000 ------=_NextPart_000_00CE_01D57841.861024F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00CF_01D57841.861024F0" ------=_NextPart_001_00CF_01D57841.861024F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sorry to TLS-WG if this getting out of TLS scope. (Let me know, and I = will be happy to cease this thread.) Hi Rene, Did you mean to ask me about the ANSI X9.62 expiration off-list? = I=E2=80=99ll assume not, and answer on-list. =20 1. I was told often by X9 admin and chairs that ANSI X9.62 was = withdrawn. Are you doubting the withdrawal? 2. When I visited ANSI just to confirm 62 expiration, = https://webstore.ansi.org/Search/Find?in=3D1 = &st=3DX9.62 = reports nothing found. 3. =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8BThe globalspec site you = mention is news to me, though I never bother to search the whole web for = X9.62. I sympathize with others that need to: sorry to you. 4. I imagine that there many reasons for the expiration, many beyond my = grade, but, as you say, I (unlike some) often nap, so it=E2=80=99d be = fair to grade me at 50%. Am I to infer that you are more baffled about = all this than I am? 5. Yes, =E2=80=9Crevival=E2=80=9D is my term, and in no way an official, = so it=E2=80=99s sensible to quote me on it. Dan From: Rene Struik =20 Sent: Tuesday, October 1, 2019 9:29 AM To: Dan Brown ; John Mattsson = ; Peter Gutmann = ; Hubert Kario ; = TLS@ietf.org Subject: (question on ANSI X9.62-2005) Re: [TLS] Ecdsa-sig-value in TLS = 1.3 =E2=80=93 need for erratum? =20 Hi Dan: =20 Just curious about the fate of ANSI X9.62-2005: On the website below, = this specification is still listed as "active" (whereas ANSI X9.62-1998 = is labelled historic). I purchased that spec for a project on Nov 22, 2016 from the ANSI = webstore (when, surely, it was not labelled as expired) [see purchase = info below]. =20 What happened? Was someone sleeping at the wheel? Why would there be a = completely differently named "revival", ANSI X9.142, with almost the = same content, under way, and why would its fate, 4 years after 2015, be = unsure? Is there a technical reason ANSI did not wish to pursue this, or = admin mishaps? =20 Rene =20 Note: purchase info RS from ansi store below:=20 Subject: Your Order Confirmation for X_458150 From: ess@ansi.org =20 Date: 11/22/2016, 2:57 PM To: [snip] 25 West 43 Street New York, NY 10036 Tel: 212.642.4900 Fax: 212.398.0023 Sold To Rene Struik [snip] CANADA Order ID X_458150 Card Received Mastercard Charged to Account ****[snip] Date 11/22/2016 Quantity Product Unit Price Total Price 1 ANSI X9.62:2005 $100.00 $100.00 Download Total $100.00 THANK YOU FOR USING THE ANSI STANDARDS STORE. The American National Standards Institute (ANSI) is a private non-profit = organization that administers and coordinates the U.S. voluntary standardization and conformity assessment = system. The standards you purchased were added to your Alerts Profile, which = will allow you to receive an automatic notification via email when the documents are revised or amended. You = may manage your alerts at any time. =20 https://standards.globalspec.com/std/1955141/ANSI%20X9.62 = =20 =20 =20 On 10/1/2019 6:47 AM, Dan Brown wrote: Re ECDSA specs and paywells: ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 10 = years, despite my weak effort. A revival, ANSI X9.142, with almost the same content is under way, = though even its fate is unsure. Also, I expect FIPS 186-5 is nearly ready, and will specify much of = ECDSA and EdDSA (not ASN.1?), which many may like (even better than = ANSI). Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or = not, despite my weak effort. IETF has specs for sigs and their formats already, no? Then there's ISO, IEEE, ... =20 =20 Original Message =20 From: John Mattsson Sent: Tuesday, October 1, 2019 5:25 AM To: Peter Gutmann; Hubert Kario; TLS@ietf.org =20 Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for = erratum? =20 Hubert Kario wrote: =20 Now, I don't have access to X9.62-2005, but there's a possibility of = confusion. =20 I think references to specifications behind paywalls and other types of = limited access is a major problem. Not only for the standardization = process, but also for researchers and implementors. In general, I think = people should be able to implement and analyze IETF standards without = having to pay for access. =20 Open-access is even more important for security specifications. ANSI = X.62 is hopefully quite well-studied, but for other references, the lack = of analysis often leads to mistakes and unknown weaknesses. =20 I would like the IETF to take a much stronger stance against normative = references to paywalls.=20 =20 Cheers, John =20 _______________________________________________ TLS mailing list TLS@ietf.org =20 https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_tls = = &d=3DDwICAg&c=3DyzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=3DqkpbVDRj7= zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEoh= llYGLju6I&s=3Dp2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=3D =20 _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls = =20 =20 --=20 email: rstruik.ext@gmail.com | Skype: = rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 ------=_NextPart_001_00CF_01D57841.861024F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sorry to TLS-WG if = this getting out of TLS scope.=C2=A0 (Let me know, and I will be happy = to cease this thread.)

Hi Rene,

Did you mean to ask = me about the ANSI X9.62 expiration off-list? I=E2=80=99ll assume not, = and answer on-list.=C2=A0

  1. I was = told often by X9 admin and chairs that ANSI X9.62 was withdrawn.=C2=A0 = Are you doubting the withdrawal?
  2. When = I visited ANSI just to confirm 62 expiration, http= s://webstore.ansi.org/Search/Find?in=3D1&st=3DX9.62 reports = nothing found.
  3. =E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8B=E2=80=8BThe globalspec site = you mention is news to me, though I never bother to search the whole web = for X9.62.=C2=A0 I sympathize with others that need to: sorry to = you.
  4. I = imagine that there many reasons for the expiration, many beyond my = grade, but, as you say, I (unlike some) often nap, so it=E2=80=99d be = fair to grade me at 50%.=C2=A0 Am I to infer that you are more baffled = about all this than I am?
  5. Yes, = =E2=80=9Crevival=E2=80=9D is my term, and in no way an official, so = it=E2=80=99s sensible to quote me on it.

    6. Dan

From: Rene Struik <rstruik.ext@gmail.com> =
Sent: Tuesday, October 1, 2019 9:29 AM
To: Dan = Brown <danibrown@blackberry.com>; John Mattsson = <john.mattsson=3D40ericsson.com@dmarc.ietf.org>; Peter Gutmann = <pgut001@cs.auckland.ac.nz>; Hubert Kario = <hkario@redhat.com>; TLS@ietf.org
Subject: (question on = ANSI X9.62-2005) Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for = erratum?

 

Hi =
Dan:
 
Just curious about =
the fate of ANSI X9.62-2005: On the website below, this specification is =
still listed as "active" (whereas ANSI X9.62-1998 is labelled =
historic).
I purchased that spec for a project on =
Nov 22, 2016 from the ANSI webstore (when, surely, it was not labelled =
as expired) [see purchase info =
below].
 
What happened? =
Was someone sleeping at the wheel? Why would there be a completely =
differently named "revival", ANSI X9.142, with almost the same =
content, under way, and why would its fate, 4 years after 2015, be =
unsure? Is there a technical reason ANSI did not wish to pursue this, or =
admin =
mishaps?
 
Rene=

 
Note: purchase info RS from ansi =
store below: 
Subject: Your Order Confirmation for =
X_458150
From: ess@ansi.org
Date: =
11/22/2016, 2:57 PM
To: =
[snip]
25 West 43 Street
New =
York, NY 10036
Tel: =
212.642.4900
Fax: =
212.398.0023
Sold To
Rene =
Struik
[snip]
CANADA=

Order ID X_458150
Card Received =
Mastercard
Charged to Account =
****[snip]
Date =
11/22/2016
Quantity Product Unit Price Total =
Price
1 ANSI X9.62:2005 $100.00 $100.00 =
Download
Total $100.00
THANK =
YOU FOR USING THE ANSI STANDARDS STORE.
The =
American National Standards Institute (ANSI) is a private non-profit =
organization that administers and
coordinates the =
U.S. voluntary standardization and conformity assessment =
system.
The standards you purchased were added to =
your Alerts Profile, which will allow you to receive an =
automatic
notification via email when the documents =
are revised or amended. You may manage your alerts at any =
time.
 
https://standards.g=
lobalspec.com/std/1955141/ANSI%20X9.62
&nbs=
p;
 

On = 10/1/2019 6:47 AM, Dan Brown wrote:

Re ECDSA specs and =
paywells:
ANSI X9.62-2005 was withdrawn in 2015, =
expiring automatically after 10 years, despite my weak =
effort.
A revival, ANSI X9.142, with almost the =
same content is under way, though even its fate is =
unsure.
Also, I expect FIPS 186-5 is nearly ready, =
and will specify much of ECDSA and EdDSA (not ASN.1?), which many may =
like (even better than ANSI).
Meanwhile, SEC1, =
versions 1.0 and 2.0, are available, fortunately or not, despite my weak =
effort.
IETF has specs for sigs and their formats =
already, no?
Then there's ISO, IEEE, =
...
 
 
  Original Message  
From: John =
Mattsson
Sent: Tuesday, October 1, 2019 5:25 =
AM
To: Peter Gutmann; Hubert Kario; TLS@ietf.org
Subjec=
t: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for =
erratum?
 
Hubert Kario =
<hkario@redhat.com> =
wrote:
 
Now, I don't have =
access to X9.62-2005, but there's a possibility of =
confusion.
 
=
I think references to specifications behind paywalls and other types of =
limited access is a major problem. Not only for the standardization =
process, but also for researchers and implementors. In general, I think =
people should be able to implement and analyze IETF standards without =
having to pay for =
access.
 
Open-access is =
even more important for security specifications. ANSI X.62 is hopefully =
quite well-studied, but for other references, the lack of analysis often =
leads to mistakes and unknown =
weaknesses.
 
I would =
like the IETF to take a much stronger stance against normative =
references to paywalls. =

 
Cheers,
John
 
_____________=
__________________________________
TLS mailing =
list
TLS@ietf.org
https://urldefense.proofpoint.com/v=
2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_tls&d=3DDwICAg&=
c=3DyzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=3DqkpbVDRj7zlSRVql-=
UonsW647lYqnsrbXizKI6MgkEw&m=3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYG=
Lju6I&s=3Dp2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU&e=3D
 


___________________________=
____________________
TLS mailing =
list
TLS@ietf.org
https://www.ietf.org/mailman/listin=
fo/tls

 

-- =

email: rstruik.ext@gmail.com | Skype: =
rstruik
cell: +1 (647) 867-5658 | US: +1 (415) =
690-7363
------=_NextPart_001_00CF_01D57841.861024F0-- ------=_NextPart_000_00CE_01D57841.861024F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCIdUw ggXJMIIDsaADAgECAgUA9lfgwDANBgkqhkiG9w0BAQ0FADB8MQswCQYDVQQGEwJDQTEbMBkGA1UE CgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJ MSwwKgYDVQQDDCNCbGFja0JlcnJ5IEVudGVycHJpc2UgUlNBIFJvb3QgQ0EgMTAeFw0xMzEyMTMx NzQ1NDdaFw0zODEyMTMxNzQ1NDdaMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0JlcnJ5 IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMMI0Js YWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMIICIDANBgkqhkiG9w0BAQEFAAOCAg0A MIICCAKCAgEAxkXAf/EHxa1okuoiPnKhHeaDfSRXq35g7JH34MqiM2cxMsL+WMe/8792DLEAe5Lm FLURmrkBiqwgzkrpejF1WBUaqrM0nGSkxTfO9ywXFHKZnK2wyxE+uNdIN5KzuzijEFJpnHxapdJg k8VmsgSnn+wTyRF8J/2DsaKV7UPYNkoGGZtCggI6Dh92G9AUKzZBSjfaZRfwStEv26wVgM8CiqSa O2FuwYriu+To03yDNiC0XOaGbPLyPAdyJbY71Bud3RQE1wciQV0nLwXnyCBmDK127NkjdewY4nAF TVuKaTVCqAdGKRo5idywpSHknZy01AvOJNuvL/BkN9Nv9nflelSml5TJNhfSa2hDRmHvr0+Jns+A qORC2WlvCybRGHkmTjpYLLMnIVprNBWPCCE6B/RaoLvcTvDeUwBVoqYzLSfLT6jAoXVcJM+XT948 TzAgCKcJg4oupgiMtYyL/oktajJbnpiLtRZ3jRX2hEgRW8tJZckvlxtrBGxQLYWNVe48OdBhbNnO bByGN2o0/GAttfkM8WrdjnCNv5YZ1d1eZPqCJicQ7ML4xRzUPwD1u7YvgdVRFidB3CsxM9nnlnam MYWQIV5nUuyK/1NUTiAEhGBYOsLeemgvPz41TsjERujbzHcj8MM3zMdwhWr86Dp1292C/bwyNgMm OfVgsHnZRnECAQOjVDBSMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQW BBT4aYn4Y57vaF6BMGJwUqMO3bKWCDAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG9w0BAQ0FAAOC AgEArBVGo/mS9/+yWzGI03ae5osTFt3v2acQVj1OrqSABZQXTdOXjJL31Q4QJABZlwllzKeIlFne 3c9yn39i3QMhoSjqkn4NjbPjKiiyzOLoI0PGq5UTQtpGm7X/EaXkcYDFhrIHnGfC9dmB5WeuwMwX fmKwUtiLPhgtgjGBqkxSOiFFbBUBiLGs/muE4IYbKJGPKqilOBLpeK1Kyp8zXIrJLLQ0zzkK6TkQ x6RULQ+px3geS5UWkrsFXCHK/x9vBxH313O7RV7vvwt2Opc0HFw9LzF50jie/wqx9HD3tm0GgvqD Aabtlao1V1mfLpk8k+nrWd589ZZSHmQMVFvzETnrS0BS4wZssImORAbv6tVCHZSf6gu1XApnxMaM Hy8qmL9lfkoTaxF7cxzzwrj5P49Xj+n4NZT95GyYNAoU3AhAFrQV+H6BXFTOHNX/ALubYWg5x+xu JFi+7HTcaCjZzjSGLWG3kilqn6JkT229jgYClzN8EylemXv3yz1vVjXbTRZNDK9G/p1Jj2SxlBC/ mTBvedATbkIMVm5Wzl8cE3rIp+A9lZ+bS9CfVx5OthHQxXn0fuVCakWp4a+KTsTtFlqbtVMesdcU Q1uMk8Tap11X43bkAyX25l76ejxuVCZYZaOxZFt689bVqRFh4DjyfagCRu65eQgOu013aZiAc28i WCEwggdJMIIGMaADAgECAgpyAx1HAAEAAlASMA0GCSqGSIb3DQEBCwUAMFYxEzARBgoJkiaJk/Is ZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9y YXRlIElzc3VpbmcgQ0EgMTAeFw0xOTA0MTcyMDU4MjRaFw0yMDAyMjYyMjM2NTVaMIGpMRMwEQYK CZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMQ0wCwYDVQQLEwRBTUVSMQswCQYD VQQLEwJDQTEUMBIGA1UECxMLTWlzc2lzc2F1Z2ExDjAMBgNVBAsTBVVzZXJzMRIwEAYDVQQDEwlE YW4gQnJvd24xJzAlBgkqhkiG9w0BCQEWGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALQHoYbI3q25dSCAl6YGPubc51/jvsRg5VZl6f8cADT/ N6anVBzRl77zYVSEmqlrHG2/x++rOxdzcAi/LP+L7IEiU/TX+EyPR4OSLf3sQTJg/CzZLhKT+ouR CH1jn0QgFviHE4Ni0no/E4x+N0zjmhWpF7WcoaNbY0ZVW5g1jy7KtEoLwDGFylPVsrwLMzud4wjJ 32R/McoCAqaWr/vgUOoHYY6K+5fGp7wNyvhhc0sG+8ku2vNWhBo7sufwdehGISQsaBXS+Wqgy7g1 qNePiR/5i8OFgEFjO//iozFIeTPoFbSd+k4y/jv7wD+yLvVy84q9LteXpv92aFR+aTJxkEkCAwEA AaOCA8MwggO/MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgB gQCxwyqHn/RAAgFkAgELMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjALBgNVHQ8EBAMC BsAwDAYDVR0TAQH/BAIwADBPBgNVHSABAf8ERTBDMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAnBgkrBgEEAYI3FQoEGjAY MAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMB0GA1UdDgQWBBTb4N+ts9rY1LbQOi40ca8/M4cXVTAf BgNVHSMEGDAWgBQaL0tL2wfJSTuJ1jIIJ6KeC/MPazCCATIGA1UdHwSCASkwggElMIIBIaCCAR2g ggEZhkBodHRwOi8vY3JsLnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vpbmcl MjBDQSUyMDEuY3JshoHUbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWlu ZyUyMENBJTIwMSxDTj1NQ0EwMTBDTkMsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZp Y2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQw ggEDBggrBgEFBQcBAQSB9jCB8zAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3Nw MIHKBggrBgEFBQcwAoaBvWxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3Vp bmclMjBDQSUyMDEsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jQUNlcnRpZmljYXRlP2Jhc2U/ b2JqZWN0Q2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTBNBgNVHREERjBEoCgGCisGAQQBgjcU AgOgGgwYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20w DQYJKoZIhvcNAQELBQADggEBAEoWAOg0VEQNS86VaoPS9opseSqdMyxa/SyUNcoqeTRgadtmv1FX zUPytJUDgHQrMAmpHCurdPASknaqoHOaOyTf2AfJO9a36jIq+yC+7ybZFfiXOaFKOvAcDOpS0O25 PVZdG202Nt/g5hrOyd/hUplu0xz4h8CvihzW7AuUsBOBJn7vW5dvggrRx28FSBUARj4plfhNoGoI XJfFghQ1fWmjg8o9NjhTpXKDTy7kMNkUX2g+HACq4tzf0sjthqTFpGsAq+PhqFxKQLZ8GRAq67F+ mHWEvZArnHnDAk4JpqlGMZTVXRWZzW+21feqnog1FU6kgtM5/8uvtrEMQSe8Dn8wgggFMIIF7aAD AgECAgRDFVhfMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJCbGFja0Jl cnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAqBgNVBAMM I0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTE0MDIyNjE2MjM1NloXDTI0 MDIyNjE2MjM1NloweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGltaXRlZDEi MCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcGA1UEAwwgQmxhY2tCZXJyeSBD b3Jwb3JhdGUgUG9saWN5IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggIIAoICAQC6JvZA kPpT2uIOJ8w4/hBW8IhdwmDtvzMEVmnYEmmr1cnQaD3NVSIxDfNFG2dVVeZJB4qmLwLkjMf0dgDo LtaPRaqZ2kW+fWuEeWqG4sRxCIWMgrdppkQoCenWGIiW7Q59bdNLk9MsiP2FPgFMVhSvXN38vl9t AEssQDmwPVnr9nBbBhW4OnaM2JDw0B5YEnMyXBJwslA+n4YDOTfzbIB5rzdzkG/Cy+Ss7NtOEIG1 Hfeur5RzruqaVRINsbk884T1TjR4q2BMhTE2uSjaANXkl+IM1YsfmIgCj/AKr4KhEAeM4to10mA8 3fUVLZzn5YPo8/jikzQ0qTge/7Yj2veffvkYkWG1pZGJvlofl/bi/62vrmrTkx9lDKLMl5zuK8qF znvSWVhntGsHWO0ZI+uSz5h7Alr0dOTdTOr1+SR2SzqL+uReyf2ViywiAEf7JtZj4QU2rlN7rxOi Suf7mz0D8RelA6TXaGlAe/q35kqAcciJZjMugO7+XG2chzjci5c/q+LJJTwz3M+QgSI21MhTcytC itBl0WFSg/vmE26nQnuryhWUoNvryGEP2xarae/oCiKZo41nc6LcVXCoJfq/pE5OKUhAi1N/RH26 OdDb3kOjdDdLIKY/yVThed1zESsuCUNkgy9APj5LgS95nSG/oQ9LlLL5g4YQd8WrwdFIZQIBA6OC ApIwggKOMBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQ7uMF3 DZ6tQ1j8Ja4V0LfykTKFmzAfBgNVHSMEGDAWgBT4aYn4Y57vaF6BMGJwUqMO3bKWCDCBhgYIKwYB BQUHAQEEejB4MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwUAYIKwYBBQUH MAKGRGh0dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJv b3QlMjBDQSUyMDEuY3J0MIIBNwYDVR0fBIIBLjCCASowggEmoIIBIqCCAR6GRGh0dHA6Ly9jcmwu cmltLm5ldC9CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUyMDEuY3Js hoHVbGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwRW50ZXJwcmlzZSUyMFJTQSUyMFJvb3QlMjBDQSUy MDEsQ049Um9vdENBLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNl cyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0 aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MDcGA1UdIAQwMC4w LAYEVR0gADAkMCIGCCsGAQUFBwIBFhZodHRwOi8vY3AucmltLm5ldC9jcHMvMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBDQUAA4ICAQC38TN+ EWKxTPBOf+yu0+eJD75HI0K1/VbX+/gkxxxthB+0rhaBVrJzU3j/ifE8ST9Icc+JgORZzCjZYUz7 Lj9DbvxbtUdaJGi7CHjjxgFm7aQkPX2BvpYHjjYeQ0349boayww1AG6iX42F/Gm+P4/UT4Jv5lo5 UepzMz8mgnOnAEqpzo7NFUixXZnLTTML6g8Co+Kpwl/gDOtTcXdit2SE4qugUCI9+4UIdO5cIFUK 2vkuev3JsjuUCl0p8g/591PyDxIUoRWt9I+8nkeDmdhr/Lyuh2OY82OXqCc7TdPPRdJdo0nWCJZu OxPrK1cJPPM/FMM7EwSruS1mFbMsHyXcmUBdfm8LudkPHPpszGlQ2cAcENzgyGCd2OWlggpp+y35 JIo9eKnLC5BGio6eno6MvfNMM5DzIr5hoVfLsbJUvlIIwOaqhWWPIjiQJgS8vAAZBONh6AXXs8TA smu0yt2cSp00HvUWAyJi8eOVUOiu+f7iXXUw+xhEcOyggo4JmJ4g+qM8wzx8pc4soKVMx4SLXXlR /uO3RNZ5ZNaVc3+qIqg4EbhGNQxyCGChFYemYvRdLmjqO0sGfofYaqRdhIBpKZYk7vDOwj0ZStzg TT55OAYF0jY+A9RXSiu6xm04F3C/2G7S19sHlhK28Prjf1Ahu5NwTnpaKdM5UiX4/SrKLTCCDK4w ggqWoAMCAQICBAsRTXAwDQYJKoZIhvcNAQELBQAweTELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJs YWNrQmVycnkgTGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEpMCcG A1UEAwwgQmxhY2tCZXJyeSBDb3Jwb3JhdGUgUG9saWN5IENBIDEwHhcNMTkwMjI2MjIzNjU1WhcN MjAwMjI2MjIzNjU1WjBWMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt MSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJc3N1aW5nIENBIDEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDVHL/KEgF8NzTToTzGn4ZzdjfvMRN9YG1zaPkekwXrknWRKOTw 30fjw6bP7CF60nnJwGSVhoQ1DkNqVz0ZPI35dJW3EBEUyNVAtOGb+fiNmDsOKk2gbe+zwLb1ttrN 7BOgIDuqJKlujUBYxBk6Cl44KOoKwSzuvxuFHP7T6oev23Jh+DZmkm7M60iVLDzHjchFru696K8b vSiczJw0AVqWymaupeFveprrdJUz1y/G0Q0GoeZ3NFH0azM8JS6MB7Sz1zO/9SdlxvrRu0mCEN8E OgUTfG1l1sDILs7IhM9gUBF+tHJpeFc+xuSHpx7spkRzhESmuFD4h+6IIJ/B7SofAgMBAAGjgghf MIIIWzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUGi9LS9sH yUk7idYyCCeingvzD2swHwYDVR0jBBgwFoAUO7jBdw2erUNY/CWuFdC38pEyhZswgYEGCCsGAQUF BwEBBHUwczAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AucmltLm5ldC9vY3NwMEsGCCsGAQUFBzAC hj9odHRwOi8vY3J0LnJpbS5uZXQvQmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENB JTIwMS5jcnQwggEsBgNVHR8EggEjMIIBHzCCARugggEXoIIBE4Y/aHR0cDovL2NybC5yaW0ubmV0 L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEuY3JshoHPbGRhcDovLy9D Tj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAxLENOPVN1YkNBLENOPUNE UCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u LERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVj dENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIGEgYDVR0gBIIGCTCCBgUwQQYKKwYBBAGbShQC ATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEG CisGAQQBm0oTAQMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVt ZW50Lmh0bTBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nw cy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMBATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3Au cmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgMwMzAxBggrBgEFBQcCARYl aHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwICMDMwMQYI KwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGb ShMCATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRt MEEGCisGAQQBm0oTAwMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3Rh dGVtZW50Lmh0bTBBBgorBgEEAZtKEwMCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0 L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMDATAzMDEGCCsGAQUFBwIBFiVodHRwOi8v Y3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBAAwMzAxBggrBgEFBQcC ARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwUDMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMFAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTBQEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgEwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwcD MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMHAjAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTBwEwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgDMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIAjAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAEwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTAQBgkrBgEEAYI3 FQEEAwIBATAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTANBgkqhkiG9w0BAQsFAAOCAgEAbML2 XftFHnmxEj1R+YXOw1IvY2cr3KtA2X5HweMk8WeDorircFlDGIP09Dgj2eEn7F8yg4vevOjtOj/O u+nMfxe2XdsxqbkOfOGncy2IQY0jp8Dznqg7iTJm2q5Rz+RhyICipwRhXVGhPz+UaBqzgPMRbOCy GVJFOfzIvI6IAARtWbFpDCIkIliQ36kd8UlXuAeCOqwLOQSenuL4kV+oaCKu1mNz3hC5jurnrTrt gPDYG0koEg40cxd4rv7Dy78U9jps82PFiMiA+yomtYZEsveyHHdsPupz8BN2Q6Oww99nR1ME+ING FK9r7dhEj6xAMVJ/eS2JHwtNSU3gxhhcQm/ZaP8Isfc7JKSI86II78DCyVVAJrMrt+pkNYWw8KDi yxuN5HxfGTBykx9H4lxdDTYT8AS1kf3GJUXo3/8+09g8ZIfbiSm5l96jvAL62ix/aSwFT01T7sTn CgPAcutQSnWoONApDZvqzDSJRwAtdkX+DMn2lDlocTpw99a8WkWJpNyyImvV5OeO/ra5RMCH9f2V /SerRLOQDBIjss7S3x48Fw0VsYxEIBxMV45X47lpwGfXK5oi9OuLGHBkLFavyFpLvbSDpFHfhUiD Ae2DviaDWkyLVZJXWdrujxEW2tchEcuytZw6i9k41/4mgOiy6HYwhRJhknXr5YQJ5wu5rwQxggI8 MIICOAIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMQIKcgMdRwABAAJQEjANBglg hkgBZQMEAgEFAKCBqjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0x OTEwMDExNDE4MDlaMC8GCSqGSIb3DQEJBDEiBCDbMLgsQdNVwSQ26dPxBVq5Bd2NrEjz2X8RFqev dF7nUTA/BgkqhkiG9w0BCQ8xMjAwMAsGCWCGSAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUD BAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUABIIBAKV5hc18wTRL3cIdpYQ3f2h3REzNaEEbD/Kw faHoz+Oqop+N4kvUuZtyCBIHDKkdH2Vaq5JZ53R4oIiF059kh1g+8PwdA9ximJAjBxm71PesvEg8 EmD5XS8fK7sFy8UuM8LNwf97G1lnqGMnq5IIcb/+T1y8Cq/Zowy6BqiemvTNjpTusjR0MxGM/f02 2zVVN4/EtuwyW3aZ4f69HrfR0WBDsP6bgU6cky5myBBLS4oZtUu4VZBqdAB8M9u/GADrzJVQRAk6 rH8qUxAbrgslKkm2Z5Wpsdkv0Z9MF215MfWMv3ElOJdZNbIIi4HUB9qspQ+lGDlvYrm2B/pisL0b upIAAAAAAAA= ------=_NextPart_000_00CE_01D57841.861024F0-- From nobody Tue Oct 1 07:56:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965E61208DF for ; Tue, 1 Oct 2019 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 yhwnPNn2dp_S for ; Tue, 1 Oct 2019 07:56:01 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D41D120842 for ; Tue, 1 Oct 2019 07:56:01 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 80AAC2A5ABE; Tue, 1 Oct 2019 10:56:00 -0400 (EDT) Date: Tue, 1 Oct 2019 10:56:00 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191001145600.GU21772@straasha.imrryr.org> Reply-To: tls@ietf.org References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156962803631.24993.3421537129925787732@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 14:56:04 -0000 On Fri, Sep 27, 2019 at 04:47:16PM -0700, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : TLS Ticket Requests > Authors : Tommy Pauly > David Schinazi > Christopher A. Wood > Filename : draft-ietf-tls-ticketrequests-02.txt > > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side, per-client state. Servers vend an > arbitrary number of session tickets to clients, at their discretion, > upon connection establishment. Clients store and use tickets when > resuming future connections. This document describes a mechanism by > which clients may specify the desired number of tickets needed for > future connections. This extension aims to provide a means for > servers to determine the number of tickets to generate in order to > reduce ticket waste, while simultaneously priming clients for future > connection attempts. I've read the draft, it looks quite useful and reasonable. It would be good to see this published. I have one idea (implemented in OpenSSL 1.1.1 on the server side) that may be worth mentioning in this context (and perhaps even the draft): - By default, OpenSSL TLS 1.3 servers only vend multiple (two) tickets on full handshakes. Resumed sessions issue just one ticket. This avoids unbounded linear growth in the number of tickets vended to a client that makes many resumed connections even after reaching its peak connection concurrency. When, instead, even resumed connections (which consume at most one ticket) also receive more than one ticket, after N connections the client has at least N as yet unused tickets, which is a waste in steady state. With the proposed extension a client that already has sufficiently many tickets to handle peak concurrency can start sending 1 as its requested ticket count if it does not reuse tickets, and else 0 if it is reusing tikets and has all the tickets it needs for now. Sending 1 on resumption when enough tickets are at hand helps clients avoid receiving useless tickets from servers that don't implement the OpenSSL strategy. Sending 0 helps even with servers that use the OpenSSL strategy to avoid sending pointless tickets to clients that do reuse tickets and don't presently need more. In OpenSSL, with 2 default tickets vended per full handshake, and a client that implements single-use tickets, it takes N initial full handshakes to reach steady-state with N concurrent resumable sessions, after which time each resumption gets a new ticket for the next resumption. With the proposed extension, I'd raise the number of tickets vended on a full handshake to the smaller of say 5 and the client's requested count, which make it possible to prime N parallel tickets in N/4 previous full handshakes. I'd still (by default) cap the ticket count vended in a resumed session at 1, but a hint from clients that have enough and send a request for 0 new tickets would then be helpful. -- Viktor. From nobody Tue Oct 1 08:02:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F00E120927 for ; Tue, 1 Oct 2019 08:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 LHc5Ex1kSeKA for ; Tue, 1 Oct 2019 08:02:33 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A124312089D for ; Tue, 1 Oct 2019 08:02:32 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l21so13759252lje.4 for ; Tue, 01 Oct 2019 08:02:32 -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=yfin+no+we0MJGBZlEaS9+jr/WAKmAJc/2EFoBF/soA=; b=LhZSA/1Zr/YW5DPMRKeA/e12bDdC8mSMmzANgbJvgPnAFSET+h8q7NNvZLbeWzQTWK ge5Jsu5N7xT0xPbT9sgjEg6ohjALEBacbGsliOW9+flBwAUe7bnDb9QrBX4q8EWEe0bm e2l2jmWufqlPjt/i/4goRPzNPa5DAmcXuxAORBg4Qi3k2BAI1P8Cl+b5VCT5XAvl6mZE Aveb1Ilhf6rHmHc6wu/rPwyvijWDcV3DVM6PhI/QftpXW/9PSIOGrXGLb2GrsttCfmYa Ist701EqRWc17FknoRHc8fvftHkERh7iYGPonKh24BCibSXhwNGPta9NYP2/H/jf+5z1 zjVg== 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=yfin+no+we0MJGBZlEaS9+jr/WAKmAJc/2EFoBF/soA=; b=gGdJ5mLTMLR0Bxe040IbSOSR0y0VaQOZSGi8WP/ZtbxE29ABMCfcbuwXamy7zSi9bG h0VJy7iu9eiVh034PlH3grrMhCV8ernMN7X4KXOgt+E9D0FADYmGvtpo6yxJ6/RCC3Xh sWe7HzPEl8rx62ZgJ9aG9Dec49B4tObIoNeeQqYIpDnwNcda99lu2/jX8EvN9xLLXI4K 3ZR5TPii66R7mJFxXlyUsTUeKJGlZOBf7NHABGVB5MGlJMpL5ozttkf6wRfIrjcdzKGW X8NuHjO6bhiC9yufScZT+sFvPLKncoHYnovm3WL5wTVNi5BUqp+9fifbZYii7EPxO2AA BnXA== X-Gm-Message-State: APjAAAWuomOaFRPj1bKBvX/rMsgfn1hrtvkOT+N50n63JsrT18PuM88A KPKzHuNQImVbzsy+/9ULA9iDl8UkMJiE6WOzgsE6yQ== X-Google-Smtp-Source: APXvYqyWTfQoWHbJQkESRoul8nV+Yiz9evB3cvCUiCXO+fqDgFDJomrpb1SpoTshIbwr5HxxXt/EFwGQ092ck+Yl9RA= X-Received: by 2002:a2e:9750:: with SMTP id f16mr16565250ljj.239.1569942150748; Tue, 01 Oct 2019 08:02:30 -0700 (PDT) MIME-Version: 1.0 References: <20191001104718.8626261.12105.36904@blackberry.com> <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> In-Reply-To: <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> From: Eric Rescorla Date: Tue, 1 Oct 2019 08:01:54 -0700 Message-ID: To: John Mattsson Cc: Dan Brown , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000036ae670593daa4bf" Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 15:02:37 -0000 --00000000000036ae670593daa4bf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2019 at 5:27 AM John Mattsson wrote: > Dan Brown wrote: > > > ANSI X9.62-2005 was withdrawn in 2015 > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > behind a paywall is even worse. > Ugh. > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of > ECDSA > > That NIST FIPS 186-5 will include all the details needed to implement > ECDSA is great. > > >IETF has specs for sigs and their formats already, no? > > At the time when RFC 8446 was published, there was probably no quick and > easy solution to the problem. But the fact that IETF has historically bee= n > fine with relying on specifications behind paywalls is part of the proble= m. > If IETF had implemented a strong open-access policy a long-time ago, ther= e > would probably be an open-access version of ECDSA (NIST or IETF) a long > time ago.. > I agree with you about the policy here. To be honest, I just didn't notice this; and it would probably need some github spelunking to figure out the history of these references. If someone wanted to propose an erratum that would fix this, I would be very appreciative. -Ekr > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: Dan Brown > Date: Tuesday, 1 October 2019 at 12:47 > To: John Mattsson , Peter Gutmann < > pgut001@cs.auckland.ac.nz>, Hubert Kario , " > TLS@ietf.org" > Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erratum= ? > > Re ECDSA specs and paywells: > ANSI X9.62-2005 was withdrawn in 2015, expiring automatically after 1= 0 > years, despite my weak effort. > A revival, ANSI X9.142, with almost the same content is under way, > though even its fate is unsure. > Also, I expect FIPS 186-5 is nearly ready, and will specify much of > ECDSA and EdDSA (not ASN.1?), which many may like (even better than ANSI)= . > Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortunately or > not, despite my weak effort. > IETF has specs for sigs and their formats already, no? > Then there's ISO, IEEE, ... > > > Original Message > From: John Mattsson > Sent: Tuesday, October 1, 2019 5:25 AM > To: Peter Gutmann; Hubert Kario; TLS@ietf.org > Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erra= tum? > > Hubert Kario wrote: > > > Now, I don't have access to X9.62-2005, but there's a possibility o= f > confusion. > > I think references to specifications behind paywalls and other types > of limited access is a major problem. Not only for the standardization > process, but also for researchers and implementors. In general, I think > people should be able to implement and analyze IETF standards without > having to pay for access. > > Open-access is even more important for security specifications. ANSI > X.62 is hopefully quite well-studied, but for other references, the lack = of > analysis often leads to mistakes and unknown weaknesses. > > I would like the IETF to take a much stronger stance against normativ= e > references to paywalls. > > Cheers, > John > > _______________________________________________ > TLS mailing list > TLS@ietf.org > > https://protect2.fireeye.com/url?k=3D749c6dba-280e60e6-749c2d21-0cc47ad93= d46-3da924ab2cfe57e8&q=3D1&u=3Dhttps%3A%2F%2Furldefense.proofpoint.com%2Fv2= %2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_tls%26d%3DDwICAg%26c%3= DyzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE%26r%3DqkpbVDRj7zlSRVql-UonsW64= 7lYqnsrbXizKI6MgkEw%26m%3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I%26s%3= Dp2p9Y_hh-jb_qBNaNqTbSTYE2tAuJo-BaKDbemFVLxU%26e%3D > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000036ae670593daa4bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 1, 2019 at 5:27 AM John M= attsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:
Dan Brown <danibrown@blackberry.com> wrote:
> ANSI X9.62-2005 was withdrawn in 2015

Ok, that TLS 1.3 is relying on a withdrawn publication that used to be behi= nd a paywall is even worse.

Ugh.
=

=C2=A0
> Also, I expect FIPS 186-5 is nearly ready, and will specify much of EC= DSA

That NIST FIPS 186-5 will include all the details needed to implement ECDSA= is great.

>IETF has specs for sigs and their formats already, no?

At the time when RFC 8446 was published, there was probably no quick and ea= sy solution to the problem. But the fact that IETF has historically been fi= ne with relying on specifications behind paywalls is part of the problem. I= f IETF had implemented a strong open-access policy a long-time ago, there w= ould probably be an open-access version of ECDSA (NIST or IETF) a long time= ago..

I agree with you about the polic= y here. To be honest, I just didn't notice this; and it would probably = need some github spelunking to figure out the history of these references.<= /div>

If someone wanted to propose an erratum that would= fix this, I would be very appreciative.

-Ekr<= /div>


Cheers,
John

=EF=BB=BF-----Original Message-----
From: Dan Brown <danibrown@blackberry.com>
Date: Tuesday, 1 October 2019 at 12:47
To: John Mattsson <john.mattsson@ericsson.com>, Peter Gutmann <pgut001@cs.auckland= .ac.nz>, Hubert Kario <hkario@redhat.com>, "TLS@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS]=C2=A0 Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erra= tum?

=C2=A0 =C2=A0 Re ECDSA specs and paywells:
=C2=A0 =C2=A0 ANSI X9.62-2005 was withdrawn in 2015, expiring automatically= after 10 years, despite my weak effort.
=C2=A0 =C2=A0 A revival, ANSI X9.142, with almost the same content is under= way, though even its fate is unsure.
=C2=A0 =C2=A0 Also, I expect FIPS 186-5 is nearly ready, and will specify m= uch of ECDSA and EdDSA (not ASN.1?), which many may like (even better than = ANSI).
=C2=A0 =C2=A0 Meanwhile, SEC1, versions 1.0 and 2.0, are available, fortuna= tely or not, despite my weak effort.
=C2=A0 =C2=A0 IETF has specs for sigs and their formats already, no?
=C2=A0 =C2=A0 Then there's ISO, IEEE, ...


=C2=A0 =C2=A0 =C2=A0 Original Message=C2=A0
=C2=A0 =C2=A0 From: John Mattsson
=C2=A0 =C2=A0 Sent: Tuesday, October 1, 2019 5:25 AM
=C2=A0 =C2=A0 To: Peter Gutmann; Hubert Kario; TLS@ietf.org
=C2=A0 =C2=A0 Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need = for erratum?

=C2=A0 =C2=A0 Hubert Kario <hkario@redhat.com> wrote:

=C2=A0 =C2=A0 > Now, I don't have access to X9.62-2005, but there= 9;s a possibility of confusion.

=C2=A0 =C2=A0 I think references to specifications behind paywalls and othe= r types of limited access is a major problem. Not only for the standardizat= ion process, but also for researchers and implementors. In general, I think= people should be able to implement and analyze IETF standards without havi= ng to pay for access.

=C2=A0 =C2=A0 Open-access is even more important for security specification= s. ANSI X.62 is hopefully quite well-studied, but for other references, the= lack of analysis often leads to mistakes and unknown weaknesses.

=C2=A0 =C2=A0 I would like the IETF to take a much stronger stance against = normative references to paywalls.

=C2=A0 =C2=A0 Cheers,
=C2=A0 =C2=A0 John

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 TLS@ietf.or= g
=C2=A0 =C2=A0 https://protect2.fireeye.com/= url?k=3D749c6dba-280e60e6-749c2d21-0cc47ad93d46-3da924ab2cfe57e8&q=3D1&= amp;u=3Dhttps%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__= www.ietf.org_mailman_listinfo_tls%26d%3DDwICAg%26c%3DyzoHOc_ZK-sxl-kfGNSEvl= JYanssXN3q-lhj0sp26wE%26r%3DqkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw%26m= %3DA-9JTBh7dU_hCbOrrx-iACEmGPbjipnEohllYGLju6I%26s%3Dp2p9Y_hh-jb_qBNaNqTbST= YE2tAuJo-BaKDbemFVLxU%26e%3D


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000036ae670593daa4bf-- From nobody Tue Oct 1 09:15:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B8E120A41 for ; Tue, 1 Oct 2019 09:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 wvyffCEdJM4z for ; Tue, 1 Oct 2019 09:15:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9AC120A1D for ; Tue, 1 Oct 2019 09:15:38 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22EDCC010C19; Tue, 1 Oct 2019 16:15:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53C22614C3; Tue, 1 Oct 2019 16:15:37 +0000 (UTC) From: Hubert Kario To: Christopher Wood Cc: "TLS@ietf.org" Date: Tue, 01 Oct 2019 18:15:31 +0200 Message-ID: <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> In-Reply-To: <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2099791.1yBVDje6zj"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Tue, 01 Oct 2019 16:15:38 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 16:15:42 -0000 --nextPart2099791.1yBVDje6zj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > ``` > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > ``` > > > >=20 > > > > per what? session? at a time? connection? > > >=20 > > > This is all per session. We can state it explicitly in the next versi= on. > >=20 > > so this count needs to be kept as part of session and impacts connectio= ns > > that perform resumption? >=20 > Sorry, I meant connection: >=20 > "Clients may indicate to servers their desired number of tickets for *a > single connection* via the following "ticket_request" extension" >=20 > This is a simple hint for servers. Nothing more. No state needs to be sto= red > past connection establishment. sounds good > > > > what's the expected behaviour with tickets and post-handshake > > > > authentication? Are tickets sent after PHA also bound by this limit? > > >=20 > > > As mentioned earlier, there is no effect, so we left it out. We're ha= ppy > > > to > > > accept text should you think it's needed. > >=20 > > If the I-D states that servers should not send more tickets than the > > client > > asked for, and then send exactly that amount, then they won't be able to > > send new tickets after PHA and remain compliant. > >=20 > > Yes, it's completely up to the server to decide if to send tickets after > > PHA or not, and I'm not suggesting that the client should request for > > tickets in one of its PHA messages, much less expect or require them, b= ut > > sending tickets after PHA is reasonable and explicitly stated behaviour: > >=20 > > RFC 8446 Section 4.6.1: > > For instance, the server might send a new > > ticket after post-handshake authentication in order to encapsulate > > the additional client authentication state. > >=20 > > so the I-D should explicitly state what's the expected behaviour in that > > case. > >=20 > > IMHO, the extension should be used for the tickets sent right after the > > handshake, it should not put an upper bound for the tickets that a serv= er > > can send in a single connection. For a very long lived connection > > (especially if the connection uses KeyUpdate messages regularly), the > > initial tickets may expire. Server may notice that and send a new group > > of tickets then. > Since these hints are not mandatory to honor I don't think we need to > describe this case. In particular, this is a valid case where ignoring the > SHOULD is fine, in my opinion. >=20 > If the draft required that servers MUST NOT send more tickets than what's > requested, then yes, I think these details would be important. huh? I see the following in the draft-02: Servers MUST NOT send more than 255 tickets to clients. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2099791.1yBVDje6zj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2Te6MACgkQkqjRuAHS 9fU4tA/8CG67khXKU4W8a/dMG9mig1nXb1xEJrdfCkjRjhtotRDKC/wa8JhlvdpY gXnhyIrbzLx23dn43WG/TDC+yCuWPTtigD673p7a60K2v9/zTxkCIG1Z3RGYU8gl tKZ0sO0pUZePWy58VlibwRKYEDVLt7/pQciOIDPH9TfiLgdgHfYI9AWo9OUZeujl xpme5MU0XprCJK2SjUEzxsxVwjgBpy3+LBX72m1tAF+0w/BlImWP3MBuaYGCkBZp lOwghubkVk8NrYhkOOMnXg2VpfWnGM2Q8aX5jKbKc1o2lfJ2IrIQtNDfW5l04tQK 64ehn+yBF1zLFG69+6Oh7LOwAnL1MViEcJBAwlAZrWdRDBSZ6gYgVcM7Nlv2beZj V+IhPUDW2Tyzc8N9dlBKruAMZbEoqMFO0FHWSxBJvgq+x7KMbfUJeHtiXqbnnk3s PG6xH3vPq72ZPkdhPLHqPz3gE4zYB5N4LL3YUlAtVkICrSKWWkzGGi2w2snv+S8X FeoSsujRjEF5p2UdsNONBZ0RRtFCwABR/aNpDIw+9AS0D1e7KoYv2yQwkOVYYzQj F7p/SGbThj1bUgIIa5PyCF0D32K7SIR/X5hlQDOK57CjDrQffEqybeij3kuJ2DR/ 9Z/xBIn40khiXHg4niCkdKjv280bg/hFUibA/DqLOjVMsRujQms= =YisF -----END PGP SIGNATURE----- --nextPart2099791.1yBVDje6zj-- From nobody Tue Oct 1 10:06:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B00E120AC5 for ; Tue, 1 Oct 2019 10:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 QrPOXRNYRhUw for ; Tue, 1 Oct 2019 10:06:38 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B0D120A8A for ; Tue, 1 Oct 2019 10:06:05 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 5C45F2A5CD1; Tue, 1 Oct 2019 13:06:03 -0400 (EDT) Date: Tue, 1 Oct 2019 13:06:03 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191001170603.GX21772@straasha.imrryr.org> Reply-To: tls@ietf.org References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191001145600.GU21772@straasha.imrryr.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 17:06:46 -0000 On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > I've read the draft, it looks quite useful and reasonable. It would > be good to see this published. > > I have one idea (implemented in OpenSSL 1.1.1 on the server side) > that may be worth mentioning in this context (and perhaps even the > draft): > > - By default, OpenSSL TLS 1.3 servers only vend multiple (two) > tickets on full handshakes. Resumed sessions issue just one > ticket. Thinking about this some more a related issue comes to mind. A client with (what it believes to still be) a valid reusable ticket may want to tell the server that does not *need* a new ticket, ... But, this should not preclude the server from issuing an updated ticket when the presented ticket has expired (necessitating a full handshake) or will soon expire and should be replaced. For example: The Postfix SMTP server maintains a sliding window of two STEKs, one for encrypting/decrypting new session tickets, and another just for decrypting older tickets. A fresh STEK is created once an hour (by default), and the current active STEK becomes the old STEK. When a client presents a ticket encrypting with the current STEK, no replacement ticket is issued, but when a client presents a ticket encrypted with the old STEK, a replacement ticket is issued under the fresh STEK. A server that has a similar STEK rotation approach should be able to conditionally refresh a client's ticket that is stale, while otherwise honouring the client's signal that it does not need more tickets at present. Therefore, there is I think a need for two separate "no new tickets required" signals. A. The client has no intention to perform (further?) resumptions, No tickets at all required. B. The client is happy to keep using the current ticket so long as it is still fresh, but would like periodic refresh if the ticket gets stale from the server's perspective. i. If the presented ticket is expired or stale and a new one is needed, the server is asked to return just one ticket. ii. If the ticket is fresh, return no tickets. Therefore, it would be useful for the extension to distinguish between these two use-cases, perhaps an optional flags field, with use-case B indicated via one of the flag bits? -- Viktor. From nobody Tue Oct 1 10:19:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00DF120971; Tue, 1 Oct 2019 10:19:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 p43tQAVDzWXs; Tue, 1 Oct 2019 10:19:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119251209C1; Tue, 1 Oct 2019 10:19:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9E9733897A; Tue, 1 Oct 2019 13:17:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AFDF5D9A; Tue, 1 Oct 2019 13:19:37 -0400 (EDT) From: Michael Richardson To: "TLS\@ietf.org" , "saag\@ietf.org" In-Reply-To: References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [TLS] [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 17:19:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Mattsson wrote: >> NIST has pushed back their date for US government organizations to >> have a plan to support TLSv1.3, what=E2=80=99s the driver to get ahe= ad of that? > NIST SP 800-52 rev 2 requires support for TLS 1.3 by January 1, 2024.= I > think that is a good and ambitious plan. In fact it would be very good > if IETF agreed on the same requirement. I guess this is on outward facing web sites. Does it say which cipher suites are required, and certificate chains are re= quired? (TLS 1.3 with RSA-1024+SHA1 certificates would be dumb) Does it say that *only* TLS 1.3 is to be supported? Does it say anything about outgoing connections supporting APIs and the lik= e? > Yes, I think there is at least two things IETF can do: > - The first thing is to do like NIST and already now give implementors > a date when support for TLS 1.3 is required. But, it's so incredibly context sensitive. > - The second thing is to do like 3GPP and mandate support for TLS 1.3 > in new implementations and deployments. But, the IETF doesn't really write requirements like this. > This would avoid two thing that happened in the past. First, IETF > published RFC 8261 that mandated support for DTLS 1.0 and not DTLS 1.2 > almost 6 years after RFC 6347 made DTLS 1.0 obsolete. Secondly, just 7 > months after publishing a draft relying on DTLS 1.0, IETF started > working on a draft forbidding it=E2=80=99s use. Deprecating it from new work is not the same as removing it from implementations. My question above about *only* has to do with the knock-on effect. Entity XYZ keeps 1.2 (or 1.1) available because API FOO is used by entity BAR, which can not upgrade to 1.3 today. Entity BAR never experiences pain, never upgrades, and nobody is sure when/if they can turn off 1.2. This is a bit of a variation of the "Postel principal is bad" situation. One thing that entities like NIST could require is that compliant organizations report, in the years leading up to 2024, and after, to log and report the proportion of TLS version that connect. How can the IETF help? *An IETF standard for logging TLS connection parameters would help here* =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2TiqkACgkQgItw+93Q 3WWP4wf/add7tJC9mJUF5IxUZ8GKwlHVejuVSFyFlpwfWvKm4dTWRUiqUwRu5bD3 QP6LGJrkD5i8njt2sykwX/frcSDrg3iInTWXVkAAdmzJ/vyCPixcoB6exiqx5Pxn nr4QsYirWhtV49pFygiNwToD5NE3OHi//oiCgspAMFCqeQ4bq41v2ONzMvzwXm2F xsoOajuBzWekR9TP7AtCHR9Z2vE0uxeQwBwi4VYgGoBPLuTax8F2g1LHfArKsDV1 /dWlMKoCCilslGBqNPtfWpzkkOZGHYBri2V1pvaNME+y6vv54dtnuOy9bUq2BFD+ eXRe7boOu3H/cTsq7tkWx7RMmHEF+Q== =JR/G -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 1 10:26:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F46120908 for ; Tue, 1 Oct 2019 10:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=mNtepacM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K6oEaMFY Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC4JYtexZhBO for ; Tue, 1 Oct 2019 10:26:54 -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 DE17012096D for ; Tue, 1 Oct 2019 10:26:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 09694214CE; Tue, 1 Oct 2019 13:26:53 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 01 Oct 2019 13:26:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=8k MQwB7wxlNlusVIWgwSqO3e6ciEI3jvKB6I7FICXm0=; b=mNtepacMDAi8C3tv5u /jJxafZ5FL1z/NhPDFz2UhMWp8d9zbp2PD7FPoDPAO0Oq/EqFwce+IzzJINEtDtR DNBgVDi4FprzXf+9bXkp5uGbbmS/LUrsyUc6kuxMHm5CFI62LVJI83YjCTJoNgrb v6402RRlfJZZOrisP2+tQ3tNDizE6qylwwOPOXBdsCRtETKI5/7dkQ39WVuSIfV2 53uBzOQgIJsRkfLJketHE98Xdp9hB8eS93Nsg8D4zf4X5TtaEZwhhojuZvnKrK/v 1XH80pkOwlt7hp53arRw/ReZy1ja8/P98PujjTvstxOMQ7Ikl30drYNaZM0ybux8 26Pw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=8kMQwB7wxlNlusVIWgwSqO3e6ciEI3jvKB6I7FICX m0=; b=K6oEaMFYtG9slEPLOYiWIYTapwqK0watCCLQq6+42X2qCEgZacewhWe54 4WpxtthPcrk5qbQ/UoqBxJyk6wpqn8ZVj8a3fTuEbyOUuTQqA86w787bWBCfxhE/ 9n9pVQCNBufUfS4bzo/d2z9Z/zaXkgcK2gWYZB3sDin3bKym2DClNc31cZDgfSWa U/dchZ9LssYaszm5n0snrluHLHVg3z0wv8EDrh/8cN0S0LSTrc8tpA/uT9STjR8e y1Ih3MqoiX6haifNMBo79Rc9LwJmxR1fqAJ57JAuoRp8fN3NDF1ag4biE2GRo/en 2adu6CjhVvcra38613YdYdfScxEyg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeggdduudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucffohhmrghinheprhgvughhrghtrdgtohhmnecurfgrrhgrmhepmhgrihhlfhhr ohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 905A13C00A1; Tue, 1 Oct 2019 13:26:52 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-334-g7f5110b-fmstable-20191001v2 Mime-Version: 1.0 Message-Id: <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> In-Reply-To: <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> Date: Tue, 01 Oct 2019 10:26:32 -0700 From: "Christopher Wood" To: "Hubert Kario" Cc: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2019 17:26:57 -0000 On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > ``` > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > ``` > > > > >=20 > > > > > per what? session? at a time? connection? > > > >=20 > > > > This is all per session. We can state it explicitly in the next = version. > > >=20 > > > so this count needs to be kept as part of session and impacts conn= ections > > > that perform resumption? > >=20 > > Sorry, I meant connection: > >=20 > > "Clients may indicate to servers their desired number of tickets = for *a > > single connection* via the following "ticket_request" extension" > >=20 > > This is a simple hint for servers. Nothing more. No state needs to b= e stored > > past connection establishment. >=20 > sounds good >=20 > > > > > what's the expected behaviour with tickets and post-handshake > > > > > authentication? Are tickets sent after PHA also bound by this = limit? > > > >=20 > > > > As mentioned earlier, there is no effect, so we left it out. We'= re happy > > > > to > > > > accept text should you think it's needed. > > >=20 > > > If the I-D states that servers should not send more tickets than t= he > > > client > > > asked for, and then send exactly that amount, then they won't be a= ble to > > > send new tickets after PHA and remain compliant. > > >=20 > > > Yes, it's completely up to the server to decide if to send tickets= after > > > PHA or not, and I'm not suggesting that the client should request = for > > > tickets in one of its PHA messages, much less expect or require th= em, but > > > sending tickets after PHA is reasonable and explicitly stated beha= viour: > > >=20 > > > RFC 8446 Section 4.6.1: > > > For instance, the server might send a new > > > ticket after post-handshake authentication in order to encapsul= ate > > > the additional client authentication state. > > >=20 > > > so the I-D should explicitly state what's the expected behaviour i= n that > > > case. > > >=20 > > > IMHO, the extension should be used for the tickets sent right afte= r the > > > handshake, it should not put an upper bound for the tickets that a= server > > > can send in a single connection. For a very long lived connection > > > (especially if the connection uses KeyUpdate messages regularly), = the > > > initial tickets may expire. Server may notice that and send a new = group > > > of tickets then. > > Since these hints are not mandatory to honor I don't think we need t= o > > describe this case. In particular, this is a valid case where ignori= ng the > > SHOULD is fine, in my opinion. > >=20 > > If the draft required that servers MUST NOT send more tickets than w= hat's > > requested, then yes, I think these details would be important. >=20 > huh? I see the following in the draft-02: >=20 > Servers MUST NOT > send more than 255 tickets to clients. I was referring to the "SHOULD NOT send more than TicketRequestContents.= count NewSessionTicket messages" blurb. Indeed, the MUST NOT above shoul= d also be a SHOULD NOT. Thanks for your patience in working through the = kinks! >=20 >=20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic= > Attachments: > * signature.asc From nobody Tue Oct 1 13:15:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6CB120840 for ; Tue, 1 Oct 2019 13:15: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 7sg8M6P2unRs for ; Tue, 1 Oct 2019 13:15:14 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDE312011E for ; Tue, 1 Oct 2019 13:15:14 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id m7so14780431lji.2 for ; Tue, 01 Oct 2019 13:15:14 -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=5JVbhjevp6+iC9By7gmKcZr0JX5tH/T+avWn6EHleng=; b=Tavpv2EwrjP5cff2UlK7mAmZ0375wmGax6xeuwPOd0BKLLoc06e1vrfWjFzM1fOX/v fmqA8kyAWEAKHrEWMFY16d70OnKC4g5I7I6YFc+FHKy6EWvyog7BzfdNJHtMurOm3DAB jH5Sy7hoxcw/cPDou4n+cotism2y4C4bk+NK7L6DELZGkBUMl/4FqWdL5DtzAO5KM+bu 8AqewS2o0Cyh+PTIMUpXeKJM0TAt/O3tZ9sfCofLkn8sSajGP5tGVB3aZnJ73/9+mDe7 55xhR7uhEsKqAegxRSV/sE5yP00GXK8ZKI6//xeYUMgcRfO12L0t5JbcfwHY6tIwXXkC xgOw== 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=5JVbhjevp6+iC9By7gmKcZr0JX5tH/T+avWn6EHleng=; b=Oghldn10iz/acM7vjzhFdMUBCY6319ebCG5pJSCRzHPLwWqjxtUpCwztVoowAPN198 NIgqk5FYs/Eg6ClTTV/pcHHd1RAbWxJVOFmAt67OHXwJs18Tmu6I4kM3NfE8b/KUXcjV 6fJRPct7/rf2J8ZtmRqTCT/7aT/XgHBx6ns+JQ8bXKr4Zt0lPJUsFntPiYmO3ZKID4WN egqiK95jWbDZSDMXFI7mDqVwfIEUQ2h5zQI40GL0R7JnPcO+OqwdIk8iS0w03eEPHaJA VXgD4AtQ/feeP8Nakzxu8nmnTYtRY5jLwKN2HVUFVF/h5EOkWkOFz3lqP6UfEpEMNmWB KS0Q== X-Gm-Message-State: APjAAAWdQGBFKXcvTVenKRHszNspLzIWq16XelUl8pdBDINoNSK8h1cZ 9AFrvTXMB3cYxxC6fLTt8oCxZ99t052zwFPcX5XIXA== X-Google-Smtp-Source: APXvYqwA3EKHRUkwgL2nNzEmput5ps5a3Fkjm8OMUK+z4eLnUm1qnWFGP8WItBwmdsTUePdwHzNioEdUv2/0tMEvz2g= X-Received: by 2002:a2e:9584:: with SMTP id w4mr17460740ljh.145.1569960912649; Tue, 01 Oct 2019 13:15:12 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> In-Reply-To: <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> From: Eric Rescorla Date: Tue, 1 Oct 2019 13:14:36 -0700 Message-ID: To: John Mattsson Cc: Sean Turner via Datatracker , "kaduk@mit.edu" , "iesg-secretary@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008294700593df0269" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 01 Oct 2019 20:15:18 -0000 --0000000000008294700593df0269 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 1, 2019 at 1:04 AM John Mattsson wrote: > Hi, > > I think draft-ietf-tls-oldversions-deprecate needs to update > draft-ietf-rtcweb-security-arch as well. > > draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support > of DTLS 1.0. > > "Earlier drafts of this specification required DTLS > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > at the time of this writing some implementations do not support DTLS > 1.2; endpoints which support only DTLS 1.2 might encounter > interoperability issues." > > You should check if there are more drafts in the publication process that > needs to be updated. > I don't particularly mind, but this text was actually the result of some pretty extensive discussion and compromising in rtcweb, so it's not just as simple as changing this text. -Ekr > Cheers, > John > > =EF=BB=BF-----Original Message----- > From: TLS on behalf of Sean Turner via Datatracker > > Date: Friday, 28 June 2019 at 15:14 > To: "kaduk@mit.edu" > Cc: "iesg-secretary@ietf.org" , " > tls-chairs@ietf.org" , "TLS@ietf.org" > Subject: [TLS] Publication has been requested for > draft-ietf-tls-oldversions-deprecate-05 > > Sean Turner has requested publication of > draft-ietf-tls-oldversions-deprecate-05 as Best Current Practice on behal= f > of the TLS working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > > _______________________________________________ > 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 > --0000000000008294700593df0269 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 1, 2019 at 1:04 AM John M= attsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org> wrote:
Hi,

I think draft-ietf-tls-oldversions-deprecate needs to update draft-ietf-rtc= web-security-arch as well.

draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about support o= f DTLS 1.0.

=C2=A0 "Earlier drafts of this specification required DTLS
=C2=A0 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and<= br> =C2=A0 at the time of this writing some implementations do not support DTLS=
=C2=A0 1.2; endpoints which support only DTLS 1.2 might encounter
=C2=A0 interoperability issues."

You should check if there are more drafts in the publication process that n= eeds to be updated.

I don't particu= larly mind, but this text was actually the result of some pretty extensive = discussion and compromising in rtcweb, so it's not just as simple as ch= anging this text.

-Ekr


Cheers,
John

=EF=BB=BF-----Original Message-----
From: TLS <tls= -bounces@ietf.org> on behalf of Sean Turner via Datatracker <noreply@ietf.org><= br> Date: Friday, 28 June 2019 at 15:14
To: "kaduk@mit.edu<= /a>" <kaduk@mit.= edu>
Cc: "iesg= -secretary@ietf.org" <iesg-secretary@ietf.org>, "tls-chairs@ietf.org" <= tls-chairs@ietf.or= g>, "TLS@ietf= .org" <tls@ie= tf.org>
Subject: [TLS] Publication has been requested for draft-ietf-tls-oldversion= s-deprecate-05

=C2=A0 =C2=A0 Sean Turner has requested publication of draft-ietf-tls-oldve= rsions-deprecate-05 as Best Current Practice on behalf of the TLS working g= roup.

=C2=A0 =C2=A0 Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-o= ldversions-deprecate/

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 TLS@ietf.or= g
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tls=


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008294700593df0269-- From nobody Tue Oct 1 13:37:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD67E1200C1 for ; Tue, 1 Oct 2019 13:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 7ftYqtrtyrOZ for ; Tue, 1 Oct 2019 13:37:26 -0700 (PDT) Received: from mail-vk1-f179.google.com (mail-vk1-f179.google.com [209.85.221.179]) (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 0B37F12007A for ; Tue, 1 Oct 2019 13:37:26 -0700 (PDT) Received: by mail-vk1-f179.google.com with SMTP id p189so3827342vkf.10 for ; Tue, 01 Oct 2019 13:37:25 -0700 (PDT) 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=LkOH6CJVQUumqCy5uidq36gshbww8/4bR/jkL36xEbQ=; b=RS2+wjdv1UEMrN0d0mjLfMk5IbxF33vrgBgPWSQsjieypOvmpEJReVuiTv2CqeiPwm zylfq5QWvjnvULWyt7ftPTW21ZBeeP6W9nP8jQLd94fLzbyLjyz1XpIjjtLnE4i67+xi 2yrAVjsBnt/LVHamSRD4Hinx8scp3m0z/d2dmhW1P5/oc+0HgJelG2T/7KVCEavWf0Zu 0NOzmQpXNWH7kNasCR7gnJaU3ennpF2pEbz3Hn50kdGcEENJrtudMXecShQ8IXQHvPz9 yA8mHx6k34Uh35Oqm0yeA+0qKqJgoCJaAf7ljwwU3kUnQqBCmDx1sCopPPkp2qUQ1hIn HIxA== X-Gm-Message-State: APjAAAXEq/VD6+LM3v83bacikE+mvrL6M0q9zknLNY2HlDV/KB1iArRC N4cwFYDmDIGe2nW5VmLfnYoR2Gl4bIJBgyzUKc8= X-Google-Smtp-Source: APXvYqwcAU18L6slwJrxnTo+4/fwNZFlYT3k9AeVJ0uFwoyK/aXed3J12eqXNFFJ1X/eNMmMd4MhceQjjQN2feuwJ0A= X-Received: by 2002:a1f:d8c4:: with SMTP id p187mr165476vkg.47.1569962244993; Tue, 01 Oct 2019 13:37:24 -0700 (PDT) MIME-Version: 1.0 References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <4DE775B5-B15B-469F-A50C-3DB5B86AA5D4@ericsson.com> In-Reply-To: From: Daniel Migault Date: Tue, 1 Oct 2019 16:37:13 -0400 Message-ID: To: Kathleen Moriarty Cc: John Mattsson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ec84c30593df512e" Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 20:37:28 -0000 --000000000000ec84c30593df512e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kathleen, On Tue, Oct 1, 2019 at 7:07 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > On Tue, Oct 1, 2019 at 4:00 AM John Mattsson 40ericsson.com@dmarc.ietf.org> wrote: > >> Martin Thomson ; wrote: >> >> >When we release a new version of something, we are sending a message: >> > >> >1. new implementations and deployments MUST include support for newer >> versions >> >2. existing implementations and deployments SHOULD be updated to suppor= t >> newer versions >> >> I agree very much with this summary and I would like to have it publishe= d >> somewhere. Take for example RFC 8261. It was published almost 6 years af= ter >> RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 = and >> not DTLS 1.2. I think this is one of the lessons IETF should learn from = the >> TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in t= he >> future? For an external viewer it must look pretty strange that IETF in = Nov >> 2017 published an RFC relying on DTLS 1.0 and then 7 months later starte= d >> working on a draft forbidding its use.... >> >> I would like to see something like the following statements published: >> >> "New implementations and deployments MUST include support for TLS 1.3" >> > We have this already, I believe in new drafts. > The current wording does not, in my opinion, make the message clear in the current draft. Maybe that is a perception of non native English speaker, but there are probably three sentences that could in my opinion make the message clearer. > > >> "Existing implementations and deployments SHOULD be updated to support >> TLS 1.3" >> "Existing implementations and deployments SHALL support TLS 1.3 by >> January 1, 2024" >> > > Are you proposing a draft to state this? If agreeable, this could be a > quick draft and support for 1.3 is a reasonable request to align with > requirements in industry. I'm not sure if our statement will drive the > date as much as NIST's, but it couldn't hurt and I would be surprised if > there were any objections to this. > > I don't think anything other than an RFC is the right approach, unless > there is an avenue I am not thinking about as having IETF consensus would > be what you'd want for it. > > >> >> >> """The expectation is that TLSv1.2 will continue to be used for many >> >> years alongside TLSv1.3.""" >> > >> >Some people have that expectation, but I think that John is right to >> challenge it. >There remain reasons that people are sticking with 1.2 f= or >> now, but those reasons >are mostly to do with allowing time to flush out >> the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasies. >> >> I agree with Martin, and irrespectively of whether it is true or not, I >> do not see any need to have this sentence in an IETF draft. >> > > As for this sentence, we'll see where the discussion settles out - > removing or altering it. > > Best regards, > Kathleen > >> >> Cheers, >> John >> >> =EF=BB=BF-----Original Message----- >> From: TLS on behalf of Martin Thomson < >> mt@lowentropy.net> >> Date: Friday, 27 September 2019 at 02:03 >> To: "TLS@ietf.org" >> Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation >> >> So I agree with Kathleen's conclusion: not to change the goals of th= e >> current document. But there are changes that I think are necessary (and >> thanks to Daniel and John for highlighting these). >> >> BTW, I've moved this to the TLS working group, because this is an >> active topic there and I don't see anything in my email that SAAG needs = to >> concern itself with. >> >> On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote: >> > My understanding of deprecating of TLS1.0 TLS 1.1 is that: >> > a) new software do not use these versions >> > b) existing software stop supporting these versions. >> >> That differs from my perspective. >> >> When we release a new version of something, we are sending a message= : >> >> 1. new implementations and deployments MUST include support for newe= r >> versions >> 2. existing implementations and deployments SHOULD be updated to >> support newer versions >> >> When we deprecate an old version of something, we are sending a >> message: >> >> 3. only use this old version if you absolutely have to >> 4. you are encouraged to take active measures to remove the need to >> use the old version >> 5. you have our support if you decide not to support this old versio= n >> >> Now, "support" from the IETF is about as meaningful as you think it >> is. And you can s/MUST/really ought to/ and s/SHOULD/may wish to/ >> [RFC6919]. >> >> In browser-land, we've decided to form a coalition when it comes to >> removing TLS 1.0/1.1. 3GPP have obviously got their own support group, >> which seems to be functioning effectively, which is great. >> >> > """The expectation is that TLSv1.2 will continue to be used for >> many >> > years alongside TLSv1.3.""" >> >> Some people have that expectation, but I think that John is right to >> challenge it. There remain reasons that people are sticking with 1.2 fo= r >> now, but those reasons are mostly to do with allowing time to flush out = the >> vestiges of a dependency on some of the TLS 1.2 idiosyncrasies.. >> >> I would advocate for removing this statement and any residue of that >> sentiment from the draft. It's speculation and, even if it were true, i= t >> conveys the wrong message. The only message I would include is that one >> that is further down the document: "Any newer version of TLS is more sec= ure >> than TLSv1.1." >> >> _______________________________________________ >> 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 >> > > > -- > > Best regards, > Kathleen > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000ec84c30593df512e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kathleen,=C2=A0

On Tue, Oct 1, 2019 at = 7:07 AM Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

On Tue, Oct 1, 2019 at 4:00 AM John Mattsson <john.mattsson=3D40ericsson.com@= dmarc.ietf.org> wrote:
Martin Thomson <mt@lowentropy.net>; wrote:

>When we release a new version of something, we are sending a message: >
>1. new implementations and deployments MUST include support for newer v= ersions
>2. existing implementations and deployments SHOULD be updated to suppor= t newer versions

I agree very much with this summary and I would like to have it published s= omewhere. Take for example RFC 8261. It was published almost 6 years after = RFC 6347 made DTLS 1.0 obsolete and still mandated support for DTLS 1.0 and= not DTLS 1.2. I think this is one of the lessons IETF should learn from th= e TLS 1.0 and TLS 1.1 deprecation. How do we stop this from happening in th= e future? For an external viewer it must look pretty strange that IETF in N= ov 2017 published an RFC relying on DTLS 1.0 and then 7 months later starte= d working on a draft forbidding its use....

I would like to see something like the following statements published:

"New implementations and deployments MUST include support for TLS 1.3&= quot;
We have this already, I believe in new drafts.

The current wording does n= ot, in my opinion, make the message clear in the current draft. Maybe that = is a perception of non native English speaker, but there are probably three= sentences that could in my opinion make the message clearer.=C2=A0=C2=A0
=C2=A0
"Existing implementations and deployments SHOULD be updated to support= TLS 1.3"
"Existing implementations and deployments SHALL support TLS 1.3 by Jan= uary 1, 2024"

Are you proposing a = draft to state this?=C2=A0 If agreeable, this could be a quick draft and su= pport for 1.3 is a reasonable request to align with requirements in industr= y.=C2=A0 I'm not sure if our statement will drive the date as much as N= IST's, but it couldn't hurt and I would be surprised if there were = any objections to this.

I don't think anything= other than an RFC is the right approach, unless there is an avenue I am no= t thinking about as having IETF consensus would be what you'd want for = it.
=C2=A0

>> """The expectation is that TLSv1.2 will continue to= be used for many
>> years alongside TLSv1.3."""
>
>Some people have that expectation, but I think that John is right to ch= allenge it.=C2=A0 >There remain reasons that people are sticking with 1.= 2 for now, but those reasons >are mostly to do with allowing time to flu= sh out the vestiges of a dependency on >some of the TLS 1.2 idiosyncrasi= es.

I agree with Martin, and irrespectively of whether it is true or not, I do = not see any need to have this sentence in an IETF draft.
<= div>
As for this sentence, we'll see where the discussion= settles out - removing or altering it.

Best regar= ds,
Kathleen=C2=A0

Cheers,
John

=EF=BB=BF-----Original Message-----
From: TLS <tls= -bounces@ietf.org> on behalf of Martin Thomson <mt@lowentropy.net>
Date: Friday, 27 September 2019 at 02:03
To: "TLS@ietf.org" <tls@ietf.org<= /a>>
Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation

=C2=A0 =C2=A0 So I agree with Kathleen's conclusion: not to change the = goals of the current document.=C2=A0 But there are changes that I think are= necessary (and thanks to Daniel and John for highlighting these).

=C2=A0 =C2=A0 BTW, I've moved this to the TLS working group, because th= is is an active topic there and I don't see anything in my email that S= AAG needs to concern itself with.

=C2=A0 =C2=A0 On Fri, Sep 27, 2019, at 01:00, Daniel Migault wrote:
=C2=A0 =C2=A0 > My understanding of deprecating of TLS1.0 TLS 1.1 is tha= t:
=C2=A0 =C2=A0 > a) new software do not use these versions
=C2=A0 =C2=A0 > b) existing software stop supporting these versions.
=C2=A0 =C2=A0 That differs from my perspective.

=C2=A0 =C2=A0 When we release a new version of something, we are sending a = message:

=C2=A0 =C2=A0 1. new implementations and deployments MUST include support f= or newer versions
=C2=A0 =C2=A0 2. existing implementations and deployments SHOULD be updated= to support newer versions

=C2=A0 =C2=A0 When we deprecate an old version of something, we are sending= a message:

=C2=A0 =C2=A0 3. only use this old version if you absolutely have to
=C2=A0 =C2=A0 4. you are encouraged to take active measures to remove the n= eed to use the old version
=C2=A0 =C2=A0 5. you have our support if you decide not to support this old= version

=C2=A0 =C2=A0 Now, "support" from the IETF is about as meaningful= as you think it is.=C2=A0 And you can s/MUST/really ought to/ and s/SHOULD= /may wish to/ [RFC6919].

=C2=A0 =C2=A0 In browser-land, we've decided to form a coalition when i= t comes to removing TLS 1.0/1.1.=C2=A0 3GPP have obviously got their own su= pport group, which seems to be functioning effectively, which is great.

=C2=A0 =C2=A0 > """The expectation is that TLSv1.2 will c= ontinue to be used for many
=C2=A0 =C2=A0 > years alongside TLSv1.3."""

=C2=A0 =C2=A0 Some people have that expectation, but I think that John is r= ight to challenge it.=C2=A0 There remain reasons that people are sticking w= ith 1.2 for now, but those reasons are mostly to do with allowing time to f= lush out the vestiges of a dependency on some of the TLS 1.2 idiosyncrasies= ..

=C2=A0 =C2=A0 I would advocate for removing this statement and any residue = of that sentiment from the draft.=C2=A0 It's speculation and, even if i= t were true, it conveys the wrong message.=C2=A0 The only message I would i= nclude is that one that is further down the document: "Any newer versi= on of TLS is more secure than TLSv1.1."

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 TLS mailing list
=C2=A0 =C2=A0 TLS@ietf.or= g
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tls=


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


--

Best regards,
Kathleen
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ec84c30593df512e-- From nobody Tue Oct 1 15:15:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B32E12012C for ; Tue, 1 Oct 2019 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBEg3a_aKU0V for ; Tue, 1 Oct 2019 15:15:17 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 E510E120013 for ; Tue, 1 Oct 2019 15:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569968117; x=1601504117; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KM6TB7yOzAnVedfWeGbPkt+Q6vWb6fzUsE/FIMwhCeM=; b=spdWiwuBsbCarLH6opigBur6beQridZT2G+vVjZ5KNOiyIDhFu2O9/m6 IoRsV1t7paAHLnqRM/kbQjjJKxd3wVbfJvVZPCLSd01aHskD7BNbfa4py k1JDF6T05YD91VUW4DyqAOL1dezHinDQCKTBBKBoo7hjE03tZtv/jHP2/ RSrewfitkiTiOD1xyfFAtfe7hzCreEY2F899Lpel/iKkVzUTEa7Cx0Ckl D41SWk/s2yJ7SSb5BId8DF7Kl1bAY4SabdpWnvAopvEn1KM+K9m0RxKPJ YOjznJHxTg3hpWUFmNPN3k3w1LTOuI1OmiS0lqIkHpy3Vw/9gseFJeAa4 Q==; X-IronPort-AV: E=Sophos;i="5.64,572,1559476800"; d="scan'208";a="90124680" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Oct 2019 11:15:14 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 2 Oct 2019 11:15:14 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 2 Oct 2019 11:15:14 +1300 From: Peter Gutmann To: Hubert Kario , Dan Brown CC: "TLS@ietf.org" Thread-Topic: =?Windows-1252?Q?[TLS]__Ecdsa-sig-value_in_TLS_1.3_=96_need_for_erratum?= =?Windows-1252?Q?=3F?= Thread-Index: AQHVd50s+A+0xybJjkysFYO0CbAQRadE5DWAgAF35G8= Date: Tue, 1 Oct 2019 22:15:13 +0000 Message-ID: <1569968112465.6769@cs.auckland.ac.nz> References: <1803994.nvTnDQYtSi@pintsize.usersys.redhat.com> <810C31990B57ED40B2062BA10D43FBF501E44E12@XMB116CNC.rim.net>, <2211799.0F6m8LsVZW@pintsize.usersys.redhat.com> In-Reply-To: <2211799.0F6m8LsVZW@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] =?windows-1252?q?Ecdsa-sig-value_in_TLS_1=2E3_=96_need_for?= =?windows-1252?q?_erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 22:15:19 -0000 Hubert Kario writes:=0A= =0A= >a lax DER parser sounds like an oxymoron to me... :)=0A= =0A= That's why I assumed it was an accident/error. Writing a spec that relies = on=0A= buggy parser implementations in order to work is asking for trouble.=0A= =0A= Peter.=0A= From nobody Tue Oct 1 15:21:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8325C12021C; Tue, 1 Oct 2019 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA-FvH7H1CrQ; Tue, 1 Oct 2019 15:21:01 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 D520312012C; Tue, 1 Oct 2019 15:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569968461; x=1601504461; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=OBwXXTvFGdujNPdEQQhTJo25/wKKhMEDSWkVB9evi8s=; b=AFp1IJYVwNcN9pdLK4fwXzonyldl1xEE4j2sQsQjYFIRM426ChW5RKtm elX7QkhYNcjvAPS6JcMlubludolHAUEmBF8eBDrj8SgeVcmqoR7HHChQ8 nfQJZnaXfCK0HAlPNMwwZdvwQZgvm8kQ8SVElC6ge7O8eDJqcKqKfHqku pKKmA81/qU+E4u7D2rTFsYtXbAGQfCDYTL7LOf2VKqr6LZaEehGXKxUlJ VgK4hyhcPxJBVqWjOtwiU65wKK7qnKwCa8WBEGSUc8qegtbXqJBWSJyEd cOFhKN9w/ywLDoV1/JleAbT7fKXBJUCn38axRwavj5L6A+rKhR5vl+EtE Q==; X-IronPort-AV: E=Sophos;i="5.64,572,1559476800"; d="scan'208";a="90133194" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Oct 2019 11:20:59 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 2 Oct 2019 11:20:58 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 2 Oct 2019 11:20:58 +1300 From: Peter Gutmann To: "hannes.tschofenig@gmx.net" , 'John Mattsson' , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGRuT2dEqLFcbEmEm2g+1AcjWadE9+mAgAFsGw8= Date: Tue, 1 Oct 2019 22:20:57 +0000 Message-ID: <1569968457142.91354@cs.auckland.ac.nz> References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com>, <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> In-Reply-To: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 22:21:03 -0000 hannes.tschofenig@gmx.net writes:=0A= =0A= >IMHO the problem with deprecation is not in the IETF but rather with the d= eployments.=0A= >=0A= >PS: As Kathleen noted TLS 1.2 and DTLS 1.2 are perfectly fine if you follo= w=0A= >RFC 7925/7525.=0A= =0A= Maybe the text could be updated to have one section of text for the web and= =0A= one for everything else, since they're totally, totally different=0A= environments. I was at a meeting last week to discuss upgrade mechanisms f= or=0A= some globally deployed infrastructure and they were looking at a 2-3 year t= ime=0A= window to start the upgrade process, with completion by 2030 at the latest.= =0A= =0A= That's not a typo for 2020, it's 2030.=0A= =0A= So the text needs to acknowledge the two different operating environments, = the=0A= web where you can replace anything you want at a drop of a hat, and the res= t=0A= of the world where it takes serious effort to make the change. Moving from= =0A= TLS 1.0 to TLS 1.2 with EMS/EtM/LTS within ten years, for the non-web world= ,=0A= is a practical goal. Moving to an entirely new protocol in that time frame= =0A= (TLS 1.3) probably isn't going to happen.=0A= =0A= Peter.=0A= From nobody Tue Oct 1 15:41:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688A212012C for ; Tue, 1 Oct 2019 15:41: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] 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 vgRhvKEkDzEG for ; Tue, 1 Oct 2019 15:41:16 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C08A2120100 for ; Tue, 1 Oct 2019 15:41:15 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id m7so15120199lji.2 for ; Tue, 01 Oct 2019 15:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+bzZUzAT9+cRUvQhuXKDtCu+tjvzzDpgF1m8h/TGxXY=; b=AmZg8bzFzYrrqWzvVW5Kpo3IUGTAdC+GQT+aQfh4SPpC3ODKTFRzwnDYSXbZvKd46y icjtxXEaXgvIjrWKYnQWSb4+IuM1zWH8beXudXL/8pmHFyGXXYy3lKRhR1n9ESRqjE38 6ahM8rtRkhK4Va/FkgTa2ZMGiXKyNsxQtQI/thWy4SKu728c0YPCwiUQPjwLsztPZTU8 sW54Zt1Vt2wQsnmsQAiU+8GmAsbs8dAOXe2VaXb+4pR7Elei9J3ucQQ3vH4F+NVCvtGO DYUUUP7Udu6tFZjIiL22BuuWA82j56u1lnDfKWCmOxtRLPdZmDKZ3gOqGjWKWoS4YBWl f37A== 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=+bzZUzAT9+cRUvQhuXKDtCu+tjvzzDpgF1m8h/TGxXY=; b=NuXxxQJaLAqEQr06Aezu00CpnJT6cKXYgW98ov9KGJKaj+oiwAk0TqRmpx0chmz2fA vE9hX7O5O+7vpGZUTZUKY2NftFFyzdZf66oZfCL6ATXzHX+HejB2WRc5P53HljuYptf2 Vg7BC0vLErGSLUtpSvxdvutOMO9JI7wTZwaIzkbVKDbB65Bfw4ITy6VVoOVGG7fanIkW 5sV/hkzbUbN1GHy70LByFCPWCFJxfTeworuuChga8B+PJNFA4q4iYkoRAjo97ySflCP0 gnoeruMZ3ob1Sf9w5V0tzOD3yDH++hHcERm3JXvXM7VH6hYVSvVPt0p9kON6bfOv5qac UOAg== X-Gm-Message-State: APjAAAWKooNFpX/QlrR2AfYakRVMUxueVTTnYLYiEY1yUNVbSd1b/QjS z558QY6i4R9xpafFTT0TNhYYtaua1I4yoXBTU9eX8AjaQE0= X-Google-Smtp-Source: APXvYqxu/1Py7q9LBzLao+UyHpxv1e31tjekKf/aT1FZ12JFNUzeTZGcIzVgGd+yexGxbIdw4/eQbsAHx08JGQi8OBs= X-Received: by 2002:a2e:9750:: with SMTP id f16mr138200ljj.239.1569969673719; Tue, 01 Oct 2019 15:41:13 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Tue, 1 Oct 2019 15:40:37 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000b5e8220593e10cb2" Archived-At: Subject: [TLS] DTLS Key Separation PR X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 22:41:17 -0000 --000000000000b5e8220593e10cb2 Content-Type: text/plain; charset="UTF-8" Hi folks, As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key separation. See: https://github.com/tlswg/dtls13-spec/pull/99 Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13" -Ekr --000000000000b5e8220593e10cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

As discussed in Mo= ntreal, I've prepared a PR to give us DTLS/TLS key separation.

See:

Sadly. we didn't have enough space for "dtls13 &= quot; so I went for "dtls13"

-Ekr
<= div>
--000000000000b5e8220593e10cb2-- From nobody Tue Oct 1 16:32:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5E120132 for ; Tue, 1 Oct 2019 16:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 lXIta-8OcR4U for ; Tue, 1 Oct 2019 16:32:07 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 C5B40120089 for ; Tue, 1 Oct 2019 16:32:06 -0700 (PDT) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Oct 2019 19:32:05 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 1 Oct 2019 19:32:05 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0415.000; Tue, 1 Oct 2019 19:32:04 -0400 From: Dan Brown To: Peter Gutmann , Hubert Kario CC: "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZv?= =?utf-8?Q?r_erratum=3F?= Thread-Index: AdV4sG4BCemH32Neikq2A5/H5+a8Lw== Date: Tue, 1 Oct 2019 23:32:03 +0000 Message-ID: <20191001233202.8626261.18654.36955@blackberry.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============0583069760==" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2019 23:32:09 -0000 --===============0583069760== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Does reading Ecdsa-sig-value need a full DER parser? The new syntax does not rely on a buggy parser, as far as I know. =C2=A0 The biggest bug is in the old syntax, which is not extensible. Use a valid DER parser plus new syntax to accept signatures, and all old sy= ntax signatures will accepted, right??? Is it possible to do better with a non-extensible syntax? The only breakdown is the old syntax parsers receiving the extensions, righ= t? That's the only place a lax parser would help. =C2=A0 Original Message =C2=A0 From: Peter Gutmann Sent: Tuesday, October 1, 2019 6:15 PM To: Hubert Kario; Dan Brown Cc: TLS@ietf.org Subject: Re: [TLS] Ecdsa-sig-value in TLS 1.3 =E2=80=93 need for erratum? Hubert Kario writes: >a lax DER parser sounds like an oxymoron to me... :) That's why I assumed it was an accident/error. Writing a spec that relies on buggy parser implementations in order to work is asking for trouble. Peter. --===============0583069760== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg6QMIIH RDCCBiygAwIBAgIKcjhm+AABAAJMhDANBgkqhkiG9w0BAQsFADBWMRMwEQYKCZImiZPyLGQBGRYD bmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSowKAYDVQQDEyFCbGFja0JlcnJ5IENvcnBvcmF0ZSBJ c3N1aW5nIENBIDEwHhcNMTkwMzE5MDM1MTE4WhcNMjAwMjI2MjIzNjU1WjCBgDETMBEGCgmSJomT 8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTENMAsGA1UECxMEQU1FUjELMAkGA1UECxMC Q0ExFDASBgNVBAsTC01pc3Npc3NhdWdhMQ4wDAYDVQQLEwVVc2VyczESMBAGA1UEAxMJRGFuIEJy b3duMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkNMTd/lq8fjk77f6KlOwNglIotfS bGFfyXroxfD9tYltVP6QuHgfrTO7GmPaUTEEtyqCLgY91Md6DBmT0Wq6NdXxa+IOjLP9aH5I3haf GKYeKpLYgwhXO9vuiEMpTH84kFIvs7FM+NRCfZOB9NCCpQ3aJHjGC6OB2g/FaJi0sHLLj2D5KjbQ 0dAN5vHp2yaaR86+SihIUeUJAem+r4tDFD3xmAwE0oKAMiAdWtK0bx5AJwfiMnQixw+r1WrTS2zy HQ+dMBbhln07ZbG6irGKV59ecMfdFe5q5sb3pAfVoyjCiwT2jiTQbegT7OxsyV1gGXh8j+Uf7RMF L6IEG9eBgwIDAQABo4ID5zCCA+MwDAYDVR0TAQH/BAIwADALBgNVHQ8EBAMCBsAwJwYDVR0lBCAw HgYIKwYBBQUHAwIGCCsGAQUFCAICBggrBgEFBQcDBDBbBgNVHREEVDBShgxQSU46MkMwREI2RTWg KAYKKwYBBAGCNxQCA6AaDBhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb22BGGRhbmlicm93bkBibGFj a2JlcnJ5LmNvbTAdBgNVHQ4EFgQUrbrWl1b9yJwwqTQAIwCtdHIcaowwHwYDVR0jBBgwFoAUGi9L S9sHyUk7idYyCCeingvzD2swggEyBgNVHR8EggEpMIIBJTCCASGgggEdoIIBGYZAaHR0cDovL2Ny bC5yaW0ubmV0L0JsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIwQ0ElMjAxLmNybIaB 1GxkYXA6Ly8vQ049QmxhY2tCZXJyeSUyMENvcnBvcmF0ZSUyMElzc3VpbmclMjBDQSUyMDEsQ049 TUNBMDEwQ05DLENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxD Tj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y2VydGlmaWNhdGVSZXZvY2F0aW9u TGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBAwYIKwYBBQUHAQEE gfYwgfMwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnJpbS5uZXQvb2NzcDCBygYIKwYBBQUHMAKG gb1sZGFwOi8vL0NOPUJsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIwQ0ElMjAxLENO PUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNl cnRpZmljYXRpb25BdXRob3JpdHkwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh7+XS4a5gSSG wYEyg9vyJYLc2AGBAIbM/AOegDICAWQCAQ0wTwYDVR0gAQH/BEUwQzBBBgorBgEEAZtKEwMCMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L0NQUy9DUFN0YXRlbWVudC5odG0wMwYJKwYB BAGCNxUKBCYwJDAKBggrBgEFBQcDAjAKBggrBgEFBQgCAjAKBggrBgEFBQcDBDANBgkqhkiG9w0B AQsFAAOCAQEAoS8FKnl/YLW/XYbvshSD0GGdjzM+vXGXnYMaH+xB8YOqVPZfaPm+MZMX5eE2HgzE ePeH7c6YQBCRNCuTcX7ZtiOuU3L0p1MKaVmNmNVeb3y2bdS1CO4v4DFEk1VDavnarXXoXWYJNPQt MYQ9biVXNds8Cq2TJA3YkU385210cMN3dvus/3/yiIHZqY6GJr6eYQiB2kz3IomkqwMjQSup73c7 bREBgX2wKXfTJBzoH6RNz0gAckkNQbchb3Mv5BXUicCoyMsgM1CKIGqBttGMQNFhVYwyEYOJoCFd F9cAN3H62vgxYohnQkVH4FFKDa8+H/A7ZkKmKsbdiFtfp7+MZjCCB0QwggYsoAMCAQICCnI4ZvgA AQACTIQwDQYJKoZIhvcNAQELBQAwVjETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixk ARkWA3JpbTEqMCgGA1UEAxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUgSXNzdWluZyBDQSAxMB4XDTE5 MDMxOTAzNTExOFoXDTIwMDIyNjIyMzY1NVowgYAxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJ kiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsTAkNBMRQwEgYDVQQLEwtNaXNz aXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBCcm93bjCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAJDTE3f5avH45O+3+ipTsDYJSKLX0mxhX8l66MXw/bWJbVT+kLh4 H60zuxpj2lExBLcqgi4GPdTHegwZk9FqujXV8WviDoyz/Wh+SN4WnximHiqS2IMIVzvb7ohDKUx/ OJBSL7OxTPjUQn2TgfTQgqUN2iR4xgujgdoPxWiYtLByy49g+So20NHQDebx6dsmmkfOvkooSFHl CQHpvq+LQxQ98ZgMBNKCgDIgHVrStG8eQCcH4jJ0IscPq9Vq00ts8h0PnTAW4ZZ9O2Wxuoqxilef XnDH3RXuaubG96QH1aMowosE9o4k0G3oE+zsbMldYBl4fI/lH+0TBS+iBBvXgYMCAwEAAaOCA+cw ggPjMAwGA1UdEwEB/wQCMAAwCwYDVR0PBAQDAgbAMCcGA1UdJQQgMB4GCCsGAQUFBwMCBggrBgEF BQgCAgYIKwYBBQUHAwQwWwYDVR0RBFQwUoYMUElOOjJDMERCNkU1oCgGCisGAQQBgjcUAgOgGgwY ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tgRhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb20wHQYDVR0O BBYEFK261pdW/cicMKk0ACMArXRyHGqMMB8GA1UdIwQYMBaAFBovS0vbB8lJO4nWMggnop4L8w9r MIIBMgYDVR0fBIIBKTCCASUwggEhoIIBHaCCARmGQGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0Jl cnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENBJTIwMS5jcmyGgdRsZGFwOi8vL0NOPUJsYWNr QmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIwQ0ElMjAxLENOPU1DQTAxMENOQyxDTj1DRFAs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE Qz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RD bGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQMGCCsGAQUFBwEBBIH2MIHzMCQGCCsGAQUFBzAB hhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwgcoGCCsGAQUFBzAChoG9bGRhcDovLy9DTj1CbGFj a0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIw S2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERD PWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y aXR5MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIe/l0uGuYEkhsGBMoPb8iWC3NgBgQCGzPwD noAyAgFkAgENME8GA1UdIAEB/wRFMEMwQQYKKwYBBAGbShMDAjAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9DUFMvQ1BTdGF0ZW1lbnQuaHRtMDMGCSsGAQQBgjcVCgQmMCQwCgYIKwYB BQUHAwIwCgYIKwYBBQUIAgIwCgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAKEvBSp5f2C1 v12G77IUg9BhnY8zPr1xl52DGh/sQfGDqlT2X2j5vjGTF+XhNh4MxHj3h+3OmEAQkTQrk3F+2bYj rlNy9KdTCmlZjZjVXm98tm3UtQjuL+AxRJNVQ2r52q116F1mCTT0LTGEPW4lVzXbPAqtkyQN2JFN /OdtdHDDd3b7rP9/8oiB2amOhia+nmEIgdpM9yKJpKsDI0Erqe93O20RAYF9sCl30yQc6B+kTc9I AHJJDUG3IW9zL+QV1InAqMjLIDNQiiBqgbbRjEDRYVWMMhGDiaAhXRfXADdx+tr4MWKIZ0JFR+BR Sg2vPh/wO2ZCpirG3YhbX6e/jGYxggH2MIIB8gIBATBkMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQx EzARBgoJkiaJk/IsZAEZFgNyaW0xKjAoBgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3Vp bmcgQ0EgMQIKcjhm+AABAAJMhDALBglghkgBZQMEAgGgaTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xOTEwMDEyMzMyMDFaMC8GCSqGSIb3DQEJBDEiBCCfz3W80d5s VcfecA97IdWg1w7L6O/FQK7YyxuP3U8CuzALBgkqhkiG9w0BAQEEggEARuTEXR9AY48bMRDMue2q kZJZKlZK2H+Ouq4yqBHB1tNFXccGsvkvJSfWHUzTRaGJ8josGhKoCBN4naNWzcDH4dzRmH99FpAI 7W2UbLIhKtkqB6HoJeMP31hRbRE5LIMTkaMP5uet8s8cJVcknUARPnERhMVZOvjqGe4h4aUboV5J k/9iZHsCEtY407vbseT4HfUIyFmEwW549mEcBmnAgny8XcfDqIYw2OSjwBtjq69KMikv5mgKT955 vdaHiE71jie1O/ycOyaITV6Kw6kkDOZGDhXwxDuCAwlQ0Kt2HYjVTEh2PeeFdRy3+z10MQzdK6cp yXwjQwTbA/FiTtKueAAAAAAAAA== --===============0583069760==-- From nobody Tue Oct 1 22:46:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE56F120077 for ; Tue, 1 Oct 2019 22:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 qeSml_BNJMuT for ; Tue, 1 Oct 2019 22:46:53 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0601.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::601]) (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 1BAB4120041 for ; Tue, 1 Oct 2019 22:46:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fc0Ef4Z+YB8+Nru2ixh4LUQIgo6VKRL8/Feh0HgqxQp4EMnvd0Kdsflkkl/GGgeL+A0XBft18NaT6FtnEZSvgA9vzE6sNf6BrtJQS6OopO6IZrOBAfXXTlJP5cyxsW1Y7jSKlG6mCTnEI3RbRz8T84p9BfX0RUx3XSAMbFU5CBIp79oG+aooxcPY2kOwvnbrNJN814RrfzPfSRkkc2ophjC48UNypMe2xa9VaVwY49WupoNB84PxFRNYsuv3BwWBwkZnkYLM/YBwGBy3sBZV9J72iCYRsUukgt5b4PGOc4h6Yig+59XzWp4rM52NBjw+MYqFD8FMarBSNYtm499hzw== 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=XgIHPFt5oeU89x+9PH5t6e6a9uXeDw/qomhwExAe2lo=; b=YBoXOYfRRHWAU5kVMlrFy3H2/LgUfaGXK17Str3PqRbVnlzHV7ri8uZBPpIabrT5SvYSj1u4jr6ZwG6G+5269m35la6J7B54SW/tj+Wo6+E0ra9WV9EgNd18DPBDry/CfT9FKcOmzT/uCy03bEjcmUPOg6/GGLBAvFCRzUW/Sv2IbDiTQbTq6LFVnt7iu/kWQqEj+KU1D5dczwFKuXq9kOefrmO/5bKtlDbRrobkidSXesXAFVxiqLghySd71m/11qYxlhzlgveyaPvYFB4kAHBjKP2T23J6z/+4lSN13o3u4CedZsm2v5hU7xmbFR0fBV9FzCk9Jl+xqGOAzhawhg== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XgIHPFt5oeU89x+9PH5t6e6a9uXeDw/qomhwExAe2lo=; b=OHni6u9z7HsG+uWFIY+iBhDgT1Bw586dj894sFUa5jOZsO+VAz0XBKu7RE1mAiNdIS+Nq8gFQ6DAV0tT4d1wkXFm7JeyY2XZOwZq3mjoEeIpPe27UXQ3NqtwpTdz1wZhute+XLSOsGsxtbspJf2qx+U2uxWXdjVwwade6K4KOWQ= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4217.eurprd07.prod.outlook.com (20.176.162.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Wed, 2 Oct 2019 05:46:48 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Wed, 2 Oct 2019 05:46:48 +0000 From: John Mattsson To: Eric Rescorla CC: Dan Brown , Peter Gutmann , Hubert Kario , "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gRWNkc2Etc2lnLXZhbHVlIGluIFRMUyAxLjMg4oCTIG5lZWQgZm9y?= =?utf-8?Q?_erratum=3F?= Thread-Index: AQHVeGlJXOoNUpva+EaXYSQQm4v9R6dG+kCA Date: Wed, 2 Oct 2019 05:46:47 +0000 Message-ID: <819C3432-51C1-49A7-AD2C-53E4F7C3D469@ericsson.com> References: <20191001104718.8626261.12105.36904@blackberry.com> <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [90.232.91.179] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e7449abb-f455-44a4-6da2-08d746fbea80 x-ms-traffictypediagnostic: HE1PR07MB4217: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(366004)(346002)(376002)(13464003)(199004)(189003)(44832011)(966005)(14454004)(5660300002)(71190400001)(606006)(6246003)(36756003)(71200400001)(81166006)(99286004)(76176011)(4326008)(7736002)(66066001)(81156014)(54906003)(486006)(6916009)(476003)(6436002)(2906002)(2616005)(53546011)(6506007)(102836004)(186003)(8936002)(478600001)(6116002)(3846002)(33656002)(236005)(6512007)(6306002)(256004)(229853002)(14444005)(11346002)(58126008)(66556008)(26005)(66946007)(66476007)(64756008)(66446008)(86362001)(446003)(76116006)(25786009)(6486002)(54896002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4217; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ha+eN42q84qnLPC7cDrQbP3THdZsDUnjIiMxepmFJXWu4y2j2O1ZdikPUFPOuIn8lf+OvuHMlU1SlnHUklPQa4+6asZXC97aIpCxtRtiM2zjaTozIF5a5655dshhE6gA2iilel2swq3i2XCVgckOiPVBAIJbuzDx28AZpy+WJA7uk00iP9GP2Z2eCRazYUN96WPOXZvMDxJ2+JgIdYLTMe4joRIE0ZrBJR7zNARAonF62cV0kkWhZnZaJx9/VSNfiZLUt50yyH1H4sFjDLR28j0XGi81Bq1Pesak33Pgs0MYa17Z3QMz5r7p4lj0o3OFnekevh5QVMX0v+VgWTclReiw+Jy0W80WUh+NEo0WRwOWzkGPd+IjWn6aHp5/hnwoynbwP931qMeGcWOFEyBEi9L16BkBML3Czdt2TeKtRa9IM600O967/vtqXSGTz/rKe/PyxGkKQ8fFLGcssBganA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_819C343251C149A7AD2C53E4F7C3D469ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e7449abb-f455-44a4-6da2-08d746fbea80 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 05:46:47.6368 (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: pNecY/hYSMVCq4T/wEL1gkqPqD+KXElz3sKr8zp1WjtREbhfCYoHIjalQKf2qnXZJJ8n1k0Iu7AAjhKbJUDU4WJswKCkIwumsV8E40j2NBQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4217 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 05:46:56 -0000 --_000_819C343251C149A7AD2C53E4F7C3D469ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIHBvbGljeSBoZXJlLiBUbyBiZSBob25lc3QsIEkg anVzdCBkaWRuJ3Qgbm90aWNlIHRoaXM7IGFuZCBpdCB3b3VsZCBwcm9iYWJseSBuZWVkIHNvbWUg Z2l0aHViID5zcGVsdW5raW5nIHRvIGZpZ3VyZSBvdXQgdGhlIGhpc3Rvcnkgb2YgdGhlc2UgcmVm ZXJlbmNlcy4NCg0KVGhlIHJlZmVyZW5jZSBjb21lcyBmcm9tIFJGQyA1MjQ2IChUTFMgMS4yKS4g SW4gMjAwOCB0aGUgc3BlY2lmaWNhdGlvbiB3YXMgbm90IHdpdGhkcmF3bi4NCg0KPiBJZiBzb21l b25lIHdhbnRlZCB0byBwcm9wb3NlIGFuIGVycmF0dW0gdGhhdCB3b3VsZCBmaXggdGhpcywgSSB3 b3VsZCBiZSB2ZXJ5IGFwcHJlY2lhdGl2ZS4NCg0KUG9pbnRpbmcgb3V0IHRoZSBwcm9ibGVtIGlz IGVhc3ksIGJ1dCBJIGRvbid0IGtub3cgd2hhdCB0byBwdXQgaW4gIkl0IHNob3VsZCBzYXk6Ii4g UG9pbnRpbmcgdG8gU0VDMSBpcyBub3QgZ29vZCBpZiB0aGF0IGlzIGluY29tcGF0aWJsZSB3aXRo IE5JU1QvQU5TSS4gSVNPIGFuZCBJRUVFIGFyZSBiZWhpbmQgcGF5d2FsbHMuIEF0IHRoaXMgcG9p bnQgaXQgaXMgcHJvYmFibHkgYmVzdCB0byB3YWl0IGZvciBOSVNUIFNQIDE4Ni01IChOSVNUIHNh aWQgZWFybGllciB0aGV5IGhvcGVkIHRvIHJlbGVhc2UgYSBkcmFmdCB2ZXJzaW9uIGJ5IE1heSAy MDE5LCBzbyBJIGFzc3VtZSBpdCB3aWxsIGJlIHJlbGVhc2VkIHZlcnkgc29vbikuDQoNClJGQyA4 NDIyIGlzIGFsc28gcmVmZXJlbmNpbmcgQU5TSSBYOS42Mi0yMDA1IGFuZCB3b3VsZCBuZWVkIGEg c2ltaWxhciBlcnJhdGEuDQoNCkpvaG4NCg0KRnJvbTogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0u Y29tPg0KRGF0ZTogVHVlc2RheSwgMSBPY3RvYmVyIDIwMTkgYXQgMTc6MDINClRvOiBKb2huIE1h dHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkNjOiBEYW4gQnJvd24gPGRhbmli cm93bkBibGFja2JlcnJ5LmNvbT4sIFBldGVyIEd1dG1hbm4gPHBndXQwMDFAY3MuYXVja2xhbmQu YWMubno+LCBIdWJlcnQgS2FyaW8gPGhrYXJpb0ByZWRoYXQuY29tPiwgIlRMU0BpZXRmLm9yZyIg PFRMU0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBFY2RzYS1zaWctdmFsdWUgaW4gVExT IDEuMyDigJMgbmVlZCBmb3IgZXJyYXR1bT8NCg0KDQoNCk9uIFR1ZSwgT2N0IDEsIDIwMTkgYXQg NToyNyBBTSBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uPTQwZXJpY3Nzb24uY29tQGRtYXJj LmlldGYub3JnPG1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0K RGFuIEJyb3duIDxkYW5pYnJvd25AYmxhY2tiZXJyeS5jb208bWFpbHRvOmRhbmlicm93bkBibGFj a2JlcnJ5LmNvbT4+IHdyb3RlOg0KDQo+IEFOU0kgWDkuNjItMjAwNSB3YXMgd2l0aGRyYXduIGlu IDIwMTUNCg0KT2ssIHRoYXQgVExTIDEuMyBpcyByZWx5aW5nIG9uIGEgd2l0aGRyYXduIHB1Ymxp Y2F0aW9uIHRoYXQgdXNlZCB0byBiZSBiZWhpbmQgYSBwYXl3YWxsIGlzIGV2ZW4gd29yc2UuDQoN ClVnaC4NCg0KDQo+IEFsc28sIEkgZXhwZWN0IEZJUFMgMTg2LTUgaXMgbmVhcmx5IHJlYWR5LCBh bmQgd2lsbCBzcGVjaWZ5IG11Y2ggb2YgRUNEU0ENCg0KVGhhdCBOSVNUIEZJUFMgMTg2LTUgd2ls bCBpbmNsdWRlIGFsbCB0aGUgZGV0YWlscyBuZWVkZWQgdG8gaW1wbGVtZW50IEVDRFNBIGlzIGdy ZWF0Lg0KDQo+SUVURiBoYXMgc3BlY3MgZm9yIHNpZ3MgYW5kIHRoZWlyIGZvcm1hdHMgYWxyZWFk eSwgbm8/DQoNCkF0IHRoZSB0aW1lIHdoZW4gUkZDIDg0NDYgd2FzIHB1Ymxpc2hlZCwgdGhlcmUg d2FzIHByb2JhYmx5IG5vIHF1aWNrIGFuZCBlYXN5IHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLiBC dXQgdGhlIGZhY3QgdGhhdCBJRVRGIGhhcyBoaXN0b3JpY2FsbHkgYmVlbiBmaW5lIHdpdGggcmVs eWluZyBvbiBzcGVjaWZpY2F0aW9ucyBiZWhpbmQgcGF5d2FsbHMgaXMgcGFydCBvZiB0aGUgcHJv YmxlbS4gSWYgSUVURiBoYWQgaW1wbGVtZW50ZWQgYSBzdHJvbmcgb3Blbi1hY2Nlc3MgcG9saWN5 IGEgbG9uZy10aW1lIGFnbywgdGhlcmUgd291bGQgcHJvYmFibHkgYmUgYW4gb3Blbi1hY2Nlc3Mg dmVyc2lvbiBvZiBFQ0RTQSAoTklTVCBvciBJRVRGKSBhIGxvbmcgdGltZSBhZ28uLg0KDQpJIGFn cmVlIHdpdGggeW91IGFib3V0IHRoZSBwb2xpY3kgaGVyZS4gVG8gYmUgaG9uZXN0LCBJIGp1c3Qg ZGlkbid0IG5vdGljZSB0aGlzOyBhbmQgaXQgd291bGQgcHJvYmFibHkgbmVlZCBzb21lIGdpdGh1 YiBzcGVsdW5raW5nIHRvIGZpZ3VyZSBvdXQgdGhlIGhpc3Rvcnkgb2YgdGhlc2UgcmVmZXJlbmNl cy4NCg0KSWYgc29tZW9uZSB3YW50ZWQgdG8gcHJvcG9zZSBhbiBlcnJhdHVtIHRoYXQgd291bGQg Zml4IHRoaXMsIEkgd291bGQgYmUgdmVyeSBhcHByZWNpYXRpdmUuDQoNCi1Fa3INCg0KDQpDaGVl cnMsDQpKb2huDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYW4gQnJvd24g PGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTxtYWlsdG86ZGFuaWJyb3duQGJsYWNrYmVycnkuY29t Pj4NCkRhdGU6IFR1ZXNkYXksIDEgT2N0b2JlciAyMDE5IGF0IDEyOjQ3DQpUbzogSm9obiBNYXR0 c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmpvaG4ubWF0dHNzb25AZXJp Y3Nzb24uY29tPj4sIFBldGVyIEd1dG1hbm4gPHBndXQwMDFAY3MuYXVja2xhbmQuLmFjLm56PG1h aWx0bzpwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56Pj4sIEh1YmVydCBLYXJpbyA8aGthcmlvQHJl ZGhhdC5jb208bWFpbHRvOmhrYXJpb0ByZWRoYXQuY29tPj4sICJUTFNAaWV0Zi5vcmc8bWFpbHRv OlRMU0BpZXRmLm9yZz4iIDxUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZvciBl cnJhdHVtPw0KDQogICAgUmUgRUNEU0Egc3BlY3MgYW5kIHBheXdlbGxzOg0KICAgIEFOU0kgWDku NjItMjAwNSB3YXMgd2l0aGRyYXduIGluIDIwMTUsIGV4cGlyaW5nIGF1dG9tYXRpY2FsbHkgYWZ0 ZXIgMTAgeWVhcnMsIGRlc3BpdGUgbXkgd2VhayBlZmZvcnQuDQogICAgQSByZXZpdmFsLCBBTlNJ IFg5LjE0Miwgd2l0aCBhbG1vc3QgdGhlIHNhbWUgY29udGVudCBpcyB1bmRlciB3YXksIHRob3Vn aCBldmVuIGl0cyBmYXRlIGlzIHVuc3VyZS4NCiAgICBBbHNvLCBJIGV4cGVjdCBGSVBTIDE4Ni01 IGlzIG5lYXJseSByZWFkeSwgYW5kIHdpbGwgc3BlY2lmeSBtdWNoIG9mIEVDRFNBIGFuZCBFZERT QSAobm90IEFTTi4xPyksIHdoaWNoIG1hbnkgbWF5IGxpa2UgKGV2ZW4gYmV0dGVyIHRoYW4gQU5T SSkuDQogICAgTWVhbndoaWxlLCBTRUMxLCB2ZXJzaW9ucyAxLjAgYW5kIDIuMCwgYXJlIGF2YWls YWJsZSwgZm9ydHVuYXRlbHkgb3Igbm90LCBkZXNwaXRlIG15IHdlYWsgZWZmb3J0Lg0KICAgIElF VEYgaGFzIHNwZWNzIGZvciBzaWdzIGFuZCB0aGVpciBmb3JtYXRzIGFscmVhZHksIG5vPw0KICAg IFRoZW4gdGhlcmUncyBJU08sIElFRUUsIC4uLg0KDQoNCiAgICAgIE9yaWdpbmFsIE1lc3NhZ2UN CiAgICBGcm9tOiBKb2huIE1hdHRzc29uDQogICAgU2VudDogVHVlc2RheSwgT2N0b2JlciAxLCAy MDE5IDU6MjUgQU0NCiAgICBUbzogUGV0ZXIgR3V0bWFubjsgSHViZXJ0IEthcmlvOyBUTFNAaWV0 Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCiAgICBTdWJqZWN0OiBSZTogW1RMU10gRWNkc2Et c2lnLXZhbHVlIGluIFRMUyAxLjMg4oCTIG5lZWQgZm9yIGVycmF0dW0/DQoNCiAgICBIdWJlcnQg S2FyaW8gPGhrYXJpb0ByZWRoYXQuY29tPG1haWx0bzpoa2FyaW9AcmVkaGF0LmNvbT4+IHdyb3Rl Og0KDQogICAgPiBOb3csIEkgZG9uJ3QgaGF2ZSBhY2Nlc3MgdG8gWDkuNjItMjAwNSwgYnV0IHRo ZXJlJ3MgYSBwb3NzaWJpbGl0eSBvZiBjb25mdXNpb24uDQoNCiAgICBJIHRoaW5rIHJlZmVyZW5j ZXMgdG8gc3BlY2lmaWNhdGlvbnMgYmVoaW5kIHBheXdhbGxzIGFuZCBvdGhlciB0eXBlcyBvZiBs aW1pdGVkIGFjY2VzcyBpcyBhIG1ham9yIHByb2JsZW0uIE5vdCBvbmx5IGZvciB0aGUgc3RhbmRh cmRpemF0aW9uIHByb2Nlc3MsIGJ1dCBhbHNvIGZvciByZXNlYXJjaGVycyBhbmQgaW1wbGVtZW50 b3JzLiBJbiBnZW5lcmFsLCBJIHRoaW5rIHBlb3BsZSBzaG91bGQgYmUgYWJsZSB0byBpbXBsZW1l bnQgYW5kIGFuYWx5emUgSUVURiBzdGFuZGFyZHMgd2l0aG91dCBoYXZpbmcgdG8gcGF5IGZvciBh Y2Nlc3MuDQoNCiAgICBPcGVuLWFjY2VzcyBpcyBldmVuIG1vcmUgaW1wb3J0YW50IGZvciBzZWN1 cml0eSBzcGVjaWZpY2F0aW9ucy4gQU5TSSBYLjYyIGlzIGhvcGVmdWxseSBxdWl0ZSB3ZWxsLXN0 dWRpZWQsIGJ1dCBmb3Igb3RoZXIgcmVmZXJlbmNlcywgdGhlIGxhY2sgb2YgYW5hbHlzaXMgb2Z0 ZW4gbGVhZHMgdG8gbWlzdGFrZXMgYW5kIHVua25vd24gd2Vha25lc3Nlcy4NCg0KICAgIEkgd291 bGQgbGlrZSB0aGUgSUVURiB0byB0YWtlIGEgbXVjaCBzdHJvbmdlciBzdGFuY2UgYWdhaW5zdCBu b3JtYXRpdmUgcmVmZXJlbmNlcyB0byBwYXl3YWxscy4NCg0KICAgIENoZWVycywNCiAgICBKb2hu DQoNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9y Zz4NCiAgICBodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPTc0OWM2ZGJhLTI4MGU2 MGU2LTc0OWMyZDIxLTBjYzQ3YWQ5M2Q0Ni0zZGE5MjRhYjJjZmU1N2U4JnE9MSZ1PWh0dHBzJTNB JTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMlMjZkJTNERHdJQ0FnJTI2YyUzRHl6 b0hPY19aSy1zeGwta2ZHTlNFdmxKWWFuc3NYTjNxLWxoajBzcDI2d0UlMjZyJTNEcWtwYlZEUmo3 emxTUlZxbC1Vb25zVzY0N2xZcW5zcmJYaXpLSTZNZ2tFdyUyNm0lM0RBLTlKVEJoN2RVX2hDYk9y cngtaUFDRW1HUGJqaXBuRW9obGxZR0xqdTZJJTI2cyUzRHAycDlZX2hoLWpiX3FCTmFOcVRiU1RZ RTJ0QXVKby1CYUtEYmVtRlZMeFUlMjZlJTNEDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxt YWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHMNCg== --_000_819C343251C149A7AD2C53E4F7C3D469ericssoncom_ 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 YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtJIGFncmVlIHdpdGggeW91 IGFib3V0IHRoZSBwb2xpY3kgaGVyZS4gVG8gYmUgaG9uZXN0LCBJIGp1c3QgZGlkbid0IG5vdGlj ZSB0aGlzOyBhbmQgaXQgd291bGQgcHJvYmFibHkgbmVlZCBzb21lIGdpdGh1YiAmZ3Q7c3BlbHVu a2luZyB0byBmaWd1cmUgb3V0IHRoZSBoaXN0b3J5IG9mIHRoZXNlIHJlZmVyZW5jZXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHJlZmVyZW5jZSBjb21lcyBmcm9tIFJGQyA1 MjQ2IChUTFMgMS4yKS4gSW4gMjAwOCB0aGUgc3BlY2lmaWNhdGlvbiB3YXMgbm90IHdpdGhkcmF3 bi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZndDsgSWYgc29tZW9uZSB3YW50 ZWQgdG8gcHJvcG9zZSBhbiBlcnJhdHVtIHRoYXQgd291bGQgZml4IHRoaXMsIEkgd291bGQgYmUg dmVyeSBhcHByZWNpYXRpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UG9pbnRp bmcgb3V0IHRoZSBwcm9ibGVtIGlzIGVhc3ksIGJ1dCBJIGRvbid0IGtub3cgd2hhdCB0byBwdXQg aW4gJnF1b3Q7SXQgc2hvdWxkIHNheTomcXVvdDsuIFBvaW50aW5nIHRvIFNFQzEgaXMgbm90IGdv b2QgaWYgdGhhdCBpcyBpbmNvbXBhdGlibGUgd2l0aCBOSVNUL0FOU0kuIElTTyBhbmQgSUVFRSBh cmUgYmVoaW5kIHBheXdhbGxzLg0KIEF0IHRoaXMgcG9pbnQgaXQgaXMgcHJvYmFibHkgYmVzdCB0 byB3YWl0IGZvciBOSVNUIFNQIDE4Ni01IChOSVNUIHNhaWQgZWFybGllciB0aGV5IGhvcGVkIHRv IHJlbGVhc2UgYSBkcmFmdCB2ZXJzaW9uIGJ5IE1heSAyMDE5LCBzbyBJIGFzc3VtZSBpdCB3aWxs IGJlIHJlbGVhc2VkIHZlcnkgc29vbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ UkZDIDg0MjIgaXMgYWxzbyByZWZlcmVuY2luZyBBTlNJIFg5LjYyLTIwMDUgYW5kIHdvdWxkIG5l ZWQgYSBzaW1pbGFyIGVycmF0YS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0u Y29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCAxIE9jdG9iZXIgMjAxOSBhdCAxNzow Mjxicj4NCjxiPlRvOiA8L2I+Sm9obiBNYXR0c3NvbiAmbHQ7am9obi5tYXR0c3NvbkBlcmljc3Nv bi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5EYW4gQnJvd24gJmx0O2Rhbmlicm93bkBibGFja2Jl cnJ5LmNvbSZndDssIFBldGVyIEd1dG1hbm4gJmx0O3BndXQwMDFAY3MuYXVja2xhbmQuYWMubnom Z3Q7LCBIdWJlcnQgS2FyaW8gJmx0O2hrYXJpb0ByZWRoYXQuY29tJmd0OywgJnF1b3Q7VExTQGll dGYub3JnJnF1b3Q7ICZsdDtUTFNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbVExTXSBFY2RzYS1zaWctdmFsdWUgaW4gVExTIDEuMyDigJMgbmVlZCBmb3IgZXJyYXR1bT88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pk9uIFR1ZSwgT2N0IDEsIDIwMTkgYXQgNToyNyBBTSBKb2huIE1hdHRzc29uICZsdDtqb2huLm1h dHRzc29uPTxhIGhyZWY9Im1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkRhbiBCcm93biAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhbmlicm93bkBibGFj a2JlcnJ5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmRhbmlicm93bkBibGFja2JlcnJ5LmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCjxicj4NCiZndDsgQU5TSSBYOS42Mi0yMDA1IHdhcyB3aXRoZHJhd24g aW4gMjAxNTxicj4NCjxicj4NCk9rLCB0aGF0IFRMUyAxLjMgaXMgcmVseWluZyBvbiBhIHdpdGhk cmF3biBwdWJsaWNhdGlvbiB0aGF0IHVzZWQgdG8gYmUgYmVoaW5kIGEgcGF5d2FsbCBpcyBldmVu IHdvcnNlLg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5VZ2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jmd0OyBBbHNvLCBJ IGV4cGVjdCBGSVBTIDE4Ni01IGlzIG5lYXJseSByZWFkeSwgYW5kIHdpbGwgc3BlY2lmeSBtdWNo IG9mIEVDRFNBDQo8YnI+DQo8YnI+DQpUaGF0IE5JU1QgRklQUyAxODYtNSB3aWxsIGluY2x1ZGUg YWxsIHRoZSBkZXRhaWxzIG5lZWRlZCB0byBpbXBsZW1lbnQgRUNEU0EgaXMgZ3JlYXQuDQo8YnI+ DQo8YnI+DQomZ3Q7SUVURiBoYXMgc3BlY3MgZm9yIHNpZ3MgYW5kIHRoZWlyIGZvcm1hdHMgYWxy ZWFkeSwgbm8/PGJyPg0KPGJyPg0KQXQgdGhlIHRpbWUgd2hlbiBSRkMgODQ0NiB3YXMgcHVibGlz aGVkLCB0aGVyZSB3YXMgcHJvYmFibHkgbm8gcXVpY2sgYW5kIGVhc3kgc29sdXRpb24gdG8gdGhl IHByb2JsZW0uIEJ1dCB0aGUgZmFjdCB0aGF0IElFVEYgaGFzIGhpc3RvcmljYWxseSBiZWVuIGZp bmUgd2l0aCByZWx5aW5nIG9uIHNwZWNpZmljYXRpb25zIGJlaGluZCBwYXl3YWxscyBpcyBwYXJ0 IG9mIHRoZSBwcm9ibGVtLiBJZiBJRVRGIGhhZCBpbXBsZW1lbnRlZCBhIHN0cm9uZw0KIG9wZW4t YWNjZXNzIHBvbGljeSBhIGxvbmctdGltZSBhZ28sIHRoZXJlIHdvdWxkIHByb2JhYmx5IGJlIGFu IG9wZW4tYWNjZXNzIHZlcnNpb24gb2YgRUNEU0EgKE5JU1Qgb3IgSUVURikgYSBsb25nIHRpbWUg YWdvLi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPkkgYWdyZWUgd2l0aCB5b3UgYWJvdXQgdGhlIHBvbGljeSBoZXJlLiBUbyBiZSBob25l c3QsIEkganVzdCBkaWRuJ3Qgbm90aWNlIHRoaXM7IGFuZCBpdCB3b3VsZCBwcm9iYWJseSBuZWVk IHNvbWUgZ2l0aHViIHNwZWx1bmtpbmcgdG8gZmlndXJlIG91dCB0aGUgaGlzdG9yeSBvZiB0aGVz ZSByZWZlcmVuY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5JZiBzb21lb25lIHdhbnRlZCB0byBwcm9wb3NlIGFuIGVycmF0dW0gdGhhdCB3b3Vs ZCBmaXggdGhpcywgSSB3b3VsZCBiZSB2ZXJ5IGFwcHJlY2lhdGl2ZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQpDaGVlcnMsPGJy Pg0KSm9objxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTog RGFuIEJyb3duICZsdDs8YSBocmVmPSJtYWlsdG86ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tPC9hPiZndDs8YnI+DQpEYXRl OiBUdWVzZGF5LCAxIE9jdG9iZXIgMjAxOSBhdCAxMjo0Nzxicj4NClRvOiBKb2huIE1hdHRzc29u ICZsdDs8YSBocmVmPSJtYWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20iIHRhcmdldD0i X2JsYW5rIj5qb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCBQZXRlciBHdXRtYW5u ICZsdDs8YSBocmVmPSJtYWlsdG86cGd1dDAwMUBjcy5hdWNrbGFuZC5hYy5ueiIgdGFyZ2V0PSJf YmxhbmsiPnBndXQwMDFAY3MuYXVja2xhbmQuLmFjLm56PC9hPiZndDssIEh1YmVydCBLYXJpbyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmhrYXJpb0ByZWRoYXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+aGth cmlvQHJlZGhhdC5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86VExTQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KU3ViamVjdDogUmU6IFtUTFNdJm5ic3A7IEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4z IOKAkyBuZWVkIGZvciBlcnJhdHVtPzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUmUgRUNEU0Eg c3BlY3MgYW5kIHBheXdlbGxzOjxicj4NCiZuYnNwOyAmbmJzcDsgQU5TSSBYOS42Mi0yMDA1IHdh cyB3aXRoZHJhd24gaW4gMjAxNSwgZXhwaXJpbmcgYXV0b21hdGljYWxseSBhZnRlciAxMCB5ZWFy cywgZGVzcGl0ZSBteSB3ZWFrIGVmZm9ydC48YnI+DQombmJzcDsgJm5ic3A7IEEgcmV2aXZhbCwg QU5TSSBYOS4xNDIsIHdpdGggYWxtb3N0IHRoZSBzYW1lIGNvbnRlbnQgaXMgdW5kZXIgd2F5LCB0 aG91Z2ggZXZlbiBpdHMgZmF0ZSBpcyB1bnN1cmUuPGJyPg0KJm5ic3A7ICZuYnNwOyBBbHNvLCBJ IGV4cGVjdCBGSVBTIDE4Ni01IGlzIG5lYXJseSByZWFkeSwgYW5kIHdpbGwgc3BlY2lmeSBtdWNo IG9mIEVDRFNBIGFuZCBFZERTQSAobm90IEFTTi4xPyksIHdoaWNoIG1hbnkgbWF5IGxpa2UgKGV2 ZW4gYmV0dGVyIHRoYW4gQU5TSSkuPGJyPg0KJm5ic3A7ICZuYnNwOyBNZWFud2hpbGUsIFNFQzEs IHZlcnNpb25zIDEuMCBhbmQgMi4wLCBhcmUgYXZhaWxhYmxlLCBmb3J0dW5hdGVseSBvciBub3Qs IGRlc3BpdGUgbXkgd2VhayBlZmZvcnQuPGJyPg0KJm5ic3A7ICZuYnNwOyBJRVRGIGhhcyBzcGVj cyBmb3Igc2lncyBhbmQgdGhlaXIgZm9ybWF0cyBhbHJlYWR5LCBubz88YnI+DQombmJzcDsgJm5i c3A7IFRoZW4gdGhlcmUncyBJU08sIElFRUUsIC4uLjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7IE9yaWdpbmFsIE1lc3NhZ2UmbmJzcDsgPGJyPg0KJm5ic3A7ICZuYnNwOyBG cm9tOiBKb2huIE1hdHRzc29uPGJyPg0KJm5ic3A7ICZuYnNwOyBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDEsIDIwMTkgNToyNSBBTTxicj4NCiZuYnNwOyAmbmJzcDsgVG86IFBldGVyIEd1dG1hbm47 IEh1YmVydCBLYXJpbzsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPg0KVExTQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgU3ViamVjdDogUmU6IFtU TFNdIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZvciBlcnJhdHVtPzxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgSHViZXJ0IEthcmlvICZsdDs8YSBocmVmPSJtYWlsdG86aGth cmlvQHJlZGhhdC5jb20iIHRhcmdldD0iX2JsYW5rIj5oa2FyaW9AcmVkaGF0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBOb3csIEkgZG9uJ3QgaGF2ZSBh Y2Nlc3MgdG8gWDkuNjItMjAwNSwgYnV0IHRoZXJlJ3MgYSBwb3NzaWJpbGl0eSBvZiBjb25mdXNp b24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJIHRoaW5rIHJlZmVyZW5jZXMgdG8gc3BlY2lm aWNhdGlvbnMgYmVoaW5kIHBheXdhbGxzIGFuZCBvdGhlciB0eXBlcyBvZiBsaW1pdGVkIGFjY2Vz cyBpcyBhIG1ham9yIHByb2JsZW0uIE5vdCBvbmx5IGZvciB0aGUgc3RhbmRhcmRpemF0aW9uIHBy b2Nlc3MsIGJ1dCBhbHNvIGZvciByZXNlYXJjaGVycyBhbmQgaW1wbGVtZW50b3JzLiBJbiBnZW5l cmFsLCBJIHRoaW5rIHBlb3BsZSBzaG91bGQgYmUgYWJsZSB0byBpbXBsZW1lbnQgYW5kIGFuYWx5 emUNCiBJRVRGIHN0YW5kYXJkcyB3aXRob3V0IGhhdmluZyB0byBwYXkgZm9yIGFjY2Vzcy48YnI+ DQo8YnI+DQombmJzcDsgJm5ic3A7IE9wZW4tYWNjZXNzIGlzIGV2ZW4gbW9yZSBpbXBvcnRhbnQg Zm9yIHNlY3VyaXR5IHNwZWNpZmljYXRpb25zLiBBTlNJIFguNjIgaXMgaG9wZWZ1bGx5IHF1aXRl IHdlbGwtc3R1ZGllZCwgYnV0IGZvciBvdGhlciByZWZlcmVuY2VzLCB0aGUgbGFjayBvZiBhbmFs eXNpcyBvZnRlbiBsZWFkcyB0byBtaXN0YWtlcyBhbmQgdW5rbm93biB3ZWFrbmVzc2VzLjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgSSB3b3VsZCBsaWtlIHRoZSBJRVRGIHRvIHRha2UgYSBtdWNo IHN0cm9uZ2VyIHN0YW5jZSBhZ2FpbnN0IG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIHBheXdhbGxz Lg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBDaGVlcnMsPGJyPg0KJm5ic3A7ICZuYnNwOyBK b2huPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZuYnNwOyAmbmJzcDsgVExTIG1haWxpbmcgbGlzdDxi cj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9NzQ5YzZkYmEtMjgwZTYwZTYtNzQ5YzJkMjEt MGNjNDdhZDkzZDQ2LTNkYTkyNGFiMmNmZTU3ZTgmYW1wO3E9MSZhbXA7dT1odHRwcyUzQSUyRiUy RnVybGRlZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGxzJTI2ZCUzRER3SUNBZyUyNmMlM0R5em9IT2Nf Wkstc3hsLWtmR05TRXZsSllhbnNzWE4zcS1saGowc3AyNndFJTI2ciUzRHFrcGJWRFJqN3psU1JW cWwtVW9uc1c2NDdsWXFuc3JiWGl6S0k2TWdrRXclMjZtJTNEQS05SlRCaDdkVV9oQ2JPcnJ4LWlB Q0VtR1BiamlwbkVvaGxsWUdManU2SSUyNnMlM0RwMnA5WV9oaC1qYl9xQk5hTnFUYlNUWUUydEF1 Sm8tQmFLRGJlbUZWTHhVJTI2ZSUzRCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9wcm90ZWN0 Mi5maXJlZXllLmNvbS91cmw/az03NDljNmRiYS0yODBlNjBlNi03NDljMmQyMS0wY2M0N2FkOTNk NDYtM2RhOTI0YWIyY2ZlNTdlOCZhbXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb190bHMlMjZkJTNERHdJQ0FnJTI2YyUzRHl6b0hPY19aSy1zeGwta2ZH TlNFdmxKWWFuc3NYTjNxLWxoajBzcDI2d0UlMjZyJTNEcWtwYlZEUmo3emxTUlZxbC1Vb25zVzY0 N2xZcW5zcmJYaXpLSTZNZ2tFdyUyNm0lM0RBLTlKVEJoN2RVX2hDYk9ycngtaUFDRW1HUGJqaXBu RW9obGxZR0xqdTZJJTI2cyUzRHAycDlZX2hoLWpiX3FCTmFOcVRiU1RZRTJ0QXVKby1CYUtEYmVt RlZMeFUlMjZlJTNEPC9hPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_819C343251C149A7AD2C53E4F7C3D469ericssoncom_-- From nobody Wed Oct 2 03:59:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483EC120833 for ; Wed, 2 Oct 2019 03:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 0whYMKNGg1R0 for ; Wed, 2 Oct 2019 03:59:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C99C120123 for ; Wed, 2 Oct 2019 03:59:22 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5B6B3084032; Wed, 2 Oct 2019 10:59:21 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 08A4F19C6A; Wed, 2 Oct 2019 10:59:20 +0000 (UTC) From: Hubert Kario To: Peter Gutmann Cc: Dan Brown , "TLS@ietf.org" Date: Wed, 02 Oct 2019 12:59:09 +0200 Message-ID: <9146093.uL4vQXI3YF@pintsize.usersys.redhat.com> In-Reply-To: <1569968112465.6769@cs.auckland.ac.nz> References: <1803994.nvTnDQYtSi@pintsize.usersys.redhat.com> <2211799.0F6m8LsVZW@pintsize.usersys.redhat.com> <1569968112465.6769@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2893588.6agtgx6lC7"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 02 Oct 2019 10:59:22 +0000 (UTC) Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 10:59:25 -0000 --nextPart2893588.6agtgx6lC7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :) >=20 > That's why I assumed it was an accident/error. Writing a spec that relies > on buggy parser implementations in order to work is asking for trouble. well, SEC 1 does not require the ECDSA-Sig-Value structure to be encoded wi= th=20 DER, it's TLS that does that (and I'd say for the better, given the multitu= de=20 of ways you can encode SEQUENCE in BER...) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2893588.6agtgx6lC7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2Ugv0ACgkQkqjRuAHS 9fV3ag//V7SfxPSxc/tfAotqm/XexBuOpk3K/9lpmoHQ1qDfHm3tFFQQwbFwftAN MhfA9BiY5Pk41wueevzuvOFWiMdV5iMthik9H+oh4UEnnfYh3/3g+TZixNsNtU6t 5uAC1colATq5uzMuL6Zc8VpMFSmJRTSTF2OLsOLnICs1xLEQWAzlkiyP3NTrLWRX vjIjxHwJFxXAdAK5bw3mxdvHE2ZWLVv1Cf6y54a+iSkNiXVJBWUkHOVyG6lczmnB 4BW60/+2nNF4naYcT5cbsE3/B/lZ7rPOI36KA5czdjRLbLAmq9Q1FBA5/3wc4Zrq 4AMLivkRF0XgixqaqwDx4HfaW9dKXBrHRfgoq+yr1eS5jHEtq4lJnWP68NpbXcWy 3yOXAUuqEs8bgJHvfTAvA3PqHrH9rMSfQvFGHPpbLsO4iZgVshJALH1K0bglSgoD zLTgWORxG/rEkstXZSUFBtcZC/Faj8+ff/b+qSROWjAe9k2yLFOoC/t5NBZYoyNC ai966lAXlLiiL3HG3wDawsQBaTwzBqIheoBDjjfcIqq6Pghj+lmpEELTzzpZ12G7 bTPmrrpR5ZY039pzGZjFOV7GHPK5fSqgcfursISh9fZ7QEn5XC44U/2mv7Ll8DOD uyHLO3ilMVYemyagNL1e7QMQxmic00Ex/RyGIk5GR2Of9uLCRQA= =bN4t -----END PGP SIGNATURE----- --nextPart2893588.6agtgx6lC7-- From nobody Wed Oct 2 04:17:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB71120123 for ; Wed, 2 Oct 2019 04:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8hfm2AzzeyQE for ; Wed, 2 Oct 2019 04:17:18 -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 149A7120044 for ; Wed, 2 Oct 2019 04:17:18 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2C349B817D2; Wed, 2 Oct 2019 04:17:15 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: hkario@redhat.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191002111715.2C349B817D2@rfc-editor.org> Date: Wed, 2 Oct 2019 04:17:15 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (5868) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 11:17:20 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5868 -------------------------------------- Type: Technical Reported by: Hubert Kario Section: 4.2.3 Original Text ------------- ECDSA algorithms: Indicates a signature algorithm using ECDSA [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] and FIPS 186-4 [DSS], and the corresponding hash algorithm as defined in [SHS]. The signature is represented as a DER-encoded [X690] ECDSA-Sig-Value structure. Corrected Text -------------- ECDSA algorithms: Indicates a signature algorithm using ECDSA [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA] and FIPS 186-4 [DSS], and the corresponding hash algorithm as defined in [SHS]. The signature is represented as a DER-encoded [X690] ECDSA-Sig-Value structure as defined in [RFC4492]. Notes ----- There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting definitions in authoritative standards. TLS always used the following (see RFC4492): ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } but the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) defines it like this: ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER, a INTEGER OPTIONAL, y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL } I think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, but the former is not an existing reference, so we would need to update section 12 also. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Oct 2 04:18:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9952120889 for ; Wed, 2 Oct 2019 04:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 5tWBemQzfmTr for ; Wed, 2 Oct 2019 04:18:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6CED12006D for ; Wed, 2 Oct 2019 04:18:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 864D88980EA; Wed, 2 Oct 2019 11:18:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 66CF2600CE; Wed, 2 Oct 2019 11:18:08 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: John Mattsson , Dan Brown , Peter Gutmann , "TLS@ietf.org" Date: Wed, 02 Oct 2019 13:18:07 +0200 Message-ID: <2229393.EUzCCCBh9I@pintsize.usersys.redhat.com> In-Reply-To: References: <20191001104718.8626261.12105.36904@blackberry.com> <7F3BF5B8-8E88-4611-813D-F207CCED4CD9@ericsson.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3507027.qbJXi4ApxD"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.67]); Wed, 02 Oct 2019 11:18:09 +0000 (UTC) Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 11:18:23 -0000 --nextPart3507027.qbJXi4ApxD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson =20 > 40ericsson.com@dmarc.ietf.org> wrote: > > Dan Brown wrote: > > > ANSI X9.62-2005 was withdrawn in 2015 > >=20 > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > > behind a paywall is even worse. >=20 > Ugh. >=20 > > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of > >=20 > > ECDSA > >=20 > > That NIST FIPS 186-5 will include all the details needed to implement > > ECDSA is great. > >=20 > > >IETF has specs for sigs and their formats already, no? > >=20 > > At the time when RFC 8446 was published, there was probably no quick and > > easy solution to the problem. But the fact that IETF has historically b= een > > fine with relying on specifications behind paywalls is part of the > > problem. > > If IETF had implemented a strong open-access policy a long-time ago, th= ere > > would probably be an open-access version of ECDSA (NIST or IETF) a long > > time ago.. >=20 > I agree with you about the policy here. To be honest, I just didn't notice > this; and it would probably need some github spelunking to figure out the > history of these references. >=20 > If someone wanted to propose an erratum that would fix this, I would be > very appreciative. I just did propose an erratum for that. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3507027.qbJXi4ApxD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2Uh28ACgkQkqjRuAHS 9fULNw/+PqrNqzlUA2YK60uP5v50WufnTKp2kLQwiqEZ54L9WQX2paOxMNV45s02 UJ0nsdJfcjdnPaPmkQHscfUjm22upmREFazK06SJWLcIwDpugFp9s+c70ykD/wwV eK/FK9aDzH8UUwwo0iyAxi7UErDQyE7RjgBr8oXHLdN+YdtyGsVKphsjWH4xqi1E n9DXijEeB1njPN76PiNai+qfV6bFVBSsGvVfQmHUBwZad/51Rr+E60EH/lj6BMfo ny8eIM8KGOp7mLSknvQbMfmwBldphbbGI4f9eyVzFQWX933PSJdTjeuqh/14xnHE CUKm/cXwE/9GfccpTMWajXJB2HOeggiy2O5L0ihz6JCxdF379l37jujPxmTa/pXC R6ZNQ0rkMjzdH14U73gllqyPxqbLQYlmXOz0OwMNgmVmtgm3FIE0BtRCijis/qHL fzhheoOJe98QXCmUhxMhOVWEOfXoLsBQQF8CY30I6V8JvdyNwsFWQIKzqWkW1mCG LOubCBaHXYZOvQ3UhqZ0K1mptng0FFxvSHMa/u8qdUOa0/iLr4na7pw5m8rLXtKR fyssv1kgUEfH8V6tmc1gGnAWOAEQxXoW/mMvNOA7UIHT5O3R6k1ixzeT4JNKP+ju ZQJRDC0vaIXSwy2ff+Y/VMTYeYv/ZcgKaiQJSkXrRKeZS20hrYw= =xQNP -----END PGP SIGNATURE----- --nextPart3507027.qbJXi4ApxD-- From nobody Wed Oct 2 04:23:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10908120048 for ; Wed, 2 Oct 2019 04:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 t5zZN3LKn8kO for ; Wed, 2 Oct 2019 04:23:33 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF0512000F for ; Wed, 2 Oct 2019 04:23:33 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 298233084032; Wed, 2 Oct 2019 11:23:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 150C2600CE; Wed, 2 Oct 2019 11:23:31 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: John Mattsson , Dan Brown , Peter Gutmann , "TLS@ietf.org" Date: Wed, 02 Oct 2019 13:23:31 +0200 Message-ID: <4732865.utW65egNGI@pintsize.usersys.redhat.com> In-Reply-To: <2229393.EUzCCCBh9I@pintsize.usersys.redhat.com> References: <20191001104718.8626261.12105.36904@blackberry.com> <2229393.EUzCCCBh9I@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1615272.pFhteH1R5e"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Wed, 02 Oct 2019 11:23:33 +0000 (UTC) Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 11:23:36 -0000 --nextPart1615272.pFhteH1R5e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote: > On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: > > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >=20 > > 40ericsson.com@dmarc.ietf.org> wrote: > > > Dan Brown wrote: > > > > ANSI X9.62-2005 was withdrawn in 2015 > > >=20 > > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be > > > behind a paywall is even worse. > >=20 > > Ugh. > >=20 > > > > Also, I expect FIPS 186-5 is nearly ready, and will specify much of > > >=20 > > > ECDSA > > >=20 > > > That NIST FIPS 186-5 will include all the details needed to implement > > > ECDSA is great. > > >=20 > > > >IETF has specs for sigs and their formats already, no? > > >=20 > > > At the time when RFC 8446 was published, there was probably no quick = and > > > easy solution to the problem. But the fact that IETF has historically > > > been > > > fine with relying on specifications behind paywalls is part of the > > > problem. > > > If IETF had implemented a strong open-access policy a long-time ago, > > > there > > > would probably be an open-access version of ECDSA (NIST or IETF) a lo= ng > > > time ago.. > >=20 > > I agree with you about the policy here. To be honest, I just didn't not= ice > > this; and it would probably need some github spelunking to figure out t= he > > history of these references. > >=20 > > If someone wanted to propose an erratum that would fix this, I would be > > very appreciative. >=20 > I just did propose an erratum for that. https://www.rfc-editor.org/errata/eid5868 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1615272.pFhteH1R5e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2UiLMACgkQkqjRuAHS 9fUfLA//Z1AtCtoyAGH7/NkaCnLYs6SxUKSC9jdhV102DJkheXRkEHQFrL5pdcN3 xon91iBtm7AsM3+7dnhetqAUPR7vEjDBT50YR20KkN6BvaAg1ZQX4fvhQJ/NhGdl p51k5MYK3vG5/0TKcWJCqDBL+aQGZnlXkBObEgcoKu/YXnAnVFVbklLDeZBbH9gZ uVHqUL+IglJKuzixBjynBoVH6W1t7oMGdQYlcMbXUoNTXbBm55mNbGVr4YprFRi7 89hPETKpVY30qCjupnXh3NO7A8uablRQ5v4bgxBkhGvenz1t4oAdQjqTDM4QBWJc lxGM8+ihJgxVa70u1twnpdo6TUnre4CkxbSSA3Unug6MsSXvNojQHfNxNjd5eW/w mKewG+gDDHB57CLkn3fjjikpuUhx8lZ38Hxm4PHPRkGdzP25Oljpmm8TilL1jAzl rpTHBK+3jGJQHnm0JVN52LlEc0RrA3gpi6XjFwVdj8a4hmKcRVIZ/Z9VaaTwBbug zK20qxcn5TIXneAxdeVqgXkRxT+euZPw2yzjxOHJgvO0Va4nB0myyHtMbNnSrim9 g7eAmrdyU37XXY/X9FwhSzaOMt50CpiBGw0Y+Gy2KPQpQxX54vM/Ab2PJg2utfaU d+t0BoTxjaOGsM2FVDlQLy4Bxrqvo3OHXR9joQO690nico6DgGU= =+WVh -----END PGP SIGNATURE----- --nextPart1615272.pFhteH1R5e-- From nobody Wed Oct 2 04:33:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6F12006B for ; Wed, 2 Oct 2019 04:33:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qWF_ZNoutUTe for ; Wed, 2 Oct 2019 04:33:33 -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 D3122120048 for ; Wed, 2 Oct 2019 04:33:32 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id x134so14602905qkb.0 for ; Wed, 02 Oct 2019 04:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FUYRm7ZLIm0mVvFRTFCuIvig2JEP4PRb1FlFrdvX1Y0=; b=abvn+o6huDjT75rDn7chRT29zUDSqMhKwfG8SkfwD+CQ8vrAMWhRec6Z2Iqdv2OtP2 GCBMpkN2EsdoJd74ArYMA/1uabGOTAj/IFYoQVGnOMytJaGhlXzJcgfUxIO/ISPYyv9c GRYd4+jC417n59qDwY+UJ93gxNURJOzXejfS8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FUYRm7ZLIm0mVvFRTFCuIvig2JEP4PRb1FlFrdvX1Y0=; b=e1Frs7B6+s/tPGhTIthATj20P7R9klp4RKTSKkdH+U8Cp4vzAYb1wR63XRxgOT67FA TuUh48F5id0KX7kxOZEMrEa0a66+6Wjx402/rhbxYOFstOwJe/Q9mdYvdpay8QzyOT6S yq7RXqhtWXokWwaAa8BAneED0bXHdCnvwKjk090ytYYYmBoVA7U4Mpo4CDgI3lP9I0CU 4IkSf81s4/3NstOEJ2iS6qtJUcZ9v00pft16z0GTvG8Pjl23kRIq/qEpEDO/EE9o+N0r 0ndD7bOd45kbWQDs3lXU90Nif2SnQzdEUtGyBDMuIUlysLlhdpa//pgSclYQka5wCDWq x4JA== X-Gm-Message-State: APjAAAU1l9deLNgKbkmtrMRk/UJnofiLxU29MyjrTGL5fts3s8q2LKYR nB1ihDI2uSqEV99GGNlVKgZWr5Ss+A6rwA== X-Google-Smtp-Source: APXvYqxvrqb/cYXMswN82jg9nqwJqQtjrXQlWKFXpX8LGgyr5YMYEHO7jI0ndZXE5TU7fVRvmtSRoQ== X-Received: by 2002:a37:6190:: with SMTP id v138mr3262833qkb.12.1570016011953; Wed, 02 Oct 2019 04:33:31 -0700 (PDT) Received: from ?IPv6:2a06:98c0:1000:8800:38c9:4e75:625e:a073? ([2a06:98c0:1000:8800:38c9:4e75:625e:a073]) by smtp.gmail.com with ESMTPSA id f27sm9752110qtv.85.2019.10.02.04.33.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2019 04:33:31 -0700 (PDT) From: Sean Turner Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7D20091D-2793-40F4-A373-C40BADE4B02B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 2 Oct 2019 12:33:28 +0100 In-Reply-To: <4732865.utW65egNGI@pintsize.usersys.redhat.com> Cc: Eric Rescorla , John Mattsson , "TLS@ietf.org" To: Hubert Kario References: <20191001104718.8626261.12105.36904@blackberry.com> <2229393.EUzCCCBh9I@pintsize.usersys.redhat.com> <4732865.utW65egNGI@pintsize.usersys.redhat.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 11:33:35 -0000 --Apple-Mail=_7D20091D-2793-40F4-A373-C40BADE4B02B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 2, 2019, at 12:23, Hubert Kario wrote: >=20 > Signed PGP part > On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote: >> On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: >>> On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >>=20 >>> 40ericsson.com@dmarc.ietf.org> wrote: >>>> Dan Brown wrote: >>>>> ANSI X9.62-2005 was withdrawn in 2015 >>>>=20 >>>> Ok, that TLS 1.3 is relying on a withdrawn publication that used to = be >>>> behind a paywall is even worse. >>>=20 >>> Ugh. >>>=20 >>>>> Also, I expect FIPS 186-5 is nearly ready, and will specify much = of >>>>=20 >>>> ECDSA >>>>=20 >>>> That NIST FIPS 186-5 will include all the details needed to = implement >>>> ECDSA is great. >>>>=20 >>>>> IETF has specs for sigs and their formats already, no? >>>>=20 >>>> At the time when RFC 8446 was published, there was probably no = quick and >>>> easy solution to the problem. But the fact that IETF has = historically >>>> been >>>> fine with relying on specifications behind paywalls is part of the >>>> problem. >>>> If IETF had implemented a strong open-access policy a long-time = ago, >>>> there >>>> would probably be an open-access version of ECDSA (NIST or IETF) a = long >>>> time ago.. >>>=20 >>> I agree with you about the policy here. To be honest, I just didn't = notice >>> this; and it would probably need some github spelunking to figure = out the >>> history of these references. >>>=20 >>> If someone wanted to propose an erratum that would fix this, I would = be >>> very appreciative. >>=20 >> I just did propose an erratum for that. >=20 > https://www.rfc-editor.org/errata/eid5868 On the 5480 vs 4492 reference. 4492 is also in the DOWNREF registry so = it=E2=80=99s okay on that front, but three=E2=80=99s no ASN.1 module. = That ASN.;1 come from the ASNI X9.62 spec. I have a slight preference = to refer to 5480 and just add the reference. spt --Apple-Mail=_7D20091D-2793-40F4-A373-C40BADE4B02B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5nRo/+BCFVtKzul3/mY1xyb/oi0FAl2UiwgACgkQ/mY1xyb/ oi3bsQ/+IjYuDraYkhH82Bcjswt5ZjtOpR0lzOSW1QC/VMAAjtNDchrdGu2gJv1n 7y9XEUmWqSdO2fOC/ks2hK5fTt9+5ZigkE6A27Q6w2oLcF957CfH5bVxxGDHPpIk KSIRHIBT23gyftwN1d1BwZakNLnLWlhD+zScLyb+Ip0YNMhjW9KBf5GWU84iX9ZT Codws/7IoJ4ANbsj2TVKnCpHxCE/uKioAkexqw5nT2h8TMy1AXFecb3T3/pbyAiA 33reLQtxpMvwHwdqq7NmS/ka/JOI2nU9oD791xj88+eXfo3Ygi5zun92viSGyPZM EMJ6O3jMnJHLKzzggO7p1uNj0i93QPhHxuy3Y5bNhyCYUb7xZg+W8mGYlI/tI7Qr jH8FKhIuCOGItYN1y4xX/i9czkU/skDMdJV7mQ7dJyKBxgYObc3kSlCvvjOHsHfa IfgnZ+v3vmhCzxgNZCRZTmkEr3Hg/VIvK+s435XyXBReIYkS2aTXhGJ+pVgE3RoD ffim2RtB25rqD+Pd0HutcMd0Si3H+dk0WyOEdhmBwRap3++YWTKJbl/2cM7hjsIh MFoRtY3VizTd3LwBDUnFyOaCk6eukiM4fHVOVuVkT8FjlNa3V2W7I/7YsI5vDhcF qYTesuQ+dolW0DrSDhq69f6IfzNg06encNSVPxn9GDQN+pIU7qI= =t+TD -----END PGP SIGNATURE----- --Apple-Mail=_7D20091D-2793-40F4-A373-C40BADE4B02B-- From nobody Wed Oct 2 06:17:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EBB112022C for ; Wed, 2 Oct 2019 06:17:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqNizHOlZG53 for ; Wed, 2 Oct 2019 06:17:08 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 32FD3120103 for ; Wed, 2 Oct 2019 06:17:07 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id 201so14878430qkd.13 for ; Wed, 02 Oct 2019 06:17:07 -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=FhHZacA4wPeG41yRniroRDucZBn1J9sQMA6nhV1KxkM=; b=MER5OmTF4cG87/4Keciixp7IdsBokn86WQH7hQcvH77+oaygsNWfuph5Hns/zk4Vqa EPkxsEFNaa7YQB2wHdN9JH+ZoXvk+56RBiQstjpM1/VycAqczS9HwVU37v7tA0m45oq8 +ETlvayONdUWf4UxBFToodYqW96qgc+/ukscM= 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=FhHZacA4wPeG41yRniroRDucZBn1J9sQMA6nhV1KxkM=; b=ERRg97LrcHTi3mbDTnDnuUrCs47Zj++IUDSveGh6x1NVkAqFVmndiT1tIPxhQSwRpD YOKBX8A2NKUhKuRF3qc2esVKdiqI5RByNFLFXuvi4DPyDAhRQRGBuopqRUgQ73Y/NZkI 2ih9C+zVFQY2j31yICZImb6E477PvraeCaK3MD8atmCjHVc7KOGE1A58Xj+zmvseTgQI a0zRX3yM8/0hztkeBYb79SWMBGiXdYsEPxAZvz2tW3sMC3jkTJ1dRTJc0If7gDUxY2sx TzaRaIpUrN+TkxUyT+BqlMYgkymXeA+VAEKRUHj2w2doCzgV6mVrI3UH1KLMEUhWMkAr C0Sw== X-Gm-Message-State: APjAAAWkp9rsz4sGVixrGM0vpvMAF8hKuHzR04qtslf78az/eaWb57da pm4vAjGxVcfjLU8ZwokX0lv2PQ== X-Google-Smtp-Source: APXvYqwrYSEGOtR/nAhYW/yxzIYgzeHuS6hFxlzhFffk/wzsDmJD85FwlS00s3gmz+Gh4F+iyVtPXA== X-Received: by 2002:a37:660c:: with SMTP id a12mr3683497qkc.70.1570022225250; Wed, 02 Oct 2019 06:17:05 -0700 (PDT) Received: from ?IPv6:2a06:98c0:1000:8800:38c9:4e75:625e:a073? ([2a06:98c0:1000:8800:38c9:4e75:625e:a073]) by smtp.gmail.com with ESMTPSA id x19sm8683627qkf.26.2019.10.02.06.17.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2019 06:17:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Wed, 2 Oct 2019 14:17:01 +0100 Cc: Eric Rescorla , Sean Turner via Datatracker , Benjamin Kaduk , IESG Secretary , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> To: John Mattsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 02 Oct 2019 13:17:15 -0000 > On Oct 1, 2019, at 21:14, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Oct 1, 2019 at 1:04 AM John Mattsson = wrote: > Hi, >=20 > I think draft-ietf-tls-oldversions-deprecate needs to update = draft-ietf-rtcweb-security-arch as well. >=20 > draft-ietf-rtcweb-security-arch-20 uses DTLS and even talks about = support of DTLS 1.0. >=20 > "Earlier drafts of this specification required DTLS > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > at the time of this writing some implementations do not support DTLS > 1.2; endpoints which support only DTLS 1.2 might encounter > interoperability issues." >=20 > You should check if there are more drafts in the publication process = that needs to be updated. >=20 > I don't particularly mind, but this text was actually the result of = some pretty extensive discussion and compromising in rtcweb, so it's not = just as simple as changing this text. You can change the text, but I do not believe it will change the = implementations. I would leave the text as is and NOT do an updates = header. spt From nobody Wed Oct 2 06:20:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF42120045; Wed, 2 Oct 2019 06:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 KmeaG2jliCSS; Wed, 2 Oct 2019 06:20:28 -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 5FD28120025; Wed, 2 Oct 2019 06:20:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77358BE39; Wed, 2 Oct 2019 14:20:26 +0100 (IST) 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 5BF_0W3cuuDd; Wed, 2 Oct 2019 14:20:26 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2AACBBE2F; Wed, 2 Oct 2019 14:20:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1570022426; bh=MYSV0S0dB65QqvcHOaalgtEhIWa52wgTKx9WYwBNUUk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fWddkHkU8JIyptCqc4RrHOw2jUK4nbaNeZg3njAAyHjtTdgBv5lAfYSeM66Gzyk0W XcjojanrYZt1jrOXRBAn+oNdwcfs5n+YqrqQQclHhiZDvqH0OghkTS7W748JCplyeH 7VNc8prYUevBzJS3F/TsE4dThOqfvL7GdxippM0E= To: Sean Turner , John Mattsson Cc: Sean Turner via Datatracker , "tls-chairs@ietf.org" , IESG Secretary , Benjamin Kaduk , "tls@ietf.org" References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> Date: Wed, 2 Oct 2019 14:20:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="igw1GRREEyKcfiXU51Y3UNBjzxmFZNSfV" Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 02 Oct 2019 13:20:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --igw1GRREEyKcfiXU51Y3UNBjzxmFZNSfV Content-Type: multipart/mixed; boundary="x0ssE0C0X7wMBTjrRJFW8BDMvnJfXrj60"; protected-headers="v1" From: Stephen Farrell To: Sean Turner , John Mattsson Cc: Sean Turner via Datatracker , "tls-chairs@ietf.org" , IESG Secretary , Benjamin Kaduk , "tls@ietf.org" Message-ID: <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> In-Reply-To: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> --x0ssE0C0X7wMBTjrRJFW8BDMvnJfXrj60 Content-Type: multipart/mixed; boundary="------------FEA868BAB37AE66F93BC8F34" Content-Language: en-GB This is a multi-part message in MIME format. --------------FEA868BAB37AE66F93BC8F34 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 02/10/2019 14:17, Sean Turner wrote: > You can change the text, but I do not believe it will change the > implementations. I would leave the text as is and NOT do an updates > header. WFM. I have executed that NOOP:-) S. --------------FEA868BAB37AE66F93BC8F34 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----- --------------FEA868BAB37AE66F93BC8F34-- --x0ssE0C0X7wMBTjrRJFW8BDMvnJfXrj60-- --igw1GRREEyKcfiXU51Y3UNBjzxmFZNSfV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2UpBMACgkQWrL68XsX K+rC6A/+O0DAbfYeEk4ppsWVSHKAasvXtGM8JZ3OxWyVY2RCzm0e2+87bcUNE5hh FcRmVQ994x4HyvKdPIrKiZeCd3y0Ob2yKsilCszGEkBOA6MCt2M3MFOdup7Tz3Ra pjwfPFpxFq5ydOMusE08uJWo7tFA8T1wNyajX5RL+dvfHVozg5lT/mFfgTKwu3xK Beaz08Q769TGDjHVX80I79QvSNehNgQSQP+gWyjT6yqkcUWfDm2F0mbDAoJz/iVQ 8rKCLST5VTDCPJD9z9MBHo2Oa1xQ1M0m018Hq8P77i7m9g726izXilizBIKwld2T zEWBTiKoZk0px7aCV+PUxRHKcw7p8oto0/f6FLFthEpAxLhzDpghWe5he8fjYqYB 5KAPH6GiQYSN0PFLf0KCnRDpwi1k4EOqxhLqosAR2NDqoyLxlqg8ovYjgalMy99X aWxDusEEJ71hpb5gT/k2y8Ng7TaLCIGGLzNOnzhj7YUGV87Mbwf/jx7HJXiHjkGU Wdqv54mCOd7X0fOrtjIHHDRtM8jWkUvf5VM3aVABlNkv4IEwzGhOz9TKzWqQWai+ 39hAM+4rkd+x3VXmiZsxnSV1NijndkYLPSRlKM995gy3ZVIkY6+fYvc39Rf2H5kO aW1wpt55ABWYuXU7eDIx7kKO23FCcoqbb+52n39EZ2Y8cxNNV1k= =3mD3 -----END PGP SIGNATURE----- --igw1GRREEyKcfiXU51Y3UNBjzxmFZNSfV-- From nobody Wed Oct 2 06:36:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D097120020 for ; Wed, 2 Oct 2019 06:36:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 CfbeT-HgHw5j for ; Wed, 2 Oct 2019 06:36:51 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 2B96112000F for ; Wed, 2 Oct 2019 06:36:51 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id w2so14985380qkf.2 for ; Wed, 02 Oct 2019 06:36:51 -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=SfYv3oOjXLfpw9oVGtYvqZBTgB3pIyDCCOVwY5PR/r0=; b=XtY75haIiHhsv+HBQjIy6dLkAPJQvNVgQmBmqXIvNAwGCuz6okA/UgTSszQY+NNzVu yZAAyGPrIuHMc4KgJcB9cLsnAWw9swl58J0qD7Jdf/7zqApQRUWzmBfuGpV+pfFo+bZB NUCen5bRjooaD26ijFi4TuJps9+UyRGTSoaNk= 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=SfYv3oOjXLfpw9oVGtYvqZBTgB3pIyDCCOVwY5PR/r0=; b=T0wsd5jeUK7S52jJFxRNjzBHz2oz2DxroTvgs/DkCcbTBoW5PoyE3LFoqxsyNeeRjI xXmXeIwr5c33sdmqhFDptN8QU4rh0j8XcrKgtKtLHymApFPRazkqha+WztlPX02+yin+ hPknzk2DYYmSxsbARQQDWWEmsqNMUacbTQMztcaKKrZEGO8xkXc6dOB1BkqX38h9FVOP MazRHNU69Fkr3N5HZY8/SyIFTlxKY1FnHtba+OIi+Wu9PlAkGXGMGnjWR+FHjAKYl3hk n1J+jbm3qFh1800uenN4cEERGTfKu/b/tFxyEp2BUUAslOLFym7yLMjkHuNruRRleYux pz4Q== X-Gm-Message-State: APjAAAW86hiRKlt23GhXiVF7uEuNBmhf6D5vfK4Lof40C0fCb6qfY2xc A4x1mmXdEciSb4KZ5PzPdcEJnViV3lwZvw== X-Google-Smtp-Source: APXvYqw5Z1c1jpcMxW9b5WXgNBcYsJThgoNydGsWPwwNmybiPwP1/rQqao272UT4xPegZNl0dRLKcQ== X-Received: by 2002:a37:3c4:: with SMTP id 187mr3616500qkd.424.1570023409719; Wed, 02 Oct 2019 06:36:49 -0700 (PDT) Received: from ?IPv6:2a06:98c0:1000:8800:38c9:4e75:625e:a073? ([2a06:98c0:1000:8800:38c9:4e75:625e:a073]) by smtp.gmail.com with ESMTPSA id 29sm9284984qkp.86.2019.10.02.06.36.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Oct 2019 06:36:47 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 2 Oct 2019 14:36:45 +0100 References: To: TLS List In-Reply-To: Message-Id: <67842C75-39D0-4C26-9DD2-A59BD44C6B36@sn3rd.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] DTLS Key Separation PR X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 13:36:53 -0000 Since this had support in the room, we would really like to get a sense = if there are any objections to this. Baring any negative comments, = we=E2=80=99ll ask ekr to merge this on 10/7. spt > On Oct 1, 2019, at 23:40, Eric Rescorla wrote: >=20 > Hi folks, >=20 > As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key = separation. >=20 > See:=20 > https://github.com/tlswg/dtls13-spec/pull/99 >=20 > Sadly. we didn't have enough space for "dtls13 " so I went for = "dtls13" >=20 > -Ekr >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Oct 2 06:44:57 2019 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 99CD7120020; Wed, 2 Oct 2019 06:44:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157002388954.8989.1895500690796679305@ietfa.amsl.com> Date: Wed, 02 Oct 2019 06:44:49 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 13:44:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename : draft-ietf-tls-external-psk-importer-01.txt Pages : 9 Date : 2019-10-02 Abstract: This document describes an interface for importing external PSK (Pre- Shared Key) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 2 06:55:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8A6120048 for ; Wed, 2 Oct 2019 06:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=kUzIL43r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=frNSxYCC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11TP949OobyI for ; Wed, 2 Oct 2019 06:54:56 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACBA1120020 for ; Wed, 2 Oct 2019 06:54:56 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id EA6B962D for ; Wed, 2 Oct 2019 09:54:55 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 02 Oct 2019 09:54:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=toYlxxsXkARbEJm2MW1N4rSbkmr2uYh 0S+vJ3sY6s20=; b=kUzIL43rJ/Osz20MT43azxsa3WkaUlByYpZuzlyOCn1qJwH gP0zrKhsGGvn1PPQAK5kTkEi5WSqhiYm1nxpuh1QHzDsrrWCVsoPOXKN7aU7IVwp CDTVpHneZ3NCQEBq24x5C5VpEkZogRozKfEWgYeCgoXSocXjyMvQ3lhUBAz8jhgS g6nt48h28zTO5+5PUEIqln9s3o3E/7i4KQ543oekIU5m4Azz3nVpRCEQzQx9YV0n IGbaM/Qwj0MDUiPgCJU9Yjg3TFSNrTOYSeVsBrdIFqZIQA7IZqFoKeGbGZRc2xNy wxXJoJZJ3guO+TcZ88lElBIUdFcdMxPgLooI4Gw== 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=toYlxx sXkARbEJm2MW1N4rSbkmr2uYh0S+vJ3sY6s20=; b=frNSxYCC0Y5TPAfvwlflTc ZBirlmNnAzxtXoVwY8X0R/tEzbtSXUO0TCUbtXh0jHQU3HI2f9b/gUErcVac4qFB /olJGwQGYUEC3KT9aynquxXWQQiIuiWL7aJeAqfHjhC7nEAFBiTenfLHLYIrIkl1 ct8TPcWETv1SWVeeC3cW0aoSW8Wi/mSC5SFjnxmHoR9MIxjM9JYGYm1ZhtBW3Idf LxF+tk42ASrmd1uDUEk381zLolA6DQDpruU0SospBcwPNIEOjkano9yuibfEawN3 gMejDSfwlDDg0Yirz9ZdTU5/UX9A5FWlrNYsod4UjjCO3lBquImLE3CD5oHidIjA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeigdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4AF833C00A1; Wed, 2 Oct 2019 09:54:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-359-g64bf1af-fmstable-20191002v2 Mime-Version: 1.0 Message-Id: <3ad6ba75-4aee-48b2-b8eb-5d43d37f7153@www.fastmail.com> In-Reply-To: <157002388954.8989.1895500690796679305@ietfa.amsl.com> References: <157002388954.8989.1895500690796679305@ietfa.amsl.com> Date: Wed, 02 Oct 2019 06:54:35 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 13:54:59 -0000 This update includes recent feedback received on the list and GitHub. There are three major changes: - Target KDFs instead of hash algorithms when importing external PSKs - Add an opaque "context" slot to the ImportedIdentity struct and describe its use for Selfie mitigations - Remove backwards compatibility ((D)TLS 1.2 and earlier) cruft (There's a silly formatting issue with the KDF table. We'll fix that in the next version.) Please have a look and provide feedback. PRs are welcome and highly encouraged. Looking ahead, there is one outstanding PR [1] that discussion. It deviates from an original goal of the importer, which was to not make any changes to TLS. There's also an issue to better document the importer security requirements and goals [2]. We are working on analyzing the importer and should be complete before Singapore, at which point we'll update the draft again. Best, Chris (no hat) On Wed, Oct 2, 2019, at 6:44 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Importing External PSKs for TLS > Authors : David Benjamin > Christopher A. Wood > Filename : draft-ietf-tls-external-psk-importer-01.txt > Pages : 9 > Date : 2019-10-02 > > Abstract: > This document describes an interface for importing external PSK (Pre- > Shared Key) into TLS 1.3. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 2 06:56:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35A4120074 for ; Wed, 2 Oct 2019 06:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=XQIxmvW2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=K8W1jY7F Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sZqT-Qse4Xv for ; Wed, 2 Oct 2019 06:55:56 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57B3120048 for ; Wed, 2 Oct 2019 06:55:56 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4F1035EB for ; Wed, 2 Oct 2019 09:55:56 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 02 Oct 2019 09:55:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=+rQ5AeK68TFZzLma+y58rUlAUyOfMgB YrCFOURlejNI=; b=XQIxmvW2JDZoc9BtMwOYeycEjGvPqIF2cqex9fc9AOvxGJo 9uaY84PD5s5P/F/oNoeyIAAhDAa145m0Amd18Eh9zM1+7hMASKQz8QLmE84NdGQe EA30AFg+O7ObQurQ5BzE3v/MbFf4B7JBA7uv2c6ELiJ/RzN9EC+jBg5AydrebJm4 FJKkMQZ2eH/Xe5YDl2SLxHs5SuD4FtTOoT5zmcRdj8HbQionW+ECPkk89eFn8R+v mfZAOmAi+RzpTBmsNCOD8iUzLDNaFtD1PAW/j8dtWhknQKdS04BYFbpYfyMpxE+J pFFBA2Q+fcB9VxOaYA95kLntHn3FgkGFGqBuXNA== 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=+rQ5Ae K68TFZzLma+y58rUlAUyOfMgBYrCFOURlejNI=; b=K8W1jY7F148ItkroIBhJdG tjW66tpgijVn1AbpBo0DYH8Ie2rZJ44PD0zp9egwRkoNtCdxtia/lWxBhc5pGdWW DR1V7rGy96IXJC7OB58T9Fz8QSx5+91CpMtPoN6Z13aL1ny7xnPolw1noMFAijXY 4yxnfAF0PJeJy2uUhn+/JuNUOM2T92bLzVBb33J75v6x6fIgmnuAcb2UZ1Ej7ccE 4VMFV0L2bhi7JVJCoz6cNNCRdtTkn1fsbPwADifilM3kNaIVsDpibFWa8Wkxk8LJ y6Zzlx7HldoknUMvBTWljCitFJr49LV/peRXjUEzh9umOQM0U1MILnHkZVHkrpMg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeigdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhi nhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7D4873C00A1; Wed, 2 Oct 2019 09:55:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-359-g64bf1af-fmstable-20191002v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <3ad6ba75-4aee-48b2-b8eb-5d43d37f7153@www.fastmail.com> References: <157002388954.8989.1895500690796679305@ietfa.amsl.com> <3ad6ba75-4aee-48b2-b8eb-5d43d37f7153@www.fastmail.com> Date: Wed, 02 Oct 2019 06:55:35 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 13:55:59 -0000 Oops. Here are the referenced links: [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 [2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/20 On Wed, Oct 2, 2019, at 6:54 AM, Christopher Wood wrote: > This update includes recent feedback received on the list and GitHub. > There are three major changes: > > - Target KDFs instead of hash algorithms when importing external PSKs > - Add an opaque "context" slot to the ImportedIdentity struct and > describe its use for Selfie mitigations > - Remove backwards compatibility ((D)TLS 1.2 and earlier) cruft > > (There's a silly formatting issue with the KDF table. We'll fix that in > the next version.) > > Please have a look and provide feedback. PRs are welcome and highly encouraged. > > Looking ahead, there is one outstanding PR [1] that discussion. It > deviates from an original goal of the importer, which was to not make > any changes to TLS. There's also an issue to better document the > importer security requirements and goals [2]. We are working on > analyzing the importer and should be complete before Singapore, at > which point we'll update the draft again. > > Best, > Chris (no hat) > > On Wed, Oct 2, 2019, at 6:44 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : Importing External PSKs for TLS > > Authors : David Benjamin > > Christopher A. Wood > > Filename : draft-ietf-tls-external-psk-importer-01.txt > > Pages : 9 > > Date : 2019-10-02 > > > > Abstract: > > This document describes an interface for importing external PSK (Pre- > > Shared Key) into TLS 1.3. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-01 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-01 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > From nobody Wed Oct 2 07:45:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADEFF1200CE; Wed, 2 Oct 2019 07:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 kbZGlb9HDw09; Wed, 2 Oct 2019 07:45:12 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80088.outbound.protection.outlook.com [40.107.8.88]) (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 C8C681200B6; Wed, 2 Oct 2019 07:45:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nvmq99ePRke6toMhAhf+WrW5QUnslhxVB16OTu8RMPHGHF8OYa61kD0RdKnyYjvXX2gz6oGVQlzT7Ot8/hQr1mDWYzc4ciN1hZWAdWrHqMZM5XefqOH7/QR+IeaFKFGLWdU7n9IoIKdwtCx3XC0iY2wDPOgIW4ZZfVTZn9feC4cQgbn05GM22ypiMl9a22cq8PE2bKWLhLXnjJIcIWk0YQcSBhOwwuJzC1WayUhq3MyCpwRRUTrpa++gNnznMQep1npxXxSnIVB0aElNqbdu0ADvBzn7mWT6ll8StJVEp8P4efa6XCJfN6iDexT5zG2azaMQlI+SNGhl/FyMI2L4Qg== 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=k8HKnh7f8FvCncxW8ti0IdU+HvUWr1sPThZ0w+w97ss=; b=C8GuBre7Iamfty2haHhX8U9kMyo8whYli+PAFrhi0OnUDhAgV/RiENRyBa9HBqnda9xXON2C9SKTV6FPS+aq44wflACFQdGcXzV+R401La2O1qUSYIb7eG1KvY6fYm5dD00vf4JRdrLZoWSeConX+OLwrI7FnnuUZpgwV1Alm9L7jUE3TMQeKO/TvFzDXOw+TW1ZfKfB1VISJgT2QN1ewa+cyGrvT+N+yyZE+HdXdHn9YptAvUuFfhFvf2or2fvjeFymHBoCmJ3ZLr8NWkxFqaRA7hnq2fKIytu0jo1Zx8ED9Ff/EMUmkuXUykiGMkSjnRfjzgXZ3f1yuvqh3XNRTA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k8HKnh7f8FvCncxW8ti0IdU+HvUWr1sPThZ0w+w97ss=; b=mVpovkZih61wJwwkFxIjxbwqyvhCqMejTbuPg39DV8bGqsQLkpR4pD69fFtlomVCZ8qVKkLZBZ5lDeR6cUJjniJeDX3P45iX64tGAUiMTmAwsu/i6rTzzVjeZ1gNVZh50RHRARqosUI+1I2DMJq7oA9f7xHmp4fxlMf5moqWZzw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3132.eurprd07.prod.outlook.com (10.170.242.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Wed, 2 Oct 2019 14:45:08 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.017; Wed, 2 Oct 2019 14:45:08 +0000 From: John Mattsson To: Stephen Farrell , Sean Turner CC: Sean Turner via Datatracker , "tls-chairs@ietf.org" , IESG Secretary , Benjamin Kaduk , "tls@ietf.org" Thread-Topic: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVLbNwka9w/WHllUqjsaoZBuXNvKdGI6+AgACqmwCAAR2pgIAAAOyAgAA5OQA= Date: Wed, 2 Oct 2019 14:45:08 +0000 Message-ID: <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> In-Reply-To: <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fb3366c8-df7d-4292-817e-08d747471f36 x-ms-traffictypediagnostic: HE1PR07MB3132: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(376002)(396003)(39860400002)(346002)(51444003)(189003)(199004)(6512007)(6436002)(186003)(256004)(76176011)(4326008)(305945005)(6506007)(7736002)(6486002)(6246003)(102836004)(446003)(99286004)(476003)(2616005)(486006)(11346002)(44832011)(26005)(33656002)(5660300002)(36756003)(54906003)(8936002)(81166006)(81156014)(6116002)(71190400001)(3846002)(58126008)(110136005)(316002)(296002)(66066001)(8676002)(86362001)(478600001)(25786009)(14454004)(76116006)(66946007)(14444005)(66476007)(2906002)(66446008)(71200400001)(64756008)(66556008)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3132; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z3cDL0fRWymXpy9RV3vNhgNHmLRyWLLpW/rBP5Lel0eY7u0Ct5L7INVnHrWBhMLuMJkShUrh6Vn9xSt/O3/5aKgZDtelB4TE/Qx9rI4Nnq9Ci6hxpERbPWxGiojEDSL2wtUX/vUzBAuZUpPnUXl9rMx1pVpxGPAziPzjGyrprRKPxjebT0JHrPTGEY1aducO+FvjAIFEtrlvStRJO9WugrOIv1bDKvkzp9ZzRQpX49UMel9jcKLwOhU26BVoMWSNT+tqXV+omGrIacw5ObQNanhH6Y20KLyDaF+ULrOpHU5RntaWyZkqegSUJ4OFuIoPDAvbputH59uEmgcqfPn/AyJ50/sJrrxH1UJ7alFmFpsDFWcQjfMP8lNJOu/IeBjbbGnlJkJ/KH8uEIMnDzs+dt1Nj9hC63759qjTbCi7HlM= 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-Network-Message-Id: fb3366c8-df7d-4292-817e-08d747471f36 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 14:45:08.6981 (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: rsvZhXfwQIy3FdEAViGjjPX/jdqQn5vt19g5ZSNNS7ix6I/uRN8jkMb4JJQd8lgRgsalauf3pxggGdAjyKbyzovtqv3wKteXyX8jKFS+H44= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3132 Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 02 Oct 2019 14:45:15 -0000 SGksDQoNClNlYW4gVHVybmVyIHdyb3RlOg0KPiAiWW91IGNhbiBjaGFuZ2UgdGhlIHRleHQsIGJ1 dCBJIGRvIG5vdCBiZWxpZXZlIGl0IHdpbGwgY2hhbmdlIHRoZSBpbXBsZW1lbnRhdGlvbnMuIg0K DQpJIHdvdWxkIG11Y2ggcmF0aGVyIGhhdmUgYSBmdXR1cmUgcHJvb2YgUkZDIHRoYXQgZm9yYmlk cyBuZWdvdGlhdGlvbiBvZiBEVExTIDEuMCB3aXRoIHRoZSBrbm93bGVkZ2UgdGhhdCBzb21lIGlt cGxlbWVudGF0aW9ucyB3aWxsIHRlbXBvcmFyeSB2aW9sYXRlIHRoYXQsIHRoYW4gaGF2aW5nIGFu IFJGQyB0aGF0IGxvbmcgdGltZSBpbiB0aGUgZnV0dXJlIGFsbG93cyBuZWdvdGlhdGlvbiBhbmQg dXNlIG9mIERUTFMgMS4wLg0KDQoNCkVyaWMgUmVzY29ybGEgd3JvdGU6DQo+ICJyZXN1bHQgb2Yg c29tZSBwcmV0dHkgZXh0ZW5zaXZlIGRpc2N1c3Npb24gYW5kIGNvbXByb21pc2luZyBpbiBydGN3 ZWIiDQoNClRoYXQgZG9lcyBub3Qgc3VycHJpc2UgbWUsIGJ1dCBJIHRoaW5rIHRoYXQgaXMgcGFy dCBvZiB0aGUgcHJvYmxlbS4gVGhlc2UgdGhpbmdzIHNob3VsZCBtYWlubHkgYmUgZGVjaWRlZCBi eSB0aGUgVExTIHdvcmtpbmcgZ3JvdXAuIERyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gg bWFuZGF0ZWQgRFRMUyAxLjAgdW50aWwgTm92IDIwMTguIFRoYXQgaXMgaGFsZiBhIHllYXIgYWZ0 ZXIgdGhlICJEZXByZWNhdGluZyBUTFN2MS4wIGFuZCBUTFN2MS4xIiBkcmFmdCB3YXMgc3VibWl0 dGVkIGFuZCBhbG1vc3QgNyB5ZWFycyBhZnRlciBEVExTIDEuMCB3YXMgbWFkZSBvYnNvbGV0ZS4N Cg0KDQpObyBtYXR0ZXIgd2hhdCBpcyBkb25lIGluIHRoaXMgcGFydGljdWxhciBjYXNlLCBJIHRo aW5rIHRoZSBpbXBvcnRhbnQgdGhpbmcgdG8gZGlzY3VzcyBpcyBob3cgd2UgYXZvaWQgZHJhZnRz IHRoYXQgb25seSBzdXBwb3J0IG9ic29sZXRlIHZlcnNpb25zIG9mIFRMUy9EVExTIGluIHRoZSBm dXR1cmUuIEFjY29yZGluZyB0byBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb21tZW50cyBpbiB0 aGUgdGhyZWFkICJMZXNzb25zIGxlYXJuZWQgZnJvbSBUTFMgMS4wIGFuZCBUTFMgMS4xIGRlcHJl Y2F0aW9uIiwgYm90aCBtZSwgS2F0aGxlZW4gTW9yaWFydHksIGFuZCBNYXJ0aW4gVGhvbXNvbiB1 bmRlcnN0YW5kcyBvYnNvbGV0ZWQgYXM6DQoNCiJOZXcgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBs b3ltZW50cyBNVVNUIGluY2x1ZGUgc3VwcG9ydCBvZiB0aGUgbmV3IHZlcnNpb24iLg0KDQpJZiB0 aGlzIGlzIG5vdCBjbGVhcmx5IGRlZmluZWQgc29tZXdoZXJlLCBJIHRoaW5rIGl0IG5lZWRzIHRv IGJlIHNwZWNpZmllZC4gSWYgaXQgaXMgc3BlY2lmaWVkIHNvbWV3aGVyZSwgSUVURiBuZWVkcyB0 byBtYWtlIHN1cmUgdG8gZm9sbG93IGFwcGx5IGl0Lg0KDQpDaGVlcnMsDQpKb2huIA0KDQo= From nobody Wed Oct 2 09:16:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09A5120088 for ; Wed, 2 Oct 2019 09:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 e8JK1bdhasT6 for ; Wed, 2 Oct 2019 09:16:04 -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 C1B1212004F for ; Wed, 2 Oct 2019 09:16:04 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id x92GG2fr005218 for ; Wed, 2 Oct 2019 12:16:02 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "TLS@ietf.org" Thread-Topic: =?utf-8?B?W1RMU10gIEVjZHNhLXNpZy12YWx1ZSBpbiBUTFMgMS4zIOKAkyBuZWVkIGZv?= =?utf-8?Q?r_erratum=3F?= Thread-Index: AQHVd50lWjU3XpWcNkSHADqIhiUs6qdGATGAgACeB4CAANVwgIAAFXqA Date: Wed, 2 Oct 2019 16:16:01 +0000 Message-ID: References: <1803994.nvTnDQYtSi@pintsize.usersys.redhat.com> <2211799.0F6m8LsVZW@pintsize.usersys.redhat.com> <1569968112465.6769@cs.auckland.ac.nz> <9146093.uL4vQXI3YF@pintsize.usersys.redhat.com> In-Reply-To: <9146093.uL4vQXI3YF@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-originating-ip: [172.25.1.84] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3652863361_2089206938" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-02_07:, , 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-1908290000 definitions=main-1910020142 Archived-At: Subject: Re: [TLS] =?utf-8?q?Ecdsa-sig-value_in_TLS_1=2E3_=E2=80=93_need_for_?= =?utf-8?q?erratum=3F?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 16:16:09 -0000 --B_3652863361_2089206938 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I concur with Hubert, and think that DER in this context is perfectly OK. =EF=BB=BFOn 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario" wrote: On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :) >=20 > That's why I assumed it was an accident/error. Writing a spec that r= elies > on buggy parser implementations in order to work is asking for troubl= e. =20 well, SEC 1 does not require the ECDSA-Sig-Value structure to be encode= d with=20 DER, it's TLS that does that (and I'd say for the better, given the mul= titude=20 of ways you can encode SEQUENCE in BER...) --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --B_3652863361_2089206938 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITQQYJKoZIhvcNAQcCoIITMjCCEy4CAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghEHMIIE8zCCA9ugAwIBAgITWQADyHaxtc8GrYDIrgAAAAPIdjANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE5MDMyNjE4NDEwMVoXDTIyMDMy NTE4NDEwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCzD7FJptOjLaaidxt9QIIH/dAblMrT ESMm4ggEBR0KqbmSkRY+x45ed8E2u9fJuFWKAgwU+vJo//kzavEpAAuyhe61Z+4noWIvV0sY WkUs+ffLh+29MxDs8Mt1++mDAC1+NyLCPN8QNPRJVu7ECRtmKu3DiAtuEKva3J7lZyVVNE+3 e9HQJlr/3alifN4sg/NxOFMTKMMEq15RgOhDyAudnNSs2IesRnoKTZq/Jykwbm0fg06ePSBR /k2JuYNW8/UZnU7d/Ez2n1NEtZkQw5QzWrC27ijf7FFQxM9yLToJneFVK+krQsfvtMbHGpnz Yo9keqc3Uxb13P4mpDbZiIBTAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUMzH1HGnW9jHVrCuy FAmJhhljwLcwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACztsHHc HX+FTwlhjHUUU+AcLyX3hgIdnTovNmPWVhVgzpN25AotcwODhCwuaLNoLsC0OHRISFUvkqHg 7aeZ9CiDOL4KwlNZgzGpDlqZ/AgMJ+JodWz0XqoNm4wYNs2rl7sEzLe70yPVyzTYlhECYnex UxE4hL334w/cx+Mb8vKn+/EQ9NFKVfCJ8X1dDkCA19EkZu2DbFF2oAM0kr6JX2dNx1rChTMZ iOSkGkKKpnVNFBMl/uw8qH8XrD+slPhLpTQg5t9l0pCtkJSMnrMovPvgwhlOP7yCLdPYYTwY IjwvUeqj1VAvid80L9vevRY1D6NDz/eWfoqCxXxPvtue//owggTAMIIDqKADAgECAgEGMA0G 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 xO9IcJIwggO6MIICIqADAgECAgRdXDruMA0GCSqGSIb3DQEBCwUAMBoxGDAWBgNVBAMMD0Zv cmVzdCBDQSBSU0EgNDAeFw0xOTA4MjAxODI0NDZaFw0yMjA4MjAxODI0NDZaMBgxFjAUBgNV BAMMDVVyaSB0aGUgR3JlYXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrm/Qc kv0j3p3fgutQujd+On6j7F39glKg15ZotSHpTk8Xv/xYJa8lEwWmCyFi7J19Soj2BYKB6Vpt hB/0eAlCiApOlJnzJ8nsosuB0Y9TMl1VRLXl/6NZboXFV6cYQNQioRE6A45nbSITxSQNgnyd flhq6oIWSOJYZDhbzH7kh2bgD2EyhoNybc6ttakg7CmswjvtuKnJtYjRfH7Hg+E19uL1vMfA M8URRIfh8Ih2evzTeKHJxqT0a9JUbfxRLY5SlSoi8fXJBvLvUBCT57chZ1JihS2yLHWofRIh RVPGrgtaOLt92ZT4OIk+bHDPIiikfb3VazQclW4QkU42BNGjAgMBAAGjgYkwgYYwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBSAwFgYDVR0RBA8wDYELdXJpQG1pdC5lZHUwHQYDVR0O BBYEFI+4HtpBG/H0lMsFmvZKC8BzEwxZMC8GA1UdJQQoMCYGCCsGAQUFBwMEBgorBgEEAYI3 CgMEBggrBgEFBQcDBgYEVR0lADANBgkqhkiG9w0BAQsFAAOCAYEAQdPfOUER5cfr6q90yJ1t ooYbnOFfwMUCtjaBJ5pNCaeQIT24f+xLQYDykkwZDVG+quGP/vH3i4xqh5QS5BOVEoOC2Rm4 SEW7c+27diwuJ3YoSDkXkjDMNc5YqYMBmHh+aktM4uQK0SDKuHCN4TNEzrf6UfvPhn7WgLtD p5d7wqaP/7Z8NbZt6ygIawlFQGF0hcQM4WL76jCEvakf/4y0IG7wmy+tzHICca0DADQ2SJdR ysh+e05uXf16st1uK+QbgsDxTH5r5WR1pBJmhigItpoig7JZOItcSMvCqWfwwxcWnskWTsqD 1rjs0/nCMTaYPUmwIWEsrseB9h2UUWczjBwpdIw/VbKKDBMqWN3KeNk1Q0TDub8NDLqL/PSM wJEGUD0RllGm/U3EKj/PDU7Im3CaFz7RcUb/tRGE8c7JftgDfq/NGMHzUoLRDTDmUoRon1xQ PGeqNBrGuC5+AwLT81RZa32v5dTZaY8cB5ExOVI5mOe67Kdyl87EsXQVC537MYIB/jCCAfoC AQEwaDBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEM MAoGA1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01AhNZAAPIdrG1zwatgMiuAAAAA8h2 MA0GCWCGSAFlAwQCAQUAoGkwLwYJKoZIhvcNAQkEMSIEIIL2V7qLER5WZadA2XBABaV3UAI2 jWiR5lpbH2naWN4bMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTE5MTAwMjE2MTYwMVowDQYJKoZIhvcNAQEBBQAEggEAj6fBYmEsP5Ut7VmjfCEumYuN1vgF 0whxRdwb1BrVLW0n6ltCD8CvYBSx9wFnKqv/rqU1lwHf9CQWBDaJbjlXcNKfE1j0YkjbVuzj 3CTNhF+ow2eOa1MGhH8pZyByD/0E3V2FkdQo/0tZ4j1g5HuXcP9+pb8I7K5wKlvZtQbMRMlR p10UNrS7AMpUygNy4AWV2/nh5Ud6I+AjuAzFxtqQVpPsjWapmGP/EkPW1SneOjphsre8EtdH FIWYFwq1R1qVRrYlN25RjGgcs2Bfme7GMbXWTpeMSeIDGm5bhi7P57q/sTyRTtMonbvBnEPy rGddXnkFaRkjXywPI08I1TNORw== --B_3652863361_2089206938-- From nobody Wed Oct 2 13:42:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3B12002F for ; Wed, 2 Oct 2019 13:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 sLXnD3___Otv for ; Wed, 2 Oct 2019 13:42:48 -0700 (PDT) Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) (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 10C21120018 for ; Wed, 2 Oct 2019 13:42:48 -0700 (PDT) Received: by mail-vs1-f41.google.com with SMTP id y129so160827vsc.6 for ; Wed, 02 Oct 2019 13:42:48 -0700 (PDT) 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=mItQXed/tynaUUxbzQHbB3/doEZE6W2egRK1qZ0Dsyw=; b=T/B1pQMsceeFQ9tvVvFcXDo9q+zGYoKailcFSbpPA5db3bJ4Idde5MT5Ohfl+cHI+N DZdLIzdTbJDBCTdQNcNZEUdJECLdNV9IH4VLQJjolOdQXI+6ZVsUe3qKprjRfsucUsK4 fku7oTp4tbLEMNiEcpA1j6HBxcVCtbX4ej6KMUihJ6epFNCALXakyXgWf6orCZlEU45I WojfzwtL5JaxAmpYkSFz6M+lFhGEVJS4ZnCOzFhvsuLR83fxNroG102yuwGS7s/pzqzd Tl9f0rOnM4RE/Lc8lR94YyT1fsVgEO4ge0r5CrC4dwoaw/3qRQdunK/N4t4+m5gQhgFl Xv7w== X-Gm-Message-State: APjAAAWLoC2TK6Itdg4n1skg6peayX8ioOrpdntQvS3oTXMgC+xgoF3L lg9MN1JOLC8Z0vz4VUv2hrkxV4XO/TVOU2js1cQ= X-Google-Smtp-Source: APXvYqwWqlcD+PvCc1t0AYy6UTtSNNvcH5y515u+8eSN5zZYQOaoHzfAFm/WIpd9TkZx6Mn8U7EdzRoY7Z7fHBC0Kz0= X-Received: by 2002:a05:6102:445:: with SMTP id e5mr3039189vsq.69.1570048967084; Wed, 02 Oct 2019 13:42:47 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> In-Reply-To: <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> From: Daniel Migault Date: Wed, 2 Oct 2019 16:42:32 -0400 Message-ID: To: Christopher Wood Cc: Hubert Kario , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f68db10593f382d2" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Wed, 02 Oct 2019 20:42:50 -0000 --000000000000f68db10593f382d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Please find some comments on the draft. In the introduction, I believe both limitations may be merged into one limitation which is the number of ticket is a server only decision. The purpose of the extension is the client providing information so the server can pick the appropriated number. I find "choose" and "hard-coded" a bit contradicting. If the server uses a hard coded value for the number of tickets, then I would understand the limitation as the server being unable to chose a value per client or per connection. This seems to me an implementation limitation and so maybe out of scope of the extension. If it is able to choose that number, the limitation is that it is a server only decision. I understand the meaning of count is the higher limit of ticket and the server can provides any tickets between 0 and count. If that is correct, this could be clearly stated and indication to chose an appropriated value for each cases may be provided. I would rather see the count value as a hard line from the server with a MUST NOT instead of a SHOULD NOT statement. My reading of 8446 is that NewSessionTicket messages can be sent at multiple time during or after the handshake. If that is correct, it seems to me quite complex to track the number of tickets that had been sent. Typically, if I have to send them at different time how much would I send at each flight. I would rather consider the min(count, server_limit) as the number of tickets in any batch of NewSessionTicket messages. We may also ask the client to only keep the latest batch of tickets and delete the others previously sent tickets. The ability to request 255 tickets with one byte can be seen as an amplification vector, especially when a server sends directly the tickets after its Finished message. I believe that additional text in the security consideration could be added. Yours, Daniel On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood wrote= : > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > ``` > > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > > ``` > > > > > > > > > > > > per what? session? at a time? connection? > > > > > > > > > > This is all per session. We can state it explicitly in the next > version. > > > > > > > > so this count needs to be kept as part of session and impacts > connections > > > > that perform resumption? > > > > > > Sorry, I meant connection: > > > > > > "Clients may indicate to servers their desired number of tickets > for *a > > > single connection* via the following "ticket_request" extension" > > > > > > This is a simple hint for servers. Nothing more. No state needs to be > stored > > > past connection establishment. > > > > sounds good > > > > > > > > what's the expected behaviour with tickets and post-handshake > > > > > > authentication? Are tickets sent after PHA also bound by this > limit? > > > > > > > > > > As mentioned earlier, there is no effect, so we left it out. We'r= e > happy > > > > > to > > > > > accept text should you think it's needed. > > > > > > > > If the I-D states that servers should not send more tickets than th= e > > > > client > > > > asked for, and then send exactly that amount, then they won't be > able to > > > > send new tickets after PHA and remain compliant. > > > > > > > > Yes, it's completely up to the server to decide if to send tickets > after > > > > PHA or not, and I'm not suggesting that the client should request f= or > > > > tickets in one of its PHA messages, much less expect or require > them, but > > > > sending tickets after PHA is reasonable and explicitly stated > behaviour: > > > > > > > > RFC 8446 Section 4.6.1: > > > > For instance, the server might send a new > > > > ticket after post-handshake authentication in order to encapsula= te > > > > the additional client authentication state. > > > > > > > > so the I-D should explicitly state what's the expected behaviour in > that > > > > case. > > > > > > > > IMHO, the extension should be used for the tickets sent right after > the > > > > handshake, it should not put an upper bound for the tickets that a > server > > > > can send in a single connection. For a very long lived connection > > > > (especially if the connection uses KeyUpdate messages regularly), t= he > > > > initial tickets may expire. Server may notice that and send a new > group > > > > of tickets then. > > > Since these hints are not mandatory to honor I don't think we need to > > > describe this case. In particular, this is a valid case where ignorin= g > the > > > SHOULD is fine, in my opinion. > > > > > > If the draft required that servers MUST NOT send more tickets than > what's > > > requested, then yes, I think these details would be important. > > > > huh? I see the following in the draft-02: > > > > Servers MUST NOT > > send more than 255 tickets to clients. > > I was referring to the "SHOULD NOT send more than > TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, the > MUST NOT above should also be a SHOULD NOT. Thanks for your patience in > working through the kinks! > > > > > > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > Attachments: > > * signature.asc > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000f68db10593f382d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find some comments on the draft.=C2=A0

In the introduction, I believe both lim= itations may be merged into one limitation which is the number of ticket is= a server only decision. The purpose of the extension is the client providi= ng information so the server can pick the appropriated number.=C2=A0
<= div dir=3D"ltr">=C2=A0
I find "choose" and = "hard-coded" a bit contradicting. If the server uses a hard coded= value for the number of tickets, then I would understand the limitation as= the server being unable to chose a value per client or per connection. Thi= s seems to me an implementation limitation and so maybe out of scope of the= extension. If it is able to choose that number, the limitation is that it = is a server only decision.=C2=A0

I understand the meaning of count is the higher limit of ticket an= d the server can provides any tickets between 0 and count. If that is corre= ct, this could be clearly stated and indication to chose an appropriated va= lue for each cases may be provided.=C2=A0=C2=A0

<= /div>
I would rather see the count value as a hard line fro= m the server with a MUST NOT instead of a SHOULD NOT statement.=C2=A0
=

My reading of 8446 is that NewS= essionTicket messages can be sent at multiple time during or after the hand= shake. If that is correct, it seems to me quite complex to track the number= of tickets that had been sent. Typically, if I have to send them at differ= ent time how much would I send at each flight. I would rather consider the = min(count, server_limit) as the number of tickets in any batch of NewSessio= nTicket messages. We may also ask the client to only keep the latest batch = of tickets and delete the others previously sent tickets.=C2=A0

The ability to request 255 tickets wi= th one byte can be seen as an amplification vector, especially when a serve= r sends directly the tickets after its Finished message. I believe that add= itional text in the security consideration could be added.=C2=A0

Yours,=C2=A0
Daniel



<= div class=3D"gmail_quote">
On Tue, Oct= 1, 2019 at 1:27 PM Christopher Wood <caw@heapingbits.net> wrote:


On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > > ```
> > > > > Servers MUST NOT send more than 255 tickets to cli= ents.
> > > > > ```
> > > > >
> > > > > per what? session? at a time? connection?
> > > >
> > > > This is all per session. We can state it explicitly in = the next version.
> > >
> > > so this count needs to be kept as part of session and impact= s connections
> > > that perform resumption?
> >
> > Sorry, I meant connection:
> >
> >=C2=A0 =C2=A0 "Clients may indicate to servers their desired = number of tickets for *a
> > single connection* via the following "ticket_request" e= xtension"
> >
> > This is a simple hint for servers. Nothing more. No state needs t= o be stored
> > past connection establishment.
>
> sounds good
>
> > > > > what's the expected behaviour with tickets and= post-handshake
> > > > > authentication? Are tickets sent after PHA also bo= und by this limit?
> > > >
> > > > As mentioned earlier, there is no effect, so we left it= out. We're happy
> > > > to
> > > > accept text should you think it's needed.
> > >
> > > If the I-D states that servers should not send more tickets = than the
> > > client
> > > asked for, and then send exactly that amount, then they won&= #39;t be able to
> > > send new tickets after PHA and remain compliant.
> > >
> > > Yes, it's completely up to the server to decide if to se= nd tickets after
> > > PHA or not, and I'm not suggesting that the client shoul= d request for
> > > tickets in one of its PHA messages, much less expect or requ= ire them, but
> > > sending tickets after PHA is reasonable and explicitly state= d behaviour:
> > >
> > > RFC 8446 Section 4.6.1:
> > >=C2=A0 =C2=A0 For instance, the server might send a new
> > >=C2=A0 =C2=A0 ticket after post-handshake authentication in o= rder to encapsulate
> > >=C2=A0 =C2=A0 the additional client authentication state.
> > >
> > > so the I-D should explicitly state what's the expected b= ehaviour in that
> > > case.
> > >
> > > IMHO, the extension should be used for the tickets sent righ= t after the
> > > handshake, it should not put an upper bound for the tickets = that a server
> > > can send in a single connection. For a very long lived conne= ction
> > > (especially if the connection uses KeyUpdate messages regula= rly), the
> > > initial tickets may expire. Server may notice that and send = a new group
> > > of tickets then.
> > Since these hints are not mandatory to honor I don't think we= need to
> > describe this case. In particular, this is a valid case where ign= oring the
> > SHOULD is fine, in my opinion.
> >
> > If the draft required that servers MUST NOT send more tickets tha= n what's
> > requested, then yes, I think these details would be important. >
> huh? I see the following in the draft-02:
>
>=C2=A0 =C2=A0 Servers MUST NOT
>=C2=A0 =C2=A0 send more than 255 tickets to clients.

I was referring to the "SHOULD NOT send more than TicketRequestContent= s.count NewSessionTicket messages" blurb. Indeed, the MUST NOT above s= hould also be a SHOULD NOT. Thanks for your patience in working through the= kinks!

>
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Rep= ublic
> Attachments:
> * signature.asc

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000f68db10593f382d2-- From nobody Wed Oct 2 13:54:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1C012004C for ; Wed, 2 Oct 2019 13:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=ix7cPAZJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=kjwx6vYW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HapbxEp5dpSL for ; Wed, 2 Oct 2019 13:54:32 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DE10120018 for ; Wed, 2 Oct 2019 13:54:32 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 89E2E21FF5; Wed, 2 Oct 2019 16:54:31 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 02 Oct 2019 16:54:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=QtUaul7ZA60Nf0xfHbbSf2/hzoAA yHoURTyZEm97NYk=; b=ix7cPAZJlTvpo5CsDjJr5D+nDwr1tabdMEVz1fAJuQlc Zja76VdXTK7QaANGpkxXIferbwvtNqCG33BbB5ujdS/pMRwCaWlhKj0WFqJ+xWZ0 MwJcoHUvZ+M+tUowlYS4SIhW6dRoHtCXtwHlomK+MSzCBopqTvxsPFc77z+N0njO z9bz7HuHrIZI8LusAVkJPawSQYp/Zitwa/8g+5TmdAXg/4cLY7k+Lz0A7PLgu84w P5yjybXJJLyrgC2ueZM/JdA9J/pEkRp9Lj39eUUWwcIYbp5uJgk8y8XWLOQFth8m 6DUIdZhqjJjpaD0yZmStKGJrUje9axawtOKJmMRSGw== 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=QtUaul 7ZA60Nf0xfHbbSf2/hzoAAyHoURTyZEm97NYk=; b=kjwx6vYWZ9fOMYs2LkgNuu hG6eH1+rF8C74C6+/FqNXy+9iUsKAZWoCnFgz2DGSl+YBBIgj/a3iBSuUGp243Ig Qx1dz/6twG3bVxvZJUIr9wYmAPNy8XGiTQpLFuedQDty4AhHk/cMqdRHIpYsmfuu sigc7Er34TgFDp2N/KdjxGiUvxM/ZHNOde1uEbfrqEUCGcVmt2dN0mLtW/7tCRGe h3t84jC941rmJmM1QBrvDXgjQU4KGqsaue79hcHE4JiAmCS+iTJkQMjFNZHj0TlX YkHHaJY7RH/ss8QD7QoMQNHb5hjSlCZEyk03iNgACzD7xu4uuZMYWtIoSI+8VobA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeigdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhn vghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7DFD3C00A1; Wed, 2 Oct 2019 16:54:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-359-g64bf1af-fmstable-20191002v2 Mime-Version: 1.0 Message-Id: <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> Date: Wed, 02 Oct 2019 13:53:44 -0700 From: "Christopher Wood" To: "Daniel Migault" Cc: "Hubert Kario" , "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Wed, 02 Oct 2019 20:54:34 -0000 Hi Daniel, Please see inline below. On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > Hi, > > Please find some comments on the draft. > > In the introduction, I believe both limitations may be merged into one > limitation which is the number of ticket is a server only decision. The > purpose of the extension is the client providing information so the > server can pick the appropriated number. I'd prefer we didn't merge them, though admittedly I don't feel strongly about this one way or the other. > I find "choose" and "hard-coded" a bit contradicting. If the server > uses a hard coded value for the number of tickets, then I would > understand the limitation as the server being unable to chose a value > per client or per connection. This seems to me an implementation > limitation and so maybe out of scope of the extension. If it is able to > choose that number, the limitation is that it is a server only > decision. Indeed. I think this is fairly clear from the draft. How would you suggest this be clarified? > I understand the meaning of count is the higher limit of ticket and the > server can provides any tickets between 0 and count. If that is > correct, this could be clearly stated and indication to chose an > appropriated value for each cases may be provided. The document states this: A supporting server MAY vend TicketRequestContents.count NewSessionTicket messages to a requesting client, and SHOULD NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. Is this not sufficient clear? If not, how can it be improved? > I would rather see the count value as a hard line from the server with > a MUST NOT instead of a SHOULD NOT statement. As this is merely a hint from the client, I don't think this is necessary. > My reading of 8446 is that NewSessionTicket messages can be sent at > multiple time during or after the handshake. If that is correct, it > seems to me quite complex to track the number of tickets that had been > sent. Typically, if I have to send them at different time how much > would I send at each flight. I would rather consider the min(count, > server_limit) as the number of tickets in any batch of NewSessionTicket > messages. We may also ask the client to only keep the latest batch of > tickets and delete the others previously sent tickets. This behavior is orthogonal to the intent of the hint. Imagine, for example, clients sent no hint and servers decided to do what you describe above. The same issues would still exist (tracking some count sent on the server, deciding which tickets to use on the client, etc.). Thus, I don't think this would add much value. > > The ability to request 255 tickets with one byte can be seen as an > amplification vector, especially when a server sends directly the > tickets after its Finished message. I believe that additional text in > the security consideration could be added. The text lists this: Servers SHOULD place a limit on the number of tickets they are willing to vend to clients. Though we can add a parenthetical to indicate that failure to do so may result in doing more work that intended. Thanks for the feedback! Best, Chris From nobody Wed Oct 2 13:58:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0BE1200EB; Wed, 2 Oct 2019 13:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=aEoW3kNC; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=u98x/hcX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzLFrs-HrQkk; Wed, 2 Oct 2019 13:58:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2413512004C; Wed, 2 Oct 2019 13:58:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 36EFB22095; Wed, 2 Oct 2019 16:58:40 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 02 Oct 2019 16:58:40 -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=eBaTxCM8z+U+LzXPOjuXjEiK7yewh0DNmN/pg5LdQoM=; b=aEoW3 kNCL5NjJTB3vhDGDUjKyOhGSqTJQxwg2lVwnQ3Z5pg3My4O05IyhW+SDjwi8pZnh AFNMjnGs4qE1RowjvhNuRw5XLflHHXb75Z3QBKm3etIqQV3K0Selj+knmtKjaafQ W53pF0jqAOP95fPDvDjKiP8vSRcavASos4wzxqjrGo8mmaJMkNxqJitYI/nez4rK +DUVuHSoSCxGPhhosbuvmVzgjZ0H2bWR2qUmdea4JhpiAvvb/4w7YhH2R7RYuJIw 4vGsGw7+7wKOnokcZ7zB19v1kQWxSRYYYDh2DXeIVaQQ17FPikfPOygOzwOAwhm1 m0uqQHT0vdCUMtaQw== 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=eBaTxCM8z+U+LzXPOjuXjEiK7yewh 0DNmN/pg5LdQoM=; b=u98x/hcXWba+NWtVX26fSQjgKCbuFWmpMiEzT0Xtgbqgr nYmhT+cQCK0sIrBPVchRVxyv7EsBtUwCT2PKLcuIrekAt/5SbmTimNNi+8eu0BrH XnsyZlD2WnlPIlsBFKYV9VjJ/7eCHg8Er1D1c4qJTqOVTGklZ+W4cPvlnRxf42Ce hnK/pR4RR08kygI/F88vtWhG322AbshSmawP7+fODWr3+3lByF6+88jG9LhXuPKj 6A35pROJW0QBomlhF34XoC0ArVD3TBRUmrvyMgvPmJp1NejeGqhujRayhKqPXGF+ Z/0VuBFwNUw9kawaUnTNHWk5W+WqVv9O01IfabkOA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeeigdduheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkfffhvffutgesthdtredtreertdenucfhrhhomhepfdevhhhrihhs thhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvtheqne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C8BFC3C00A2; Wed, 2 Oct 2019 16:58:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-359-g64bf1af-fmstable-20191002v2 Mime-Version: 1.0 Message-Id: <31e3f9ed-6b24-4526-af75-e2c190a3d707@www.fastmail.com> Date: Wed, 02 Oct 2019 13:58:19 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Cc: "TLS Chairs" Content-Type: text/plain Archived-At: Subject: [TLS] IANA changes for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 02 Oct 2019 20:58:42 -0000 Hi folks, draft-ietf-tls-exported-authenticator requires some IANA changes that were not discussed during WGLC. The proposed changes are below. Please let the list know by next week (10/9) if you object to them, and if so, please explain why. > Value: EXPORTER-server authenticator handshake context > DTLS-OK: Y > Recommended: Y > Reference: [ RFC-to-be ] > Note: > > Value: EXPORTER-client authenticator finished key > DTLS-OK: Y > Recommended: Y > Reference: [ RFC-to-be ] > Note: > > Value: EXPORTER-server authenticator finished key > DTLS-OK: Y > Recommended: Y > Reference: [ RFC-to-be ] > Note: Thanks! Chris From nobody Wed Oct 2 15:00:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EF1120059 for ; Wed, 2 Oct 2019 15:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 13ouKJK8S17f for ; Wed, 2 Oct 2019 15:00:27 -0700 (PDT) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 7977312006F for ; Wed, 2 Oct 2019 15:00:27 -0700 (PDT) Received: by mail-vs1-f52.google.com with SMTP id z14so267406vsz.13 for ; Wed, 02 Oct 2019 15:00:27 -0700 (PDT) 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=rAlZUQ9Htvz6yQgNTNy24+j2a70c3XnJ1dqzX575tHg=; b=eBHBJQqUvLUsnAKu9b1l+FWgq068KbDV80dR8qt4WbNZ+0MKo7kzA08/1qkL5slyHn TdYiv3zZQYsUuXW9ww40/GQzPxDCZtlHZ65Jnp/tuPVTojtVYVhggLZZi2toYH7NxKJJ lbKBLMSUrRelrFiSQASAlzOvq9X+cA8NwolfcLn8vBSElHfwPbeT0QGPRTQANU1ojURH mY8fHfAVPClTFxCa783Sav/T6H5m9q7dUskMwTisUuz0Y8h8nQEa++E5ghdFYBxY9yRQ HW2kCDicy9wmRUWk+qNwUfDPA7JvmTVAjbl33EENb/ZLQZ81T4jciqlZ+6jyn7adn5O3 vcZA== X-Gm-Message-State: APjAAAUVgADn/iedIViu3eHhd64KhCtk57AvSorlHSxC6IV8fO0KmLYm Nso5x2x1GSfZKqbTDoOFNzqOX8yqMPJkH67fLMiO5A4RJaU= X-Google-Smtp-Source: APXvYqwKWGsSztd8rdVQvexAY15zFuwPcB855VVn0atgxbImxtxhvEAf0ub6nLMEgkXTkAeSohSmeOZ4dyPjXxV6XUQ= X-Received: by 2002:a67:3355:: with SMTP id z82mr3488397vsz.169.1570053626494; Wed, 02 Oct 2019 15:00:26 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> In-Reply-To: <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> From: Daniel Migault Date: Wed, 2 Oct 2019 18:00:15 -0400 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000af829d0593f49827" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Wed, 02 Oct 2019 22:00:30 -0000 --000000000000af829d0593f49827 Content-Type: text/plain; charset="UTF-8" Hi, Please see my comments. Yours, Daniel On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood wrote: > Hi Daniel, > > Please see inline below. > > On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > > Hi, > > > > Please find some comments on the draft. > > > > In the introduction, I believe both limitations may be merged into one > > limitation which is the number of ticket is a server only decision. The > > purpose of the extension is the client providing information so the > > server can pick the appropriated number. > > I'd prefer we didn't merge them, though admittedly I don't feel strongly > about this one way or the other. > > > I find "choose" and "hard-coded" a bit contradicting. If the server > > uses a hard coded value for the number of tickets, then I would > > understand the limitation as the server being unable to chose a value > > per client or per connection. This seems to me an implementation > > limitation and so maybe out of scope of the extension. If it is able to > > choose that number, the limitation is that it is a server only > > decision. > > Indeed. I think this is fairly clear from the draft. How would you suggest > this be clarified? > The draft does not seem, in my opinion, to address the case when values are hard coded. OK hardcoded is just there to expose it cannot chose the value. It is fine. > > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is > > correct, this could be clearly stated and indication to chose an > > appropriated value for each cases may be provided. > > The document states this: > > A supporting server MAY vend TicketRequestContents.count > NewSessionTicket messages to a requesting client, and SHOULD NOT send > more than TicketRequestContents.count NewSessionTicket messages to a > requesting client. > > Is this not sufficient clear? If not, how can it be improved? > > > I would rather see the count value as a hard line from the server with > > a MUST NOT instead of a SHOULD NOT statement. > > As this is merely a hint from the client, I don't think this is necessary. > > I believe we could be more specific than a hint, and a server supporting the extension MUST NOT send more tickets then specified. This is what is expected when count is set to 0. > > My reading of 8446 is that NewSessionTicket messages can be sent at > > multiple time during or after the handshake. If that is correct, it > > seems to me quite complex to track the number of tickets that had been > > sent. Typically, if I have to send them at different time how much > > would I send at each flight. I would rather consider the min(count, > > server_limit) as the number of tickets in any batch of NewSessionTicket > > messages. We may also ask the client to only keep the latest batch of > > tickets and delete the others previously sent tickets. > > This behavior is orthogonal to the intent of the hint. Imagine, for > example, clients sent no hint and servers decided to do what you describe > above. The same issues would still exist (tracking some count sent on the > server, deciding which tickets to use on the client, etc.). Thus, I don't > think this would add much value. > > If the servers receives a count value and sends tickets right after the Finished message and after the post handshake authentication. How many messages do you expect to be sent at each round? I suggested to have count at each round, as the server does not know how the client expects to use these tickets. I have the impression the current text says count. > > > > The ability to request 255 tickets with one byte can be seen as an > > amplification vector, especially when a server sends directly the > > tickets after its Finished message. I believe that additional text in > > the security consideration could be added. > > The text lists this: > > Servers SHOULD place a limit on the number of tickets they are willing > to vend to clients. > > The draft mentions limitation of tickets to avoid computation of the server, and I was reading the limit as to limit that computation, in which case the limit addresses server's resource exhaustion. What I meant was the use of the extension with a spoofed IP address. > Though we can add a parenthetical to indicate that failure to do so may > result in doing more work that intended. > > Thanks for the feedback! > > Best, > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000af829d0593f49827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,=C2=A0

Pl= ease see my comments.=C2=A0

Yours,=C2=A0
Daniel
On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood <caw@heapingbits.net> wrote:
Hi Daniel,

Please see inline below.

On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> Hi,
>
> Please find some comments on the draft.
>
> In the introduction, I believe both limitations may be merged into one=
> limitation which is the number of ticket is a server only decision. Th= e
> purpose of the extension is the client providing information so the > server can pick the appropriated number.

I'd prefer we didn't merge them, though admittedly I don't feel= strongly about this one way or the other.

> I find "choose" and "hard-coded" a bit contradicti= ng. If the server
> uses a hard coded value for the number of tickets, then I would
> understand the limitation as the server being unable to chose a value =
> per client or per connection. This seems to me an implementation
> limitation and so maybe out of scope of the extension. If it is able t= o
> choose that number, the limitation is that it is a server only
> decision.

Indeed. I think this is fairly clear from the draft. How would you suggest = this be clarified?
The draft does not seem, in my opin= ion, to address the case when values are hard coded. OK hardcoded is just t= here to expose it cannot chose the value. It is fine.=C2=A0 =C2=A0 =C2=A0

> I understand the meaning of count is the higher limit of ticket and th= e
> server can provides any tickets between 0 and count. If that is
> correct, this could be clearly stated and indication to chose an
> appropriated value for each cases may be provided.

The document states this:

=C2=A0 =C2=A0A supporting server MAY vend TicketRequestContents.count
=C2=A0 =C2=A0NewSessionTicket messages to a requesting client, and SHOULD N= OT send
=C2=A0 =C2=A0more than TicketRequestContents.count NewSessionTicket message= s to a
=C2=A0 =C2=A0requesting client.

Is this not sufficient clear? If not, how can it be improved?

> I would rather see the count value as a hard line from the server with=
> a MUST NOT instead of a SHOULD NOT statement.

As this is merely a hint from the client, I don't think this is necessa= ry.

I believe we could be more specific than a hint, and = a server supporting the extension MUST NOT send more tickets then specified= . This is what is expected when count is set to 0.=C2=A0
=C2= =A0
> My reading of 8446 is that NewSessionTicket messages can be sent at > multiple time during or after the handshake. If that is correct, it > seems to me quite complex to track the number of tickets that had been=
> sent. Typically, if I have to send them at different time how much > would I send at each flight. I would rather consider the min(count, > server_limit) as the number of tickets in any batch of NewSessionTicke= t
> messages. We may also ask the client to only keep the latest batch of =
> tickets and delete the others previously sent tickets.

This behavior is orthogonal to the intent of the hint. Imagine, for example= , clients sent no hint and servers decided to do what you describe above. T= he same issues would still exist (tracking some count sent on the server, d= eciding which tickets to use on the client, etc.). Thus, I don't think = this would add much value.

If the servers receives a count value and sends ticke= ts right after the Finished message and after the post handshake authentica= tion. How many messages do you expect to be sent at each round?=C2=A0 I sug= gested to have count at each round, as the server does not know how the cli= ent expects to use these tickets. I have the impression the current text sa= ys count.=C2=A0
>
> The ability to request 255 tickets with one byte can be seen as an > amplification vector, especially when a server sends directly the
> tickets after its Finished message. I believe that additional text in =
> the security consideration could be added.

The text lists this:

=C2=A0 =C2=A0Servers SHOULD place a limit on the number of tickets they are= willing to vend to clients.

The draft mentions limitation of tickets to avoid com= putation of the server, and I was reading the limit as to limit that comput= ation, in which case the limit addresses server's resource exhaustion. = What I meant was the use of the extension with a spoofed IP address.=C2=A0= =C2=A0
=C2=A0=C2=A0
Though we can add a parenthetical to indicate that failure to do so may res= ult in doing more work that intended.

Thanks for the feedback!

Best,
Chris

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000af829d0593f49827-- From nobody Wed Oct 2 16:04:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072C812010D for ; Wed, 2 Oct 2019 16:04:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 (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 vs_R1wJWPttY for ; Wed, 2 Oct 2019 16:04:11 -0700 (PDT) Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 174A61200F4 for ; Wed, 2 Oct 2019 16:04:10 -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 A21BFE055D; Wed, 2 Oct 2019 23:04:09 +0000 (UTC) Received: from pdx1-sub0-mail-a97.g.dreamhost.com (100-96-8-30.trex.outbound.svc.cluster.local [100.96.8.30]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 395D0E05B6; Wed, 2 Oct 2019 23:04:09 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a97.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Wed, 02 Oct 2019 23:04:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Army-Tangy: 115f00d62043e02d_1570057449471_1758708564 X-MC-Loop-Signature: 1570057449471:2318745942 X-MC-Ingress-Time: 1570057449471 Received: from pdx1-sub0-mail-a97.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a97.g.dreamhost.com (Postfix) with ESMTP id 3709384047; Wed, 2 Oct 2019 16:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=buIg35DlUl0SpBIKS0oyR9bbWyg =; b=b37/WGdSnEUJwbA1083reLYATRndvdV4TfaCAzYzoRXjSh9nKz+3LZ1XYuC E/4a5Ac83X5wUpo/x8Npaj/ZYTIUnAR+qHpsjPV6jtEJWsr2WIEnKPCW7WVm1mHV rQPMJRFgGvuohuKtLSimlrvONsilacy71M/npOVDfbHk8dZw= 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-a97.g.dreamhost.com (Postfix) with ESMTPSA id C1C6C8403A; Wed, 2 Oct 2019 16:04:05 -0700 (PDT) Date: Wed, 2 Oct 2019 18:04:03 -0500 X-DH-BACKEND: pdx1-sub0-mail-a97 From: Nico Williams To: tls@ietf.org Message-ID: <20191002230402.GF5002@localhost> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191001145600.GU21772@straasha.imrryr.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrgeejgddugecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Wed, 02 Oct 2019 23:04:13 -0000 On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > I've read the draft, it looks quite useful and reasonable. It would > be good to see this published. +1 > I have one idea (implemented in OpenSSL 1.1.1 on the server side) > that may be worth mentioning in this context (and perhaps even the > draft): > > - By default, OpenSSL TLS 1.3 servers only vend multiple (two) > tickets on full handshakes. Resumed sessions issue just one > ticket. > > This avoids unbounded linear growth in the number of tickets vended > to a client that makes many resumed connections even after reaching > its peak connection concurrency. Dumb clients that say they want so many tickets on resumption, and then store them all, and don't clear out older tickets fast enough... can get DoSed by a server than gives them what they asked for. This probably warrants a bit of text on the matter. Probably a SHOULD saying that clients should ask for only one ticket in resumptions (i.e., not use this extension) unless they are short of tickets. Nico -- From nobody Wed Oct 2 20:08:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF81F120073 for ; Wed, 2 Oct 2019 20:08:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 NVjCUHgLrk82 for ; Wed, 2 Oct 2019 20:08:16 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 45FFD12006F for ; Wed, 2 Oct 2019 20:08:16 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id n197so2108003iod.9 for ; Wed, 02 Oct 2019 20:08: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=OQthgOGOesEj/VkobG+IAwSyldG1iVI5n+l+nJCIxmw=; b=Zb9vxAkGV012SJk3FzgePJ63wz3mP030GGpiB/lEaMxr18EKDVuwdyOFYvDifAknGq w9tmStTQ0watwazlDu8TJVKjOrYbhzcxTxnnq2wXijPxsWf/TuOnDqGNnLrJuQ2RYtDT FR1j2ux4SQ0Yv3QmHwoErEsJTrN8oEgr+aUmuYeQagyUI8rWWlg7meL1lQ59zMW4ux0O j4jRan9ceG03a2xlcXdPiU8YZgvrIs2xeXyL0fQXz+0aVF1ThRoA/jFBBSLvA+G3E05P ow00CQTHSLodpSY/E7ug12VFoLdiiosypgGZAAl1t852YlvhkoyheiPqF36WdMM4airJ C66A== 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=OQthgOGOesEj/VkobG+IAwSyldG1iVI5n+l+nJCIxmw=; b=bUXa0Ln4ECloH0e9digCvJNWkWPtmc7T/yTz+o3TitY6Eau2BfKhDj7S8yArfYXG9V 1L1DvCl72Vk/bmpz6wSRfLT3VNBEZZE+xociteQWtK+fnNpYQ0XlXvvHLm/aJkH1XkaD HfOyYb4HIFM487BXeoUZOz9dhCEXqrN/vQIkMxzM0sPUHt9+ZMLW3xKRiXE82OqqlRlq obnIX1EplM9T8bFd6p9177EaWtSfwQwcWJ8hwpDaTi9nH3lcO7UY0pzkSaWc/iRKQkDL qWZibVOMRauBUm5IAvdvj6D7c+NK1GGJqqu2Dyc3+16EQ1zm0KWpMrr5zLK7hYIieDnM U+nw== X-Gm-Message-State: APjAAAUj6MAiAgPcN2bh2NwZWy/eRnqifN+RmmLQyVFRWwX2daWrg1tA dnw9wFg2GdHFvwY8P0z3nLrfQ7qYSrnbyT5013c= X-Google-Smtp-Source: APXvYqx3BO+OG6eOySTzK2i6dxbs7EJo+JAQX9qhT5YiCkOpYEZ/YScGSzMv0XGueV+O1UKsH4RRbvnEaJ119O4B6MU= X-Received: by 2002:a6b:2c07:: with SMTP id s7mr6504420ios.254.1570072095287; Wed, 02 Oct 2019 20:08:15 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> In-Reply-To: <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> From: Rob Sayre Date: Thu, 3 Oct 2019 10:08:02 +0700 Message-ID: To: Christopher Wood Cc: Daniel Migault , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000082edb80593f8e544" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 03:08:18 -0000 --00000000000082edb80593f8e544 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote: > > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is > > correct, this could be clearly stated and indication to chose an > > appropriated value for each cases may be provided. > > The document states this: > > A supporting server MAY vend TicketRequestContents.count > NewSessionTicket messages to a requesting client, and SHOULD NOT send > more than TicketRequestContents.count NewSessionTicket messages to a > requesting client. > > Is this not sufficient clear? If not, how can it be improved? > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some examples of "valid reasons in particular circumstances to ignore a particular item" [RFC2119]. Otherwise, those requirements can be cryptic, and perhaps better-described by MAY or MUST language. thanks, Rob --00000000000082edb80593f8e544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 3, 2019 at 3:54 AM Christophe= r Wood <caw@heapingbits.net&g= t; wrote:

> I understand the meaning of count is the higher limit of ticket and th= e
> server can provides any tickets between 0 and count. If that is
> correct, this could be clearly stated and indication to chose an
> appropriated value for each cases may be provided.

The document states this:

=C2=A0 =C2=A0A supporting server MAY vend TicketRequestContents.count
=C2=A0 =C2=A0NewSessionTicket messages to a requesting client, and SHOULD N= OT send
=C2=A0 =C2=A0more than TicketRequestContents.count NewSessionTicket message= s to a
=C2=A0 =C2=A0requesting client.

Is this not sufficient clear? If not, how can it be improved?

RFC2119 "SHOULD/SHOULD NOT" requirements a= re usually clearer with some examples of "valid reasons in particular = circumstances to ignore a particular item" [RFC2119]. Otherwise, those= requirements can be cryptic, and perhaps better-described by MAY or MUST l= anguage.

thanks,
Rob
--00000000000082edb80593f8e544-- From nobody Wed Oct 2 20:19:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6FF12007A for ; Wed, 2 Oct 2019 20:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=hvPYN+vp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZgU+ThVK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTi7HH6i-ss9 for ; Wed, 2 Oct 2019 20:19:04 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFAD120073 for ; Wed, 2 Oct 2019 20:19:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 010E35B5; Wed, 2 Oct 2019 23:19:03 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 02 Oct 2019 23:19:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=5nXi9eY1bgJNQGca33xfqvokWRg1 208wEo/TAlJcdTQ=; b=hvPYN+vpjKlMvPlAfvK1kNYz6QQS+k8hpsDNjZMdc/14 ZghIvngRGNlLBvCiB9C6zt51dcIETCK4KQGQUbHm4cgL/vbP1+hCv+/KDTUcI5sl WUT3pPECYDPEzS0HzmOYCZmTR4AUoHiml53q2lxarggYEMkXYs6er3tVGTjRhG0K ExTy5iWDkRv9D9yjQ9CRw/WQvT47F+XXOMZdcl/h0HvKJUYocAwL3BNd7QUGIGWl b2cYcCJKLDBhfxRcoaC4ufmX7LbF4Ao/TFZX+GiY8fJVRf/FabvfT34MbvHr9UA5 gkoqgLOwmAm/n3dAl8e6p3VSObNJUy+tuIrsQwT8hw== 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=5nXi9e Y1bgJNQGca33xfqvokWRg1208wEo/TAlJcdTQ=; b=ZgU+ThVKC7x+3lBJQ08sW7 DFHf3+5oipQDmiIoSjR2UroDaCoGi/e4nWVcA6Yvlcjglf92DxlLsDxOl9Qunll3 KeUbCcDaMXky9DJBcH3URuxVCro62g9pK/XOMxeJBomZyF8dwRNQ7nUqAMmUMiCg ReXyfwV7Bj5Bvkzr3nBDRj8EXBU6lWdk7NL9U+LHEw997BByEzukTpinfdm59tCS tpbsI8aG+/6sgl91nrdMUy+oVEVArpgVQQIn4pKUPzTfpWRZYgDH8zeuewJqWpvK 7nsybqPX7iRTjVPWX+RyjD2USiB/dd7FcUlmtu8D7gYbOW/5+/T4oo73beNvhJhg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeejgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21EA23C00A1; Wed, 2 Oct 2019 23:19:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-359-g64bf1af-fmstable-20191002v2 Mime-Version: 1.0 Message-Id: <16d1473c-8ee9-4007-b71e-eef38134d331@www.fastmail.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> Date: Wed, 02 Oct 2019 20:18:42 -0700 From: "Christopher Wood" To: "Rob Sayre" Cc: "Daniel Migault" , "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 03:19:07 -0000 On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote: > > > > > I understand the meaning of count is the higher limit of ticket and the > > > server can provides any tickets between 0 and count. If that is > > > correct, this could be clearly stated and indication to chose an > > > appropriated value for each cases may be provided. > > > > The document states this: > > > > A supporting server MAY vend TicketRequestContents.count > > NewSessionTicket messages to a requesting client, and SHOULD NOT send > > more than TicketRequestContents.count NewSessionTicket messages to a > > requesting client. > > > > Is this not sufficient clear? If not, how can it be improved? > > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some > examples of "valid reasons in particular circumstances to ignore a > particular item" [RFC2119]. Otherwise, those requirements can be > cryptic, and perhaps better-described by MAY or MUST language. I understand, though I'm not sure more text is needed here. If you disagree, can you please suggest text to make it more clear? Thanks, Chris From nobody Wed Oct 2 20:20:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659B3120073 for ; Wed, 2 Oct 2019 20:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=gKmFqjT1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BYaCbi+w Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54rjRJnN3qbp for ; Wed, 2 Oct 2019 20:20:27 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B05E12006F for ; Wed, 2 Oct 2019 20:20:27 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id DE5CA52F for ; Wed, 2 Oct 2019 23:20:26 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 02 Oct 2019 23:20:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Jbwi828E6KHAMpBDiDUwD+OGfXYVzSj du1x2Ay6u+hI=; b=gKmFqjT1R8apN5XpNngXAh2GGl77vsMiW0XArcnReejcdyE 1Kw7A4qD/tCDtCvWSjMSAhNPyaMYuNi/drH4T+2mCO+cXiw6r22dtPfxrtnIAjaj 2DXa8GxbhTiULKtTdteAKsq5PhytNI2mvvnYvasbk70cWdufjeRM/sS+xOravWET KteFYonf2N2q4VqNwt/uePeBd5EQQa/9AN/8XVcPlBZTIu0attukNRyPYMwv3lrM /67CzH+EO7Ubd4NJwJa4Lff7xn36ISC1jFBM9uJnV0FDOiFOnu4kEZ0ceo0JJviO BFEY4oJnp47H7TVJXYxn6REnZIi31u5AuwsdSEQ== 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=Jbwi82 8E6KHAMpBDiDUwD+OGfXYVzSjdu1x2Ay6u+hI=; b=BYaCbi+w4HccbXYO3nyvWY NwDlE9shMtYnA3kuHGd9M5PTkh+R6BkoqpYnrHuJRX7H/ZE1IwD9hyGmn2Yt0ffl nCsq5wqUosrpChCEKsIcRsrXzTQ/+ONow6+y2C6cHy5NBzlqfhh2jptW4AMXT0ZB LGDS05qaVjOKdm7kPRs3keQKFH33VrnT84JmZYlCza0/5bzxdUZUf5eGZd5zn1Xj 3CoqL8+wfAqPC9sMQpjGwSTI+B1ZZf+17QU4T1divmC67OQrlAgo6rCNvPU2XlTi lyzRsTGl5RjWaliD3TZt9MlrOHjnxbh6e68K0i9R12NNsKd64eTQ9AOp0OVpe8Qw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrgeejgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrg ifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 548B93C00A2; Wed, 2 Oct 2019 23:20:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-359-g64bf1af-fmstable-20191002v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <20191002230402.GF5002@localhost> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org> <20191002230402.GF5002@localhost> Date: Wed, 02 Oct 2019 20:20:06 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 03:20:30 -0000 On Wed, Oct 2, 2019, at 4:04 PM, Nico Williams wrote: > On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > > I've read the draft, it looks quite useful and reasonable. It would > > be good to see this published. > > +1 > > > I have one idea (implemented in OpenSSL 1.1.1 on the server side) > > that may be worth mentioning in this context (and perhaps even the > > draft): > > > > - By default, OpenSSL TLS 1.3 servers only vend multiple (two) > > tickets on full handshakes. Resumed sessions issue just one > > ticket. > > > > This avoids unbounded linear growth in the number of tickets vended > > to a client that makes many resumed connections even after reaching > > its peak connection concurrency. > > Dumb clients that say they want so many tickets on resumption, and then > store them all, and don't clear out older tickets fast enough... can get > DoSed by a server than gives them what they asked for. > > This probably warrants a bit of text on the matter. Probably a SHOULD > saying that clients should ask for only one ticket in resumptions (i.e., > not use this extension) unless they are short of tickets. Asking for one upon resumption seems reasonable to me. Thanks to you and Viktor for bringing up this case! Best, Chris From nobody Wed Oct 2 20:44:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9631200C1 for ; Wed, 2 Oct 2019 20:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 UUrPi3HoNKSD for ; Wed, 2 Oct 2019 20:44:29 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BF212006F for ; Wed, 2 Oct 2019 20:44:29 -0700 (PDT) Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id A9DBD2A73D1 for ; Wed, 2 Oct 2019 23:44:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 2 Oct 2019 23:44:27 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org> <20191002230402.GF5002@localhost> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 03:44:32 -0000 > On Oct 2, 2019, at 11:20 PM, Christopher Wood = wrote: >=20 > Asking for one upon resumption seems reasonable to me. Thanks to you = and Viktor for bringing up this case! Thanks! Much appreciated. My other point, which I probably obscured in too many words, is that a client that prefers to re-use existing tickets, would normally want to ask for 0 new tickets, but this should not necessarily preclude the server from issuing one *as needed* (STEK rollover, ...). So there is a difference between a signal that tickets are simply not wanted, vs. wanted only *as needed*. Do you have any thoughts on how a client might signal this? The use-case is clients and servers that don't make use of early-data, and don't need to avoid traffic analysis. For example, MTA-to-MTA traffic, where the client even identifies in clear text with "EHLO". Here ticket reuse is the norm, and renewal is only needed as tickets age. [ I hope I managed an suitably concise description this time... ] --=20 --=20 Viktor. From nobody Wed Oct 2 21:24:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1748E120835 for ; Wed, 2 Oct 2019 21:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 rSX0UMMhUErK for ; Wed, 2 Oct 2019 21:23:59 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 2BF49120825 for ; Wed, 2 Oct 2019 21:23:58 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id a1so2433647ioc.6 for ; Wed, 02 Oct 2019 21:23:58 -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=bAVdVfRDNmMmXwK5H+jmJBN0+3f2+NADH0xa4+hn2/8=; b=CwHlVM34sB0d/+6lL2QAM2skDmcleX2SZtXhPVVT+lIR5suvqqlTtM/7Vx+6AZ1RuA OWqmq2Yc3kp3L+hnuYQsLG/nBAEuY/bfhusZFqfsCm7eRBoGeMdRsOE/crr+0NIptxuU DdJiEqleyftOjN133vNl+ThXWHJy+oppyJBr0uGHm+3EupYBCYLjY1OqHL30O8KO+Btb Hj8Gpwal8E38bwb7EmFNz0FECM88xEO1gmyTlLSNX8Cbn7GkdXBme6JT7fGgu6xo9CYH V6Ml9M2P+cUYK5wURW1bTbbVXykP/6H4Imsedp9sSh7krpp5HhZrlZSxKeS3A51g1ybY q0UQ== 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=bAVdVfRDNmMmXwK5H+jmJBN0+3f2+NADH0xa4+hn2/8=; b=jz4yuTFZXhfUxaqnaoczVtkb/B+4FpsA4kO98kLnFdVEMxzfAKSIg+MtGV5Bu9XDMk WgoELQ57mUDT1a1GsNd9wvxcQMtppg3scv+5r97GsM/jrGXijfn09qAVhIcX2OWKBRZS pMbsutplQlqRxPx1o/+ur4sDX6lnhXZwnS7SWAM+JFmIQap1UmaZVJfGbhVpyTZSej7C HfOTbSRcUeffvSuWPD9pCmcxrqx/6pcMUdf463WrqqH0LqVmpss0ljKREVX+IzF/hRXh mVCHNl7aBkIk0h0jC+wu93lB9UfWKRvePLPRpK+c+595RNZvsZQ76XCCtWM1/kBI5PEx QZDg== X-Gm-Message-State: APjAAAVH9KWzej+z0zpm8Ybc+7SaFZjhDWzfxx4CgSOYwddDf2e5d7LC 12w9HLjj3a2EydESjUHuQqeasvB1C/FXI38GbutOPWTOZKOgoA== X-Google-Smtp-Source: APXvYqwf9MtZjZCxf9VKs+oG8BbvEzydccm9eqqdPPgnPKboZr9Eqcxp2e9Dk7E/5ZuWPoRw/LYGGw9NhetnLeAwzpg= X-Received: by 2002:a02:c049:: with SMTP id u9mr7744641jam.131.1570076637813; Wed, 02 Oct 2019 21:23:57 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <1971068.D9yiD15FoS@pintsize.usersys.redhat.com> <851aded9-70a7-4a9a-abd5-b75f98f86baf@www.fastmail.com> <1708345.JU3unZtj4k@pintsize.usersys.redhat.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> <945ac286-bb40-4a41-8612-3183f28b68e5@www.fastmail.com> <16d1473c-8ee9-4007-b71e-eef38134d331@www.fastmail.com> In-Reply-To: <16d1473c-8ee9-4007-b71e-eef38134d331@www.fastmail.com> From: Rob Sayre Date: Thu, 3 Oct 2019 11:23:45 +0700 Message-ID: To: Christopher Wood Cc: Daniel Migault , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000445f5d0593f9f4a6" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 04:24:03 -0000 --000000000000445f5d0593f9f4a6 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood wrote: > On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood > wrote: > > > > > > > I understand the meaning of count is the higher limit of ticket and > the > > > > server can provides any tickets between 0 and count. If that is > > > > correct, this could be clearly stated and indication to chose an > > > > appropriated value for each cases may be provided. > > > > > > The document states this: > > > > > > A supporting server MAY vend TicketRequestContents.count > > > NewSessionTicket messages to a requesting client, and SHOULD NOT send > > > more than TicketRequestContents.count NewSessionTicket messages to a > > > requesting client. > > > > > > Is this not sufficient clear? If not, how can it be improved? > > > > RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer with some > > examples of "valid reasons in particular circumstances to ignore a > > particular item" [RFC2119]. Otherwise, those requirements can be > > cryptic, and perhaps better-described by MAY or MUST language. > > I understand, though I'm not sure more text is needed here. If you > disagree, can you please suggest text to make it more clear? > The current text the describes the interaction well enough, but I don't understand the requirement. I can suggest two alternatives: 1) A supporting server [...] MAY send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. The client might not be able to use all of them. 2) A supporting server [...] MUST NOT send more than TicketRequestContents.count NewSessionTicket messages to a requesting client. The draft uses "SHOULD NOT". Why is that? Perhaps that trailing sentence I added to 1) seems obvious to the authors? I did not automatically assume the consequences of sending extra NewSessionTicket messages would be so innocuous. If that's the case, it seems like MAY would be better, since clients need to handle extra NewSessionTicket messages, even if they just discard them. thanks, Rob --000000000000445f5d0593f9f4a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 3, 2019 at 10:19 AM Chris= topher Wood <caw@heapingbits.net<= /a>> wrote:
O= n Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood <caw@heapingbits.net> wrote: > >
> >=C2=A0 > I understand the meaning of count is the higher limit = of ticket and the
> >=C2=A0 > server can provides any tickets between 0 and count. I= f that is
> >=C2=A0 > correct, this could be clearly stated and indication t= o chose an
> >=C2=A0 > appropriated value for each cases may be provided. > >
> >=C2=A0 The document states this:
> >
> >=C2=A0 A supporting server MAY vend TicketRequestContents.count > >=C2=A0 NewSessionTicket messages to a requesting client, and SHOUL= D NOT send
> >=C2=A0 more than TicketRequestContents.count NewSessionTicket mess= ages to a
> >=C2=A0 requesting client.
> >
> >=C2=A0 Is this not sufficient clear? If not, how can it be improve= d?
>
> RFC2119 "SHOULD/SHOULD NOT" requirements are usually clearer= with some
> examples of "valid reasons in particular circumstances to ignore = a
> particular item" [RFC2119]. Otherwise, those requirements can be =
> cryptic, and perhaps better-described by MAY or MUST language.

I understand, though I'm not sure more text is needed here. If you disa= gree, can you please suggest text to make it more clear?

The current text the describes the interaction well enoug= h, but I don't understand the requirement. I can suggest two alternativ= es:

1) A supporting server [...] MAY send more tha= n TicketRequestContents.count NewSessionTicket messages to a requesting cli= ent. The client might not be able to use all of them.
2) A suppor= ting server [...] MUST NOT send more than TicketRequestContents.count NewSe= ssionTicket messages to a requesting client.

The d= raft uses "SHOULD NOT". Why is that? Perhaps that trailing senten= ce I added to 1) seems obvious to the authors? I did not automatically assu= me the consequences of sending extra=C2=A0NewSessionTicket messages would b= e so innocuous. If that's the case, it seems like MAY would be better, = since clients need to handle extra=C2=A0NewSessionTicket messages, even if = they just discard them.

thanks,
Rob
--000000000000445f5d0593f9f4a6-- From nobody Thu Oct 3 04:55:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE52120232 for ; Thu, 3 Oct 2019 04:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 gUEA5pvmE9yW for ; Thu, 3 Oct 2019 04:55:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77D6C12011A for ; Thu, 3 Oct 2019 04:55:21 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E5888125C; Thu, 3 Oct 2019 11:55:20 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 625146013A; Thu, 3 Oct 2019 11:55:19 +0000 (UTC) From: Hubert Kario To: Daniel Migault Cc: Christopher Wood , "TLS@ietf.org" Date: Thu, 03 Oct 2019 13:55:10 +0200 Message-ID: <2328460.Fs94otCilB@pintsize.usersys.redhat.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2255254.vObBVBeLRa"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Thu, 03 Oct 2019 11:55:20 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 11:55:26 -0000 --nextPart2255254.vObBVBeLRa Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > I understand the meaning of count is the higher limit of ticket and the > server can provides any tickets between 0 and count. If that is correct, > this could be clearly stated and indication to chose an appropriated value > for each cases may be provided. >=20 > I would rather see the count value as a hard line from the server with a > MUST NOT instead of a SHOULD NOT statement. see my previous comments: this ignores existence of post handshake=20 authentication, ticket lifetimes and KeyUpdate =20 > The ability to request 255 tickets with one byte can be seen as an > amplification vector, especially when a server sends directly the tickets > after its Finished message. I believe that additional text in the security > consideration could be added. true =20 > Yours, > Daniel >=20 > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood wro= te: > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > > ``` > > > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > > > ``` > > > > > > >=20 > > > > > > > per what? session? at a time? connection? > > > > > >=20 > > > > > > This is all per session. We can state it explicitly in the next > >=20 > > version. > >=20 > > > > > so this count needs to be kept as part of session and impacts > >=20 > > connections > >=20 > > > > > that perform resumption? > > > >=20 > > > > Sorry, I meant connection: > > > > "Clients may indicate to servers their desired number of tickets > >=20 > > for *a > >=20 > > > > single connection* via the following "ticket_request" extension" > > > >=20 > > > > This is a simple hint for servers. Nothing more. No state needs to = be > >=20 > > stored > >=20 > > > > past connection establishment. > > >=20 > > > sounds good > > >=20 > > > > > > > what's the expected behaviour with tickets and post-handshake > > > > > > > authentication? Are tickets sent after PHA also bound by this > >=20 > > limit? > >=20 > > > > > > As mentioned earlier, there is no effect, so we left it out. We= 're > >=20 > > happy > >=20 > > > > > > to > > > > > > accept text should you think it's needed. > > > > >=20 > > > > > If the I-D states that servers should not send more tickets than = the > > > > > client > > > > > asked for, and then send exactly that amount, then they won't be > >=20 > > able to > >=20 > > > > > send new tickets after PHA and remain compliant. > > > > >=20 > > > > > Yes, it's completely up to the server to decide if to send tickets > >=20 > > after > >=20 > > > > > PHA or not, and I'm not suggesting that the client should request > > > > > for > > > > > tickets in one of its PHA messages, much less expect or require > >=20 > > them, but > >=20 > > > > > sending tickets after PHA is reasonable and explicitly stated > >=20 > > behaviour: > > > > > RFC 8446 Section 4.6.1: > > > > > For instance, the server might send a new > > > > > ticket after post-handshake authentication in order to > > > > > encapsulate > > > > > the additional client authentication state. > > > > >=20 > > > > > so the I-D should explicitly state what's the expected behaviour = in > >=20 > > that > >=20 > > > > > case. > > > > >=20 > > > > > IMHO, the extension should be used for the tickets sent right aft= er > >=20 > > the > >=20 > > > > > handshake, it should not put an upper bound for the tickets that a > >=20 > > server > >=20 > > > > > can send in a single connection. For a very long lived connection > > > > > (especially if the connection uses KeyUpdate messages regularly), > > > > > the > > > > > initial tickets may expire. Server may notice that and send a new > >=20 > > group > >=20 > > > > > of tickets then. > > > >=20 > > > > Since these hints are not mandatory to honor I don't think we need = to > > > > describe this case. In particular, this is a valid case where ignor= ing > >=20 > > the > >=20 > > > > SHOULD is fine, in my opinion. > > > >=20 > > > > If the draft required that servers MUST NOT send more tickets than > >=20 > > what's > >=20 > > > > requested, then yes, I think these details would be important. > > >=20 > > > huh? I see the following in the draft-02: > > > Servers MUST NOT > > > send more than 255 tickets to clients. > >=20 > > I was referring to the "SHOULD NOT send more than > > TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, t= he > > MUST NOT above should also be a SHOULD NOT. Thanks for your patience in > > working through the kinks! > >=20 > > > -- > > > Regards, > > > Hubert Kario > > > Senior Quality Engineer, QE BaseOS Security team > > > Web: www.cz.redhat.com > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > > Attachments: > > > * signature.asc > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2255254.vObBVBeLRa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2V4Z4ACgkQkqjRuAHS 9fXEXQ/+IK0ac58KtBY048c5LGk87gtpDdZsnRdObquEI3uAXgHO0l5CIJ4oOVyj Htbx53NYMoR08V8vHmVg7v4ubSV2mH+s1tFVfzBseTu56Ubjw4kg8Qay6F6uPGMK B38qjzR3YQVtDm4YjhP8TpbA0ZhDHjk5AG+RfDsFpvynZ32DKCvVMINdWqZ3/XZ2 MtCd6VFi5fyobErM1991wdQyPZ4se65WLuqnQ4sFejoH1xEG1AUXwE3Zbdx0cdRZ 5fKJrsWG1oKo4L5QB7bv/qLMyMimmAI3j3fBr15VPrCyBw3OBhQnz4d9O5QFjEeo m3BG7rxi4zlD/H7AImH1Z1PaB8h8pADyN/tPnhOIndHBFXxdv4hpok2ZkdsTnApP YdPjj9XJQ8/Xv2Yfhb5TwY22KiNOIjYlEY7Vic2TIGehQlvXzTc6X0KvogHXa7es TFu3/uuGveqhjECBJbLKpRdGrAb0lA7E8GNbJwTg/i3aYccPMBUYJLgyp6wxKuR2 6IleLipMGEbsjn5XnBDShv1EiFEMfbktpiOEoCzWi5jlntB0FANEWvWtawBQk1QC IKck8gPvwsg+4U8JbrAAvKc0jWZCsNtU7RQvAUxP7iXvPxJaz2o98MXLcVCBB6lH AVzhtPv+fWYO2qZeGPTrukP2SPr6SDkk1XVumMItVv2AiLRCpBc= =qKOo -----END PGP SIGNATURE----- --nextPart2255254.vObBVBeLRa-- From nobody Thu Oct 3 11:39:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841DF1200EF for ; Thu, 3 Oct 2019 11:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nZ3W7Jvzt25o for ; Thu, 3 Oct 2019 11:39:26 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0051200D6 for ; Thu, 3 Oct 2019 11:39:26 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2ECC518CB8EF for ; Thu, 3 Oct 2019 18:39:26 +0000 (UTC) Received: from rrelyea-laptop.localdomain (unknown [10.14.72.154]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE928600CD for ; Thu, 3 Oct 2019 18:39:25 +0000 (UTC) To: tls@ietf.org References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <62ee0774-5667-43a3-b5fa-144d52c04c4d@www.fastmail.com> <7775c911-5355-ba17-b8b3-7c3e00c03043@wizmail.org> <1730830.Bn5YTEkoct@pintsize.usersys.redhat.com> From: Robert Relyea Message-ID: <6279e16d-1e93-526f-c750-883d86ee2e97@REDHAT.COM> Date: Thu, 3 Oct 2019 11:39:25 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1730830.Bn5YTEkoct@pintsize.usersys.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-MW X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.63]); Thu, 03 Oct 2019 18:39:26 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 18:39:30 -0000 On 10/01/2019 04:39 AM, Hubert Kario wrote: > On Monday, 30 September 2019 15:56:19 CEST Jeremy Harris wrote: >> On 30/09/2019 14:36, Christopher Wood wrote: >>> On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote: >>>> Clients must therefore >>>> bound the number of parallel connections they initiate by the >>>> number of tickets in their possession, or risk ticket re-use. >>>> >>>> ``` >>>> >>>> I'm not a native speaker, but shouldn't it be "...therefore bind the >>>> number..."? >>> Yes, we can fix it in the next version. >> "Bound" reads correctly to me. You could spell it out in detail >> if it is thought confusing: >> >> "Clients must therefore not start a number of parallel connections >> larger than the number of tickets in their possession" > "bound" would work also like this: > > "The number of parallel connections the clients can initiate is bound by > the number of tickets in their possession." > That would be 'is bounded by' bound as a past participle/adjective of bind means to connect to. (in which case you would use bound with) bound as a verb means to constrain or set limits on, it's past participle is bounded. Maybe we should use Jeremy's construction which avoids the word, since it's bound to cause confusion (sorry couldn't resist the pun, as well as noting another reason to avoid the word in a spec that has to be parsed by non-native speakers;). bob From nobody Thu Oct 3 13:15:32 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AAD120241 for ; Thu, 3 Oct 2019 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Q3Lf5tQ06oO9 for ; Thu, 3 Oct 2019 13:15:28 -0700 (PDT) Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (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 95D931200B7 for ; Thu, 3 Oct 2019 13:15:28 -0700 (PDT) Received: by mail-ua1-f45.google.com with SMTP id n63so1352435uan.2 for ; Thu, 03 Oct 2019 13:15:28 -0700 (PDT) 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=TFAoEQ09k4tqhP5CxN855+ZVi6zH7MI+RT/WWGg+5jM=; b=N0ZWOVgS/hCKdIIx9NVNsQcjJBRWgc+0aP1mBz+NIxDSBwE9L1t8NkIbsP+zTuxM/N Wa3tvIqOPohOJt9o9kHxNTrPAYD2CSSB9XB8OlqmY8Tl69zduUUk/o1+zmeabjarHM4X aP1OprCYZhY0vy4CjuabaGq6b4XBb19mulJbjBcTZk6P64VvBIERGmzq3l8HiSy7yJUz YVtmGk4YRAbocp1+sPxoIhRwiM/NCZlxfEU/Q88ldUgxUAYxkYhVaDwTgXRRbtMrw+dQ LRZCCr7smlLM7TmXmHkQBh7/AFI3zVJups/YuXDpRgnocAseq1FRFHa70nF9N1BHgPBq dL0w== X-Gm-Message-State: APjAAAWaHJKuOj0c5/7+qsi0a/F2ENG8IKKUHp9mBw8aJqYhHqj8ntOZ w8tuIO/K7DxGPx/KMZmxqCa8gaessJ6dO6xB8Xw= X-Google-Smtp-Source: APXvYqzUfIJF1T+HR/1UWh1B/qh+8hmuiHkeCz9TktDP3dZpxEhtI6cmoEMMYSBf7v3gkn3YuImHUB3l1n4+LMbjbtc= X-Received: by 2002:ab0:76d1:: with SMTP id w17mr5490481uaq.114.1570133727543; Thu, 03 Oct 2019 13:15:27 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <350020eb-c43b-4941-93e9-06ea9a0cacc3@www.fastmail.com> <2328460.Fs94otCilB@pintsize.usersys.redhat.com> In-Reply-To: <2328460.Fs94otCilB@pintsize.usersys.redhat.com> From: Daniel Migault Date: Thu, 3 Oct 2019 16:15:14 -0400 Message-ID: To: Hubert Kario Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001485980594073f63" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 03 Oct 2019 20:15:31 -0000 --0000000000001485980594073f63 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is correct= , > > this could be clearly stated and indication to chose an appropriated > value > > for each cases may be provided. > > > > I would rather see the count value as a hard line from the server with = a > > MUST NOT instead of a SHOULD NOT statement. > > see my previous comments: this ignores existence of post handshake > authentication, ticket lifetimes and KeyUpdate > > I think we agree on the problem which is it is hard to have a specific count as tickets may be sent at multiple time during the key exchange or the later during the session. If the "SHOULD" is addressing this aspect I believe that more text is needed.. From my perspective, what I proposed I imagined that count was related to the maximum number of ticket provided **each time the server is sending tickets**. The reason for having the same number is that the server does not know how the client will use these tickets and the client does not know precisely when the server sends the tickets. So at the end the number of tickets sent is likely to be n*count when n represents the number of times during the session tickets are provided. My understanding of the SHOULD is that it makes legitimate for a server to ignore the count value provided by the client. > > The ability to request 255 tickets with one byte can be seen as an > > amplification vector, especially when a server sends directly the ticke= ts > > after its Finished message. I believe that additional text in the > security > > consideration could be added. > > true > > > Yours, > > Daniel > > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood > wrote: > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > > > ``` > > > > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > > > > ``` > > > > > > > > > > > > > > > > per what? session? at a time? connection? > > > > > > > > > > > > > > This is all per session. We can state it explicitly in the ne= xt > > > > > > version. > > > > > > > > > so this count needs to be kept as part of session and impacts > > > > > > connections > > > > > > > > > that perform resumption? > > > > > > > > > > Sorry, I meant connection: > > > > > "Clients may indicate to servers their desired number of ticke= ts > > > > > > for *a > > > > > > > > single connection* via the following "ticket_request" extension" > > > > > > > > > > This is a simple hint for servers. Nothing more. No state needs t= o > be > > > > > > stored > > > > > > > > past connection establishment. > > > > > > > > sounds good > > > > > > > > > > > > what's the expected behaviour with tickets and post-handsha= ke > > > > > > > > authentication? Are tickets sent after PHA also bound by th= is > > > > > > limit? > > > > > > > > > > As mentioned earlier, there is no effect, so we left it out. > We're > > > > > > happy > > > > > > > > > > to > > > > > > > accept text should you think it's needed. > > > > > > > > > > > > If the I-D states that servers should not send more tickets tha= n > the > > > > > > client > > > > > > asked for, and then send exactly that amount, then they won't b= e > > > > > > able to > > > > > > > > > send new tickets after PHA and remain compliant. > > > > > > > > > > > > Yes, it's completely up to the server to decide if to send > tickets > > > > > > after > > > > > > > > > PHA or not, and I'm not suggesting that the client should reque= st > > > > > > for > > > > > > tickets in one of its PHA messages, much less expect or require > > > > > > them, but > > > > > > > > > sending tickets after PHA is reasonable and explicitly stated > > > > > > behaviour: > > > > > > RFC 8446 Section 4.6.1: > > > > > > For instance, the server might send a new > > > > > > ticket after post-handshake authentication in order to > > > > > > encapsulate > > > > > > the additional client authentication state. > > > > > > > > > > > > so the I-D should explicitly state what's the expected behaviou= r > in > > > > > > that > > > > > > > > > case. > > > > > > > > > > > > IMHO, the extension should be used for the tickets sent right > after > > > > > > the > > > > > > > > > handshake, it should not put an upper bound for the tickets tha= t > a > > > > > > server > > > > > > > > > can send in a single connection. For a very long lived connecti= on > > > > > > (especially if the connection uses KeyUpdate messages regularly= ), > > > > > > the > > > > > > initial tickets may expire. Server may notice that and send a n= ew > > > > > > group > > > > > > > > > of tickets then. > > > > > > > > > > Since these hints are not mandatory to honor I don't think we nee= d > to > > > > > describe this case. In particular, this is a valid case where > ignoring > > > > > > the > > > > > > > > SHOULD is fine, in my opinion. > > > > > > > > > > If the draft required that servers MUST NOT send more tickets tha= n > > > > > > what's > > > > > > > > requested, then yes, I think these details would be important. > > > > > > > > huh? I see the following in the draft-02: > > > > Servers MUST NOT > > > > send more than 255 tickets to clients. > > > > > > I was referring to the "SHOULD NOT send more than > > > TicketRequestContents.count NewSessionTicket messages" blurb. Indeed, > the > > > MUST NOT above should also be a SHOULD NOT. Thanks for your patience = in > > > working through the kinks! > > > > > > > -- > > > > Regards, > > > > Hubert Kario > > > > Senior Quality Engineer, QE BaseOS Security team > > > > Web: www.cz.redhat.com > > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Repub= lic > > > > Attachments: > > > > * signature.asc > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001485980594073f63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 3, 2019 at 7:56 AM Hubert= Kario <hkario@redhat.com> w= rote:
On Wednesd= ay, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> I understand the meaning of count is the higher limit of ticket and th= e
> server can provides any tickets between 0 and count. If that is correc= t,
> this could be clearly stated and indication to chose an appropriated v= alue
> for each cases may be provided.
>
> I would rather see the count value as a hard line from the server with= a
> MUST NOT instead of a SHOULD NOT statement.

see my previous comments: this ignores existence of post handshake
authentication, ticket lifetimes and KeyUpdate


I think we agree on the problem which = is it is hard to have a specific count as tickets may be sent at multiple t= ime during the key exchange or the later during the session. If the "S= HOULD" is addressing=C2=A0this aspect I believe=C2=A0that more text is= needed.. From my perspective, what I proposed=C2=A0 I imagined that count = was related to the maximum number of ticket provided **each time the server= is sending tickets**. The reason for having the same number is that the se= rver does not know how the client will use these tickets and the client doe= s not know precisely when the server sends the tickets. So at the end the n= umber of tickets sent is likely to be n*count when n represents the number = of times during the session tickets are provided.=C2=A0

My understanding of the SHOULD is that it makes legitimate for a serv= er to ignore the count value provided by the client.

=C2=A0=C2=A0
> The ability to request 255 tickets with one byte can be seen as an
> amplification vector, especially when a server sends directly the tick= ets
> after its Finished message. I believe that additional text in the secu= rity
> consideration could be added.

true

> Yours,
> Daniel
>
> On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <caw@heapingbits.net> wrote: > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wr= ote:
> > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > > ```
> > > > > > > Servers MUST NOT send more than 255 tick= ets to clients.
> > > > > > > ```
> > > > > > >
> > > > > > > per what? session? at a time? connection= ?
> > > > > >
> > > > > > This is all per session. We can state it expl= icitly in the next
> >
> > version.
> >
> > > > > so this count needs to be kept as part of session = and impacts
> >
> > connections
> >
> > > > > that perform resumption?
> > > >
> > > > Sorry, I meant connection:
> > > >=C2=A0 =C2=A0 "Clients may indicate to servers thei= r desired number of tickets
> >
> > for *a
> >
> > > > single connection* via the following "ticket_reque= st" extension"
> > > >
> > > > This is a simple hint for servers. Nothing more. No sta= te needs to be
> >
> > stored
> >
> > > > past connection establishment.
> > >
> > > sounds good
> > >
> > > > > > > what's the expected behaviour with t= ickets and post-handshake
> > > > > > > authentication? Are tickets sent after P= HA also bound by this
> >
> > limit?
> >
> > > > > > As mentioned earlier, there is no effect, so = we left it out. We're
> >
> > happy
> >
> > > > > > to
> > > > > > accept text should you think it's needed.=
> > > > >
> > > > > If the I-D states that servers should not send mor= e tickets than the
> > > > > client
> > > > > asked for, and then send exactly that amount, then= they won't be
> >
> > able to
> >
> > > > > send new tickets after PHA and remain compliant. > > > > >
> > > > > Yes, it's completely up to the server to decid= e if to send tickets
> >
> > after
> >
> > > > > PHA or not, and I'm not suggesting that the cl= ient should request
> > > > > for
> > > > > tickets in one of its PHA messages, much less expe= ct or require
> >
> > them, but
> >
> > > > > sending tickets after PHA is reasonable and explic= itly stated
> >
> > behaviour:
> > > > > RFC 8446 Section 4.6.1:
> > > > >=C2=A0 =C2=A0 For instance, the server might send a= new
> > > > >=C2=A0 =C2=A0 ticket after post-handshake authentic= ation in order to
> > > > >=C2=A0 =C2=A0 encapsulate
> > > > >=C2=A0 =C2=A0 the additional client authentication = state.
> > > > >
> > > > > so the I-D should explicitly state what's the = expected behaviour in
> >
> > that
> >
> > > > > case.
> > > > >
> > > > > IMHO, the extension should be used for the tickets= sent right after
> >
> > the
> >
> > > > > handshake, it should not put an upper bound for th= e tickets that a
> >
> > server
> >
> > > > > can send in a single connection. For a very long l= ived connection
> > > > > (especially if the connection uses KeyUpdate messa= ges regularly),
> > > > > the
> > > > > initial tickets may expire. Server may notice that= and send a new
> >
> > group
> >
> > > > > of tickets then.
> > > >
> > > > Since these hints are not mandatory to honor I don'= t think we need to
> > > > describe this case. In particular, this is a valid case= where ignoring
> >
> > the
> >
> > > > SHOULD is fine, in my opinion.
> > > >
> > > > If the draft required that servers MUST NOT send more t= ickets than
> >
> > what's
> >
> > > > requested, then yes, I think these details would be imp= ortant.
> > >
> > > huh? I see the following in the draft-02:
> > >=C2=A0 =C2=A0 Servers MUST NOT
> > >=C2=A0 =C2=A0 send more than 255 tickets to clients.
> >
> > I was referring to the "SHOULD NOT send more than
> > TicketRequestContents.count NewSessionTicket messages" blurb= . Indeed, the
> > MUST NOT above should also be a SHOULD NOT. Thanks for your patie= nce in
> > working through the kinks!
> >
> > > --
> > > Regards,
> > > Hubert Kario
> > > Senior Quality Engineer, QE BaseOS Security team
> > > Web: www.cz.redhat.com
> > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno,= Czech Republic
> > > Attachments:
> > > * signature.asc
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001485980594073f63-- From nobody Thu Oct 3 17:11:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9EC120889; Thu, 3 Oct 2019 17:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 ABNdlbWqIXbF; Thu, 3 Oct 2019 17:11:54 -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 DB3D912006E; Thu, 3 Oct 2019 17:11:53 -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 x940BgOT023643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Oct 2019 20:11:45 -0400 Date: Thu, 3 Oct 2019 17:11:42 -0700 From: Benjamin Kaduk To: John Mattsson Cc: Stephen Farrell , Sean Turner , Sean Turner via Datatracker , "tls-chairs@ietf.org" , IESG Secretary , "tls@ietf.org" Message-ID: <20191004001142.GF6424@kduck.mit.edu> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Fri, 04 Oct 2019 00:11:56 -0000 On Wed, Oct 02, 2019 at 02:45:08PM +0000, John Mattsson wrote: > Hi, > > Sean Turner wrote: > > "You can change the text, but I do not believe it will change the implementations." > > I would much rather have a future proof RFC that forbids negotiation of DTLS 1.0 with the knowledge that some implementations will temporary violate that, than having an RFC that long time in the future allows negotiation and use of DTLS 1.0. > > > Eric Rescorla wrote: > > "result of some pretty extensive discussion and compromising in rtcweb" > > That does not surprise me, but I think that is part of the problem. These > things should mainly be decided by the TLS working group. How? Just by publishing BCPs, or is the TLS WG also supposed to (e.g.) watch IETF LCs and complain about use of old protocol versions? > Draft-ietf-rtcweb-security-arch mandated DTLS 1.0 until Nov 2018. That is > half a year after the "Deprecating TLSv1.0 and TLSv1.1" draft was > submitted and almost 7 years after DTLS 1.0 was made obsolete. Mandating (D)TLS 1.0 is not going to get past the IESG in 2018. We can (and are) try to better communicate our expectations for this sort of thing to the WGs, but it seems unrealistic to expect a 100% success rate from them, since it's usually not the WG's core competency. (See also https://mailarchive.ietf.org/arch/msg/wgchairs/dfe_5obSQm7YK7JzVbmc-MbXNmU .) > > No matter what is done in this particular case, I think the important thing to discuss is how we avoid drafts that only support obsolete versions of TLS/DTLS in the future. According to my understanding of the comments in the thread "Lessons learned from TLS 1.0 and TLS 1.1 deprecation", both me, Kathleen Moriarty, and Martin Thomson understands obsoleted as: > > "New implementations and deployments MUST include support of the new version". > > If this is not clearly defined somewhere, I think it needs to be specified. If it is specified somewhere, IETF needs to make sure to follow apply it. Even supposing everyone agrees on this, there seem to be some fencepost issues surrounding "new". Is a protocol "new" when it gets published as an RFC, or at WGLC, or even earlier? I have been pretty laid-back until now about requiring things coming in front of the IESG to pick up TLS 1.3, since for the most part they were in progress (including implementations) before TLS 1.3 implementations were readily available in production-grade form. It's about time to tighten up on that, since it's been over a year since RFC 8446, but I'm not sure I fully understand where you want us to fall across these boundary conditions. -Ben From nobody Fri Oct 4 06:17:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF4412082B for ; Fri, 4 Oct 2019 06:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 oMDOMiAXHRTr for ; Fri, 4 Oct 2019 06:17:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59AE812008C for ; Fri, 4 Oct 2019 06:17:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C4880C01092E; Fri, 4 Oct 2019 13:17:16 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A1335C1D8; Fri, 4 Oct 2019 13:17:15 +0000 (UTC) From: Hubert Kario To: Daniel Migault Cc: "TLS@ietf.org" Date: Fri, 04 Oct 2019 15:17:15 +0200 Message-ID: <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <2328460.Fs94otCilB@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3227776.MxLprl8Xxt"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 04 Oct 2019 13:17:16 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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, 04 Oct 2019 13:17:21 -0000 --nextPart3227776.MxLprl8Xxt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > I understand the meaning of count is the higher limit of ticket and t= he > > > server can provides any tickets between 0 and count. If that is corre= ct, > > > this could be clearly stated and indication to chose an appropriated > >=20 > > value > >=20 > > > for each cases may be provided. > > >=20 > > > I would rather see the count value as a hard line from the server wit= h a > > > MUST NOT instead of a SHOULD NOT statement. > >=20 > > see my previous comments: this ignores existence of post handshake > > authentication, ticket lifetimes and KeyUpdate >=20 > I think we agree on the problem which is it is hard to have a specific > count as tickets may be sent at multiple time during the key exchange or > the later during the session. If the "SHOULD" is addressing this aspect I > believe that more text is needed.. From my perspective, what I proposed I > imagined that count was related to the maximum number of ticket provided > **each time the server is sending tickets**. The reason for having the sa= me > number is that the server does not know how the client will use these > tickets and the client does not know precisely when the server sends the > tickets. So at the end the number of tickets sent is likely to be n*count > when n represents the number of times during the session tickets are > provided. >=20 > My understanding of the SHOULD is that it makes legitimate for a server to > ignore the count value provided by the client. yes, it looks like we are in agreement Sounds like something that should be spelled out explicitly in the draft. I= =2Ee.=20 it should talk about groups of tickets, not tickets in connection, and it=20 should definitely not specify the maximum number of tickets a server can se= nd=20 in a connection. =20 > > > The ability to request 255 tickets with one byte can be seen as an > > > amplification vector, especially when a server sends directly the > > > tickets > > > after its Finished message. I believe that additional text in the > >=20 > > security > >=20 > > > consideration could be added. > >=20 > > true > >=20 > > > Yours, > > > Daniel > > >=20 > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood > >=20 > > wrote: > > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > > > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote: > > > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > > > > ``` > > > > > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > > > > > ``` > > > > > > > > >=20 > > > > > > > > > per what? session? at a time? connection? > > > > > > > >=20 > > > > > > > > This is all per session. We can state it explicitly in the > > > > > > > > next > > > >=20 > > > > version. > > > >=20 > > > > > > > so this count needs to be kept as part of session and impacts > > > >=20 > > > > connections > > > >=20 > > > > > > > that perform resumption? > > > > > >=20 > > > > > > Sorry, I meant connection: > > > > > > "Clients may indicate to servers their desired number of > > > > > > tickets > > > >=20 > > > > for *a > > > >=20 > > > > > > single connection* via the following "ticket_request" extension" > > > > > >=20 > > > > > > This is a simple hint for servers. Nothing more. No state needs= to > >=20 > > be > >=20 > > > > stored > > > >=20 > > > > > > past connection establishment. > > > > >=20 > > > > > sounds good > > > > >=20 > > > > > > > > > what's the expected behaviour with tickets and > > > > > > > > > post-handshake > > > > > > > > > authentication? Are tickets sent after PHA also bound by > > > > > > > > > this > > > >=20 > > > > limit? > > > >=20 > > > > > > > > As mentioned earlier, there is no effect, so we left it out. > >=20 > > We're > >=20 > > > > happy > > > >=20 > > > > > > > > to > > > > > > > > accept text should you think it's needed. > > > > > > >=20 > > > > > > > If the I-D states that servers should not send more tickets t= han > >=20 > > the > >=20 > > > > > > > client > > > > > > > asked for, and then send exactly that amount, then they won't= be > > > >=20 > > > > able to > > > >=20 > > > > > > > send new tickets after PHA and remain compliant. > > > > > > >=20 > > > > > > > Yes, it's completely up to the server to decide if to send > >=20 > > tickets > >=20 > > > > after > > > >=20 > > > > > > > PHA or not, and I'm not suggesting that the client should > > > > > > > request > > > > > > > for > > > > > > > tickets in one of its PHA messages, much less expect or requi= re > > > >=20 > > > > them, but > > > >=20 > > > > > > > sending tickets after PHA is reasonable and explicitly stated > > > >=20 > > > > behaviour: > > > > > > > RFC 8446 Section 4.6.1: > > > > > > > For instance, the server might send a new > > > > > > > ticket after post-handshake authentication in order to > > > > > > > encapsulate > > > > > > > the additional client authentication state. > > > > > > >=20 > > > > > > > so the I-D should explicitly state what's the expected behavi= our > >=20 > > in > >=20 > > > > that > > > >=20 > > > > > > > case. > > > > > > >=20 > > > > > > > IMHO, the extension should be used for the tickets sent right > >=20 > > after > >=20 > > > > the > > > >=20 > > > > > > > handshake, it should not put an upper bound for the tickets t= hat > >=20 > > a > >=20 > > > > server > > > >=20 > > > > > > > can send in a single connection. For a very long lived > > > > > > > connection > > > > > > > (especially if the connection uses KeyUpdate messages > > > > > > > regularly), > > > > > > > the > > > > > > > initial tickets may expire. Server may notice that and send a > > > > > > > new > > > >=20 > > > > group > > > >=20 > > > > > > > of tickets then. > > > > > >=20 > > > > > > Since these hints are not mandatory to honor I don't think we n= eed > >=20 > > to > >=20 > > > > > > describe this case. In particular, this is a valid case where > >=20 > > ignoring > >=20 > > > > the > > > >=20 > > > > > > SHOULD is fine, in my opinion. > > > > > >=20 > > > > > > If the draft required that servers MUST NOT send more tickets t= han > > > >=20 > > > > what's > > > >=20 > > > > > > requested, then yes, I think these details would be important. > > > > >=20 > > > > > huh? I see the following in the draft-02: > > > > > Servers MUST NOT > > > > > send more than 255 tickets to clients. > > > >=20 > > > > I was referring to the "SHOULD NOT send more than > > > > TicketRequestContents.count NewSessionTicket messages" blurb. Indee= d, > >=20 > > the > >=20 > > > > MUST NOT above should also be a SHOULD NOT. Thanks for your patience > > > > in > > > > working through the kinks! > > > >=20 > > > > > -- > > > > > Regards, > > > > > Hubert Kario > > > > > Senior Quality Engineer, QE BaseOS Security team > > > > > Web: www.cz.redhat.com > > > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Rep= ublic > > > > > Attachments: > > > > > * signature.asc > > > >=20 > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tls > >=20 > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > > Republic_______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3227776.MxLprl8Xxt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2XRlsACgkQkqjRuAHS 9fXl5A/9F1PKTR1LGcUKjUdBHXxLgirbRAYzoyuMIR+9u5mNXKXPP0ARZgLZWYKK UJZ7YgME1maqAMfupcq0W2TBylr+90Efr/61bt6vKJKO/0DEzZk5i0rMaP8VdTI0 VkDk/JyTwsopZ6+vFtROcrlH2bEkfD612apJ7dgfJaovHNINddmH5HwuBuWRfWsc MW4b3T3tBm3oew2d/fCWumLoIDOi3nq/wnyoyBqDfwa8kxgaA5V1s7pdFoKq7O9O +rakCnAkLDp5d3ir6oU352BNFXyltsLv9w5/1K0e9x32QtbuTMeZhQZ9P5Bfmjuy XDWU2OjjMCxTNRYwlns0ua4o6zb6Z6izP7GPbZVNMXQ/XQkUyHJwpag5xVRs98mI sGTIJg/lo8Itf4bJgWONXzy2jyDNpARpRQSx0vCNuXvjVxVq6zvMyMR4bjEWNPH/ EQqVxz6hGhFaMdhGB9CI2PvueAK+8bHyRA+H+8SjsvflHBzjQlgbzIZNzyppO3Z4 WuTepXv3HAYXu0aJTnS0borT3xCdq2l3/j84wm3K6kymRZ8s3dL/wD7haoS21C9/ SrnFc8OSYC0BJ4PHSgtk46eXd2qZXR/k5kkDvYjVHHMmJJxzaMRYv4XdX9LKeC7/ EU2EemgexluXWqS9XMDMXbr48hmXrahiGzgBZXg4wdsL52AUYWg= =NWea -----END PGP SIGNATURE----- --nextPart3227776.MxLprl8Xxt-- From nobody Fri Oct 4 06:55:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70229120046 for ; Fri, 4 Oct 2019 06:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.477 X-Spam-Level: X-Spam-Status: No, score=-1.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 YDAzAxOtPu1O for ; Fri, 4 Oct 2019 06:55:36 -0700 (PDT) Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) (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 E67DC120043 for ; Fri, 4 Oct 2019 06:55:35 -0700 (PDT) Received: by mail-vk1-f171.google.com with SMTP id u4so1476453vkl.6 for ; Fri, 04 Oct 2019 06:55:35 -0700 (PDT) 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=nuTpfAzbwWMac55/v2hkXF2nSui0nXOlao07DHKKPbw=; b=Jqh6TojYg4Lp4/NPL2LvnkuQvFUyPDaMYOg0jk2BfGv9BkKHtfGa8cPLo21LdcZM10 hwN9nc2aNPpPNArXRLp+q+BfA8M4oihQnHx8eH6aV3lSLK3jho8dg37gOeQbjPY0CfYd 7SKCMXZEkBeaCvK/01lUxhHrOEf/JzH66amgnnXK2smRWBqxNU+qA8JgYQLIaYAkE7qx xojKsu3QFHS/rbIHDgMevZT0exkELLbaUP8Qx04veg6XnuM1ljt3KxOZN3noHvNv6g9x RuIyCW/vkZNTNRgDKnXukNSxy7vWxXoGG8TFHOHbkWkt/tTpiei1AIG+Ebw0LRw+wyxW W6KA== X-Gm-Message-State: APjAAAWVFx5TnaOTNR0v+v9qM4POkmq581Rr5TWaXamsdBy4gReTETOo gM9guYkA2VkRb7P0NRUNpPtXaNFjyinuREd+opU= X-Google-Smtp-Source: APXvYqxHIXg3cve0Jb6NuKAlkAYNt1/OKAPP5Bg2ZRcZy4+eC60bIiyLsx9ocwQlh/59GIXidekDlteXotkfmSRuX1M= X-Received: by 2002:a1f:a181:: with SMTP id k123mr7942847vke.55.1570197334818; Fri, 04 Oct 2019 06:55:34 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <2328460.Fs94otCilB@pintsize.usersys.redhat.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> In-Reply-To: <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> From: Daniel Migault Date: Fri, 4 Oct 2019 09:55:23 -0400 Message-ID: To: Hubert Kario Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005e82310594160e53" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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, 04 Oct 2019 13:55:38 -0000 --0000000000005e82310594160e53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Hubert, I agree. Yours, Daniel On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario wrote: > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > I understand the meaning of count is the higher limit of ticket and > the > > > > server can provides any tickets between 0 and count. If that is > correct, > > > > this could be clearly stated and indication to chose an appropriate= d > > > > > > value > > > > > > > for each cases may be provided. > > > > > > > > I would rather see the count value as a hard line from the server > with a > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > > see my previous comments: this ignores existence of post handshake > > > authentication, ticket lifetimes and KeyUpdate > > > > I think we agree on the problem which is it is hard to have a specific > > count as tickets may be sent at multiple time during the key exchange o= r > > the later during the session. If the "SHOULD" is addressing this aspect= I > > believe that more text is needed.. From my perspective, what I proposed > I > > imagined that count was related to the maximum number of ticket provide= d > > **each time the server is sending tickets**. The reason for having the > same > > number is that the server does not know how the client will use these > > tickets and the client does not know precisely when the server sends th= e > > tickets. So at the end the number of tickets sent is likely to be n*cou= nt > > when n represents the number of times during the session tickets are > > provided. > > > > My understanding of the SHOULD is that it makes legitimate for a server > to > > ignore the count value provided by the client. > > yes, it looks like we are in agreement > > Sounds like something that should be spelled out explicitly in the draft. > I.e. > it should talk about groups of tickets, not tickets in connection, and it > should definitely not specify the maximum number of tickets a server can > send > in a connection. > > > > > The ability to request 255 tickets with one byte can be seen as an > > > > amplification vector, especially when a server sends directly the > > > > tickets > > > > after its Finished message. I believe that additional text in the > > > > > > security > > > > > > > consideration could be added. > > > > > > true > > > > > > > Yours, > > > > Daniel > > > > > > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood > > > > > > > wrote: > > > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > > > > > On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote= : > > > > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote: > > > > > > > > > > ``` > > > > > > > > > > Servers MUST NOT send more than 255 tickets to clients. > > > > > > > > > > ``` > > > > > > > > > > > > > > > > > > > > per what? session? at a time? connection? > > > > > > > > > > > > > > > > > > This is all per session. We can state it explicitly in th= e > > > > > > > > > next > > > > > > > > > > version. > > > > > > > > > > > > > so this count needs to be kept as part of session and impac= ts > > > > > > > > > > connections > > > > > > > > > > > > > that perform resumption? > > > > > > > > > > > > > > Sorry, I meant connection: > > > > > > > "Clients may indicate to servers their desired number of > > > > > > > tickets > > > > > > > > > > for *a > > > > > > > > > > > > single connection* via the following "ticket_request" > extension" > > > > > > > > > > > > > > This is a simple hint for servers. Nothing more. No state > needs to > > > > > > be > > > > > > > > stored > > > > > > > > > > > > past connection establishment. > > > > > > > > > > > > sounds good > > > > > > > > > > > > > > > > what's the expected behaviour with tickets and > > > > > > > > > > post-handshake > > > > > > > > > > authentication? Are tickets sent after PHA also bound b= y > > > > > > > > > > this > > > > > > > > > > limit? > > > > > > > > > > > > > > As mentioned earlier, there is no effect, so we left it > out. > > > > > > We're > > > > > > > > happy > > > > > > > > > > > > > > to > > > > > > > > > accept text should you think it's needed. > > > > > > > > > > > > > > > > If the I-D states that servers should not send more tickets > than > > > > > > the > > > > > > > > > > > client > > > > > > > > asked for, and then send exactly that amount, then they > won't be > > > > > > > > > > able to > > > > > > > > > > > > > send new tickets after PHA and remain compliant. > > > > > > > > > > > > > > > > Yes, it's completely up to the server to decide if to send > > > > > > tickets > > > > > > > > after > > > > > > > > > > > > > PHA or not, and I'm not suggesting that the client should > > > > > > > > request > > > > > > > > for > > > > > > > > tickets in one of its PHA messages, much less expect or > require > > > > > > > > > > them, but > > > > > > > > > > > > > sending tickets after PHA is reasonable and explicitly stat= ed > > > > > > > > > > behaviour: > > > > > > > > RFC 8446 Section 4.6.1: > > > > > > > > For instance, the server might send a new > > > > > > > > ticket after post-handshake authentication in order to > > > > > > > > encapsulate > > > > > > > > the additional client authentication state. > > > > > > > > > > > > > > > > so the I-D should explicitly state what's the expected > behaviour > > > > > > in > > > > > > > > that > > > > > > > > > > > > > case. > > > > > > > > > > > > > > > > IMHO, the extension should be used for the tickets sent rig= ht > > > > > > after > > > > > > > > the > > > > > > > > > > > > > handshake, it should not put an upper bound for the tickets > that > > > > > > a > > > > > > > > server > > > > > > > > > > > > > can send in a single connection. For a very long lived > > > > > > > > connection > > > > > > > > (especially if the connection uses KeyUpdate messages > > > > > > > > regularly), > > > > > > > > the > > > > > > > > initial tickets may expire. Server may notice that and send= a > > > > > > > > new > > > > > > > > > > group > > > > > > > > > > > > > of tickets then. > > > > > > > > > > > > > > Since these hints are not mandatory to honor I don't think we > need > > > > > > to > > > > > > > > > > describe this case. In particular, this is a valid case where > > > > > > ignoring > > > > > > > > the > > > > > > > > > > > > SHOULD is fine, in my opinion. > > > > > > > > > > > > > > If the draft required that servers MUST NOT send more tickets > than > > > > > > > > > > what's > > > > > > > > > > > > requested, then yes, I think these details would be important= . > > > > > > > > > > > > huh? I see the following in the draft-02: > > > > > > Servers MUST NOT > > > > > > send more than 255 tickets to clients. > > > > > > > > > > I was referring to the "SHOULD NOT send more than > > > > > TicketRequestContents.count NewSessionTicket messages" blurb. > Indeed, > > > > > > the > > > > > > > > MUST NOT above should also be a SHOULD NOT. Thanks for your > patience > > > > > in > > > > > working through the kinks! > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Hubert Kario > > > > > > Senior Quality Engineer, QE BaseOS Security team > > > > > > Web: www.cz.redhat.com > > > > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech R= epublic > > > > > > Attachments: > > > > > > * signature.asc > > > > > > > > > > _______________________________________________ > > > > > TLS mailing list > > > > > TLS@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > > > Regards, > > > Hubert Kario > > > Senior Quality Engineer, QE BaseOS Security team > > > Web: www.cz.redhat.com > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > > > Republic_______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005e82310594160e53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Hubert,=C2=A0

I agree.=C2= =A0
Yours,=C2=A0
Daniel

On Fri, Oct 4, 2019 at 9:17 AM H= ubert Kario <hkario@redhat.com&= gt; wrote:
On Th= ursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <hkario@redhat.com> wrote:
> > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:<= br> > > > I understand the meaning of count is the higher limit of tic= ket and the
> > > server can provides any tickets between 0 and count. If that= is correct,
> > > this could be clearly stated and indication to chose an appr= opriated
> >
> > value
> >
> > > for each cases may be provided.
> > >
> > > I would rather see the count value as a hard line from the s= erver with a
> > > MUST NOT instead of a SHOULD NOT statement.
> >
> > see my previous comments: this ignores existence of post handshak= e
> > authentication, ticket lifetimes and KeyUpdate
>
> I think we agree on the problem which is it is hard to have a specific=
> count as tickets may be sent at multiple time during the key exchange = or
> the later during the session. If the "SHOULD" is addressing = this aspect I
> believe that more text is needed.. From my perspective, what I propose= d=C2=A0 I
> imagined that count was related to the maximum number of ticket provid= ed
> **each time the server is sending tickets**. The reason for having the= same
> number is that the server does not know how the client will use these<= br> > tickets and the client does not know precisely when the server sends t= he
> tickets. So at the end the number of tickets sent is likely to be n*co= unt
> when n represents the number of times during the session tickets are > provided.
>
> My understanding of the SHOULD is that it makes legitimate for a serve= r to
> ignore the count value provided by the client.

yes, it looks like we are in agreement

Sounds like something that should be spelled out explicitly in the draft. I= .e.
it should talk about groups of tickets, not tickets in connection, and it <= br> should definitely not specify the maximum number of tickets a server can se= nd
in a connection.

> > > The ability to request 255 tickets with one byte can be seen= as an
> > > amplification vector, especially when a server sends directl= y the
> > > tickets
> > > after its Finished message. I believe that additional text i= n the
> >
> > security
> >
> > > consideration could be added.
> >
> > true
> >
> > > Yours,
> > > Daniel
> > >
> > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <caw@heapingbits.net&g= t;
> >
> > wrote:
> > > > On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote: > > > > > On Tuesday, 1 October 2019 16:01:32 CEST Christoph= er Wood wrote:
> > > > > > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario= wrote:
> > > > > > > > > ```
> > > > > > > > > Servers MUST NOT send more tha= n 255 tickets to clients.
> > > > > > > > > ```
> > > > > > > > >
> > > > > > > > > per what? session? at a time? = connection?
> > > > > > > >
> > > > > > > > This is all per session. We can sta= te it explicitly in the
> > > > > > > > next
> > > >
> > > > version.
> > > >
> > > > > > > so this count needs to be kept as part o= f session and impacts
> > > >
> > > > connections
> > > >
> > > > > > > that perform resumption?
> > > > > >
> > > > > > Sorry, I meant connection:
> > > > > >=C2=A0 =C2=A0 "Clients may indicate to se= rvers their desired number of
> > > > > >=C2=A0 =C2=A0 tickets
> > > >
> > > > for *a
> > > >
> > > > > > single connection* via the following "ti= cket_request" extension"
> > > > > >
> > > > > > This is a simple hint for servers. Nothing mo= re. No state needs to
> >
> > be
> >
> > > > stored
> > > >
> > > > > > past connection establishment.
> > > > >
> > > > > sounds good
> > > > >
> > > > > > > > > what's the expected behavi= our with tickets and
> > > > > > > > > post-handshake
> > > > > > > > > authentication? Are tickets se= nt after PHA also bound by
> > > > > > > > > this
> > > >
> > > > limit?
> > > >
> > > > > > > > As mentioned earlier, there is no e= ffect, so we left it out.
> >
> > We're
> >
> > > > happy
> > > >
> > > > > > > > to
> > > > > > > > accept text should you think it'= ;s needed.
> > > > > > >
> > > > > > > If the I-D states that servers should no= t send more tickets than
> >
> > the
> >
> > > > > > > client
> > > > > > > asked for, and then send exactly that am= ount, then they won't be
> > > >
> > > > able to
> > > >
> > > > > > > send new tickets after PHA and remain co= mpliant.
> > > > > > >
> > > > > > > Yes, it's completely up to the serve= r to decide if to send
> >
> > tickets
> >
> > > > after
> > > >
> > > > > > > PHA or not, and I'm not suggesting t= hat the client should
> > > > > > > request
> > > > > > > for
> > > > > > > tickets in one of its PHA messages, much= less expect or require
> > > >
> > > > them, but
> > > >
> > > > > > > sending tickets after PHA is reasonable = and explicitly stated
> > > >
> > > > behaviour:
> > > > > > > RFC 8446 Section 4.6.1:
> > > > > > >=C2=A0 =C2=A0 For instance, the server mi= ght send a new
> > > > > > >=C2=A0 =C2=A0 ticket after post-handshake= authentication in order to
> > > > > > >=C2=A0 =C2=A0 encapsulate
> > > > > > >=C2=A0 =C2=A0 the additional client authe= ntication state.
> > > > > > >
> > > > > > > so the I-D should explicitly state what&= #39;s the expected behaviour
> >
> > in
> >
> > > > that
> > > >
> > > > > > > case.
> > > > > > >
> > > > > > > IMHO, the extension should be used for t= he tickets sent right
> >
> > after
> >
> > > > the
> > > >
> > > > > > > handshake, it should not put an upper bo= und for the tickets that
> >
> > a
> >
> > > > server
> > > >
> > > > > > > can send in a single connection. For a v= ery long lived
> > > > > > > connection
> > > > > > > (especially if the connection uses KeyUp= date messages
> > > > > > > regularly),
> > > > > > > the
> > > > > > > initial tickets may expire. Server may n= otice that and send a
> > > > > > > new
> > > >
> > > > group
> > > >
> > > > > > > of tickets then.
> > > > > >
> > > > > > Since these hints are not mandatory to honor = I don't think we need
> >
> > to
> >
> > > > > > describe this case. In particular, this is a = valid case where
> >
> > ignoring
> >
> > > > the
> > > >
> > > > > > SHOULD is fine, in my opinion.
> > > > > >
> > > > > > If the draft required that servers MUST NOT s= end more tickets than
> > > >
> > > > what's
> > > >
> > > > > > requested, then yes, I think these details wo= uld be important.
> > > > >
> > > > > huh? I see the following in the draft-02:
> > > > >=C2=A0 =C2=A0 Servers MUST NOT
> > > > >=C2=A0 =C2=A0 send more than 255 tickets to clients= .
> > > >
> > > > I was referring to the "SHOULD NOT send more than<= br> > > > > TicketRequestContents.count NewSessionTicket messages&q= uot; blurb. Indeed,
> >
> > the
> >
> > > > MUST NOT above should also be a SHOULD NOT. Thanks for = your patience
> > > > in
> > > > working through the kinks!
> > > >
> > > > > --
> > > > > Regards,
> > > > > Hubert Kario
> > > > > Senior Quality Engineer, QE BaseOS Security team > > > > > Web: www.cz.redhat.com
> > > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00= =C2=A0 Brno, Czech Republic
> > > > > Attachments:
> > > > > * signature.asc
> > > >
> > > > _______________________________________________
> > > > TLS mailing list
> > > > TLS@i= etf.org
> > > > https://www.ietf.org/mailman/listinfo/t= ls
> >
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czec= h
> > Republic_______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005e82310594160e53-- From nobody Fri Oct 4 07:08:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED8F120071; Fri, 4 Oct 2019 07:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 es-yW6GlXt4M; Fri, 4 Oct 2019 07:08:07 -0700 (PDT) Received: from smtp69.iad3a.emailsrvr.com (smtp69.iad3a.emailsrvr.com [173.203.187.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1518012004C; Fri, 4 Oct 2019 07:08:06 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp33.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 4196B54AC; Fri, 4 Oct 2019 10:08:05 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.91] (d75-155-57-73.abhsia.telus.net [75.155.57.73]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 04 Oct 2019 10:08:06 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Cullen Jennings In-Reply-To: <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> Date: Fri, 4 Oct 2019 08:08:04 -0600 Cc: Stephen Farrell , Sean Turner , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , "tls@ietf.org" , Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> To: John Mattsson X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Fri, 04 Oct 2019 14:08:09 -0000 I do not think you have consensus for that change to WebRTC - it was = discussed extensively. I would just leave things as they are.=20 > On Oct 2, 2019, at 8:45 AM, John Mattsson = wrote: >=20 > Hi, >=20 > Sean Turner wrote: >> "You can change the text, but I do not believe it will change the = implementations." >=20 > I would much rather have a future proof RFC that forbids negotiation = of DTLS 1.0 with the knowledge that some implementations will temporary = violate that, than having an RFC that long time in the future allows = negotiation and use of DTLS 1.0. >=20 >=20 > Eric Rescorla wrote: >> "result of some pretty extensive discussion and compromising in = rtcweb" >=20 > That does not surprise me, but I think that is part of the problem. = These things should mainly be decided by the TLS working group. = Draft-ietf-rtcweb-security-arch mandated DTLS 1.0 until Nov 2018. That = is half a year after the "Deprecating TLSv1.0 and TLSv1.1" draft was = submitted and almost 7 years after DTLS 1.0 was made obsolete. >=20 >=20 > No matter what is done in this particular case, I think the important = thing to discuss is how we avoid drafts that only support obsolete = versions of TLS/DTLS in the future. According to my understanding of the = comments in the thread "Lessons learned from TLS 1.0 and TLS 1.1 = deprecation", both me, Kathleen Moriarty, and Martin Thomson understands = obsoleted as: >=20 > "New implementations and deployments MUST include support of the new = version". >=20 > If this is not clearly defined somewhere, I think it needs to be = specified. If it is specified somewhere, IETF needs to make sure to = follow apply it. >=20 > Cheers, > John=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Oct 4 07:43:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45A0120949; Fri, 4 Oct 2019 07:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QWiUdUaN4SkG; Fri, 4 Oct 2019 07:43:26 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 6264A120918; Fri, 4 Oct 2019 07:43:26 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id b19so14103605iob.4; Fri, 04 Oct 2019 07:43:26 -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=2qDyVa1oSfZaPXYkRwJrVvl1xQYVEXzg2qcPo2X0gHM=; b=D69jfFOhQvsSRUhcj95AQruTcF7AHO8xNrp0XrWNup7uOuQMZJzT6lDzk+bpR0QyFD N7g3+zbDwRYa8pwqaW6fOCA27+0Hmby82QpZJmNdx0tVxB58TqTHQqxYmIEMBD3Lxlw6 Uq5H6fEfm8mNh2g5y3kfiLD87yPmqosDJJStuTNG9+pX+pS7DtOg9x7/V6bqDstl9Aml f6S43F+SMEgaNcSq26RiWFF4dRz3Jh59kO8/IUM0D5xyVCw+rPebRBHuzQ5MJ5quQ9xs nvTbx+mvVu7DKOq539aHU2Mq7snlNWNsMXwUZiuu3d+xGYr3j/HQmjU1t0fvRg6OhheG HAlQ== 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=2qDyVa1oSfZaPXYkRwJrVvl1xQYVEXzg2qcPo2X0gHM=; b=X97lhLK6h8IIpugMhxWmNKXg5F8KVPFMJ8QkCXaNvj8qf4hVP1sjrRlT1o/2JLbx7Q y79uDqrqNv+O0C/u63k9iUMl4TNnO8GlzCGd6Rb51cWMD0pHQjR/XgAsLqq5Ao9cUdwE 82Jo1ptbC2L9YaLzmkhJav2pLbMgsBts4Smpm//L0thvon+vw2zdeaBS/o/7YUIsbKqx ARyrRumy/+wHzPiiCerSiGYx9WuvQdvAb35iTHt5ZB69PGmC6zbGX+g79tHJ7+vfi+V4 Ufh5MtdM3qJgeEFNycAxkZ0eUnQ+IDi5a82ciBqihhIhZ8fIiWAqvyrY2en1dFxfMHWA jGLw== X-Gm-Message-State: APjAAAUkTafq4XqJJaMkbUC4gYhnaKyvtzacvJRXxdkOBXpklDTxOXtY CZJcls36OmWC6bY0mJg1ziyJ3uMNGOV46/zrVbc= X-Google-Smtp-Source: APXvYqxcO+nUbujOsXETfMhgjKtIWbkR+bgSrz/ak/VzwA72WUe37Za6W6p52TjlqsCG/r5uoE6g1hVTv3W1YlZ4Ei8= X-Received: by 2002:a5e:8902:: with SMTP id k2mr13540510ioj.49.1570200205547; Fri, 04 Oct 2019 07:43:25 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> From: Rob Sayre Date: Fri, 4 Oct 2019 21:43:13 +0700 Message-ID: To: Cullen Jennings Cc: John Mattsson , Benjamin Kaduk , Sean Turner via Datatracker , IESG Secretary , "tls@ietf.org" , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007a5f03059416b964" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Fri, 04 Oct 2019 14:43:28 -0000 --0000000000007a5f03059416b964 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote: > > I do not think you have consensus for that change to WebRTC - it was > discussed extensively. ... > While that may be true, readers of this list might want to read a rationale, rather than just the results of a negotiation. Is there a rationale somewhere? It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. thanks, Rob --0000000000007a5f03059416b964 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 4, 2019 at 9:08 PM Cullen Jen= nings <fluffy@iii.ca> wrote:
=

I do not think you have consensus for that change to WebRTC - it was discus= sed extensively. ...

=C2=A0While that m= ay be true, readers of this list might want to read a rationale, rather tha= n just the results of a negotiation. Is there a rationale somewhere?
<= div>
It seems strange to put DTLS 1.0 (based on TLS 1.1) into= new documents.

thanks,
Rob
<= /div> --0000000000007a5f03059416b964-- From nobody Fri Oct 4 07:48:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD160120861 for ; Fri, 4 Oct 2019 07:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 NjK_9rJ2okDv for ; Fri, 4 Oct 2019 07:48:29 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC1D120835 for ; Fri, 4 Oct 2019 07:48:28 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v24so6812647ljj.3 for ; Fri, 04 Oct 2019 07:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MmIY0n9FuaDSVSR5gyPsbkaBC1Rpt7/6IhsE/RnSzOE=; b=OpuQ/kh261iMwfZRCB1eDLWmHAhB5ME8nlddS4gFty9oGOruyZGbIfTNa35Ek/9KOz WQW2ovynYEAtmQ7Nl8zUGpKi6Il6JRqKBEl93mUzNwZPCd8eDWvefwWcAKB+H+yOgmHo 8xaFSPzH2BE/6mfJO3VY2m5wS0CE1xzaNyu8OHf86LP7HmMCfuSAhRhbROIsLxDgCXIu zn2Bi9LL0Ffx1bYwj9czw3fXfGVpB3p17ow8l2+f0oSXNgfewsXQ8ZCur1/LrHEj8vxQ pLzrlt7fCvI++7x/2aUKa5qRbh6kksb7xQMExBYo/ZSw94xgOm0LDG55NrzsOmIPrkhL 4wOQ== 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=MmIY0n9FuaDSVSR5gyPsbkaBC1Rpt7/6IhsE/RnSzOE=; b=EI8EytXnKyr2xBCCG3PD6bD3HX37H02Lpj3zm/tWjNd7x1OklPdsOObj9Ronn6tCxT Px6Z/+JRLxJLJXGZ2J33nO4KNosXvggqLcJoYlC7cSZQiVr3PXNit3xeu1Vsrq4qF8ox yrmSiIPg+DXevo23iRXvbRtqXEbN5oj0Go1THQKcQIsQgP9vryjOb65nNdx1YcnTUU4B dFQwcKjCZBd+j94utuFzpbkprBFYm7t3cWOkYBx+1hsUCLRX8yFu6PCt62GnexRRkl94 om8YYJ5B7niZjkZ3rw9C/HKsc0petHju5X/DAtY1aujrd3qyfeEKUmHz4CloPHq6eejP 3O8w== X-Gm-Message-State: APjAAAV1u1cIVWsz4QRZ52RZrDoP307Q0A9gQvipDpnH6E4FaPPAT+j/ 6PNmsJXOSzFudEY0eZ3126p70lgFBE9agkarNooF/w== X-Google-Smtp-Source: APXvYqxzyLfVtFTJqYFGsBAHB1cIMcoJk1IPe2BHVXYeYDXONPB4UlvWCvlzpCFVTnnx+MFuGth13+cuLHAIdllnsmg= X-Received: by 2002:a05:651c:1031:: with SMTP id w17mr10025672ljm.16.1570200507039; Fri, 04 Oct 2019 07:48:27 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Eric Rescorla Date: Fri, 4 Oct 2019 07:47:50 -0700 Message-ID: To: Rob Sayre Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="00000000000072d8c4059416cbbd" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Fri, 04 Oct 2019 14:48:32 -0000 --00000000000072d8c4059416cbbd Content-Type: text/plain; charset="UTF-8" On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote: > On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote: > >> >> I do not think you have consensus for that change to WebRTC - it was >> discussed extensively. ... >> > > While that may be true, readers of this list might want to read a > rationale, rather than just the results of a negotiation. Is there a > rationale somewhere? > > It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. > A few points. 1. It doesn't pull it in. There's no reference and there's just an informative statement. 2. There is a rationale. In fact, the relevant text pretty much is all rationale. All Implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186 ]. Earlier drafts of this specification required DTLS 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this writing some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues. -Ekr Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000072d8c4059416cbbd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 4, 2019 at 7:43 AM Rob Sa= yre <sayrer@gmail.com> wrote:=
On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <fluffy@iii.ca> wrote:<= br>

I do not think you have consensus for that change to WebRTC - it was discus= sed extensively. ...

=C2=A0While that m= ay be true, readers of this list might want to read a rationale, rather tha= n just the results of a negotiation. Is there a rationale somewhere?
<= div>
It seems strange to put DTLS 1.0 (based on TLS 1.1) into= new documents.

A few poi= nts.

1. It doesn't pull = it in. There's no reference and there's just an informative stateme= nt.
2. There is a rationale. In fact, the r= elevant text pretty much is all rationale.
   All Implementations MUST support DTLS 1.2 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
   curve [-Ekr

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000072d8c4059416cbbd-- From nobody Fri Oct 4 07:58:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74101120883; Fri, 4 Oct 2019 07:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Qos4x8IIwqqT; Fri, 4 Oct 2019 07:58:06 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 73D71120897; Fri, 4 Oct 2019 07:58:06 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id n197so14118360iod.9; Fri, 04 Oct 2019 07:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jo//O/KqimRqrLCEcqYQgVeJnteLoukj5ip+PhwTU5g=; b=pBC0GKxxLicPqTjK3fCcmXnuJK2JJ3QN66JnolSNXfJyTvj+uNsy5lUr4fWy4kBQUL kemb5Uj0GTQTxmS+fAH30jP5s7DS6K+NYdR6lGuMu8XaQelxM/y5dGShzm0ESGIerw0N ATHxMa7EaU2Kd090yGUKxF8jCYOrOIiEksdS3mLOhbjHuDhNl3ZPxDT8pr9sOkXHjnci yKvN0V4V7bYlJ+id55Tc+h/OlbkKW0Ype5QJJuOWAoKVzXoRPzCMiFbTihzwPdZNpuCS GN5k6cFbAD+m2xusLrB4neDc21oS492hW/RxkIvdNnLG0KLcK/+C9Vt94GvObkBlglRv fGZQ== 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=jo//O/KqimRqrLCEcqYQgVeJnteLoukj5ip+PhwTU5g=; b=pF83x41ekYlZvmQmbLzzV509wi32x5tJClWsCVdgCke8Ayg+pPttOkwu/gNIZhhGWI gHDj6n8TrBMDH+AYAGxzVnYR1fG32r082PAnvkvDpU11MHgO6bp1FVYuXqCzJG4T8m/2 ihdv+MJDmogHZ9eR3VSuBp6l5juxrbd1AOITB554hA6bkE5nhbZBSPeldlUW/lqjvGvy GoqFfWAUUodC1Qqpd6IEAkPk2h0Xntc3GkUi75XI43BxEvby2uk0KYR73rD7WAcClQxS Pe5c92cbwxSwxPiDKdvpClLI1jkLbpluDRKYQ0HK/RtdQM+HY+ixW9HxTGU73F5Y8OZv 8uVg== X-Gm-Message-State: APjAAAVZHE/UBY8dVcyKaN8ZbGwN9B71MZuYEU4+dZb9oCeMU+WecoJr PGFL9dM+vcmRaQTXEZEV2Nt4vF2zYxEcilC4vmU= X-Google-Smtp-Source: APXvYqwQhIsZ5wGKfqRBEO+iMF72KpGbdn8BL5/gUF9HmYy4D/xJuRcZ4cpE3a72A8U9dCo5Hs0DmSfLoP5jtsX9bLI= X-Received: by 2002:a92:ca8e:: with SMTP id t14mr16180341ilo.73.1570201085575; Fri, 04 Oct 2019 07:58:05 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Rob Sayre Date: Fri, 4 Oct 2019 21:57:53 +0700 Message-ID: To: Eric Rescorla Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000ee8ad0059416ed1f" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Fri, 04 Oct 2019 14:58:10 -0000 --000000000000ee8ad0059416ed1f Content-Type: text/plain; charset="UTF-8" On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla wrote: > > > On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote: > >> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote: >> >>> >>> I do not think you have consensus for that change to WebRTC - it was >>> discussed extensively. ... >>> >> >> While that may be true, readers of this list might want to read a >> rationale, rather than just the results of a negotiation. Is there a >> rationale somewhere? >> >> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. >> > > A few points. > > 1. It doesn't pull it in. There's no reference and there's just an > informative statement. > Shouldn't there be an informative reference? > 2. There is a rationale. In fact, the relevant text pretty much is all > rationale. > > All Implementations MUST support DTLS 1.2 with the > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 > curve [FIPS186 ]. Earlier drafts of this specification required DTLS > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > at the time of this writing some implementations do not support DTLS > 1.2; endpoints which support only DTLS 1.2 might encounter > interoperability issues. > > Yes, I read this section and I was wondering what the rationale was for the text: "endpoints which support only DTLS 1.2 might encounter interoperability issues." Is there some data behind this? I'm not suggesting a change in the draft without more information, but I do wonder how the WG came to agree on this text. thanks, Rob --000000000000ee8ad0059416ed1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 4, 2019 at 9:48 PM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre <sayrer@gmail.com> wrote:<= br>
On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <fluffy@iii.ca> wrote:

I do not think you have consensus for that change to WebRTC - it was discus= sed extensively. ...

=C2=A0While that m= ay be true, readers of this list might want to read a rationale, rather tha= n just the results of a negotiation. Is there a rationale somewhere?
<= div>
It seems strange to put DTLS 1.0 (based on TLS 1.1) into= new documents.

A few poi= nts.

1. It doesn't pull = it in. There's no reference and there's just an informative stateme= nt.

Shouldn't there b= e an informative reference?
=C2=A0
2. There is a rationale. In fact, the relevant text pr= etty much is all rationale.
   All Implementations MUST support =
DTLS 1.2 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
   curve [FIPS186].  Earlier drafts of this specification req=
uired DTLS
   1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
   at the time of this writing some implementations do not support DTLS
   1.2; endpoints which support only DTLS 1.2 might encounter
   interoperability issues.

Yes, I read this section and I was wondering what the = rationale was for the text: "endpoints which support only DTLS 1.2 mig= ht encounter interoperability issues." Is there some data behind this?= I'm not suggesting a change in the draft without more information, but= I do wonder how the WG came to agree on this text.

thanks,
Rob

--000000000000ee8ad0059416ed1f-- From nobody Fri Oct 4 09:44:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62841200A1 for ; Fri, 4 Oct 2019 09:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 AkziFqWVcVlr for ; Fri, 4 Oct 2019 09:44:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE464120048 for ; Fri, 4 Oct 2019 09:44:13 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7B76B309BF23; Fri, 4 Oct 2019 16:44:13 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id CF3E110018F8; Fri, 4 Oct 2019 16:44:12 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 04 Oct 2019 18:44:06 +0200 Message-ID: <5308311.VbF7qBjPJL@pintsize.usersys.redhat.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2678527.Yuvi7abKi2"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Fri, 04 Oct 2019 16:44:13 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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, 04 Oct 2019 16:44:17 -0000 --nextPart2678527.Yuvi7abKi2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 3 October 2019 05:44:27 CEST Viktor Dukhovni wrote: > > On Oct 2, 2019, at 11:20 PM, Christopher Wood wro= te: > >=20 > > Asking for one upon resumption seems reasonable to me. Thanks to you and > > Viktor for bringing up this case! > Thanks! Much appreciated. >=20 > My other point, which I probably obscured in too many words, is > that a client that prefers to re-use existing tickets, would > normally want to ask for 0 new tickets, but this should not > necessarily preclude the server from issuing one *as needed* > (STEK rollover, ...). >=20 > So there is a difference between a signal that tickets > are simply not wanted, vs. wanted only *as needed*. >=20 > Do you have any thoughts on how a client might signal this? >=20 > The use-case is clients and servers that don't make use of > early-data, and don't need to avoid traffic analysis. For > example, MTA-to-MTA traffic, where the client even identifies > in clear text with "EHLO". Here ticket reuse is the norm, > and renewal is only needed as tickets age. >=20 > [ I hope I managed an suitably concise description this time... ] Well, the client doesn't have any feedback from server that the server=20 supports this extension so it will need to be able to handle tickets anyway= =2E=20 It can't use this extension to disable sending of tickets. now, we may say in the text, that's it's recommended for the server to stil= l=20 send them in case of resumption and STEK rollover of PHA, but I'm not sure = if=20 we're not too far into the weeds... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2678527.Yuvi7abKi2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2XdtYACgkQkqjRuAHS 9fXx/A/+NGF06BFacSHg/HYDCcTlMzqGxniL+mQnu2pBCysSqKiOs/mixThSJ8br EmrIzStdE4CrXhCu5u5nTCIIzDWwWoJn+e36J7QCl2T8ew9J2rQjLAyx2zF/4URc lZnH0m1jmT1IlojkP0mKzNrtTRgq4OlKoXPr/laP0e3N31wS+u0Opm6MQ0pebDvU /CGdHrQmLGKLvtPEMj3qUm0guPy1EwHA1h4n4pEFewRX8Voz8niMHdSHM6vqZ/RD EPk/Vm13h0NpQPX/X1G5zc45BYbzTcig//amo5qWNtFctvPO0jsmQ3v25Vlm4dAe kQihRNyxQ8bo1AE4yp9ILpR2cvoUAIFHka4qespEoZnaeR506TBMsso7j14z5Uh9 ZtLv6ugj3zsSwPY13WoLcisbqgJyx1V4rQqqLkPkO/N2vDeDtl0LzgqKCcxQKWcB 8vGf5mYMzhH4elFZBukTYWTUQmyYut/6iIQ67vtY4hvwZ+RCR4KPmCfLSSyslSB/ px9upaiHwEFbqA+9aq3PGeINraSUGoZX+eu1PQu02sB6/vJohtsTLfR83PJwm3OC DdhgRR0o4Ab6mOSr4LuHRL6dVkvU4SnyEPCMnJ3ITP9iu6QbiX0GMrx7b0rqL6Dc m/c/+MiOP5v3mzmU2f3iQ9KC33O1nolXJGtW5E5093Y7V+JC7QU= =C7Ns -----END PGP SIGNATURE----- --nextPart2678527.Yuvi7abKi2-- From nobody Sat Oct 5 03:36:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E841200C5; Sat, 5 Oct 2019 03:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mN22EvTRpOYi; Sat, 5 Oct 2019 03:36:30 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40047.outbound.protection.outlook.com [40.107.4.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329D0120033; Sat, 5 Oct 2019 03:36:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EeUIUBlAYd/lzKm1bUOCcDgqMB6W/CjDLE0CZPdes43tTm70e2MnRgllXVGR8aAwNpzplS3qOecQkrTTfRMJBFtcXzNVY+KU4DZC+zz+rWxpJIojrmAkj1DE6fCvPRIAUq2DGNF/0qBwel2+E/BcGkH0quh4PFMEr46St+dLpOOLzDbHGZN/1+3iqLCM7igII4HLEE+ysTv5GWPMmvqKpODKQ7UyZ8yOv0JYkdrX5MoDbXMkM7TDNGfE/nPfY3V32YqH2ji0yKZugnQvio/9HO0aopwB/jbnsMBFh4Ol3CDpDdjru0AbkXrJEPerhhYVBrlVCERAcXTOIdrAyAVX1w== 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=VlltzUx0nXak1Cp2vbDBmsRikov4e1Mzj8sjHpI+UEo=; b=gEiiB/QgLhBhEKNLfvZ8empX3sp7QUvK/+hiKGv7Kp0vxFetGnpEUz1g72SsPxYYj83AZ1q9Gmxq0nK7rVivcT4eXhmSLRxlsXiv65VvJdImDQ3WJUe2JEwbjXkFmOJQqkbfXJVYUFRWk5fbkL/oSmnFDZM/lN8q7mF58dD4U1ICeAIB859IKgtRIW+YkJUIn7K3qJdWfZP2jVgQN3zsfn2bxBE701osawIz6hv4Y6tdP4+zZ+6tTV5/4cynQ5kM6DYKXwnrXbLIakHLD9DInY9Sldo1FKJNONRGMgqJQpVCVXjFEVzbxjPzXK7xenzFY4l2xSEanl1FRUd4RJACNA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VlltzUx0nXak1Cp2vbDBmsRikov4e1Mzj8sjHpI+UEo=; b=AfsdKnXfeLwvU0Vk8YRjrOTgUOqlkevHVxw998ibqmCA1cgEsVtcJQQJkrjznW1amfxJ1a+gfOx8JwW2FLhmhEQhua6Cv5QN74X17RGb7RBnmzaxWgrrvqpeh0O5afmJ9dLJ5JZbcynThUNz54AyNb2Bu8KeaSxZsy5GNjOlNWw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3084.eurprd07.prod.outlook.com (10.170.247.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Sat, 5 Oct 2019 10:36:27 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2327.021; Sat, 5 Oct 2019 10:36:27 +0000 From: John Mattsson To: "hannes.tschofenig@gmx.net" , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGRuT2dEqLFcbEmEm2g+1AcjWadF0deAgAY4YQA= Date: Sat, 5 Oct 2019 10:36:27 +0000 Message-ID: <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> In-Reply-To: <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c63e079f-2a73-4455-006e-08d7497fe0d2 x-ms-traffictypediagnostic: HE1PR07MB3084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(136003)(39860400002)(366004)(346002)(199004)(189003)(8936002)(478600001)(86362001)(186003)(110136005)(36756003)(486006)(2501003)(6246003)(99286004)(14444005)(2906002)(26005)(14454004)(446003)(3846002)(256004)(2616005)(6116002)(71190400001)(71200400001)(2201001)(476003)(25786009)(66066001)(44832011)(6512007)(66946007)(7736002)(76116006)(11346002)(6506007)(66446008)(64756008)(5660300002)(66476007)(66556008)(58126008)(229853002)(91956017)(6436002)(305945005)(4744005)(316002)(8676002)(33656002)(81156014)(81166006)(102836004)(76176011)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3084; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SETWXdXmUtYZEk5Qw7a+t89UQvnAvCSJifbvkiqzws/tAC3iJXbLGeIMF1OpF7mQRYjbohVUXzHasXaZ9W6agDnMIYuOTOTAWS/QRa5Fhc/Wk4EddxlzTIpgNRisce6OblS+PfBy85cS08MvmMfFWTasVqH1cjFRKWpKqRO/3r0++yZiZ49Xv5R90mrmMJ3g95sqkrW/cbDnvMYKnczWdfVyLJNJKAzhlkgo6bfOKT3OfEHNGIc50R9IRs3OEPmsmT17POK7/R7PpzvO7YjFwZ14AkJ0migS71W+5URnculbiR1k9JrhBGvEiEs/55Lmu+AQOeGqtHJti2dTfsX/JgvqrM7rmc5hoGwznxvG1qMa1TVIcc9YpQa7jvwvsCS+jaYYc2adV77BS+nX32uz92Vv76scuh4O/xcO2f97hEY= 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-Network-Message-Id: c63e079f-2a73-4455-006e-08d7497fe0d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2019 10:36:27.6108 (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: On2msrtgHpBiLuOzBKGC/8yLknE1Mn4MPPsv2wt38LViu6ovxpyLQgjrnivRTyPIOxbUSTKP5M+SeZfTktqkB+uv25qS+tpWgxJcBqHN2No= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3084 Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2019 10:36:32 -0000 Imhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQiIDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PiB3 cm90ZToNCg0KPiBQUzogQXMgS2F0aGxlZW4gbm90ZWQgVExTIDEuMiBhbmQgRFRMUyAxLjIgYXJl IHBlcmZlY3RseSBmaW5lIGlmIHlvdSBmb2xsb3cgUkZDIDc5MjUvNzUyNS4NCg0KV2hpbGUgVExT IDEuMiBhbmQgRFRMUyAxLjIgY2FuIGJlIGNvbmZpZ3VyZWQgdG8gYmUgc2VjdXJlLCBSRkMgNzUy NSBpcyBkZWZpbml0ZWx5IG5vdCBlbm91Z2guIFJGQyA3NTQwIHdvdWxkIGJlIGEgZ29vZCBzdGFy dCwgYnV0IGFsc28gdGhhdCB3b3VsZCBuZWVkIHRvIGJlIGV4dGVuZGVkIHdpdGggc3VwcG9ydCBv ZiBleHRlbnNpb25zIGxpa2UgRXh0ZW5kZWQgTWFzdGVyIFNlY3JldCwgU2lnbmF0dXJlIEFsZ29y aXRobXMsIGFuZCBDZXJ0aWZpY2F0ZSBTdGF0dXMgUmVxdWVzdCB0byBiZSBjb25zaWRlcmVkIGZp bmUgaW4gMjAxOS4NCg0KQ2hlZXJzLA0KSm9obg0KDQrvu78NCiANCg0K From nobody Sat Oct 5 04:41:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8036F12012C for ; Sat, 5 Oct 2019 04:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=ZKAm45yz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ikDdBeJr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK_FGPhxx3qs for ; Sat, 5 Oct 2019 04:41:44 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF48B1200D5 for ; Sat, 5 Oct 2019 04:41:43 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5BBED21D73 for ; Sat, 5 Oct 2019 07:41:43 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sat, 05 Oct 2019 07:41:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=CIOYI jZaAvH1ZseaVS+Mq3IcWocmIu1qkNp6sJrYUfI=; b=ZKAm45yzNxXRPSThEezi4 7WtQWeEtTTppwhI5vnmw1h9yEJpebBi7r9myiXsvesoIRds66BUutR5Wk9uK8Kxt Patvi7RQvvGeQV3/f6+oWAVe9WUaiTXvVJnhlLRAv0LPp2kF8ORHyirAbWO+EzFY rTIqX7C15jvzz42om0zJrKlM1dnghJFcQjLkgR5ckK+/H8PJktQHwvL+FL9Xi4VA WtH94oAbU2ZnIRALj76SU6qEeuteBFyKFhNjPcujZRdnedA16HKA5/n6p9bH3fLO uCswf7GiXdQsjrmNPbA9D2e5n9lZ1xvhDQ8/SmNePSBJRmTqBX6/V8rpQsusfIZs w== 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=CIOYIjZaAvH1ZseaVS+Mq3IcWocmIu1qkNp6sJrYU fI=; b=ikDdBeJrJTqO1D2mMMUL8VqUcYOpN0oosVkhxeZx3vsZaZSGEYdGvjJwL cAU34Oimqr1+Kjpq/OPApcBDFP7O7g9HVprgZsBXR25x/XLgGhcfkurONP6aVQWH 4f2mB5G6/AfuAsLWSBMDAS3Gcl9cvEsKs96+TR8Sor4POngMrQLB3ONEk1le7D6r 0h9sAj9paIRkhK9s3u6QEgDyMf+yAHpnifk+oeaZybW5gsR0Evwx8R61PBf+KhPi t0tySVtrKwJBA6xWiuTNx3CW0s/6XRlb8lB6dn9Yo2ukwIga+SzrL/tJhxK+1PN7 0YjBxmhnIIQocrvI0IPfTT1ScO0Iw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepsghhrghmrdgrtgdruh hkpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EAE573C00A1; Sat, 5 Oct 2019 07:41:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> Date: Sat, 05 Oct 2019 04:41:22 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] =?utf-8?q?Selfie_attack_was_Re=3A_Distinguishing_between_e?= =?utf-8?q?xternal/resumption_PSKs?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2019 11:41:46 -0000 Hi Feng, For what it's worth, the latest version of the PSK importers draft inclu= des a "context" field into which identity information can be fed: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#a= ppendix-B Best, Chris On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote: > Hi John, >=20 > Reflection attacks are indeed older, but the selfie attack is a bit=20= > different. It's actually a variant of the unknown key share attack. A=20= > typical example of the UKS attack is the one reported on MQV by Kalisk= i=20 > in 2001 (see "An unknown key-share attack on the MQV key agreement=20 > protocol" in ACM TISSEC 2001). In that example, the adversary plays=20= > message between two users to cause confusion in the identity, but in=20= > Selfie, the adversary plays message with only one user and uses anothe= r=20 > instance of the user to cause confusion in the identity. When we=20 > reported this variant of UKS in [3], we were not aware of anything lik= e=20 > that in the literature. >=20 > Cheers, > Feng >=20 > =EF=BB=BFOn 24/09/2019, 16:17, "John Mattsson" wrote: >=20 > Hi, > =20 > I think these reflection attacks are much older than this. I quick= =20 > search for reflection attack security protocol gives a lot of old=20 > results, The description of reflection attack in the following lecture= =20 > material from 2009 looks just like the "selfie attack" on TLS 1.3 > http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf > =20 > With multiple sections there are other things that change as well.= =20 > If two nodes unintentionally initiate simultaneous ClientHello to each= =20 > other, even if they only want a single secure connection (I have seen=20= > live systems where this happens in practice), an attacker can select=20= > which ClientHello to block (e.g. the one with the strongest=20 > cryptographic parameters). The following security property would then=20= > no longer hold : > =20 > "Downgrade protection: The cryptographic parameters should be t= he > same on both sides and should be the same as if the peers ha= d been > communicating in the absence of an attack" > =20 > (I have not looked at what the definitions in [BBFGKZ16] say). > =20 > Cheers, > John > =20 > -----Original Message----- > From: TLS on behalf of "Hao, Feng"=20 > > Date: Tuesday, 24 September 2019 at 16:09 > To: Mohit Sethi M ,= =20 > "Owen Friel (ofriel)" , Jonathan Hoyland=20 > > Cc: "TLS@ietf.org" > Subject: Re: [TLS] Selfie attack was Re: Distinguishing between=20= > external/resumption PSKs > =20 > =20 > On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"=20 > mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> wrote: > =20 > Hi all, > =20 > On the topic of external PSKs in TLS 1.3, I found a=20 > publication on the=20 > Selfie attack:=20 > https://protect2.fireeye.com/url?k=3Ddd432f13-81c9e5ad-dd436f88-869a17= b5b21b-dc6c6f0a5dd21faf&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F2019%2= F347 > =20 > Perhaps this was already discussed on the list. I thought=20= > that sharing=20 > it again wouldn't hurt while we discuss how servers=20 > distinguish between=20 > external and resumption PSKs. > =20 > I just read the paper with interest. It occurs to me that the=20= > selfie attack is consistent with the "impersonation attack" that we=20= > reported on SPEKE in 2014; see Sec 4.1 [1] and the updated version wit= h=20 > details on how SPEKE is revised in ISO/IEC 11770-4 [2]. The same attac= k=20 > can be traced back to 2010 in [3] where a "worm-hole attack" (Fig. 5,=20= > [3]) is reported on the self-communication mode of HMQV. The essence o= f=20 > these attacks is the same: Bob tricks Alice into thinking that she is=20= > talking to authenticated Bob, but she is actually talking to herself.=20= > In [3], we explained that the attack was missed from the "security=20 > proofs" as the proofs didn't consider multiple sessions.=20 > =20 > The countermeasure we proposed in [1-3] was to ensure the user= =20 > identity is unique in key exchange processes: in case of multiple=20 > sessions that may cause confusion in the user identity, an extension=20= > should be added to the user identity to distinguish the instances. The= =20 > underlying intuition is that one should know "unambiguously" whom they= =20 > are communicating with, and perform authentication based on that. The=20= > discovery of this type of attacks and the proposed solution are=20 > inspired by the "explicitness principle" (Ross Anderson and Roger=20 > Needham, Crypto'95), which states the importance of being explicit on=20= > user identities and other attributes in a public key protocol; also se= e=20 > [3]. I hope it might be useful to people who work on TLS PSK. > =20 > [1]=20 > https://protect2.fireeye.com/url?k=3D5a822513-0608efad-5a826588-869a17= b5b21b-eb260151f78b0718&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F2014%2= F585.pdf > [2] https://arxiv.org/abs/1802.04900 > [3]=20 > https://protect2.fireeye.com/url?k=3Dd5bf88ff-89354241-d5bfc864-869a17= b5b21b-0e9b3bf58e104f32&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F2010%2= F136.pdf=20 > =20 > =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > =20 > =20 > =20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Oct 5 04:55:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C223120145 for ; Sat, 5 Oct 2019 04:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=Sdfqosax; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q8EM1ekI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgBMZO30Y3UG for ; Sat, 5 Oct 2019 04:55:53 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 621B2120113 for ; Sat, 5 Oct 2019 04:55:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8F1D42210D for ; Sat, 5 Oct 2019 07:55:52 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sat, 05 Oct 2019 07:55:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=spHphFvg+L67We9R3J+jf0C1hlpoUoL 52yIFU0c0fbQ=; b=SdfqosaxCizT34VV5CIkorJVCuLHBS7cEvOAAHNpuHWwdBi Q8QF4gqXCnTdIHz8QIjOeFQlrPD69bYIIqTbYFT6MuNS6DsDllGzEEXJnqQRT9N1 4gfv5AbX54Vs1PP+2oS+lPEXlTSQojzhTfh7A8PefNcECcKT7UVWj/a1CPdZdXSQ V3sbOMrNVJFooTkR/E0LOqj+ls6caw1eq+aZph8lN7uHZI1oY3ooS5THPoFMAgyo iMGJbALBlAkLTjpudlwVfWxgA4A+d3d3bW6HitKBovZGG9tyD7mbZOb6LZm/gKTI O18HMsPpQ++VhYiXtomHc3mBQqv8bJK7HER/t1g== 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=spHphF vg+L67We9R3J+jf0C1hlpoUoL52yIFU0c0fbQ=; b=q8EM1ekI4VUy3rrTAaroNe A+zZIbGipUBgyYYI/gMVZwtL2Fo/CPeu0Fg3jE85dUXsGQrnJDclXgq0kpg5ICsP /PR6yrAAAG6A/0QLm54JoMo/tAemSyYMgdoIHFsdSgsOe0oIgAbwvSe21+W8TAxB KqM7bpKynTblKmIOxzwdcrYnsCmdGaLuIwNm0cgl0A8oyL/K4pETp2xzGmWHdw7x mmYf5pBGBL1yO9F3/leJUV1vwKfONMffxwEq4VtetEaFPR7Rvg0f3yNt+2T3sb5g q5uTuGD2wKjmwgxy4mjcUrsRTBXDtEyZe3UP+Gu78nwwVVELgbGzUrBlw3zqBw+Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdegiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D62F03C00A1; Sat, 5 Oct 2019 07:55:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <77112123-822b-0aaa-6cc7-159167637916@cs.tcd.ie> References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> <80881fa1-97df-56c9-10c5-f9e754b6cdb6@cs.tcd.ie> <77112123-822b-0aaa-6cc7-159167637916@cs.tcd.ie> Date: Sat, 05 Oct 2019 04:55:31 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 05 Oct 2019 11:55:55 -0000 On Fri, Sep 27, 2019, at 1:45 AM, Stephen Farrell wrote: > > > On 27/09/2019 04:50, Martin Thomson wrote: > > On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote: > >>>> """The expectation is that TLSv1.2 will continue to be used > >>>> for many years alongside TLSv1.3.""" > >> > >> So is your proposed change to only remove that sentence? > > > > I just checked, and it seems like the only thing the document says > > along these lines, so yeah. > > Grand so. Like I said I don't think it's a biggie so I've > commented out that sentence in the GH version. [1] > > [1] > https://github.com/tlswg/oldversions-deprecate/blob/master/draft-ietf-tls-oldversions-deprecate.txt > > BTW - for the chairs/AD - how are we doing on getting IETF LC under > way? I realise the world won't end if this isn't super-fast but it's > been 3 months since publication was requested which seems like a bit > of a while. Sorry, Stephen! I missed this question. It's in Ben's queue at the moment. Hopefully it'll go up to LC soon (and, in my opinion with no hat, with this proposed sentence removal). Best, Chris From nobody Sat Oct 5 05:06:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8A212018D for ; Sat, 5 Oct 2019 05:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=qUiqw83R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=t5zZYpS5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvkMas2bJBgi for ; Sat, 5 Oct 2019 05:06:26 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866DD120116 for ; Sat, 5 Oct 2019 05:06:26 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id E9546268 for ; Sat, 5 Oct 2019 08:06:25 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sat, 05 Oct 2019 08:06:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=2GsxEUIm1rYHjMR/5m2VL6Q3jBqDJpa AdmBU/dPDWZk=; b=qUiqw83RNW30/+nnycLEHEa5Ar6Fq/yvGm3CvhQ3+sYzCLw aEXSXHG/6sh9sjh8QKKrTDciSaywRJ2E6Y9KdW0o/LhYvpW5NcIHg7+a4+u5AbL5 EI56JhHAN/w5P40F/ezXBBEbHptlfiOuxGI9Rj/I1mLhdIdYrrXthrKgCxtShE9/ JN7+y9jHLCJsbIDJ1QaY+NtphXuE1d9mLQVNxnajh6sCerrMwtjiYUCRrVfSo01Z LuuP2UK7hEFUnJIOAVqCbXkmwM33WSBpnVwJg+DVI6gxLulrOcUDbTmhUPU/VCFL lzrP4/yw5AE2bnRnKuR1pG2zk2lYHN27j4Cp6Kg== 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=2GsxEU Im1rYHjMR/5m2VL6Q3jBqDJpaAdmBU/dPDWZk=; b=t5zZYpS5pDzuaaHYj3MNsv zR9p5kTo6zv1/FrLd56636IbPwxbdKTvzAK06RohmdYm2SDDIRW/CBxfrkVErTW2 T+AbJ/w/IJVxk/G9G+q8JtpTCiNUQGE5l79K98GJdv5Dt0NzziyQMBmzEmW05I6L QPY+eVh5fDy083s03oTiAti/yMkb2wnsAY5Tj4gBvmQzf2+6+bQRp4xiTHCJED45 pvXButPobwlLgTf01+sFORp6vTI+tgjpERp2FJmWYP1mhit8H6BofmexfNqTwfHs +xC9JsuTCnmeCSrx1Jugww0MldtPM5VmU0TzZ6yR4lvcf4dypohW8eiQRYtQ606g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvthen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D87563C00A1; Sat, 5 Oct 2019 08:06:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <9805f0ea-065f-48be-8514-1b8ff3373f7b@www.fastmail.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org> <20191002230402.GF5002@localhost> Date: Sat, 05 Oct 2019 05:06:04 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Sat, 05 Oct 2019 12:06:28 -0000 On Wed, Oct 2, 2019, at 8:44 PM, Viktor Dukhovni wrote: > > On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote: > > > > Asking for one upon resumption seems reasonable to me. Thanks to you and Viktor for bringing up this case! > > Thanks! Much appreciated. > > My other point, which I probably obscured in too many words, is > that a client that prefers to re-use existing tickets, would > normally want to ask for 0 new tickets, but this should not > necessarily preclude the server from issuing one *as needed* > (STEK rollover, ...). > > So there is a difference between a signal that tickets > are simply not wanted, vs. wanted only *as needed*. > > Do you have any thoughts on how a client might signal this? > > The use-case is clients and servers that don't make use of > early-data, and don't need to avoid traffic analysis. For > example, MTA-to-MTA traffic, where the client even identifies > in clear text with "EHLO". Here ticket reuse is the norm, > and renewal is only needed as tickets age. > > [ I hope I managed an suitably concise description this time... ] You did indeed! However, as I'm not sure we should be encouraging ticket re-use. I think asking for 1 upon resumption would be the norm, which should address this case. (That is, I'm not sure adding more information to the signal to support the *as needed* case is worth the added complexity.) Best, Chris > > -- > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Oct 5 05:09:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70F41201DB for ; Sat, 5 Oct 2019 05:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=oNL/hGeO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eCBxCG2Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaHzH0ykAVtX for ; Sat, 5 Oct 2019 05:09:07 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608C3120116 for ; Sat, 5 Oct 2019 05:09:07 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id B34A82E9 for ; Sat, 5 Oct 2019 08:09:06 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sat, 05 Oct 2019 08:09:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=6uR7J2kASpJm/L5Dje3Xr2r35ucRgiw KcN2O5lqzuPM=; b=oNL/hGeOKlvvHGXjJ0RPwWCY4nyUk+mta/FH9PHjo3Gfpdg fU039Z+cJBoLITXFW5V6oWh8XM3Udnhp/kBpCmjpo+0eVce4gGOPhTAFq0Bt5RFl WrNCL4cZiICqNhwg0uJcFG2n/Q8VbjvHK08SixuHuFMHIHsUT1nX9skJ5kcQ5EgA ZJDHyYFg4ub3bUakYszZyWp7fjnqOY9K6g5Zxlam8wQ22wVKX7dj8lSFD4p6U61u X8uc90xofM9v22VsZR5GbC3oKN9fvKhz5ItQDRGJHm6/dERRNDfiFbtvRbS7DBvX MFvHVx6ziYc71XpNufQ4t9zssCmsFhtZwYSbReQ== 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=6uR7J2 kASpJm/L5Dje3Xr2r35ucRgiwKcN2O5lqzuPM=; b=eCBxCG2Ql1RUdopqdUJZnf sexE240Cn2t3D8gpNpw3z9ngMw3U0KgW/mmGERfb+jXinvJ7BOqmsORyBbJ12Cjt nWE9bqeaFDqMRdlVX/h3tK6hVYEjaiDg7uImLQ/FmElzCOGTOcUoJ1DzIap6VHui CVB1AG3QhM4oRQR2vkZDBO2AQwSqmckgPTFFvvOMnY2Cz6UHeeHOUuMcRAa1EhQ2 PZB9tL7sCA8lx2wSlwSKZxyXkTa1RbdZS8J+Z5mlkQQ9AcmoHKladsWf/x9SEXMS cP1jc8JHlfrkZ5d121EW6H2xjb1jGQEmwsrFSbdAs+TkfY1X4EQbN7wkkjRrb5+w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheefgdeglecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrg ifsehhvggrphhinhhgsghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 152E23C00A1; Sat, 5 Oct 2019 08:09:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <2328460.Fs94otCilB@pintsize.usersys.redhat.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> Date: Sat, 05 Oct 2019 05:08:45 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Sat, 05 Oct 2019 12:09:09 -0000 On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > I understand the meaning of count is the higher limit of ticket and the > > > > server can provides any tickets between 0 and count. If that is correct, > > > > this could be clearly stated and indication to chose an appropriated > > > > > > value > > > > > > > for each cases may be provided. > > > > > > > > I would rather see the count value as a hard line from the server with a > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > > see my previous comments: this ignores existence of post handshake > > > authentication, ticket lifetimes and KeyUpdate > > > > I think we agree on the problem which is it is hard to have a specific > > count as tickets may be sent at multiple time during the key exchange or > > the later during the session. If the "SHOULD" is addressing this aspect I > > believe that more text is needed.. From my perspective, what I proposed I > > imagined that count was related to the maximum number of ticket provided > > **each time the server is sending tickets**. The reason for having the same > > number is that the server does not know how the client will use these > > tickets and the client does not know precisely when the server sends the > > tickets. So at the end the number of tickets sent is likely to be n*count > > when n represents the number of times during the session tickets are > > provided. > > > > My understanding of the SHOULD is that it makes legitimate for a server to > > ignore the count value provided by the client. > > yes, it looks like we are in agreement > > Sounds like something that should be spelled out explicitly in the draft. I.e. > it should talk about groups of tickets, not tickets in connection, and it > should definitely not specify the maximum number of tickets a server can send > in a connection. Since it's meant as a hint, removing that clause (maximum number of tickets a server can send in a connection) is reasonable, and sounds like it should address the concerns here. (Assuming we also include text which says servers should obviously place a cap on what they send, as they do today.) Would you agree? I'm really trying to avoid this becoming overly complex, as it's a very small feature. Best, Chris From nobody Sat Oct 5 05:32:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9952C1201DE; Sat, 5 Oct 2019 05:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 XJ67AD5DO6Kq; Sat, 5 Oct 2019 05:32:08 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130083.outbound.protection.outlook.com [40.107.13.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671C712016E; Sat, 5 Oct 2019 05:32:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ChDCgxdOq2MEzizf8cgK9zKSA3dp0wG7p+dC+vJ/fQSuB6wi0stc7gOcyhMCFrMaLReCOvQh3+24rzqcxMVOpvropBw47kHeRsb4q8xEOVwuGFlABaDJHCuJ2/YwKUFCgaQ244WNwWDqU7rLk7Z3z+Ipj4qFTMuSBX+lB+3tU5xBLjcPIUoOe826I6Ac1cLEBwD7CjiIhbk89eZX2dZuFvbxBydM9Z4gIAoAjUGmpxFUsY6O2vtBo6b7MWte7J2ZAC7DcBciJSsmiHwnnnXEoqbyEVXFtWkT2syRGOqcxIwL5EyVqEnL7BJ/99cb66SotB49XsO73AjCJ4Iu5aUkZQ== 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=VJ77zHms5YfDvim4lJ4yWnE6uYxFOKj6OHVVwVdOE30=; b=FRjKFwozZMZVDYT9pzkTqbbX4Y1gDhmZBZ8NnymGvMp9+s4qec43737It+F7Q15JJc8vlDmNTLy6UNq7IExkX3VEiRUuNeJqd87IFtPeE2o4ByyHE+RCw/KX+CFT/G4KnwSnmKR76EI4otjkqmEA5FjKdLZamoMJpAObzmflOIwCWJtPXZyRg8E3xaD1Jh0eUZSY3FK/Ig2eGseN2/M7oRsFFDnx8jgytzknIcfP/3l9qoXnm8GL+ABIC+U7eVzoT0jGgw4RS74BbVtQS+xM5Xn2ohoMvm2WqD69gwE6BDra1uJk88ZIQD5T660VdcEm6wF3uPUilejh9XgcNr063A== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VJ77zHms5YfDvim4lJ4yWnE6uYxFOKj6OHVVwVdOE30=; b=UDElDmUPhSfFEx1z+SFNsRmwY1EMPmPhkvqP9TLO2p2hA4U4eTG79+REsG1ANodKQ1kY4djN2V1P5eCQB92bXcakryFupnbH/7KbGHliltHkxDrzWpFJvg3alszVYyu7Q/2QpQEqGq3sz/tt4KpvKJ5XzQmESzH8FKzmc0F9PUg= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3260.eurprd07.prod.outlook.com (10.170.247.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.7; Sat, 5 Oct 2019 12:32:05 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2327.021; Sat, 5 Oct 2019 12:32:05 +0000 From: John Mattsson To: Benjamin Kaduk CC: Stephen Farrell , Sean Turner , Sean Turner via Datatracker , "tls-chairs@ietf.org" , IESG Secretary , "tls@ietf.org" Thread-Topic: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVLbNwka9w/WHllUqjsaoZBuXNvKdGI6+AgACqmwCAAR2pgIAAAOyAgAA5OQCAAg8aAIACgrcA Date: Sat, 5 Oct 2019 12:32:04 +0000 Message-ID: <54213F5A-4778-4B27-8E19-FD581281B110@ericsson.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <20191004001142.GF6424@kduck.mit.edu> In-Reply-To: <20191004001142.GF6424@kduck.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d8838af5-3483-44b8-14ef-08d7499007c1 x-ms-traffictypediagnostic: HE1PR07MB3260: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(366004)(396003)(136003)(13464003)(51444003)(199004)(189003)(4326008)(86362001)(186003)(26005)(66066001)(6506007)(2906002)(76176011)(53546011)(33656002)(5660300002)(2171002)(102836004)(8676002)(44832011)(6486002)(229853002)(25786009)(966005)(478600001)(81156014)(14454004)(81166006)(2616005)(6916009)(6246003)(99286004)(71190400001)(71200400001)(476003)(6512007)(6306002)(486006)(6116002)(446003)(3846002)(58126008)(11346002)(8936002)(6436002)(305945005)(54906003)(36756003)(91956017)(76116006)(66946007)(7736002)(64756008)(256004)(66446008)(66556008)(66476007)(14444005)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3260; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fT+6QkkNLp07SC2A7VhKGDJxxqiE0XHDjUXvsmckGt4gMwmRwyRKeMbdqRdZ3zw/YTdVhRzyUzrrWsxQviatCc4R0uLXCjcU8Ti5V5AzGwPKcJX5cSoL58/EGTQtlZZAfXrmLUVhmUWkuxyjoifjNotbKIkwidpJAj0ZNZLzCCuUA0egpyn6Ltp+z0Jj0YzNjKm0w8u3FyhswdVeP4lwiW8wiZT7ExQVmQizwKnkX7Kzg67T+51agoP7YEc7AGVsjlCio+UUdpV1IlXJKL8d/VWFEgKqp+Z3AP3smaS5gMnvSgr0SE/GEsqbCVXZYQmBATFZWgLGQih8UPB4HvEBBCldIGZMzRHNrIeZ/oIC5t/i5xDnlqqqDAMUSgxhJesZqTn2TIvmBJRwepd8CmA/LZJqZ0V34Ui4Hm+xB7pkrXyKJZjEInLayMQeY/OrIhDyLyWpBHByZ1OsrSwizaOLfw== 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-Network-Message-Id: d8838af5-3483-44b8-14ef-08d7499007c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2019 12:32:04.9227 (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: eAeAsB0XAnlBe5Dq3Czs3HVkicdlAOEdWZNcYM/zBxX/fYSoKxwexYO+7UETRo4yxdhacYW1SslCRwOVSprTMGulh5UipWRvZIlEoOUGKqc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3260 Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Sat, 05 Oct 2019 12:32:12 -0000 QmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+IHdyb3RlOg0KDQo+PiBUaGF0IGRvZXMgbm90 IHN1cnByaXNlIG1lLCBidXQgSSB0aGluayB0aGF0IGlzIHBhcnQgb2YgdGhlIHByb2JsZW0uIFRo ZXNlDQo+PiB0aGluZ3Mgc2hvdWxkIG1haW5seSBiZSBkZWNpZGVkIGJ5IHRoZSBUTFMgd29ya2lu ZyBncm91cC4NCj4NCj5Ib3c/ICBKdXN0IGJ5IHB1Ymxpc2hpbmcgQkNQcywgb3IgaXMgdGhlIFRM UyBXRyBhbHNvIHN1cHBvc2VkIHRvIChlLmcuKQ0KPndhdGNoIElFVEYgTENzIGFuZCBjb21wbGFp biBhYm91dCB1c2Ugb2Ygb2xkIHByb3RvY29sIHZlcnNpb25zPw0KDQpKdXN0IGJ5IHB1Ymxpc2hp bmcgQkNQcyBhbmQgc3RhbmRhcmQgdHJhY2sgZG9jdW1lbnRzLiBXYXRjaGluZyBvdXQgZm9yIG9s ZCBwcm90b2NvbCB2ZXJzaW9ucyBpbiBvdGhlciBXR+KAmXMgaXMgbm90IHJlYWxseSB0aGUgVExT IFdH4oCZcyBqb2IuIEhvcGVmdWxseSwgZXZlcnlib2R5IGluIHRoZSBzZWN1cml0eSBhcmVhIGNv bXBsYWluIGlmIHRoZXkgc2VlIHVzZSBvZiBvYnNvbGV0ZSB2ZXJzaW9ucyBvciB3ZWFrIGFsZ29y aXRobXMuDQoNCj4+ICJOZXcgaW1wbGVtZW50YXRpb25zIGFuZCBkZXBsb3ltZW50cyBNVVNUIGlu Y2x1ZGUgc3VwcG9ydCBvZiB0aGUgbmV3IHZlcnNpb24iLg0KPj4NCj4+IElmIHRoaXMgaXMgbm90 IGNsZWFybHkgZGVmaW5lZCBzb21ld2hlcmUsIEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgc3BlY2lm aWVkLiBJZiBpdCBpcyA+c3BlY2lmaWVkIHNvbWV3aGVyZSwgSUVURiBuZWVkcyB0byBtYWtlIHN1 cmUgdG8gZm9sbG93IGFwcGx5IGl0Lg0KPg0KPkV2ZW4gc3VwcG9zaW5nIGV2ZXJ5b25lIGFncmVl cyBvbiB0aGlzLCB0aGVyZSBzZWVtIHRvIGJlIHNvbWUgZmVuY2Vwb3N0DQo+aXNzdWVzIHN1cnJv dW5kaW5nICJuZXciLiAgSXMgYSBwcm90b2NvbCAibmV3IiB3aGVuIGl0IGdldHMgcHVibGlzaGVk IGFzIGFuDQo+UkZDLCBvciBhdCBXR0xDLCBvciBldmVuIGVhcmxpZXI/ICBJIGhhdmUgYmVlbiBw cmV0dHkgbGFpZC1iYWNrIHVudGlsIG5vdw0KPmFib3V0IHJlcXVpcmluZyB0aGluZ3MgY29taW5n IGluIGZyb250IG9mIHRoZSBJRVNHIHRvIHBpY2sgdXAgVExTIDEuMywNCj5zaW5jZSBmb3IgdGhl IG1vc3QgcGFydCB0aGV5IHdlcmUgaW4gcHJvZ3Jlc3MgKGluY2x1ZGluZyBpbXBsZW1lbnRhdGlv bnMpDQo+YmVmb3JlIFRMUyAxLjMgaW1wbGVtZW50YXRpb25zIHdlcmUgcmVhZGlseSBhdmFpbGFi bGUgaW4gcHJvZHVjdGlvbi1ncmFkZQ0KPmZvcm0uICBJdCdzIGFib3V0IHRpbWUgdG8gdGlnaHRl biB1cCBvbiB0aGF0LCBzaW5jZSBpdCdzIGJlZW4gb3ZlciBhIHllYXINCj5zaW5jZSBSRkMgODQ0 NiwgYnV0IEknbSBub3Qgc3VyZSBJIGZ1bGx5IHVuZGVyc3RhbmQgd2hlcmUgeW91IHdhbnQgdXMg dG8NCj5mYWxsIGFjcm9zcyB0aGVzZSBib3VuZGFyeSBjb25kaXRpb25zLg0KDQpJIGZ1bGx5IGFn cmVlLiBUaGVyZSBhcmUgc2V2ZXJhbCBib3VuZGFyeSBjb25kaXRpb25zIGhlcmUgYW5kIGFueSBi ZXN0IHByYWN0aWNlIGNhbiBwcm9iYWJseSBub3QgYmUgc3VtbWFyaXplZCBvbiBhIHNpbmdsZSBs aW5lLiBUaWdodGVuaW5nIHVwIHJlcXVpcmVtZW50IG9mIG5ldyBkcmFmdHMgdG8gc3VwcG9ydCBU TFMgMS4zIG5vdyBzZWVtcyBhYm91dCByaWdodC4gVGhlcmUgY291bGQgcHJvYmFibHkgc3RpbGwg YmUgZXhjZXB0aW9ucywgYnV0IHRoZXkgd291bGQgaGF2ZSB0byBiZSB3ZWxsIG1vdGl2YXRlZC4g DQoNCi9Kb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW5qYW1p biBLYWR1ayA8a2FkdWtAbWl0LmVkdT4NCkRhdGU6IEZyaWRheSwgNCBPY3RvYmVyIDIwMTkgYXQg MDI6MTENClRvOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkNj OiBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+LCBTZWFuIFR1cm5l ciA8c2VhbkBzbjNyZC5jb20+LCBTZWFuIFR1cm5lciB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlA aWV0Zi5vcmc+LCAidGxzLWNoYWlyc0BpZXRmLm9yZyIgPHRscy1jaGFpcnNAaWV0Zi5vcmc+LCBJ RVNHIFNlY3JldGFyeSA8aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+LCAiVExTQGlldGYub3JnIiA8 dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFB1YmxpY2F0aW9uIGhhcyBiZWVuIHJl cXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi10bHMtb2xkdmVyc2lvbnMtZGVwcmVjYXRlLTA1DQoNCiAg ICBPbiBXZWQsIE9jdCAwMiwgMjAxOSBhdCAwMjo0NTowOFBNICswMDAwLCBKb2huIE1hdHRzc29u IHdyb3RlOg0KICAgID4gSGksDQogICAgPiANCiAgICA+IFNlYW4gVHVybmVyIHdyb3RlOg0KICAg ID4gPiAiWW91IGNhbiBjaGFuZ2UgdGhlIHRleHQsIGJ1dCBJIGRvIG5vdCBiZWxpZXZlIGl0IHdp bGwgY2hhbmdlIHRoZSBpbXBsZW1lbnRhdGlvbnMuIg0KICAgID4gDQogICAgPiBJIHdvdWxkIG11 Y2ggcmF0aGVyIGhhdmUgYSBmdXR1cmUgcHJvb2YgUkZDIHRoYXQgZm9yYmlkcyBuZWdvdGlhdGlv biBvZiBEVExTIDEuMCB3aXRoIHRoZSBrbm93bGVkZ2UgdGhhdCBzb21lIGltcGxlbWVudGF0aW9u cyB3aWxsIHRlbXBvcmFyeSB2aW9sYXRlIHRoYXQsIHRoYW4gaGF2aW5nIGFuIFJGQyB0aGF0IGxv bmcgdGltZSBpbiB0aGUgZnV0dXJlIGFsbG93cyBuZWdvdGlhdGlvbiBhbmQgdXNlIG9mIERUTFMg MS4wLg0KICAgID4gDQogICAgPiANCiAgICA+IEVyaWMgUmVzY29ybGEgd3JvdGU6DQogICAgPiA+ ICJyZXN1bHQgb2Ygc29tZSBwcmV0dHkgZXh0ZW5zaXZlIGRpc2N1c3Npb24gYW5kIGNvbXByb21p c2luZyBpbiBydGN3ZWIiDQogICAgPiANCiAgICA+IFRoYXQgZG9lcyBub3Qgc3VycHJpc2UgbWUs IGJ1dCBJIHRoaW5rIHRoYXQgaXMgcGFydCBvZiB0aGUgcHJvYmxlbS4gVGhlc2UNCiAgICA+IHRo aW5ncyBzaG91bGQgbWFpbmx5IGJlIGRlY2lkZWQgYnkgdGhlIFRMUyB3b3JraW5nIGdyb3VwLg0K ICAgIA0KICAgIEhvdz8gIEp1c3QgYnkgcHVibGlzaGluZyBCQ1BzLCBvciBpcyB0aGUgVExTIFdH IGFsc28gc3VwcG9zZWQgdG8gKGUuZy4pDQogICAgd2F0Y2ggSUVURiBMQ3MgYW5kIGNvbXBsYWlu IGFib3V0IHVzZSBvZiBvbGQgcHJvdG9jb2wgdmVyc2lvbnM/DQogICAgDQogICAgPiBEcmFmdC1p ZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoIG1hbmRhdGVkIERUTFMgMS4wIHVudGlsIE5vdiAyMDE4 LiBUaGF0IGlzDQogICAgPiBoYWxmIGEgeWVhciBhZnRlciB0aGUgIkRlcHJlY2F0aW5nIFRMU3Yx LjAgYW5kIFRMU3YxLjEiIGRyYWZ0IHdhcw0KICAgID4gc3VibWl0dGVkIGFuZCBhbG1vc3QgNyB5 ZWFycyBhZnRlciBEVExTIDEuMCB3YXMgbWFkZSBvYnNvbGV0ZS4NCiAgICANCiAgICBNYW5kYXRp bmcgKEQpVExTIDEuMCBpcyBub3QgZ29pbmcgdG8gZ2V0IHBhc3QgdGhlIElFU0cgaW4gMjAxOC4g IFdlIGNhbg0KICAgIChhbmQgYXJlKSB0cnkgdG8gYmV0dGVyIGNvbW11bmljYXRlIG91ciBleHBl Y3RhdGlvbnMgZm9yIHRoaXMgc29ydCBvZiB0aGluZw0KICAgIHRvIHRoZSBXR3MsIGJ1dCBpdCBz ZWVtcyB1bnJlYWxpc3RpYyB0byBleHBlY3QgYSAxMDAlIHN1Y2Nlc3MgcmF0ZSBmcm9tDQogICAg dGhlbSwgc2luY2UgaXQncyB1c3VhbGx5IG5vdCB0aGUgV0cncyBjb3JlIGNvbXBldGVuY3kuICAo U2VlIGFsc28NCiAgICBodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPTgxMDYyYTRj LWRkOGZmMDVjLTgxMDY2YWQ3LTBjYzQ3YWQ5M2UyYS0xZTc0OWI3YWVmNmVmY2I4JnE9MSZ1PWh0 dHBzJTNBJTJGJTJGbWFpbGFyY2hpdmUuaWV0Zi5vcmclMkZhcmNoJTJGbXNnJTJGd2djaGFpcnMl MkZkZmVfNW9iU1FtN1lLN0p6VmJtYy1NYlhObVUgLikNCiAgICANCiAgICA+IA0KICAgID4gTm8g bWF0dGVyIHdoYXQgaXMgZG9uZSBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgSSB0aGluayB0aGUg aW1wb3J0YW50IHRoaW5nIHRvIGRpc2N1c3MgaXMgaG93IHdlIGF2b2lkIGRyYWZ0cyB0aGF0IG9u bHkgc3VwcG9ydCBvYnNvbGV0ZSB2ZXJzaW9ucyBvZiBUTFMvRFRMUyBpbiB0aGUgZnV0dXJlLiBB Y2NvcmRpbmcgdG8gbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgY29tbWVudHMgaW4gdGhlIHRocmVh ZCAiTGVzc29ucyBsZWFybmVkIGZyb20gVExTIDEuMCBhbmQgVExTIDEuMSBkZXByZWNhdGlvbiIs IGJvdGggbWUsIEthdGhsZWVuIE1vcmlhcnR5LCBhbmQgTWFydGluIFRob21zb24gdW5kZXJzdGFu ZHMgb2Jzb2xldGVkIGFzOg0KICAgID4gDQogICAgPiAiTmV3IGltcGxlbWVudGF0aW9ucyBhbmQg ZGVwbG95bWVudHMgTVVTVCBpbmNsdWRlIHN1cHBvcnQgb2YgdGhlIG5ldyB2ZXJzaW9uIi4NCiAg ICA+IA0KICAgID4gSWYgdGhpcyBpcyBub3QgY2xlYXJseSBkZWZpbmVkIHNvbWV3aGVyZSwgSSB0 aGluayBpdCBuZWVkcyB0byBiZSBzcGVjaWZpZWQuIElmIGl0IGlzIHNwZWNpZmllZCBzb21ld2hl cmUsIElFVEYgbmVlZHMgdG8gbWFrZSBzdXJlIHRvIGZvbGxvdyBhcHBseSBpdC4NCiAgICANCiAg ICBFdmVuIHN1cHBvc2luZyBldmVyeW9uZSBhZ3JlZXMgb24gdGhpcywgdGhlcmUgc2VlbSB0byBi ZSBzb21lIGZlbmNlcG9zdA0KICAgIGlzc3VlcyBzdXJyb3VuZGluZyAibmV3Ii4gIElzIGEgcHJv dG9jb2wgIm5ldyIgd2hlbiBpdCBnZXRzIHB1Ymxpc2hlZCBhcyBhbg0KICAgIFJGQywgb3IgYXQg V0dMQywgb3IgZXZlbiBlYXJsaWVyPyAgSSBoYXZlIGJlZW4gcHJldHR5IGxhaWQtYmFjayB1bnRp bCBub3cNCiAgICBhYm91dCByZXF1aXJpbmcgdGhpbmdzIGNvbWluZyBpbiBmcm9udCBvZiB0aGUg SUVTRyB0byBwaWNrIHVwIFRMUyAxLjMsDQogICAgc2luY2UgZm9yIHRoZSBtb3N0IHBhcnQgdGhl eSB3ZXJlIGluIHByb2dyZXNzIChpbmNsdWRpbmcgaW1wbGVtZW50YXRpb25zKQ0KICAgIGJlZm9y ZSBUTFMgMS4zIGltcGxlbWVudGF0aW9ucyB3ZXJlIHJlYWRpbHkgYXZhaWxhYmxlIGluIHByb2R1 Y3Rpb24tZ3JhZGUNCiAgICBmb3JtLiAgSXQncyBhYm91dCB0aW1lIHRvIHRpZ2h0ZW4gdXAgb24g dGhhdCwgc2luY2UgaXQncyBiZWVuIG92ZXIgYSB5ZWFyDQogICAgc2luY2UgUkZDIDg0NDYsIGJ1 dCBJJ20gbm90IHN1cmUgSSBmdWxseSB1bmRlcnN0YW5kIHdoZXJlIHlvdSB3YW50IHVzIHRvDQog ICAgZmFsbCBhY3Jvc3MgdGhlc2UgYm91bmRhcnkgY29uZGl0aW9ucy4NCiAgICANCiAgICAtQmVu DQogICAgDQoNCg== From nobody Sat Oct 5 05:57:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7B120123; Sat, 5 Oct 2019 05:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 q8C4YPlIhXw8; Sat, 5 Oct 2019 05:57:52 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30044.outbound.protection.outlook.com [40.107.3.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21536120121; Sat, 5 Oct 2019 05:57:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ayyn50iMKFGSlWDa2Ng11AFsBHvOj8cHLnyqttbxd/qV5OFwlBUpShIN/Fl0XVOdgBPGTLSriMC9W4a6rgs+Yi1zL77oqexdyBEUS79XsMUz9v46gNY1Bk1ayJdHCkDsvG48unrBnlDGL+R+sg+h0ZlnK4NghZSRFbsdCnOAlGrlBZqZSkrrmrzHZ/rpnVm6ZNJNuXbKiWO0AurVONWCQNU6g1B+rRUiTgsavZrfQD0lBGESpg9XK5z/CgfRA60LlbPYPANcQKQvdBvMo1W3EWDSHsi3A7MsPx14qqb7aYz31nK645NFtTTjATVrnJ8Fv+z0ACeOYQw2Am9ngcT5RQ== 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=FpXMuAWaVmqkvCDbtkXb1lusoz1DRt1KAUIxRQ1Td4g=; b=ehc0RnMlZiKl7iEuTJZlKZYEPvWhADpUgsW17Qbn6LLWW8nE30STOt6NB+XivisCT4NfHxvq29TvN2wkOEsSlWOccuQs/mD5NgSiSxDnqmVHu8YUCt6CYMdbqoWLp1Kqf0FI1uXdRBPQ7vJi7e5gPu3bhxnT+A1Qe4m06a4O6jiBHZnsOl7adtrFliobrStOFyMPzB2Cx+uW8/pIVPffvG9tUr59ynfaXbgqQR9PtQ4/RM5/YRFJPVvyqfnl28eW6b6gzx/3cXQQ8nUePMrS4MelSdjATRNjWt4ilycvVxkezaDBybUen0ZXdt2k56EVYlryAZPnwkkO+600bhr5OA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FpXMuAWaVmqkvCDbtkXb1lusoz1DRt1KAUIxRQ1Td4g=; b=N15zdMXW5WEmcg5BdqxS3Fpjtky8qvEkoo+9VtfmTvaUl8YCQxl0aOKtHw1+lA4UOzEpQZS2ALhaMqQTjmlXMS/ctTjkfWaecNXLhgun4cjZprebvIQ+S8g6/l0Mevl0ArmDNGIO7HYxUg6EKOEpEzoQZDyE/3T1IAP0IlTmO+M= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4378.eurprd07.prod.outlook.com (20.176.162.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Sat, 5 Oct 2019 12:57:49 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2327.021; Sat, 5 Oct 2019 12:57:49 +0000 From: John Mattsson To: Cullen Jennings CC: Stephen Farrell , Sean Turner , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , "tls@ietf.org" , Benjamin Kaduk Thread-Topic: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVLbNwka9w/WHllUqjsaoZBuXNvKdGI6+AgACqmwCAAR2pgIAAAOyAgAA5OQCAAvjIAIABoDoA Date: Sat, 5 Oct 2019 12:57:49 +0000 Message-ID: <11EF02D5-4557-4454-9C72-E445453E9AE7@ericsson.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 72b12ee2-83d6-4b40-df52-08d74993a06c x-ms-traffictypediagnostic: HE1PR07MB4378: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(76176011)(81166006)(6506007)(33656002)(186003)(5660300002)(4744005)(26005)(86362001)(14444005)(256004)(102836004)(6116002)(316002)(3846002)(25786009)(99286004)(54906003)(58126008)(6246003)(4326008)(6436002)(6486002)(478600001)(44832011)(14454004)(8676002)(66946007)(6512007)(81156014)(66556008)(91956017)(66446008)(64756008)(66476007)(2906002)(6916009)(305945005)(36756003)(66066001)(7736002)(71200400001)(71190400001)(11346002)(446003)(2616005)(486006)(476003)(76116006)(229853002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4378; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jvPjjmsq9WZQPHPEiY7lZjc6DoVgKEaG26u8pAUEJEGBiyKKfbeURFzJ3Sro7HfPehWm1uKHeDyrLiEwEXeDXJ6V9MMlbdDIr85HG0fs1aG1PBXZJHFbfkVeyuUHERD4ABoUpJkNs0CNtHfIBIStHSjDe2yZFjUZDjDmUuPCowvAynUjOz6rhXyvZzd/bXwi56Hdp+/0xegiEqDfJn1/KcQ44+lcwRVRAJzKwk7Xz7dYhtPqK/xFDsbpPBSqI9Mc4dDzlMy7NKbsEiYBP44P4Bdj0bPT9oR3brz9qBAnmbw6C6gOtj7ilDynKTb/dyiWuxEPt7e5GnWCk/T1VSr2IAJl+TyQI94HUqgJ1dQ6NN9KANsfX/7AdBV17bm8NDheO6zbBy5UVkIBW9DCgC6YRS3FTNUN5qnNhxjI6luTBhw= 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-Network-Message-Id: 72b12ee2-83d6-4b40-df52-08d74993a06c X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2019 12:57:49.5125 (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: ZGPXW2c/nqaulN+WdtnDTwLvWYqkzydldoCrggEEjgR44fiLgygE+bjd5pQxzRuVxeqvcnOUUyHoCFnPIy6VJKxiAQJUrvixpruIUtr+YNo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4378 Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Sat, 05 Oct 2019 12:57:55 -0000 Q3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPiB3cm90ZToNCg0KPkkgZG8gbm90IHRoaW5r IHlvdSBoYXZlIGNvbnNlbnN1cyBmb3IgdGhhdCBjaGFuZ2UgdG8gV2ViUlRDIC0gaXQgd2FzDQo+ ZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5LiBJIHdvdWxkIGp1c3QgbGVhdmUgdGhpbmdzIGFzIHRoZXkg YXJlLg0KDQpNeSBzdWdnZXN0aW9uIHdhcyB0byBoYXZlIGRyYWZ0LWlldGYtdGxzLW9sZHZlcnNp b25zLWRlcHJlY2F0ZSB1cGRhdGUgdGhlIHdlYnJ0YyBkcmFmdC4gSSBkaWQgbm90IHRoaW5rIHRo YXQgd2FzIGNvbnRyb3ZlcnNpYWwuIE15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgSUVURiB3aXRo IHRoaXMgQkNQIGhhZCBmb3JiaWRkZW4gbmVnb3RpYXRpb24gb2YgRFRMUyAxLjAgd2l0aG91dCBl eGNlcHRpb25zLiBJIHRob3VnaHQgdGhlIHdlYnJ0YyBkcmFmdCBoYWQgc2ltcGx5IGJlZW4gZm9y Z290dGVuIGFuZCB0aGF0IEkgaGFkIG1hZGUgYSDigJxnb29kIGNhdGNo4oCdIGFzIEthdGhsZWVu IGV4cHJlc3NlZCBpdC4NCg0KSSBjYW4gbGl2ZSB3aXRoIHRoZSBCQ1Agbm90IHVwZGF0aW5nIGRy YWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZSBpZiB0aGF0IGRlbGF5cyBwdWJsaXNo aW5nLCBidXQgb3RoZXJ3aXNlIEkgc2VlIG5vIHJlYXNvbnMgd2h5IFdlYlJUQyBzaG91bGQgZ2V0 IHNwZWNpYWwgdHJlYXRtZW50LiBUaGVyZSBhcmUgb3RoZXIgZGVwbG95bWVudHMgb3V0IHRoZXJl IHdpdGggZGV2aWNlcyBub3Qgc3VwcG9ydGluZyBUTFMgMS4yLg0KDQogDQoNCg== From nobody Sat Oct 5 06:12:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98E12006A; Sat, 5 Oct 2019 06:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 kuDExwNcXVy3; Sat, 5 Oct 2019 06:12:46 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80070.outbound.protection.outlook.com [40.107.8.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA18A12003F; Sat, 5 Oct 2019 06:12:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ho6eeJKDKg+8EwuiNWPTF6H5Xl+Bs0kxAE54JiQJSRLAfz//rGNubp7/duNDdM7ViQY9ipbfKpOic5fOiA9KbhTyPANbYcLffmu4/VQ8PhB7dhGxrdHyjjmDPwkeXjGZvi0hxNQEcw8jm2E1SnHkNRzpdN6AJV1ihDoEvb8tKeuXSTZBIKdXl1kNKePiK2ldVRdgqSayC1/TfePBzi3alkDvkn0fwE1T3lN/ZEsxY2IerTum3bPrSm7SGSoVQ6tzLi+yHyWlkSMlh0dL9QSjOOywOYcycPgDGaAiduDxQJLcxuQvsecPOg4wU3JQeJiqI+dMsQemDma/wfRYLCCgDQ== 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=i2L6/J+i+2a7IDr9GoEJzIYQd1wNXuPuiLWdUOhi8eY=; b=bvhKgFm7//dLLX/SvCJhaji3M6Ty7VKHGLya4/GQwxf8DORG9OiSwDHFXPMnSTz9ge+aiyKizLIT2s7cJTU2romz1Shxvg9U4QGdq5KLzEAqJ6rceifGMYAJqYdnRRvjgMvdLazJkwkfFHaPdf8FQTNDRhzUfcDWMRosDeTBxUhtZeVYvTzERbKNj4ZHToE4dOI1910n3+S+cf7W8gt+ouXcacvyPZwcZDMX09OXcCVMu2UbQA9EhvJ/L9+VzUhxl5V81ugHrsEz/V9XtxBoO/pt0NlnN/sEJ2M68ulXQcC/AbWnFDkxg/6LahOJey5a45QLfJnqJ21Gvwkm+oumjw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i2L6/J+i+2a7IDr9GoEJzIYQd1wNXuPuiLWdUOhi8eY=; b=P/nI+7el9kTOcTJVlF2ALFgVcIKaliDasdxTTw6s3EXXAZr89JLxvmIznWLe2qpkvfO/ZJ3ZzW0W6c91eueXEibM7VySX6iFhRsKJGL9BqZ3BBeqgihXpzdQmWyqb5gezHhRBhQLepghwQYmUam/9kxyLP4cWmfFgmXNUiWn9Gc= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3132.eurprd07.prod.outlook.com (10.170.242.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Sat, 5 Oct 2019 13:12:42 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2327.021; Sat, 5 Oct 2019 13:12:42 +0000 From: John Mattsson To: Rob Sayre , Eric Rescorla CC: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , Benjamin Kaduk Thread-Topic: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVLbNwka9w/WHllUqjsaoZBuXNvKdGI6+AgACqmwCAAR2pgIAAAOyAgAA5OQCAAvjIAIAACdKAgAABSgCAAALPgIABlngA Date: Sat, 5 Oct 2019 13:12:42 +0000 Message-ID: <0744E7F3-B4D0-4935-8601-DB4D45DCACCB@ericsson.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e63cda7c-5312-4035-0453-08d74995b4c7 x-ms-traffictypediagnostic: HE1PR07MB3132: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(396003)(39860400002)(366004)(199004)(189003)(6436002)(76176011)(186003)(236005)(6512007)(6506007)(7736002)(6486002)(6246003)(54896002)(6116002)(102836004)(11346002)(486006)(53546011)(446003)(99286004)(2616005)(476003)(44832011)(4326008)(66556008)(229853002)(2906002)(33656002)(5660300002)(26005)(81166006)(8936002)(36756003)(81156014)(54906003)(256004)(3846002)(790700001)(66446008)(71190400001)(316002)(110136005)(8676002)(6306002)(86362001)(478600001)(25786009)(66066001)(58126008)(606006)(76116006)(91956017)(14454004)(66476007)(71200400001)(66946007)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3132; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FEBpHb7S0RG8A43J0n2k6jPSf/1EIhZYaLubA6xA2pjdtDuPMxdWgGsniDrgNvd2oBFrBXsF7mBbN794d+mV+J5rbn+Zd27W2Gd6DkTXjRMDt3akYRmyGsWbHrR8qQqdvEhyDCmavQ8YNiJhp/4FlQtMrVeNiK/xySa21S5Hs7T5Rp1A/3yoa+TeekXYhv+VGTJsT8QjGVqesgOTMns6iZI4UYZOJ39UvDGPyLcueA/whFFuf9PU9bDc5Sa0MlSjHTxaFPRspyFMR3GoOZjpGdpVabrP3S1RwgC2Oev3Z0z6RUS9cHIvWCQEcwdGacdEKiW3RS4ayI5UhTx7Edci1S3BDEhpEVHzETHaSPPyu1D6L+JyWk7nu6R+fmuhiLpwOtVIghsWOLKSXhBx/zhQ6u/mv0NTk1AhlqASmWSP2o/tDfQpalOWYhIAfXXoQv2vNU+rzFNHOBLARTTS8JnB6A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0744E7F3B4D049358601DB4D45DCACCBericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e63cda7c-5312-4035-0453-08d74995b4c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2019 13:12:42.5952 (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: IaS873tbqDiWF66OowrQ2Nz+xv49JfSD956mATXmG9bVCYExO05UQlKe9EVDxHOWpZ3HP6rx4lHsISqy98e87i1GOcGgIVpma7OxFYPaVvo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3132 Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Sat, 05 Oct 2019 13:12:49 -0000 --_000_0744E7F3B4D049358601DB4D45DCACCBericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iIFNheXJlIHNheXJlckBnbWFpbC5jb20gd3JvdGU6DQoNCiJJcyB0aGVyZSBzb21lIGRhdGEg YmVoaW5kIHRoaXM/DQoNCkkgYWdyZWUgd2l0aCBSb2IsIGl0IHdvdWxkIGJlIGludGVyZXN0aW5n IHRvIGdldCBzb21lIGRhdGEgb24gd2h5IHdlYnJ0YyBuZWVkIHRvIGNvbnRpbnVlIHRvIG5lZ290 aWF0ZSBhbmQgdXNlIERUTFMgMS4wLiBJdCB3b3VsZCBhbHNvIGJlIGludGVyZXN0aW5nIHRvIGtu b3cgZm9yIGhvdyBsb25nIHRpbWUgd2VicnRjIHBsYW5zIHRvIGNvbnRpbnVlIG5lZ290aWF0ZSBh bmQgdXNlIERUTFMgMS4wLg0KDQpFQVAtVExTIGFsc28gaGF2ZSBsZWdhY3kgZGV2aWNlcyB0aGF0 IGRvIG5vdCBzdXBwb3J0IFRMUyAxLjIgYW5kIGluIHByYWN0aWNlIHNvbWUgRUFQIHNlcnZlcnMg d2lsbCBwcm9iYWJseSBjb250aW51ZSB0byBuZWdvdGlhdGUgVExTIDEuMSBmb3IgYSB3aGlsZS4g U3RpbGwsIHRoZSBFTVUgV0cgYWdyZWVkIHRoYXQgdGhlIHVwY29taW5nIEJDUCBmb3JiaWRkaW5n IHVzZSBhbmQgbmVnb3RpYXRpb24gb2YgVExTIDEuMSB3YXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRv IGFzIGl0IHB1dHMgaW5jcmVhc2VkIHByZXNzdXJlIG9uIGltcGxlbWVudGF0aW9ucyB0byBpbXBy b3ZlLg0KDQpDaGVlcnMsDQpKb2huDQoNCkZyb206IFJvYiBTYXlyZSA8c2F5cmVyQGdtYWlsLmNv bT4NCkRhdGU6IEZyaWRheSwgNCBPY3RvYmVyIDIwMTkgYXQgMTY6NTgNClRvOiBFcmljIFJlc2Nv cmxhIDxla3JAcnRmbS5jb20+DQpDYzogQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPiwg IlRMU0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4sIFNlYW4gVHVybmVyIHZpYSBEYXRhdHJhY2tl ciA8bm9yZXBseUBpZXRmLm9yZz4sIElFU0cgU2VjcmV0YXJ5IDxpZXNnLXNlY3JldGFyeUBpZXRm Lm9yZz4sICJ0bHMtY2hhaXJzQGlldGYub3JnIiA8dGxzLWNoYWlyc0BpZXRmLm9yZz4sIEpvaG4g TWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPiwgQmVuamFtaW4gS2FkdWsgPGth ZHVrQG1pdC5lZHU+DQpTdWJqZWN0OiBSZTogW1RMU10gUHVibGljYXRpb24gaGFzIGJlZW4gcmVx dWVzdGVkIGZvciBkcmFmdC1pZXRmLXRscy1vbGR2ZXJzaW9ucy1kZXByZWNhdGUtMDUNCg0KDQoN Ck9uIEZyaSwgT2N0IDQsIDIwMTkgYXQgOTo0OCBQTSBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQoNCk9uIEZyaSwgT2N0IDQsIDIwMTkg YXQgNzo0MyBBTSBSb2IgU2F5cmUgPHNheXJlckBnbWFpbC5jb208bWFpbHRvOnNheXJlckBnbWFp bC5jb20+PiB3cm90ZToNCk9uIEZyaSwgT2N0IDQsIDIwMTkgYXQgOTowOCBQTSBDdWxsZW4gSmVu bmluZ3MgPGZsdWZmeUBpaWkuY2E8bWFpbHRvOmZsdWZmeUBpaWkuY2E+PiB3cm90ZToNCg0KSSBk byBub3QgdGhpbmsgeW91IGhhdmUgY29uc2Vuc3VzIGZvciB0aGF0IGNoYW5nZSB0byBXZWJSVEMg LSBpdCB3YXMgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5LiAuLi4NCg0KIFdoaWxlIHRoYXQgbWF5IGJl IHRydWUsIHJlYWRlcnMgb2YgdGhpcyBsaXN0IG1pZ2h0IHdhbnQgdG8gcmVhZCBhIHJhdGlvbmFs ZSwgcmF0aGVyIHRoYW4ganVzdCB0aGUgcmVzdWx0cyBvZiBhIG5lZ290aWF0aW9uLiBJcyB0aGVy ZSBhIHJhdGlvbmFsZSBzb21ld2hlcmU/DQoNCkl0IHNlZW1zIHN0cmFuZ2UgdG8gcHV0IERUTFMg MS4wIChiYXNlZCBvbiBUTFMgMS4xKSBpbnRvIG5ldyBkb2N1bWVudHMuDQoNCkEgZmV3IHBvaW50 cy4NCg0KMS4gSXQgZG9lc24ndCBwdWxsIGl0IGluLiBUaGVyZSdzIG5vIHJlZmVyZW5jZSBhbmQg dGhlcmUncyBqdXN0IGFuIGluZm9ybWF0aXZlIHN0YXRlbWVudC4NCg0KU2hvdWxkbid0IHRoZXJl IGJlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZT8NCg0KMi4gVGhlcmUgaXMgYSByYXRpb25hbGUu IEluIGZhY3QsIHRoZSByZWxldmFudCB0ZXh0IHByZXR0eSBtdWNoIGlzIGFsbCByYXRpb25hbGUu DQoNCiAgIEFsbCBJbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IERUTFMgMS4yIHdpdGggdGhl DQoNCiAgIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiBjaXBoZXIgc3Vp dGUgYW5kIHRoZSBQLTI1Ng0KDQogICBjdXJ2ZSBbRklQUzE4NjxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0yMCNyZWYtRklQUzE4Nj5d LiAgRWFybGllciBkcmFmdHMgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkIERUTFMNCg0K ICAgMS4wIHdpdGggdGhlIGNpcGhlciBzdWl0ZSBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4 X0NCQ19TSEEsIGFuZA0KDQogICBhdCB0aGUgdGltZSBvZiB0aGlzIHdyaXRpbmcgc29tZSBpbXBs ZW1lbnRhdGlvbnMgZG8gbm90IHN1cHBvcnQgRFRMUw0KDQogICAxLjI7IGVuZHBvaW50cyB3aGlj aCBzdXBwb3J0IG9ubHkgRFRMUyAxLjIgbWlnaHQgZW5jb3VudGVyDQoNCiAgIGludGVyb3BlcmFi aWxpdHkgaXNzdWVzLg0KDQpZZXMsIEkgcmVhZCB0aGlzIHNlY3Rpb24gYW5kIEkgd2FzIHdvbmRl cmluZyB3aGF0IHRoZSByYXRpb25hbGUgd2FzIGZvciB0aGUgdGV4dDogImVuZHBvaW50cyB3aGlj aCBzdXBwb3J0IG9ubHkgRFRMUyAxLjIgbWlnaHQgZW5jb3VudGVyIGludGVyb3BlcmFiaWxpdHkg aXNzdWVzLiIgSXMgdGhlcmUgc29tZSBkYXRhIGJlaGluZCB0aGlzPyBJJ20gbm90IHN1Z2dlc3Rp bmcgYSBjaGFuZ2UgaW4gdGhlIGRyYWZ0IHdpdGhvdXQgbW9yZSBpbmZvcm1hdGlvbiwgYnV0IEkg ZG8gd29uZGVyIGhvdyB0aGUgV0cgY2FtZSB0byBhZ3JlZSBvbiB0aGlzIHRleHQuDQoNCnRoYW5r cywNClJvYg0KDQo= --_000_0744E7F3B4D049358601DB4D45DCACCBericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9iIFNheXJlIHNheXJlckBn bWFpbC5jb20gd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+JnF1b3Q7SXMg dGhlcmUgc29tZSBkYXRhIGJlaGluZCB0aGlzPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SSBhZ3JlZSB3aXRoIFJvYiwgaXQgd291bGQgYmUgaW50ZXJlc3RpbmcgdG8gZ2V0IHNv bWUgZGF0YSBvbiB3aHkgd2VicnRjIG5lZWQgdG8gY29udGludWUgdG8gbmVnb3RpYXRlIGFuZCB1 c2UgRFRMUyAxLjAuIEl0IHdvdWxkIGFsc28gYmUgaW50ZXJlc3RpbmcgdG8ga25vdyBmb3IgaG93 IGxvbmcgdGltZSB3ZWJydGMNCiBwbGFucyB0byBjb250aW51ZSBuZWdvdGlhdGUgYW5kIHVzZSBE VExTIDEuMC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5FQVAtVExTIGFsc28gaGF2 ZSBsZWdhY3kgZGV2aWNlcyB0aGF0IGRvIG5vdCBzdXBwb3J0IFRMUyAxLjIgYW5kIGluIHByYWN0 aWNlIHNvbWUgRUFQIHNlcnZlcnMgd2lsbCBwcm9iYWJseSBjb250aW51ZSB0byBuZWdvdGlhdGUg VExTIDEuMSBmb3IgYSB3aGlsZS4gU3RpbGwsIHRoZSBFTVUgV0cgYWdyZWVkIHRoYXQgdGhlDQog dXBjb21pbmcgQkNQIGZvcmJpZGRpbmcgdXNlIGFuZCBuZWdvdGlhdGlvbiBvZiBUTFMgMS4xIHdh cyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gYXMgaXQgcHV0cyBpbmNyZWFzZWQgcHJlc3N1cmUgb24g aW1wbGVtZW50YXRpb25zIHRvIGltcHJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkpvaG48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJvYiBTYXlyZSAmbHQ7c2F5cmVyQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5LCA0IE9jdG9iZXIgMjAxOSBhdCAxNjo1ODxicj4N CjxiPlRvOiA8L2I+RXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ozxicj4NCjxiPkNj OiA8L2I+Q3VsbGVuIEplbm5pbmdzICZsdDtmbHVmZnlAaWlpLmNhJmd0OywgJnF1b3Q7VExTQGll dGYub3JnJnF1b3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7LCBTZWFuIFR1cm5lciB2aWEgRGF0YXRy YWNrZXIgJmx0O25vcmVwbHlAaWV0Zi5vcmcmZ3Q7LCBJRVNHIFNlY3JldGFyeSAmbHQ7aWVzZy1z ZWNyZXRhcnlAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDt0bHMtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZs dDt0bHMtY2hhaXJzQGlldGYub3JnJmd0OywgSm9obiBNYXR0c3NvbiAmbHQ7am9obi5tYXR0c3Nv bkBlcmljc3Nvbi5jb20mZ3Q7LCBCZW5qYW1pbg0KIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1RMU10gUHVibGljYXRpb24gaGFzIGJlZW4gcmVx dWVzdGVkIGZvciBkcmFmdC1pZXRmLXRscy1vbGR2ZXJzaW9ucy1kZXByZWNhdGUtMDU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIEZy aSwgT2N0IDQsIDIwMTkgYXQgOTo0OCBQTSBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWls dG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBGcmksIE9jdCA0LCAyMDE5IGF0IDc6NDMgQU0gUm9i IFNheXJlICZsdDs8YSBocmVmPSJtYWlsdG86c2F5cmVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnNheXJlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gRnJpLCBPY3QgNCwgMjAxOSBhdCA5OjA4IFBNIEN1bGxl biBKZW5uaW5ncyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZsdWZmeUBpaWkuY2EiIHRhcmdldD0iX2Js YW5rIj5mbHVmZnlAaWlpLmNhPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGJyPg0KSSBkbyBub3QgdGhpbmsgeW91IGhhdmUgY29uc2Vuc3VzIGZvciB0 aGF0IGNoYW5nZSB0byBXZWJSVEMgLSBpdCB3YXMgZGlzY3Vzc2VkIGV4dGVuc2l2ZWx5LiAuLi48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwO1doaWxlIHRoYXQgbWF5IGJlIHRydWUsIHJlYWRlcnMgb2YgdGhpcyBsaXN0IG1pZ2h0 IHdhbnQgdG8gcmVhZCBhIHJhdGlvbmFsZSwgcmF0aGVyIHRoYW4ganVzdCB0aGUgcmVzdWx0cyBv ZiBhIG5lZ290aWF0aW9uLiBJcyB0aGVyZSBhIHJhdGlvbmFsZSBzb21ld2hlcmU/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkl0IHNlZW1zIHN0cmFu Z2UgdG8gcHV0IERUTFMgMS4wIChiYXNlZCBvbiBUTFMgMS4xKSBpbnRvIG5ldyBkb2N1bWVudHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BIGZldyBwb2ludHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjEuIEl0IGRvZXNuJ3QgcHVsbCBpdCBp bi4gVGhlcmUncyBubyByZWZlcmVuY2UgYW5kIHRoZXJlJ3MganVzdCBhbiBpbmZvcm1hdGl2ZSBz dGF0ZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5TaG91bGRuJ3QgdGhlcmUgYmUgYW4g aW5mb3JtYXRpdmUgcmVmZXJlbmNlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4yLiBUaGVyZSBpcyBh IHJhdGlvbmFsZS4gSW4gZmFjdCwgdGhlIHJlbGV2YW50IHRleHQgcHJldHR5IG11Y2ggaXMgYWxs IHJhdGlvbmFsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBBbGwgSW1wbGVtZW50YXRpb25zIE1VU1Qgc3Vw cG9ydCBEVExTIDEuMiB3aXRoIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FF U18xMjhfR0NNX1NIQTI1NiBjaXBoZXIgc3VpdGUgYW5kIHRoZSBQLTI1NjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IGN1 cnZlIFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3 ZWItc2VjdXJpdHktYXJjaC0yMCNyZWYtRklQUzE4NiIgdGFyZ2V0PSJfYmxhbmsiIHRpdGxlPSIm cXVvdDtEaWdpdGFsIFNpZ25hdHVyZSBTdGFuZGFyZCAoRFNTKSZxdW90OyI+RklQUzE4NjwvYT5d LiZuYnNwOyBFYXJsaWVyIGRyYWZ0cyBvZiB0aGlzIHNwZWNpZmljYXRpb24gcmVxdWlyZWQgRFRM UzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7IDEuMCB3aXRoIHRoZSBjaXBoZXIgc3VpdGUgVExTX0VDREhFX0VDRFNBX1dJ VEhfQUVTXzEyOF9DQkNfU0hBLCBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBhdCB0aGUgdGltZSBvZiB0aGlzIHdy aXRpbmcgc29tZSBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IHN1cHBvcnQgRFRMUzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7 IDEuMjsgZW5kcG9pbnRzIHdoaWNoIHN1cHBvcnQgb25seSBEVExTIDEuMiBtaWdodCBlbmNvdW50 ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOyZuYnNwOyBpbnRlcm9wZXJhYmlsaXR5IGlzc3Vlcy4gPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5ZZXMsIEkgcmVhZCB0aGlzIHNlY3Rpb24gYW5kIEkgd2FzIHdvbmRl cmluZyB3aGF0IHRoZSByYXRpb25hbGUgd2FzIGZvciB0aGUgdGV4dDogJnF1b3Q7ZW5kcG9pbnRz IHdoaWNoIHN1cHBvcnQgb25seSBEVExTIDEuMiBtaWdodCBlbmNvdW50ZXIgaW50ZXJvcGVyYWJp bGl0eSBpc3N1ZXMuJnF1b3Q7IElzIHRoZXJlIHNvbWUgZGF0YSBiZWhpbmQgdGhpcz8gSSdtIG5v dCBzdWdnZXN0aW5nDQogYSBjaGFuZ2UgaW4gdGhlIGRyYWZ0IHdpdGhvdXQgbW9yZSBpbmZvcm1h dGlvbiwgYnV0IEkgZG8gd29uZGVyIGhvdyB0aGUgV0cgY2FtZSB0byBhZ3JlZSBvbiB0aGlzIHRl eHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_0744E7F3B4D049358601DB4D45DCACCBericssoncom_-- From nobody Sat Oct 5 10:05:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7B12087E for ; Sat, 5 Oct 2019 10:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 USYGpareYTzR for ; Sat, 5 Oct 2019 10:05:03 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 790A01200B6 for ; Sat, 5 Oct 2019 10:05:03 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 9E71C2AD631; Sat, 5 Oct 2019 13:05:02 -0400 (EDT) Date: Sat, 5 Oct 2019 13:05:02 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20191005170502.GF21772@straasha.imrryr.org> Reply-To: tls@ietf.org References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <20191001145600.GU21772@straasha.imrryr.org> <20191002230402.GF5002@localhost> <9805f0ea-065f-48be-8514-1b8ff3373f7b@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9805f0ea-065f-48be-8514-1b8ff3373f7b@www.fastmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Sat, 05 Oct 2019 17:05:06 -0000 On Sat, Oct 05, 2019 at 05:06:04AM -0700, Christopher Wood wrote: > > The use-case is clients and servers that don't make use of > > early-data, and don't need to avoid traffic analysis. For > > example, MTA-to-MTA traffic, where the client even identifies > > in clear text with "EHLO". Here ticket reuse is the norm, > > and renewal is only needed as tickets age. > > > > [ I hope I managed a suitably concise description this time... ] > > You did indeed! However, as I'm not sure we should be encouraging ticket > re-use. I think asking for 1 upon resumption would be the norm, which > should address this case. Granted, ill-conceived ticket re-use should not be encouraged, in fact should be prominently discouraged. But perhaps the MTA-to-MTA use-case has more general applicability in a broad class of server-to-server (datacentre-to-datacentre) traffic, where the client has a long-term stable IP address, and often a long-term affiliation with a single downstream peer. An obvious example that comes to mind is a reverse-proxy that terminates and resumes TLS. At various $jobs I've helped folks design/deploy such beasts in the DMZ. Here there's a steady stream of traffic between two nodes, and traffic-analysis "privacy" considerations around ticket re-use don't come into play. > (That is, I'm not sure adding more information to the signal to support > the *as needed* case is worth the added complexity.) That's the key question. Such a signal could perhaps steal the high-bit of the ticket count, limiting the count to at most 127. Or alternatively the extension could send * 0 to mean no tickets ever (client has no ticket cache) * 1 to mean none required, but refresh as needed * n=2 or more to mean please send n-1 tickets. This keeps the structure of the extension simple: for most clients just send n+1 for n∈[1,254]. On the server side for n∈[2,255], just vend the lower of the server's limit and n-1, for 0 send no tickets, which leaves only "n=1" for the server to handle specially, by renewing the ticket if it is either a single-use ticket or suitably dated. -- Viktor. From nobody Sat Oct 5 17:45:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7061208B3 for ; Sat, 5 Oct 2019 17:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=fZUr/ye5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=03DYkjYG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0AjyBBkFTuF for ; Sat, 5 Oct 2019 17:45:31 -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 B25D712089F for ; Sat, 5 Oct 2019 17:45:31 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4DD5A3D1 for ; Sat, 5 Oct 2019 20:45:31 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 05 Oct 2019 20:45:31 -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=AnAb3ihXd8URHv2/Xcl90COcjghn5Fy2dzoEgNC0ODg=; b=fZUr/ye5 yjhhMuGQyxFhTdH9PPUiEQLX4oz4WGNrDVPBbCSmHV/+mOqLU2eBv+gRs0ftAtr6 rV44QJfq819GdAMua6xKb/1fqVyu3kGnbe2cryyiSpQzkDJcW/gHE/1b3REIoPlc GE6MdZlI8iRMwKxpPjUz/KDzPafl9piZjDk3c8pCRQXAhu8+xOGrfIr9FXNV4ZUF goWfI9kQoDQCBrouZ4056AHBdIVk66XMEQxKftTGw93+aoa9uy+Mh9B4m64o3mHC FOKNajfjwsZKa336F5+3mah1B78ENbisaY1bUDXPpXnjyPD4LbidAy6AhEmqoi/n NJHZMs2AFiLTxg== 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=AnAb3ihXd8URHv2/Xcl90COcjghn5 Fy2dzoEgNC0ODg=; b=03DYkjYG89zvpjBL7ErgjoTNn4/8dXb/IIWgx50bMpv62 m1bCpcZ2JKzkji+CTtAtEbj9JchWkIYiHwuVTWh1HG4sL9f5hxOPjbvZ1iY6UdBo CIf2lnaCg5a28dkJ8L4JD5l0XjZQi5yYC2Unr24/TyedD5487OlCdJeeDLa4JkUx dCHsc0warVeMKQB/rVcOx/Zb/eeF9Gelt+HKQ82qyDVc7h6wSqF5OAje/hP9lj48 plf9dMmZRQemu+Fx4btSW8VMXrfFRS0ETO6KHv40JVoYwoRmEZG0FOUYXiwOle/h B81gSP3MVDFaLScChoF/A9Nm21rTmk0te1kR3WUGQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheeggddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgepud X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 32C76D6005A for ; Sat, 5 Oct 2019 20:45:30 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 4CEBAC03FA for ; Sun, 6 Oct 2019 00:45:27 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3435284051881650402==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: tls@ietf.org Message-Id: <20191006004527.4CEBAC03FA@cloud.mnot.net> Date: Sun, 6 Oct 2019 00:45:27 +0000 (UTC) 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, 06 Oct 2019 00:45:39 -0000 --===============3435284051881650402== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC1) 1 issues created: - Clarification on repeated extensions in ESNIRecord and ESNIKeys (by dmc= ardle) https://github.com/tlswg/draft-ietf-tls-esni/issues/183 = 1 issues received 1 new comments: - #182 Consider disabling server tickets if tickets are not uniform acros= s the ESNI anonymity set (1 by kazuho) https://github.com/tlswg/draft-ietf-tls-esni/issues/182 = * tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0) 1 issues created: - Document security requirements and properties (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/20 = 1 issues closed: - Change intended status https://github.com/tlswg/draft-ietf-tls-external= -psk-importer/issues/11 = * tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0) 1 issues created: - Discuss possible self-induced amplification for servers (by chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/6 = Pull requests ------------- * tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Add some security considerations text (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/21 = 1 pull requests merged: - Change category from Experimental to Standards Track. https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/19 = * tlswg/dtls13-spec (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Change the key label for DTLS to be "dtls13". Note that we have to (by = ekr) https://github.com/tlswg/dtls13-spec/pull/99 = 1 pull requests received 1 new comments: - #99 Change the key label for DTLS to be "dtls13". Note that we have to = (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/99 = Repositories tracked by this digest: ----------------------------------- * 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 --===============3435284051881650402== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday October 06, 2019

Issues

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

1 issues created:

1 issues received 1 new comments:

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

1 issues created:

1 issues closed:

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

1 issues created:

Pull requests

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

1 pull requests submitted:

1 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============3435284051881650402==-- From nobody Sun Oct 6 09:42:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23532120147; Sun, 6 Oct 2019 09:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 wUVcbP_nsosJ; Sun, 6 Oct 2019 09:42:17 -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 A970A12013C; Sun, 6 Oct 2019 09:42:14 -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 x96Gg55f020327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 6 Oct 2019 12:42:08 -0400 Date: Sun, 6 Oct 2019 09:42:05 -0700 From: Benjamin Kaduk To: Rob Sayre Cc: Eric Rescorla , Cullen Jennings , "tls@ietf.org" , "tls-chairs@ietf.org" , John Mattsson , draft-ietf-rtcweb-security-arch.ad@ietf.org Message-ID: <20191006164205.GW6722@kduck.mit.edu> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Sun, 06 Oct 2019 16:42:19 -0000 On Fri, Oct 04, 2019 at 09:57:53PM +0700, Rob Sayre wrote: > On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla wrote: > > > > > > > On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote: > > > >> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote: > >> > >>> > >>> I do not think you have consensus for that change to WebRTC - it was > >>> discussed extensively. ... > >>> > >> > >> While that may be true, readers of this list might want to read a > >> rationale, rather than just the results of a negotiation. Is there a > >> rationale somewhere? > >> > >> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. > >> > > > > A few points. > > > > 1. It doesn't pull it in. There's no reference and there's just an > > informative statement. > > > > Shouldn't there be an informative reference? I think that's largely a question for the sponsoring AD (CC'd) and the RFC Editor. > > > 2. There is a rationale. In fact, the relevant text pretty much is all > > rationale. > > > > All Implementations MUST support DTLS 1.2 with the > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 > > curve [FIPS186 ]. Earlier drafts of this specification required DTLS > > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > > at the time of this writing some implementations do not support DTLS > > 1.2; endpoints which support only DTLS 1.2 might encounter > > interoperability issues. > > > > > Yes, I read this section and I was wondering what the rationale was for the > text: "endpoints which support only DTLS 1.2 might encounter > interoperability issues." Is there some data behind this? I'm not > suggesting a change in the draft without more information, but I do wonder > how the WG came to agree on this text. My assumption (I was not following the work) is that it was a well-known fact among implementors at the time that some large implementations only implemented DTLS 1.0. Accordingly, "might encounter interoperability issues" is a bland uncontroversial fact, in that context. It's not clear to me that we are adding much value revisiting the rtcweb WG's decisions over here on the TLS WG without getting input from rtcweb about why they put it that way in the first place... -Ben From nobody Sun Oct 6 11:26:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB88B12080C for ; Sun, 6 Oct 2019 11:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 OaQr9e1iDWDL for ; Sun, 6 Oct 2019 11:25:58 -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 D092F12081B for ; Sun, 6 Oct 2019 11:25:57 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id 72so7684922lfh.6 for ; Sun, 06 Oct 2019 11:25:57 -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=p0+LDL3ESB/xh9tA098MmhB6lE+DimAcDaCMg9LHLnE=; b=BakB9DxIqa+d9s2c0UarZXipVGUztWmAPV3URBCReCfdV5gqP2koP4cRZ9rC9NCBvO QytPYEByBncnowN04qUyzoHP4PDrY1BtxfqPZ4z06x6aWPuM08+1JKgi/tyKxS9avyXZ LgMM07HGpBsiv4/0UnmHmWpSlv1beBIWcHzKmDNHPgxSEm0ql2lQlc3T+8XOYmhiG2n/ yAh4D3lsQG7HwCsgg4sD2LfiARmXGR0Gmy8j0JDh9WutCA8Hg1Dld2tbl97/WgWQ4oFw ARvqVlvQ/M25gPQcFb68CZWLdKydVcn3SoZ6yisltt2JLf7kiSjOnxzVPIqKxzrJvZHd 6gkw== 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=p0+LDL3ESB/xh9tA098MmhB6lE+DimAcDaCMg9LHLnE=; b=fDgip+4S7Ut6ZzCG7LxoVoMvPQ6KZsXuctZVrFU0TBPdnOYQJvbkTCxwwVW0MRexBF OSkzPA2GcCWI4t/OgAHuKhCTjsUh+pFYn0TqopviJ2tgNVjsCkeUAfio4GdnCIYTpCfZ n4SFwmO+H1V1jhI30SQAs9DcdX1LV4pTEy35qt7+dDQGRXArFk50R+FZPQSAkHmFEy8v 5CvYllax4PQFvihvpeNtqnPj53G7kkdIOBnBkAXrVqjX3dubzvd1klV9eiqe5HGTTJLj rAWBvjBgSOtEZMTvVzU74ajcVMq0swKfR9t0mzYkWWWxIoOAyOnRU+cvi3r/KGS/BgK7 UWfw== X-Gm-Message-State: APjAAAWpu0SQUC5RYPDrlAHZigIxwQQmjjyDNipp+GXXVqOFjlOA9Vef G42OkBb4h49XTQShU+p2qOrIlqhPASY4VR0Kyv4Iog== X-Google-Smtp-Source: APXvYqxg1zKm0SqIEnbfLIbDC6sHPVv59s0tsLt6YmriUVXI53uIap4W9pkrykhz2KBN7ukdmxJZ6Gp5Kt4id/1lUuw= X-Received: by 2002:ac2:44a3:: with SMTP id c3mr13325801lfm.17.1570386356113; Sun, 06 Oct 2019 11:25:56 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Eric Rescorla Date: Sun, 6 Oct 2019 11:25:19 -0700 Message-ID: To: Rob Sayre Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000eaa648059442106e" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Sun, 06 Oct 2019 18:26:04 -0000 --000000000000eaa648059442106e Content-Type: text/plain; charset="UTF-8" On Fri, Oct 4, 2019 at 7:58 AM Rob Sayre wrote: > > > On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla wrote: > >> >> >> On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote: >> >>> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote: >>> >>>> >>>> I do not think you have consensus for that change to WebRTC - it was >>>> discussed extensively. ... >>>> >>> >>> While that may be true, readers of this list might want to read a >>> rationale, rather than just the results of a negotiation. Is there a >>> rationale somewhere? >>> >>> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. >>> >> >> A few points. >> >> 1. It doesn't pull it in. There's no reference and there's just an >> informative statement. >> > > Shouldn't there be an informative reference? > To what? Basically, what we had was the personal representations of WG members that they had products or were aware of products that used DTLS 1.0 only. > >> 2. There is a rationale. In fact, the relevant text pretty much is all >> rationale. >> >> All Implementations MUST support DTLS 1.2 with the >> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 >> curve [FIPS186 ]. Earlier drafts of this specification required DTLS >> 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and >> at the time of this writing some implementations do not support DTLS >> 1.2; endpoints which support only DTLS 1.2 might encounter >> interoperability issues. >> >> > Yes, I read this section and I was wondering what the rationale was for > the text: "endpoints which support only DTLS 1.2 might encounter > interoperability issues." Is there some data behind this? I'm not > suggesting a change in the draft without more information, but I do wonder > how the WG came to agree on this text. > See above. -Ekr > thanks, > Rob > > --000000000000eaa648059442106e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 4, 2019 at 7:58 AM Rob Sa= yre <sayrer@gmail.com> wrote:=


On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla <ekr@rtfm.com> wrote:<= br>


On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre <sayrer@gmail.com> wro= te:
On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <fluffy@iii.ca> wrot= e:

I do not think you have consensus for that change to WebRTC - it was discus= sed extensively. ...

=C2=A0While that m= ay be true, readers of this list might want to read a rationale, rather tha= n just the results of a negotiation. Is there a rationale somewhere?
<= div>
It seems strange to put DTLS 1.0 (based on TLS 1.1) into= new documents.

A few poi= nts.

1. It doesn't pull = it in. There's no reference and there's just an informative stateme= nt.

Shouldn't there b= e an informative reference?

To what? Basically, what we had was the personal representations of WG m= embers that they had products or were aware of products that used DTLS 1.0 = only.

=C2=A0
2. There is a rationale. In fact, the = relevant text pretty much is all rationale.
   All Implementatio=
ns MUST support DTLS 1.2 with the
   TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256
   curve [FIPS186].  Earlier drafts of this specification req=
uired DTLS
   1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and
   at the time of this writing some implementations do not support DTLS
   1.2; endpoints which support only DTLS 1.2 might encounter
   interoperability issues.

Yes, I read this section and I was wondering what the = rationale was for the text: "endpoints which support only DTLS 1.2 mig= ht encounter interoperability issues." Is there some data behind this?= I'm not suggesting a change in the draft without more information, but= I do wonder how the WG came to agree on this text.

See above.

-Ekr


thanks,
Rob

--000000000000eaa648059442106e-- From nobody Sun Oct 6 11:27:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B458A120074 for ; Sun, 6 Oct 2019 11:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 S52fsXyBZjgj for ; Sun, 6 Oct 2019 11:27:42 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 D8FA1120048 for ; Sun, 6 Oct 2019 11:27:41 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id u3so7666902lfl.10 for ; Sun, 06 Oct 2019 11:27:41 -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=a+QAMxMopmJi+OKppZ7b0WFyxfqmShZWnzf8TWTrcVY=; b=Lz1BsxaID12KjnenYR0R9N2+GqamBWMrqg3GHxitDAPmp4e1pRQ3qf00pGKwTOELU8 q6vqsR/WfEiUVXQYio0JvJXr22EgL9UWVnrRYwd49zgKLC7H55oILSLFCehyWK6fqdtc Fhak2oT9DfmKdvCf3e4yHvE0C2kgQ8aGv13FvTHXbubk1MmAsDomM/h04msglPkPBp4j BWislSImbWh/57qn6KEnc50XItHvMqlGUv6raRD653ZI3LnJekLwB24c3KsnSKqp/e8L DI/zuIGNL8zjhcABpBzpH0rNFAhFKbL5tS6RAkFGT3S0v2Jak+lhxzZiInu0+7WD7n29 splw== 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=a+QAMxMopmJi+OKppZ7b0WFyxfqmShZWnzf8TWTrcVY=; b=qRUEfdleliNJ7J+G4glFFHqQ2GgNOLpsBEv7ZM5cb+SbO5jXK59RJbRHQ7A9ZB2Dll 2RMyhI279x/tMnazSw+V8EkFzCSzEImQtqIfxf6k6C53enZzkyD4v3UKlMcv38MFeuni 3BVhiznxCkBnZccKkqcOxqblipvZm25wSN8e0wzft0RCqW1b2p9pS47oD1ylmcrjexbl KWP7JEtx3l5HNgatnJeoZyHN+Jbh+UShlRuzZnhYSXraEtdCsZUhlzb8wYVbIBdQ/+2N B9P5dDAnj+S0mKEpmfY2MQ2KWTfTbUVxOPO99QwTz6qgEay6u6ebjh4n921OW6ngvpzS kysA== X-Gm-Message-State: APjAAAVw200forSRJ1z9bfpLZrZpdssmCG4qlK6PnEHQt+0bv1jLwsOA UjLy7KJtdNkWL+9ppnOlwB67Koup64WJX9vp0zbkhg== X-Google-Smtp-Source: APXvYqxGPWuVhuUyX962ipAB/4AfebRr22JBpLKXDtGOO4o1MIzxlGPfDojyGLyl5cnQculXotA5ec29lNkWUuU6QxI= X-Received: by 2002:a19:6a09:: with SMTP id u9mr6155868lfu.91.1570386460215; Sun, 06 Oct 2019 11:27:40 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <20191006164205.GW6722@kduck.mit.edu> In-Reply-To: <20191006164205.GW6722@kduck.mit.edu> From: Eric Rescorla Date: Sun, 6 Oct 2019 11:27:03 -0700 Message-ID: To: Benjamin Kaduk Cc: Rob Sayre , Cullen Jennings , "tls@ietf.org" , "tls-chairs@ietf.org" , John Mattsson , draft-ietf-rtcweb-security-arch.ad@ietf.org Content-Type: multipart/alternative; boundary="0000000000001f23da05944217e4" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Sun, 06 Oct 2019 18:27:45 -0000 --0000000000001f23da05944217e4 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 6, 2019 at 9:42 AM Benjamin Kaduk wrote: > On Fri, Oct 04, 2019 at 09:57:53PM +0700, Rob Sayre wrote: > > On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla wrote: > > > > > > > > > > > On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre wrote: > > > > > >> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings wrote: > > >> > > >>> > > >>> I do not think you have consensus for that change to WebRTC - it was > > >>> discussed extensively. ... > > >>> > > >> > > >> While that may be true, readers of this list might want to read a > > >> rationale, rather than just the results of a negotiation. Is there a > > >> rationale somewhere? > > >> > > >> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new > documents. > > >> > > > > > > A few points. > > > > > > 1. It doesn't pull it in. There's no reference and there's just an > > > informative statement. > > > > > > > Shouldn't there be an informative reference? > > I think that's largely a question for the sponsoring AD (CC'd) and the RFC > Editor. > > > > > > 2. There is a rationale. In fact, the relevant text pretty much is all > > > rationale. > > > > > > All Implementations MUST support DTLS 1.2 with the > > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 > > > curve [FIPS186 < > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20#ref-FIPS186>]. > Earlier drafts of this specification required DTLS > > > 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and > > > at the time of this writing some implementations do not support DTLS > > > 1.2; endpoints which support only DTLS 1.2 might encounter > > > interoperability issues. > > > > > > > > Yes, I read this section and I was wondering what the rationale was for > the > > text: "endpoints which support only DTLS 1.2 might encounter > > interoperability issues." Is there some data behind this? I'm not > > suggesting a change in the draft without more information, but I do > wonder > > how the WG came to agree on this text. > > My assumption (I was not following the work) is that it was a well-known > fact among implementors at the time that some large implementations only > implemented DTLS 1.0. Yes, though I don't have data on it. Accordingly, "might encounter interoperability > issues" is a bland uncontroversial fact, in that context. It's not clear > to me that we are adding much value revisiting the rtcweb WG's decisions > over here on the TLS WG without getting input from rtcweb about why they > put it that way in the first place... > Fortunately, the WGs share a chair, so perhaps that chair could provide the minutes, etc. :) -Ekr > -Ben > --0000000000001f23da05944217e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 6, 2019 at 9:42 AM Benjam= in Kaduk <kaduk@mit.edu> wrote:<= br>
On Fri, Oct 04, = 2019 at 09:57:53PM +0700, Rob Sayre wrote:
> On Fri, Oct 4, 2019 at 9:48 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
> >
> >
> > On Fri, Oct 4, 2019 at 7:43 AM Rob Sayre <sayrer@gmail.com> wrote:
> >
> >> On Fri, Oct 4, 2019 at 9:08 PM Cullen Jennings <fluffy@iii.ca> wrote:
> >>
> >>>
> >>> I do not think you have consensus for that change to WebR= TC - it was
> >>> discussed extensively. ...
> >>>
> >>
> >>=C2=A0 While that may be true, readers of this list might want= to read a
> >> rationale, rather than just the results of a negotiation. Is = there a
> >> rationale somewhere?
> >>
> >> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new = documents.
> >>
> >
> > A few points.
> >
> > 1. It doesn't pull it in. There's no reference and there&= #39;s just an
> > informative statement.
> >
>
> Shouldn't there be an informative reference?

I think that's largely a question for the sponsoring AD (CC'd) and = the RFC
Editor.

>
> > 2. There is a rationale. In fact, the relevant text pretty much i= s all
> > rationale.
> >
> >=C2=A0 =C2=A0 All Implementations MUST support DTLS 1.2 with the > >=C2=A0 =C2=A0 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite= and the P-256
> >=C2=A0 =C2=A0 curve [FIPS186 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch= -20#ref-FIPS186>].=C2=A0 Earlier drafts of this specification requir= ed DTLS
> >=C2=A0 =C2=A0 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_1= 28_CBC_SHA, and
> >=C2=A0 =C2=A0 at the time of this writing some implementations do = not support DTLS
> >=C2=A0 =C2=A0 1.2; endpoints which support only DTLS 1.2 might enc= ounter
> >=C2=A0 =C2=A0 interoperability issues.
> >
> >
> Yes, I read this section and I was wondering what the rationale was fo= r the
> text: "endpoints which support only DTLS 1.2 might encounter
> interoperability issues." Is there some data behind this? I'm= not
> suggesting a change in the draft without more information, but I do wo= nder
> how the WG came to agree on this text.

My assumption (I was not following the work) is that it was a well-known fact among implementors at the time that some large implementations only implemented DTLS 1.0.=C2=A0

Yes, though I = don't have data on it.


Accordingly, "might encounter in= teroperability
issues" is a bland uncontroversial fact, in that context.=C2=A0 It'= ;s not clear
to me that we are adding much value revisiting the rtcweb WG's decision= s
over here on the TLS WG without getting input from rtcweb about why they put it that way in the first place...

F= ortunately, the WGs share a chair, so perhaps that chair could provide the = minutes, etc. :)

-Ekr


-Ben
--0000000000001f23da05944217e4-- From nobody Sun Oct 6 20:30:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE3E12002F; Sun, 6 Oct 2019 20:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 GbPmpKl3YV_y; Sun, 6 Oct 2019 20:30:53 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 1E54112000F; Sun, 6 Oct 2019 20:30:53 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id z19so25576075ior.0; Sun, 06 Oct 2019 20:30:53 -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=gZHaxPQbtOOMoNhUOOAy8keZo5kZviyZNPQdQj54BM4=; b=EXBLac9srCle+7pX+lJh/u/RU5vC9dBtIzulDfhcr1pQQb3CmW351zcfA+cSwgTVOS x7VD7fW7u6GSdHN338WjQrWTTZaAnOAayeciw4FAaXOuY2EVz56+3NFooigr6YX52o5c f3HXL0keoHtNRvifSbIZXLoP85Cuk/Le34TiM4Za3a6TJhk4DYeLuFPcxlW7cF3y8JS4 ikGqwYA7txgW4I7qLdwZ+xPfzAplGi5FLYgouVfdyS98bKwpqfm5CU80o8tyhRznk4MR uTA31lx8n+Rtkc2GCziPT2Q8/+L7bvWp6KuOnbJGCs9IFV2cQJtn6zeloapLeX8+qdTM XV7Q== 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=gZHaxPQbtOOMoNhUOOAy8keZo5kZviyZNPQdQj54BM4=; b=JNE5Oumlx93XYRPVHfkfRkWG6ZMamMsr6Q6WG2Zhl0zJiNAHtWknyPakZprcjEInMw RnL4HY0XyK1tbFCMTWzUqWjvbJVwf6Qw23Lg65ufqr/EX3ZqsFYb+ZigV4USWx6EOgX3 9A1LDdGzkElowK/hpY85bRy3PcobP7LZoC8XdXtqv/XA8b2tfoZPHnLfUCm9VcoKjSvm NoYz15/NR7pdBjpRH+Y/qJjVCbjPrL2TCfklgJjS+Quo0gjDbYqJFo1eNofJSwcYLluf dZ6hMOAVvPEDneHj01w618u0wNLOwWaqOFn8Zd5fHZWLzFotv14ccRIXfhkbXw3Gppd7 ARdA== X-Gm-Message-State: APjAAAVMojubSPfE6RiskM2Tv++dGxXMJ4NNGSsVjwrKRmZbegZL/SEk QLpNCdWPSsZpmskUFnk5FHsUmMXFC4BkaZz0ilg= X-Google-Smtp-Source: APXvYqyOLHhUbZcwy0XWpMsV/yVUHd9n+fp/jwmibiVpzyBiog5GNPd9OwtyDVZpB4pNpQsHOoR6xkiqHbjhT9NGI2I= X-Received: by 2002:a92:ca8e:: with SMTP id t14mr27607801ilo.73.1570419052251; Sun, 06 Oct 2019 20:30:52 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <20191006164205.GW6722@kduck.mit.edu> In-Reply-To: <20191006164205.GW6722@kduck.mit.edu> From: Rob Sayre Date: Mon, 7 Oct 2019 10:30:38 +0700 Message-ID: To: Benjamin Kaduk Cc: Eric Rescorla , Cullen Jennings , "tls@ietf.org" , "tls-chairs@ietf.org" , John Mattsson , draft-ietf-rtcweb-security-arch.ad@ietf.org Content-Type: multipart/alternative; boundary="000000000000c210b6059449ad52" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Mon, 07 Oct 2019 03:30:55 -0000 --000000000000c210b6059449ad52 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 6, 2019 at 11:42 PM Benjamin Kaduk wrote: > > > > Shouldn't there be an informative reference? > > I think that's largely a question for the sponsoring AD (CC'd) and the RFC > Editor. > Well, I hope we can all agree that the document refers to an RFC without a citation in the references section. > > My assumption (I was not following the work) is that it was a well-known > fact among implementors at the time that some large implementations only > implemented DTLS 1.0. Accordingly, "might encounter interoperability > issues" is a bland uncontroversial fact, in that context. > That was definitely the case in November 2018, when the text was added: https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-rtcweb-security-arch-17.txt Chrome tried and failed to remove DTLS 1.0 in April 2019: https://bugs.chromium.org/p/webrtc/issues/detail?id=10261#c38 But now all major browsers are removing TLS 1.0 and 1.1 support in January of 2020: https://groups.google.com/forum/#!searchin/discuss-webrtc/dtls$201.0%7Csort:date/discuss-webrtc/Dsq_14_WoUk/U2vFXSYlCgAJ https://security.googleblog.com/2018/10/modernizing-transport-security.html So, it seems like endpoints that don't support DTLS 1.2 will soon be the ones "encountering interoperability issues". Not sure whether a change to draft-ietf-rtcweb-security-arch or an update in draft-ietf-tls-oldversions-deprecate is better. thanks, Rob --000000000000c210b6059449ad52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Oct 6, 2019 at 11:42 PM Benjamin = Kaduk <kaduk@mit.edu> wrote:
=
>
> Shouldn't there be an informative reference?

I think that's largely a question for the sponsoring AD (CC'd) and = the RFC
Editor.

Well, I hope we can all agree t= hat the document refers to an RFC without a citation in the references sect= ion.=C2=A0
=C2=A0

My assumption (I was not following the work) is that it was a well-known fact among implementors at the time that some large implementations only implemented DTLS 1.0.=C2=A0 Accordingly, "might encounter interoperabi= lity
issues" is a bland uncontroversial fact, in that context.=C2=A0

That was definitely the case in November 2018= , when the text was added:

Chrome tried and= failed to remove DTLS 1.0 in April 2019:

= But now all major browsers are removing TLS 1.0 and 1.1 support in January = of 2020:

So, it seems like endpoints that do= n't support DTLS 1.2 will soon be the ones "encountering interoper= ability issues".

Not sure whether a change to= draft-ietf-rtcweb-security-arch or an update in=C2=A0draft-ietf-tls-oldver= sions-deprecate is better.

thanks,
Rob
--000000000000c210b6059449ad52-- From nobody Mon Oct 7 07:28:47 2019 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 BBF6B1208A2; Mon, 7 Oct 2019 07:28:40 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157045852074.4673.1204603034644719579@ietfa.amsl.com> Date: Mon, 07 Oct 2019 07:28:40 -0700 Archived-At: Subject: [TLS] IPR Disclosure Certicom Corp's Statement about IPR related to RFC 4492 and RFC 8422 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: Mon, 07 Oct 2019 14:28:41 -0000 Dear Bodo Moeller, Nelson Bolyard, Vipul Gupta, Simon Blake-Wilson, Chris Hawk: An IPR disclosure that pertains to your RFC entitled "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)" (RFC4492) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3800/). The title of the IPR disclosure is "Certicom Corp's Statement about IPR related to RFC 4492 and RFC 8422" Thank you IETF Secretariat From nobody Mon Oct 7 07:29:02 2019 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 D12771208A6; Mon, 7 Oct 2019 07:28:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IETF Secretariat To: Cc: tls@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157045852082.4673.6823256528221172065@ietfa.amsl.com> Date: Mon, 07 Oct 2019 07:28:40 -0700 Archived-At: Subject: [TLS] IPR Disclosure Certicom Corp's Statement about IPR related to RFC 4492 and RFC 8422 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: Mon, 07 Oct 2019 14:28:41 -0000 Dear Yoav Nir, Simon Josefsson, Manuel Pégourié-Gonnard: An IPR disclosure that pertains to your RFC entitled "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier" (RFC8422) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3800/). The title of the IPR disclosure is "Certicom Corp's Statement about IPR related to RFC 4492 and RFC 8422" Thank you IETF Secretariat From nobody Mon Oct 7 07:46:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEDF1200C7 for ; Mon, 7 Oct 2019 07:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 fHTVu5tTrwn8 for ; Mon, 7 Oct 2019 07:45:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C00112010E for ; Mon, 7 Oct 2019 07:45:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DC100883859; Mon, 7 Oct 2019 14:45:43 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 259C9544E6; Mon, 7 Oct 2019 14:45:42 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 07 Oct 2019 16:45:42 +0200 Message-ID: <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1660136.O7gKnjuQ9x"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.69]); Mon, 07 Oct 2019 14:45:44 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2019 14:46:03 -0000 --nextPart1660136.O7gKnjuQ9x Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote: > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote: > > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > > I understand the meaning of count is the higher limit of ticket a= nd > > > > > the > > > > > server can provides any tickets between 0 and count. If that is > > > > > correct, > > > > > this could be clearly stated and indication to chose an appropria= ted > > > >=20 > > > > value > > > >=20 > > > > > for each cases may be provided. > > > > >=20 > > > > > I would rather see the count value as a hard line from the server > > > > > with a > > > > > MUST NOT instead of a SHOULD NOT statement. > > > >=20 > > > > see my previous comments: this ignores existence of post handshake > > > > authentication, ticket lifetimes and KeyUpdate > > >=20 > > > I think we agree on the problem which is it is hard to have a specific > > > count as tickets may be sent at multiple time during the key exchange= or > > > the later during the session. If the "SHOULD" is addressing this aspe= ct > > > I > > > believe that more text is needed.. From my perspective, what I propos= ed > > > I > > > imagined that count was related to the maximum number of ticket provi= ded > > > **each time the server is sending tickets**. The reason for having the > > > same > > > number is that the server does not know how the client will use these > > > tickets and the client does not know precisely when the server sends = the > > > tickets. So at the end the number of tickets sent is likely to be > > > n*count > > > when n represents the number of times during the session tickets are > > > provided. > > >=20 > > > My understanding of the SHOULD is that it makes legitimate for a serv= er > > > to > > > ignore the count value provided by the client. > >=20 > > yes, it looks like we are in agreement > >=20 > > Sounds like something that should be spelled out explicitly in the draf= t. > > I.e. it should talk about groups of tickets, not tickets in connection, > > and it should definitely not specify the maximum number of tickets a > > server can send in a connection. >=20 > Since it's meant as a hint, removing that clause (maximum number of ticke= ts > a server can send in a connection) is reasonable, and sounds like it shou= ld > address the concerns here. (Assuming we also include text which says > servers should obviously place a cap on what they send, as they do today.) > Would you agree? I'm really trying to avoid this becoming overly complex, > as it's a very small feature. yes, having a "server SHOULD place a cap on the number of tickets it sends = at=20 once" with a note in security section that "not having such a limit may exp= ose=20 the server to DoS or amplification attacks" would be enough (note that without client certificate authentication, the server can use ea= rly=20 exit from handshake method and thus send the extensions just as a result of= a=20 single ClientHello message) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1660136.O7gKnjuQ9x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2bT5YACgkQkqjRuAHS 9fUG4BAAkZhOIFdD0o9xX6RJ4F6Tk5iH/U0U29VdPiX+0zzMzWuEjHG2c9c5BhHf 8ulUECeoUfjUa6DFtOzwBRddtI/pwPSDRTzbX4lb5eql0MMD6iG5bEuHEQNcTeuF 17fUpBc0K313bo0xuQG080zQxtoQaUCIMpH/Ep4EP9SaqyLXfSrLyfgb6X7o+4A2 uBm/EOLSFVNbraPaVv1KDgSkk+xysr6zMkB3ilWjk0dz3J2pIUOlreo7t1EF1Rog hmEPfHtU1lYGjqlplgrxgwVKWFr0Qo3R9jD2hMxJxuQgny7GlznlYSas/k3UW6// fBpWLFYq6fbAPBiPkv0vGRrtBlG3bdbXqfpYeEc8DMLDToomZbi9Gz/CdUMLuWoM oIL1VHjst/tArGOz2e9BDtggb9A6k1m3MNTbUMIqbor43kcXFmPVwvjnVHhZH5yU SMZkFK7zWA/mS3EoXBqtPaPXr34YsnD930PiuOkVHrXXhBeM+b8oSGNge73waOnW E/VpfsQXxeR4HJ9uqPzkU1gFG212q9Qw/d+l8jGG9EJ5xawYOBZdLAWLc9hIOhwk N1AHQ/hmItFb6DoXm6h4KH9Z7jLMofgpHJwne841aBNAIGQA5ZRdGTdKMAdi0HDc QzswSxUwBIt6cvGN693yUNaPDH52ARzOZwFQdgtE8+aokYupfVY= =anij -----END PGP SIGNATURE----- --nextPart1660136.O7gKnjuQ9x-- From nobody Mon Oct 7 10:29:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97A012087C; Mon, 7 Oct 2019 10:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 fYiJTBqrBoSF; Mon, 7 Oct 2019 10:29:45 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 562FA12088E; Mon, 7 Oct 2019 10:29:42 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id c25so30330372iot.12; Mon, 07 Oct 2019 10:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S4W5wx4y52t4Rr23iNL4Dt6d6Uwbb5mETE9c222oruY=; b=bsrvGuB6oQAoxkXzuouUvZ+fHYVuJ26pkAzW6fKGVbDyaFnl+zZjhjf/0ekuFEX7so zhrDeNfOAsuUiHhFkccT6GFJ+7j2DuYSk9vOqDhbf0WdhIdqCZmv+SV8ZS5cZNqaCnch QaQCNx/e4syn/UJhZM5XvuThDilg+x6uqUhBDJ0LHwSTiv69Wz8DWdTFAdkcc0qC60s8 PCLoKtZUeVjd/UWZ2EnMK72/+9vh7wN/kLuYQCNMZ8jb7H85DNsxai/zGJ65oMj21KNV o9lS26ZAnTziQs3Q9/7r6Ql48ildmbMJay9YeQgXVdqGNMgRo2Q8cAEP2zZWvuLXgwrQ G0PA== 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=S4W5wx4y52t4Rr23iNL4Dt6d6Uwbb5mETE9c222oruY=; b=fsQauwXyZUSGtGnc2DNFNfnNyJMrKp1iPamh16wwOXr2+aRJqfxZhZw4orKgilmnz8 YJBxre5HAbeJ0LJoT7yzm26WM0Gwta59UskajjcQz5sirCwl9VX7yiaUsL89pacfLKbc KVrECFHyfblkPgFTDOk/fxZTrJqeQeA2ClH2Sm7jule6FSctFVpA/cjQn+jbAv0GTrde 4rNC9aru8K6FbYM31sZ4aDI5HZN8y3JzEuXUCPXpAJjaUU/h5SA8//pPmlk9aqJkhBNl hh5dsr2aw3UfxKaS7pGtgp+RFk3xWnz0zQex6QLaQ/g/UQ+J3rEKK5tbZSHYBqYeSCqt SJWQ== X-Gm-Message-State: APjAAAV45Pwgae1Sx1XVy1VgB14O6Pjs30Gd1G5rTlmKjAdJsLzMJZIe 6TmtRiIDdy0CN9xo4UfqDf72Ep3FwNiyvVvtWjE= X-Google-Smtp-Source: APXvYqyH8Om21uXWamrfVvZ04/xQZMttEAd1xO8wS3fdDGV7bpxuhPwc42YPyipEUMlVK/TgWXKSnshgtQIIEZlkcac= X-Received: by 2002:a5e:8902:: with SMTP id k2mr7758158ioj.49.1570469381423; Mon, 07 Oct 2019 10:29:41 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Rob Sayre Date: Tue, 8 Oct 2019 00:29:29 +0700 Message-ID: To: Eric Rescorla Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000009c49b50594556594" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Mon, 07 Oct 2019 17:29:47 -0000 --0000000000009c49b50594556594 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla wrote: > >>>> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. >>>> >>> >>> A few points. >>> >>> 1. It doesn't pull it in. There's no reference and there's just an >>> informative statement. >>> >> >> Shouldn't there be an informative reference? >> > > To what? > Hi, I missed this response. This discussion seems a bit tedious, but 1) it doesn't seem like a particularly valid claim to say that the document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a missing reference. 2) if "DTLS 1.0" remains in the document, I /think/ the document should cite RFC 4347, and maybe the updates to it. But, perhaps there's a chain of unstated dependencies in these documents, and I've only noticed the latest one. This thread also has some other unusual claims: On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell wrote: > we can't "UPDATE" an I-D. Not true. If you need to refer to something that's been IESG-approved but still in the RFC queue, you can leave a note for the RFC editor to update the reference to the eventual RFC number. On Wed, Oct 2, 2019 at 8:17 PM Sean Turner wrote: > You can change the text, but I do not believe it will change the implementations. If true, changing the text would seem to be uncontroversial. Anyway, leaving strange text like this DTLS 1.0 stuff in the webrtc document is one thing (although I'm surprised the IESG allowed it). Claiming that a document like draft-ietf-tls-oldversions-deprecate can't update documents from a concluded WG is another. If the IETF can't get consensus on actually deprecating DTLS 1.0, maybe something similar to the text from draft-ietf-rtcweb-security-arch should be added to draft-ietf-tls-oldversions-deprecate. "Earlier specifications required DTLS 1.0. Endpoints which support only DTLS 1.2 might encounter interoperability issues." That would seem to subvert the point of the draft--I think this is the point that the original post in this thread was making. thanks, Rob --0000000000009c49b50594556594 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 7, 2019 at 1:25 AM Eric Resco= rla <ekr@rtfm.com&= gt; wrote:
=

<= /div>
It seems strange to put DTLS 1.0 (based on TLS 1.1) into new docu= ments.

A few points.

1. It doesn't pull it in. Th= ere's no reference and there's just an informative statement.
=

Shouldn't there be an info= rmative reference?

To wha= t?

Hi, I missed this resp= onse. This discussion seems a bit tedious, but

1) = it doesn't seem like a particularly valid claim to say that the documen= t "doesn't pull" in DTLS 1.0 when the rationale for that clai= m is a missing reference.
2) if "DTLS 1.0" remains in t= he document, I /think/ the document should cite RFC 4347, and maybe the upd= ates to it. But, perhaps there's a chain of unstated dependencies in th= ese documents, and I've only noticed the latest one.

This thread also has some other unusual claims:

=
On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> = we can't "UPDATE" an I-D.

Not tr= ue. If you need to refer to something that's been IESG-approved but sti= ll in the RFC queue, you can leave a note for the RFC editor to update the = reference to the eventual RFC number.

On Wed, Oct = 2, 2019 at 8:17 PM Sean Turner <sean@s= n3rd.com> wrote:
> You can change the text, but I do no= t believe it will change the implementations.

= If true, changing the text would seem to be uncontroversial.

=
Anyway, leaving strange text like this DTLS 1.0 stuff in the web= rtc document is one thing (although I'm surprised the IESG allowed it).= Claiming that a document like draft-ietf-tls-oldversions-deprecate can'= ;t update documents from a concluded WG is another.

If the IETF can't get consensus on actually deprecating DTLS 1.0, may= be something similar to the text from=C2=A0draft-ietf-rtcweb-security-arch = should be added to draft-ietf-tls-oldversions-deprecate.

"Earlier specifications required DTLS 1.0. Endpoints which supp= ort only DTLS 1.2 might encounter interoperability issues."
=
That would seem to subvert the point of the draft--I think t= his is the point that the original post in this thread was making.

thanks,
Rob
--0000000000009c49b50594556594-- From nobody Mon Oct 7 12:07:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A849120154; Mon, 7 Oct 2019 12:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 wbuw1_q0IGE4; Mon, 7 Oct 2019 12:07:27 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 3291F1200F5; Mon, 7 Oct 2019 12:07:27 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x97J7K4P004002; Mon, 7 Oct 2019 15:07:20 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x97J7K4P004002 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1570475240; bh=EWXqde1C+6NBJfi+w/fD7EP50MUe0t2Bc2kvealK/Kw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=HZChp5wh/h+OD+Xr2xOl4AcvOi8aT3OH0ThheTNXD6roQwPYzWJ/yreAvRn/QnBW7 t+i2OL4aK90OJxLnisy9SgKibmtWi2ljB4xjAYdXsYf2lc/8n3PYNQu+NaHao/hK9W kDEg9NC5GOd2BVnuHBy2fgniG2te/SA2mUAbzNz0= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x97J7IJf025979; Mon, 7 Oct 2019 15:07:18 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0468.000; Mon, 7 Oct 2019 15:07:17 -0400 From: Roman Danyliw To: Christian Huitema , The IESG CC: "draft-ietf-tls-sni-encryption@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT) Thread-Index: AQHVbi8COnMhMIVEW0a3iVa1HwFkKKcyhpWAgADP/5CACcQaAIABZHnAgABh8YCAEMNMkA== Date: Mon, 7 Oct 2019 19:07:16 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B347B31A@marathon> References: <156881761812.4630.11745895149419124830.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon> <81e39835-82e7-03c7-feaf-33980629986c@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon> <2efdf56d-2846-a08e-2b2d-aa0703281b18@huitema.net> In-Reply-To: <2efdf56d-2846-a08e-2b2d-aa0703281b18@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B347B31Amarathon_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2019 19:07:37 -0000 --_000_359EC4B99E040048A7131E0F4E113AFC01B347B31Amarathon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuIQ0KDQpUaGFua3MgZm9yIGFsbCBvZiB0aGUgaXRlcmF0aW9uIGFuZCB1cGRh dGVzLiAgR2l2ZW4gd2hhdOKAmXMgcHJvcG9zZWQgaW4gZ2l0aHViIChodHRwczovL2dpdGh1Yi5j b20vdGxzd2cvc25pZW5jcnlwdGlvbi9wdWxsLzQ2L2ZpbGVzKSwgY29uc2lkZXIgbXkgY29tbWVu dHMgcmVzb2x2ZWQuICBNaW5vciBjb21tZW50cyBpbmxpbmUg4oCmDQoNCkZyb206IENocmlzdGlh biBIdWl0ZW1hIFttYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldF0NClNlbnQ6IFRodXJzZGF5LCBT ZXB0ZW1iZXIgMjYsIDIwMTkgNjo1MyBQTQ0KVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9y Zz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KQ2M6IGRyYWZ0LWlldGYtdGxzLXNuaS1lbmNy eXB0aW9uQGlldGYub3JnOyB0bHMtY2hhaXJzQGlldGYub3JnOyB0bHNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbVExTXSBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYt dGxzLXNuaS1lbmNyeXB0aW9uLTA1OiAod2l0aCBDT01NRU5UKQ0KDQoNCg0KT24gOS8yNi8yMDE5 IDExOjM4IEFNLCBSb21hbiBEYW55bGl3IHdyb3RlOg0KDQpIaSBDaHJpc3RpYW4hDQoNCg0KDQpU aGFua3MgZm9yIGFsbCBvZiB0aGUgdXBkYXRlcy4gIEkgaGF2ZSBhIHJlbWFpbmluZyBpdGVtcyBh cmUgZGVzY3JpYmVkIGlubGluZS4NCg0KDQoNClRvIGJyaW5nIHVwIGEgbmV3IGl0ZW0sIHRoZXJl IHdhcyBuZXcgdGV4dCBpbnRyb2R1Y2VkIGluIC0wNiBvZiBTZWN0aW9uIDUgdG8gd2hpY2ggSSBz dHJvbmdseSBvYmplY3QuICBTcGVjaWZpY2FsbHk6DQoNCg0KDQoiUmVwbGFjaW5nIGNsZWFyIHRl eHQgU05JIHRyYW5zbWlzc2lvbiBieSBhbiBlbmNyeXB0ZWQgdmFyaWFudCB3aWxsDQoNCmFsc28g dGh3YXJ0IE1JVE0gaW50ZXJmZXJlbmNlcyB0aGF0IGFyZSBzb21ldGltZXMgZGVzY3JpYmVkIGFz DQoNCmxlZ2l0aW1hdGUuICBBcyBleHBsYWluZWQgaW4gU2VjdGlvbiAyLjMsIGFsdGVybmF0aXZl IHNvbHV0aW9ucyB3aWxsDQoNCmhhdmUgdG8gYmUgZGV2ZWxvcGVkLuKAnQ0KDQoNCg0KSSByZWFk IHRoaXMgcGFyYWdyYXBoIGFzIGFkZHJlc3NpbmcgdGhlIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBv dXRsaW5lZCBpbiBTZWN0aW9uIDIuMS4gIEkgdGhpbmsgaXQgaXMgaW5hcHByb3ByaWF0ZSB0byBy ZWZlciB0byBzb21lIG9mIHRoZXNlIG9wZXJhdGlvbmFsIHByYWN0aWNlcyBhcyBiZWluZyAic29t ZXRpbWVzIGRlc2NyaWJlZCBhcyBsZWdpdGltYXRlIi4NCg0KQW55dGhpbmcgcGVyZm9ybWVkIGJ5 IE1JVE0gaXMgYnkgZGVmaW5pdGlvbiBjb250cm92ZXJzaWFsLiBCdXQgSSBnZXQgeW91ciBwb2lu dC4gSG93IGFib3V0DQoNCiJSZXBsYWNpbmcgY2xlYXIgdGV4dCBTTkkgdHJhbnNtaXNzaW9uIGJ5 IGFuIGVuY3J5cHRlZCB2YXJpYW50IHdpbGwgYnJlYWsgb3IgcmVkdWNlIHRoZQ0KDQplZmZpY2Fj eSBvZiB0aGUgb3BlcmF0aW9uYWwgcHJhY3RpY2VzIGFuZCB0ZWNobmlxdWVzIGltcGxlbWVudGVk IGluIG1pZGRsZS1ib3hlcyBhcw0KDQpkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEuIEFzIGV4cGxh aW5lZCBpbiBTZWN0aW9uIDIuMywgYWx0ZXJuYXRpdmUgc29sdXRpb25zIHdpbGwNCg0KaGF2ZSB0 byBiZSBkZXZlbG9wZWQuIg0KDQoNCg0KW1JvbWFuXSBMb29rcyBnb29kIHRvIG1lLiAgVGhhbmtz Lg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KRnJvbTogQ2hyaXN0aWFuIEh1 aXRlbWEgW21haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0XQ0KDQpTZW50OiBXZWRuZXNkYXksIFNl cHRlbWJlciAyNSwgMjAxOSAzOjQ3IFBNDQoNClRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5v cmc+PG1haWx0bzpyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz48bWFpbHRv Omllc2dAaWV0Zi5vcmc+DQoNCkNjOiBkcmFmdC1pZXRmLXRscy1zbmktZW5jcnlwdGlvbkBpZXRm Lm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi10bHMtc25pLWVuY3J5cHRpb25AaWV0Zi5vcmc+OyB0bHMt Y2hhaXJzQGlldGYub3JnPG1haWx0bzp0bHMtY2hhaXJzQGlldGYub3JnPjsgdGxzQGlldGYub3Jn PG1haWx0bzp0bHNAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbVExTXSBSb21hbiBEYW55bGl3 J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdGxzLXNuaS0NCg0KZW5jcnlwdGlvbi0wNTog KHdpdGggQ09NTUVOVCkNCg0KDQoNCkhlbGxvIFJvbWFuLA0KDQoNCg0KQSBsb3Qgb2YgdGhlIGZp eGVzIHRoYXQgeW91IHN1Z2dlc3RlZCBhcmUgaW5jb3Jwb3JhdGVkIGluIHRoZSBkcmFmdC0wNyB0 aGF0IHdhcw0KDQpqdXN0IHJlbGVhc2VkLiBJIHRoaW5rIHRoZSBsYXN0IHZlcnNpb24gYWRkcmVz c2VzIHlvdXIgY29uY2VybnMsIGJ1dCB5b3UgbWF5DQoNCm9mIGNvdXJzZSB3YW50IHRvIHZlcmlm eS4NCg0KDQoNCk9uIDkvMjUvMjAxOSA3OjI3IEFNLCBSb21hbiBEYW55bGl3IHdyb3RlOg0KDQpI aSBDaHJpc3RpYW4hDQoNCg0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCByZXNwb25zZXMgYW5k IHRoZSBoZWxwZnVsIGJhY2tncm91bmQuICBCZWxvdyBhcmUgYQ0KDQpudW1iZXIgb2YgcHJvcG9z ZWQgdGV4dCBibG9jayByZXBsYWNlbWVudHMgdG8gY2xhcmlmeSBteSBpbnRlbnQgKGluc3RlYWQg b2YNCg0KbW9yZSBxdWVzdGlvbnMpLg0KDQoNCg0KUm9tYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQoNCkZyb206IGllc2cgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4NCg0KSHVpdGVtYQ0KDQpTZW50OiBXZWRuZXNkYXksIFNl cHRlbWJlciAxOCwgMjAxOSAxMDoxNCBQTQ0KDQpUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQu b3JnPjxtYWlsdG86cmRkQGNlcnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+PG1haWx0 bzppZXNnQGlldGYub3JnPg0KDQpDYzogZHJhZnQtaWV0Zi10bHMtc25pLWVuY3J5cHRpb25AaWV0 Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdGxzLXNuaS1lbmNyeXB0aW9uQGlldGYub3JnPjsgdGxz LWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86dGxzLWNoYWlyc0BpZXRmLm9yZz47DQoNCnRsc0BpZXRm Lm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSZTogW1RMU10gUm9tYW4gRGFu eWxpdydzIE5vIE9iamVjdGlvbiBvbg0KDQpkcmFmdC1pZXRmLXRscy1zbmktDQoNCmVuY3J5cHRp b24tMDU6ICh3aXRoIENPTU1FTlQpDQoNCg0KDQpUaGFua3MgZm9yIHRoZSBmZWVkYmFjaywgUm9t YW4uIENvbW1lbnRzIGluIGxpbmUuDQoNCg0KDQpPbiA5LzE4LzIwMTkgNDo0MCBBTSwgUm9tYW4g RGFueWxpdyB2aWEgRGF0YXRyYWNrZXIgd3JvdGU6DQoNCioqIFNlY3Rpb24gMS4gIFBlciDigJxN b3JlIGFuZCBtb3JlIHNlcnZpY2VzIGFyZSBjb2xvY2F0ZWQgb24NCg0KbXVsdGlwbGV4ZWQgc2Vy dmVycywgbG9vc2VuaW5nIHRoZSByZWxhdGlvbiBiZXR3ZWVuIElQIGFkZHJlc3MgYW5kDQoNCndl YiBzZXJ2aWNl4oCdLCBjb21wbGV0ZWx5IGFncmVlLiAgSU1PLCB1bnBhY2tpbmcg4oCcbXVsdGlw bGV4ZWQNCg0Kc2VydmVyc+KAnSBpcyB3b3J0aHdoaWxlIHRvIGV4cGxhaW4gdGhlIHN1YnNlcXVl bnQgdGV4dCBiZWNhdXNlIGl0DQoNCm1vdGl2YXRlcyB0aGUgbG9zcyBvZiB2aXNpYmlsaXR5IGR1 ZSB0byBlbmNyeXB0aW9uIHdpdGggbmV0d29yayBvbmx5DQoNCm1vbml0b3JpbmcuDQoNCuKAnE11 bHRpcGxleOKAmSBoYXBwZW5zIGF0IHR3byBsZXZlbHM6DQoNCi0tIGNvLXRlbmFudHMgKGUuZy4s IHZpcnR1YWwgaG9zdGluZykg4oCTIG11bHRpcGxlIHNlcnZpY2VzIG9uIHRoZQ0KDQpzYW1lIHNl cnZlciAoaS5lLiwgYW4gSVAvcG9ydCBkb2VzbuKAmXQgdW5pcXVlbHkgaWRlbnRpZnkgdGhlIHNl cnZpY2UpDQoNCg0KDQotLSBjbG91ZC9jZG4gIOKAkyBhIGdpdmVuIHBsYXRmb3JtIGhvc3RzIHRo ZSBzZXJ2aWNlcy9zZXJ2ZXJzIG9mIGEgbG90DQoNCm9mIG9yZ2FuaXphdGlvbiAoaS5lLiwgbG9v a2luZyB1cCB0byB3aGF0IG5ldGJsb2NrIGFuIElQIGJlbG9uZ3MNCg0KcmV2ZWFscyBsaXR0bGUp DQoNCg0KDQpPSywgd2lsbCB0cnkgdG8gaW5jb3Jwb3JhdGUgeW91ciB0ZXh0Lg0KDQpUaGFua3Mu DQoNCg0KDQpDaGFuZ2VzIGluY29ycG9yYXRlZCBpbiBmaXJzdCBwYXJhZ3JhcGggb2Ygc2VjdGlv biAxLg0KDQoNCg0KVGhlIHRleHQgLTA3IHdvcmtzIGZvciBtZS4gIFRoYW5rcyBmb3IgYWRkaW5n IHRoaXMgZXh0cmEgYml0Lg0KDQoNCg0KDQoNCioqIFNlY3Rpb24gMi4xLiAgUGVyIOKAnFRoZSBT Tkkgd2FzIGRlZmluZWQgdG8gZmFjaWxpdGF0ZSBtYW5hZ2VtZW50DQoNCm9mIHNlcnZlcnMsIHRo b3VnaCB0aGUgZGV2ZWxvcGVycyBvZiBtaWRkbGVib3hlcyBzb29uIGZvdW5kIG91dCB0aGF0DQoN CnRoZXkgY291bGQgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlIGluZm9ybWF0aW9uLiAgTWFueSBleGFt cGxlcyBvZiBzdWNoDQoNCnVzYWdlIGFyZSByZXZpZXdlZCBpbiBbUkZDODQwNF0u4oCdLA0KDQoN Cg0KLS0gQ2Fu4oCZdCBtaWRkbGVib3hlcyBhbHNvIGhlbHAgZmFjaWxpdGF0ZSB0aGUgbWFuYWdl bWVudCBvZiBzZXJ2ZXJzPw0KDQpUaGlzIHRleHQgc2VlbXMgdG8gdGFrZSBhIHBhcnRpY3VsYXIg dmlldyBvbiBtaWRkbGVib3hlcyB3aGljaA0KDQpkb2Vzbid0DQoNCnNlZW0gYXBwcm9wcmlhdGUu DQoNCg0KDQpJdCBpcyBwcmV0dHkgY2xlYXIgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBpbiBmcm9u dCBvZiBhIHNlcnZlciBmYXJtDQoNCndpbGwgbmVlZCBhY2Nlc3MgdG8gdGhlIHNlcnZpY2UgSUQs IGFuZCBtdXN0IGJlIGFibGUgdG8gcmV0cmlldmUgdGhlDQoNCmRlY3J5cHRlZCBTTkkuDQoNClRo ZXJlIG1heSBiZSBvdGhlciBleGFtcGxlcywgc3VjaCBhcyBEb1MgbWl0aWdhdGlvbiBib3hlcy4g VGhlDQoNCiJ1bmFudGljaXBhdGVkIHVzYWdlIiBjb21lcyB0eXBpY2FsbHkgZnJvbSBtaWRkbGUt Ym94ZXMgdGhhdCBhcmUgbm90DQoNCmluIHRoZSBzYW1lIG1hbmFnZW1lbnQgZG9tYWluIGFzIGVp dGhlciB0aGUgY2xpZW50IG9yIHRoZSBzZXJ2ZXIuIElzDQoNCnRoZXJlIGFuIGVzdGFibGlzaGVk IHdheSB0byBkZXNpZ25hdGUgdGhvc2U/DQoNCkknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhl IG9yaWdpbmFsIG9mIHRoZSByZXF1aXJlbWVudCB0aGF0IHRoZSBjbGllbnQNCg0KYW5kIHNlcnZl ciBiZWluZyBpbiB0aGUgc2FtZSBtYW5hZ2VtZW50IGRvbWFpbi4NCg0KDQoNClJGQzM1NDYncyBk ZWZpbml0aW9uIG9mIFNOSSBvcGVucyB3aXRoOg0KDQogICBbVExTXSBkb2VzIG5vdCBwcm92aWRl IGEgbWVjaGFuaXNtIGZvciBhIGNsaWVudCB0byB0ZWxsIGEgc2VydmVyIHRoZQ0KDQogICBuYW1l IG9mIHRoZSBzZXJ2ZXIgaXQgaXMgY29udGFjdGluZy4gIEl0IG1heSBiZSBkZXNpcmFibGUgZm9y IGNsaWVudHMNCg0KICAgdG8gcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uIHRvIGZhY2lsaXRhdGUg c2VjdXJlIGNvbm5lY3Rpb25zIHRvDQoNCiAgIHNlcnZlcnMgdGhhdCBob3N0IG11bHRpcGxlICd2 aXJ0dWFsJyBzZXJ2ZXJzIGF0IGEgc2luZ2xlIHVuZGVybHlpbmcNCg0KICAgbmV0d29yayBhZGRy ZXNzLg0KDQoNCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBpZiB3ZSBhcmUgdHJ5aW5nIHRvIGNoYW5u ZWwgb3JpZ2luYWwgaW50ZW50LCB0aGVuIG9ubHkgdGhlDQoNCnZpcnR1YWwgc2VydmVyIHVzZSBj YXNlIGFwcGxpZXMuICBJJ2QgcHJvcG9zZToNCg0KDQoNCk9MRA0KDQpUaGUgU05JIHdhcyBkZWZp bmVkIHRvIGZhY2lsaXRhdGUgbWFuYWdlbWVudCBvZiBzZXJ2ZXJzLCB0aG91Z2ggdGhlDQoNCmRl dmVsb3BlcnMgb2YgbWlkZGxlYm94ZXMgc29vbiBmb3VuZCBvdXQgdGhhdCB0aGV5IGNvdWxkIHRh a2UgYWR2YW50YWdlDQoNCm9mIHRoZSBpbmZvcm1hdGlvbi4gIE1hbnkgZXhhbXBsZXMgb2Ygc3Vj aCB1c2FnZSBhcmUgcmV2aWV3ZWQgaW4NCg0KW1JGQzg0MDRdLg0KDQoNCg0KTkVXDQoNClRoZSBT Tkkgd2FzIGRlZmluZWQgdG8gZmFjaWxpdGF0ZSBzZWN1cmUgY29ubmVjdGlvbnMgdG8gc2VydmVy cyB0aGF0IGhvc3QNCg0KbXVsdGlwbGUgJ3ZpcnR1YWwnIHNlcnZlcnMgYXQgYSBzaW5nbGUgdW5k ZXJseWluZyBuZXR3b3JrIGFkZHJlc3MgW1JGQzM1NDZdLg0KDQpIb3dldmVyLCBhZGRpdGlvbiBt YW5hZ2VtZW50IGFuZCBzZWN1cml0eSBwcmFjdGljZXMgZW1lcmdlZCBtYWtpbmcgdXNlDQoNCm9m IHRoaXMgaW5mb3JtYXRpb24uICBFeGFtcGxlcyBvZiBzdWNoIHVzYWdlIGFyZSByZXZpZXdlZCBp biBbUkZDODQwNF0uDQoNCg0KDQpUaGlzIGxhbmd1YWdlIHdvdWxkIGxldCB5b3UgZGlzdGluZ3Vp c2ggYWxsIG9mIHRoZSBtaWRkbGUgYm94IGJlaGF2aW9ycw0KDQpkb25lIGJ5IG9wZXJhdG9ycyBh bmQgZW50ZXJwcmlzZXMgZnJvbSBhIHBvc3NpYmxlIFtSRkM3MjU4XSBhdHRhY2tlci4NCg0KDQoN CkFzIEkgbm90ZWQgaW4gbXkgcmVwbHkgdG8gQmVuLCBJIGRvbid0IGZvbGxvdyB0aGUgY3VycmVu dCBsYW5ndWFnZSBmb3IgYW50aWNpcGF0ZWQvdW5hbnRpY2lwYXRlZC4NCg0KDQoNCmh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGxzLzU0Y0VwalVjSVpxTldfeTdFYjM0NFhM UXAwWQ0KDQoNCg0KLS0gUkZDODQwNCBkZXNjcmliZXMgYSBudW1iZXIgb2YgbWlkZGxlYm94IHBy YWN0aWNlcywgYnV0IG9ubHkNCg0KU2VjdGlvbg0KDQo2LjIgZXhwbGljaXRseSBkaXNjdXNzZXMg U05JLCBhbmQgb2YgdGhlIGV4YW1wbGVzIGxpc3QgaGVyZSwgb25seQ0KDQpvbmUgY29tZXMgZnJv bSBSRkM4NDA0Lg0KDQpBIGZldyBvZiB0aGUgZXhhbXBsZXMgYWxzbyBjb21lIGluIHRoZSAiZGVl cCBwYWNrZXQgaW5zcGVjdGlvbiINCg0Kc2VjdGlvbnMgb2YgODQwNC4gQnV0IHJhdGhlciB0aGFu IGdvaW5nIGluIGEgbG9uZyBkaXNjdXNzaW9uLCBJIHdvdWxkDQoNCnJhdGhlciByZXdyaXRlIHRo ZSBzZW50ZW5jZSBhczogTWFueSBleGFtcGxlcyBvZiBzdWNoIHVzYWdlIGFyZQ0KDQpyZXZpZXdl ZCBpbiBbQD9SRkM4NDA0XSwgb3RoZXIgZXhhbXBsZXMgY2FtZSBvdXQgZHVyaW5nIGRpc2N1c3Np b25zIG9mDQoNCnRoaXMgZHJhZnQuDQoNCg0KDQpUaGUgLTA3IHRleHQgd29ya3MgZm9yIG1lLiAg VGhhbmtzLg0KDQoNCg0KKiogU2VjdGlvbiAyLjEuIFRoZSDigJxtb25pdG9yaW5nIGFuZCBpZGVu dGlmaWNhdGlvbiBvZiBzcGVjaWZpYyBzaXRlc+KAnQ0KDQppc27igJl0IHN5bW1ldHJpYyB0byB0 aGUgb3RoZXIgZXhhbXBsZXMg4oCTIGl0IGlzIHJhdGhlciBnZW5lcmljLiAgVGhlDQoNCm90aGVy IGV4YW1wbGVzLCBpZGVudGlmeSBhIHdoYXQvd2hvIChlLmcuLCBJU1AsIGZpcmV3YWxsKSArIGFj dGlvbg0KDQooZS5nLiwNCg0KYmxvY2ssIGZpbHRlcikuDQoNCkFsc28sIHRvIGltcGxlbWVudCBt b3N0IG9mIHRoZSBvdGhlciBleGFtcGxlLCDigJxtb25pdG9yaW5nIGFuZA0KDQppZGVudGlmaWNh dGlvbiBvZiBzcGVjaWZpYyBzaXRlc+KAnSBuZWVkcyB0byBiZSBkb25lLg0KDQpJIHN0aWxsIHRo aW5rIHRoaXMgbmVlZHMgdG8gYmUgY2xlYW5lZCB1cCBpbiBzb21lIHdheS4gIElNTywgSSdkIGRy b3AgaXQuDQoNCg0KDQpXYXMgcmV3cml0dGVuIGluIG5ldyBzZWN0aW9uIDIuMSBhcyAiRmlsdGVy aW5nIG9yIGNlbnNvcnNoaXAgb2Ygc3BlY2lmaWMNCg0Kc2VydmljZXMgZm9yIGEgdmFyaWV0eSBv ZiByZWFzb25zLiINCg0KDQoNCkknbSBzdGlsbCBzdHJ1Z2dsaW5nIHdpdGggdGhlIHNwZWNpZmlj aXR5IGhlcmUgYW5kIHRoZSBvdmVybGFwLiAgRHJvcHBpbmcgdGhlIGNlbnNvcnNoaXAgYW5kIGl0 IHJlYWRzICJmaWx0ZXJpbmcgb2Ygc3BlY2lmaWMgc2VydmljZXMgZm9yIGEgdmFyaWV0eSBvZiBy ZWFzb25zIi4gIFRoYXQncyBleGFjdGx5IHdoYXQgYnVsbGV0IDIgKGNvbnRlbnQgZmlsdGVyaW5n IGJ5IG9wZXJhdG9ycykgYW5kIGJ1bGxldCAzIChlbnRlcnByaXNlIGZpcmV3YWxscyBmb3IgTlNG VykNCg0KDQoNCldoYXQncyB1bmlxdWUgYWJvdXQgdGhpcyBidWxsZXQgLS0gaXMgaXQgd2hvIGlz IGRvaW5nIHRoaXMgZmlsdGVyL2NlbnNvcnNoaXA/IHdoZXJlIGl0IGlzIGhhcHBlbmluZz8gV2hh dCB0ZWNoIGlzIGJlaW5nIHVzZWQ/DQoNCkZvciBleGFtcGxlLCBhcmJpdHJhcnkgZmlsdGVyaW5n IG9mIHdlYiBzaXRlcyBjb21wZXRpbmcgd2l0aCBvdGhlciBzZXJ2aWNlcyBwcmVmZXJyZWQgYnkg dGhlIG5ldHdvcmsgcHJvdmlkZXIuICBTb21lIGZpbHRlcmluZyBhbmQgY2Vuc29yc2hpcCBpcyBt b3JlIGNvbnRyb3ZlcnNpYWwgdGhhbiBvdGhlcnMuIEJ1dCBJIGRvbid0IHRoaW5rIHRoYXQgbGlz dGluZyBldmVyeSBjb250cm92ZXJzaWFsIHVzYWdlIHdvdWxkIGJlIGFwcHJvcHJpYXRlLiBJIHdv dWxkIHJhdGhlciBrZWVwIHRoZSBzb21ld2hhdCB2YWd1ZSBwaHJhc2luZyB0aGFuIHRyeSB0byBo YXZlIGEgZGViYXRlIGFib3V0IHdoaWNoIHByYWN0aWNlIGlzIGNvbnRyb3ZlcnNpYWwgYW5kIHdo aWNoIGlzIG5vdC4NCg0KW1JvbWFuXSAgVW5kZXJzdG9vZC4gIFBvaW50IG1hZGUuICBUaGUgdGV4 dCBpcyBuZXV0cmFsIGVub3VnaCBmb3IgbWUgbm93LCBhbmQgSSB3b27igJl0IHB1c2ggZnVydGhl ciAoZm9yIGVkaXRvcmlhbCBjbGFyaXR5KS4gIFRoYW5rcy4NCg0KDQoNCi4uLg0KDQoqKiBTZWN0 aW9uIDIuMS4gIFBlciDigJxUaGUgU05JIGlzIHByb2JhYmx5IGFsc28gaW5jbHVkZWQgaW4gdGhl DQoNCmdlbmVyYWwgY29sbGVjdGlvbiBvZiBtZXRhZGF0YSBieSBwZXJ2YXNpdmUgc3VydmVpbGxh bmNlIGFjdG9yc+KAnSwgSQ0KDQpyZWNvbW1lbmQgYWdhaW5zdCBzcGVjdWxhdGlvbiBhbmQgaW5z dGVhZCBzaW1wbHkgc3RhdGluZyB0aGF0IFNOSQ0KDQp3b3VsZCBiZSBpbnRlcmVzdGluZyBtZXRh LWRhdGEgZm9yIGEgUkZDNzI1OCBhdHRhY2tlci4NCg0KWWVzLCBNaXJqYSBtYWRlIGEgc2ltaWxh ciBjb21tZW50LiBQcm9wb3NlZCByZXBsYWNlbWVudDoNCg0KDQoNClRoZSBTTkkgaXMgcHJvYmFi bHkgYWxzbyBpbmNsdWRlZCBpbiB0aGUgZ2VuZXJhbCBjb2xsZWN0aW9uIG9mDQoNCm1ldGFkYXRh IGJ5IHBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2UgYWN0b3JzLCBmb3IgZXhhbXBsZSB0byBpZGVudGlm eQ0KDQpzZXJ2aWNlcyB1c2VkIGJ5IHN1cnZlaWxsYW5jZSB0YXJnZXRzLg0KDQpJTU8sIGV4cGxp Y2l0bHkgbGlua2luZyBpdCB0byB0aGUgZHJhZnQgd291bGQgaGVscC4NCg0KDQoNCk9MRDoNCg0K VGhlIFNOSSBpcyBwcm9iYWJseSBhbHNvIGluY2x1ZGVkIGluIHRoZSBnZW5lcmFsIGNvbGxlY3Rp b24gb2YNCg0KbWV0YWRhdGEgYnkgcGVydmFzaXZlIHN1cnZlaWxsYW5jZSBhY3RvcnMsIGZvciBl eGFtcGxlIHRvIGlkZW50aWZ5DQoNCnNlcnZpY2VzIHVzZWQgYnkgc3VydmVpbGxhbmNlIHRhcmdl dHMuDQoNCg0KDQpORVc6DQoNClRoZSBTTkkgY291bGQgYmUgaW5jbHVkZWQgaW4gdGhlIGdlbmVy YWwgY29sbGVjdGlvbiBvZiBtZXRhZGF0YSBieQ0KDQpwZXJ2YXNpdmUgbW9uaXRvcmluZyBhdHRh Y2tlciBbUkZDNzI1OF0sIGZvciBleGFtcGxlIHRvIGlkZW50aWZ5DQoNCnNlcnZpY2VzIHVzZWQg Ynkgc3VydmVpbGxhbmNlIHRhcmdldHMuDQoNCg0KDQpJIG1pc3NlZCB0aGUgcmVmZXJlbmNlIHRv IDcyNTguIFdpbGwgYWRkIGl0IGluIHRoZSBuZXh0IHZlcnNpb24uDQoNCg0KDQpSZWNvbW1lbmQg YWRkaW5nIHRoZSBSRkM3MjU4IHJlZmVyZW5jZS4gIEFzIEkgbm90ZWQgYWJvdmUsIHRoZSBzZW1h bnRpY3Mgb2YgInByb2JhYmx5IiB2cy4gImNvdWxkIi4gICJwcm9iYWJseSIgc3VnZ2VzdHMgYSBj b25maWRlbmNlIHRvIG1lLg0KDQpZZXMsIHRoZXJlIGlzIHNvbWUgY29uZmlkZW5jZSwgYmFzZWQg b24gdGhlIFNub3dkZW4gcmV2ZWxhdGlvbiBvZiBzeXN0ZW1zIGxpa2UgUXVhbnR1bSBJbnNlcnQs IGNvbW1lbnRzIGxpa2UgInJlY29yZGluZyB0aGUgd2hvbGUgaGF5c3RhY2siLCBvciB0aGUgS29y ZWFuIHJlZ3VsYXRpb24gZXhwbGljaXRseSB0YXJnZXRpbmcgdGhlIFNOSSBmaWVsZC4gSXQgaXMg bW9yZSBwcm9iYWJsZSB0aGFuIG5vdCB0aGF0IFNOSSBkYXRhIGlzIGJlaW5nIHJlY29yZGVkLCBh bmQgSSB0aGluayB0aGF0ICJwcm9iYWJseSIgaXMganVzdCBmaW5lLg0KDQpbUm9tYW5dIEkgY2Fu IGxpdmUgd2l0aCBqdXN0IHRoZSBSRkM3MjU4IHJlZmVyZW5jZS4gIFRoYW5rcyBmb3IgYWRkaW5n IGl0Lg0KDQoNCg0KDQoNCg0KDQoNCg0KKiogU2VjdGlvbiAyLjIuICBQZXIg4oCcT25lIHJlYXNv biBtYXkgYmUgdGhhdCwgd2hlbiB0aGVzZSBSRkNzIHdlcmUNCg0Kd3JpdHRlbiwgdGhlIFNOSSBp bmZvcm1hdGlvbiB3YXMgYXZhaWxhYmxlIHRocm91Z2ggYSB2YXJpZXR5IG9mDQoNCm90aGVyIG1l YW5z4oCdLCB3aGF0IHdvdWxkIHRob3NlIOKAnG90aGVyIG1lYW5z4oCdIGJlPw0KDQpUaGUgbGlz dCBpbmNsdWRlcyBhdCBhIG1pbmltdW06DQoNCg0KDQpDbGVhciB0ZXh0IGV4Y2hhbmdlcyBhbWVu YWJsZSB0byBkZWVwIHBhY2tldCBpbnNwZWN0aW9uIChEUEkpLCBzZXJ2ZXINCg0KY2VydGlmaWNh dGVzIHNlbmQgaW4gY2xlYXIgdGV4dCBkdXJpbmcgVExTL1NTTCBleGNoYW5nZXMsIEROUyBuYW1l cw0KDQpvZiBzZXJ2ZXJzIGluIGNsZWFyIHRleHQgRE5TIHF1ZXJpZXMsIGFuZCBzZXJ2ZXIgc3Bl Y2lmaWMgSVANCg0KYWRkcmVzc2VzIGluIHBhY2tldCBoZWFkZXJzLg0KDQoNCg0KSSBndWVzcyBJ IGNvdWxkIHdyaXRlIHRoYXQgYWxsLCBidXQgaXQgbWFrZXMgdGhlIHRleHQgYSBiaXQNCg0KcmVk dW5kYW50LCBzaW5jZSB0aGUgZm9sbG93aW5nIHBhcmFncmFwaHMgZG8gZGlzY3VzcyBzZXJ2ZXIN Cg0KY2VydGlmaWNhdGVzLCBETlMgbmFtZXMgYW5kIElQIGFkZHJlc3Nlcy4NCg0KSSB1bmRlcnN0 YW5kLiAgSSBkaWRuJ3QgcmVhZCBpdCB0aGF0IHdheS4gIE15IHJlY29tbWVuZGF0aW9uIGlzbid0 IHRvDQoNCmRlc2NyaWJlIHRoZSAib3RoZXIgbWVhbnMiIChhcyBpdCBpcyBkZXNjcmliZWQgYmVs b3cpLCBidXQgdG8gYmUgY2xlYXIgb24gdGhlDQoNCm9idmlvdXMsIHdoYXQgaXMgdGhlIFNOSSBp bmZvcm1hdGlvbi4NCg0KDQoNCk9MRDoNCg0KT25lIHJlYXNvbiBtYXkgYmUgdGhhdCwgd2hlbiB0 aGVzZSBSRkNzIHdlcmUgd3JpdHRlbiwgdGhlIFNOSQ0KDQppbmZvcm1hdGlvbiB3YXMgYXZhaWxh YmxlIHRocm91Z2ggYSB2YXJpZXR5IG9mIG90aGVyIG1lYW5zLg0KDQoNCg0KTkVXOg0KDQpPbmUg cmVhc29uIG1heSBiZSB0aGF0IHdoZW4gdGhlIFJGQ3Mgd2VyZSB3cml0dGVuLCB0aGUgbmFtZSBv ZiB0aGUNCg0Kc2VydmVyIHRoZSBiZWluZyBjb250YWN0ZWQgYnkgdGhlIGNsaWVudCAoaS5lLiwg dGhlIFNOSSkgd2FzIGV2aWRlbnQgdGhyb3VnaA0KDQpvdGhlciBtZWFucy4NCg0KDQoNClRoZSBu ZXcgdGV4dCBpbiAtMDcgcmVhZHMgbW9yZSBjbGVhcmx5IHRvIG1lLiAgVGhhbmtzIGZvciB0aGlz IGNoYW5nZS4NCg0KDQoNCioqIFNlY3Rpb24gMi4zLiAgUGVyIOKAnERlcGxveWluZyBTTkkgZW5j cnlwdGlvbiB3aWxsIGhlbHAgdGh3YXJ0aW5nDQoNCm1vc3Qgb2YNCg0KdGhlDQoNCuKAmHVuYW50 aWNpcGF0ZWTigJkgU05JIHVzYWdlcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEsIGluY2x1ZGlu Zw0KDQpjZW5zb3JzaGlwDQoNCmFuZA0KDQpwZXJ2YXNpdmUgc3VydmVpbGxhbmNlLuKAnToNCg0K DQoNCi0tIFdoeSB0aGUgcXVvdGVzIGFyb3VuZCAidW5hbnRpY2lwYXRlZCIgU05JIHVzYWdlPw0K DQpSZW1vdmluZyB0aGUgcXVvdGVzLiBPdGhlcndpc2UsIHlvdSB3aWxsIGJlIGNvbnZpbmNlZCB0 aGF0IHRoZQ0KDQphdXRob3JzIGJlbGlldmUgdGhhdCBhbGwgbWlkZGxlLWJveGVzIGFyZSB0aGUg c3Bhd24gb2YgdGhlIGRldmlsLi4uDQoNClRoYW5rcy4NCg0KDQoNCi0tIE9uZSBwZXJzb27igJlz IGNlbnNvcnNoaXAgaXMgYW5vdGhlciBwZXJzb27igJlzIHRocmVhdCBtaXRpZ2F0aW9uLA0KDQpw b2xpY3kgZW5mb3JjZW1lbnQgZm9yIGEgbmV0d29yayB0aGV5IG93biwgb3IgcGFyZW50YWwgY29u dHJvbHMgKHBlcg0KDQp0aGUgbGlzdCBpbiBTZWN0aW9uIDIuMSkg4oCTIHJlY29tbWVuZCBiZWlu ZyBtb3JlIHByZWNpc2Ugb24gdGhlIG9yZGVyDQoNCm9mIOKAnERlcGxveWluZw0KDQpTTkkNCg0K ZW5jcnlwdGlvbiB3aWxsIHticmVhayB8IHJlZHVjZSB0aGUgZWZmaWNhY3kgb2YgfSB0aGUgb3Bl cmF0aW9uYWwNCg0KcHJhY3RpY2VzDQoNCmFuZA0KDQp0ZWNobmlxdWVzIHVzZWQgaW4gbWlkZGxl Ym94ZXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4x4oCdLg0KDQpPSy4gSSB3aWxsIHRyeSB0byBt YWtlIHRoZSB0ZXh0IGp1c3Qgc3RpY2sgdG8gdGhlIGZhY3RzOg0KDQoNCg0KRGVwbG95aW5nIFNO SSBlbmNyeXB0aW9uIHRod2FydHMgbW9zdCBvZiB0aGUgdW5hbnRpY2lwYXRlZCBTTkkgdXNhZ2Vz DQoNCmRlc2NyaWJlZCBpbiAoI3NuaWxlYWspLiBJdCByZWR1Y2VzIHRoZSBlZmZpY2FjeSBvZiB0 aGUgb3BlcmF0aW9uYWwNCg0KcHJhY3RpY2VzIGFuZCB0ZWNobmlxdWVzIGltcGxlbWVudCBpbiBt aWRkbGUtYm94ZXMuIE1vc3Qgb2YgdGhlc2UNCg0KZnVuY3Rpb25zIGNhbiwgaG93ZXZlciwgYmUg cmVhbGl6ZWQgYnkgb3RoZXIgbWVhbnMuDQoNCg0KDQpUaGFua3MgZm9yIHRoaXMuDQoNCg0KDQpX b3JrcyBmb3IgbWUuICBIb3dldmVyLCBJJ2QgZHJvcCAiTW9zdCBvZiB0aGVzZSBmdW5jdGlvbnMg Y2FuLCBob3dldmVyLA0KDQpiZSByZWFsaXplZCBieSBvdGhlciBtZWFucyIgYmVjYXVzZSB0aGlz IG9wZW5zIHRoZSBkZWJhdGUgb24gaG93IGV4YWN0bHksDQoNCmV0Yy4NCg0KDQoNCkkgc3RpbGwg cmVjb21tZW5kIGRyb3BwaW5nIHRoZSAib3RoZXIgbWVhbnMiIHRleHQgYmVjYXVzZSB0aGF0IG9w ZW5zIGRlYmF0ZS4NCg0KDQoNCioqIFNlY3Rpb24gMi4zLiAgUGVyIOKAnEl0IHdpbGwgYWxzbyB0 aHdhcnQgZnVuY3Rpb25zIHRoYXQgYXJlDQoNCnNvbWV0aW1lcyBkZXNjcmliZWQgYXMgbGVnaXRp bWF0ZeKAnSwgd2hhdCBmdW5jdGlvbnMgYXJlIHRob3NlPyAgSeKAmWQNCg0KcmVjb21tZW5kDQoN CmVsaW1pbmF0aW5nDQoNCnRoaXMgc2VudGVuY2UgYXMgaXQgcmVhZHMgbGlrZSBhIHZhbHVlIGp1 ZGdlbWVudCBvbiBleGlzdGluZw0KDQpwcmFjdGljZXMgKHdoaWNoIGRvZXNu4oCZdCBzZWVtIGdl cm1hbmUgZm9yIGRpc2N1c3NpbmcgcmVxdWlyZW1lbnRzKS4NCg0KDQoNCk5vdyB0aGF0IGNlbnNv cnNoaXAgZ290IGFkZGVkIHRvIHRoZSBsaXN0IGluIFNlY3Rpb24gMi4xLCB5b3UgbGlrZWx5IHdh bnQgdG86DQoNCg0KDQpzL2luY2x1ZGluZyBjZW5zb3JzaGlwIGFuZCBwZXJ2YXNpdmUgc3VydmVp bGxhbmNlL2luY2x1ZGluZyBwZXJ2YXNpdmUgc3VydmVpbGxhbmNlLw0KDQoNCg0KT3RoZXJ3aXNl LCBMR1RNLiAgVGhhbmtzLg0KDQpPSy4NCg0KDQoNCi4uLg0KLi4uDQoNCg0KDQoiVGhpcyBkb2N1 bWVudCBkb2VzIG5vdCBwcmVzZW50IHRoZSBkZXNpZ24gb2YgYSBzb2x1dGlvbiwgYnV0IHByb3Zp ZGVzDQoNCmd1aWRlbGluZXMgZm9yIGV2YWx1YXRpbmcgcHJvcG9zZWQgc29sdXRpb25zLiIgIEhv d2V2ZXIsIHRoZSBjdXJyZW50IHRleHQgaW4NCg0KU2VjdGlvbiA0IGlzIGV4cGxpY2l0bHkgc3Rh dGVzIGl0IGlzIHByb3ZpZGluZyBhIHNvbHV0aW9uLiAgVGhlIHN1Yi1zZWN0aW9uIG9mDQoNClNl Y3Rpb24gNC54IGFzc3VtZSB0aGUgc29sdXRpb24gaW4gU2VjdGlvbiA0LjAgYW5kIGRlc2NyaWJl IHRoZSBmb2xsb3ctb24NCg0Kd29yay4gIFNlY3Rpb24gMiAtIDMgZG8gbGF5IG91dCB0aGUgbWVh bnMgZm9yIGV2YWx1YXRpb24gbmljZWx5LiAgUGVyaGFwcywNCg0Kc29tZXRoaW5nIG9uIHRoZSBv cmRlciBvZjoNCg0KDQoNCk9MRDoNCg0KVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBwcmVzZW50IHRo ZSBkZXNpZ24gb2YgYSBzb2x1dGlvbiwgYnV0IHByb3ZpZGVzDQoNCmd1aWRlbGluZXMgZm9yIGV2 YWx1YXRpbmcgcHJvcG9zZWQgc29sdXRpb25zLg0KDQoNCg0KTkVXOg0KDQpUaGlzIHByb3ZpZGVz IGd1aWRlbGluZXMgb24gZXZhbHVhdGluZyBzb2x1dGlvbiBhbmQgcHJvcG9zZXMgYW4NCg0KYXJj aGl0ZWN0dXJlIHRvIG1pdGlnYXRlIHRoZSB0aHJlYXRzIGNyZWF0ZWQgYnkgYW4gdW5lbmNyeXB0 ZWQgU05JIHVzaW5nDQoNCmV4aXN0aW5nIGFwcHJvYWNoZXMuDQoNCg0KDQoNCg0KSSBhZGRlZCB0 aGUgcmVmZXJlbmNlIHRvIGEgcGFwZXIgYnkgRmlmaWVkIGV0IGFsLiB0aGF0IGRlc2NyaWJlcyB0 aGUgImRvbWFpbg0KDQpmcm9udGluZyIgc29sdXRpb24gYW5kIHNvbWUgb2YgaXRzIGRlcGxveW1l bnRzLg0KDQoNCg0KTm90ZSB0aGF0IHRoZSBpbnRlbnQgaXMgbm90IHRvIHJlY29tbWVuZCB0aGUg ZG9tYWluIGZyb250aW5nIHNvbHV0aW9uLiBUaGF0IHNvbHV0aW9uLCBhbmQgdGhlIEhUVFBTIHR1 bm5lbCBzb2x1dGlvbiwgYXJlIGV4YW1pbmVkIGFzIGV4YW1wbGUgb2YgcHJvcG9zZWQgc29sdXRp b25zIHRoYXQgbWVldCBzb21lIG9mIHRoZSByZXF1aXJlbWVudCBidXQgbm90IGFsbC4gQnV0IEkg dW5kZXJzdGFuZCB0aGF0IHlvdSBwZXJjZWl2ZWQgdGhlIHRleHQgYXMgc29tZSBraW5kIG9mIGVu ZG9yc2VtZW50Lg0KDQpbUm9tYW5dICBSaWdodCwgYnV0IEkgYWxzbyB0aGluayB0aGUgY2l0YXRp b24gaGVscHMgdGhhdCB5b3XigJlyZSBkZXNjcmliaW5nIGFuIGV4aXN0aW5nIHByYWN0aWNlLiAg VGhlIG5ldyBsYW5ndWFnZSBpbiBhZGRlZCBpbiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvc25p ZW5jcnlwdGlvbi9wdWxsLzQ2L2ZpbGVzIHdvcmtzIGZvciBtZS4gIFRoYW5rcy4NCg0KLi4uDQoN Cg0KDQoNCg0KRHJhZnQgMDcgYWRkZWQgdGV4dCBkZXNjcmliaW5nIGFjdHVhbCBkZXBsb3ltZW50 cy4NCg0KDQoNClRoZSB1c2Ugb2YgdGhlIFtkb21mcm9udF0gY2l0YXRpb24gd29ya3MgZm9yIG1l IGFuZCBhZGRyZXNzZXMgbXkgY29uY2VybnMuICBUd28gbml0czoNCg0KDQoNCioqIEknZCByZWNv bW1lbmQgdXNpbmcgdGhlIFVSTCB0byB0aGUgcGFwZXIgZnJvbSBjb25mZXJlbmNlIHNpdGUgaXRz ZWxmOiBodHRwczovL3BldHN5bXBvc2l1bS5vcmcvMjAxNS9wYXBlcnMvMDNfRmlmaWVsZC5wZGYN Ck9LLg0KDQoNCg0KDQoNCg0KKiogSSdkIGFsc28gcmVjb21tZW5kIGFkZGluZyBhIHNlbnRlbmNl IHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDEsICJUaGlzIGRvY3VtZW50IGRvZXMg bm90IHByZXNlbnQgdGhlIGRlc2lnbiAuLi4iLCB0byBmb3Jlc2hhZG93IHRoYXQgeW91J2xsIGRp c2N1c3MgYW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggZXZlbiBpZiBlbmNyeXB0ZWQgU05JIGlzbid0 IHJlYWxpemVkIHlldC4NCg0KT0ssIHdpbGwgdHJ5IG1ha2UgY2xlYXIgdGhhdCB0aGlzIGlzIG5v dCBhbiBlbmRvcnNlbWVudCBvciBhIHByb3Bvc2FsLg0KDQpbUm9tYW5dIEkgdGhpbmsgeW91IGhh dmUgaXQgY292ZXJlZCBpbiB0aGUgbmV3IGxhbmd1YWdlIGluIGh0dHBzOi8vZ2l0aHViLmNvbS90 bHN3Zy9zbmllbmNyeXB0aW9uL3B1bGwvNDYvZmlsZXMuDQoNClJlZ2FyZHMsDQoNClJvbWFuDQoN Ci0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0KDQoNCg0KDQo= --_000_359EC4B99E040048A7131E0F4E113AFC01B347B31Amarathon_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBDaHJpc3RpYW4hPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIGFsbCBvZiB0aGUgaXRlcmF0aW9uIGFu ZCB1cGRhdGVzLiZuYnNwOyBHaXZlbiB3aGF04oCZcyBwcm9wb3NlZCBpbiBnaXRodWIgKGh0dHBz Oi8vZ2l0aHViLmNvbS90bHN3Zy9zbmllbmNyeXB0aW9uL3B1bGwvNDYvZmlsZXMpLCBjb25zaWRl ciBteSBjb21tZW50cyByZXNvbHZlZC4mbmJzcDsNCiBNaW5vciBjb21tZW50cyBpbmxpbmUg4oCm PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQ2hyaXN0aWFuIEh1aXRl bWEgW21haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTkgNjo1MyBQTTxicj4NCjxiPlRvOjwvYj4gUm9tYW4gRGFu eWxpdyAmbHQ7cmRkQGNlcnQub3JnJmd0OzsgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBkcmFmdC1pZXRmLXRscy1zbmktZW5jcnlwdGlvbkBpZXRmLm9yZzsg dGxzLWNoYWlyc0BpZXRmLm9yZzsgdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbVExTXSBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdGxzLXNu aS1lbmNyeXB0aW9uLTA1OiAod2l0aCBDT01NRU5UKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDkvMjYvMjAxOSAxMTozOCBBTSwgUm9tYW4gRGFueWxpdyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cHJlPkhpIENocmlzdGlhbiE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGFua3MgZm9yIGFsbCBvZiB0aGUgdXBkYXRlcy4m bmJzcDsgSSBoYXZlIGEgcmVtYWluaW5nIGl0ZW1zIGFyZSBkZXNjcmliZWQgaW5saW5lLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRvIGJyaW5n IHVwIGEgbmV3IGl0ZW0sIHRoZXJlIHdhcyBuZXcgdGV4dCBpbnRyb2R1Y2VkIGluIC0wNiBvZiBT ZWN0aW9uIDUgdG8gd2hpY2ggSSBzdHJvbmdseSBvYmplY3QuJm5ic3A7IFNwZWNpZmljYWxseTo8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mcXVv dDtSZXBsYWNpbmcgY2xlYXIgdGV4dCBTTkkgdHJhbnNtaXNzaW9uIGJ5IGFuIGVuY3J5cHRlZCB2 YXJpYW50IHdpbGwmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+YWxz byB0aHdhcnQgTUlUTSBpbnRlcmZlcmVuY2VzIHRoYXQgYXJlIHNvbWV0aW1lcyBkZXNjcmliZWQg YXMgPG86cD48L286cD48L3ByZT4NCjxwcmU+bGVnaXRpbWF0ZS4mbmJzcDsgQXMgZXhwbGFpbmVk IGluIFNlY3Rpb24gMi4zLCBhbHRlcm5hdGl2ZSBzb2x1dGlvbnMgd2lsbCZuYnNwOyA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5oYXZlIHRvIGJlIGRldmVsb3BlZC7igJ08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHJlYWQgdGhpcyBwYXJhZ3Jh cGggYXMgYWRkcmVzc2luZyB0aGUgb3BlcmF0aW9uYWwgcHJhY3RpY2VzIG91dGxpbmVkIGluIFNl Y3Rpb24gMi4xLiZuYnNwOyBJIHRoaW5rIGl0IGlzIGluYXBwcm9wcmlhdGUgdG8gcmVmZXIgdG8g c29tZSBvZiB0aGVzZSBvcGVyYXRpb25hbCBwcmFjdGljZXMgYXMgYmVpbmcgJnF1b3Q7c29tZXRp bWVzIGRlc2NyaWJlZCBhcyBsZWdpdGltYXRlJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Js b2NrcXVvdGU+DQo8cD5Bbnl0aGluZyBwZXJmb3JtZWQgYnkgTUlUTSBpcyBieSBkZWZpbml0aW9u IGNvbnRyb3ZlcnNpYWwuIEJ1dCBJIGdldCB5b3VyIHBvaW50LiBIb3cgYWJvdXQNCjxvOnA+PC9v OnA+PC9wPg0KPHByZT4mcXVvdDtSZXBsYWNpbmcgY2xlYXIgdGV4dCBTTkkgdHJhbnNtaXNzaW9u IGJ5IGFuIGVuY3J5cHRlZCB2YXJpYW50IHdpbGwgYnJlYWsgb3IgcmVkdWNlIHRoZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPmVmZmljYWN5IG9mIHRoZSBvcGVyYXRpb25hbCBwcmFjdGljZXMgYW5k IHRlY2huaXF1ZXMgaW1wbGVtZW50ZWQgaW4gbWlkZGxlLWJveGVzIGFzPG86cD48L286cD48L3By ZT4NCjxwcmU+ZGVzY3JpYmVkIGluIFNlY3Rpb24gMi4xLiBBcyBleHBsYWluZWQgaW4gU2VjdGlv biAyLjMsIGFsdGVybmF0aXZlIHNvbHV0aW9ucyB3aWxsPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+aGF2ZSB0byBiZSBkZXZlbG9wZWQuJnF1b3Q7PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUm9tYW5dIExvb2tzIGdv b2QgdG8gbWUuJm5ic3A7IFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwcmU+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5Gcm9tOiBDaHJpc3RpYW4gSHVpdGVtYSBbPGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVp dGVtYS5uZXQiPm1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0PC9hPl08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5TZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyNSwgMjAxOSAzOjQ3IFBNPG86cD48 L286cD48L3ByZT4NCjxwcmU+VG86IFJvbWFuIERhbnlsaXcgPGEgaHJlZj0ibWFpbHRvOnJkZEBj ZXJ0Lm9yZyI+Jmx0O3JkZEBjZXJ0Lm9yZyZndDs8L2E+OyBUaGUgSUVTRyA8YSBocmVmPSJtYWls dG86aWVzZ0BpZXRmLm9yZyI+Jmx0O2llc2dAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkNjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi10bHMtc25pLWVuY3J5cHRp b25AaWV0Zi5vcmciPmRyYWZ0LWlldGYtdGxzLXNuaS1lbmNyeXB0aW9uQGlldGYub3JnPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnRscy1jaGFpcnNAaWV0Zi5vcmciPnRscy1jaGFpcnNAaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+PG86cD48 L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFtUTFNdIFJvbWFuIERhbnlsaXcncyBObyBP YmplY3Rpb24gb24gZHJhZnQtaWV0Zi10bHMtc25pLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmVu Y3J5cHRpb24tMDU6ICh3aXRoIENPTU1FTlQpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+SGVsbG8gUm9tYW4sPG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QSBsb3Qgb2YgdGhlIGZpeGVzIHRoYXQg eW91IHN1Z2dlc3RlZCBhcmUgaW5jb3Jwb3JhdGVkIGluIHRoZSBkcmFmdC0wNyB0aGF0IHdhczxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmp1c3QgcmVsZWFzZWQuIEkgdGhpbmsgdGhlIGxhc3QgdmVy c2lvbiBhZGRyZXNzZXMgeW91ciBjb25jZXJucywgYnV0IHlvdSBtYXk8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5vZiBjb3Vyc2Ugd2FudCB0byB2ZXJpZnkuPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T24gOS8yNS8yMDE5IDc6MjcgQU0sIFJvbWFu IERhbnlsaXcgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IaSBDaHJpc3RpYW4hPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhhbmtz IGZvciB0aGUgZGV0YWlsZWQgcmVzcG9uc2VzIGFuZCB0aGUgaGVscGZ1bCBiYWNrZ3JvdW5kLiZu YnNwOyBCZWxvdyBhcmUgYTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPm51 bWJlciBvZiBwcm9wb3NlZCB0ZXh0IGJsb2NrIHJlcGxhY2VtZW50cyB0byBjbGFyaWZ5IG15IGlu dGVudCAoaW5zdGVhZCBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1vcmUgcXVlc3Rpb25zKS48 bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlJv bWFuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy ZT4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkZyb206 IGllc2cgWzxhIGhyZWY9Im1haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzppZXNn LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuPG86cD48L286cD48 L3ByZT4NCjxwcmU+SHVpdGVtYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlNlbnQ6IFdlZG5lc2Rh eSwgU2VwdGVtYmVyIDE4LCAyMDE5IDEwOjE0IFBNPG86cD48L286cD48L3ByZT4NCjxwcmU+VG86 IFJvbWFuIERhbnlsaXcgPGEgaHJlZj0ibWFpbHRvOnJkZEBjZXJ0Lm9yZyI+Jmx0O3JkZEBjZXJ0 Lm9yZyZndDs8L2E+OyBUaGUgSUVTRyA8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+Jmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkNjOiA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi10bHMtc25pLWVuY3J5cHRpb25AaWV0Zi5vcmciPmRyYWZ0LWll dGYtdGxzLXNuaS1lbmNyeXB0aW9uQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnRscy1j aGFpcnNAaWV0Zi5vcmciPnRscy1jaGFpcnNAaWV0Zi5vcmc8L2E+OzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPnRsc0BpZXRmLm9yZzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5TdWJqZWN0OiBSZTogW1RMU10gUm9tYW4gRGFueWxpdydzIE5v IE9iamVjdGlvbiBvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRyYWZ0LWlldGYtdGxzLXNuaS08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lbmNyeXB0aW9uLTA1OiAod2l0aCBDT01NRU5UKTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyBm b3IgdGhlIGZlZWRiYWNrLCBSb21hbi4gQ29tbWVudHMgaW4gbGluZS48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiA5LzE4LzIwMTkgNDo0MCBB TSwgUm9tYW4gRGFueWxpdyB2aWEgRGF0YXRyYWNrZXIgd3JvdGU6PG86cD48L286cD48L3ByZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT4qKiBTZWN0aW9uIDEuJm5ic3A7IFBlciDigJxNb3JlIGFuZCBtb3JlIHNlcnZpY2Vz IGFyZSBjb2xvY2F0ZWQgb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tdWx0aXBsZXhlZCBzZXJ2 ZXJzLCBsb29zZW5pbmcgdGhlIHJlbGF0aW9uIGJldHdlZW4gSVAgYWRkcmVzcyBhbmQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT53ZWIgc2VydmljZeKAnSwgY29tcGxldGVseSBhZ3JlZS4mbmJzcDsg SU1PLCB1bnBhY2tpbmcg4oCcbXVsdGlwbGV4ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZXJ2 ZXJz4oCdIGlzIHdvcnRod2hpbGUgdG8gZXhwbGFpbiB0aGUgc3Vic2VxdWVudCB0ZXh0IGJlY2F1 c2UgaXQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tb3RpdmF0ZXMgdGhlIGxvc3Mgb2YgdmlzaWJp bGl0eSBkdWUgdG8gZW5jcnlwdGlvbiB3aXRoIG5ldHdvcmsgb25seTxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPm1vbml0 b3JpbmcuPG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPuKAnE11bHRpcGxleOKAmSBoYXBwZW5z IGF0IHR3byBsZXZlbHM6PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4tLSBjby10ZW5hbnRzIChl LmcuLCB2aXJ0dWFsIGhvc3RpbmcpIOKAkyBtdWx0aXBsZSBzZXJ2aWNlcyBvbiB0aGU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5zYW1lIHNlcnZlciAoaS5lLiwgYW4gSVAvcG9ydCBkb2VzbuKAmXQg dW5pcXVlbHkgaWRlbnRpZnkgdGhlIHNlcnZpY2UpPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0gY2xvdWQvY2RuJm5ic3A7IOKAkyBhIGdpdmVu IHBsYXRmb3JtIGhvc3RzIHRoZSBzZXJ2aWNlcy9zZXJ2ZXJzIG9mIGEgbG90PG86cD48L286cD48 L3ByZT4NCjxwcmU+b2Ygb3JnYW5pemF0aW9uIChpLmUuLCBsb29raW5nIHVwIHRvIHdoYXQgbmV0 YmxvY2sgYW4gSVAgYmVsb25nczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJldmVhbHMgbGl0dGxl KTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPk9LLCB3aWxsIHRyeSB0byBpbmNvcnBvcmF0ZSB5b3VyIHRleHQuPG86cD48 L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+VGhhbmtzLjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNoYW5n ZXMgaW5jb3Jwb3JhdGVkIGluIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDEuPG86cD48L286 cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+VGhlIHRleHQgLTA3IHdvcmtzIGZvciBtZS4mbmJzcDsgVGhhbmtzIGZvciBhZGRpbmcgdGhp cyBleHRyYSBiaXQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4qKiBTZWN0aW9u IDIuMS4mbmJzcDsgUGVyIOKAnFRoZSBTTkkgd2FzIGRlZmluZWQgdG8gZmFjaWxpdGF0ZSBtYW5h Z2VtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+b2Ygc2VydmVycywgdGhvdWdoIHRoZSBkZXZl bG9wZXJzIG9mIG1pZGRsZWJveGVzIHNvb24gZm91bmQgb3V0IHRoYXQ8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT50aGV5IGNvdWxkIHRha2UgYWR2YW50YWdlIG9mIHRoZSBpbmZvcm1hdGlvbi4mbmJz cDsgTWFueSBleGFtcGxlcyBvZiBzdWNoPG86cD48L286cD48L3ByZT4NCjxwcmU+dXNhZ2UgYXJl IHJldmlld2VkIGluIFtSRkM4NDA0XS7igJ0sPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS0gQ2Fu4oCZdCBtaWRkbGVib3hlcyBhbHNvIGhlbHAg ZmFjaWxpdGF0ZSB0aGUgbWFuYWdlbWVudCBvZiBzZXJ2ZXJzPzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPlRoaXMgdGV4dCBzZWVtcyB0byB0YWtlIGEgcGFydGljdWxhciB2aWV3IG9uIG1pZGRsZWJv eGVzIHdoaWNoPG86cD48L286cD48L3ByZT4NCjxwcmU+ZG9lc24ndDxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPnNlZW0gYXBwcm9wcmlhdGUuPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SXQgaXMgcHJldHR5IGNsZWFyIHRo YXQgdGhlIGxvYWQgYmFsYW5jZXIgaW4gZnJvbnQgb2YgYSBzZXJ2ZXIgZmFybTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPndpbGwgbmVlZCBhY2Nlc3MgdG8gdGhlIHNlcnZpY2UgSUQsIGFuZCBtdXN0 IGJlIGFibGUgdG8gcmV0cmlldmUgdGhlPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxwcmU+ZGVjcnlwdGVkIFNOSS48bzpwPjwvbzpwPjwvcHJlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwcmU+VGhlcmUgbWF5IGJlIG90aGVyIGV4YW1wbGVzLCBzdWNoIGFzIERvUyBtaXRpZ2F0aW9u IGJveGVzLiBUaGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDt1bmFudGljaXBhdGVkIHVz YWdlJnF1b3Q7IGNvbWVzIHR5cGljYWxseSBmcm9tIG1pZGRsZS1ib3hlcyB0aGF0IGFyZSBub3Q8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pbiB0aGUgc2FtZSBtYW5hZ2VtZW50IGRvbWFpbiBhcyBl aXRoZXIgdGhlIGNsaWVudCBvciB0aGUgc2VydmVyLiBJczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PnRoZXJlIGFuIGVzdGFibGlzaGVkIHdheSB0byBkZXNpZ25hdGUgdGhvc2U/PG86cD48L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUg b3JpZ2luYWwgb2YgdGhlIHJlcXVpcmVtZW50IHRoYXQgdGhlIGNsaWVudDxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmFuZCBzZXJ2ZXIgYmVpbmcgaW4gdGhlIHNhbWUgbWFu YWdlbWVudCBkb21haW4uPG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5SRkMzNTQ2J3MgZGVmaW5pdGlvbiBvZiBTTkkgb3BlbnMgd2l0aDo8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgW1RMU10gZG9lcyBub3QgcHJvdmlkZSBh IG1lY2hhbmlzbSBmb3IgYSBjbGllbnQgdG8gdGVsbCBhIHNlcnZlciB0aGU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbmFtZSBvZiB0aGUgc2VydmVyIGl0IGlzIGNvbnRhY3Rp bmcuJm5ic3A7IEl0IG1heSBiZSBkZXNpcmFibGUgZm9yIGNsaWVudHM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsgdG8gcHJvdmlkZSB0aGlzIGluZm9ybWF0aW9uIHRvIGZhY2ls aXRhdGUgc2VjdXJlIGNvbm5lY3Rpb25zIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IHNlcnZlcnMgdGhhdCBob3N0IG11bHRpcGxlICd2aXJ0dWFsJyBzZXJ2ZXJzIGF0IGEg c2luZ2xlIHVuZGVybHlpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbmV0 d29yayBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPkl0IHNlZW1zIHRvIG1lIHRoYXQgaWYgd2UgYXJlIHRyeWluZyB0byBjaGFubmVs IG9yaWdpbmFsIGludGVudCwgdGhlbiBvbmx5IHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cHJlPnZpcnR1YWwgc2VydmVyIHVzZSBjYXNlIGFwcGxpZXMuJm5ic3A7IEknZCBw cm9wb3NlOjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+T0xEPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIFNOSSB3YXMgZGVmaW5lZCB0byBm YWNpbGl0YXRlIG1hbmFnZW1lbnQgb2Ygc2VydmVycywgdGhvdWdoIHRoZTxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmRldmVsb3BlcnMgb2YgbWlkZGxlYm94ZXMgc29vbiBm b3VuZCBvdXQgdGhhdCB0aGV5IGNvdWxkIHRha2UgYWR2YW50YWdlPG86cD48L286cD48L3ByZT4N CjxwcmU+b2YgdGhlIGluZm9ybWF0aW9uLiZuYnNwOyBNYW55IGV4YW1wbGVzIG9mIHN1Y2ggdXNh Z2UgYXJlIHJldmlld2VkIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+W1JGQzg0MDRdLjxvOnA+ PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TkVXPG86 cD48L286cD48L3ByZT4NCjxwcmU+VGhlIFNOSSB3YXMgZGVmaW5lZCB0byBmYWNpbGl0YXRlIHNl Y3VyZSBjb25uZWN0aW9ucyB0byBzZXJ2ZXJzIHRoYXQgaG9zdDxvOnA+PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cHJlPm11bHRpcGxlICd2aXJ0dWFsJyBzZXJ2ZXJzIGF0IGEgc2luZ2xl IHVuZGVybHlpbmcgbmV0d29yayBhZGRyZXNzIFtSRkMzNTQ2XS48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5Ib3dldmVyLCBhZGRpdGlvbiBtYW5hZ2VtZW50IGFuZCBzZWN1cml0eSBwcmFjdGljZXMg ZW1lcmdlZCBtYWtpbmcgdXNlPG86cD48L286cD48L3ByZT4NCjxwcmU+b2YgdGhpcyBpbmZvcm1h dGlvbi4mbmJzcDsgRXhhbXBsZXMgb2Ygc3VjaCB1c2FnZSBhcmUgcmV2aWV3ZWQgaW4gW1JGQzg0 MDRdLjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+VGhpcyBsYW5ndWFnZSB3b3VsZCBsZXQgeW91IGRpc3Rpbmd1aXNoIGFsbCBvZiB0aGUgbWlk ZGxlIGJveCBiZWhhdmlvcnM8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5k b25lIGJ5IG9wZXJhdG9ycyBhbmQgZW50ZXJwcmlzZXMgZnJvbSBhIHBvc3NpYmxlIFtSRkM3MjU4 XSBhdHRhY2tlci48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5BcyBJIG5vdGVkIGluIG15IHJlcGx5IHRvIEJlbiwgSSBk b24ndCBmb2xsb3cgdGhlIGN1cnJlbnQgbGFuZ3VhZ2UgZm9yIGFudGljaXBhdGVkL3VuYW50aWNp cGF0ZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy90bHMvNTRj RXBqVWNJWnFOV195N0ViMzQ0WExRcDBZIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2Fy Y2gvbXNnL3Rscy81NGNFcGpVY0lacU5XX3k3RWIzNDRYTFFwMFk8L2E+PG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4tLSBSRkM4NDA0 IGRlc2NyaWJlcyBhIG51bWJlciBvZiBtaWRkbGVib3ggcHJhY3RpY2VzLCBidXQgb25seTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT42LjIgZXhw bGljaXRseSBkaXNjdXNzZXMgU05JLCBhbmQgb2YgdGhlIGV4YW1wbGVzIGxpc3QgaGVyZSwgb25s eTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9uZSBjb21lcyBmcm9tIFJGQzg0MDQuPG86cD48L286 cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+QSBmZXcgb2YgdGhlIGV4YW1wbGVzIGFsc28g Y29tZSBpbiB0aGUgJnF1b3Q7ZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiZxdW90OzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnNlY3Rpb25zIG9mIDg0MDQuIEJ1dCByYXRoZXIgdGhhbiBnb2luZyBpbiBh IGxvbmcgZGlzY3Vzc2lvbiwgSSB3b3VsZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJhdGhlciBy ZXdyaXRlIHRoZSBzZW50ZW5jZSBhczogTWFueSBleGFtcGxlcyBvZiBzdWNoIHVzYWdlIGFyZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJldmlld2VkIGluIFtAP1JGQzg0MDRdLCBvdGhlciBleGFt cGxlcyBjYW1lIG91dCBkdXJpbmcgZGlzY3Vzc2lvbnMgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT50aGlzIGRyYWZ0LjxvOnA+PC9vOnA+PC9w cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRo ZSAtMDcgdGV4dCB3b3JrcyBmb3IgbWUuJm5ic3A7IFRoYW5rcy48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPioqIFNlY3Rpb24gMi4x LiBUaGUg4oCcbW9uaXRvcmluZyBhbmQgaWRlbnRpZmljYXRpb24gb2Ygc3BlY2lmaWMgc2l0ZXPi gJ08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pc27igJl0IHN5bW1ldHJpYyB0byB0aGUgb3RoZXIg ZXhhbXBsZXMg4oCTIGl0IGlzIHJhdGhlciBnZW5lcmljLiZuYnNwOyBUaGU8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5vdGhlciBleGFtcGxlcywgaWRlbnRpZnkgYSB3aGF0L3dobyAoZS5nLiwgSVNQ LCBmaXJld2FsbCkgJiM0MzsgYWN0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+KGUuZy4sPG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+YmxvY2ssIGZpbHRlcikuPG86cD48 L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZT5BbHNvLCB0byBpbXBsZW1lbnQgbW9zdCBvZiB0aGUgb3RoZXIg ZXhhbXBsZSwg4oCcbW9uaXRvcmluZyBhbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGlm aWNhdGlvbiBvZiBzcGVjaWZpYyBzaXRlc+KAnSBuZWVkcyB0byBiZSBkb25lLjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkkgc3RpbGwgdGhpbmsg dGhpcyBuZWVkcyB0byBiZSBjbGVhbmVkIHVwIGluIHNvbWUgd2F5LiZuYnNwOyBJTU8sIEknZCBk cm9wIGl0LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPldhcyByZXdyaXR0ZW4gaW4gbmV3IHNlY3Rpb24gMi4xIGFzICZx dW90O0ZpbHRlcmluZyBvciBjZW5zb3JzaGlwIG9mIHNwZWNpZmljPG86cD48L286cD48L3ByZT4N CjxwcmU+c2VydmljZXMgZm9yIGEgdmFyaWV0eSBvZiByZWFzb25zLiZxdW90OzxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PkknbSBzdGlsbCBzdHJ1Z2dsaW5nIHdpdGggdGhlIHNwZWNpZmljaXR5IGhlcmUgYW5kIHRoZSBv dmVybGFwLiZuYnNwOyBEcm9wcGluZyB0aGUgY2Vuc29yc2hpcCBhbmQgaXQgcmVhZHMgJnF1b3Q7 ZmlsdGVyaW5nIG9mIHNwZWNpZmljIHNlcnZpY2VzIGZvciBhIHZhcmlldHkgb2YgcmVhc29ucyZx dW90Oy4mbmJzcDsgVGhhdCdzIGV4YWN0bHkgd2hhdCBidWxsZXQgMiAoY29udGVudCBmaWx0ZXJp bmcgYnkgb3BlcmF0b3JzKSBhbmQgYnVsbGV0IDMgKGVudGVycHJpc2UgZmlyZXdhbGxzIGZvciBO U0ZXKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PldoYXQncyB1bmlxdWUgYWJvdXQgdGhpcyBidWxsZXQgLS0gaXMgaXQgd2hvIGlzIGRvaW5nIHRo aXMgZmlsdGVyL2NlbnNvcnNoaXA/IHdoZXJlIGl0IGlzIGhhcHBlbmluZz8gV2hhdCB0ZWNoIGlz IGJlaW5nIHVzZWQ/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPkZvciBleGFt cGxlLCBhcmJpdHJhcnkgZmlsdGVyaW5nIG9mIHdlYiBzaXRlcyBjb21wZXRpbmcgd2l0aCBvdGhl ciBzZXJ2aWNlcyBwcmVmZXJyZWQgYnkgdGhlIG5ldHdvcmsgcHJvdmlkZXIuJm5ic3A7IFNvbWUg ZmlsdGVyaW5nIGFuZCBjZW5zb3JzaGlwIGlzIG1vcmUgY29udHJvdmVyc2lhbCB0aGFuIG90aGVy cy4gQnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCBsaXN0aW5nIGV2ZXJ5IGNvbnRyb3ZlcnNpYWwgdXNh Z2Ugd291bGQgYmUgYXBwcm9wcmlhdGUuDQogSSB3b3VsZCByYXRoZXIga2VlcCB0aGUgc29tZXdo YXQgdmFndWUgcGhyYXNpbmcgdGhhbiB0cnkgdG8gaGF2ZSBhIGRlYmF0ZSBhYm91dCB3aGljaCBw cmFjdGljZSBpcyBjb250cm92ZXJzaWFsIGFuZCB3aGljaCBpcyBub3QuPG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JvbWFuXSZuYnNwOyBVbmRlcnN0 b29kLiZuYnNwOyBQb2ludCBtYWRlLiZuYnNwOyBUaGUgdGV4dCBpcyBuZXV0cmFsIGVub3VnaCBm b3IgbWUgbm93LCBhbmQgSSB3b27igJl0IHB1c2ggZnVydGhlciAoZm9yIGVkaXRvcmlhbCBjbGFy aXR5KS4mbmJzcDsgVGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4uLi48bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl PioqIFNlY3Rpb24gMi4xLiZuYnNwOyBQZXIg4oCcVGhlIFNOSSBpcyBwcm9iYWJseSBhbHNvIGlu Y2x1ZGVkIGluIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmdlbmVyYWwgY29sbGVjdGlvbiBv ZiBtZXRhZGF0YSBieSBwZXJ2YXNpdmUgc3VydmVpbGxhbmNlIGFjdG9yc+KAnSwgSTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPnJlY29tbWVuZCBhZ2FpbnN0IHNwZWN1bGF0aW9uIGFuZCBpbnN0ZWFk IHNpbXBseSBzdGF0aW5nIHRoYXQgU05JPG86cD48L286cD48L3ByZT4NCjxwcmU+d291bGQgYmUg aW50ZXJlc3RpbmcgbWV0YS1kYXRhIGZvciBhIFJGQzcyNTggYXR0YWNrZXIuPG86cD48L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+WWVzLCBNaXJqYSBtYWRlIGEgc2ltaWxhciBjb21t ZW50LiBQcm9wb3NlZCByZXBsYWNlbWVudDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgU05JIGlzIHByb2JhYmx5IGFsc28gaW5jbHVkZWQg aW4gdGhlIGdlbmVyYWwgY29sbGVjdGlvbiBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1ldGFk YXRhIGJ5IHBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2UgYWN0b3JzLCBmb3IgZXhhbXBsZSB0byBpZGVu dGlmeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZpY2VzIHVzZWQgYnkgc3VydmVpbGxhbmNl IHRhcmdldHMuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SU1PLCBleHBs aWNpdGx5IGxpbmtpbmcgaXQgdG8gdGhlIGRyYWZ0IHdvdWxkIGhlbHAuPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T0xEOjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPlRoZSBTTkkgaXMgcHJvYmFibHkgYWxzbyBpbmNsdWRlZCBpbiB0aGUgZ2VuZXJh bCBjb2xsZWN0aW9uIG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+bWV0YWRhdGEgYnkgcGVydmFz aXZlIHN1cnZlaWxsYW5jZSBhY3RvcnMsIGZvciBleGFtcGxlIHRvIGlkZW50aWZ5PG86cD48L286 cD48L3ByZT4NCjxwcmU+c2VydmljZXMgdXNlZCBieSBzdXJ2ZWlsbGFuY2UgdGFyZ2V0cy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5ORVc6PG86 cD48L286cD48L3ByZT4NCjxwcmU+VGhlIFNOSSBjb3VsZCBiZSBpbmNsdWRlZCBpbiB0aGUgZ2Vu ZXJhbCBjb2xsZWN0aW9uIG9mIG1ldGFkYXRhIGJ5PG86cD48L286cD48L3ByZT4NCjxwcmU+cGVy dmFzaXZlIG1vbml0b3JpbmcgYXR0YWNrZXIgW1JGQzcyNThdLCBmb3IgZXhhbXBsZSB0byBpZGVu dGlmeTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZpY2VzIHVzZWQgYnkgc3VydmVpbGxhbmNl IHRhcmdldHMuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+SSBtaXNzZWQgdGhlIHJlZmVyZW5jZSB0byA3MjU4LiBXaWxs IGFkZCBpdCBpbiB0aGUgbmV4dCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlJlY29tbWVuZCBhZGRpbmcg dGhlIFJGQzcyNTggcmVmZXJlbmNlLiZuYnNwOyBBcyBJIG5vdGVkIGFib3ZlLCB0aGUgc2VtYW50 aWNzIG9mICZxdW90O3Byb2JhYmx5JnF1b3Q7IHZzLiAmcXVvdDtjb3VsZCZxdW90Oy4mbmJzcDsg JnF1b3Q7cHJvYmFibHkmcXVvdDsgc3VnZ2VzdHMgYSBjb25maWRlbmNlIHRvIG1lLjxvOnA+PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5ZZXMsIHRoZXJlIGlzIHNvbWUgY29uZmlkZW5j ZSwgYmFzZWQgb24gdGhlIFNub3dkZW4gcmV2ZWxhdGlvbiBvZiBzeXN0ZW1zIGxpa2UgUXVhbnR1 bSBJbnNlcnQsIGNvbW1lbnRzIGxpa2UgJnF1b3Q7cmVjb3JkaW5nIHRoZSB3aG9sZSBoYXlzdGFj ayZxdW90Oywgb3IgdGhlIEtvcmVhbiByZWd1bGF0aW9uIGV4cGxpY2l0bHkgdGFyZ2V0aW5nIHRo ZSBTTkkgZmllbGQuIEl0IGlzIG1vcmUgcHJvYmFibGUgdGhhbiBub3QgdGhhdCBTTkkgZGF0YSBp cyBiZWluZw0KIHJlY29yZGVkLCBhbmQgSSB0aGluayB0aGF0ICZxdW90O3Byb2JhYmx5JnF1b3Q7 IGlzIGp1c3QgZmluZS48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5bUm9tYW5dIEkgY2FuIGxpdmUgd2l0aCBqdXN0IHRoZSBSRkM3MjU4IHJlZmVyZW5j ZS4mbmJzcDsgVGhhbmtzIGZvciBhZGRpbmcgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZT4qKiBTZWN0aW9uIDIuMi4mbmJzcDsgUGVyIOKAnE9uZSByZWFzb24gbWF5 IGJlIHRoYXQsIHdoZW4gdGhlc2UgUkZDcyB3ZXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+d3Jp dHRlbiwgdGhlIFNOSSBpbmZvcm1hdGlvbiB3YXMgYXZhaWxhYmxlIHRocm91Z2ggYSB2YXJpZXR5 IG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+b3RoZXIgbWVhbnPigJ0sIHdoYXQgd291bGQgdGhv c2Ug4oCcb3RoZXIgbWVhbnPigJ0gYmU/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwcmU+VGhlIGxpc3QgaW5jbHVkZXMgYXQgYSBtaW5pbXVtOjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNsZWFyIHRleHQgZXhjaGFuZ2VzIGFt ZW5hYmxlIHRvIGRlZXAgcGFja2V0IGluc3BlY3Rpb24gKERQSSksIHNlcnZlcjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmNlcnRpZmljYXRlcyBzZW5kIGluIGNsZWFyIHRleHQgZHVyaW5nIFRMUy9T U0wgZXhjaGFuZ2VzLCBETlMgbmFtZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vZiBzZXJ2ZXJz IGluIGNsZWFyIHRleHQgRE5TIHF1ZXJpZXMsIGFuZCBzZXJ2ZXIgc3BlY2lmaWMgSVA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5hZGRyZXNzZXMgaW4gcGFja2V0IGhlYWRlcnMuPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBndWVzcyBJIGNvdWxk IHdyaXRlIHRoYXQgYWxsLCBidXQgaXQgbWFrZXMgdGhlIHRleHQgYSBiaXQ8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5yZWR1bmRhbnQsIHNpbmNlIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBocyBkbyBk aXNjdXNzIHNlcnZlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNlcnRpZmljYXRlcywgRE5TIG5h bWVzIGFuZCBJUCBhZGRyZXNzZXMuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw cmU+SSB1bmRlcnN0YW5kLiZuYnNwOyBJIGRpZG4ndCByZWFkIGl0IHRoYXQgd2F5LiZuYnNwOyBN eSByZWNvbW1lbmRhdGlvbiBpc24ndCB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cHJlPmRlc2NyaWJlIHRoZSAmcXVvdDtvdGhlciBtZWFucyZxdW90OyAoYXMgaXQgaXMgZGVz Y3JpYmVkIGJlbG93KSwgYnV0IHRvIGJlIGNsZWFyIG9uIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPm9idmlvdXMsIHdoYXQgaXMgdGhlIFNOSSBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvcHJl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk9MRDo8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PbmUgcmVhc29uIG1heSBiZSB0aGF0LCB3aGVuIHRoZXNlIFJGQ3Mgd2VyZSB3 cml0dGVuLCB0aGUgU05JPG86cD48L286cD48L3ByZT4NCjxwcmU+aW5mb3JtYXRpb24gd2FzIGF2 YWlsYWJsZSB0aHJvdWdoIGEgdmFyaWV0eSBvZiBvdGhlciBtZWFucy48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5ORVc6PG86cD48L286cD48L3By ZT4NCjxwcmU+T25lIHJlYXNvbiBtYXkgYmUgdGhhdCB3aGVuIHRoZSBSRkNzIHdlcmUgd3JpdHRl biwgdGhlIG5hbWUgb2YgdGhlPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+ c2VydmVyIHRoZSBiZWluZyBjb250YWN0ZWQgYnkgdGhlIGNsaWVudCAoaS5lLiwgdGhlIFNOSSkg d2FzIGV2aWRlbnQgdGhyb3VnaDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm90aGVyIG1lYW5zLjxv OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPlRoZSBuZXcgdGV4dCBpbiAtMDcgcmVhZHMgbW9yZSBjbGVhcmx5IHRvIG1lLiZu YnNwOyBUaGFua3MgZm9yIHRoaXMgY2hhbmdlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KiogU2VjdGlvbiAyLjMuJm5ic3A7IFBl ciDigJxEZXBsb3lpbmcgU05JIGVuY3J5cHRpb24gd2lsbCBoZWxwIHRod2FydGluZzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPm1vc3Qgb2Y8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHByZT50aGU8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPuKAmHVuYW50aWNpcGF0ZWTigJkgU05J IHVzYWdlcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEsIGluY2x1ZGluZzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmNlbnNvcnNoaXA8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy ZT5hbmQ8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPnBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2Uu4oCd OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0t IFdoeSB0aGUgcXVvdGVzIGFyb3VuZCAmcXVvdDt1bmFudGljaXBhdGVkJnF1b3Q7IFNOSSB1c2Fn ZT88bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5SZW1vdmluZyB0aGUgcXVv dGVzLiBPdGhlcndpc2UsIHlvdSB3aWxsIGJlIGNvbnZpbmNlZCB0aGF0IHRoZTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmF1dGhvcnMgYmVsaWV2ZSB0aGF0IGFsbCBtaWRkbGUtYm94ZXMgYXJlIHRo ZSBzcGF3biBvZiB0aGUgZGV2aWwuLi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHByZT5UaGFua3MuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cHJlPi0tIE9uZSBwZXJzb27igJlzIGNlbnNvcnNoaXAgaXMgYW5vdGhlciBwZXJz b27igJlzIHRocmVhdCBtaXRpZ2F0aW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBvbGljeSBl bmZvcmNlbWVudCBmb3IgYSBuZXR3b3JrIHRoZXkgb3duLCBvciBwYXJlbnRhbCBjb250cm9scyAo cGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIGxpc3QgaW4gU2VjdGlvbiAyLjEpIOKAkyBy ZWNvbW1lbmQgYmVpbmcgbW9yZSBwcmVjaXNlIG9uIHRoZSBvcmRlcjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPm9mIOKAnERlcGxveWluZzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cHJlPlNOSTxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+ZW5jcnlwdGlvbiB3aWxsIHticmVhayB8 IHJlZHVjZSB0aGUgZWZmaWNhY3kgb2YgfSB0aGUgb3BlcmF0aW9uYWw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5wcmFjdGljZXM8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5h bmQ8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPnRlY2huaXF1ZXMgdXNlZCBpbiBtaWRkbGVib3hl cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjHigJ0uPG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjxwcmU+T0suIEkgd2lsbCB0cnkgdG8gbWFrZSB0aGUgdGV4dCBqdXN0IHN0aWNrIHRv IHRoZSBmYWN0czo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5EZXBsb3lpbmcgU05JIGVuY3J5cHRpb24gdGh3YXJ0cyBtb3N0IG9mIHRoZSB1bmFu dGljaXBhdGVkIFNOSSB1c2FnZXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5kZXNjcmliZWQgaW4g KCNzbmlsZWFrKS4gSXQgcmVkdWNlcyB0aGUgZWZmaWNhY3kgb2YgdGhlIG9wZXJhdGlvbmFsPG86 cD48L286cD48L3ByZT4NCjxwcmU+cHJhY3RpY2VzIGFuZCB0ZWNobmlxdWVzIGltcGxlbWVudCBp biBtaWRkbGUtYm94ZXMuIE1vc3Qgb2YgdGhlc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5mdW5j dGlvbnMgY2FuLCBob3dldmVyLCBiZSByZWFsaXplZCBieSBvdGhlciBtZWFucy48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGFua3MgZm9yIHRoaXMuPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPldvcmtzIGZv ciBtZS4mbmJzcDsgSG93ZXZlciwgSSdkIGRyb3AgJnF1b3Q7TW9zdCBvZiB0aGVzZSBmdW5jdGlv bnMgY2FuLCBob3dldmVyLDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmJl IHJlYWxpemVkIGJ5IG90aGVyIG1lYW5zJnF1b3Q7IGJlY2F1c2UgdGhpcyBvcGVucyB0aGUgZGVi YXRlIG9uIGhvdyBleGFjdGx5LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV0Yy48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT5JIHN0aWxsIHJlY29tbWVuZCBkcm9wcGluZyB0aGUgJnF1b3Q7b3RoZXIgbWVhbnMmcXVvdDsg dGV4dCBiZWNhdXNlIHRoYXQgb3BlbnMgZGViYXRlLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+KiogU2VjdGlvbiAyLjMuJm5ic3A7 IFBlciDigJxJdCB3aWxsIGFsc28gdGh3YXJ0IGZ1bmN0aW9ucyB0aGF0IGFyZTxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnNvbWV0aW1lcyBkZXNjcmliZWQgYXMgbGVnaXRpbWF0ZeKAnSwgd2hhdCBm dW5jdGlvbnMgYXJlIHRob3NlPyZuYnNwOyBJ4oCZZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJl Y29tbWVuZDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmVsaW1pbmF0aW5n PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT50aGlzIHNlbnRlbmNlIGFzIGl0IHJlYWRzIGxpa2Ug YSB2YWx1ZSBqdWRnZW1lbnQgb24gZXhpc3Rpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wcmFj dGljZXMgKHdoaWNoIGRvZXNu4oCZdCBzZWVtIGdlcm1hbmUgZm9yIGRpc2N1c3NpbmcgcmVxdWly ZW1lbnRzKS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5Ob3cgdGhhdCBjZW5zb3JzaGlwIGdvdCBhZGRlZCB0byB0aGUgbGlzdCBpbiBTZWN0 aW9uIDIuMSwgeW91IGxpa2VseSB3YW50IHRvOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPnMvaW5jbHVkaW5nIGNlbnNvcnNoaXAgYW5kIHBlcnZh c2l2ZSBzdXJ2ZWlsbGFuY2UvaW5jbHVkaW5nIHBlcnZhc2l2ZSBzdXJ2ZWlsbGFuY2UvPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T3RoZXJ3aXNl LCBMR1RNLiZuYnNwOyBUaGFua3MuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw Pk9LLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl Pi4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4uLi4gPG86cD48L286 cD48L3A+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+JnF1b3Q7VGhpcyBk b2N1bWVudCBkb2VzIG5vdCBwcmVzZW50IHRoZSBkZXNpZ24gb2YgYSBzb2x1dGlvbiwgYnV0IHBy b3ZpZGVzPG86cD48L286cD48L3ByZT4NCjxwcmU+Z3VpZGVsaW5lcyBmb3IgZXZhbHVhdGluZyBw cm9wb3NlZCBzb2x1dGlvbnMuJnF1b3Q7Jm5ic3A7IEhvd2V2ZXIsIHRoZSBjdXJyZW50IHRleHQg aW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZWN0aW9uIDQgaXMgZXhwbGljaXRseSBzdGF0ZXMg aXQgaXMgcHJvdmlkaW5nIGEgc29sdXRpb24uJm5ic3A7IFRoZSBzdWItc2VjdGlvbiBvZjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb24gNC54IGFzc3VtZSB0aGUgc29sdXRpb24gaW4gU2Vj dGlvbiA0LjAgYW5kIGRlc2NyaWJlIHRoZSBmb2xsb3ctb248bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT53b3JrLiZuYnNwOyBTZWN0aW9uIDIgLSAzIGRvIGxheSBvdXQgdGhlIG1lYW5zIGZvciBldmFs dWF0aW9uIG5pY2VseS4mbmJzcDsgUGVyaGFwcyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zb21l dGhpbmcgb24gdGhlIG9yZGVyIG9mOjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+T0xEOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMgZG9j dW1lbnQgZG9lcyBub3QgcHJlc2VudCB0aGUgZGVzaWduIG9mIGEgc29sdXRpb24sIGJ1dCBwcm92 aWRlczxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmd1aWRlbGluZXMgZm9y IGV2YWx1YXRpbmcgcHJvcG9zZWQgc29sdXRpb25zLjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+TkVXOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PlRoaXMgcHJvdmlkZXMgZ3VpZGVsaW5lcyBvbiBldmFsdWF0aW5nIHNvbHV0aW9uIGFuZCBwcm9w b3NlcyBhbjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmFyY2hpdGVjdHVy ZSB0byBtaXRpZ2F0ZSB0aGUgdGhyZWF0cyBjcmVhdGVkIGJ5IGFuIHVuZW5jcnlwdGVkIFNOSSB1 c2luZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmV4aXN0aW5nIGFwcHJvYWNoZXMuPG86cD48L286 cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmU+SSBhZGRlZCB0aGUgcmVmZXJlbmNlIHRvIGEgcGFwZXIgYnkgRmlm aWVkIGV0IGFsLiB0aGF0IGRlc2NyaWJlcyB0aGUgJnF1b3Q7ZG9tYWluPG86cD48L286cD48L3By ZT4NCjxwcmU+ZnJvbnRpbmcmcXVvdDsgc29sdXRpb24gYW5kIHNvbWUgb2YgaXRzIGRlcGxveW1l bnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPk5vdGUg dGhhdCB0aGUgaW50ZW50IGlzIG5vdCB0byByZWNvbW1lbmQgdGhlIGRvbWFpbiBmcm9udGluZyBz b2x1dGlvbi4gVGhhdCBzb2x1dGlvbiwgYW5kIHRoZSBIVFRQUyB0dW5uZWwgc29sdXRpb24sIGFy ZSBleGFtaW5lZCBhcyBleGFtcGxlIG9mIHByb3Bvc2VkIHNvbHV0aW9ucyB0aGF0IG1lZXQgc29t ZSBvZiB0aGUgcmVxdWlyZW1lbnQgYnV0IG5vdCBhbGwuIEJ1dCBJIHVuZGVyc3RhbmQNCiB0aGF0 IHlvdSBwZXJjZWl2ZWQgdGhlIHRleHQgYXMgc29tZSBraW5kIG9mIGVuZG9yc2VtZW50LjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1JvbWFuXSZuYnNwOyBSaWdodCwgYnV0IEkgYWxzbyB0 aGluayB0aGUgY2l0YXRpb24gaGVscHMgdGhhdCB5b3XigJlyZSBkZXNjcmliaW5nIGFuIGV4aXN0 aW5nIHByYWN0aWNlLiZuYnNwOyBUaGUgbmV3IGxhbmd1YWdlIGluIGFkZGVkIGluDQo8YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvc25pZW5jcnlwdGlvbi9wdWxsLzQ2L2ZpbGVzIj5o dHRwczovL2dpdGh1Yi5jb20vdGxzd2cvc25pZW5jcnlwdGlvbi9wdWxsLzQ2L2ZpbGVzPC9hPiB3 b3JrcyBmb3IgbWUuJm5ic3A7IFRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy ZT4uLi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5EcmFmdCAwNyBhZGRlZCB0ZXh0IGRlc2NyaWJp bmcgYWN0dWFsIGRlcGxveW1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSB1c2Ugb2YgdGhlIFtkb21mcm9u dF0gY2l0YXRpb24gd29ya3MgZm9yIG1lIGFuZCBhZGRyZXNzZXMgbXkgY29uY2VybnMuJm5ic3A7 IFR3byBuaXRzOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPioqIEknZCByZWNvbW1lbmQgdXNpbmcgdGhlIFVSTCB0byB0aGUgcGFwZXIgZnJvbSBj b25mZXJlbmNlIHNpdGUgaXRzZWxmOiA8YSBocmVmPSJodHRwczovL3BldHN5bXBvc2l1bS5vcmcv MjAxNS9wYXBlcnMvMDNfRmlmaWVsZC5wZGYiPmh0dHBzOi8vcGV0c3ltcG9zaXVtLm9yZy8yMDE1 L3BhcGVycy8wM19GaWZpZWxkLnBkZjwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0suPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+KiogSSdkIGFsc28gcmVjb21tZW5kIGFkZGluZyBhIHNlbnRlbmNlIHRvIHRoZSBs YXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDEsICZxdW90O1RoaXMgZG9jdW1lbnQgZG9lcyBub3Qg cHJlc2VudCB0aGUgZGVzaWduIC4uLiZxdW90OywgdG8gZm9yZXNoYWRvdyB0aGF0IHlvdSdsbCBk aXNjdXNzIGFuIGFsdGVybmF0aXZlIGFwcHJvYWNoIGV2ZW4gaWYgZW5jcnlwdGVkIFNOSSBpc24n dCByZWFsaXplZCB5ZXQuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPk9LLCB3 aWxsIHRyeSBtYWtlIGNsZWFyIHRoYXQgdGhpcyBpcyBub3QgYW4gZW5kb3JzZW1lbnQgb3IgYSBw cm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5bUm9tYW5dIEkgdGhpbmsgeW91IGhhdmUgaXQgY292ZXJlZCBpbiB0aGUgbmV3IGxhbmd1YWdl IGluDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvc25pZW5jcnlwdGlvbi9wdWxs LzQ2L2ZpbGVzIj5odHRwczovL2dpdGh1Yi5jb20vdGxzd2cvc25pZW5jcnlwdGlvbi9wdWxsLzQ2 L2ZpbGVzPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9tYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD4tLSBD aHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_359EC4B99E040048A7131E0F4E113AFC01B347B31Amarathon_-- From nobody Mon Oct 7 13:13:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9709120046; Mon, 7 Oct 2019 13:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 rymE6M7GGpcu; Mon, 7 Oct 2019 13:13:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3C571201C6; Mon, 7 Oct 2019 13:12:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D3044BE20; Mon, 7 Oct 2019 21:12:46 +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 2XdHtwpikccQ; Mon, 7 Oct 2019 21:12:45 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 45804BDCF; Mon, 7 Oct 2019 21:12:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1570479165; bh=BvazihnKFhiFLCUwtTMohUuEQt68ytv0sC+1veUg7+4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=m1MEpAD2MN8STlfLYlJeey5yTcpRAwMiS83IL1FxwTxWQPfSrcKhdCKWiThwfvZWV yPNydwBALhkOlqZmiJGwbXrJoJWKd0cdKsnUV5D8uTlmT8LfBfvf8aLrCdPvYHGbjh jhLbkcWU6MW2SVgrIHwe8a7FdWywAIpCdLpgbNQI= To: Rob Sayre , Eric Rescorla Cc: Benjamin Kaduk , Sean Turner via Datatracker , John Mattsson , "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> Date: Mon, 7 Oct 2019 21:12:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sPXKNVaAM2VvqiNM1II0Vlfd8RKaQ0lID" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Mon, 07 Oct 2019 20:13:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sPXKNVaAM2VvqiNM1II0Vlfd8RKaQ0lID Content-Type: multipart/mixed; boundary="oWdBykmgYhl9wO9tFiiR3inZqd3MSq0S0"; protected-headers="v1" From: Stephen Farrell To: Rob Sayre , Eric Rescorla Cc: Benjamin Kaduk , Sean Turner via Datatracker , John Mattsson , "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" Message-ID: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: --oWdBykmgYhl9wO9tFiiR3inZqd3MSq0S0 Content-Type: multipart/mixed; boundary="------------7086F2D8614B0993871C6B2A" Content-Language: en-GB This is a multi-part message in MIME format. --------------7086F2D8614B0993871C6B2A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 07/10/2019 18:29, Rob Sayre wrote: > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell > wrote: >> we can't "UPDATE" an I-D. > > Not true. If you need to refer to something that's been IESG-approved b= ut > still in the RFC queue, you can leave a note for the RFC editor to upda= te > the reference to the eventual RFC number. That would be an UPDATE on the eventual RFC and not on the I-D. And in this case, it'd IMO not be a good plan as a) the relevant WG didn't want that, b) the I-D in question is part of a mega-cluster, so any dependency on it (as you suggest) risks loadsa delay if the cluster doesn't get unstuck, which can happen and c) our draft already stretches the header enough updating 85 RFCs - trying to add an I-D to that list would break tools and cause much pointless process-angst. Mostly (a) is the reason to not do it though. If you want to disagree with (a), then the right list for that would be the rtcweb list I guess, even though the WG is now concluded (which could, I guess, be (d);-) Overall, the cost isn't worth the benefit IMO. Cheers, S. --------------7086F2D8614B0993871C6B2A 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----- --------------7086F2D8614B0993871C6B2A-- --oWdBykmgYhl9wO9tFiiR3inZqd3MSq0S0-- --sPXKNVaAM2VvqiNM1II0Vlfd8RKaQ0lID Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2bnDwACgkQWrL68XsX K+q3whAAqHdCaBlZNYVtEsFFV+aRo3aXijeB2ecjhfvC+k60jIs1r/BZUd/UU3R8 e+/CuqqWw/CmKwNnBo7Xj99muufwyIyfoLhBOxA3lPlxY3zx0pqQFxIm+VjyTp8/ IX4B3PFvtbJjBoYpzA+QH9QvALt9MTFQh6Zt5yAZG+Qrj6lyMxP66yMBnBidyeYs 5jrG63zjt9AjMBkRJd1c4yQquhS/bwuIhCUumkwH3sE+FDtnvz42D63SZBOW5WpS Hxr5nVFkhGEOCVeqgVV1os7I0oILh4XAA6axVUgTABLWJ7TTpGRqcClLVHZvjTjz 3FMhwnWDiZhhn0rqVTDNfVs1TdT9Gev8JfcHHszkkGr/1nO/MbCDUE5LLihTDqIr Bnerr+Cj9Ryhf+F7XFdZHX/fwvRTERBKAspQbNOwWLV7AIIRNQE86pLGcBt1i2uW O29aori6W4W9PvKYMAuEV8aLdd2Ac/YLZJUHmqpwg7SIJghvJjZhVQNgeLZ+JlNq pricGmkeBRx8PSk3WpzeehzPCD9N+4WYf/odPC4jgvwK/tP/JNlh8YIdxMMnlloV dqHFmqgLaXZx2/7AekKzse13oEv7KReMG2PQ3JMWIKY+BGkVnDomh1ZniYdpZMe7 Ge59L0WqMuTmyw8pUW+xp4hpR2tmBBqbmETQ3MF7cq1YoWmHkWg= =hWtX -----END PGP SIGNATURE----- --sPXKNVaAM2VvqiNM1II0Vlfd8RKaQ0lID-- From nobody Mon Oct 7 13:56:36 2019 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 09633120020; Mon, 7 Oct 2019 13:56:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157048178892.4743.5417505225884589066@ietfa.amsl.com> Date: Mon, 07 Oct 2019 13:56:29 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-08.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: Mon, 07 Oct 2019 20:56:29 -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 : Issues and Requirements for SNI Encryption in TLS Authors : Christian Huitema Eric Rescorla Filename : draft-ietf-tls-sni-encryption-08.txt Pages : 14 Date : 2019-10-07 Abstract: This draft 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. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-08 https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-08 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 Mon Oct 7 13:57:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5436312010C for ; Mon, 7 Oct 2019 13:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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 xE4d85sV1dQJ for ; Mon, 7 Oct 2019 13:57:31 -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 26837120909 for ; Mon, 7 Oct 2019 13:57:31 -0700 (PDT) Received: from xse439.mail2web.com ([66.113.197.185] helo=xse.mail2web.com) by mx35.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iHa4L-0005dL-Lx for tls@ietf.org; Mon, 07 Oct 2019 22:57:28 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46nCTt6kSlzrx8 for ; Mon, 7 Oct 2019 13:57:22 -0700 (PDT) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iHa4I-0006bs-PH for tls@ietf.org; Mon, 07 Oct 2019 13:57:22 -0700 Received: (qmail 26636 invoked from network); 7 Oct 2019 20:57:22 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Oct 2019 20:57:22 -0000 To: Roman Danyliw , The IESG Cc: "draft-ietf-tls-sni-encryption@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" References: <156881761812.4630.11745895149419124830.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3467E89@marathon> <81e39835-82e7-03c7-feaf-33980629986c@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B346A4D0@marathon> <2efdf56d-2846-a08e-2b2d-aa0703281b18@huitema.net> <359EC4B99E040048A7131E0F4E113AFC01B347B31A@marathon> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <58f6bc3e-7ab9-5d7b-c82a-3bff73b42c2c@huitema.net> Date: Mon, 7 Oct 2019 13:57:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B347B31A@marathon> Content-Type: multipart/alternative; boundary="------------E64FE887C1FC362B01F74124" Content-Language: en-US X-Originating-IP: 66.113.197.185 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/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4ahK8DVh4lJUxNaI5QkrfIkgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+celWigidmUBfpu1oPmNJeGmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdGd9U9Oojh2QY0MMPWjRsTVhMmX9VvKuj6psZloQqgYBwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPm2wrFQSzUyjM lP3fg3yMYvfCDpUQOiZ6EGidJUqXhcEF2ElKuz9RzupplPoARiNxjAeYUOp7A73HI6oJg7w/VocK FIxNlsy2WJpil5s07kEDyBw3j/aBxjxoZyMqfIL/jJq7xqDoiTjjGpNS1XGXbXKoKce5OCcmnXyB bZGwx3bzAztqzrCt4TZ/wLtujY/tpeaoe6wPyFQzYOf2yDDY1H4NeQEoO561gIA/qCUU5zrkPAlb DjazCbhs7qBpykynMha5/rijjcguRYfyvX/qs6AD7aMSznt5euQNs/W8G07C83g9ueTJOU6a76yp yxjdeg8YhWenlMfuvb1mNY5/IPiuedK/Z3MvnAyDmuOaA5CGZRWsGw8ac2InzcAP/gmxwNpms+rB 6wJM+NNhN3aT35NSU/fjw6KbqLw80r1gDO3m6U0LjBzYuQztdAThgtWSU3qCINKqlAdh+ePAcEwD s/8= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2019 20:57:38 -0000 This is a multi-part message in MIME format. --------------E64FE887C1FC362B01F74124 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Thanks, Roman. I have submitted draft-08 with the changes. On 10/7/2019 12:07 PM, Roman Danyliw wrote: > > Hi Christian! > >   > > Thanks for all of the iteration and updates.  Given what’s proposed in > github (https://github.com/tlswg/sniencryption/pull/46/files), > consider my comments resolved.  Minor comments inline … > >   > > *From:*Christian Huitema [mailto:huitema@huitema.net] > *Sent:* Thursday, September 26, 2019 6:53 PM > *To:* Roman Danyliw ; The IESG > *Cc:* draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org; > tls@ietf.org > *Subject:* Re: [TLS] Roman Danyliw's No Objection on > draft-ietf-tls-sni-encryption-05: (with COMMENT) > >   > >   > > On 9/26/2019 11:38 AM, Roman Danyliw wrote: > > Hi Christian! > >   > > Thanks for all of the updates.  I have a remaining items are described inline. > >   > > To bring up a new item, there was new text introduced in -06 of Section 5 to which I strongly object.  Specifically: > >   > > "Replacing clear text SNI transmission by an encrypted variant will    > > also thwart MITM interferences that are sometimes described as > > legitimate.  As explained in Section 2.3, alternative solutions will  > > have to be developed.” > >   > > I read this paragraph as addressing the operational practices outlined in Section 2.1.  I think it is inappropriate to refer to some of these operational practices as being "sometimes described as legitimate". > > Anything performed by MITM is by definition controversial. But I get > your point. How about > > "Replacing clear text SNI transmission by an encrypted variant will break or reduce the > efficacy of the operational practices and techniques implemented in middle-boxes as > described in Section 2.1. As explained in Section 2.3, alternative solutions will > have to be developed." >   > [Roman] Looks good to me.  Thanks. > >   > > -----Original Message----- > > From: Christian Huitema [mailto:huitema@huitema.net] > > Sent: Wednesday, September 25, 2019 3:47 PM > > To: Roman Danyliw ; The IESG > > Cc: draft-ietf-tls-sni-encryption@ietf.org ; tls-chairs@ietf.org ; tls@ietf.org > > Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni- > > encryption-05: (with COMMENT) > >   > > Hello Roman, > >   > > A lot of the fixes that you suggested are incorporated in the draft-07 that was > > just released. I think the last version addresses your concerns, but you may > > of course want to verify. > >   > > On 9/25/2019 7:27 AM, Roman Danyliw wrote: > > Hi Christian! > >   > > Thanks for the detailed responses and the helpful background.  Below are a > > number of proposed text block replacements to clarify my intent (instead of > > more questions). > >   > > Roman > >   > > -----Original Message----- > > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Christian > > Huitema > > Sent: Wednesday, September 18, 2019 10:14 PM > > To: Roman Danyliw ; The IESG > > Cc: draft-ietf-tls-sni-encryption@ietf.org ; tls-chairs@ietf.org ; > > tls@ietf.org > > Subject: Re: [TLS] Roman Danyliw's No Objection on > > draft-ietf-tls-sni- > > encryption-05: (with COMMENT) > >   > > Thanks for the feedback, Roman. Comments in line. > >   > > On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote: > > ** Section 1.  Per “More and more services are colocated on > > multiplexed servers, loosening the relation between IP address and > > web service”, completely agree.  IMO, unpacking “multiplexed > > servers” is worthwhile to explain the subsequent text because it > > motivates the loss of visibility due to encryption with network only > > monitoring. > > “Multiplex’ happens at two levels: > > -- co-tenants (e.g., virtual hosting) – multiple services on the > > same server (i.e., an IP/port doesn’t uniquely identify the service) > >   > > -- cloud/cdn  – a given platform hosts the services/servers of a lot > > of organization (i.e., looking up to what netblock an IP belongs > > reveals little) > >   > > OK, will try to incorporate your text. > > Thanks. > >   > > Changes incorporated in first paragraph of section 1. > >   > > The text -07 works for me.  Thanks for adding this extra bit. > >   > >   > > ** Section 2.1.  Per “The SNI was defined to facilitate management > > of servers, though the developers of middleboxes soon found out that > > they could take advantage of the information.  Many examples of such > > usage are reviewed in [RFC8404].”, > >   > > -- Can’t middleboxes also help facilitate the management of servers? > > This text seems to take a particular view on middleboxes which > > doesn't > > seem appropriate. > >   > > It is pretty clear that the load balancer in front of a server farm > > will need access to the service ID, and must be able to retrieve the > > decrypted SNI. > > There may be other examples, such as DoS mitigation boxes. The > > "unanticipated usage" comes typically from middle-boxes that are not > > in the same management domain as either the client or the server. Is > > there an established way to designate those? > > I'm not sure I understand the original of the requirement that the client > > and server being in the same management domain. > >   > > RFC3546's definition of SNI opens with: > >    [TLS] does not provide a mechanism for a client to tell a server the > >    name of the server it is contacting.  It may be desirable for clients > >    to provide this information to facilitate secure connections to > >    servers that host multiple 'virtual' servers at a single underlying > >    network address. > >   > > It seems to me that if we are trying to channel original intent, then only the > > virtual server use case applies.  I'd propose: > >   > > OLD > > The SNI was defined to facilitate management of servers, though the > > developers of middleboxes soon found out that they could take advantage > > of the information.  Many examples of such usage are reviewed in > > [RFC8404]. > >   > > NEW > > The SNI was defined to facilitate secure connections to servers that host > > multiple 'virtual' servers at a single underlying network address [RFC3546]. > > However, addition management and security practices emerged making use > > of this information.  Examples of such usage are reviewed in [RFC8404]. > >   > > This language would let you distinguish all of the middle box behaviors > > done by operators and enterprises from a possible [RFC7258] attacker. > >   > > As I noted in my reply to Ben, I don't follow the current language for anticipated/unanticipated. > >   > > https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y > >   > > -- RFC8404 describes a number of middlebox practices, but only > > Section > > 6.2 explicitly discusses SNI, and of the examples list here, only > > one comes from RFC8404. > > A few of the examples also come in the "deep packet inspection" > > sections of 8404. But rather than going in a long discussion, I would > > rather rewrite the sentence as: Many examples of such usage are > > reviewed in [@?RFC8404], other examples came out during discussions of > > this draft. > >   > > The -07 text works for me.  Thanks. > >   > > ** Section 2.1. The “monitoring and identification of specific sites” > > isn’t symmetric to the other examples – it is rather generic.  The > > other examples, identify a what/who (e.g., ISP, firewall) + action > > (e.g., > > block, filter). > > Also, to implement most of the other example, “monitoring and > > identification of specific sites” needs to be done. > > I still think this needs to be cleaned up in some way.  IMO, I'd drop it. > >   > > Was rewritten in new section 2.1 as "Filtering or censorship of specific > > services for a variety of reasons." > >   > > I'm still struggling with the specificity here and the overlap.  Dropping the censorship and it reads "filtering of specific services for a variety of reasons".  That's exactly what bullet 2 (content filtering by operators) and bullet 3 (enterprise firewalls for NSFW) > >   > > What's unique about this bullet -- is it who is doing this filter/censorship? where it is happening? What tech is being used? > > For example, arbitrary filtering of web sites competing with other > services preferred by the network provider.  Some filtering and > censorship is more controversial than others. But I don't think that > listing every controversial usage would be appropriate. I would rather > keep the somewhat vague phrasing than try to have a debate about which > practice is controversial and which is not. > > [Roman]  Understood.  Point made.  The text is neutral enough for me > now, and I won’t push further (for editorial clarity).  Thanks. > >   > > ... > > ** Section 2.1.  Per “The SNI is probably also included in the > > general collection of metadata by pervasive surveillance actors”, I > > recommend against speculation and instead simply stating that SNI > > would be interesting meta-data for a RFC7258 attacker. > > Yes, Mirja made a similar comment. Proposed replacement: > >   > > The SNI is probably also included in the general collection of > > metadata by pervasive surveillance actors, for example to identify > > services used by surveillance targets. > > IMO, explicitly linking it to the draft would help. > >   > > OLD: > > The SNI is probably also included in the general collection of > > metadata by pervasive surveillance actors, for example to identify > > services used by surveillance targets. > >   > > NEW: > > The SNI could be included in the general collection of metadata by > > pervasive monitoring attacker [RFC7258], for example to identify > > services used by surveillance targets. > >   > > I missed the reference to 7258. Will add it in the next version. > >   > > Recommend adding the RFC7258 reference.  As I noted above, the semantics of "probably" vs. "could".  "probably" suggests a confidence to me. > > Yes, there is some confidence, based on the Snowden revelation of > systems like Quantum Insert, comments like "recording the whole > haystack", or the Korean regulation explicitly targeting the SNI > field. It is more probable than not that SNI data is being recorded, > and I think that "probably" is just fine. > > [Roman] I can live with just the RFC7258 reference.  Thanks for adding it. > >   > >   > >   > >   > > ** Section 2.2.  Per “One reason may be that, when these RFCs were > > written, the SNI information was available through a variety of > > other means”, what would those “other means” be? > > The list includes at a minimum: > >   > > Clear text exchanges amenable to deep packet inspection (DPI), server > > certificates send in clear text during TLS/SSL exchanges, DNS names > > of servers in clear text DNS queries, and server specific IP > > addresses in packet headers. > >   > > I guess I could write that all, but it makes the text a bit > > redundant, since the following paragraphs do discuss server > > certificates, DNS names and IP addresses. > > I understand.  I didn't read it that way.  My recommendation isn't to > > describe the "other means" (as it is described below), but to be clear on the > > obvious, what is the SNI information. > >   > > OLD: > > One reason may be that, when these RFCs were written, the SNI > > information was available through a variety of other means. > >   > > NEW: > > One reason may be that when the RFCs were written, the name of the > > server the being contacted by the client (i.e., the SNI) was evident through > > other means. > >   > > The new text in -07 reads more clearly to me.  Thanks for this change. > >   > > ** Section 2.3.  Per “Deploying SNI encryption will help thwarting > > most of > > the > > ‘unanticipated’ SNI usages described in Section 2.1, including > > censorship > > and > > pervasive surveillance.”: > >   > > -- Why the quotes around "unanticipated" SNI usage? > > Removing the quotes. Otherwise, you will be convinced that the > > authors believe that all middle-boxes are the spawn of the devil... > > Thanks. > >   > > -- One person’s censorship is another person’s threat mitigation, > > policy enforcement for a network they own, or parental controls (per > > the list in Section 2.1) – recommend being more precise on the order > > of “Deploying > > SNI > > encryption will {break | reduce the efficacy of } the operational > > practices > > and > > techniques used in middleboxes described in Section 2.1”. > > OK. I will try to make the text just stick to the facts: > >   > > Deploying SNI encryption thwarts most of the unanticipated SNI usages > > described in (#snileak). It reduces the efficacy of the operational > > practices and techniques implement in middle-boxes. Most of these > > functions can, however, be realized by other means. > >   > > Thanks for this. > >   > > Works for me.  However, I'd drop "Most of these functions can, however, > > be realized by other means" because this opens the debate on how exactly, > > etc. > >   > > I still recommend dropping the "other means" text because that opens debate. > >   > > ** Section 2.3.  Per “It will also thwart functions that are > > sometimes described as legitimate”, what functions are those?  I’d > > recommend > > eliminating > > this sentence as it reads like a value judgement on existing > > practices (which doesn’t seem germane for discussing requirements). > >   > > Now that censorship got added to the list in Section 2.1, you likely want to: > >   > > s/including censorship and pervasive surveillance/including pervasive surveillance/ > >   > > Otherwise, LGTM.  Thanks. > > OK. > >   > > ... > > ... > >   > > "This document does not present the design of a solution, but provides > > guidelines for evaluating proposed solutions."  However, the current text in > > Section 4 is explicitly states it is providing a solution.  The sub-section of > > Section 4.x assume the solution in Section 4.0 and describe the follow-on > > work.  Section 2 - 3 do lay out the means for evaluation nicely.  Perhaps, > > something on the order of: > >   > > OLD: > > This document does not present the design of a solution, but provides > > guidelines for evaluating proposed solutions. > >   > > NEW: > > This provides guidelines on evaluating solution and proposes an > > architecture to mitigate the threats created by an unencrypted SNI using > > existing approaches. > >   > >   > > I added the reference to a paper by Fified et al. that describes the "domain > > fronting" solution and some of its deployments. > >   > > Note that the intent is not to recommend the domain fronting solution. > That solution, and the HTTPS tunnel solution, are examined as example > of proposed solutions that meet some of the requirement but not all. > But I understand that you perceived the text as some kind of endorsement. > > [Roman]  Right, but I also think the citation helps that you’re > describing an existing practice.  The new language in added in > https://github.com/tlswg/sniencryption/pull/46/files works for me.  > Thanks. > > ... > > > >   > > Draft 07 added text describing actual deployments. > >   > > The use of the [domfront] citation works for me and addresses my concerns.  Two nits: > >   > > ** I'd recommend using the URL to the paper from conference site itself: https://petsymposium.org/2015/papers/03_Fifield.pdf > > OK. > >   > >   > > ** I'd also recommend adding a sentence to the last paragraph of Section 1, "This document does not present the design ...", to foreshadow that you'll discuss an alternative approach even if encrypted SNI isn't realized yet. > > OK, will try make clear that this is not an endorsement or a proposal. > > [Roman] I think you have it covered in the new language in > https://github.com/tlswg/sniencryption/pull/46/files. > > Regards, > > Roman > > -- Christian Huitema > >   > >   > >   > --------------E64FE887C1FC362B01F74124 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thanks, Roman. I have submitted draft-08 with the changes.

On 10/7/2019 12:07 PM, Roman Danyliw wrote:

Hi Christian!

 

Thanks for all of the iteration and updates.  Given what’s proposed in github (https://github.com/tlswg/sniencryption/pull/46/files), consider my comments resolved.  Minor comments inline …

 

From: Christian Huitema [mailto:huitema@huitema.net]
Sent: Thursday, September 26, 2019 6:53 PM
To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org; tls@ietf.org
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-encryption-05: (with COMMENT)

 

 

On 9/26/2019 11:38 AM, Roman Danyliw wrote:

Hi Christian!
 
Thanks for all of the updates.  I have a remaining items are described inline.
 
To bring up a new item, there was new text introduced in -06 of Section 5 to which I strongly object.  Specifically:
 
"Replacing clear text SNI transmission by an encrypted variant will    
also thwart MITM interferences that are sometimes described as 
legitimate.  As explained in Section 2.3, alternative solutions will  
have to be developed.”
 
I read this paragraph as addressing the operational practices outlined in Section 2.1.  I think it is inappropriate to refer to some of these operational practices as being "sometimes described as legitimate".

Anything performed by MITM is by definition controversial. But I get your point. How about 

"Replacing clear text SNI transmission by an encrypted variant will break or reduce the
efficacy of the operational practices and techniques implemented in middle-boxes as
described in Section 2.1. As explained in Section 2.3, alternative solutions will
have to be developed."
 
[Roman] Looks good to me.  Thanks.
 
-----Original Message-----
From: Christian Huitema [mailto:huitema@huitema.net]
Sent: Wednesday, September 25, 2019 3:47 PM
To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org; tls@ietf.org
Subject: Re: [TLS] Roman Danyliw's No Objection on draft-ietf-tls-sni-
encryption-05: (with COMMENT)
 
Hello Roman,
 
A lot of the fixes that you suggested are incorporated in the draft-07 that was
just released. I think the last version addresses your concerns, but you may
of course want to verify.
 
On 9/25/2019 7:27 AM, Roman Danyliw wrote:
Hi Christian!
 
Thanks for the detailed responses and the helpful background.  Below are a
number of proposed text block replacements to clarify my intent (instead of
more questions).
 
Roman
 
-----Original Message-----
From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Christian
Huitema
Sent: Wednesday, September 18, 2019 10:14 PM
To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
Cc: draft-ietf-tls-sni-encryption@ietf.org; tls-chairs@ietf.org;
tls@ietf.org
Subject: Re: [TLS] Roman Danyliw's No Objection on
draft-ietf-tls-sni-
encryption-05: (with COMMENT)
 
Thanks for the feedback, Roman. Comments in line.
 
On 9/18/2019 4:40 AM, Roman Danyliw via Datatracker wrote:
** Section 1.  Per “More and more services are colocated on
multiplexed servers, loosening the relation between IP address and
web service”, completely agree.  IMO, unpacking “multiplexed
servers” is worthwhile to explain the subsequent text because it
motivates the loss of visibility due to encryption with network only
monitoring.
“Multiplex’ happens at two levels:
-- co-tenants (e.g., virtual hosting) – multiple services on the
same server (i.e., an IP/port doesn’t uniquely identify the service)
 
-- cloud/cdn  – a given platform hosts the services/servers of a lot
of organization (i.e., looking up to what netblock an IP belongs
reveals little)
 
OK, will try to incorporate your text.
Thanks.
 
Changes incorporated in first paragraph of section 1.
 
The text -07 works for me.  Thanks for adding this extra bit.
 
 
** Section 2.1.  Per “The SNI was defined to facilitate management
of servers, though the developers of middleboxes soon found out that
they could take advantage of the information.  Many examples of such
usage are reviewed in [RFC8404].”,
 
-- Can’t middleboxes also help facilitate the management of servers?
This text seems to take a particular view on middleboxes which
doesn't
seem appropriate.
 
It is pretty clear that the load balancer in front of a server farm
will need access to the service ID, and must be able to retrieve the
decrypted SNI.
There may be other examples, such as DoS mitigation boxes. The
"unanticipated usage" comes typically from middle-boxes that are not
in the same management domain as either the client or the server. Is
there an established way to designate those?
I'm not sure I understand the original of the requirement that the client
and server being in the same management domain.
 
RFC3546's definition of SNI opens with:
   [TLS] does not provide a mechanism for a client to tell a server the
   name of the server it is contacting.  It may be desirable for clients
   to provide this information to facilitate secure connections to
   servers that host multiple 'virtual' servers at a single underlying
   network address.
 
It seems to me that if we are trying to channel original intent, then only the
virtual server use case applies.  I'd propose:
 
OLD
The SNI was defined to facilitate management of servers, though the
developers of middleboxes soon found out that they could take advantage
of the information.  Many examples of such usage are reviewed in
[RFC8404].
 
NEW
The SNI was defined to facilitate secure connections to servers that host
multiple 'virtual' servers at a single underlying network address [RFC3546].
However, addition management and security practices emerged making use
of this information.  Examples of such usage are reviewed in [RFC8404].
 
This language would let you distinguish all of the middle box behaviors
done by operators and enterprises from a possible [RFC7258] attacker.
 
As I noted in my reply to Ben, I don't follow the current language for anticipated/unanticipated.
 
https://mailarchive.ietf.org/arch/msg/tls/54cEpjUcIZqNW_y7Eb344XLQp0Y
 
-- RFC8404 describes a number of middlebox practices, but only
Section
6.2 explicitly discusses SNI, and of the examples list here, only
one comes from RFC8404.
A few of the examples also come in the "deep packet inspection"
sections of 8404. But rather than going in a long discussion, I would
rather rewrite the sentence as: Many examples of such usage are
reviewed in [@?RFC8404], other examples came out during discussions of
this draft.
 
The -07 text works for me.  Thanks.
 
** Section 2.1. The “monitoring and identification of specific sites”
isn’t symmetric to the other examples – it is rather generic.  The
other examples, identify a what/who (e.g., ISP, firewall) + action
(e.g.,
block, filter).
Also, to implement most of the other example, “monitoring and
identification of specific sites” needs to be done.
I still think this needs to be cleaned up in some way.  IMO, I'd drop it.
 
Was rewritten in new section 2.1 as "Filtering or censorship of specific
services for a variety of reasons."
 
I'm still struggling with the specificity here and the overlap.  Dropping the censorship and it reads "filtering of specific services for a variety of reasons".  That's exactly what bullet 2 (content filtering by operators) and bullet 3 (enterprise firewalls for NSFW)
 
What's unique about this bullet -- is it who is doing this filter/censorship? where it is happening? What tech is being used?

For example, arbitrary filtering of web sites competing with other services preferred by the network provider.  Some filtering and censorship is more controversial than others. But I don't think that listing every controversial usage would be appropriate. I would rather keep the somewhat vague phrasing than try to have a debate about which practice is controversial and which is not.

[Roman]  Understood.  Point made.  The text is neutral enough for me now, and I won’t push further (for editorial clarity).  Thanks.

 
...
** Section 2.1.  Per “The SNI is probably also included in the
general collection of metadata by pervasive surveillance actors”, I
recommend against speculation and instead simply stating that SNI
would be interesting meta-data for a RFC7258 attacker.
Yes, Mirja made a similar comment. Proposed replacement:
 
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify
services used by surveillance targets.
IMO, explicitly linking it to the draft would help.
 
OLD:
The SNI is probably also included in the general collection of
metadata by pervasive surveillance actors, for example to identify
services used by surveillance targets.
 
NEW:
The SNI could be included in the general collection of metadata by
pervasive monitoring attacker [RFC7258], for example to identify
services used by surveillance targets.
 
I missed the reference to 7258. Will add it in the next version.
 
Recommend adding the RFC7258 reference.  As I noted above, the semantics of "probably" vs. "could".  "probably" suggests a confidence to me.

Yes, there is some confidence, based on the Snowden revelation of systems like Quantum Insert, comments like "recording the whole haystack", or the Korean regulation explicitly targeting the SNI field. It is more probable than not that SNI data is being recorded, and I think that "probably" is just fine.

[Roman] I can live with just the RFC7258 reference.  Thanks for adding it.

 

 
 
 
** Section 2.2.  Per “One reason may be that, when these RFCs were
written, the SNI information was available through a variety of
other means”, what would those “other means” be?
The list includes at a minimum:
 
Clear text exchanges amenable to deep packet inspection (DPI), server
certificates send in clear text during TLS/SSL exchanges, DNS names
of servers in clear text DNS queries, and server specific IP
addresses in packet headers.
 
I guess I could write that all, but it makes the text a bit
redundant, since the following paragraphs do discuss server
certificates, DNS names and IP addresses.
I understand.  I didn't read it that way.  My recommendation isn't to
describe the "other means" (as it is described below), but to be clear on the
obvious, what is the SNI information.
 
OLD:
One reason may be that, when these RFCs were written, the SNI
information was available through a variety of other means.
 
NEW:
One reason may be that when the RFCs were written, the name of the
server the being contacted by the client (i.e., the SNI) was evident through
other means.
 
The new text in -07 reads more clearly to me.  Thanks for this change.
 
** Section 2.3.  Per “Deploying SNI encryption will help thwarting
most of
the
‘unanticipated’ SNI usages described in Section 2.1, including
censorship
and
pervasive surveillance.”:
 
-- Why the quotes around "unanticipated" SNI usage?
Removing the quotes. Otherwise, you will be convinced that the
authors believe that all middle-boxes are the spawn of the devil...
Thanks.
 
-- One person’s censorship is another person’s threat mitigation,
policy enforcement for a network they own, or parental controls (per
the list in Section 2.1) – recommend being more precise on the order
of “Deploying
SNI
encryption will {break | reduce the efficacy of } the operational
practices
and
techniques used in middleboxes described in Section 2.1”.
OK. I will try to make the text just stick to the facts:
 
Deploying SNI encryption thwarts most of the unanticipated SNI usages
described in (#snileak). It reduces the efficacy of the operational
practices and techniques implement in middle-boxes. Most of these
functions can, however, be realized by other means.
 
Thanks for this.
 
Works for me.  However, I'd drop "Most of these functions can, however,
be realized by other means" because this opens the debate on how exactly,
etc.
 
I still recommend dropping the "other means" text because that opens debate.
 
** Section 2.3.  Per “It will also thwart functions that are
sometimes described as legitimate”, what functions are those?  I’d
recommend
eliminating
this sentence as it reads like a value judgement on existing
practices (which doesn’t seem germane for discussing requirements).
 
Now that censorship got added to the list in Section 2.1, you likely want to:
 
s/including censorship and pervasive surveillance/including pervasive surveillance/
 
Otherwise, LGTM.  Thanks.

OK.

 
...

... 

 
"This document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions."  However, the current text in
Section 4 is explicitly states it is providing a solution.  The sub-section of
Section 4.x assume the solution in Section 4.0 and describe the follow-on
work.  Section 2 - 3 do lay out the means for evaluation nicely.  Perhaps,
something on the order of:
 
OLD:
This document does not present the design of a solution, but provides
guidelines for evaluating proposed solutions.
 
NEW:
This provides guidelines on evaluating solution and proposes an
architecture to mitigate the threats created by an unencrypted SNI using
existing approaches.
 
 
I added the reference to a paper by Fified et al. that describes the "domain
fronting" solution and some of its deployments.

 

Note that the intent is not to recommend the domain fronting solution. That solution, and the HTTPS tunnel solution, are examined as example of proposed solutions that meet some of the requirement but not all. But I understand that you perceived the text as some kind of endorsement.

[Roman]  Right, but I also think the citation helps that you’re describing an existing practice.  The new language in added in https://github.com/tlswg/sniencryption/pull/46/files works for me.  Thanks.

...



 
Draft 07 added text describing actual deployments.
 
The use of the [domfront] citation works for me and addresses my concerns.  Two nits:
 
** I'd recommend using the URL to the paper from conference site itself: https://petsymposium.org/2015/papers/03_Fifield.pdf

OK.

 
 
** I'd also recommend adding a sentence to the last paragraph of Section 1, "This document does not present the design ...", to foreshadow that you'll discuss an alternative approach even if encrypted SNI isn't realized yet.

OK, will try make clear that this is not an endorsement or a proposal.

[Roman] I think you have it covered in the new language in https://github.com/tlswg/sniencryption/pull/46/files.

Regards,

Roman

-- Christian Huitema

 

 

 
--------------E64FE887C1FC362B01F74124-- From nobody Mon Oct 7 17:30:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E2612010E for ; Mon, 7 Oct 2019 17:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YcH_uhSZHb2 for ; Mon, 7 Oct 2019 17:30:52 -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 EC5B3120111 for ; Mon, 7 Oct 2019 17:30:51 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id q203so14681571qke.1 for ; Mon, 07 Oct 2019 17:30:51 -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=lCqBAHbu8UHwO90yKi5ZB42Wlg89A4+5KRH7/kn0uP4=; b=aQIJVSDxBTRKpdYb8PydBNkkpN/ZrxrY61L12jmhMZ8bCNggpl35muLfwcoNGw3HOz qzAT88lygkYTr1tEe28iOpKz8cbKn4UkJ6M/d2ZdrPlh+ujw+yoUu0IMtCY3sOb+Tf4Z z8RhIlXEu33dTbhMmbA3pgq/SlMXOIVmjmpmk= 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=lCqBAHbu8UHwO90yKi5ZB42Wlg89A4+5KRH7/kn0uP4=; b=eQteYvXgTUUsDR0pJIK+pl8dHkFYl9VdmRxvtKCPm3xrMYyZ3GlWBNf12Z4GynqfQd HCYK737wRedpduKv7diURaJ3PdidYn+o6Hhv5+I3Auc/G4FG4qOcRk721111zj1GMkDi IynfHBWpNHOEAPM8YtSl4ZKdQAeSHg8OH1/U9N9IFsLsmfUs7gbw96O96J4DKPso+r5s t0O2dxfxa+CTgKj1uULLsiKmf+oziV9Acrq0Nok9fBY4Ln8XGHS3OujX13VMRaciaOos VHRjwrhFMFQQ0Zj3EhLTa1eH9oeWRyN878bwnlOsh1blJFOhI5mpz/+xHWcRcmiU5QAf AhMA== X-Gm-Message-State: APjAAAVj5hUsm/qIGTIrdclhrV+FensCT78w9g+otRXcjTAhIYa88dTQ mlhMxXQdfPzS4EFoEQk1bhECf8qWTsE= X-Google-Smtp-Source: APXvYqw7fC2Fqh0Jnf01WRaJcglXlpFTN2FuO/Z8qE/6ijFst89UGevB1hncpi3qHY74Dg3l/WWN+w== X-Received: by 2002:a37:9d3:: with SMTP id 202mr26784293qkj.391.1570494650700; Mon, 07 Oct 2019 17:30:50 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id x19sm8096501qkf.26.2019.10.07.17.30.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Oct 2019 17:30:49 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> Date: Mon, 7 Oct 2019 20:30:47 -0400 Cc: John Mattsson , IESG Secretary , "tls-chairs@ietf.org" , draft-ietf-rtcweb-security-arch.ad@ietf.org, Benjamin Kaduk Content-Transfer-Encoding: quoted-printable Message-Id: References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 00:30:55 -0000 > On Oct 7, 2019, at 16:12, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 07/10/2019 18:29, Rob Sayre wrote: >> On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell = >> wrote: >>> we can't "UPDATE" an I-D. >>=20 >> Not true. If you need to refer to something that's been IESG-approved = but >> still in the RFC queue, you can leave a note for the RFC editor to = update >> the reference to the eventual RFC number. >=20 > That would be an UPDATE on the eventual RFC and not on the > I-D. And in this case, it'd IMO not be a good plan as a) the > relevant WG didn't want that, b) the I-D in question is part > of a mega-cluster, so any dependency on it (as you suggest) > risks loadsa delay if the cluster doesn't get unstuck, which > can happen and c) our draft already stretches the header > enough updating 85 RFCs - trying to add an I-D to that list > would break tools and cause much pointless process-angst. >=20 > Mostly (a) is the reason to not do it though. If you want > to disagree with (a), then the right list for that would be > the rtcweb list I guess, even though the WG is now concluded > (which could, I guess, be (d);-) >=20 > Overall, the cost isn't worth the benefit IMO. draft-ietf-rtcweb-security-arch shepherd hat on To ekr=E2=80=99s point, the decision to make that switch I think = actually pre-dated me. But before I go off and dig up the history, I = think we should consider what an "updates=E2=80=9D in terms of = draft-ietf-tls-oldversions-deprecate would be. First the 2119 = requirement in draft-ietf-rtcweb-security-arch is as follows: All Implementations MUST support DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186]. =20 The rest of the quote contains no 2119 language and is merely an = informative statement: Earlier drafts of this specification required DTLS 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this writing some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues.=20 So, draft-ietf-tls-oldversions-deprecate would say nothing about DTLS1.2 = because DTLS1.2 is not being deprecated. It could update the = informative statement to say something else, but it is a factual = statement. Maybe changing the last sentence to say =E2=80=9C... which = support only DTLS 1.0 might encounter interoperability issues=E2=80=9D = sounds somehow better, but maybe this is better just leave it alone. spt= From nobody Mon Oct 7 22:02:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB10120088; Mon, 7 Oct 2019 22:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CDAfVdetB77F; Mon, 7 Oct 2019 22:02:39 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 5963512000F; Mon, 7 Oct 2019 22:02:39 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id u8so33810672iom.5; Mon, 07 Oct 2019 22:02: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=uvGtT8fx8IbnqGg8fbF+WULEJmJeMhKT8iT8R2ohFFU=; b=IJgm66l7iFZQ49ZUsqIPk1pH+Nfzr7uVo8jh0TBFPWaI8/7jUryEq70GYvdx6XQfm5 7vdHyFvQEVbqn4w0mEInhhr6oV+eVV04dF5ujER5eA81bvIhfbTpD+V5wo/yhqwmK4te J1oP13IJxbSK1owjdqPL/uf6mBGWyRMFkKn4H8d6P07UFBWlxLjwKgjVOQefPkDIUAvY 8eT7iATI+yYiUAzGLLM34/YLSPdOoLkzay7A3UJmJoASpci32GxxqnoXNIIKI3GFk0rL 7qX3F94SLo+k2O2EsIjaTSjA0rWr7l0300wZc/+PwERBEgMxVZNg31Ml2FAKOnoHJy7m MO8g== 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=uvGtT8fx8IbnqGg8fbF+WULEJmJeMhKT8iT8R2ohFFU=; b=ePuvzhs6jCEwbxx/qvNqvkdnK7WypscfwXVTAlTkVQFICIGIyspFdX3rT5EjqKxC5t C5hpPHFwAJxoV3YBfdUJjuHZ0YILSasN07eAIYDwn8TsCcp6/ut/qKql2CuZRiTwPPgf 26GcJ4b4ebRMy203RpCTwQiop98W7XTv1mOMbFezGBM/znxbwGcYACbyLaepGMb6Vibv RH9ZQnj8UbGZ4prdUSDLg0obVmoUvE6+/MJuEN+JhlOVZCtuX+0UYX8qc1x8JRVRd1tY sUA+jdo3LN5mZP5o4pYoFmmvaCLG7sssMZOcbLagzx0zzfZoNN14zTqDvVrYRb6I7SmA FH3g== X-Gm-Message-State: APjAAAXL79EnGnWCaDebdCEPujYvZB4voujdcZ7dqQYU5Y8Lhey3c6Kp MOnmZCkWuyOCoXgG5wKJF0NQYjJtDabRTt9lKd0= X-Google-Smtp-Source: APXvYqwHi6OX3DjuPn1XSgPVMAWFIAhHMFuv62gHrY0lQNOWfh6emDbFV6rqmiXjOeUpJrm4LOXnVM1dP9DmnVAEKUo= X-Received: by 2002:a5e:c00a:: with SMTP id u10mr28082076iol.73.1570510958468; Mon, 07 Oct 2019 22:02:38 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 8 Oct 2019 12:02:24 +0700 Message-ID: To: Sean Turner Cc: "tls@ietf.org" , IESG Secretary , John Mattsson , "tls-chairs@ietf.org" , draft-ietf-rtcweb-security-arch.ad@ietf.org, Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000cba4a905945f131d" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 05:02:41 -0000 --000000000000cba4a905945f131d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 8, 2019 at 7:31 AM Sean Turner wrote: > draft-ietf-rtcweb-security-arch shepherd hat on > > To ekr=E2=80=99s point, the decision to make that switch I think actually > pre-dated me. But before I go off and dig up the history, I think we > should consider what an "updates=E2=80=9D in terms of > draft-ietf-tls-oldversions-deprecate would be. > I think the relevant text from draft-ietf-tls-oldversions-deprecate is "Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347], [RFC6347]." The WebRTC text implies that it's ok to negotiate DTLS 1.0 [RFC4347], and certainly doesn't rule it out. thanks, Rob --000000000000cba4a905945f131d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 8, 2019 at 7:31 AM Sean T= urner <sean@sn3rd.com> wrote:
draft-ietf-rtcweb-security-arch shepherd hat on

To ekr=E2=80=99s point, the decision to make that switch I think actually p= re-dated me.=C2=A0 But before I go off and dig up the history, I think we s= hould consider what an "updates=E2=80=9D in terms of draft-ietf-tls-ol= dversions-deprecate would be.=C2=A0

I t= hink the relevant text from draft-ietf-tls-oldversions-deprecate is "I= mplementations MUST NOT negotiate DTLS version 1.0 [RFC4347],=C2=A0 [RFC634= 7]."=C2=A0

The WebRTC text implies that it= 9;s ok to negotiate DTLS 1.0=C2=A0[RFC4347], and certainly doesn't rule= it out.

thanks,
Rob
=C2=A0
--000000000000cba4a905945f131d-- From nobody Tue Oct 8 02:55:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A868120164 for ; Tue, 8 Oct 2019 02:55:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 21YkQ8SBh6sh for ; Tue, 8 Oct 2019 02:55:42 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50064.outbound.protection.outlook.com [40.107.5.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448AF120144 for ; Tue, 8 Oct 2019 02:55:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mcJr5qgfzx+FVdvOtMDliTRJepo6z+tcAb76wQB5IGIcxbN2qIeNOR11XZ5IdpMVS5nuzOe5GKBwqAOjsWGpguLnqi8ys0csAdgLxAa3uBhSsS+fJ4tPtajsA2vhzXL4KR/zg/F8JaEsrrLpfMGXnNDenKNc7QnGgBkmHgLlXKiy11bO7agfTFadRiC0/P27melX4gEHEbaDCpm8eZfdsNyOu06FzzATWs710ezVaGrKtSXgzQ++MAF4F3vvRnYpPJq9ecGP55hClnaVkAMLTw8oHwiz36T49VXOlJTemOs/QrFdQr01nLPKfatLcPmxl9uW7smLLCAN0UBt37Mplg== 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=mFZawpdWrtbBPvZvFAs7vQu180W9xaB7QAAR59pYKPk=; b=m0KUgXOZU6fU8L280pLgBnIm5cVvRYhMcjROUloYBEo6Q917VwyzvOQLVTvD9eHUJWTe2YdlNSxNXl/hnUR6VXjyb5WulC7L/OEWLzqIODWiUbxCvRkevq0RJXsCt7GTixvMprAhxd+XNtI/M9NaJZl5+x2grDBBHnqmZwrQ9chXeA6nJLLM0ZdXGKMTNUCYnndecxTk36qAdJLNPx5b+oy6DFQTc1cmYzrgipeN2yN6BEEL5V7TJ986nrdYcZ+iNcZ9opD1equR86T/Jk1NCB0KlzVmIh2j/NPkGyvObpH1y9NahrGQ+o7A21loJWs2Pp94qUsfF8H02PYG0EiujQ== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mFZawpdWrtbBPvZvFAs7vQu180W9xaB7QAAR59pYKPk=; b=aWc4IF4KymWR9sDtd1OWRDGEkGxvIBLzXdTQzxIi1iLO3aMzdAflGhzofhn7iSAr25LSJ3cGK6qtO/rDPbc55k1AHT8Lw5wbnfka6C9I6milUyhmuxiA/IqCcnH1AZcyWeyAFm446nMvNRlqPvY5peNweyWeroAduDwXusza6eU= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2298.eurprd07.prod.outlook.com (10.168.126.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Tue, 8 Oct 2019 09:55:38 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9%10]) with mapi id 15.20.2305.023; Tue, 8 Oct 2019 09:55:38 +0000 From: Mohit Sethi M To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb6JZ9ydCGu6h0WNgLEAne6JUw== Date: Tue, 8 Oct 2019 09:55:37 +0000 Message-ID: References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> In-Reply-To: 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:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:140:26ac:193b:4683:69c6:f65d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a8ab00c8-e04b-4460-da38-08d74bd5abe5 x-ms-traffictypediagnostic: HE1PR0701MB2298: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(366004)(396003)(136003)(346002)(53754006)(13464003)(189003)(199004)(66446008)(476003)(486006)(186003)(102836004)(7736002)(76116006)(53546011)(31696002)(6506007)(66946007)(54896002)(236005)(6306002)(8936002)(6512007)(64756008)(66556008)(66476007)(446003)(11346002)(86362001)(46003)(6486002)(8676002)(6436002)(65806001)(65956001)(25786009)(2616005)(81166006)(81156014)(36756003)(14444005)(256004)(229853002)(31686004)(99286004)(6246003)(58126008)(6116002)(2906002)(110136005)(316002)(2501003)(5660300002)(14454004)(76176011)(478600001)(71200400001)(71190400001)(606006)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2298; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z2wsi3jq8llg0Qg/7MKTEtsjUY0ZQruLI/hvBo69w9MUrDqIhrBnNJ9d6obUJnRega3iAZpAEOlpQW1whGBd+QzIpLLLvdfmr6mNUofJLvpsDuTFZOdpFr+aCsnbXNr1/89QYTGYCAfWGBh4N/OIgMrovqm+mEumoCc+p4TkZ7rmAkTnOrj47SOmhmnhyPJ5/H6tKtYpBru1ZrJ78gUCwXZHrpMSE2pOpryOJgooezxNgmoeal3oS+cfiBg+lC2YAU4AHRQq3VROUMBcQtDK65yFFvmbTo4NW8/6iYK7M0XHXO8lfVqU/wAh5sKpvnNKeN7Zd7oUurmToddKaP+8uN5EHBnadUFFF+cmY//DRC2jbBL7rTlOB+k2zstflyKXa07ZKjIVjKzs6v+wDBbs1dQoXYyS4BotegBoDkfPbrKs3eaK+GijI9FypX5x1M1EVnEY/PV3LQSGgw6vGGYprg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_a0c560b08bcad843dac857c90c0488deericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a8ab00c8-e04b-4460-da38-08d74bd5abe5 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 09:55:37.9039 (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: /+kISdDXByPltUqLKCZGtvLnkrmYcstedgtD5O6SNMeELhcnAOtM84quUNNlAC71v0SaBaCl85yWX4TOpiv8Mgqv3+32Gz40u5hd5d5WDPY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2298 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 09:55:45 -0000 --_000_a0c560b08bcad843dac857c90c0488deericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXMsDQoNCkZvciB0aGUgYmVuZWZpdCBvZiB0aGUgbGlzdCwgbGV0IG1lIHN1bW1hcml6 ZSB0aGF0IHRoZSBzZWxmaWUgYXR0YWNrIGlzIG9ubHkgcmVsZXZhbnQgd2hlcmUgbXVsdGlwbGUg cGFydGllcyBzaGFyZSB0aGUgc2FtZSBQU0sgYW5kIHVzZSB0aGUgc2FtZSBQU0sgZm9yIG91dGdv aW5nIGFuZCBpbmNvbWluZyBjb25uZWN0aW9ucy4gVGhlc2Ugc2l0dWF0aW9ucyBhcmUgcmF0aGVy IHJhcmUsIGJ1dCBJIGFjY2VwdCB0aGF0IFRMUyBpcyB3aWRlbHkgdXNlZCAoYW5kIHNvbWV0aW1l cyBtaXN1c2VkKSBpbiBtYW55IHBsYWNlcy4NCg0KVGhlIFNlbGZpZSBhdHRhY2sgb25seSBoYXBw ZW5zIHdoZW4gYW4gZW50aXR5IHdpdGggdGhlIFBTSyBhY3RzIG1hbGljaW91c2x5LiBTbyBJIHRo aW5rIHRoZSBmYWN0IHRoYXQgeW91IHdyaXRlIGluIHRoZSBkcmFmdDogImVhY2ggbm9kZSBtdXN0 IGJlIHRydXN0ZWQgbm90IHRvIGltcGVyc29uYXRlIGFub3RoZXIgbm9kZSdzIHJvbGUiIGRvZXMg bm90IHRha2UgaW50byBhY2NvdW50IHRoYXQgdGhlcmUgbXVzdCBiZSBhIG1hbGljaW91cyBub2Rl IGZvciB0aGUgc2VsZmllIGF0dGFjayB0byBoYXBwZW4gaW4gdGhlIGZpcnN0IHBsYWNlLg0KDQpE cnVja2VyIGFuZCBHdWVyb24ncyBwYXBlciByZWNvbW1lbmRzIHRoYXQgImV2ZXJ5IHBhcnRpY2lw YXRpbmcgcGFydHkgZ2V0cyAoZHVyaW5nIHRoZSBzZXR1cCBvZiB0aGUgbmV0d29yaykgYSB1bmlx dWUgaWRlbnRpdHkiIGFuZCAidGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBtdXN0IHZlcmlmeSB0 aGUgdmFsaWRpdHkgb2YgdGhlIGNsYWltZWQgaWRlbnRpdGllcy4iLiBUaGUgcmVhbGl0eSBob3dl dmVyIGlzIHRoYXQgaW4gbW9zdCBncm91cCBQU0sgc2NlbmFyaW9zLCB0aGUgbm9kZXMgZG9uJ3Qg aGF2ZSBhbnkgc3Ryb25nIGlkZW50aXRpZXMgdGhhdCBjYW4gYmUgdmVyaWZpZWQuDQoNCldoYXQg eW91IHNob3VsZCBpbnN0ZWFkIChvciBhZGRpdGlvbmFsbHkpIHNheSBpbiB0aGUgdGV4dCBpcyB0 aGF0IGEgbm9kZSBzaG91bGQgY2hlY2sgdGhhdCB0aGUgY2xpZW50X21hYyBhbmQgc2VydmVyX21h YyAob3IgYW55IG90aGVyIGlkZW50aXRpZXMgdXNlZCkgYXJlIG5ldmVyIHRoZSBzYW1lLiBXaXRo b3V0IHRoaXMgY2hlY2ssIHRoZSBzZWxmaWUgYXR0YWNrIHdvdWxkIHN0aWxsIGJlIHBvc3NpYmxl LiBBbmQgYXQgbGVhc3QgdGhpcyBkb2VzIG5vdCByZXF1aXJlIHN0cm9uZyBpZGVudGl0eSB2ZXJp ZmljYXRpb24gZm9yIHByZXZlbnRpbmcgc2VsZmllIGF0dGFja3MuDQoNCi0tTW9oaXQNCg0KT24g MTAvNS8xOSAyOjQxIFBNLCBDaHJpc3RvcGhlciBXb29kIHdyb3RlOg0KDQpIaSBGZW5nLA0KDQpG b3Igd2hhdCBpdCdzIHdvcnRoLCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIFBTSyBpbXBvcnRl cnMgZHJhZnQgaW5jbHVkZXMgYSAiY29udGV4dCIgZmllbGQgaW50byB3aGljaCBpZGVudGl0eSBp bmZvcm1hdGlvbiBjYW4gYmUgZmVkOg0KDQogICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyLTAxI2FwcGVuZGl4LUINCg0KQmVz dCwNCkNocmlzDQoNCk9uIFR1ZSwgU2VwIDI0LCAyMDE5LCBhdCA5OjE5IEFNLCBIYW8sIEZlbmcg d3JvdGU6DQoNCg0KSGkgSm9obiwNCg0KUmVmbGVjdGlvbiBhdHRhY2tzIGFyZSBpbmRlZWQgb2xk ZXIsIGJ1dCB0aGUgc2VsZmllIGF0dGFjayBpcyBhIGJpdA0KZGlmZmVyZW50LiBJdCdzIGFjdHVh bGx5IGEgdmFyaWFudCBvZiB0aGUgdW5rbm93biBrZXkgc2hhcmUgYXR0YWNrLiBBDQp0eXBpY2Fs IGV4YW1wbGUgb2YgdGhlIFVLUyBhdHRhY2sgaXMgdGhlIG9uZSByZXBvcnRlZCBvbiBNUVYgYnkg S2FsaXNraQ0KaW4gMjAwMSAoc2VlICJBbiB1bmtub3duIGtleS1zaGFyZSBhdHRhY2sgb24gdGhl IE1RViBrZXkgYWdyZWVtZW50DQpwcm90b2NvbCIgaW4gQUNNIFRJU1NFQyAyMDAxKS4gSW4gdGhh dCBleGFtcGxlLCB0aGUgYWR2ZXJzYXJ5IHBsYXlzDQptZXNzYWdlIGJldHdlZW4gdHdvIHVzZXJz IHRvIGNhdXNlIGNvbmZ1c2lvbiBpbiB0aGUgaWRlbnRpdHksIGJ1dCBpbg0KU2VsZmllLCB0aGUg YWR2ZXJzYXJ5IHBsYXlzIG1lc3NhZ2Ugd2l0aCBvbmx5IG9uZSB1c2VyIGFuZCB1c2VzIGFub3Ro ZXINCmluc3RhbmNlIG9mIHRoZSB1c2VyIHRvIGNhdXNlIGNvbmZ1c2lvbiBpbiB0aGUgaWRlbnRp dHkuIFdoZW4gd2UNCnJlcG9ydGVkIHRoaXMgdmFyaWFudCBvZiBVS1MgaW4gWzNdLCB3ZSB3ZXJl IG5vdCBhd2FyZSBvZiBhbnl0aGluZyBsaWtlDQp0aGF0IGluIHRoZSBsaXRlcmF0dXJlLg0KDQpD aGVlcnMsDQpGZW5nDQoNCu+7v09uIDI0LzA5LzIwMTksIDE2OjE3LCAiSm9obiBNYXR0c3NvbiIg PGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPjxtYWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nv bi5jb20+IHdyb3RlOg0KDQogICAgSGksDQoNCiAgICBJIHRoaW5rIHRoZXNlIHJlZmxlY3Rpb24g YXR0YWNrcyBhcmUgbXVjaCBvbGRlciB0aGFuIHRoaXMuIEkgcXVpY2sNCnNlYXJjaCBmb3IgcmVm bGVjdGlvbiBhdHRhY2sgc2VjdXJpdHkgcHJvdG9jb2wgZ2l2ZXMgYSBsb3Qgb2Ygb2xkDQpyZXN1 bHRzLCBUaGUgZGVzY3JpcHRpb24gb2YgcmVmbGVjdGlvbiBhdHRhY2sgaW4gdGhlIGZvbGxvd2lu ZyBsZWN0dXJlDQptYXRlcmlhbCBmcm9tIDIwMDkgbG9va3MganVzdCBsaWtlIHRoZSAic2VsZmll IGF0dGFjayIgb24gVExTIDEuMw0KICAgIGh0dHA6Ly93d3cuY3MuYmhhbS5hYy51ay9+dHBjL2N3 aS9UZWFjaGluZy9GaWxlcy9MZWN0dXJlNF82dXAucGRmDQoNCiAgICBXaXRoIG11bHRpcGxlIHNl Y3Rpb25zIHRoZXJlIGFyZSBvdGhlciB0aGluZ3MgdGhhdCBjaGFuZ2UgYXMgd2VsbC4NCklmIHR3 byBub2RlcyB1bmludGVudGlvbmFsbHkgaW5pdGlhdGUgc2ltdWx0YW5lb3VzIENsaWVudEhlbGxv IHRvIGVhY2gNCm90aGVyLCBldmVuIGlmIHRoZXkgb25seSB3YW50IGEgc2luZ2xlIHNlY3VyZSBj b25uZWN0aW9uIChJIGhhdmUgc2Vlbg0KbGl2ZSBzeXN0ZW1zIHdoZXJlIHRoaXMgaGFwcGVucyBp biBwcmFjdGljZSksIGFuIGF0dGFja2VyIGNhbiBzZWxlY3QNCndoaWNoIENsaWVudEhlbGxvIHRv IGJsb2NrIChlLmcuIHRoZSBvbmUgd2l0aCB0aGUgc3Ryb25nZXN0DQpjcnlwdG9ncmFwaGljIHBh cmFtZXRlcnMpLiBUaGUgZm9sbG93aW5nIHNlY3VyaXR5IHByb3BlcnR5IHdvdWxkIHRoZW4NCm5v IGxvbmdlciBob2xkIDoNCg0KICAgICAgIkRvd25ncmFkZSBwcm90ZWN0aW9uOiAgVGhlIGNyeXB0 b2dyYXBoaWMgcGFyYW1ldGVycyBzaG91bGQgYmUgdGhlDQogICAgICAgICAgc2FtZSBvbiBib3Ro IHNpZGVzIGFuZCBzaG91bGQgYmUgdGhlIHNhbWUgYXMgaWYgdGhlIHBlZXJzIGhhZCBiZWVuDQog ICAgICAgICAgY29tbXVuaWNhdGluZyBpbiB0aGUgYWJzZW5jZSBvZiBhbiBhdHRhY2siDQoNCiAg ICAoSSBoYXZlIG5vdCBsb29rZWQgYXQgd2hhdCB0aGUgZGVmaW5pdGlvbnMgaW4gW0JCRkdLWjE2 XSBzYXkpLg0KDQogICAgQ2hlZXJzLA0KICAgIEpvaG4NCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQogICAgRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz48bWFpbHRvOnRs cy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIkhhbywgRmVuZyINCjxGZW5nLkhhb0B3 YXJ3aWNrLmFjLnVrPjxtYWlsdG86RmVuZy5IYW9Ad2Fyd2ljay5hYy51az4NCiAgICBEYXRlOiBU dWVzZGF5LCAyNCBTZXB0ZW1iZXIgMjAxOSBhdCAxNjowOQ0KICAgIFRvOiBNb2hpdCBTZXRoaSBN IDxtb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPjxtYWlsdG86bW9o aXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4sDQoiT3dlbiBGcmllbCAo b2ZyaWVsKSIgPG9mcmllbEBjaXNjby5jb20+PG1haWx0bzpvZnJpZWxAY2lzY28uY29tPiwgSm9u YXRoYW4gSG95bGFuZA0KPGpvbmF0aGFuLmhveWxhbmRAZ21haWwuY29tPjxtYWlsdG86am9uYXRo YW4uaG95bGFuZEBnbWFpbC5jb20+DQogICAgQ2M6ICJUTFNAaWV0Zi5vcmciPG1haWx0bzpUTFNA aWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+PG1haWx0bzp0bHNAaWV0Zi5vcmc+DQogICAgU3ViamVj dDogUmU6IFtUTFNdIFNlbGZpZSBhdHRhY2sgd2FzIFJlOiBEaXN0aW5ndWlzaGluZyBiZXR3ZWVu DQpleHRlcm5hbC9yZXN1bXB0aW9uIFBTS3MNCg0KDQogICAgICAgIE9uIDIzLzA5LzIwMTksIDE4 OjUwLCAiVExTIG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRoaSBNIg0KPHRscy1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZg0KbW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRm Lm9yZz48bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3Jnb25iZWhhbGZvZm1vaGl0Lm0uc2V0aGk9 NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgICAgICAgICBIaSBh bGwsDQoNCiAgICAgICAgICAgIE9uIHRoZSB0b3BpYyBvZiBleHRlcm5hbCBQU0tzIGluIFRMUyAx LjMsIEkgZm91bmQgYQ0KcHVibGljYXRpb24gb24gdGhlDQogICAgICAgICAgICBTZWxmaWUgYXR0 YWNrOg0KaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az1kZDQzMmYxMy04MWM5ZTVh ZC1kZDQzNmY4OC04NjlhMTdiNWIyMWItZGM2YzZmMGE1ZGQyMWZhZiZxPTEmdT1odHRwcyUzQSUy RiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTklMkYzNDcNCg0KICAgICAgICAgICAgUGVyaGFwcyB0 aGlzIHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gSSB0aG91Z2h0DQp0aGF0IHNo YXJpbmcNCiAgICAgICAgICAgIGl0IGFnYWluIHdvdWxkbid0IGh1cnQgd2hpbGUgd2UgZGlzY3Vz cyBob3cgc2VydmVycw0KZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KICAgICAgICAgICAgZXh0ZXJuYWwg YW5kIHJlc3VtcHRpb24gUFNLcy4NCg0KICAgICAgICBJIGp1c3QgcmVhZCB0aGUgcGFwZXIgd2l0 aCBpbnRlcmVzdC4gSXQgb2NjdXJzIHRvIG1lIHRoYXQgdGhlDQpzZWxmaWUgYXR0YWNrIGlzIGNv bnNpc3RlbnQgd2l0aCB0aGUgImltcGVyc29uYXRpb24gYXR0YWNrIiB0aGF0IHdlDQpyZXBvcnRl ZCBvbiBTUEVLRSBpbiAyMDE0OyBzZWUgU2VjIDQuMSBbMV0gYW5kIHRoZSB1cGRhdGVkIHZlcnNp b24gd2l0aA0KZGV0YWlscyBvbiBob3cgU1BFS0UgaXMgcmV2aXNlZCBpbiBJU08vSUVDIDExNzcw LTQgWzJdLiBUaGUgc2FtZSBhdHRhY2sNCmNhbiBiZSB0cmFjZWQgYmFjayB0byAyMDEwIGluIFsz XSB3aGVyZSBhICJ3b3JtLWhvbGUgYXR0YWNrIiAoRmlnLiA1LA0KWzNdKSBpcyByZXBvcnRlZCBv biB0aGUgc2VsZi1jb21tdW5pY2F0aW9uIG1vZGUgb2YgSE1RVi4gVGhlIGVzc2VuY2Ugb2YNCnRo ZXNlIGF0dGFja3MgaXMgdGhlIHNhbWU6IEJvYiB0cmlja3MgQWxpY2UgaW50byB0aGlua2luZyB0 aGF0IHNoZSBpcw0KdGFsa2luZyB0byBhdXRoZW50aWNhdGVkIEJvYiwgYnV0IHNoZSBpcyBhY3R1 YWxseSB0YWxraW5nIHRvIGhlcnNlbGYuDQpJbiBbM10sIHdlIGV4cGxhaW5lZCB0aGF0IHRoZSBh dHRhY2sgd2FzIG1pc3NlZCBmcm9tIHRoZSAic2VjdXJpdHkNCnByb29mcyIgYXMgdGhlIHByb29m cyBkaWRuJ3QgY29uc2lkZXIgbXVsdGlwbGUgc2Vzc2lvbnMuDQoNCiAgICAgICAgVGhlIGNvdW50 ZXJtZWFzdXJlIHdlIHByb3Bvc2VkIGluIFsxLTNdIHdhcyB0byBlbnN1cmUgdGhlIHVzZXINCmlk ZW50aXR5IGlzIHVuaXF1ZSBpbiBrZXkgZXhjaGFuZ2UgcHJvY2Vzc2VzOiBpbiBjYXNlIG9mIG11 bHRpcGxlDQpzZXNzaW9ucyB0aGF0IG1heSBjYXVzZSBjb25mdXNpb24gaW4gdGhlIHVzZXIgaWRl bnRpdHksIGFuIGV4dGVuc2lvbg0Kc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSB1c2VyIGlkZW50aXR5 IHRvIGRpc3Rpbmd1aXNoIHRoZSBpbnN0YW5jZXMuIFRoZQ0KdW5kZXJseWluZyBpbnR1aXRpb24g aXMgdGhhdCBvbmUgc2hvdWxkIGtub3cgInVuYW1iaWd1b3VzbHkiIHdob20gdGhleQ0KYXJlIGNv bW11bmljYXRpbmcgd2l0aCwgYW5kIHBlcmZvcm0gYXV0aGVudGljYXRpb24gYmFzZWQgb24gdGhh dC4gVGhlDQpkaXNjb3Zlcnkgb2YgdGhpcyB0eXBlIG9mIGF0dGFja3MgYW5kIHRoZSBwcm9wb3Nl ZCBzb2x1dGlvbiBhcmUNCmluc3BpcmVkIGJ5IHRoZSAiZXhwbGljaXRuZXNzIHByaW5jaXBsZSIg KFJvc3MgQW5kZXJzb24gYW5kIFJvZ2VyDQpOZWVkaGFtLCBDcnlwdG8nOTUpLCB3aGljaCBzdGF0 ZXMgdGhlIGltcG9ydGFuY2Ugb2YgYmVpbmcgZXhwbGljaXQgb24NCnVzZXIgaWRlbnRpdGllcyBh bmQgb3RoZXIgYXR0cmlidXRlcyBpbiBhIHB1YmxpYyBrZXkgcHJvdG9jb2w7IGFsc28gc2VlDQpb M10uIEkgaG9wZSBpdCBtaWdodCBiZSB1c2VmdWwgdG8gcGVvcGxlIHdobyB3b3JrIG9uIFRMUyBQ U0suDQoNCiAgICAgICAgWzFdDQpodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPTVh ODIyNTEzLTA2MDhlZmFkLTVhODI2NTg4LTg2OWExN2I1YjIxYi1lYjI2MDE1MWY3OGIwNzE4JnE9 MSZ1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxNCUyRjU4NS5wZGYNCiAgICAg ICAgWzJdIGh0dHBzOi8vYXJ4aXYub3JnL2Ficy8xODAyLjA0OTAwDQogICAgICAgIFszXQ0KaHR0 cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az1kNWJmODhmZi04OTM1NDI0MS1kNWJmYzg2 NC04NjlhMTdiNWIyMWItMGU5YjNiZjU4ZTEwNGYzMiZxPTEmdT1odHRwcyUzQSUyRiUyRmVwcmlu dC5pYWNyLm9yZyUyRjIwMTAlMkYxMzYucGRmDQoNCg0KICAgICAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICBUTFMgbWFpbGluZyBsaXN0 DQogICAgICAgIFRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0K VExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3Rscw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86 VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMN Cg0K --_000_a0c560b08bcad843dac857c90c0488deericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <3998A3BBD3C9FE48A9B94E74895DA7B9@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgQ2hyaXMsPC9wPg0KPHA+Rm9yIHRoZSBiZW5lZml0 IG9mIHRoZSBsaXN0LCBsZXQgbWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMg b25seSByZWxldmFudCB3aGVyZSBtdWx0aXBsZSBwYXJ0aWVzIHNoYXJlIHRoZSBzYW1lIFBTSyBh bmQgdXNlIHRoZSBzYW1lIFBTSyBmb3Igb3V0Z29pbmcgYW5kIGluY29taW5nIGNvbm5lY3Rpb25z LiBUaGVzZSBzaXR1YXRpb25zIGFyZSByYXRoZXIgcmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExT IGlzIHdpZGVseQ0KIHVzZWQgKGFuZCBzb21ldGltZXMgbWlzdXNlZCkgaW4gbWFueSBwbGFjZXMu PC9wPg0KPHA+VGhlIFNlbGZpZSBhdHRhY2sgb25seSBoYXBwZW5zIHdoZW4gYW4gZW50aXR5IHdp dGggdGhlIFBTSyBhY3RzIG1hbGljaW91c2x5LiBTbyBJIHRoaW5rIHRoZSBmYWN0IHRoYXQgeW91 IHdyaXRlIGluIHRoZSBkcmFmdDogJnF1b3Q7ZWFjaCBub2RlIG11c3QgYmUgdHJ1c3RlZCBub3Qg dG8gaW1wZXJzb25hdGUgYW5vdGhlciBub2RlJ3Mgcm9sZSZxdW90OyBkb2VzIG5vdCB0YWtlIGlu dG8gYWNjb3VudCB0aGF0IHRoZXJlIG11c3QgYmUgYSBtYWxpY2lvdXMgbm9kZQ0KIGZvciB0aGUg c2VsZmllIGF0dGFjayB0byBoYXBwZW4gaW4gdGhlIGZpcnN0IHBsYWNlLiA8YnI+DQo8L3A+DQo8 cD5EcnVja2VyIGFuZCBHdWVyb24ncyBwYXBlciByZWNvbW1lbmRzIHRoYXQgJnF1b3Q7ZXZlcnkg cGFydGljaXBhdGluZyBwYXJ0eSBnZXRzIChkdXJpbmcgdGhlIHNldHVwIG9mIHRoZSBuZXR3b3Jr KSBhIHVuaXF1ZSBpZGVudGl0eSZxdW90OyBhbmQgJnF1b3Q7dGhlIGNsaWVudCBhbmQgdGhlIHNl cnZlciBtdXN0IHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgdGhlIGNsYWltZWQgaWRlbnRpdGllcy4m cXVvdDsuIFRoZSByZWFsaXR5IGhvd2V2ZXIgaXMgdGhhdCBpbiBtb3N0IGdyb3VwDQogUFNLIHNj ZW5hcmlvcywgdGhlIG5vZGVzIGRvbid0IGhhdmUgYW55IHN0cm9uZyBpZGVudGl0aWVzIHRoYXQg Y2FuIGJlIHZlcmlmaWVkLiA8YnI+DQo8L3A+DQo8cD5XaGF0IHlvdSBzaG91bGQgaW5zdGVhZCAo b3IgYWRkaXRpb25hbGx5KSBzYXkgaW4gdGhlIHRleHQgaXMgdGhhdCBhIG5vZGUgc2hvdWxkIGNo ZWNrIHRoYXQgdGhlIGNsaWVudF9tYWMgYW5kIHNlcnZlcl9tYWMgKG9yIGFueSBvdGhlciBpZGVu dGl0aWVzIHVzZWQpDQo8Yj5hcmUgbmV2ZXIgdGhlIHNhbWU8L2I+LiBXaXRob3V0IHRoaXMgY2hl Y2ssIHRoZSBzZWxmaWUgYXR0YWNrIHdvdWxkIHN0aWxsIGJlIHBvc3NpYmxlLiBBbmQgYXQgbGVh c3QgdGhpcyBkb2VzIG5vdCByZXF1aXJlIHN0cm9uZyBpZGVudGl0eSB2ZXJpZmljYXRpb24gZm9y IHByZXZlbnRpbmcgc2VsZmllIGF0dGFja3MuDQo8YnI+DQo8L3A+DQo8cD4tLU1vaGl0PGJyPg0K PC9wPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMC81LzE5IDI6NDEgUE0sIENo cmlzdG9waGVyIFdvb2Qgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjaXRlPSJtaWQ6YmI0MTBjMmEtNjgzNi00OGE4LWFjM2QtZGUzOTVmNGM1N2Q4QHd3dy5mYXN0 bWFpbC5jb20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5IaSBGZW5nLA0K DQpGb3Igd2hhdCBpdCdzIHdvcnRoLCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIFBTSyBpbXBv cnRlcnMgZHJhZnQgaW5jbHVkZXMgYSAmcXVvdDtjb250ZXh0JnF1b3Q7IGZpZWxkIGludG8gd2hp Y2ggaWRlbnRpdHkgaW5mb3JtYXRpb24gY2FuIGJlIGZlZDoNCg0KICAgPGEgY2xhc3M9Im1vei10 eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlci0wMSNhcHBlbmRpeC1CIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyLTAx I2FwcGVuZGl4LUI8L2E+DQoNCkJlc3QsDQpDaHJpcw0KDQpPbiBUdWUsIFNlcCAyNCwgMjAxOSwg YXQgOToxOSBBTSwgSGFvLCBGZW5nIHdyb3RlOg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+SGkgSm9obiwNCg0KUmVm bGVjdGlvbiBhdHRhY2tzIGFyZSBpbmRlZWQgb2xkZXIsIGJ1dCB0aGUgc2VsZmllIGF0dGFjayBp cyBhIGJpdCANCmRpZmZlcmVudC4gSXQncyBhY3R1YWxseSBhIHZhcmlhbnQgb2YgdGhlIHVua25v d24ga2V5IHNoYXJlIGF0dGFjay4gQSANCnR5cGljYWwgZXhhbXBsZSBvZiB0aGUgVUtTIGF0dGFj ayBpcyB0aGUgb25lIHJlcG9ydGVkIG9uIE1RViBieSBLYWxpc2tpIA0KaW4gMjAwMSAoc2VlICZx dW90O0FuIHVua25vd24ga2V5LXNoYXJlIGF0dGFjayBvbiB0aGUgTVFWIGtleSBhZ3JlZW1lbnQg DQpwcm90b2NvbCZxdW90OyBpbiBBQ00gVElTU0VDIDIwMDEpLiBJbiB0aGF0IGV4YW1wbGUsIHRo ZSBhZHZlcnNhcnkgcGxheXMgDQptZXNzYWdlIGJldHdlZW4gdHdvIHVzZXJzIHRvIGNhdXNlIGNv bmZ1c2lvbiBpbiB0aGUgaWRlbnRpdHksIGJ1dCBpbiANClNlbGZpZSwgdGhlIGFkdmVyc2FyeSBw bGF5cyBtZXNzYWdlIHdpdGggb25seSBvbmUgdXNlciBhbmQgdXNlcyBhbm90aGVyIA0KaW5zdGFu Y2Ugb2YgdGhlIHVzZXIgdG8gY2F1c2UgY29uZnVzaW9uIGluIHRoZSBpZGVudGl0eS4gV2hlbiB3 ZSANCnJlcG9ydGVkIHRoaXMgdmFyaWFudCBvZiBVS1MgaW4gWzNdLCB3ZSB3ZXJlIG5vdCBhd2Fy ZSBvZiBhbnl0aGluZyBsaWtlIA0KdGhhdCBpbiB0aGUgbGl0ZXJhdHVyZS4NCg0KQ2hlZXJzLA0K RmVuZw0KDQrvu79PbiAyNC8wOS8yMDE5LCAxNjoxNywgJnF1b3Q7Sm9obiBNYXR0c3NvbiZxdW90 OyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86am9obi5tYXR0 c3NvbkBlcmljc3Nvbi5jb20iPiZsdDtqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSZndDs8L2E+ IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgSSB0aGluayB0aGVzZSByZWZsZWN0aW9uIGF0 dGFja3MgYXJlIG11Y2ggb2xkZXIgdGhhbiB0aGlzLiBJIHF1aWNrIA0Kc2VhcmNoIGZvciByZWZs ZWN0aW9uIGF0dGFjayBzZWN1cml0eSBwcm90b2NvbCBnaXZlcyBhIGxvdCBvZiBvbGQgDQpyZXN1 bHRzLCBUaGUgZGVzY3JpcHRpb24gb2YgcmVmbGVjdGlvbiBhdHRhY2sgaW4gdGhlIGZvbGxvd2lu ZyBsZWN0dXJlIA0KbWF0ZXJpYWwgZnJvbSAyMDA5IGxvb2tzIGp1c3QgbGlrZSB0aGUgJnF1b3Q7 c2VsZmllIGF0dGFjayZxdW90OyBvbiBUTFMgMS4zDQogICAgPGEgY2xhc3M9Im1vei10eHQtbGlu ay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL3d3dy5jcy5iaGFtLmFjLnVrL350cGMvY3dpL1RlYWNo aW5nL0ZpbGVzL0xlY3R1cmU0XzZ1cC5wZGYiPmh0dHA6Ly93d3cuY3MuYmhhbS5hYy51ay9+dHBj L2N3aS9UZWFjaGluZy9GaWxlcy9MZWN0dXJlNF82dXAucGRmPC9hPg0KICAgIA0KICAgIFdpdGgg bXVsdGlwbGUgc2VjdGlvbnMgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0IGNoYW5nZSBhcyB3 ZWxsLiANCklmIHR3byBub2RlcyB1bmludGVudGlvbmFsbHkgaW5pdGlhdGUgc2ltdWx0YW5lb3Vz IENsaWVudEhlbGxvIHRvIGVhY2ggDQpvdGhlciwgZXZlbiBpZiB0aGV5IG9ubHkgd2FudCBhIHNp bmdsZSBzZWN1cmUgY29ubmVjdGlvbiAoSSBoYXZlIHNlZW4gDQpsaXZlIHN5c3RlbXMgd2hlcmUg dGhpcyBoYXBwZW5zIGluIHByYWN0aWNlKSwgYW4gYXR0YWNrZXIgY2FuIHNlbGVjdCANCndoaWNo IENsaWVudEhlbGxvIHRvIGJsb2NrIChlLmcuIHRoZSBvbmUgd2l0aCB0aGUgc3Ryb25nZXN0IA0K Y3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzKS4gVGhlIGZvbGxvd2luZyBzZWN1cml0eSBwcm9wZXJ0 eSB3b3VsZCB0aGVuIA0Kbm8gbG9uZ2VyIGhvbGQgOg0KICAgIA0KICAgICAgJnF1b3Q7RG93bmdy YWRlIHByb3RlY3Rpb246ICBUaGUgY3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzIHNob3VsZCBiZSB0 aGUNCiAgICAgICAgICBzYW1lIG9uIGJvdGggc2lkZXMgYW5kIHNob3VsZCBiZSB0aGUgc2FtZSBh cyBpZiB0aGUgcGVlcnMgaGFkIGJlZW4NCiAgICAgICAgICBjb21tdW5pY2F0aW5nIGluIHRoZSBh YnNlbmNlIG9mIGFuIGF0dGFjayZxdW90Ow0KICAgIA0KICAgIChJIGhhdmUgbm90IGxvb2tlZCBh dCB3aGF0IHRoZSBkZWZpbml0aW9ucyBpbiBbQkJGR0taMTZdIHNheSkuDQogICAgDQogICAgQ2hl ZXJzLA0KICAgIEpvaG4NCiAgICANCiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAg IEZyb206IFRMUyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmciPiZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9u IGJlaGFsZiBvZiAmcXVvdDtIYW8sIEZlbmcmcXVvdDsgDQo8YSBjbGFzcz0ibW96LXR4dC1saW5r LXJmYzIzOTZFIiBocmVmPSJtYWlsdG86RmVuZy5IYW9Ad2Fyd2ljay5hYy51ayI+Jmx0O0Zlbmcu SGFvQHdhcndpY2suYWMudWsmZ3Q7PC9hPg0KICAgIERhdGU6IFR1ZXNkYXksIDI0IFNlcHRlbWJl ciAyMDE5IGF0IDE2OjA5DQogICAgVG86IE1vaGl0IFNldGhpIE0gPGEgY2xhc3M9Im1vei10eHQt bGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21A ZG1hcmMuaWV0Zi5vcmciPiZsdDttb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmll dGYub3JnJmd0OzwvYT4sIA0KJnF1b3Q7T3dlbiBGcmllbCAob2ZyaWVsKSZxdW90OyA8YSBjbGFz cz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86b2ZyaWVsQGNpc2NvLmNvbSI+ Jmx0O29mcmllbEBjaXNjby5jb20mZ3Q7PC9hPiwgSm9uYXRoYW4gSG95bGFuZCANCjxhIGNsYXNz PSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpqb25hdGhhbi5ob3lsYW5kQGdt YWlsLmNvbSI+Jmx0O2pvbmF0aGFuLmhveWxhbmRAZ21haWwuY29tJmd0OzwvYT4NCiAgICBDYzog PGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyI+JnF1b3Q7VExTQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJm YzIzOTZFIiBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj4mbHQ7dGxzQGlldGYub3JnJmd0Ozwv YT4NCiAgICBTdWJqZWN0OiBSZTogW1RMU10gU2VsZmllIGF0dGFjayB3YXMgUmU6IERpc3Rpbmd1 aXNoaW5nIGJldHdlZW4gDQpleHRlcm5hbC9yZXN1bXB0aW9uIFBTS3MNCiAgICANCiAgICAgICAg DQogICAgICAgIE9uIDIzLzA5LzIwMTksIDE4OjUwLCAmcXVvdDtUTFMgb24gYmVoYWxmIG9mIE1v aGl0IFNldGhpIE0mcXVvdDsgDQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVm PSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmdvbmJlaGFsZm9mbW9oaXQubS5zZXRoaT00MGVy aWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+Jmx0O3Rscy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZiANCm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7 PC9hPiB3cm90ZToNCiAgICAgICAgDQogICAgICAgICAgICBIaSBhbGwsDQogICAgICAgICAgICAN CiAgICAgICAgICAgIE9uIHRoZSB0b3BpYyBvZiBleHRlcm5hbCBQU0tzIGluIFRMUyAxLjMsIEkg Zm91bmQgYSANCnB1YmxpY2F0aW9uIG9uIHRoZSANCiAgICAgICAgICAgIFNlbGZpZSBhdHRhY2s6 IA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0 Mi5maXJlZXllLmNvbS91cmw/az1kZDQzMmYxMy04MWM5ZTVhZC1kZDQzNmY4OC04NjlhMTdiNWIy MWItZGM2YzZmMGE1ZGQyMWZhZiZhbXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50Lmlh Y3Iub3JnJTJGMjAxOSUyRjM0NyI+aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az1k ZDQzMmYxMy04MWM5ZTVhZC1kZDQzNmY4OC04NjlhMTdiNWIyMWItZGM2YzZmMGE1ZGQyMWZhZiZh bXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxOSUyRjM0Nzwv YT4NCiAgICAgICAgICAgIA0KICAgICAgICAgICAgUGVyaGFwcyB0aGlzIHdhcyBhbHJlYWR5IGRp c2N1c3NlZCBvbiB0aGUgbGlzdC4gSSB0aG91Z2h0IA0KdGhhdCBzaGFyaW5nIA0KICAgICAgICAg ICAgaXQgYWdhaW4gd291bGRuJ3QgaHVydCB3aGlsZSB3ZSBkaXNjdXNzIGhvdyBzZXJ2ZXJzIA0K ZGlzdGluZ3Vpc2ggYmV0d2VlbiANCiAgICAgICAgICAgIGV4dGVybmFsIGFuZCByZXN1bXB0aW9u IFBTS3MuDQogICAgICAgICAgICANCiAgICAgICAgSSBqdXN0IHJlYWQgdGhlIHBhcGVyIHdpdGgg aW50ZXJlc3QuIEl0IG9jY3VycyB0byBtZSB0aGF0IHRoZSANCnNlbGZpZSBhdHRhY2sgaXMgY29u c2lzdGVudCB3aXRoIHRoZSAmcXVvdDtpbXBlcnNvbmF0aW9uIGF0dGFjayZxdW90OyB0aGF0IHdl IA0KcmVwb3J0ZWQgb24gU1BFS0UgaW4gMjAxNDsgc2VlIFNlYyA0LjEgWzFdIGFuZCB0aGUgdXBk YXRlZCB2ZXJzaW9uIHdpdGggDQpkZXRhaWxzIG9uIGhvdyBTUEVLRSBpcyByZXZpc2VkIGluIElT Ty9JRUMgMTE3NzAtNCBbMl0uIFRoZSBzYW1lIGF0dGFjayANCmNhbiBiZSB0cmFjZWQgYmFjayB0 byAyMDEwIGluIFszXSB3aGVyZSBhICZxdW90O3dvcm0taG9sZSBhdHRhY2smcXVvdDsgKEZpZy4g NSwgDQpbM10pIGlzIHJlcG9ydGVkIG9uIHRoZSBzZWxmLWNvbW11bmljYXRpb24gbW9kZSBvZiBI TVFWLiBUaGUgZXNzZW5jZSBvZiANCnRoZXNlIGF0dGFja3MgaXMgdGhlIHNhbWU6IEJvYiB0cmlj a3MgQWxpY2UgaW50byB0aGlua2luZyB0aGF0IHNoZSBpcyANCnRhbGtpbmcgdG8gYXV0aGVudGlj YXRlZCBCb2IsIGJ1dCBzaGUgaXMgYWN0dWFsbHkgdGFsa2luZyB0byBoZXJzZWxmLiANCkluIFsz XSwgd2UgZXhwbGFpbmVkIHRoYXQgdGhlIGF0dGFjayB3YXMgbWlzc2VkIGZyb20gdGhlICZxdW90 O3NlY3VyaXR5IA0KcHJvb2ZzJnF1b3Q7IGFzIHRoZSBwcm9vZnMgZGlkbid0IGNvbnNpZGVyIG11 bHRpcGxlIHNlc3Npb25zLiANCiAgICAgICAgDQogICAgICAgIFRoZSBjb3VudGVybWVhc3VyZSB3 ZSBwcm9wb3NlZCBpbiBbMS0zXSB3YXMgdG8gZW5zdXJlIHRoZSB1c2VyIA0KaWRlbnRpdHkgaXMg dW5pcXVlIGluIGtleSBleGNoYW5nZSBwcm9jZXNzZXM6IGluIGNhc2Ugb2YgbXVsdGlwbGUgDQpz ZXNzaW9ucyB0aGF0IG1heSBjYXVzZSBjb25mdXNpb24gaW4gdGhlIHVzZXIgaWRlbnRpdHksIGFu IGV4dGVuc2lvbiANCnNob3VsZCBiZSBhZGRlZCB0byB0aGUgdXNlciBpZGVudGl0eSB0byBkaXN0 aW5ndWlzaCB0aGUgaW5zdGFuY2VzLiBUaGUgDQp1bmRlcmx5aW5nIGludHVpdGlvbiBpcyB0aGF0 IG9uZSBzaG91bGQga25vdyAmcXVvdDt1bmFtYmlndW91c2x5JnF1b3Q7IHdob20gdGhleSANCmFy ZSBjb21tdW5pY2F0aW5nIHdpdGgsIGFuZCBwZXJmb3JtIGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9u IHRoYXQuIFRoZSANCmRpc2NvdmVyeSBvZiB0aGlzIHR5cGUgb2YgYXR0YWNrcyBhbmQgdGhlIHBy b3Bvc2VkIHNvbHV0aW9uIGFyZSANCmluc3BpcmVkIGJ5IHRoZSAmcXVvdDtleHBsaWNpdG5lc3Mg cHJpbmNpcGxlJnF1b3Q7IChSb3NzIEFuZGVyc29uIGFuZCBSb2dlciANCk5lZWRoYW0sIENyeXB0 byc5NSksIHdoaWNoIHN0YXRlcyB0aGUgaW1wb3J0YW5jZSBvZiBiZWluZyBleHBsaWNpdCBvbiAN CnVzZXIgaWRlbnRpdGllcyBhbmQgb3RoZXIgYXR0cmlidXRlcyBpbiBhIHB1YmxpYyBrZXkgcHJv dG9jb2w7IGFsc28gc2VlIA0KWzNdLiBJIGhvcGUgaXQgbWlnaHQgYmUgdXNlZnVsIHRvIHBlb3Bs ZSB3aG8gd29yayBvbiBUTFMgUFNLLg0KICAgICAgICANCiAgICAgICAgWzFdIA0KPGEgY2xhc3M9 Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNv bS91cmw/az01YTgyMjUxMy0wNjA4ZWZhZC01YTgyNjU4OC04NjlhMTdiNWIyMWItZWIyNjAxNTFm NzhiMDcxOCZhbXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAx NCUyRjU4NS5wZGYiPmh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9NWE4MjI1MTMt MDYwOGVmYWQtNWE4MjY1ODgtODY5YTE3YjViMjFiLWViMjYwMTUxZjc4YjA3MTgmYW1wO3E9MSZh bXA7dT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTQlMkY1ODUucGRmPC9hPg0K ICAgICAgICBbMl0gPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6 Ly9hcnhpdi5vcmcvYWJzLzE4MDIuMDQ5MDAiPmh0dHBzOi8vYXJ4aXYub3JnL2Ficy8xODAyLjA0 OTAwPC9hPg0KICAgICAgICBbM10gDQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBo cmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPWQ1YmY4OGZmLTg5MzU0MjQx LWQ1YmZjODY0LTg2OWExN2I1YjIxYi0wZTliM2JmNThlMTA0ZjMyJmFtcDtxPTEmYW1wO3U9aHR0 cHMlM0ElMkYlMkZlcHJpbnQuaWFjci5vcmclMkYyMDEwJTJGMTM2LnBkZiI+aHR0cHM6Ly9wcm90 ZWN0Mi5maXJlZXllLmNvbS91cmw/az1kNWJmODhmZi04OTM1NDI0MS1kNWJmYzg2NC04NjlhMTdi NWIyMWItMGU5YjNiZjU4ZTEwNGYzMiZhbXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50 LmlhY3Iub3JnJTJGMjAxMCUyRjEzNi5wZGY8L2E+IA0KICAgICAgICANCiAgICAgICAgDQogICAg ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg ICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPg0KICAg ICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHM8L2E+DQogICAgICAgIA0KICAgIA0KICAgIA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KPGEg Y2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyI+VExTQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPg0KDQo8L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNCjxhIGNsYXNz PSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRM U0BpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_a0c560b08bcad843dac857c90c0488deericssoncom_-- From nobody Tue Oct 8 03:14:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968EC120169 for ; Tue, 8 Oct 2019 03:14:34 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 mSCtmsIzQfQQ for ; Tue, 8 Oct 2019 03:14:30 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40077.outbound.protection.outlook.com [40.107.4.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F413812022E for ; Tue, 8 Oct 2019 03:14:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mi48+jpp+nEN51vNNs0krnx+sRwftbj0tFaGU1KIJMVYvh9g38hOeMH4wptCKq6FgGa+o5bcXDFnbactGfvJe2u63qVa3ZZAVLpcgBlqihcnQB17ZkVcFAI3EHy8s7oIx2tpZZxU2kVRu5t9HpYNrA8gO1fO/nDATuV3Ah+TrQahVDD197fj8uSJ9FUtEVCNU+NP9Ddojmrm5slSlkm7gle9SwU4OGC6b8NlCySYdbJxEZ1iz9j0JNxUgkV+TvP6mmzeEwWEAuk1QSI64yW9dgQoA4tHqy//27GreFx98JdG0+Yn99lP7D9TbA+7mHdS5v+wMSl/q4ITIRwLSJ6qTA== 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=JZY3m81uV5MR5ZzJ2UQgKJHIES+JjFtjngqc/Ke9EQE=; b=hS/sDPLHZnGTIh3ZHRr8snBgaCE1ERbe497U9QX/WM7tcoyoE/tLrnvCcImV1utHZevKN8AYqWOJ0XUNT7tfBVqbGPhrNLFwBG/sekscMkdwsBp86cOHvENruA84sFJJk81sHRFWko3sPWvzmbbYSjZHQcN/sQo1PBBJCRHWoo7JKHrSBXxjn2K3FesgEpUTf4381XR9qCVpLLyD1H801iUoNSLIWjH8b4PfZvZbceY6+pSZElqNOLgSslzHbHP+2QOOUA29kyGA5636Qw1jnPHEgfA+Q9kJnda/icUDLRhHpzQYKrw6mFqjjes8hsKnxoxzdvnqBi3nt73DYkjpCA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JZY3m81uV5MR5ZzJ2UQgKJHIES+JjFtjngqc/Ke9EQE=; b=eSXfIELp/LHLPBydtpK9rSSdl2U0HdeIYMOF9geu0ZcjnQej6Hfv02W0Fv3E95K1aaK3KUEJM2RY9Yinzq6GR77kz+eJc5Re07prEwRuXtjBRDQIMajWL6WlUqGhcp3XAe0SekWZL+P4cn/BHjP+HM+pfC/OLXCVJTguW5m9Ijk= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3081.eurprd07.prod.outlook.com (10.170.244.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.10; Tue, 8 Oct 2019 10:14:27 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2347.016; Tue, 8 Oct 2019 10:14:27 +0000 From: John Mattsson To: Mohit Sethi M , Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb7LOQnBEvPvDUirCjFHsuP0MadQqFwA Date: Tue, 8 Oct 2019 10:14:26 +0000 Message-ID: <1107173F-E6D8-4882-A8A2-A74B6BB20427@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 42e1aafa-ac2c-4aa4-b056-08d74bd84cf2 x-ms-traffictypediagnostic: HE1PR07MB3081: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(39860400002)(376002)(199004)(189003)(13464003)(53754006)(6506007)(91956017)(76116006)(26005)(186003)(53546011)(76176011)(102836004)(36756003)(316002)(110136005)(66446008)(66556008)(66476007)(58126008)(64756008)(99286004)(71190400001)(66946007)(11346002)(446003)(71200400001)(476003)(486006)(2616005)(5660300002)(2501003)(256004)(44832011)(14444005)(2906002)(86362001)(25786009)(6246003)(236005)(6436002)(478600001)(6116002)(3846002)(966005)(14454004)(7736002)(8676002)(81166006)(81156014)(8936002)(66066001)(6486002)(54896002)(6306002)(229853002)(33656002)(6512007)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3081; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wD4U+cMVjXoSEuUmrILU/LVYrO8VtR1e8x73kunrYt9ucJlVyoCqX49Vj/CMwHULIlRKHHXVr2ra13HxI3vzEQcd3Z0Xu0QKEuZr6Ipm08npf9tSwtTRkfgCrJ+r48SlYMFwLrQIAuKye/SrDF3VZQzgb3Te7iaU9wgY7WwrrHnEHiiFgxol5sJp7yt0mg7wS0Dn1bKz7df0S/1tcT7l60i4gz3IVBOcqEYR52RcPG5Y84DM2JTea7M3Uc3VEH+eOJE01KzWN1bSc7g2+P8xtdsWpjw8561P3jduAv5YOhDUEhTZa6in/W+yg8KX9YoRr1cE7WjSNRQaELWUUu+RKF1QQ6zrweAcEggzXBH0Z1GCB/9moysnZ2F1sFiU1+6VFEnRrganz1yoFdiwo1VBCofzg13tVhvAs8QUVCaiX3gsMWjUfjvoiSKo8iXjkXIA4U6l2AiXfCtcObgzc2rXZg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_1107173FE6D84882A8A2A74B6BB20427ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 42e1aafa-ac2c-4aa4-b056-08d74bd84cf2 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 10:14:27.0168 (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: G9iEWtj52p04Yp1HRufqqlzozQYgceMUFaF8jPm73LCTgve34IE+OInTHurICO3C2bsbWIqMLf43iol7XfomdWuaksFYa2qSaQd084qiDwg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3081 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 10:14:35 -0000 --_000_1107173FE6D84882A8A2A74B6BB20427ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTW9oaXQsIHRoYXQgYXJlIGdvb2QgcG9pbnRzLg0KDQo+IFRoZSByZWFsaXR5IGhvd2V2ZXIg aXMgdGhhdCBpbiBtb3N0IGdyb3VwIFBTSyBzY2VuYXJpb3MsIHRoZSBub2RlcyBkb24ndCBoYXZl IGFueSBzdHJvbmcgaWRlbnRpdGllcyB0aGF0IGNhbiBiZSB2ZXJpZmllZC4NCkkgYXNzdW1lIGJs b2NraW5nIGFsbCBpZGVudGl0aWVzIHRoYXQgYXJlIG5vdCB0aGUgbm9kZXMgb3duIGlkZW50aXR5 IHdvdWxkIG1pdGlnYXRlIHRoZSBhdHRhY2tzLCBidXQgbGVhZCB0byBhdmFpbGFiaWxpdHkgcHJv YmxlbXMgYXMgdHdvIG5vZGVzIHdpdGggdGhlIHNhbWUgY2hvc2VuIGlkZW50aXR5IGNhbm5vdCB0 YWxrIHRvIGVhY2ggb3RoZXIuDQoNCj5XaGF0IHlvdSBzaG91bGQgaW5zdGVhZCAob3IgYWRkaXRp b25hbGx5KSBzYXkgaW4gdGhlIHRleHQgaXMgdGhhdCBhIG5vZGUgc2hvdWxkIGNoZWNrIHRoYXQg dGhlIGNsaWVudF9tYWMgYW5kIHNlcnZlcl9tYWMgKG9yIGFueSA+b3RoZXIgaWRlbnRpdGllcyB1 c2VkKSBhcmUgbmV2ZXIgdGhlIHNhbWUuDQoNCkkgdGhpbmsgY2hlY2tpbmcgQ2xpZW50SGVsbG8u cmFuZG9tIGlzIGVub3VnaC4gQmVsb3cgaXMgd2hhdCB3ZSB3cm90ZSBpbg0KaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFjZS1jb3NlLWVjZGhlLTE0DQoNCiAg4oCc SWYgdHdvIG5vZGVzIHVuaW50ZW50aW9uYWxseSBpbml0aWF0ZSB0d28gc2ltdWx0YW5lb3VzIEVE SE9DIG1lc3NhZ2UNCiAgIGV4Y2hhbmdlcyB3aXRoIGVhY2ggb3RoZXIgZXZlbiBpZiB0aGV5IG9u bHkgd2FudCB0byBjb21wbGV0ZSBhIHNpbmdsZQ0KICAgRURIT0MgbWVzc2FnZSBleGNoYW5nZSwg dGhleSBNQVkgdGVybWluYXRlIHRoZSBleGNoYW5nZSB3aXRoIHRoZQ0KICAgbGV4aWNvZ3JhcGhp Y2FsbHkgc21hbGxlc3QgR19YLiAgSWYgdGhlIHR3byBHX1ggdmFsdWVzIGFyZSBlcXVhbCwgdGhl DQogICByZWNlaXZlZCBtZXNzYWdlXzEgTVVTVCBiZSBkaXNjYXJkZWQgdG8gbWl0aWdhdGUgcmVm bGVjdGlvbiBhdHRhY2tzLg0KICAgTm90ZSB0aGF0IGluIHRoZSBjYXNlIG9mIHR3byBzaW11bHRh bmVvdXMgRURIT0MgZXhjaGFuZ2VzIHdoZXJlIHRoZQ0KICAgbm9kZXMgb25seSBjb21wbGV0ZSBv bmUgYW5kIHdoZXJlIHRoZSBub2RlcyBoYXZlIGRpZmZlcmVudCBwcmVmZXJyZWQNCiAgIGNpcGhl ciBzdWl0ZXMsIGFuIGF0dGFja2VyIGNhbiBhZmZlY3Qgd2hpY2ggb2YgdGhlIHR3byBub2RlcycN CiAgIHByZWZlcnJlZCBjaXBoZXIgc3VpdGVzIHdpbGwgYmUgdXNlZCBieSBibG9ja2luZyB0aGUg b3RoZXIgZXhjaGFuZ2Uu4oCdDQoNCkpvaG4NCg0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nv bi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCA4IE9jdG9iZXIgMjAxOSBhdCAx MTo1Nw0KVG86IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+LCAiVExTQGll dGYub3JnIiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFNlbGZpZSBhdHRhY2sN Cg0KDQpIaSBDaHJpcywNCg0KRm9yIHRoZSBiZW5lZml0IG9mIHRoZSBsaXN0LCBsZXQgbWUgc3Vt bWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMgb25seSByZWxldmFudCB3aGVyZSBtdWx0 aXBsZSBwYXJ0aWVzIHNoYXJlIHRoZSBzYW1lIFBTSyBhbmQgdXNlIHRoZSBzYW1lIFBTSyBmb3Ig b3V0Z29pbmcgYW5kIGluY29taW5nIGNvbm5lY3Rpb25zLiBUaGVzZSBzaXR1YXRpb25zIGFyZSBy YXRoZXIgcmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExTIGlzIHdpZGVseSB1c2VkIChhbmQgc29t ZXRpbWVzIG1pc3VzZWQpIGluIG1hbnkgcGxhY2VzLg0KDQpUaGUgU2VsZmllIGF0dGFjayBvbmx5 IGhhcHBlbnMgd2hlbiBhbiBlbnRpdHkgd2l0aCB0aGUgUFNLIGFjdHMgbWFsaWNpb3VzbHkuIFNv IEkgdGhpbmsgdGhlIGZhY3QgdGhhdCB5b3Ugd3JpdGUgaW4gdGhlIGRyYWZ0OiAiZWFjaCBub2Rl IG11c3QgYmUgdHJ1c3RlZCBub3QgdG8gaW1wZXJzb25hdGUgYW5vdGhlciBub2RlJ3Mgcm9sZSIg ZG9lcyBub3QgdGFrZSBpbnRvIGFjY291bnQgdGhhdCB0aGVyZSBtdXN0IGJlIGEgbWFsaWNpb3Vz IG5vZGUgZm9yIHRoZSBzZWxmaWUgYXR0YWNrIHRvIGhhcHBlbiBpbiB0aGUgZmlyc3QgcGxhY2Uu DQoNCkRydWNrZXIgYW5kIEd1ZXJvbidzIHBhcGVyIHJlY29tbWVuZHMgdGhhdCAiZXZlcnkgcGFy dGljaXBhdGluZyBwYXJ0eSBnZXRzIChkdXJpbmcgdGhlIHNldHVwIG9mIHRoZSBuZXR3b3JrKSBh IHVuaXF1ZSBpZGVudGl0eSIgYW5kICJ0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyIG11c3QgdmVy aWZ5IHRoZSB2YWxpZGl0eSBvZiB0aGUgY2xhaW1lZCBpZGVudGl0aWVzLiIuIFRoZSByZWFsaXR5 IGhvd2V2ZXIgaXMgdGhhdCBpbiBtb3N0IGdyb3VwIFBTSyBzY2VuYXJpb3MsIHRoZSBub2RlcyBk b24ndCBoYXZlIGFueSBzdHJvbmcgaWRlbnRpdGllcyB0aGF0IGNhbiBiZSB2ZXJpZmllZC4NCg0K V2hhdCB5b3Ugc2hvdWxkIGluc3RlYWQgKG9yIGFkZGl0aW9uYWxseSkgc2F5IGluIHRoZSB0ZXh0 IGlzIHRoYXQgYSBub2RlIHNob3VsZCBjaGVjayB0aGF0IHRoZSBjbGllbnRfbWFjIGFuZCBzZXJ2 ZXJfbWFjIChvciBhbnkgb3RoZXIgaWRlbnRpdGllcyB1c2VkKSBhcmUgbmV2ZXIgdGhlIHNhbWUu IFdpdGhvdXQgdGhpcyBjaGVjaywgdGhlIHNlbGZpZSBhdHRhY2sgd291bGQgc3RpbGwgYmUgcG9z c2libGUuIEFuZCBhdCBsZWFzdCB0aGlzIGRvZXMgbm90IHJlcXVpcmUgc3Ryb25nIGlkZW50aXR5 IHZlcmlmaWNhdGlvbiBmb3IgcHJldmVudGluZyBzZWxmaWUgYXR0YWNrcy4NCg0KLS1Nb2hpdA0K T24gMTAvNS8xOSAyOjQxIFBNLCBDaHJpc3RvcGhlciBXb29kIHdyb3RlOg0KDQpIaSBGZW5nLA0K DQoNCg0KRm9yIHdoYXQgaXQncyB3b3J0aCwgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBQU0sg aW1wb3J0ZXJzIGRyYWZ0IGluY2x1ZGVzIGEgImNvbnRleHQiIGZpZWxkIGludG8gd2hpY2ggaWRl bnRpdHkgaW5mb3JtYXRpb24gY2FuIGJlIGZlZDoNCg0KDQoNCiAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1leHRlcm5hbC1wc2staW1wb3J0ZXItMDEjYXBwZW5k aXgtQg0KDQoNCg0KQmVzdCwNCg0KQ2hyaXMNCg0KDQoNCk9uIFR1ZSwgU2VwIDI0LCAyMDE5LCBh dCA5OjE5IEFNLCBIYW8sIEZlbmcgd3JvdGU6DQoNCkhpIEpvaG4sDQoNCg0KDQpSZWZsZWN0aW9u IGF0dGFja3MgYXJlIGluZGVlZCBvbGRlciwgYnV0IHRoZSBzZWxmaWUgYXR0YWNrIGlzIGEgYml0 DQoNCmRpZmZlcmVudC4gSXQncyBhY3R1YWxseSBhIHZhcmlhbnQgb2YgdGhlIHVua25vd24ga2V5 IHNoYXJlIGF0dGFjay4gQQ0KDQp0eXBpY2FsIGV4YW1wbGUgb2YgdGhlIFVLUyBhdHRhY2sgaXMg dGhlIG9uZSByZXBvcnRlZCBvbiBNUVYgYnkgS2FsaXNraQ0KDQppbiAyMDAxIChzZWUgIkFuIHVu a25vd24ga2V5LXNoYXJlIGF0dGFjayBvbiB0aGUgTVFWIGtleSBhZ3JlZW1lbnQNCg0KcHJvdG9j b2wiIGluIEFDTSBUSVNTRUMgMjAwMSkuIEluIHRoYXQgZXhhbXBsZSwgdGhlIGFkdmVyc2FyeSBw bGF5cw0KDQptZXNzYWdlIGJldHdlZW4gdHdvIHVzZXJzIHRvIGNhdXNlIGNvbmZ1c2lvbiBpbiB0 aGUgaWRlbnRpdHksIGJ1dCBpbg0KDQpTZWxmaWUsIHRoZSBhZHZlcnNhcnkgcGxheXMgbWVzc2Fn ZSB3aXRoIG9ubHkgb25lIHVzZXIgYW5kIHVzZXMgYW5vdGhlcg0KDQppbnN0YW5jZSBvZiB0aGUg dXNlciB0byBjYXVzZSBjb25mdXNpb24gaW4gdGhlIGlkZW50aXR5LiBXaGVuIHdlDQoNCnJlcG9y dGVkIHRoaXMgdmFyaWFudCBvZiBVS1MgaW4gWzNdLCB3ZSB3ZXJlIG5vdCBhd2FyZSBvZiBhbnl0 aGluZyBsaWtlDQoNCnRoYXQgaW4gdGhlIGxpdGVyYXR1cmUuDQoNCg0KDQpDaGVlcnMsDQoNCkZl bmcNCg0KDQoNCk9uIDI0LzA5LzIwMTksIDE2OjE3LCAiSm9obiBNYXR0c3NvbiIgPGpvaG4ubWF0 dHNzb25AZXJpY3Nzb24uY29tPjxtYWlsdG86am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+IHdy b3RlOg0KDQoNCg0KICAgIEhpLA0KDQoNCg0KICAgIEkgdGhpbmsgdGhlc2UgcmVmbGVjdGlvbiBh dHRhY2tzIGFyZSBtdWNoIG9sZGVyIHRoYW4gdGhpcy4gSSBxdWljaw0KDQpzZWFyY2ggZm9yIHJl ZmxlY3Rpb24gYXR0YWNrIHNlY3VyaXR5IHByb3RvY29sIGdpdmVzIGEgbG90IG9mIG9sZA0KDQpy ZXN1bHRzLCBUaGUgZGVzY3JpcHRpb24gb2YgcmVmbGVjdGlvbiBhdHRhY2sgaW4gdGhlIGZvbGxv d2luZyBsZWN0dXJlDQoNCm1hdGVyaWFsIGZyb20gMjAwOSBsb29rcyBqdXN0IGxpa2UgdGhlICJz ZWxmaWUgYXR0YWNrIiBvbiBUTFMgMS4zDQoNCiAgICBodHRwOi8vd3d3LmNzLmJoYW0uYWMudWsv fnRwYy9jd2kvVGVhY2hpbmcvRmlsZXMvTGVjdHVyZTRfNnVwLnBkZg0KDQoNCg0KICAgIFdpdGgg bXVsdGlwbGUgc2VjdGlvbnMgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0IGNoYW5nZSBhcyB3 ZWxsLg0KDQpJZiB0d28gbm9kZXMgdW5pbnRlbnRpb25hbGx5IGluaXRpYXRlIHNpbXVsdGFuZW91 cyBDbGllbnRIZWxsbyB0byBlYWNoDQoNCm90aGVyLCBldmVuIGlmIHRoZXkgb25seSB3YW50IGEg c2luZ2xlIHNlY3VyZSBjb25uZWN0aW9uIChJIGhhdmUgc2Vlbg0KDQpsaXZlIHN5c3RlbXMgd2hl cmUgdGhpcyBoYXBwZW5zIGluIHByYWN0aWNlKSwgYW4gYXR0YWNrZXIgY2FuIHNlbGVjdA0KDQp3 aGljaCBDbGllbnRIZWxsbyB0byBibG9jayAoZS5nLiB0aGUgb25lIHdpdGggdGhlIHN0cm9uZ2Vz dA0KDQpjcnlwdG9ncmFwaGljIHBhcmFtZXRlcnMpLiBUaGUgZm9sbG93aW5nIHNlY3VyaXR5IHBy b3BlcnR5IHdvdWxkIHRoZW4NCg0Kbm8gbG9uZ2VyIGhvbGQgOg0KDQoNCg0KICAgICAgIkRvd25n cmFkZSBwcm90ZWN0aW9uOiAgVGhlIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVycyBzaG91bGQgYmUg dGhlDQoNCiAgICAgICAgICBzYW1lIG9uIGJvdGggc2lkZXMgYW5kIHNob3VsZCBiZSB0aGUgc2Ft ZSBhcyBpZiB0aGUgcGVlcnMgaGFkIGJlZW4NCg0KICAgICAgICAgIGNvbW11bmljYXRpbmcgaW4g dGhlIGFic2VuY2Ugb2YgYW4gYXR0YWNrIg0KDQoNCg0KICAgIChJIGhhdmUgbm90IGxvb2tlZCBh dCB3aGF0IHRoZSBkZWZpbml0aW9ucyBpbiBbQkJGR0taMTZdIHNheSkuDQoNCg0KDQogICAgQ2hl ZXJzLA0KDQogICAgSm9obg0KDQoNCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoN CiAgICBGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86dGxzLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiSGFvLCBGZW5nIg0KDQo8RmVuZy5IYW9Ad2Fyd2ljay5h Yy51az48bWFpbHRvOkZlbmcuSGFvQHdhcndpY2suYWMudWs+DQoNCiAgICBEYXRlOiBUdWVzZGF5 LCAyNCBTZXB0ZW1iZXIgMjAxOSBhdCAxNjowOQ0KDQogICAgVG86IE1vaGl0IFNldGhpIE0gPG1v aGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PG1haWx0bzptb2hpdC5t LnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiwNCg0KIk93ZW4gRnJpZWwgKG9m cmllbCkiIDxvZnJpZWxAY2lzY28uY29tPjxtYWlsdG86b2ZyaWVsQGNpc2NvLmNvbT4sIEpvbmF0 aGFuIEhveWxhbmQNCg0KPGpvbmF0aGFuLmhveWxhbmRAZ21haWwuY29tPjxtYWlsdG86am9uYXRo YW4uaG95bGFuZEBnbWFpbC5jb20+DQoNCiAgICBDYzogIlRMU0BpZXRmLm9yZyI8bWFpbHRvOlRM U0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz48bWFpbHRvOnRsc0BpZXRmLm9yZz4NCg0KICAgIFN1 YmplY3Q6IFJlOiBbVExTXSBTZWxmaWUgYXR0YWNrIHdhcyBSZTogRGlzdGluZ3Vpc2hpbmcgYmV0 d2Vlbg0KDQpleHRlcm5hbC9yZXN1bXB0aW9uIFBTS3MNCg0KDQoNCg0KDQogICAgICAgIE9uIDIz LzA5LzIwMTksIDE4OjUwLCAiVExTIG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRoaSBNIg0KDQo8dGxz LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIDxtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5v cmdvbmJlaGFsZm9mbW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4N Cg0KbW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz48bWFpbHRvOnRs cy1ib3VuY2VzQGlldGYub3Jnb25iZWhhbGZvZm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21A ZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCg0KICAgICAgICAgICAgSGkgYWxsLA0KDQoNCg0K ICAgICAgICAgICAgT24gdGhlIHRvcGljIG9mIGV4dGVybmFsIFBTS3MgaW4gVExTIDEuMywgSSBm b3VuZCBhDQoNCnB1YmxpY2F0aW9uIG9uIHRoZQ0KDQogICAgICAgICAgICBTZWxmaWUgYXR0YWNr Og0KDQpodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPWRkNDMyZjEzLTgxYzllNWFk LWRkNDM2Zjg4LTg2OWExN2I1YjIxYi1kYzZjNmYwYTVkZDIxZmFmJnE9MSZ1PWh0dHBzJTNBJTJG JTJGZXByaW50LmlhY3Iub3JnJTJGMjAxOSUyRjM0Nw0KDQoNCg0KICAgICAgICAgICAgUGVyaGFw cyB0aGlzIHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gSSB0aG91Z2h0DQoNCnRo YXQgc2hhcmluZw0KDQogICAgICAgICAgICBpdCBhZ2FpbiB3b3VsZG4ndCBodXJ0IHdoaWxlIHdl IGRpc2N1c3MgaG93IHNlcnZlcnMNCg0KZGlzdGluZ3Vpc2ggYmV0d2Vlbg0KDQogICAgICAgICAg ICBleHRlcm5hbCBhbmQgcmVzdW1wdGlvbiBQU0tzLg0KDQoNCg0KICAgICAgICBJIGp1c3QgcmVh ZCB0aGUgcGFwZXIgd2l0aCBpbnRlcmVzdC4gSXQgb2NjdXJzIHRvIG1lIHRoYXQgdGhlDQoNCnNl bGZpZSBhdHRhY2sgaXMgY29uc2lzdGVudCB3aXRoIHRoZSAiaW1wZXJzb25hdGlvbiBhdHRhY2si IHRoYXQgd2UNCg0KcmVwb3J0ZWQgb24gU1BFS0UgaW4gMjAxNDsgc2VlIFNlYyA0LjEgWzFdIGFu ZCB0aGUgdXBkYXRlZCB2ZXJzaW9uIHdpdGgNCg0KZGV0YWlscyBvbiBob3cgU1BFS0UgaXMgcmV2 aXNlZCBpbiBJU08vSUVDIDExNzcwLTQgWzJdLiBUaGUgc2FtZSBhdHRhY2sNCg0KY2FuIGJlIHRy YWNlZCBiYWNrIHRvIDIwMTAgaW4gWzNdIHdoZXJlIGEgIndvcm0taG9sZSBhdHRhY2siIChGaWcu IDUsDQoNClszXSkgaXMgcmVwb3J0ZWQgb24gdGhlIHNlbGYtY29tbXVuaWNhdGlvbiBtb2RlIG9m IEhNUVYuIFRoZSBlc3NlbmNlIG9mDQoNCnRoZXNlIGF0dGFja3MgaXMgdGhlIHNhbWU6IEJvYiB0 cmlja3MgQWxpY2UgaW50byB0aGlua2luZyB0aGF0IHNoZSBpcw0KDQp0YWxraW5nIHRvIGF1dGhl bnRpY2F0ZWQgQm9iLCBidXQgc2hlIGlzIGFjdHVhbGx5IHRhbGtpbmcgdG8gaGVyc2VsZi4NCg0K SW4gWzNdLCB3ZSBleHBsYWluZWQgdGhhdCB0aGUgYXR0YWNrIHdhcyBtaXNzZWQgZnJvbSB0aGUg InNlY3VyaXR5DQoNCnByb29mcyIgYXMgdGhlIHByb29mcyBkaWRuJ3QgY29uc2lkZXIgbXVsdGlw bGUgc2Vzc2lvbnMuDQoNCg0KDQogICAgICAgIFRoZSBjb3VudGVybWVhc3VyZSB3ZSBwcm9wb3Nl ZCBpbiBbMS0zXSB3YXMgdG8gZW5zdXJlIHRoZSB1c2VyDQoNCmlkZW50aXR5IGlzIHVuaXF1ZSBp biBrZXkgZXhjaGFuZ2UgcHJvY2Vzc2VzOiBpbiBjYXNlIG9mIG11bHRpcGxlDQoNCnNlc3Npb25z IHRoYXQgbWF5IGNhdXNlIGNvbmZ1c2lvbiBpbiB0aGUgdXNlciBpZGVudGl0eSwgYW4gZXh0ZW5z aW9uDQoNCnNob3VsZCBiZSBhZGRlZCB0byB0aGUgdXNlciBpZGVudGl0eSB0byBkaXN0aW5ndWlz aCB0aGUgaW5zdGFuY2VzLiBUaGUNCg0KdW5kZXJseWluZyBpbnR1aXRpb24gaXMgdGhhdCBvbmUg c2hvdWxkIGtub3cgInVuYW1iaWd1b3VzbHkiIHdob20gdGhleQ0KDQphcmUgY29tbXVuaWNhdGlu ZyB3aXRoLCBhbmQgcGVyZm9ybSBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiB0aGF0LiBUaGUNCg0K ZGlzY292ZXJ5IG9mIHRoaXMgdHlwZSBvZiBhdHRhY2tzIGFuZCB0aGUgcHJvcG9zZWQgc29sdXRp b24gYXJlDQoNCmluc3BpcmVkIGJ5IHRoZSAiZXhwbGljaXRuZXNzIHByaW5jaXBsZSIgKFJvc3Mg QW5kZXJzb24gYW5kIFJvZ2VyDQoNCk5lZWRoYW0sIENyeXB0byc5NSksIHdoaWNoIHN0YXRlcyB0 aGUgaW1wb3J0YW5jZSBvZiBiZWluZyBleHBsaWNpdCBvbg0KDQp1c2VyIGlkZW50aXRpZXMgYW5k IG90aGVyIGF0dHJpYnV0ZXMgaW4gYSBwdWJsaWMga2V5IHByb3RvY29sOyBhbHNvIHNlZQ0KDQpb M10uIEkgaG9wZSBpdCBtaWdodCBiZSB1c2VmdWwgdG8gcGVvcGxlIHdobyB3b3JrIG9uIFRMUyBQ U0suDQoNCg0KDQogICAgICAgIFsxXQ0KDQpodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3Vy bD9rPTVhODIyNTEzLTA2MDhlZmFkLTVhODI2NTg4LTg2OWExN2I1YjIxYi1lYjI2MDE1MWY3OGIw NzE4JnE9MSZ1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxNCUyRjU4NS5wZGYN Cg0KICAgICAgICBbMl0gaHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE4MDIuMDQ5MDANCg0KICAgICAg ICBbM10NCg0KaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az1kNWJmODhmZi04OTM1 NDI0MS1kNWJmYzg2NC04NjlhMTdiNWIyMWItMGU5YjNiZjU4ZTEwNGYzMiZxPTEmdT1odHRwcyUz QSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTAlMkYxMzYucGRmDQoNCg0KDQoNCg0KICAgICAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICAg ICAgIFRMUyBtYWlsaW5nIGxpc3QNCg0KICAgICAgICBUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0Bp ZXRmLm9yZz4NCg0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Rscw0KDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KVExTIG1haWxpbmcgbGlzdA0KDQpUTFNAaWV0Zi5vcmc8bWFpbHRv OlRMU0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNClRMUyBtYWlsaW5nIGxpc3QNCg0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+ DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo= --_000_1107173FE6D84882A8A2A74B6BB20427ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3 MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIE1vaGl0LCB0aGF0IGFyZSBnb29kIHBv aW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBU aGUgcmVhbGl0eSBob3dldmVyIGlzIHRoYXQgaW4gbW9zdCBncm91cCBQU0sgc2NlbmFyaW9zLCB0 aGUgbm9kZXMgZG9uJ3QgaGF2ZSBhbnkgc3Ryb25nIGlkZW50aXRpZXMgdGhhdCBjYW4gYmUgdmVy aWZpZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SSBhc3N1bWUgYmxvY2tpbmcgYWxsIGlkZW50aXRpZXMgdGhhdCBhcmUg bm90IHRoZSBub2RlcyBvd24gaWRlbnRpdHkgd291bGQgbWl0aWdhdGUgdGhlIGF0dGFja3MsIGJ1 dCBsZWFkIHRvIGF2YWlsYWJpbGl0eSBwcm9ibGVtcyBhcyB0d28gbm9kZXMgd2l0aCB0aGUgc2Ft ZSBjaG9zZW4gaWRlbnRpdHkgY2Fubm90IHRhbGsgdG8gZWFjaCBvdGhlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDtXaGF0IHlvdSBzaG91bGQgaW5zdGVhZCAob3IgYWRkaXRpb25hbGx5KSBzYXkg aW4gdGhlIHRleHQgaXMgdGhhdCBhIG5vZGUgc2hvdWxkIGNoZWNrIHRoYXQgdGhlIGNsaWVudF9t YWMgYW5kIHNlcnZlcl9tYWMgKG9yIGFueSAmZ3Q7b3RoZXIgaWRlbnRpdGllcyB1c2VkKQ0KPGI+ YXJlIG5ldmVyIHRoZSBzYW1lPC9iPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgY2hlY2tp bmcgQ2xpZW50SGVsbG8ucmFuZG9tIGlzIGVub3VnaC4gQmVsb3cgaXMgd2hhdCB3ZSB3cm90ZSBp bjxicj4NCjwvc3Bhbj48dT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsdWUiPjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWxhbmRlci1hY2UtY29z ZS1lY2RoZS0xNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlbGFuZGVyLWFj ZS1jb3NlLWVjZGhlLTE0PC9hPjwvc3Bhbj48L3U+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyDigJw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SWYgdHdvIG5vZGVz IHVuaW50ZW50aW9uYWxseSBpbml0aWF0ZSB0d28gc2ltdWx0YW5lb3VzIEVESE9DIG1lc3NhZ2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgZXhj aGFuZ2VzIHdpdGggZWFjaCBvdGhlciBldmVuIGlmIHRoZXkgb25seSB3YW50IHRvIGNvbXBsZXRl IGEgc2luZ2xlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 Jm5ic3A7IEVESE9DIG1lc3NhZ2UgZXhjaGFuZ2UsIHRoZXkgTUFZIHRlcm1pbmF0ZSB0aGUgZXhj aGFuZ2Ugd2l0aCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDsmbmJzcDsgbGV4aWNvZ3JhcGhpY2FsbHkgc21hbGxlc3QgR19YLiZuYnNwOyBJZiB0aGUg dHdvIEdfWCB2YWx1ZXMgYXJlIGVxdWFsLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgcmVjZWl2ZWQgbWVzc2FnZV8xIE1VU1QgYmUgZGlz Y2FyZGVkIHRvIG1pdGlnYXRlIHJlZmxlY3Rpb24gYXR0YWNrcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgTm90ZSB0aGF0IGluIHRoZSBjYXNl IG9mIHR3byBzaW11bHRhbmVvdXMgRURIT0MgZXhjaGFuZ2VzIHdoZXJlIHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyBub2RlcyBvbmx5IGNv bXBsZXRlIG9uZSBhbmQgd2hlcmUgdGhlIG5vZGVzIGhhdmUgZGlmZmVyZW50IHByZWZlcnJlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyBjaXBo ZXIgc3VpdGVzLCBhbiBhdHRhY2tlciBjYW4gYWZmZWN0IHdoaWNoIG9mIHRoZSB0d28gbm9kZXMn PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7IHBy ZWZlcnJlZCBjaXBoZXIgc3VpdGVzIHdpbGwgYmUgdXNlZCBieSBibG9ja2luZyB0aGUgb3RoZXIg ZXhjaGFuZ2Uu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Sm9objxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+VExTICZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVo YWxmIG9mIE1vaGl0IFNldGhpIE0gJmx0O21vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDggT2N0b2JlciAyMDE5 IGF0IDExOjU3PGJyPg0KPGI+VG86IDwvYj5DaHJpc3RvcGhlciBXb29kICZsdDtjYXdAaGVhcGlu Z2JpdHMubmV0Jmd0OywgJnF1b3Q7VExTQGlldGYub3JnJnF1b3Q7ICZsdDt0bHNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVExTXSBTZWxmaWUgYXR0YWNrPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIENocmlzLDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9yIHRoZSBiZW5lZml0IG9mIHRoZSBsaXN0LCBsZXQg bWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMgb25seSByZWxldmFudCB3aGVy ZSBtdWx0aXBsZSBwYXJ0aWVzIHNoYXJlIHRoZSBzYW1lIFBTSyBhbmQgdXNlIHRoZSBzYW1lIFBT SyBmb3Igb3V0Z29pbmcgYW5kIGluY29taW5nIGNvbm5lY3Rpb25zLiBUaGVzZSBzaXR1YXRpb25z IGFyZSByYXRoZXIgcmFyZSwgYnV0IEkNCiBhY2NlcHQgdGhhdCBUTFMgaXMgd2lkZWx5IHVzZWQg KGFuZCBzb21ldGltZXMgbWlzdXNlZCkgaW4gbWFueSBwbGFjZXMuPG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGUgU2VsZmllIGF0dGFjayBvbmx5IGhhcHBl bnMgd2hlbiBhbiBlbnRpdHkgd2l0aCB0aGUgUFNLIGFjdHMgbWFsaWNpb3VzbHkuIFNvIEkgdGhp bmsgdGhlIGZhY3QgdGhhdCB5b3Ugd3JpdGUgaW4gdGhlIGRyYWZ0OiAmcXVvdDtlYWNoIG5vZGUg bXVzdCBiZSB0cnVzdGVkIG5vdCB0byBpbXBlcnNvbmF0ZSBhbm90aGVyIG5vZGUncyByb2xlJnF1 b3Q7IGRvZXMgbm90IHRha2UgaW50byBhY2NvdW50IHRoYXQgdGhlcmUNCiBtdXN0IGJlIGEgbWFs aWNpb3VzIG5vZGUgZm9yIHRoZSBzZWxmaWUgYXR0YWNrIHRvIGhhcHBlbiBpbiB0aGUgZmlyc3Qg cGxhY2UuIDxvOnA+DQo8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5E cnVja2VyIGFuZCBHdWVyb24ncyBwYXBlciByZWNvbW1lbmRzIHRoYXQgJnF1b3Q7ZXZlcnkgcGFy dGljaXBhdGluZyBwYXJ0eSBnZXRzIChkdXJpbmcgdGhlIHNldHVwIG9mIHRoZSBuZXR3b3JrKSBh IHVuaXF1ZSBpZGVudGl0eSZxdW90OyBhbmQgJnF1b3Q7dGhlIGNsaWVudCBhbmQgdGhlIHNlcnZl ciBtdXN0IHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgdGhlIGNsYWltZWQgaWRlbnRpdGllcy4mcXVv dDsuIFRoZSByZWFsaXR5IGhvd2V2ZXINCiBpcyB0aGF0IGluIG1vc3QgZ3JvdXAgUFNLIHNjZW5h cmlvcywgdGhlIG5vZGVzIGRvbid0IGhhdmUgYW55IHN0cm9uZyBpZGVudGl0aWVzIHRoYXQgY2Fu IGJlIHZlcmlmaWVkLg0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij5XaGF0IHlvdSBzaG91bGQgaW5zdGVhZCAob3IgYWRkaXRpb25hbGx5KSBzYXkgaW4gdGhl IHRleHQgaXMgdGhhdCBhIG5vZGUgc2hvdWxkIGNoZWNrIHRoYXQgdGhlIGNsaWVudF9tYWMgYW5k IHNlcnZlcl9tYWMgKG9yIGFueSBvdGhlciBpZGVudGl0aWVzIHVzZWQpDQo8Yj5hcmUgbmV2ZXIg dGhlIHNhbWU8L2I+LiBXaXRob3V0IHRoaXMgY2hlY2ssIHRoZSBzZWxmaWUgYXR0YWNrIHdvdWxk IHN0aWxsIGJlIHBvc3NpYmxlLiBBbmQgYXQgbGVhc3QgdGhpcyBkb2VzIG5vdCByZXF1aXJlIHN0 cm9uZyBpZGVudGl0eSB2ZXJpZmljYXRpb24gZm9yIHByZXZlbnRpbmcgc2VsZmllIGF0dGFja3Mu DQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPi0tTW9oaXQ8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5PbiAxMC81LzE5IDI6NDEgUE0sIENocmlzdG9waGVyIFdvb2Qgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5IaSBGZW5nLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPkZvciB3aGF0IGl0J3Mgd29ydGgsIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgUFNLIGlt cG9ydGVycyBkcmFmdCBpbmNsdWRlcyBhICZxdW90O2NvbnRleHQmcXVvdDsgZmllbGQgaW50byB3 aGljaCBpZGVudGl0eSBpbmZvcm1hdGlvbiBjYW4gYmUgZmVkOjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWltcG9y dGVyLTAxI2FwcGVuZGl4LUIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRscy1leHRlcm5hbC1wc2staW1wb3J0ZXItMDEjYXBwZW5kaXgtQjwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CZXN0LDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNocmlzPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBTZXAgMjQsIDIwMTks IGF0IDk6MTkgQU0sIEhhbywgRmVuZyB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIEpvaG4sPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+UmVmbGVjdGlvbiBhdHRhY2tzIGFyZSBpbmRlZWQg b2xkZXIsIGJ1dCB0aGUgc2VsZmllIGF0dGFjayBpcyBhIGJpdCA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5kaWZmZXJlbnQuIEl0J3MgYWN0dWFsbHkg YSB2YXJpYW50IG9mIHRoZSB1bmtub3duIGtleSBzaGFyZSBhdHRhY2suIEEgPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dHlwaWNhbCBleGFtcGxlIG9m IHRoZSBVS1MgYXR0YWNrIGlzIHRoZSBvbmUgcmVwb3J0ZWQgb24gTVFWIGJ5IEthbGlza2kgPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+aW4gMjAwMSAo c2VlICZxdW90O0FuIHVua25vd24ga2V5LXNoYXJlIGF0dGFjayBvbiB0aGUgTVFWIGtleSBhZ3Jl ZW1lbnQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ cHJvdG9jb2wmcXVvdDsgaW4gQUNNIFRJU1NFQyAyMDAxKS4gSW4gdGhhdCBleGFtcGxlLCB0aGUg YWR2ZXJzYXJ5IHBsYXlzIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPm1lc3NhZ2UgYmV0d2VlbiB0d28gdXNlcnMgdG8gY2F1c2UgY29uZnVzaW9uIGlu IHRoZSBpZGVudGl0eSwgYnV0IGluIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPlNlbGZpZSwgdGhlIGFkdmVyc2FyeSBwbGF5cyBtZXNzYWdlIHdpdGgg b25seSBvbmUgdXNlciBhbmQgdXNlcyBhbm90aGVyIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmluc3RhbmNlIG9mIHRoZSB1c2VyIHRvIGNhdXNlIGNv bmZ1c2lvbiBpbiB0aGUgaWRlbnRpdHkuIFdoZW4gd2UgPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+cmVwb3J0ZWQgdGhpcyB2YXJpYW50IG9mIFVLUyBp biBbM10sIHdlIHdlcmUgbm90IGF3YXJlIG9mIGFueXRoaW5nIGxpa2UgPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dGhhdCBpbiB0aGUgbGl0ZXJhdHVy ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5DaGVl cnMsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RmVu ZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDI0 LzA5LzIwMTksIDE2OjE3LCAmcXVvdDtKb2huIE1hdHRzc29uJnF1b3Q7IDxhIGhyZWY9Im1haWx0 bzpqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSI+Jmx0O2pvaG4ubWF0dHNzb25AZXJpY3Nzb24u Y29tJmd0OzwvYT4gd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhpLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtJIHRoaW5rIHRoZXNlIHJlZmxlY3Rpb24gYXR0YWNrcyBhcmUgbXVjaCBvbGRlciB0 aGFuIHRoaXMuIEkgcXVpY2sgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+c2VhcmNoIGZvciByZWZsZWN0aW9uIGF0dGFjayBzZWN1cml0eSBwcm90b2Nv bCBnaXZlcyBhIGxvdCBvZiBvbGQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+cmVzdWx0cywgVGhlIGRlc2NyaXB0aW9uIG9mIHJlZmxlY3Rpb24gYXR0 YWNrIGluIHRoZSBmb2xsb3dpbmcgbGVjdHVyZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5tYXRlcmlhbCBmcm9tIDIwMDkgbG9va3MganVzdCBsaWtl IHRoZSAmcXVvdDtzZWxmaWUgYXR0YWNrJnF1b3Q7IG9uIFRMUyAxLjM8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPGEg aHJlZj0iaHR0cDovL3d3dy5jcy5iaGFtLmFjLnVrL350cGMvY3dpL1RlYWNoaW5nL0ZpbGVzL0xl Y3R1cmU0XzZ1cC5wZGYiPmh0dHA6Ly93d3cuY3MuYmhhbS5hYy51ay9+dHBjL2N3aS9UZWFjaGlu Zy9GaWxlcy9MZWN0dXJlNF82dXAucGRmPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtXaXRoIG11bHRpcGxlIHNlY3Rpb25zIHRoZXJlIGFyZSBvdGhlciB0aGluZ3MgdGhhdCBjaGFu Z2UgYXMgd2VsbC4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+SWYgdHdvIG5vZGVzIHVuaW50ZW50aW9uYWxseSBpbml0aWF0ZSBzaW11bHRhbmVvdXMg Q2xpZW50SGVsbG8gdG8gZWFjaCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5vdGhlciwgZXZlbiBpZiB0aGV5IG9ubHkgd2FudCBhIHNpbmdsZSBzZWN1 cmUgY29ubmVjdGlvbiAoSSBoYXZlIHNlZW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+bGl2ZSBzeXN0ZW1zIHdoZXJlIHRoaXMgaGFwcGVucyBpbiBw cmFjdGljZSksIGFuIGF0dGFja2VyIGNhbiBzZWxlY3QgPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+d2hpY2ggQ2xpZW50SGVsbG8gdG8gYmxvY2sgKGUu Zy4gdGhlIG9uZSB3aXRoIHRoZSBzdHJvbmdlc3QgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Y3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzKS4gVGhlIGZv bGxvd2luZyBzZWN1cml0eSBwcm9wZXJ0eSB3b3VsZCB0aGVuIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPm5vIGxvbmdlciBob2xkIDo8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7RG93bmdyYWRlIHByb3RlY3Rp b246Jm5ic3A7IFRoZSBjcnlwdG9ncmFwaGljIHBhcmFtZXRlcnMgc2hvdWxkIGJlIHRoZTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzYW1lIG9uIGJvdGgg c2lkZXMgYW5kIHNob3VsZCBiZSB0aGUgc2FtZSBhcyBpZiB0aGUgcGVlcnMgaGFkIGJlZW48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tbXVuaWNhdGlu ZyBpbiB0aGUgYWJzZW5jZSBvZiBhbiBhdHRhY2smcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286 cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7KEkgaGF2ZSBub3QgbG9va2VkIGF0IHdoYXQgdGhlIGRlZmluaXRpb25zIGluIFtC QkZHS1oxNl0gc2F5KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q2hlZXJzLDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyBKb2huPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb206IFRMUyA8YSBocmVmPSJtYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmciPiZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9uIGJlaGFs ZiBvZiAmcXVvdDtIYW8sIEZlbmcmcXVvdDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0ibWFpbHRvOkZlbmcuSGFvQHdhcndpY2suYWMu dWsiPiZsdDtGZW5nLkhhb0B3YXJ3aWNrLmFjLnVrJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgRGF0ZTog VHVlc2RheSwgMjQgU2VwdGVtYmVyIDIwMTkgYXQgMTY6MDk8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4gJm5ic3A7Jm5ic3A7Jm5ic3A7VG86IE1vaGl0 IFNldGhpIE0gPGEgaHJlZj0ibWFpbHRvOm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmciPiZsdDttb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYu b3JnJmd0OzwvYT4sIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZxdW90O093ZW4gRnJpZWwgKG9mcmllbCkmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOm9m cmllbEBjaXNjby5jb20iPiZsdDtvZnJpZWxAY2lzY28uY29tJmd0OzwvYT4sIEpvbmF0aGFuIEhv eWxhbmQgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuLmhveWxhbmRAZ21haWwuY29tIj4mbHQ7am9uYXRoYW4u aG95bGFuZEBnbWFpbC5jb20mZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBDYzogPGEgaHJlZj0ibWFpbHRv OlRMU0BpZXRmLm9yZyI+JnF1b3Q7VExTQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBocmVmPSJtYWls dG86dGxzQGlldGYub3JnIj4mbHQ7dGxzQGlldGYub3JnJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgU3Vi amVjdDogUmU6IFtUTFNdIFNlbGZpZSBhdHRhY2sgd2FzIFJlOiBEaXN0aW5ndWlzaGluZyBiZXR3 ZWVuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmV4 dGVybmFsL3Jlc3VtcHRpb24gUFNLczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtPbiAyMy8wOS8yMDE5LCAxODo1MCwgJnF1b3Q7VExTIG9uIGJlaGFsZiBvZiBNb2hpdCBT ZXRoaSBNJnF1b3Q7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxhIGhyZWY9Im1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ29uYmVoYWxmb2Ztb2hp dC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIj4mbHQ7dGxzLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIDxvOnA+PC9vOnA+PC9hPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBjbGFzcz0iTXNvSHlwZXJsaW5rIj48YSBocmVmPSJt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmdvbmJlaGFsZm9mbW9oaXQubS5zZXRoaT00MGVyaWNz c29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+bW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFy Yy5pZXRmLm9yZyZndDs8L2E+PC9zcGFuPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SGkgYWxsLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtPbiB0aGUgdG9waWMgb2Yg ZXh0ZXJuYWwgUFNLcyBpbiBUTFMgMS4zLCBJIGZvdW5kIGEgPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+cHVibGljYXRpb24gb24gdGhlIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1NlbGZpZSBhdHRhY2s6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9ZGQ0 MzJmMTMtODFjOWU1YWQtZGQ0MzZmODgtODY5YTE3YjViMjFiLWRjNmM2ZjBhNWRkMjFmYWYmYW1w O3E9MSZhbXA7dT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTklMkYzNDciPmh0 dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9ZGQ0MzJmMTMtODFjOWU1YWQtZGQ0MzZm ODgtODY5YTE3YjViMjFiLWRjNmM2ZjBhNWRkMjFmYWYmYW1wO3E9MSZhbXA7dT1odHRwcyUzQSUy RiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTklMkYzNDc8L2E+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1BlcmhhcHMg dGhpcyB3YXMgYWxyZWFkeSBkaXNjdXNzZWQgb24gdGhlIGxpc3QuIEkgdGhvdWdodCA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50aGF0IHNoYXJpbmcg PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7aXQgYWdhaW4gd291bGRuJ3QgaHVydCB3aGlsZSB3ZSBkaXNjdXNzIGhvdyBzZXJ2 ZXJzIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmRp c3Rpbmd1aXNoIGJldHdlZW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXh0ZXJuYWwgYW5kIHJlc3VtcHRpb24gUFNLcy48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSBqdXN0IHJlYWQg dGhlIHBhcGVyIHdpdGggaW50ZXJlc3QuIEl0IG9jY3VycyB0byBtZSB0aGF0IHRoZSA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5zZWxmaWUgYXR0YWNr IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgJnF1b3Q7aW1wZXJzb25hdGlvbiBhdHRhY2smcXVvdDsg dGhhdCB3ZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5yZXBvcnRlZCBvbiBTUEVLRSBpbiAyMDE0OyBzZWUgU2VjIDQuMSBbMV0gYW5kIHRoZSB1cGRh dGVkIHZlcnNpb24gd2l0aCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5kZXRhaWxzIG9uIGhvdyBTUEVLRSBpcyByZXZpc2VkIGluIElTTy9JRUMgMTE3 NzAtNCBbMl0uIFRoZSBzYW1lIGF0dGFjayA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5jYW4gYmUgdHJhY2VkIGJhY2sgdG8gMjAxMCBpbiBbM10gd2hl cmUgYSAmcXVvdDt3b3JtLWhvbGUgYXR0YWNrJnF1b3Q7IChGaWcuIDUsIDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlszXSkgaXMgcmVwb3J0ZWQgb24g dGhlIHNlbGYtY29tbXVuaWNhdGlvbiBtb2RlIG9mIEhNUVYuIFRoZSBlc3NlbmNlIG9mIDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRoZXNlIGF0dGFj a3MgaXMgdGhlIHNhbWU6IEJvYiB0cmlja3MgQWxpY2UgaW50byB0aGlua2luZyB0aGF0IHNoZSBp cyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50YWxr aW5nIHRvIGF1dGhlbnRpY2F0ZWQgQm9iLCBidXQgc2hlIGlzIGFjdHVhbGx5IHRhbGtpbmcgdG8g aGVyc2VsZi4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+SW4gWzNdLCB3ZSBleHBsYWluZWQgdGhhdCB0aGUgYXR0YWNrIHdhcyBtaXNzZWQgZnJvbSB0 aGUgJnF1b3Q7c2VjdXJpdHkgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+cHJvb2ZzJnF1b3Q7IGFzIHRoZSBwcm9vZnMgZGlkbid0IGNvbnNpZGVyIG11 bHRpcGxlIHNlc3Npb25zLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgY291bnRlcm1l YXN1cmUgd2UgcHJvcG9zZWQgaW4gWzEtM10gd2FzIHRvIGVuc3VyZSB0aGUgdXNlciA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pZGVudGl0eSBpcyB1 bmlxdWUgaW4ga2V5IGV4Y2hhbmdlIHByb2Nlc3NlczogaW4gY2FzZSBvZiBtdWx0aXBsZSA8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5zZXNzaW9ucyB0 aGF0IG1heSBjYXVzZSBjb25mdXNpb24gaW4gdGhlIHVzZXIgaWRlbnRpdHksIGFuIGV4dGVuc2lv biA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5zaG91 bGQgYmUgYWRkZWQgdG8gdGhlIHVzZXIgaWRlbnRpdHkgdG8gZGlzdGluZ3Vpc2ggdGhlIGluc3Rh bmNlcy4gVGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPnVuZGVybHlpbmcgaW50dWl0aW9uIGlzIHRoYXQgb25lIHNob3VsZCBrbm93ICZxdW90O3Vu YW1iaWd1b3VzbHkmcXVvdDsgd2hvbSB0aGV5IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPmFyZSBjb21tdW5pY2F0aW5nIHdpdGgsIGFuZCBwZXJmb3Jt IGF1dGhlbnRpY2F0aW9uIGJhc2VkIG9uIHRoYXQuIFRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5kaXNjb3Zlcnkgb2YgdGhpcyB0eXBlIG9mIGF0 dGFja3MgYW5kIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBhcmUgPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+aW5zcGlyZWQgYnkgdGhlICZxdW90O2V4cGxp Y2l0bmVzcyBwcmluY2lwbGUmcXVvdDsgKFJvc3MgQW5kZXJzb24gYW5kIFJvZ2VyIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk5lZWRoYW0sIENyeXB0 byc5NSksIHdoaWNoIHN0YXRlcyB0aGUgaW1wb3J0YW5jZSBvZiBiZWluZyBleHBsaWNpdCBvbiA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij51c2VyIGlk ZW50aXRpZXMgYW5kIG90aGVyIGF0dHJpYnV0ZXMgaW4gYSBwdWJsaWMga2V5IHByb3RvY29sOyBh bHNvIHNlZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij5bM10uIEkgaG9wZSBpdCBtaWdodCBiZSB1c2VmdWwgdG8gcGVvcGxlIHdobyB3b3JrIG9uIFRM UyBQU0suPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1sxXSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVl eWUuY29tL3VybD9rPTVhODIyNTEzLTA2MDhlZmFkLTVhODI2NTg4LTg2OWExN2I1YjIxYi1lYjI2 MDE1MWY3OGIwNzE4JmFtcDtxPTEmYW1wO3U9aHR0cHMlM0ElMkYlMkZlcHJpbnQuaWFjci5vcmcl MkYyMDE0JTJGNTg1LnBkZiI+aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az01YTgy MjUxMy0wNjA4ZWZhZC01YTgyNjU4OC04NjlhMTdiNWIyMWItZWIyNjAxNTFmNzhiMDcxOCZhbXA7 cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxNCUyRjU4NS5wZGY8 L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1syXSA8YSBocmVmPSJodHRw czovL2FyeGl2Lm9yZy9hYnMvMTgwMi4wNDkwMCI+aHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE4MDIu MDQ5MDA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFszXSA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRw czovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPWQ1YmY4OGZmLTg5MzU0MjQxLWQ1YmZjODY0 LTg2OWExN2I1YjIxYi0wZTliM2JmNThlMTA0ZjMyJmFtcDtxPTEmYW1wO3U9aHR0cHMlM0ElMkYl MkZlcHJpbnQuaWFjci5vcmclMkYyMDEwJTJGMTM2LnBkZiI+aHR0cHM6Ly9wcm90ZWN0Mi5maXJl ZXllLmNvbS91cmw/az1kNWJmODhmZi04OTM1NDI0MS1kNWJmYzg2NC04NjlhMTdiNWIyMWItMGU5 YjNiZjU4ZTEwNGYzMiZhbXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3Jn JTJGMjAxMCUyRjEzNi5wZGY8L2E+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFRMUyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg PGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHM8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VExTIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UTFMgbWFpbGluZyBsaXN0PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0ibWFpbHRvOlRM U0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs czwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_1107173FE6D84882A8A2A74B6BB20427ericssoncom_-- From nobody Tue Oct 8 03:28:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39001200B8; Tue, 8 Oct 2019 03:28:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8QW4oaj7a6jD; Tue, 8 Oct 2019 03:28:26 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0630.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C98A120089; Tue, 8 Oct 2019 03:28:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pnqr30R1kMrjP+NryVZ10RTnZgvNSZqxMMkJIn57s9x5PetBsbggjqDEJxSX/02vdtEI6+cxVAq55A7BqBat4nBHuONFoOpq682oX5ZeJ1vOcJcp+KBAKuj9qFse6FYDBmD1Cvz5m5vGmG2SxOUWC5VgNj5H0SptbfGCiViiRCPPZZj9cKV0onenXLFKhhVif5ly4ysGYWPefcBniCPDc/LiJ3beKasmmt+aM+EP5tkq/65xBiAJkR4PAOVxU++Eh+ZfzAFdXEPwdy8llcBPbaf7vIK2427Equlh8taXiqHMd68eKxH6jiX+Gox4f3P2X5BRs7KgfMhh1U7UNhhnqg== 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=t3EvD+r5SjGb5Wfgjd6leSduXXwVsWyPFJW5YlOFTJs=; b=H7Rim0Y2dXqGd4N7lYL8K16lGwBT47NB1fqnJOAl/wGsaTDx3x9rx3/BJwhJDYbQdewJRUOxR40RqQlay8U5ydVoQQYSKLvvoPsRvpUnldldp3V3XAIo1jwKo+44iRJO0kVTv/qXgXh5fqXAocI3BC9tdJWojbY/fMXCyGaiHxeMqUKlqxyoOzR/i0WyPoATMIiIPiSF+k58HljWUddfnxhqJJRmlzxlUMW5Zqe73427cGfaTMUp3ufKCFwaMgPS51gNL+4LzSVl+TS11y7TWcQffZ4Qo9HKLBxa73zJjEULwjjrWr/heeKhR+V2Lp8oIeDgGXxg2xvK537q5+ziDg== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t3EvD+r5SjGb5Wfgjd6leSduXXwVsWyPFJW5YlOFTJs=; b=hjvNIgL4fr472+vaIf0ExAgE+797o21PwzT4diGBdkY8FJ21nY2lHEVECUDXnWNehekrhL1jOj3hQI0sMuOSg9gUf1G/OY+V1LnF6ETwUf7EufxkvFuNT/zHsEveHUiAU4QtIt3+tZBiwr6DLhUeJXagOGutaBBSVEY0/uFzj7A= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4284.eurprd07.prod.outlook.com (20.176.166.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.11; Tue, 8 Oct 2019 10:28:23 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2347.016; Tue, 8 Oct 2019 10:28:23 +0000 From: John Mattsson To: Rob Sayre , Sean Turner CC: "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" , "draft-ietf-rtcweb-security-arch.ad@ietf.org" , Benjamin Kaduk Thread-Topic: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 Thread-Index: AQHVLbNwka9w/WHllUqjsaoZBuXNvKdGI6+AgACqmwCAAR2pgIAAAOyAgAA5OQCAAvjIAIAACdKAgAABSgCAAALPgIADXp6AgAGCvICAAC2cAIAASBmAgABL5ACAAHyaAA== Date: Tue, 8 Oct 2019 10:28:23 +0000 Message-ID: <13CE39A7-2F51-4058-825E-60E2DFE3B28C@ericsson.com> References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 038716b3-e62f-4996-5e63-08d74bda3f66 x-ms-traffictypediagnostic: HE1PR07MB4284: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(376002)(39860400002)(396003)(189003)(199004)(66066001)(229853002)(36756003)(5660300002)(7736002)(316002)(71190400001)(86362001)(71200400001)(2906002)(6486002)(14454004)(58126008)(236005)(64756008)(66946007)(8676002)(26005)(14444005)(81156014)(91956017)(6436002)(44832011)(81166006)(76116006)(54896002)(6306002)(99286004)(486006)(186003)(6116002)(6512007)(256004)(8936002)(4326008)(66556008)(66476007)(476003)(478600001)(2616005)(33656002)(25786009)(3846002)(102836004)(54906003)(6506007)(76176011)(11346002)(110136005)(53546011)(6246003)(446003)(66446008); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4284; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JoQMEglZsY9P/oU4DGGxmD40F96I8SSiMmLdxSwUZCQspasMWnkOxOfz9PvfD05GEKRtqifTxIod+dXieg9/aGZ9c7U5I1wK9xC9kQ++qoa6ol+C+bxOE/w37QnwPX+PBmrd+QRq9nZ3o30t5vWIOZkazRfXXl7DuCS6trj0GYQmBXgDqvZjQxAr5zcjiUPvGEpF5r1kjfjRrOn4uOebIdHq1D7dpt25mZa8UoIMwsoxF9NFbHTqyRUTDQNds12ZOkJejTOD36yHyZIgn8IS1Pm8QKji0p29M/KZKfTqFwOfP7Pv9oxy6YytCaJS2+FQ/vqy6Ps1z4SJ8aUKtZEibuB1ydGWmYa/iGwOcazs+iwepPMD11AcwzgrHHQ5ZMlzml5Hdvtodjvp7rUTcD68mnkkfdbfLBkEq9UMVBUmxXo= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_13CE39A72F514058825E60E2DFE3B28Cericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 038716b3-e62f-4996-5e63-08d74bda3f66 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 10:28:23.2662 (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: 4VqfSFiGN83rVR2NDH/baMH7Hw4yvKVjQ3jhHJMd/XmQtvq6zykUsnPN2Mk8hV4Mk001PxvBgK5Ob8Eq+wpy/EV+s4gRhEB6WdvTYwv5Z/w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4284 Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 10:28:29 -0000 --_000_13CE39A72F514058825E60E2DFE3B28Cericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHdheSBJIHNlZSBpdCwgdGhlIHVwY29taW5nIEJDUCBhcHBsaWVzIHRvIFdlYlJUQyBpcnJl c3BlY3RpdmVseSBvZiB3aGV0aGVyIGl0IGZvcm1hbGx5IHVwZGF0ZXMgdGhlIGRvY3VtZW50IG9y IG5vdC4gVGhlIGZvcm1hbCB1cGRhdGVzIGFyZSBpbXBvcnRhbnQgc28gcGVvcGxlIGVhc2lseSBm aW5kIHRoZSBCQ1AsIGJ1dCBub3QgY3JpdGljYWwuIENvbXBhbmllcyBjYW4gYW55d2F5IGNob29z ZSB0byBpbXBsZW1lbnQgV2ViUlRDIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSBCQ1AuDQoNCkkg ZG8gbm90IHRoaW5rIHRoZSBCQ1AgbmVlZCB0byBjaGFuZ2UgYW55IHRleHQgaW4gdGhlIFdlYlJU QyBkcmFmdC4gVGhlIEJDUCB1cGRhdGVzIGEgbG90IG9mIG90aGVyIFJGQ3Mgd2l0aG91dCBjaGFu Z2luZyB0aGUgdGV4dCBpbiB0aGVtLg0KDQpJIGRvIG5vdCB0aGluayB0aGUgVExTIFdHIHNob3Vs ZCBhc2sgdGhlIFdlYlJUQyB3b3JraW5nIGdyb3VwIGZvciBwZXJtaXNzaW9uLCB0aGUgQkNQIHVw ZGF0ZXMgYSBodWdlIG51bWJlciBvZiBSRkNzIGZyb20gYSBsb3Qgb2YgZGlmZmVyZW50IGdyb3Vw cy4gVGhlc2UgZ3JvdXBzIHdlcmUgbm90IGFza2VkLg0KDQpJIHdvdWxkIGxpa2UgdG8gc2VlIGEg Zm9ybWFsIHVwZGF0ZSwgYnV0IGIpIG1pZ2h0IGJlIGEgdmFsaWQgcmVhc29uIHRvIG5vdCBkbyB0 aGF0Lg0KDQpKb2huDQpGcm9tOiBSb2IgU2F5cmUgPHNheXJlckBnbWFpbC5jb20+DQpEYXRlOiBU dWVzZGF5LCA4IE9jdG9iZXIgMjAxOSBhdCAwNzowMg0KVG86IFNlYW4gVHVybmVyIDxzZWFuQHNu M3JkLmNvbT4NCkNjOiAiVExTQGlldGYub3JnIiA8dGxzQGlldGYub3JnPiwgSUVTRyBTZWNyZXRh cnkgPGllc2ctc2VjcmV0YXJ5QGlldGYub3JnPiwgSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3Nv bkBlcmljc3Nvbi5jb20+LCAidGxzLWNoYWlyc0BpZXRmLm9yZyIgPHRscy1jaGFpcnNAaWV0Zi5v cmc+LCAiZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC5hZEBpZXRmLm9yZyIgPGRyYWZ0 LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2guYWRAaWV0Zi5vcmc+LCBCZW5qYW1pbiBLYWR1ayA8 a2FkdWtAbWl0LmVkdT4NClN1YmplY3Q6IFJlOiBbVExTXSBQdWJsaWNhdGlvbiBoYXMgYmVlbiBy ZXF1ZXN0ZWQgZm9yIGRyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZS0wNQ0KDQoN Cg0KT24gVHVlLCBPY3QgOCwgMjAxOSBhdCA3OjMxIEFNIFNlYW4gVHVybmVyIDxzZWFuQHNuM3Jk LmNvbTxtYWlsdG86c2VhbkBzbjNyZC5jb20+PiB3cm90ZToNCmRyYWZ0LWlldGYtcnRjd2ViLXNl Y3VyaXR5LWFyY2ggc2hlcGhlcmQgaGF0IG9uDQoNClRvIGVrcuKAmXMgcG9pbnQsIHRoZSBkZWNp c2lvbiB0byBtYWtlIHRoYXQgc3dpdGNoIEkgdGhpbmsgYWN0dWFsbHkgcHJlLWRhdGVkIG1lLiAg QnV0IGJlZm9yZSBJIGdvIG9mZiBhbmQgZGlnIHVwIHRoZSBoaXN0b3J5LCBJIHRoaW5rIHdlIHNo b3VsZCBjb25zaWRlciB3aGF0IGFuICJ1cGRhdGVz4oCdIGluIHRlcm1zIG9mIGRyYWZ0LWlldGYt dGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZSB3b3VsZCBiZS4NCg0KSSB0aGluayB0aGUgcmVsZXZh bnQgdGV4dCBmcm9tIGRyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0ZSBpcyAiSW1w bGVtZW50YXRpb25zIE1VU1QgTk9UIG5lZ290aWF0ZSBEVExTIHZlcnNpb24gMS4wIFtSRkM0MzQ3 XSwgIFtSRkM2MzQ3XS4iDQoNClRoZSBXZWJSVEMgdGV4dCBpbXBsaWVzIHRoYXQgaXQncyBvayB0 byBuZWdvdGlhdGUgRFRMUyAxLjAgW1JGQzQzNDddLCBhbmQgY2VydGFpbmx5IGRvZXNuJ3QgcnVs ZSBpdCBvdXQuDQoNCnRoYW5rcywNClJvYg0KDQo= --_000_13CE39A72F514058825E60E2DFE3B28Cericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0A9784FAF71F2C408FD0DD8AFD354F3D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSB3YXkgSSBzZWUgaXQsIHRo ZSB1cGNvbWluZyBCQ1AgYXBwbGllcyB0byBXZWJSVEMgaXJyZXNwZWN0aXZlbHkgb2Ygd2hldGhl ciBpdCBmb3JtYWxseSB1cGRhdGVzIHRoZSBkb2N1bWVudCBvciBub3QuIFRoZSBmb3JtYWwgdXBk YXRlcyBhcmUgaW1wb3J0YW50IHNvIHBlb3BsZSBlYXNpbHkgZmluZCB0aGUgQkNQLCBidXQgbm90 IGNyaXRpY2FsLiBDb21wYW5pZXMgY2FuIGFueXdheQ0KIGNob29zZSB0byBpbXBsZW1lbnQgV2Vi UlRDIHdpdGhvdXQgaW1wbGVtZW50aW5nIHRoZSBCQ1AuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvIG5vdCB0 aGluayB0aGUgQkNQIG5lZWQgdG8gY2hhbmdlIGFueSB0ZXh0IGluIHRoZSBXZWJSVEMgZHJhZnQu IFRoZSBCQ1AgdXBkYXRlcyBhIGxvdCBvZiBvdGhlciBSRkNzIHdpdGhvdXQgY2hhbmdpbmcgdGhl IHRleHQgaW4gdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG8gbm90IHRoaW5rIHRoZSBUTFMg V0cgc2hvdWxkIGFzayB0aGUgV2ViUlRDIHdvcmtpbmcgZ3JvdXAgZm9yIHBlcm1pc3Npb24sIHRo ZSBCQ1AgdXBkYXRlcyBhIGh1Z2UgbnVtYmVyIG9mIFJGQ3MgZnJvbSBhIGxvdCBvZiBkaWZmZXJl bnQgZ3JvdXBzLiBUaGVzZSBncm91cHMgd2VyZSBub3QgYXNrZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JIHdvdWxkIGxpa2UgdG8gc2VlIGEgZm9ybWFsIHVwZGF0ZSwgYnV0IGIpIG1pZ2h0IGJlIGEg dmFsaWQgcmVhc29uIHRvIG5vdCBkbyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2huPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Um9iIFNheXJlICZsdDtz YXlyZXJAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCA4IE9jdG9iZXIg MjAxOSBhdCAwNzowMjxicj4NCjxiPlRvOiA8L2I+U2VhbiBUdXJuZXIgJmx0O3NlYW5Ac24zcmQu Y29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7VExTQGlldGYub3JnJnF1b3Q7ICZsdDt0bHNA aWV0Zi5vcmcmZ3Q7LCBJRVNHIFNlY3JldGFyeSAmbHQ7aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmcm Z3Q7LCBKb2huIE1hdHRzc29uICZsdDtqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbSZndDssICZx dW90O3Rscy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3Rscy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7 LCAmcXVvdDtkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLmFkQGlldGYub3JnJnF1b3Q7 ICZsdDtkcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLmFkQGlldGYub3JnJmd0OywNCiBC ZW5qYW1pbiBLYWR1ayAmbHQ7a2FkdWtAbWl0LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtUTFNdIFB1YmxpY2F0aW9uIGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtaWV0Zi10 bHMtb2xkdmVyc2lvbnMtZGVwcmVjYXRlLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUdWUsIE9jdCA4LCAyMDE5IGF0IDc6MzEg QU0gU2VhbiBUdXJuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWFuQHNuM3JkLmNvbSI+c2VhbkBz bjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmRyYWZ0 LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2ggc2hlcGhlcmQgaGF0IG9uPGJyPg0KPGJyPg0KVG8g ZWty4oCZcyBwb2ludCwgdGhlIGRlY2lzaW9uIHRvIG1ha2UgdGhhdCBzd2l0Y2ggSSB0aGluayBh Y3R1YWxseSBwcmUtZGF0ZWQgbWUuJm5ic3A7IEJ1dCBiZWZvcmUgSSBnbyBvZmYgYW5kIGRpZyB1 cCB0aGUgaGlzdG9yeSwgSSB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIgd2hhdCBhbiAmcXVvdDt1 cGRhdGVz4oCdIGluIHRlcm1zIG9mIGRyYWZ0LWlldGYtdGxzLW9sZHZlcnNpb25zLWRlcHJlY2F0 ZSB3b3VsZCBiZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkkgdGhpbmsgdGhlIHJlbGV2YW50IHRleHQgZnJvbSBkcmFmdC1p ZXRmLXRscy1vbGR2ZXJzaW9ucy1kZXByZWNhdGUgaXMgJnF1b3Q7SW1wbGVtZW50YXRpb25zIE1V U1QgTk9UIG5lZ290aWF0ZSBEVExTIHZlcnNpb24gMS4wIFtSRkM0MzQ3XSwmbmJzcDsgW1JGQzYz NDddLiZxdW90OyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5UaGUgV2ViUlRDIHRleHQgaW1wbGllcyB0aGF0IGl0J3Mgb2sgdG8gbmVnb3Rp YXRlIERUTFMgMS4wJm5ic3A7W1JGQzQzNDddLCBhbmQgY2VydGFpbmx5IGRvZXNuJ3QgcnVsZSBp dCBvdXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PnRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJvYjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_13CE39A72F514058825E60E2DFE3B28Cericssoncom_-- From nobody Tue Oct 8 03:35:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB0D120227; Tue, 8 Oct 2019 03:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 K90wkxBSqdiD; Tue, 8 Oct 2019 03:35:42 -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 446E6120089; Tue, 8 Oct 2019 03:35:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 74F91BE55; Tue, 8 Oct 2019 11:35:40 +0100 (IST) 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 dCtZF5rOq6lZ; Tue, 8 Oct 2019 11:35:40 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 21095BE2E; Tue, 8 Oct 2019 11:35:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1570530940; bh=fNSAdcySdKa9GOsah1xV6NE0s1P+d9Pdw9JibwTdmzY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mqvT592jJZae1Z/T0bfnPZKmJyZ3InMFiuPa01MEKutI+0xPKlPdmizqmHfw4G/zH GYsccOJF4nB+pDpBZwTM46I9q70ckqAs+iMpqU4mbgmR0BLaxGnAk3AY6/Zy4IK5yK 5Z5QwitIcSp5f8ca/bRTrH4/DmtIZtjpO4p/zX/I= To: John Mattsson , Rob Sayre , Sean Turner Cc: Benjamin Kaduk , IESG Secretary , "tls@ietf.org" , "draft-ietf-rtcweb-security-arch.ad@ietf.org" , "tls-chairs@ietf.org" References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <13CE39A7-2F51-4058-825E-60E2DFE3B28C@ericsson.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <8aff0e27-877d-d171-9be8-6e84d3e8f2ab@cs.tcd.ie> Date: Tue, 8 Oct 2019 11:35:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <13CE39A7-2F51-4058-825E-60E2DFE3B28C@ericsson.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WDSxzbdKCgWk4FklRkbweQPHXyG1LRAcN" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 10:35:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WDSxzbdKCgWk4FklRkbweQPHXyG1LRAcN Content-Type: multipart/mixed; boundary="QL7QMck59rnOrCpOjcHhr1bgC8agxDGoC"; protected-headers="v1" From: Stephen Farrell To: John Mattsson , Rob Sayre , Sean Turner Cc: Benjamin Kaduk , IESG Secretary , "tls@ietf.org" , "draft-ietf-rtcweb-security-arch.ad@ietf.org" , "tls-chairs@ietf.org" Message-ID: <8aff0e27-877d-d171-9be8-6e84d3e8f2ab@cs.tcd.ie> Subject: Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <13CE39A7-2F51-4058-825E-60E2DFE3B28C@ericsson.com> In-Reply-To: <13CE39A7-2F51-4058-825E-60E2DFE3B28C@ericsson.com> --QL7QMck59rnOrCpOjcHhr1bgC8agxDGoC Content-Type: multipart/mixed; boundary="------------F7E7FAF8067855D3870B7BB6" Content-Language: en-GB This is a multi-part message in MIME format. --------------F7E7FAF8067855D3870B7BB6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/10/2019 11:28, John Mattsson wrote: > I do not think the TLS WG should ask the WebRTC working group for > permission, the BCP updates a huge number of RFCs from a lot of > different groups. These groups were not asked. IETF last call and IESG evaluation is when each of those will ll turn out to be an issue, or a non-issue. Cheers, S. --------------F7E7FAF8067855D3870B7BB6 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----- --------------F7E7FAF8067855D3870B7BB6-- --QL7QMck59rnOrCpOjcHhr1bgC8agxDGoC-- --WDSxzbdKCgWk4FklRkbweQPHXyG1LRAcN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2cZnoACgkQWrL68XsX K+qjLg/+KSeSfZJWNFhf+YEaZpXzcA2vxxko1xPxVOptYY5kJRLwFxmIm+LTqJaR Bw/MnWhsCwzMrCgmCPCeg6UOHM19qUTlDNaFE4j7NeuYTu3GxlBdgZEHlYtITbU0 QRMAtNPhw0jNmGSlmVhCzLAKqlt3QyzTFg5nq0Tf8YnV5DXKuqaIBXgPr9K7UW9K SruCe/3/K8JDwREc/KqGezSZWZ34BweLhV0G7b7WcWjPa0bn28uoAf6GPO2UpoFz 0QxTHWXmc7O423MWOLZF6B7Yhq+rO3Kwq+HsdUJAvbSjrbfmavpl24dn9gbxH2QM hBhbsacvGnEOj0A7tRD4u9hfn2FJARW0zj429esDYExL1QnE8ywr/OCkwKPf909r PzynOVW5e/+fAtazw4Tz1BQ0A9ZZoS79VRhCOvpdyYqjziwU3rvKvP02BRjNrfH2 yv2Ib8CauEAam24a2IBWv8nKPlVCBxBbDV008Z9kpFUCHRpZsaMoQlah43tMhrg+ t9ZwY3zV3dUzBzZ1RRwpzBQ/uaqSdk0oG3oCdA+hSIWDmDext52Zi67UiNGTL+HE 2mLnKu+zzS+RapnebpIpHlU1jyFW75+L6nlA9Wiynj8r22bS51dvpIW2I7iKXLhm OJAmdFuOpL1dD9rf9VKkrTNfQ2EX0AnOvCchSoXlddULnXlulxo= =A5J6 -----END PGP SIGNATURE----- --WDSxzbdKCgWk4FklRkbweQPHXyG1LRAcN-- From nobody Tue Oct 8 05:05:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD22120077; Tue, 8 Oct 2019 05:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 6jvNOAGoxIeT; Tue, 8 Oct 2019 05:05:17 -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 EF1811202A0; Tue, 8 Oct 2019 05:05:16 -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 x98C56m5009358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 8 Oct 2019 08:05:09 -0400 Date: Tue, 8 Oct 2019 05:05:06 -0700 From: Benjamin Kaduk To: Stephen Farrell Cc: Rob Sayre , Eric Rescorla , Sean Turner via Datatracker , John Mattsson , "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" Message-ID: <20191008120506.GF76545@kduck.mit.edu> References: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 12:05:18 -0000 On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote: > > Hiya, > > On 07/10/2019 18:29, Rob Sayre wrote: > > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell > > wrote: > >> we can't "UPDATE" an I-D. > > > > Not true. If you need to refer to something that's been IESG-approved but > > still in the RFC queue, you can leave a note for the RFC editor to update > > the reference to the eventual RFC number. > > That would be an UPDATE on the eventual RFC and not on the > I-D. And in this case, it'd IMO not be a good plan as a) the Recent IESGs have been taking the stance that it's weird to have "Updates:" to a document that's not yet an RFC, mostly preferring to pull the document in question back and get changed directly. But ... > relevant WG didn't want that, b) the I-D in question is part > of a mega-cluster, so any dependency on it (as you suggest) > risks loadsa delay if the cluster doesn't get unstuck, which > can happen and c) our draft already stretches the header ... given that C238 is unblocked, dependencies-wise, that seems questionable in this case. (The whole set of documents does have to go through the xmlv2-->xmlv3 conversion, though.) > enough updating 85 RFCs - trying to add an I-D to that list > would break tools and cause much pointless process-angst. > > Mostly (a) is the reason to not do it though. If you want > to disagree with (a), then the right list for that would be > the rtcweb list I guess, even though the WG is now concluded > (which could, I guess, be (d);-) > > Overall, the cost isn't worth the benefit IMO. That's roughly where I'm landing, too, though as noted previously, it's largely up to the sponsoring AD. -Ben From nobody Tue Oct 8 05:09:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241191202A0 for ; Tue, 8 Oct 2019 05:09:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hDXXecq45hc1 for ; Tue, 8 Oct 2019 05:09:23 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10040.outbound.protection.outlook.com [40.107.1.40]) (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 5DCBF120077 for ; Tue, 8 Oct 2019 05:09:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NFa4NNxfK0xvjo80Hzc9gGhglQ0zjWSJQdgDEyvzI86ADmvCspQwyWJi6scJ/7I8Il0LK05ZvoaP4O33OUtN2teoay2vW75bX1RPwXSqI6C6BnT4QSnddYFvPxjxit0aOrS2/9xcMdqxvcqjgJuFi5nHL2maL+ufdrjEP3cmDyqRq/jj3TCgZylpAWgdxB7vTGxpDRAErzVhB5y8+ivxnWIBq/5T4YDrcX9Et9GAmfWtB17CHoN07GZ8gh8F+4pB0pAnL0fZmAFbriccygpzm6+V2nT1iOLAQpCawQD+qBhWLbQuhYbblz680i0QLqt7tl5VbROeVezFPBxsZOTcog== 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=h+HQa7LKNJXvwMYTWosAi3JvrJ/l3QJ/O70EIp3EK9o=; b=DnU6pwxm58+IpWvWo/IxpXHdtXkthH16otTWN6cjnB7b/BNCSuWQQMGySh50Z2FFIs+giQH1oC0uJm/mWTJa8nRcS7znK3PjUXQwwwiu1ob7JpDaaq0CdTq2hE+iG4LXGLOlMTziN3dHCsErPEvWGpk0fmmeznCKuB0BFB553zTYpq5tFTT8i+FEC/I/bVv0RMHHGtXAc2Kjt5TnONAiU0VIzsaavaokC3H/UBoZylzPXS7Qf3CiK04jg+mqzRfycdjQg38ujk21o4+R5nLoORmHtAjyTv5ngTDD7GF/2wVHpU2mPI1N6b+wqdl79fLy64+bABaiFK5hQwbebCg9YQ== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h+HQa7LKNJXvwMYTWosAi3JvrJ/l3QJ/O70EIp3EK9o=; b=nVZxEqFGUnNeZZ8v5cZOjrZ7C/0S+AtL60Ji2AJahvCJdMx99iOUWmSf1w5vFpICIgswlf8CGVQSrxuxp9Ykp9t56vU/FtXzL2U83D2BOMf8f35dnWvMN4BziMjhuKuMJXWPddSM3avNkASczM/bZriE/VOPXUA0rDgMyCbG+SQ= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2507.eurprd07.prod.outlook.com (10.168.129.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Tue, 8 Oct 2019 12:09:19 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::758a:12ec:c6d:e8a9%10]) with mapi id 15.20.2305.023; Tue, 8 Oct 2019 12:09:19 +0000 From: Mohit Sethi M To: John Mattsson , Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb6JZ9ydCGu6h0WNgLEAne6JU6dQhtYAgAAgF4A= Date: Tue, 8 Oct 2019 12:09:18 +0000 Message-ID: <3945c14b-7e72-808f-ec8c-81c6f485adf6@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <1107173F-E6D8-4882-A8A2-A74B6BB20427@ericsson.com> In-Reply-To: <1107173F-E6D8-4882-A8A2-A74B6BB20427@ericsson.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:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:140:26ac:193b:4683:69c6:f65d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e804162a-6e8b-4f67-2233-08d74be858e0 x-ms-traffictypediagnostic: HE1PR0701MB2507: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(396003)(39860400002)(376002)(136003)(53754006)(13464003)(199004)(189003)(51444003)(65806001)(31686004)(65956001)(66946007)(606006)(186003)(46003)(64756008)(66556008)(66476007)(76116006)(71190400001)(14454004)(256004)(229853002)(71200400001)(25786009)(66446008)(316002)(6486002)(14444005)(6246003)(36756003)(6436002)(6116002)(236005)(99286004)(54896002)(81166006)(81156014)(486006)(8676002)(76176011)(102836004)(6506007)(5660300002)(6306002)(478600001)(446003)(2501003)(2906002)(53546011)(31696002)(6512007)(966005)(8936002)(476003)(7736002)(86362001)(11346002)(58126008)(2616005)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2507; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1tmUeyRyylCu/exMIgixK9T6C5oaIL0ta2IykspCWuZiNSp03+nfR+Q3j/8gayte3QmsszciWYzCXD7rRuzWayyKcWhZ7+bkpxhKylZWe+ybviEdA6ERtKVAtfSuNjSa4uKGzBvUkBoZ+qmdIP4TM5PWt5R+Ombb/TL8n0VH/HZ7hkLisCjC+P7NhC6Q3Fkh1pcDbm1XSrC4ZH1ZAs5CiqiFyxtiVMuz4uEQ6CFGyYFuPZ7d6iPFSv8JyxUFrTzin7ZjuB5tTnjbpqcMOVsloraWnd5VoqtPR2r4N1nfUfyo6ZAKDmTp+A7RhQUqXmeYapTyz/XEb/ynOMHp0lGeIia0Foc7Zhf0khJImOJmPqm6Z/XZxLNAkzZJ6QsXXO5fyCspmOlLSs0X1RORtG2JxkNICqgnpHzGePYPpU5Eb4CwGjA5b73B/1gN9t9XvANsTV2aT0iWeGiIrZjW1O20Bg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3945c14b7e72808fec8c81c6f485adf6ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e804162a-6e8b-4f67-2233-08d74be858e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 12:09:18.8565 (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: j71Q/fg263NvBgZFCKFeR6MzIvjJfz/QgsryawIsWMi4KJmID1LQJm3vQ6/M/ZjZa+7dy1KatdZ5AXwUg3sjs9i6vjHgSQ3orXkO+MwPDFI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2507 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 12:09:27 -0000 --_000_3945c14b7e72808fec8c81c6f485adf6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KT24gMTAvOC8xOSAxOjE0IFBNLCBKb2huIE1hdHRzc29uIHdyb3RlOg0KSGkg TW9oaXQsIHRoYXQgYXJlIGdvb2QgcG9pbnRzLg0KDQo+IFRoZSByZWFsaXR5IGhvd2V2ZXIgaXMg dGhhdCBpbiBtb3N0IGdyb3VwIFBTSyBzY2VuYXJpb3MsIHRoZSBub2RlcyBkb24ndCBoYXZlIGFu eSBzdHJvbmcgaWRlbnRpdGllcyB0aGF0IGNhbiBiZSB2ZXJpZmllZC4NCkkgYXNzdW1lIGJsb2Nr aW5nIGFsbCBpZGVudGl0aWVzIHRoYXQgYXJlIG5vdCB0aGUgbm9kZXMgb3duIGlkZW50aXR5IHdv dWxkIG1pdGlnYXRlIHRoZSBhdHRhY2tzLCBidXQgbGVhZCB0byBhdmFpbGFiaWxpdHkgcHJvYmxl bXMgYXMgdHdvIG5vZGVzIHdpdGggdGhlIHNhbWUgY2hvc2VuIGlkZW50aXR5IGNhbm5vdCB0YWxr IHRvIGVhY2ggb3RoZXIuDQpXZWxsIHRoaXMgaXMgZ2V0dGluZyBvZmYtdG9waWMsIGJ1dCBpZiBp ZGVudGl0aWVzIGFyZSBnZW5lcmF0ZWQgcmFuZG9tbHkgYW5kIGFyZSBsb25nIGVub3VnaCwgY29s bGlzaW9ucyBzaG91bGRuJ3QgYmUgYSBwcm9ibGVtLiBTb21lIE1BQyBhZGRyZXNzIHJhbmRvbWl6 YXRpb24gaW1wbGVtZW50YXRpb25zIHNpbXBseSBnZW5lcmF0ZSBhIG5ldyBhZGRyZXNzIGlmIHRo ZXkgZGV0ZWN0IGEgY29sbGlzaW9uLiBCdXQgd2Ugd2lsbCBzb29uIHN0YXJ0IGRpc2N1c3Npbmcg dGhlIHByb2JsZW0gb2YgYWRkcmVzcyBzcXVhdHRpbmcgYW5kIHdhbnQgQ3J5cHRvZ3JhcGhpY2Fs bHkgR2VuZXJhdGVkIEFkZHJlc3MgKENHQXMpLiBTbyBwZXJoYXBzIHdlIGNhbiBsZWF2ZSB0aGUg aWRlbnRpdHkgY29sbGlzaW9uIGFuZCBzcXVhdHRpbmcgcHJvYmxlbSB0byB0aGUgYWN0dWFsIGRl cGxveW1lbnQuDQoNCj5XaGF0IHlvdSBzaG91bGQgaW5zdGVhZCAob3IgYWRkaXRpb25hbGx5KSBz YXkgaW4gdGhlIHRleHQgaXMgdGhhdCBhIG5vZGUgc2hvdWxkIGNoZWNrIHRoYXQgdGhlIGNsaWVu dF9tYWMgYW5kIHNlcnZlcl9tYWMgKG9yIGFueSA+b3RoZXIgaWRlbnRpdGllcyB1c2VkKSBhcmUg bmV2ZXIgdGhlIHNhbWUuDQoNCkkgdGhpbmsgY2hlY2tpbmcgQ2xpZW50SGVsbG8ucmFuZG9tIGlz IGVub3VnaC4gQmVsb3cgaXMgd2hhdCB3ZSB3cm90ZSBpbg0KDQpPbiB0aGlzLCBEcnVja2VyIGFu ZCBHdWVyb24ncyBwYXBlciBtZW50aW9ucyB0aGF0IGEgcG9zc2libGUgc29sdXRpb24gaXM6ICJF dmVyeSBwYXJ0eSAoY2xpZW50IG9yIHNlcnZlcikgY2FjaGVzIGFsbCB0aGUgbm9uY2VzIHRoYXQg aXQgZ2VuZXJhdGVkLCBhbmQgcmVqZWN0cyBhIGNvbm5lY3Rpb24gZnJvbSBvdGhlciBwYXJ0aWVz IGlmIHRoZXkgdXNlIGEgY2FjaGVkIG5vbmNlLiIgYW5kIHRoYXQgaXQgImludm9sdmVzIHRoZSBv dmVyaGVhZCBvZiBtYWludGFpbmluZyBhIGNhY2hlIGFuZCB0aGUgb3ZlcmhlYWQgb2Ygc2hhcmlu ZyB0aGUgY2FjaGUgYmV0d2VlbiBzZXZlcmFsIHByb2Nlc3NlcyBvbiB0aGUgc2FtZSBub2RlLiIu IFRoZSBwYXBlciBhbHNvIGRlc2NyaWJlcyBhIGdyb3VwIHNjZW5hcmlvIHdoZXJlIG5vZGVzIGNh biBpbmFkdmVydGVudGx5IGxlYWsgY2FjaGUgYW5kIG1lbW9yeSBpbmZvcm1hdGlvbiBpZiBzb21l dGhpbmcgbGlrZSB0aGlzIGlzIGltcGxlbWVudGVkLiBTbyBJIHRoaW5rIHRoYXQgZW5zdXJpbmcg bm9uLWVxdWFsIGNsaWVudCBhbmQgc2VydmVyIGlkZW50aXRpZXMgaXMgZWFzaWVyIGFuZCBzYWZl ciBzaW5jZSB0aGlzIGNoZWNrIGNhbiBiZSBwZXJmb3JtZWQgYmVmb3JlIHRoZSBUTFMgaGFuZHNo YWtlIGJlZ2lucyAoaS5lLiB3aGVuIHRoZSBleHRlcm5hbCBQU0sgaXMgdHJhbnNmb3JtZWQgdG8g aXBza3gpLg0KDQotLU1vaGl0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2Vs YW5kZXItYWNlLWNvc2UtZWNkaGUtMTQNCg0KICDigJxJZiB0d28gbm9kZXMgdW5pbnRlbnRpb25h bGx5IGluaXRpYXRlIHR3byBzaW11bHRhbmVvdXMgRURIT0MgbWVzc2FnZQ0KICAgZXhjaGFuZ2Vz IHdpdGggZWFjaCBvdGhlciBldmVuIGlmIHRoZXkgb25seSB3YW50IHRvIGNvbXBsZXRlIGEgc2lu Z2xlDQogICBFREhPQyBtZXNzYWdlIGV4Y2hhbmdlLCB0aGV5IE1BWSB0ZXJtaW5hdGUgdGhlIGV4 Y2hhbmdlIHdpdGggdGhlDQogICBsZXhpY29ncmFwaGljYWxseSBzbWFsbGVzdCBHX1guICBJZiB0 aGUgdHdvIEdfWCB2YWx1ZXMgYXJlIGVxdWFsLCB0aGUNCiAgIHJlY2VpdmVkIG1lc3NhZ2VfMSBN VVNUIGJlIGRpc2NhcmRlZCB0byBtaXRpZ2F0ZSByZWZsZWN0aW9uIGF0dGFja3MuDQogICBOb3Rl IHRoYXQgaW4gdGhlIGNhc2Ugb2YgdHdvIHNpbXVsdGFuZW91cyBFREhPQyBleGNoYW5nZXMgd2hl cmUgdGhlDQogICBub2RlcyBvbmx5IGNvbXBsZXRlIG9uZSBhbmQgd2hlcmUgdGhlIG5vZGVzIGhh dmUgZGlmZmVyZW50IHByZWZlcnJlZA0KICAgY2lwaGVyIHN1aXRlcywgYW4gYXR0YWNrZXIgY2Fu IGFmZmVjdCB3aGljaCBvZiB0aGUgdHdvIG5vZGVzJw0KICAgcHJlZmVycmVkIGNpcGhlciBzdWl0 ZXMgd2lsbCBiZSB1c2VkIGJ5IGJsb2NraW5nIHRoZSBvdGhlciBleGNoYW5nZS7igJ0NCg0KSm9o bg0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86dGxzLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRoaSBNIDxtb2hpdC5tLnNldGhpPTQwZXJp Y3Nzb24uY29tQGRtYXJjLmlldGYub3JnPjxtYWlsdG86bW9oaXQubS5zZXRoaT00MGVyaWNzc29u LmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFR1ZXNkYXksIDggT2N0b2JlciAyMDE5IGF0IDEx OjU3DQpUbzogQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD48bWFpbHRvOmNh d0BoZWFwaW5nYml0cy5uZXQ+LCAiVExTQGlldGYub3JnIjxtYWlsdG86VExTQGlldGYub3JnPiA8 dGxzQGlldGYub3JnPjxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFNl bGZpZSBhdHRhY2sNCg0KDQpIaSBDaHJpcywNCg0KRm9yIHRoZSBiZW5lZml0IG9mIHRoZSBsaXN0 LCBsZXQgbWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMgb25seSByZWxldmFu dCB3aGVyZSBtdWx0aXBsZSBwYXJ0aWVzIHNoYXJlIHRoZSBzYW1lIFBTSyBhbmQgdXNlIHRoZSBz YW1lIFBTSyBmb3Igb3V0Z29pbmcgYW5kIGluY29taW5nIGNvbm5lY3Rpb25zLiBUaGVzZSBzaXR1 YXRpb25zIGFyZSByYXRoZXIgcmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExTIGlzIHdpZGVseSB1 c2VkIChhbmQgc29tZXRpbWVzIG1pc3VzZWQpIGluIG1hbnkgcGxhY2VzLg0KDQpUaGUgU2VsZmll IGF0dGFjayBvbmx5IGhhcHBlbnMgd2hlbiBhbiBlbnRpdHkgd2l0aCB0aGUgUFNLIGFjdHMgbWFs aWNpb3VzbHkuIFNvIEkgdGhpbmsgdGhlIGZhY3QgdGhhdCB5b3Ugd3JpdGUgaW4gdGhlIGRyYWZ0 OiAiZWFjaCBub2RlIG11c3QgYmUgdHJ1c3RlZCBub3QgdG8gaW1wZXJzb25hdGUgYW5vdGhlciBu b2RlJ3Mgcm9sZSIgZG9lcyBub3QgdGFrZSBpbnRvIGFjY291bnQgdGhhdCB0aGVyZSBtdXN0IGJl IGEgbWFsaWNpb3VzIG5vZGUgZm9yIHRoZSBzZWxmaWUgYXR0YWNrIHRvIGhhcHBlbiBpbiB0aGUg Zmlyc3QgcGxhY2UuDQoNCkRydWNrZXIgYW5kIEd1ZXJvbidzIHBhcGVyIHJlY29tbWVuZHMgdGhh dCAiZXZlcnkgcGFydGljaXBhdGluZyBwYXJ0eSBnZXRzIChkdXJpbmcgdGhlIHNldHVwIG9mIHRo ZSBuZXR3b3JrKSBhIHVuaXF1ZSBpZGVudGl0eSIgYW5kICJ0aGUgY2xpZW50IGFuZCB0aGUgc2Vy dmVyIG11c3QgdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiB0aGUgY2xhaW1lZCBpZGVudGl0aWVzLiIu IFRoZSByZWFsaXR5IGhvd2V2ZXIgaXMgdGhhdCBpbiBtb3N0IGdyb3VwIFBTSyBzY2VuYXJpb3Ms IHRoZSBub2RlcyBkb24ndCBoYXZlIGFueSBzdHJvbmcgaWRlbnRpdGllcyB0aGF0IGNhbiBiZSB2 ZXJpZmllZC4NCg0KV2hhdCB5b3Ugc2hvdWxkIGluc3RlYWQgKG9yIGFkZGl0aW9uYWxseSkgc2F5 IGluIHRoZSB0ZXh0IGlzIHRoYXQgYSBub2RlIHNob3VsZCBjaGVjayB0aGF0IHRoZSBjbGllbnRf bWFjIGFuZCBzZXJ2ZXJfbWFjIChvciBhbnkgb3RoZXIgaWRlbnRpdGllcyB1c2VkKSBhcmUgbmV2 ZXIgdGhlIHNhbWUuIFdpdGhvdXQgdGhpcyBjaGVjaywgdGhlIHNlbGZpZSBhdHRhY2sgd291bGQg c3RpbGwgYmUgcG9zc2libGUuIEFuZCBhdCBsZWFzdCB0aGlzIGRvZXMgbm90IHJlcXVpcmUgc3Ry b25nIGlkZW50aXR5IHZlcmlmaWNhdGlvbiBmb3IgcHJldmVudGluZyBzZWxmaWUgYXR0YWNrcy4N Cg0KLS1Nb2hpdA0KT24gMTAvNS8xOSAyOjQxIFBNLCBDaHJpc3RvcGhlciBXb29kIHdyb3RlOg0K DQpIaSBGZW5nLA0KDQoNCg0KRm9yIHdoYXQgaXQncyB3b3J0aCwgdGhlIGxhdGVzdCB2ZXJzaW9u IG9mIHRoZSBQU0sgaW1wb3J0ZXJzIGRyYWZ0IGluY2x1ZGVzIGEgImNvbnRleHQiIGZpZWxkIGlu dG8gd2hpY2ggaWRlbnRpdHkgaW5mb3JtYXRpb24gY2FuIGJlIGZlZDoNCg0KDQoNCiAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1leHRlcm5hbC1wc2staW1wb3J0 ZXItMDEjYXBwZW5kaXgtQg0KDQoNCg0KQmVzdCwNCg0KQ2hyaXMNCg0KDQoNCk9uIFR1ZSwgU2Vw IDI0LCAyMDE5LCBhdCA5OjE5IEFNLCBIYW8sIEZlbmcgd3JvdGU6DQoNCkhpIEpvaG4sDQoNCg0K DQpSZWZsZWN0aW9uIGF0dGFja3MgYXJlIGluZGVlZCBvbGRlciwgYnV0IHRoZSBzZWxmaWUgYXR0 YWNrIGlzIGEgYml0DQoNCmRpZmZlcmVudC4gSXQncyBhY3R1YWxseSBhIHZhcmlhbnQgb2YgdGhl IHVua25vd24ga2V5IHNoYXJlIGF0dGFjay4gQQ0KDQp0eXBpY2FsIGV4YW1wbGUgb2YgdGhlIFVL UyBhdHRhY2sgaXMgdGhlIG9uZSByZXBvcnRlZCBvbiBNUVYgYnkgS2FsaXNraQ0KDQppbiAyMDAx IChzZWUgIkFuIHVua25vd24ga2V5LXNoYXJlIGF0dGFjayBvbiB0aGUgTVFWIGtleSBhZ3JlZW1l bnQNCg0KcHJvdG9jb2wiIGluIEFDTSBUSVNTRUMgMjAwMSkuIEluIHRoYXQgZXhhbXBsZSwgdGhl IGFkdmVyc2FyeSBwbGF5cw0KDQptZXNzYWdlIGJldHdlZW4gdHdvIHVzZXJzIHRvIGNhdXNlIGNv bmZ1c2lvbiBpbiB0aGUgaWRlbnRpdHksIGJ1dCBpbg0KDQpTZWxmaWUsIHRoZSBhZHZlcnNhcnkg cGxheXMgbWVzc2FnZSB3aXRoIG9ubHkgb25lIHVzZXIgYW5kIHVzZXMgYW5vdGhlcg0KDQppbnN0 YW5jZSBvZiB0aGUgdXNlciB0byBjYXVzZSBjb25mdXNpb24gaW4gdGhlIGlkZW50aXR5LiBXaGVu IHdlDQoNCnJlcG9ydGVkIHRoaXMgdmFyaWFudCBvZiBVS1MgaW4gWzNdLCB3ZSB3ZXJlIG5vdCBh d2FyZSBvZiBhbnl0aGluZyBsaWtlDQoNCnRoYXQgaW4gdGhlIGxpdGVyYXR1cmUuDQoNCg0KDQpD aGVlcnMsDQoNCkZlbmcNCg0KDQoNCk9uIDI0LzA5LzIwMTksIDE2OjE3LCAiSm9obiBNYXR0c3Nv biIgPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPjxtYWlsdG86am9obi5tYXR0c3NvbkBlcmlj c3Nvbi5jb20+IHdyb3RlOg0KDQoNCg0KICAgIEhpLA0KDQoNCg0KICAgIEkgdGhpbmsgdGhlc2Ug cmVmbGVjdGlvbiBhdHRhY2tzIGFyZSBtdWNoIG9sZGVyIHRoYW4gdGhpcy4gSSBxdWljaw0KDQpz ZWFyY2ggZm9yIHJlZmxlY3Rpb24gYXR0YWNrIHNlY3VyaXR5IHByb3RvY29sIGdpdmVzIGEgbG90 IG9mIG9sZA0KDQpyZXN1bHRzLCBUaGUgZGVzY3JpcHRpb24gb2YgcmVmbGVjdGlvbiBhdHRhY2sg aW4gdGhlIGZvbGxvd2luZyBsZWN0dXJlDQoNCm1hdGVyaWFsIGZyb20gMjAwOSBsb29rcyBqdXN0 IGxpa2UgdGhlICJzZWxmaWUgYXR0YWNrIiBvbiBUTFMgMS4zDQoNCiAgICBodHRwOi8vd3d3LmNz LmJoYW0uYWMudWsvfnRwYy9jd2kvVGVhY2hpbmcvRmlsZXMvTGVjdHVyZTRfNnVwLnBkZg0KDQoN Cg0KICAgIFdpdGggbXVsdGlwbGUgc2VjdGlvbnMgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0 IGNoYW5nZSBhcyB3ZWxsLg0KDQpJZiB0d28gbm9kZXMgdW5pbnRlbnRpb25hbGx5IGluaXRpYXRl IHNpbXVsdGFuZW91cyBDbGllbnRIZWxsbyB0byBlYWNoDQoNCm90aGVyLCBldmVuIGlmIHRoZXkg b25seSB3YW50IGEgc2luZ2xlIHNlY3VyZSBjb25uZWN0aW9uIChJIGhhdmUgc2Vlbg0KDQpsaXZl IHN5c3RlbXMgd2hlcmUgdGhpcyBoYXBwZW5zIGluIHByYWN0aWNlKSwgYW4gYXR0YWNrZXIgY2Fu IHNlbGVjdA0KDQp3aGljaCBDbGllbnRIZWxsbyB0byBibG9jayAoZS5nLiB0aGUgb25lIHdpdGgg dGhlIHN0cm9uZ2VzdA0KDQpjcnlwdG9ncmFwaGljIHBhcmFtZXRlcnMpLiBUaGUgZm9sbG93aW5n IHNlY3VyaXR5IHByb3BlcnR5IHdvdWxkIHRoZW4NCg0Kbm8gbG9uZ2VyIGhvbGQgOg0KDQoNCg0K ICAgICAgIkRvd25ncmFkZSBwcm90ZWN0aW9uOiAgVGhlIGNyeXB0b2dyYXBoaWMgcGFyYW1ldGVy cyBzaG91bGQgYmUgdGhlDQoNCiAgICAgICAgICBzYW1lIG9uIGJvdGggc2lkZXMgYW5kIHNob3Vs ZCBiZSB0aGUgc2FtZSBhcyBpZiB0aGUgcGVlcnMgaGFkIGJlZW4NCg0KICAgICAgICAgIGNvbW11 bmljYXRpbmcgaW4gdGhlIGFic2VuY2Ugb2YgYW4gYXR0YWNrIg0KDQoNCg0KICAgIChJIGhhdmUg bm90IGxvb2tlZCBhdCB3aGF0IHRoZSBkZWZpbml0aW9ucyBpbiBbQkJGR0taMTZdIHNheSkuDQoN Cg0KDQogICAgQ2hlZXJzLA0KDQogICAgSm9obg0KDQoNCg0KICAgIC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQoNCiAgICBGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiSGFvLCBGZW5nIg0KDQo8RmVuZy5I YW9Ad2Fyd2ljay5hYy51az48bWFpbHRvOkZlbmcuSGFvQHdhcndpY2suYWMudWs+DQoNCiAgICBE YXRlOiBUdWVzZGF5LCAyNCBTZXB0ZW1iZXIgMjAxOSBhdCAxNjowOQ0KDQogICAgVG86IE1vaGl0 IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+PG1h aWx0bzptb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiwNCg0KIk93 ZW4gRnJpZWwgKG9mcmllbCkiIDxvZnJpZWxAY2lzY28uY29tPjxtYWlsdG86b2ZyaWVsQGNpc2Nv LmNvbT4sIEpvbmF0aGFuIEhveWxhbmQNCg0KPGpvbmF0aGFuLmhveWxhbmRAZ21haWwuY29tPjxt YWlsdG86am9uYXRoYW4uaG95bGFuZEBnbWFpbC5jb20+DQoNCiAgICBDYzogIlRMU0BpZXRmLm9y ZyI8bWFpbHRvOlRMU0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz48bWFpbHRvOnRsc0BpZXRmLm9y Zz4NCg0KICAgIFN1YmplY3Q6IFJlOiBbVExTXSBTZWxmaWUgYXR0YWNrIHdhcyBSZTogRGlzdGlu Z3Vpc2hpbmcgYmV0d2Vlbg0KDQpleHRlcm5hbC9yZXN1bXB0aW9uIFBTS3MNCg0KDQoNCg0KDQog ICAgICAgIE9uIDIzLzA5LzIwMTksIDE4OjUwLCAiVExTIG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRo aSBNIg0KDQo8dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIDxtYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmdvbmJlaGFsZm9mbW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFy Yy5pZXRmLm9yZz4NCg0KbW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9y Zz48bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3Jnb25iZWhhbGZvZm1vaGl0Lm0uc2V0aGk9NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCg0KICAgICAgICAgICAgSGkg YWxsLA0KDQoNCg0KICAgICAgICAgICAgT24gdGhlIHRvcGljIG9mIGV4dGVybmFsIFBTS3MgaW4g VExTIDEuMywgSSBmb3VuZCBhDQoNCnB1YmxpY2F0aW9uIG9uIHRoZQ0KDQogICAgICAgICAgICBT ZWxmaWUgYXR0YWNrOg0KDQpodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPWRkNDMy ZjEzLTgxYzllNWFkLWRkNDM2Zjg4LTg2OWExN2I1YjIxYi1kYzZjNmYwYTVkZDIxZmFmJnE9MSZ1 PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxOSUyRjM0Nw0KDQoNCg0KICAgICAg ICAgICAgUGVyaGFwcyB0aGlzIHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gSSB0 aG91Z2h0DQoNCnRoYXQgc2hhcmluZw0KDQogICAgICAgICAgICBpdCBhZ2FpbiB3b3VsZG4ndCBo dXJ0IHdoaWxlIHdlIGRpc2N1c3MgaG93IHNlcnZlcnMNCg0KZGlzdGluZ3Vpc2ggYmV0d2Vlbg0K DQogICAgICAgICAgICBleHRlcm5hbCBhbmQgcmVzdW1wdGlvbiBQU0tzLg0KDQoNCg0KICAgICAg ICBJIGp1c3QgcmVhZCB0aGUgcGFwZXIgd2l0aCBpbnRlcmVzdC4gSXQgb2NjdXJzIHRvIG1lIHRo YXQgdGhlDQoNCnNlbGZpZSBhdHRhY2sgaXMgY29uc2lzdGVudCB3aXRoIHRoZSAiaW1wZXJzb25h dGlvbiBhdHRhY2siIHRoYXQgd2UNCg0KcmVwb3J0ZWQgb24gU1BFS0UgaW4gMjAxNDsgc2VlIFNl YyA0LjEgWzFdIGFuZCB0aGUgdXBkYXRlZCB2ZXJzaW9uIHdpdGgNCg0KZGV0YWlscyBvbiBob3cg U1BFS0UgaXMgcmV2aXNlZCBpbiBJU08vSUVDIDExNzcwLTQgWzJdLiBUaGUgc2FtZSBhdHRhY2sN Cg0KY2FuIGJlIHRyYWNlZCBiYWNrIHRvIDIwMTAgaW4gWzNdIHdoZXJlIGEgIndvcm0taG9sZSBh dHRhY2siIChGaWcuIDUsDQoNClszXSkgaXMgcmVwb3J0ZWQgb24gdGhlIHNlbGYtY29tbXVuaWNh dGlvbiBtb2RlIG9mIEhNUVYuIFRoZSBlc3NlbmNlIG9mDQoNCnRoZXNlIGF0dGFja3MgaXMgdGhl IHNhbWU6IEJvYiB0cmlja3MgQWxpY2UgaW50byB0aGlua2luZyB0aGF0IHNoZSBpcw0KDQp0YWxr aW5nIHRvIGF1dGhlbnRpY2F0ZWQgQm9iLCBidXQgc2hlIGlzIGFjdHVhbGx5IHRhbGtpbmcgdG8g aGVyc2VsZi4NCg0KSW4gWzNdLCB3ZSBleHBsYWluZWQgdGhhdCB0aGUgYXR0YWNrIHdhcyBtaXNz ZWQgZnJvbSB0aGUgInNlY3VyaXR5DQoNCnByb29mcyIgYXMgdGhlIHByb29mcyBkaWRuJ3QgY29u c2lkZXIgbXVsdGlwbGUgc2Vzc2lvbnMuDQoNCg0KDQogICAgICAgIFRoZSBjb3VudGVybWVhc3Vy ZSB3ZSBwcm9wb3NlZCBpbiBbMS0zXSB3YXMgdG8gZW5zdXJlIHRoZSB1c2VyDQoNCmlkZW50aXR5 IGlzIHVuaXF1ZSBpbiBrZXkgZXhjaGFuZ2UgcHJvY2Vzc2VzOiBpbiBjYXNlIG9mIG11bHRpcGxl DQoNCnNlc3Npb25zIHRoYXQgbWF5IGNhdXNlIGNvbmZ1c2lvbiBpbiB0aGUgdXNlciBpZGVudGl0 eSwgYW4gZXh0ZW5zaW9uDQoNCnNob3VsZCBiZSBhZGRlZCB0byB0aGUgdXNlciBpZGVudGl0eSB0 byBkaXN0aW5ndWlzaCB0aGUgaW5zdGFuY2VzLiBUaGUNCg0KdW5kZXJseWluZyBpbnR1aXRpb24g aXMgdGhhdCBvbmUgc2hvdWxkIGtub3cgInVuYW1iaWd1b3VzbHkiIHdob20gdGhleQ0KDQphcmUg Y29tbXVuaWNhdGluZyB3aXRoLCBhbmQgcGVyZm9ybSBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiB0 aGF0LiBUaGUNCg0KZGlzY292ZXJ5IG9mIHRoaXMgdHlwZSBvZiBhdHRhY2tzIGFuZCB0aGUgcHJv cG9zZWQgc29sdXRpb24gYXJlDQoNCmluc3BpcmVkIGJ5IHRoZSAiZXhwbGljaXRuZXNzIHByaW5j aXBsZSIgKFJvc3MgQW5kZXJzb24gYW5kIFJvZ2VyDQoNCk5lZWRoYW0sIENyeXB0byc5NSksIHdo aWNoIHN0YXRlcyB0aGUgaW1wb3J0YW5jZSBvZiBiZWluZyBleHBsaWNpdCBvbg0KDQp1c2VyIGlk ZW50aXRpZXMgYW5kIG90aGVyIGF0dHJpYnV0ZXMgaW4gYSBwdWJsaWMga2V5IHByb3RvY29sOyBh bHNvIHNlZQ0KDQpbM10uIEkgaG9wZSBpdCBtaWdodCBiZSB1c2VmdWwgdG8gcGVvcGxlIHdobyB3 b3JrIG9uIFRMUyBQU0suDQoNCg0KDQogICAgICAgIFsxXQ0KDQpodHRwczovL3Byb3RlY3QyLmZp cmVleWUuY29tL3VybD9rPTVhODIyNTEzLTA2MDhlZmFkLTVhODI2NTg4LTg2OWExN2I1YjIxYi1l YjI2MDE1MWY3OGIwNzE4JnE9MSZ1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAx NCUyRjU4NS5wZGYNCg0KICAgICAgICBbMl0gaHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE4MDIuMDQ5 MDANCg0KICAgICAgICBbM10NCg0KaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS91cmw/az1k NWJmODhmZi04OTM1NDI0MS1kNWJmYzg2NC04NjlhMTdiNWIyMWItMGU5YjNiZjU4ZTEwNGYzMiZx PTEmdT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTAlMkYxMzYucGRmDQoNCg0K DQoNCg0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQogICAgICAgIFRMUyBtYWlsaW5nIGxpc3QNCg0KICAgICAgICBUTFNAaWV0Zi5vcmc8 bWFpbHRvOlRMU0BpZXRmLm9yZz4NCg0KICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KDQoNCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVExTIG1haWxpbmcgbGlzdA0KDQpUTFNAaWV0 Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNClRMUyBtYWlsaW5nIGxpc3QNCg0KVExTQGlldGYub3JnPG1haWx0bzpU TFNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz DQo= --_000_3945c14b7e72808fec8c81c6f485adf6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5ED6FAE8FA7969498FCF66C435DF3416@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgSm9obiw8YnI+DQo8L3A+DQo8ZGl2IGNsYXNzPSJt b3otY2l0ZS1wcmVmaXgiPk9uIDEwLzgvMTkgMToxNCBQTSwgSm9obiBNYXR0c3NvbiB3cm90ZTo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDoxMTA3MTczRi1F NkQ4LTQ4ODItQThBMi1BNzRCNkJCMjA0MjdAZXJpY3Nzb24uY29tIj4NCjxtZXRhIG5hbWU9Ikdl bmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkDQogICAgICAgIG1l ZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBNb2hpdCwgdGhhdCBhcmUgZ29vZCBw b2ludHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg VGhlIHJlYWxpdHkgaG93ZXZlciBpcyB0aGF0IGluIG1vc3QgZ3JvdXAgUFNLIHNjZW5hcmlvcywg dGhlIG5vZGVzIGRvbid0IGhhdmUgYW55IHN0cm9uZyBpZGVudGl0aWVzIHRoYXQgY2FuIGJlIHZl cmlmaWVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkkgYXNzdW1lIGJsb2NraW5nIGFsbCBpZGVudGl0aWVzIHRoYXQgYXJl IG5vdCB0aGUgbm9kZXMgb3duIGlkZW50aXR5IHdvdWxkIG1pdGlnYXRlIHRoZSBhdHRhY2tzLCBi dXQgbGVhZCB0byBhdmFpbGFiaWxpdHkgcHJvYmxlbXMgYXMgdHdvIG5vZGVzIHdpdGggdGhlIHNh bWUgY2hvc2VuIGlkZW50aXR5IGNhbm5vdCB0YWxrIHRvIGVhY2ggb3RoZXIuPC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KV2VsbCB0aGlzIGlzIGdldHRpbmcgb2ZmLXRvcGljLCBi dXQgaWYgaWRlbnRpdGllcyBhcmUgZ2VuZXJhdGVkIHJhbmRvbWx5IGFuZCBhcmUgbG9uZyBlbm91 Z2gsIGNvbGxpc2lvbnMgc2hvdWxkbid0IGJlIGEgcHJvYmxlbS4gU29tZSBNQUMgYWRkcmVzcyBy YW5kb21pemF0aW9uIGltcGxlbWVudGF0aW9ucyBzaW1wbHkgZ2VuZXJhdGUgYSBuZXcgYWRkcmVz cyBpZiB0aGV5IGRldGVjdCBhIGNvbGxpc2lvbi4gQnV0IHdlIHdpbGwgc29vbiBzdGFydA0KIGRp c2N1c3NpbmcgdGhlIHByb2JsZW0gb2YgYWRkcmVzcyBzcXVhdHRpbmcgYW5kIHdhbnQgQ3J5cHRv Z3JhcGhpY2FsbHkgR2VuZXJhdGVkIEFkZHJlc3MgKENHQXMpLiBTbyBwZXJoYXBzIHdlIGNhbiBs ZWF2ZSB0aGUgaWRlbnRpdHkgY29sbGlzaW9uIGFuZCBzcXVhdHRpbmcgcHJvYmxlbSB0byB0aGUg YWN0dWFsIGRlcGxveW1lbnQuDQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJt aWQ6MTEwNzE3M0YtRTZEOC00ODgyLUE4QTItQTc0QjZCQjIwNDI3QGVyaWNzc29uLmNvbSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O1doYXQgeW91IHNob3VsZCBpbnN0ZWFk IChvciBhZGRpdGlvbmFsbHkpIHNheSBpbiB0aGUgdGV4dCBpcyB0aGF0IGEgbm9kZSBzaG91bGQg Y2hlY2sgdGhhdCB0aGUgY2xpZW50X21hYyBhbmQgc2VydmVyX21hYyAob3IgYW55ICZndDtvdGhl ciBpZGVudGl0aWVzIHVzZWQpDQo8Yj5hcmUgbmV2ZXIgdGhlIHNhbWU8L2I+LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+SSB0aGluayBjaGVja2luZyBDbGllbnRIZWxsby5yYW5kb20gaXMgZW5vdWdoLiBC ZWxvdyBpcyB3aGF0IHdlIHdyb3RlIGluPGJyPg0KPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPHA+T24gdGhpcywgRHJ1Y2tlciBhbmQgR3Vlcm9uJ3MgcGFwZXIgbWVudGlvbnMg dGhhdCBhIHBvc3NpYmxlIHNvbHV0aW9uIGlzOiAmcXVvdDtFdmVyeSBwYXJ0eSAoY2xpZW50IG9y IHNlcnZlcikgY2FjaGVzIGFsbCB0aGUgbm9uY2VzIHRoYXQgaXQgZ2VuZXJhdGVkLCBhbmQgcmVq ZWN0cyBhIGNvbm5lY3Rpb24gZnJvbSBvdGhlciBwYXJ0aWVzIGlmIHRoZXkgdXNlIGEgY2FjaGVk IG5vbmNlLiZxdW90OyBhbmQgdGhhdCBpdCAmcXVvdDtpbnZvbHZlcyB0aGUgb3ZlcmhlYWQNCiBv ZiBtYWludGFpbmluZyBhIGNhY2hlIGFuZCB0aGUgb3ZlcmhlYWQgb2Ygc2hhcmluZyB0aGUgY2Fj aGUgYmV0d2VlbiBzZXZlcmFsIHByb2Nlc3NlcyBvbiB0aGUgc2FtZSBub2RlLiZxdW90Oy4gVGhl IHBhcGVyIGFsc28gZGVzY3JpYmVzIGEgZ3JvdXAgc2NlbmFyaW8gd2hlcmUgbm9kZXMgY2FuIGlu YWR2ZXJ0ZW50bHkgbGVhayBjYWNoZSBhbmQgbWVtb3J5IGluZm9ybWF0aW9uIGlmIHNvbWV0aGlu ZyBsaWtlIHRoaXMgaXMgaW1wbGVtZW50ZWQuIFNvIEkNCiB0aGluayB0aGF0IGVuc3VyaW5nIG5v bi1lcXVhbCBjbGllbnQgYW5kIHNlcnZlciBpZGVudGl0aWVzIGlzIGVhc2llciBhbmQgc2FmZXIg c2luY2UgdGhpcyBjaGVjayBjYW4gYmUgcGVyZm9ybWVkIGJlZm9yZSB0aGUgVExTIGhhbmRzaGFr ZSBiZWdpbnMgKGkuZS4gd2hlbiB0aGUgZXh0ZXJuYWwgUFNLIGlzIHRyYW5zZm9ybWVkIHRvIGlw c2t4KS4NCjxicj4NCjwvcD4NCjxwPi0tTW9oaXQ8YnI+DQo8L3A+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjaXRlPSJtaWQ6MTEwNzE3M0YtRTZEOC00ODgyLUE4QTItQTc0QjZCQjIwNDI3QGVy aWNzc29uLmNvbSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjwvc3Bhbj48dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1 ZSIgbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zZWxhbmRlci1hY2UtY29zZS1lY2RoZS0xNCIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc2VsYW5kZXItYWNlLWNvc2UtZWNkaGUtMTQ8 L2E+PC9zcGFuPjwvdT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiIGxh bmc9IkVOLVVTIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT IiBsYW5nPSJFTi1VUyI+Jm5ic3A7IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLUdCIj5JZiB0d28gbm9kZXMgdW5pbnRlbnRpb25hbGx5 IGluaXRpYXRlIHR3byBzaW11bHRhbmVvdXMgRURIT0MgbWVzc2FnZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyIgbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBleGNoYW5nZXMgd2l0aCBlYWNo IG90aGVyIGV2ZW4gaWYgdGhleSBvbmx5IHdhbnQgdG8gY29tcGxldGUgYSBzaW5nbGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgRURIT0MgbWVz c2FnZSBleGNoYW5nZSwgdGhleSBNQVkgdGVybWluYXRlIHRoZSBleGNoYW5nZSB3aXRoIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tR0IiPiZuYnNwOyZuYnNwOyBsZXhp Y29ncmFwaGljYWxseSBzbWFsbGVzdCBHX1guJm5ic3A7IElmIHRoZSB0d28gR19YIHZhbHVlcyBh cmUgZXF1YWwsIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tR0IiPiZu YnNwOyZuYnNwOyByZWNlaXZlZCBtZXNzYWdlXzEgTVVTVCBiZSBkaXNjYXJkZWQgdG8gbWl0aWdh dGUgcmVmbGVjdGlvbiBhdHRhY2tzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyIgbGFuZz0i RU4tR0IiPiZuYnNwOyZuYnNwOyBOb3RlIHRoYXQgaW4gdGhlIGNhc2Ugb2YgdHdvIHNpbXVsdGFu ZW91cyBFREhPQyBleGNoYW5nZXMgd2hlcmUgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT IiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IG5vZGVzIG9ubHkgY29tcGxldGUgb25lIGFuZCB3 aGVyZSB0aGUgbm9kZXMgaGF2ZSBkaWZmZXJlbnQgcHJlZmVycmVkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIiBsYW5nPSJFTi1HQiI+Jm5ic3A7Jm5ic3A7IGNpcGhlciBzdWl0ZXMsIGFuIGF0 dGFja2VyIGNhbiBhZmZlY3Qgd2hpY2ggb2YgdGhlIHR3byBub2Rlcyc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiIGxhbmc9IkVOLUdCIj4mbmJzcDsmbmJzcDsgcHJlZmVycmVkIGNpcGhlciBz dWl0ZXMgd2lsbCBiZSB1c2VkIGJ5IGJsb2NraW5nIHRoZSBvdGhlciBleGNoYW5nZS7igJ08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiIGxhbmc9IkVOLUdCIj5Kb2huPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGDQogICAgICAgICAgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPlRMUyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciPg0KJmx0O3Rscy1ib3VuY2VzQGlldGYub3JnJmd0 OzwvYT4gb24gYmVoYWxmIG9mIE1vaGl0IFNldGhpIE0gPGEgY2xhc3M9Im1vei10eHQtbGluay1y ZmMyMzk2RSIgaHJlZj0ibWFpbHRvOm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMu aWV0Zi5vcmciPg0KJmx0O21vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5v cmcmZ3Q7PC9hPjxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCA4IE9jdG9iZXIgMjAxOSBhdCAx MTo1Nzxicj4NCjxiPlRvOiA8L2I+Q2hyaXN0b3BoZXIgV29vZCA8YSBjbGFzcz0ibW96LXR4dC1s aW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86Y2F3QGhlYXBpbmdiaXRzLm5ldCI+DQombHQ7Y2F3 QGhlYXBpbmdiaXRzLm5ldCZndDs8L2E+LCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZF IiBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj4NCiZxdW90O1RMU0BpZXRmLm9yZyZxdW90Ozwv YT4gPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnRsc0BpZXRm Lm9yZyI+Jmx0O3Rsc0BpZXRmLm9yZyZndDs8L2E+PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBb VExTXSBTZWxmaWUgYXR0YWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpIENo cmlzLDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Rm9yIHRo ZSBiZW5lZml0IG9mIHRoZSBsaXN0LCBsZXQgbWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBh dHRhY2sgaXMgb25seSByZWxldmFudCB3aGVyZSBtdWx0aXBsZSBwYXJ0aWVzIHNoYXJlIHRoZSBz YW1lIFBTSyBhbmQgdXNlIHRoZSBzYW1lIFBTSyBmb3Igb3V0Z29pbmcgYW5kIGluY29taW5nIGNv bm5lY3Rpb25zLiBUaGVzZSBzaXR1YXRpb25zIGFyZSByYXRoZXIgcmFyZSwgYnV0IEkNCiBhY2Nl cHQgdGhhdCBUTFMgaXMgd2lkZWx5IHVzZWQgKGFuZCBzb21ldGltZXMgbWlzdXNlZCkgaW4gbWFu eSBwbGFjZXMuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5U aGUgU2VsZmllIGF0dGFjayBvbmx5IGhhcHBlbnMgd2hlbiBhbiBlbnRpdHkgd2l0aCB0aGUgUFNL IGFjdHMgbWFsaWNpb3VzbHkuIFNvIEkgdGhpbmsgdGhlIGZhY3QgdGhhdCB5b3Ugd3JpdGUgaW4g dGhlIGRyYWZ0OiAmcXVvdDtlYWNoIG5vZGUgbXVzdCBiZSB0cnVzdGVkIG5vdCB0byBpbXBlcnNv bmF0ZSBhbm90aGVyIG5vZGUncyByb2xlJnF1b3Q7IGRvZXMgbm90IHRha2UgaW50byBhY2NvdW50 IHRoYXQgdGhlcmUNCiBtdXN0IGJlIGEgbWFsaWNpb3VzIG5vZGUgZm9yIHRoZSBzZWxmaWUgYXR0 YWNrIHRvIGhhcHBlbiBpbiB0aGUgZmlyc3QgcGxhY2UuIDxvOnA+DQo8L286cD48L3A+DQo8cCBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5EcnVja2VyIGFuZCBHdWVyb24ncyBwYXBlciByZWNv bW1lbmRzIHRoYXQgJnF1b3Q7ZXZlcnkgcGFydGljaXBhdGluZyBwYXJ0eSBnZXRzIChkdXJpbmcg dGhlIHNldHVwIG9mIHRoZSBuZXR3b3JrKSBhIHVuaXF1ZSBpZGVudGl0eSZxdW90OyBhbmQgJnF1 b3Q7dGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlciBtdXN0IHZlcmlmeSB0aGUgdmFsaWRpdHkgb2Yg dGhlIGNsYWltZWQgaWRlbnRpdGllcy4mcXVvdDsuIFRoZSByZWFsaXR5IGhvd2V2ZXINCiBpcyB0 aGF0IGluIG1vc3QgZ3JvdXAgUFNLIHNjZW5hcmlvcywgdGhlIG5vZGVzIGRvbid0IGhhdmUgYW55 IHN0cm9uZyBpZGVudGl0aWVzIHRoYXQgY2FuIGJlIHZlcmlmaWVkLg0KPG86cD48L286cD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5XaGF0IHlvdSBzaG91bGQgaW5zdGVhZCAo b3IgYWRkaXRpb25hbGx5KSBzYXkgaW4gdGhlIHRleHQgaXMgdGhhdCBhIG5vZGUgc2hvdWxkIGNo ZWNrIHRoYXQgdGhlIGNsaWVudF9tYWMgYW5kIHNlcnZlcl9tYWMgKG9yIGFueSBvdGhlciBpZGVu dGl0aWVzIHVzZWQpDQo8Yj5hcmUgbmV2ZXIgdGhlIHNhbWU8L2I+LiBXaXRob3V0IHRoaXMgY2hl Y2ssIHRoZSBzZWxmaWUgYXR0YWNrIHdvdWxkIHN0aWxsIGJlIHBvc3NpYmxlLiBBbmQgYXQgbGVh c3QgdGhpcyBkb2VzIG5vdCByZXF1aXJlIHN0cm9uZyBpZGVudGl0eSB2ZXJpZmljYXRpb24gZm9y IHByZXZlbnRpbmcgc2VsZmllIGF0dGFja3MuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPi0tTW9oaXQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAxMC81LzE5IDI6NDEg UE0sIENocmlzdG9waGVyIFdvb2Qgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBGZW5nLDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkZvciB3aGF0IGl0J3Mgd29ydGgsIHRoZSBs YXRlc3QgdmVyc2lvbiBvZiB0aGUgUFNLIGltcG9ydGVycyBkcmFmdCBpbmNsdWRlcyBhICZxdW90 O2NvbnRleHQmcXVvdDsgZmllbGQgaW50byB3aGljaCBpZGVudGl0eSBpbmZvcm1hdGlvbiBjYW4g YmUgZmVkOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyLTAxI2FwcGVuZGl4LUIiIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLWV4 dGVybmFsLXBzay1pbXBvcnRlci0wMSNhcHBlbmRpeC1CPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkJlc3QsPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Q2hyaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUdWUsIFNlcCAyNCwgMjAxOSwgYXQgOTox OSBBTSwgSGFvLCBGZW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+SGkgSm9obiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5SZWZsZWN0aW9uIGF0dGFja3MgYXJlIGluZGVlZCBvbGRlciwg YnV0IHRoZSBzZWxmaWUgYXR0YWNrIGlzIGEgYml0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmRpZmZlcmVudC4gSXQncyBhY3R1YWxseSBhIHZhcmlh bnQgb2YgdGhlIHVua25vd24ga2V5IHNoYXJlIGF0dGFjay4gQSA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50eXBpY2FsIGV4YW1wbGUgb2YgdGhlIFVL UyBhdHRhY2sgaXMgdGhlIG9uZSByZXBvcnRlZCBvbiBNUVYgYnkgS2FsaXNraSA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5pbiAyMDAxIChzZWUgJnF1 b3Q7QW4gdW5rbm93biBrZXktc2hhcmUgYXR0YWNrIG9uIHRoZSBNUVYga2V5IGFncmVlbWVudCA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5wcm90b2Nv bCZxdW90OyBpbiBBQ00gVElTU0VDIDIwMDEpLiBJbiB0aGF0IGV4YW1wbGUsIHRoZSBhZHZlcnNh cnkgcGxheXMgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+bWVzc2FnZSBiZXR3ZWVuIHR3byB1c2VycyB0byBjYXVzZSBjb25mdXNpb24gaW4gdGhlIGlk ZW50aXR5LCBidXQgaW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+U2VsZmllLCB0aGUgYWR2ZXJzYXJ5IHBsYXlzIG1lc3NhZ2Ugd2l0aCBvbmx5IG9u ZSB1c2VyIGFuZCB1c2VzIGFub3RoZXIgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+aW5zdGFuY2Ugb2YgdGhlIHVzZXIgdG8gY2F1c2UgY29uZnVzaW9u IGluIHRoZSBpZGVudGl0eS4gV2hlbiB3ZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5yZXBvcnRlZCB0aGlzIHZhcmlhbnQgb2YgVUtTIGluIFszXSwg d2Ugd2VyZSBub3QgYXdhcmUgb2YgYW55dGhpbmcgbGlrZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij50aGF0IGluIHRoZSBsaXRlcmF0dXJlLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkNoZWVycyw8bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5GZW5nPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjQvMDkvMjAx OSwgMTY6MTcsICZxdW90O0pvaG4gTWF0dHNzb24mcXVvdDsgPGEgaHJlZj0ibWFpbHRvOmpvaG4u bWF0dHNzb25AZXJpY3Nzb24uY29tIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPiZsdDtqb2huLm1h dHRzc29uQGVyaWNzc29uLmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBIaSw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SSB0aGluayB0aGVzZSByZWZsZWN0aW9uIGF0dGFja3Mg YXJlIG11Y2ggb2xkZXIgdGhhbiB0aGlzLiBJIHF1aWNrIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnNlYXJjaCBmb3IgcmVmbGVjdGlvbiBhdHRhY2sg c2VjdXJpdHkgcHJvdG9jb2wgZ2l2ZXMgYSBsb3Qgb2Ygb2xkIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnJlc3VsdHMsIFRoZSBkZXNjcmlwdGlvbiBv ZiByZWZsZWN0aW9uIGF0dGFjayBpbiB0aGUgZm9sbG93aW5nIGxlY3R1cmUgPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+bWF0ZXJpYWwgZnJvbSAyMDA5 IGxvb2tzIGp1c3QgbGlrZSB0aGUgJnF1b3Q7c2VsZmllIGF0dGFjayZxdW90OyBvbiBUTFMgMS4z PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuY3MuYmhhbS5hYy51ay9+dHBjL2N3aS9U ZWFjaGluZy9GaWxlcy9MZWN0dXJlNF82dXAucGRmIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0 dHA6Ly93d3cuY3MuYmhhbS5hYy51ay9+dHBjL2N3aS9UZWFjaGluZy9GaWxlcy9MZWN0dXJlNF82 dXAucGRmPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtXaXRoIG11bHRpcGxlIHNl Y3Rpb25zIHRoZXJlIGFyZSBvdGhlciB0aGluZ3MgdGhhdCBjaGFuZ2UgYXMgd2VsbC4gPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgdHdvIG5vZGVz IHVuaW50ZW50aW9uYWxseSBpbml0aWF0ZSBzaW11bHRhbmVvdXMgQ2xpZW50SGVsbG8gdG8gZWFj aCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5vdGhl ciwgZXZlbiBpZiB0aGV5IG9ubHkgd2FudCBhIHNpbmdsZSBzZWN1cmUgY29ubmVjdGlvbiAoSSBo YXZlIHNlZW4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+bGl2ZSBzeXN0ZW1zIHdoZXJlIHRoaXMgaGFwcGVucyBpbiBwcmFjdGljZSksIGFuIGF0dGFj a2VyIGNhbiBzZWxlY3QgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+d2hpY2ggQ2xpZW50SGVsbG8gdG8gYmxvY2sgKGUuZy4gdGhlIG9uZSB3aXRoIHRo ZSBzdHJvbmdlc3QgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Y3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzKS4gVGhlIGZvbGxvd2luZyBzZWN1cml0eSBw cm9wZXJ0eSB3b3VsZCB0aGVuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPm5vIGxvbmdlciBob2xkIDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7JnF1b3Q7RG93bmdyYWRlIHByb3RlY3Rpb246Jm5ic3A7IFRoZSBjcnlw dG9ncmFwaGljIHBhcmFtZXRlcnMgc2hvdWxkIGJlIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzYW1lIG9uIGJvdGggc2lkZXMgYW5kIHNob3VsZCBi ZSB0aGUgc2FtZSBhcyBpZiB0aGUgcGVlcnMgaGFkIGJlZW48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY29tbXVuaWNhdGluZyBpbiB0aGUgYWJzZW5jZSBv ZiBhbiBhdHRhY2smcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KEkgaGF2ZSBu b3QgbG9va2VkIGF0IHdoYXQgdGhlIGRlZmluaXRpb25zIGluIFtCQkZHS1oxNl0gc2F5KS48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJz cDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q2hlZXJzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBKb2huPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEZyb206IFRMUyA8YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0O3Rscy1ib3VuY2VzQGlldGYub3JnJmd0OzwvYT4gb24g YmVoYWxmIG9mICZxdW90O0hhbywgRmVuZyZxdW90OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJtYWlsdG86RmVuZy5IYW9Ad2Fyd2lj ay5hYy51ayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj4mbHQ7RmVuZy5IYW9Ad2Fyd2ljay5hYy51 ayZndDs8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGU6IFR1ZXNkYXksIDI0IFNlcHRlbWJlciAyMDE5IGF0 IDE2OjA5PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ ICZuYnNwOyZuYnNwOyZuYnNwO1RvOiBNb2hpdCBTZXRoaSBNIDxhIGhyZWY9Im1haWx0bzptb2hp dC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiPiZsdDttb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0 OzwvYT4sIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZxdW90O093ZW4gRnJpZWwgKG9mcmllbCkmcXVvdDsgPGEgaHJlZj0ibWFpbHRvOm9mcmllbEBj aXNjby5jb20iIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0O29mcmllbEBjaXNjby5jb20mZ3Q7 PC9hPiwgSm9uYXRoYW4gSG95bGFuZCA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJtYWlsdG86am9uYXRoYW4uaG95bGFuZEBnbWFpbC5j b20iIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0O2pvbmF0aGFuLmhveWxhbmRAZ21haWwuY29t Jmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQ2M6IDxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSI+JnF1b3Q7VExTQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBocmVm PSJtYWlsdG86dGxzQGlldGYub3JnIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPiZsdDt0bHNAaWV0 Zi5vcmcmZ3Q7PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyBTdWJqZWN0OiBSZTogW1RMU10gU2VsZmllIGF0dGFj ayB3YXMgUmU6IERpc3Rpbmd1aXNoaW5nIGJldHdlZW4gPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ZXh0ZXJuYWwvcmVzdW1wdGlvbiBQU0tzPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09uIDIzLzA5LzIwMTksIDE4OjUwLCAm cXVvdDtUTFMgb24gYmVoYWxmIG9mIE1vaGl0IFNldGhpIE0mcXVvdDsgPG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGEgaHJlZj0ibWFpbHRvOnRscy1i b3VuY2VzQGlldGYub3Jnb25iZWhhbGZvZm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1h cmMuaWV0Zi5vcmciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0O3Rscy1ib3VuY2VzQGlldGYu b3JnIG9uIGJlaGFsZiBvZiA8bzpwPjwvbzpwPjwvYT48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gY2xhc3M9Ik1zb0h5cGVybGluayI+PGEgaHJlZj0ibWFpbHRv OnRscy1ib3VuY2VzQGlldGYub3Jnb25iZWhhbGZvZm1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5j b21AZG1hcmMuaWV0Zi5vcmciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bW9oaXQubS5zZXRoaT00 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8L2E+PC9zcGFuPiB3cm90ZTo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SGkgYWxsLDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtPbiB0aGUgdG9waWMgb2YgZXh0ZXJuYWwgUFNLcyBpbiBUTFMgMS4zLCBJIGZvdW5kIGEgPG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+cHVibGljYXRp b24gb24gdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1NlbGZpZSBhdHRhY2s6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmly ZWV5ZS5jb20vdXJsP2s9ZGQ0MzJmMTMtODFjOWU1YWQtZGQ0MzZmODgtODY5YTE3YjViMjFiLWRj NmM2ZjBhNWRkMjFmYWYmYW1wO3E9MSZhbXA7dT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9y ZyUyRjIwMTklMkYzNDciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+aHR0cHM6Ly9wcm90ZWN0Mi5m aXJlZXllLmNvbS91cmw/az1kZDQzMmYxMy04MWM5ZTVhZC1kZDQzNmY4OC04NjlhMTdiNWIyMWIt ZGM2YzZmMGE1ZGQyMWZhZiZhbXA7cT0xJmFtcDt1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iu b3JnJTJGMjAxOSUyRjM0NzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UGVyaGFwcyB0aGlzIHdhcyBhbHJlYWR5 IGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gSSB0aG91Z2h0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRoYXQgc2hhcmluZyA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpdCBhZ2Fp biB3b3VsZG4ndCBodXJ0IHdoaWxlIHdlIGRpc2N1c3MgaG93IHNlcnZlcnMgPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ZGlzdGluZ3Vpc2ggYmV0d2Vl biA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtleHRlcm5hbCBhbmQgcmVzdW1wdGlvbiBQU0tzLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJIGp1c3QgcmVhZCB0aGUgcGFwZXIgd2l0aCBp bnRlcmVzdC4gSXQgb2NjdXJzIHRvIG1lIHRoYXQgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnNlbGZpZSBhdHRhY2sgaXMgY29uc2lzdGVudCB3 aXRoIHRoZSAmcXVvdDtpbXBlcnNvbmF0aW9uIGF0dGFjayZxdW90OyB0aGF0IHdlIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnJlcG9ydGVkIG9uIFNQ RUtFIGluIDIwMTQ7IHNlZSBTZWMgNC4xIFsxXSBhbmQgdGhlIHVwZGF0ZWQgdmVyc2lvbiB3aXRo IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmRldGFp bHMgb24gaG93IFNQRUtFIGlzIHJldmlzZWQgaW4gSVNPL0lFQyAxMTc3MC00IFsyXS4gVGhlIHNh bWUgYXR0YWNrIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPmNhbiBiZSB0cmFjZWQgYmFjayB0byAyMDEwIGluIFszXSB3aGVyZSBhICZxdW90O3dvcm0t aG9sZSBhdHRhY2smcXVvdDsgKEZpZy4gNSwgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WzNdKSBpcyByZXBvcnRlZCBvbiB0aGUgc2VsZi1jb21tdW5p Y2F0aW9uIG1vZGUgb2YgSE1RVi4gVGhlIGVzc2VuY2Ugb2YgPG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dGhlc2UgYXR0YWNrcyBpcyB0aGUgc2FtZTog Qm9iIHRyaWNrcyBBbGljZSBpbnRvIHRoaW5raW5nIHRoYXQgc2hlIGlzIDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnRhbGtpbmcgdG8gYXV0aGVudGlj YXRlZCBCb2IsIGJ1dCBzaGUgaXMgYWN0dWFsbHkgdGFsa2luZyB0byBoZXJzZWxmLiA8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JbiBbM10sIHdlIGV4 cGxhaW5lZCB0aGF0IHRoZSBhdHRhY2sgd2FzIG1pc3NlZCBmcm9tIHRoZSAmcXVvdDtzZWN1cml0 eSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5wcm9v ZnMmcXVvdDsgYXMgdGhlIHByb29mcyBkaWRuJ3QgY29uc2lkZXIgbXVsdGlwbGUgc2Vzc2lvbnMu IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBjb3VudGVybWVhc3VyZSB3ZSBwcm9wb3Nl ZCBpbiBbMS0zXSB3YXMgdG8gZW5zdXJlIHRoZSB1c2VyIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPmlkZW50aXR5IGlzIHVuaXF1ZSBpbiBrZXkgZXhj aGFuZ2UgcHJvY2Vzc2VzOiBpbiBjYXNlIG9mIG11bHRpcGxlIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnNlc3Npb25zIHRoYXQgbWF5IGNhdXNlIGNv bmZ1c2lvbiBpbiB0aGUgdXNlciBpZGVudGl0eSwgYW4gZXh0ZW5zaW9uIDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnNob3VsZCBiZSBhZGRlZCB0byB0 aGUgdXNlciBpZGVudGl0eSB0byBkaXN0aW5ndWlzaCB0aGUgaW5zdGFuY2VzLiBUaGUgPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+dW5kZXJseWluZyBp bnR1aXRpb24gaXMgdGhhdCBvbmUgc2hvdWxkIGtub3cgJnF1b3Q7dW5hbWJpZ3VvdXNseSZxdW90 OyB3aG9tIHRoZXkgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+YXJlIGNvbW11bmljYXRpbmcgd2l0aCwgYW5kIHBlcmZvcm0gYXV0aGVudGljYXRpb24g YmFzZWQgb24gdGhhdC4gVGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPmRpc2NvdmVyeSBvZiB0aGlzIHR5cGUgb2YgYXR0YWNrcyBhbmQgdGhlIHBy b3Bvc2VkIHNvbHV0aW9uIGFyZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5pbnNwaXJlZCBieSB0aGUgJnF1b3Q7ZXhwbGljaXRuZXNzIHByaW5jaXBs ZSZxdW90OyAoUm9zcyBBbmRlcnNvbiBhbmQgUm9nZXIgPG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TmVlZGhhbSwgQ3J5cHRvJzk1KSwgd2hpY2ggc3Rh dGVzIHRoZSBpbXBvcnRhbmNlIG9mIGJlaW5nIGV4cGxpY2l0IG9uIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPnVzZXIgaWRlbnRpdGllcyBhbmQgb3Ro ZXIgYXR0cmlidXRlcyBpbiBhIHB1YmxpYyBrZXkgcHJvdG9jb2w7IGFsc28gc2VlIDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlszXS4gSSBob3BlIGl0 IG1pZ2h0IGJlIHVzZWZ1bCB0byBwZW9wbGUgd2hvIHdvcmsgb24gVExTIFBTSy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7WzFdIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9NWE4 MjI1MTMtMDYwOGVmYWQtNWE4MjY1ODgtODY5YTE3YjViMjFiLWViMjYwMTUxZjc4YjA3MTgmYW1w O3E9MSZhbXA7dT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTQlMkY1ODUucGRm IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJs P2s9NWE4MjI1MTMtMDYwOGVmYWQtNWE4MjY1ODgtODY5YTE3YjViMjFiLWViMjYwMTUxZjc4YjA3 MTgmYW1wO3E9MSZhbXA7dT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIwMTQlMkY1 ODUucGRmPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbMl0gPGEgaHJl Zj0iaHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE4MDIuMDQ5MDAiIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSI+aHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE4MDIuMDQ5MDA8L2E+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFszXSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3Vy bD9rPWQ1YmY4OGZmLTg5MzU0MjQxLWQ1YmZjODY0LTg2OWExN2I1YjIxYi0wZTliM2JmNThlMTA0 ZjMyJmFtcDtxPTEmYW1wO3U9aHR0cHMlM0ElMkYlMkZlcHJpbnQuaWFjci5vcmclMkYyMDEwJTJG MTM2LnBkZiIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Byb3RlY3QyLmZpcmVleWUu Y29tL3VybD9rPWQ1YmY4OGZmLTg5MzU0MjQxLWQ1YmZjODY0LTg2OWExN2I1YjIxYi0wZTliM2Jm NThlMTA0ZjMyJmFtcDtxPTEmYW1wO3U9aHR0cHMlM0ElMkYlMkZlcHJpbnQuaWFjci5vcmclMkYy MDEwJTJGMTM2LnBkZjwvYT4gPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VExTIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBo cmVmPSJtYWlsdG86VExTQGlldGYub3JnIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPlRMU0BpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIG1vei1kby1ub3Qtc2VuZD0i dHJ1ZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VExTIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxh IGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+VExTQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiBt b3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+VExTIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSI+VExTQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3945c14b7e72808fec8c81c6f485adf6ericssoncom_-- From nobody Tue Oct 8 06:22:44 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF6212004E; Tue, 8 Oct 2019 06:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 iqucOV7uzDeW; Tue, 8 Oct 2019 06:22:41 -0700 (PDT) Received: from mail-vs1-f68.google.com (mail-vs1-f68.google.com [209.85.217.68]) (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 CEC5E120086; Tue, 8 Oct 2019 06:22:38 -0700 (PDT) Received: by mail-vs1-f68.google.com with SMTP id z14so11249742vsz.13; Tue, 08 Oct 2019 06:22:38 -0700 (PDT) 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=89+P+fMyM2I6EF/E0+oplCDwbQ0Ubi9ZRzk+OnnBsW0=; b=hBPusKXcngGEe1xPZkshlszAU6hPnCSIKRkClGNnFOPz8B/ej40ThJz7/g7mocZ+ow vuHHfQtXV8JuOjYHoCArx20Dj9lZpTsMAusjYGxtu2UnhXnZgxd9Zood6pWuioZmHlIT kZcM/FDy66Stg9F2sJ28LoHqqxnBqabv9qsracMYyAXaVfkWKzG40ySk8dZfmnfip2R+ 67FzPISq/Tb4MUPsYGjGOeSv4AtWbxmJby5sMp0hUFloxbQ5bYNH8YbPLKkOiT8k4j0Z /nH5t1HMCqwVwSL0Ii8jeY5tj+VGHkiVpoxNmZFUO7curAk3VclSuIc3A5HMz4/dFBuf VGbw== X-Gm-Message-State: APjAAAVyvbjHwnJlIYVMnIOCikqsfmv7SRLJST8tZwqPDUaCG7Be7Il9 JUOzTnLzngSPtC80RX8YCwngbnXDfgE3EdIcP7PQ4p93L7g= X-Google-Smtp-Source: APXvYqzE4RHPi4CeKY+nubvAmsT77NhS1XwGuzjtb7IgB21U/M7gPFmcnOnvgLnXQlprieh3pUyhcqfuy5IsesW60N4= X-Received: by 2002:a67:c297:: with SMTP id k23mr17634430vsj.31.1570540957838; Tue, 08 Oct 2019 06:22:37 -0700 (PDT) MIME-Version: 1.0 References: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> In-Reply-To: <20191008120506.GF76545@kduck.mit.edu> From: Daniel Migault Date: Tue, 8 Oct 2019 09:22:23 -0400 Message-ID: To: Benjamin Kaduk Cc: Stephen Farrell , Sean Turner via Datatracker , IESG Secretary , "tls@ietf.org" , John Mattsson , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e5b2dd0594660f7e" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 13:22:42 -0000 --000000000000e5b2dd0594660f7e Content-Type: text/plain; charset="UTF-8" Hi, For clarity to the WG I am summarizing the discussion of the "lesson learnt from deprecation" thread. There is in my opinion a consensus that the current text does not emphasize enough that TLS 1.3 is the current version of TLS. There is also a consensus that the current draft limits the wording in emphasizing that TLS 1.3 obsoletes TLS 1.2 and is the current version to consider. The current texts that are subject to changes are the following: TEXT A: """The expectation is that TLSv1.2 will continue to be used for many years alongside TLSv1.3.""" Proposed alternatives are: a) remove the sentence b) leave the sentence as it is c) clarify the sentence for example with the following text: """ While TLSv1.2 and TLSv1.3 are likely to coexist for some time, it is strongly RECOMMENDED to consider the adoption of TLSv1.3""" TEXT B: """TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions.""" Proposed alternatives are: a) leave the sentence as it is b) clarify the sentence for example with the following text: """The current recommended version for TLS is 1.3 and version 1.2 has been recommended since 2008, providing sufficient time to transition away from older versions.""" TEXT C: """Deprecation of these versions is intended to assist developers as additional justification to no longer support older TLS versions and to migrate to a minimum of TLSv1.2. Deprecation also assists product teams with phasing out support for the older versions to reduce the attack surface and the scope of maintenance for protocols in their offerings. """ Proposed alternatives are: a) leave the sentence as it is b) clarify the sentence for example with the following text: """Deprecation of these versions is intended to assist developers as additional justification to no longer support older TLS versions and to migrate to a minimum of TLSv1.2. At the time of writing this document this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is strongly RECOMMENDED. If TLSv1.2 were not supported yet, adoption of TLSv1.3 is RECOMMENDED. Deprecation also assists product teams with phasing out support for the older versions to reduce the attack surface and the scope of maintenance for protocols in their offerings. """ My personal opinion is to have some text that reflects what we think. Yours, Daniel On Tue, Oct 8, 2019 at 8:05 AM Benjamin Kaduk wrote: > On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farrell wrote: > > > > Hiya, > > > > On 07/10/2019 18:29, Rob Sayre wrote: > > > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > > wrote: > > >> we can't "UPDATE" an I-D. > > > > > > Not true. If you need to refer to something that's been IESG-approved > but > > > still in the RFC queue, you can leave a note for the RFC editor to > update > > > the reference to the eventual RFC number. > > > > That would be an UPDATE on the eventual RFC and not on the > > I-D. And in this case, it'd IMO not be a good plan as a) the > > Recent IESGs have been taking the stance that it's weird to have "Updates:" > to a document that's not yet an RFC, mostly preferring to pull the document > in question back and get changed directly. But ... > > > relevant WG didn't want that, b) the I-D in question is part > > of a mega-cluster, so any dependency on it (as you suggest) > > risks loadsa delay if the cluster doesn't get unstuck, which > > can happen and c) our draft already stretches the header > > .... given that C238 is unblocked, dependencies-wise, that seems > questionable in this case. (The whole set of documents does have to go > through the xmlv2-->xmlv3 conversion, though.) > > > enough updating 85 RFCs - trying to add an I-D to that list > > would break tools and cause much pointless process-angst. > > > > Mostly (a) is the reason to not do it though. If you want > > to disagree with (a), then the right list for that would be > > the rtcweb list I guess, even though the WG is now concluded > > (which could, I guess, be (d);-) > > > > Overall, the cost isn't worth the benefit IMO. > > That's roughly where I'm landing, too, though as noted previously, it's > largely up to the sponsoring AD. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000e5b2dd0594660f7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

F= or clarity to the WG I am summarizing the discussion of the "lesson le= arnt from deprecation" thread.=C2=A0

There is= in my opinion a consensus that the current text does not emphasize enough = that TLS 1.3 is the current version of TLS. There is also a consensus that = the current draft limits the wording in emphasizing that TLS 1.3 obsoletes = TLS 1.2 and is the current version to consider.=C2=A0

<= div>The current texts that are subject to changes are the following:
<= div>
TEXT A:=C2=A0

"""= ;The expectation is that TLSv1.2 will continue to be used for many years al= ongside TLSv1.3."""

Proposed altern= atives are:=C2=A0
a) remove the sentence
b) leave the s= entence as it is=C2=A0
c) clarify the sentence for example with t= he following text:
""" While TLSv1.2 and TLSv1.3 a= re likely to coexist for some time, it is strongly RECOMMENDED to consider = the adoption of TLSv1.3"""
=C2=A0=C2=A0
= =C2=A0
TEXT B:

"""TLSv1.2= has been the recommended version for IETF protocols since 2008, providing = sufficient time to transition away from older versions."""

Proposed alternatives are:=C2=A0
a) leave= the sentence as it is=C2=A0
b) clarify the sentence for example = with the following text:
"""The current recommende= d version for TLS is 1.3 and version 1.2 has been recommended since 2008, p= roviding sufficient time to transition away from older versions.""= ;"

TEXT C:


"""Deprecation of these versions is intended to assist= developers as
=C2=A0 =C2=A0additional justification to no longer= support older TLS versions and
=C2=A0 =C2=A0to migrate to a mini= mum of TLSv1.2.=C2=A0 Deprecation also assists product
=C2=A0 =C2= =A0teams with phasing out support for the older versions to reduce the
=C2=A0 =C2=A0attack surface and the scope of maintenance for protocol= s in their
=C2=A0 =C2=A0offerings.
"""

Proposed alternatives are:=C2=A0
a) leave= the sentence as it is=C2=A0
b) clarify the sentence for example = with the following text:
"""Deprecation of these v= ersions is intended to assist developers as
=C2=A0 =C2=A0addition= al justification to no longer support older TLS versions and
=C2= =A0 =C2=A0to migrate to a minimum of TLSv1.2. At the time of writing this d= ocument this includes TLSv1.2 and TLSv1.3. The adoption of TLSv1.3 is stron= gly RECOMMENDED. If TLSv1.2 were not supported yet, adoption of TLSv1.3 is = RECOMMENDED.=C2=A0 Deprecation also assists product
=C2=A0 =C2=A0= teams with phasing out support for the older versions to reduce the
=C2=A0 =C2=A0attack surface and the scope of maintenance for protocols i= n their
=C2=A0 =C2=A0offerings.
"""

My personal opinion is to have some text that reflects= what we think.

Yours,=C2=A0
Daniel
=

= On Tue, Oct 8, 2019 at 8:05 AM Benjamin Kaduk <kaduk@mit.edu> wrote:
On Mon, Oct 07, 2019 at 09:12:44PM +0100, Stephen Farr= ell wrote:
>
> Hiya,
>
> On 07/10/2019 18:29, Rob Sayre wrote:
> > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <stephen.farrell@cs.tcd.ie<= /a>>
> > wrote:
> >> we can't "UPDATE" an I-D.
> >
> > Not true. If you need to refer to something that's been IESG-= approved but
> > still in the RFC queue, you can leave a note for the RFC editor t= o update
> > the reference to the eventual RFC number.
>
> That would be an UPDATE on the eventual RFC and not on the
> I-D. And in this case, it'd IMO not be a good plan as a) the

Recent IESGs have been taking the stance that it's weird to have "= Updates:"
to a document that's not yet an RFC, mostly preferring to pull the docu= ment
in question back and get changed directly.=C2=A0 But ...

> relevant WG didn't want that, b) the I-D in question is part
> of a mega-cluster, so any dependency on it (as you suggest)
> risks loadsa delay if the cluster doesn't get unstuck, which
> can happen and c) our draft already stretches the header

.... given that C238 is unblocked, dependencies-wise, that seems
questionable in this case.=C2=A0 (The whole set of documents does have to g= o
through the xmlv2-->xmlv3 conversion, though.)

> enough updating 85 RFCs - trying to add an I-D to that list
> would break tools and cause much pointless process-angst.
>
> Mostly (a) is the reason to not do it though. If you want
> to disagree with (a), then the right list for that would be
> the rtcweb list I guess, even though the WG is now concluded
> (which could, I guess, be (d);-)
>
> Overall, the cost isn't worth the benefit IMO.

That's roughly where I'm landing, too, though as noted previously, = it's
largely up to the sponsoring AD.

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e5b2dd0594660f7e-- From nobody Tue Oct 8 06:26:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8721201E0; Tue, 8 Oct 2019 06:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UenE6PMcN2hv; Tue, 8 Oct 2019 06:26:08 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 7766B12004E; Tue, 8 Oct 2019 06:26:05 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id n197so36332718iod.9; Tue, 08 Oct 2019 06:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zOobsmqO9NhGhJtcVUvhYg2tt53FSwIU/q2TMmShYeQ=; b=BYSdOmF1Xp4NN/fe5D2XodSv3Nz0gjBv99IH2HA/ZDMclpdOR4ckCloGTyl6AFO21a kEDYihSmTj576X+qGba58o2cjy9fLz0U+lvDjEpQs00scFXuS++6Y5U/ysTNSsZAPsjw 4egj+TNketOfegxS3FA3XGuebEME2LcP8NxvlhqPWQed/VI/4TSc3GjQKQr/NVI9Nrpc PAcV5oKWVp/3GxRL8UOeQ1wEKajYGR9VibJKKWuEUEDripfSIcDcA9PHCmOiCVz6irpO dutvxRm7UdtPaVFtFhsaYSQP44xigqQQVI4jHt7WNmYdAvKpkaKh5GU/vR2hoIavsM93 SNLA== 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=zOobsmqO9NhGhJtcVUvhYg2tt53FSwIU/q2TMmShYeQ=; b=lhxjphuJAPwxNtoHY7uCEr2T+Sl14D22hbm7GfmxT/Pae3Y4vzujVrUvC+wYv4UCwB saaJMoqn+urkeDOvE7YG01ZTAbMib6esftLrZG2xuGcdv0mGX/AefRYGIfuuD4B1ht6w Mc5e2ECJ+U1AEopunT9b9ut7nPAtqX5S6zoB+k05u50iEppKodT172x0QYh3W0Wh+eFp c3dj+cmkVSG5MqWZWnhJuMvZYY5zC7Z73oggTjfu+uJA2Nr4Q3YciJDNMEqLFqs8rIzS WPi+uzVpx0Tof/scMebA5VHq33it6sh/1I0l5QFUus5PDNS9e/VrcxTCVnSrAlPWpYXA 85Pw== X-Gm-Message-State: APjAAAXD4lqU95DOps7RfNsCW/wTQBwb9qCqWIucdzHvWnWOuqhO7DIV qWghbT9bhRRTnRGiJFJwinwDGow83S51HHOeeB0= X-Google-Smtp-Source: APXvYqw5T7l7NgMpLZSi6T3nePr/oZjU9lzcbd4YCBtNwUX4UIl0hAOqGXGwD7zwPOfX6q1MP0bD4GtJ5wZU4xsSsAk= X-Received: by 2002:a5e:8902:: with SMTP id k2mr2199988ioj.49.1570541164552; Tue, 08 Oct 2019 06:26:04 -0700 (PDT) MIME-Version: 1.0 References: <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> In-Reply-To: <20191008120506.GF76545@kduck.mit.edu> From: Rob Sayre Date: Tue, 8 Oct 2019 20:25:51 +0700 Message-ID: To: Benjamin Kaduk Cc: Stephen Farrell , Eric Rescorla , Sean Turner via Datatracker , John Mattsson , "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000037e8890594661c4f" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Tue, 08 Oct 2019 13:26:10 -0000 --00000000000037e8890594661c4f Content-Type: text/plain; charset="UTF-8" On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk wrote: > it's largely up to the sponsoring AD. > Is that true? I'm not sure which procedure you're describing. At any rate, I think one issue is with the abstract of draft-ietf-tls-oldversions-deprecate: "This document also deprecates Datagram TLS (DTLS) version 1.0 [RFC6347] (but not DTLS version 1.2, and there is no DTLS version 1.1). This document updates many RFCs that normatively refer to TLSv1.0 or TLSv1.1 as described herein. This document also updates RFC 7525 and hence is part of BCP195." What it doesn't do is state that it updates RFCs that normatively refer to DTLS 1.0 and/or DTLS 1.2. It seems like it should, since RFC 6347 states: "Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS 1.2 implementations can interoperate with previous versions of TLS...". Although I favor deprecating DTLS 1.0 conclusively and thoroughly, there is an argument for eliding DTLS entirely in draft-ietf-tls-oldversions-deprecate, NIST SP800-52r2 explicitly states that it doesn't cover DTLS, but that document is the only citation in the "Support for Deprecation" section of draft-ietf-tls-oldversions-deprecate. Updating in-flight documents to avoid citing soon-to-be-deprecated TLS RFCs is something I expect Area Directors to be doing. It's a predictable problem. thanks, Rob --00000000000037e8890594661c4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 8, 2019 at 7:05 PM Benjamin K= aduk <kaduk@mit.edu> wrote:
<= /div>
it's largely up to the sponsoring AD.

<= /div>
Is that true? I'm not sure which procedure you're describ= ing.

At any rate, I think one issue is with the ab= stract of=C2=A0draft-ietf-tls-oldversions-deprecate:

"This document also deprecates Datagram TLS (DTLS) version 1.0 [RFC= 6347] (but not DTLS version 1.2, and there is no DTLS version 1.1).
Th= is document updates many RFCs that normatively refer to TLSv1.0 or TLSv1.1 = as described herein.=C2=A0 This document also updates RFC 7525 and hence is= part of BCP195."

What it doesn't do is state that it updates RFCs=C2=A0= that normatively refer to DTLS 1.0 and/or DTLS 1.2. It seems like it should= , since RFC 6347 states: "Implementations that speak both DTLS 1.2 and= DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS = 1.0 of course), just as TLS 1.2 implementations can interoperate with previ= ous versions of TLS...".

Although I favor deprecating DTLS 1.0 conclusively = and thoroughly, there is an argument for eliding DTLS entirely in=C2=A0draf= t-ietf-tls-oldversions-deprecate, NIST SP800-52r2 explicitly states that it= doesn't cover DTLS, but that document is the only citation in the &quo= t;Support for Deprecation" section of=C2=A0draft-ietf-tls-oldversions-= deprecate.

Updating in-flight documents to avoid cit= ing soon-to-be-deprecated TLS RFCs is something I expect Area Directors to = be doing. It's a predictable problem.

thanks,<= /div>
Rob
--00000000000037e8890594661c4f-- From nobody Tue Oct 8 07:02:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C96120113 for ; Tue, 8 Oct 2019 07:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 xMuu7N3KEvUN for ; Tue, 8 Oct 2019 07:02:34 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 600BF1200A3 for ; Tue, 8 Oct 2019 07:02:34 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id b136so36698321iof.3 for ; Tue, 08 Oct 2019 07:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dUagSEAx11tq6Ph1l6bJwzvB5tZkEhrOHUHCcOjdbNw=; b=AL6vOOUDJO8x0BiFkBrVLeBfIXPFcSoLC7u6/nJ3nxJHzRbPLo/DaHSt40s/HtxRQU ur69lQMUh3PL3yvZzVWk3VoQ8XvtJiBxP7z4pBe9xuBF7IwYp3H5lPjRrBKhMmIfGFRo +k1qE/lpO/YnST72z0K04xBFJxiJ98Ejz33r2KOtOmjmvfxm1VBmyvF+oxuZ/2IQg9tB BNvgqu3nfYSVDAHAVnIwXx+Uzr+1hWqOsfwgUE006W6GYytEluOa+Ya79nK9+PCOzoQX xZaq5+xHFlyi9dBNotMHAOliEE/OLKx+s7EVMT41hQzyI7dgwSqAR8YocX+IGM6oo3mz pX+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dUagSEAx11tq6Ph1l6bJwzvB5tZkEhrOHUHCcOjdbNw=; b=X5MUvz4ZzKxqKZxvVSldU6PCjBo5OgHlF4gLSAVeCDDoyVbdewUtaWsAMoM729HuTY 0YVG8aUUwpZ6U1WgcBsqz/9YNAmmgWpa15u7855m5ryAFlRrLMHD9KqwfIUoa/2Fp2hS 5XYbZkjAiqNabntCgsQ6nj6FTPcTtoKeVgy0sNcJqJFTgCVWtRrb0sHxsViKXN8ewq5k 8quVYbisjkHrWRRojBsrILyJs76mzKRVHHnSeepqSl1yHr+Qa1EzOmETFFrPl5MmTl2J skrlvw+pUYlNWdqRnkzREYD1mJz7u7L00QommkA2guuBwq+11aonLA7DV6EZWqf5o6fT si4w== X-Gm-Message-State: APjAAAXoMd2/f5uf5W5mbBx26/tE8MJtphl/YkzIjQqk5ZBOx0+d2Gll a4fBiH5d3wzTot1ibqs5WKThIjGkj32Q0bgQ07uldWZCdGzfZQ== X-Google-Smtp-Source: APXvYqySGsbCQmSQ91gi72yH9ZFO2fRvUg43MfzipTnezkmUuMIMwzCqdu8PsylRyLtZ8ThjF/kww6+0KI+WJh2JBbQ= X-Received: by 2002:a92:d184:: with SMTP id z4mr8596211ilz.189.1570543353006; Tue, 08 Oct 2019 07:02:33 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> In-Reply-To: <157048178892.4743.5417505225884589066@ietfa.amsl.com> From: Rob Sayre Date: Tue, 8 Oct 2019 21:02:20 +0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a912680594669e9e" Archived-At: Subject: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 14:02:37 -0000 --000000000000a912680594669e9e Content-Type: text/plain; charset="UTF-8" > Issues and Requirements for SNI Encryption in TLS One issue not covered in this document is SNI encryption from CDNs to Origin servers. For example, if I use ESNI to make a request to Cloudflare, how does Cloudflare then encrypt the SNI to the origin server? It seems like this use case could be covered by allowing the SNI to be sent alongside a client certificate (something many CDNs provide for). I think an extension accompanying a client certificate would be encrypted, but please correct me if I'm mistaken. These CDN<->Origin connections can usually be served over IPv6, so having the SNI in the ClientHello isn't necessarily as important. thanks, Rob On Tue, Oct 8, 2019 at 3:56 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Issues and Requirements for SNI Encryption in TLS > Authors : Christian Huitema > Eric Rescorla > Filename : draft-ietf-tls-sni-encryption-08.txt > Pages : 14 > Date : 2019-10-07 > > Abstract: > This draft 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. The draft lists known > attacks against SNI encryption, discusses the current "co-tenancy > fronting" 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. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-08 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-08 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a912680594669e9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0Issues and Requirements for SNI= Encryption in TLS

One issue not covered in this documen= t is SNI encryption from CDNs to Origin servers.

F= or example, if I use ESNI to make a request to Cloudflare, how does Cloudfl= are then encrypt the SNI to the origin server?

It = seems like this use case could be covered by allowing the SNI to be sent al= ongside a client certificate (something many CDNs provide for). I think an = extension accompanying a client certificate would be encrypted, but please = correct me if I'm mistaken.

These CDN<->= Origin connections can usually be served over IPv6, so having the SNI in th= e ClientHello isn't necessarily as important.

= thanks,
Rob

On Tue, Oct 8, 2019 at 3:56 AM <internet-drafts@ietf.org> wrote:
<= /div>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Layer Security WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Issues and Requirements for SNI Encryption in TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Chri= stian Huitema
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Eric Rescorla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-sni-encryption-08.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-10-07

Abstract:
=C2=A0 =C2=A0This draft describes the general problem of encrypting the Ser= ver
=C2=A0 =C2=A0Name Identification (SNI) TLS parameter.=C2=A0 The proposed so= lutions hide
=C2=A0 =C2=A0a Hidden Service behind a fronting service, only disclosing th= e SNI
=C2=A0 =C2=A0of the fronting service to external observers.=C2=A0 The draft= lists known
=C2=A0 =C2=A0attacks against SNI encryption, discusses the current "co= -tenancy
=C2=A0 =C2=A0fronting" solution, and presents requirements for future = TLS layer
=C2=A0 =C2=A0solutions.

=C2=A0 =C2=A0In practice, it may well be that no solution can meet every =C2=A0 =C2=A0requirement, and that practical solutions will have to make so= me
=C2=A0 =C2=A0compromises.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-tls-sni-encryption/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-t= ls-sni-encryption-08
https://datatracker.ietf.org/d= oc/html/draft-ietf-tls-sni-encryption-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-tls-sni-encryption-08


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

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a912680594669e9e-- From nobody Tue Oct 8 07:04:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226B412007C for ; Tue, 8 Oct 2019 07:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.476 X-Spam-Level: X-Spam-Status: No, score=-1.476 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.172, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FsIISHetizPT for ; Tue, 8 Oct 2019 07:04:35 -0700 (PDT) Received: from mail-vs1-f45.google.com (mail-vs1-f45.google.com [209.85.217.45]) (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 43741120122 for ; Tue, 8 Oct 2019 07:04:34 -0700 (PDT) Received: by mail-vs1-f45.google.com with SMTP id z14so11347416vsz.13 for ; Tue, 08 Oct 2019 07:04:34 -0700 (PDT) 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=5uw1I2EAWo4xm+J1wCY9VrpJPbfuUrbcQZNo9lrc8V8=; b=fOLnqUidOej4oCqqGSR0Bi8QTFEDo1tRFBazAd7wXV+Qg3aUoHmF4/mPBtSAFY/uaH c1Dsg6MKLs7ZVarwXs04Pr7uq1OTvrGKhHtZFKkGwr7rTWOmnw+2CxWLqmqmqpdTnEu7 0hf5r2oDIRbBiL0e23cKRuTsbMUY2tT/W4+6J547d+FJYWN6cyN0CpBQvr6IQ3n4PRrP qbKytuGfVpeyvx8nAccx32PTliBY+jsGUctJ6FlKZnVkAXeP8+UKOYqV2mRLrorj4kfx O2iSpwX2U0QWgr57MuopdM1yfOIb+kuoZUOQz4mrVnaFRzkkME8TaB+M/iZWuk1XbxhD ZgCQ== X-Gm-Message-State: APjAAAXAMLoRGKPH1LWsrhdr1t0lOkLWUKsuGN2VzSKAa80Es7oHPzzW 1td/JtKncIN0/B3WlMvtc4R1MxlF3h67/IU4lck= X-Google-Smtp-Source: APXvYqw85h/AiA9x/md4MH8d1gLiJ3/XCdNHfXPFynndzSnYsL39vGzgiysgRO1V2zGDNk9lncLfMfmJz16C1/97q9w= X-Received: by 2002:a67:3355:: with SMTP id z82mr19549400vsz.169.1570543473198; Tue, 08 Oct 2019 07:04:33 -0700 (PDT) MIME-Version: 1.0 References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8055839.FEiR5CbC9I@pintsize.usersys.redhat.com> <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com> In-Reply-To: <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com> From: Daniel Migault Date: Tue, 8 Oct 2019 10:04:18 -0400 Message-ID: To: Hubert Kario Cc: tls Content-Type: multipart/alternative; boundary="000000000000d30a36059466a542" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 14:04:37 -0000 --000000000000d30a36059466a542 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If we suppose all tickets are sent by the server at once, I am wondering if we have any case where the server will send more tickets that the number provided by the hint. Yours, Daniel On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario wrote: > On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote: > > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > > > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario > wrote: > > > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > > > I understand the meaning of count is the higher limit of ticket > and > > > > > > the > > > > > > server can provides any tickets between 0 and count. If that is > > > > > > correct, > > > > > > this could be clearly stated and indication to chose an > appropriated > > > > > > > > > > value > > > > > > > > > > > for each cases may be provided. > > > > > > > > > > > > I would rather see the count value as a hard line from the serv= er > > > > > > with a > > > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > > > > > > see my previous comments: this ignores existence of post handshak= e > > > > > authentication, ticket lifetimes and KeyUpdate > > > > > > > > I think we agree on the problem which is it is hard to have a > specific > > > > count as tickets may be sent at multiple time during the key > exchange or > > > > the later during the session. If the "SHOULD" is addressing this > aspect > > > > I > > > > believe that more text is needed.. From my perspective, what I > proposed > > > > I > > > > imagined that count was related to the maximum number of ticket > provided > > > > **each time the server is sending tickets**. The reason for having > the > > > > same > > > > number is that the server does not know how the client will use the= se > > > > tickets and the client does not know precisely when the server send= s > the > > > > tickets. So at the end the number of tickets sent is likely to be > > > > n*count > > > > when n represents the number of times during the session tickets ar= e > > > > provided. > > > > > > > > My understanding of the SHOULD is that it makes legitimate for a > server > > > > to > > > > ignore the count value provided by the client. > > > > > > yes, it looks like we are in agreement > > > > > > Sounds like something that should be spelled out explicitly in the > draft. > > > I.e. it should talk about groups of tickets, not tickets in connectio= n, > > > and it should definitely not specify the maximum number of tickets a > > > server can send in a connection. > > > > Since it's meant as a hint, removing that clause (maximum number of > tickets > > a server can send in a connection) is reasonable, and sounds like it > should > > address the concerns here. (Assuming we also include text which says > > servers should obviously place a cap on what they send, as they do > today.) > > Would you agree? I'm really trying to avoid this becoming overly comple= x, > > as it's a very small feature. > > yes, having a "server SHOULD place a cap on the number of tickets it send= s > at > once" with a note in security section that "not having such a limit may > expose > the server to DoS or amplification attacks" would be enough > > (note that without client certificate authentication, the server can use > early > exit from handshake method and thus send the extensions just as a result > of a > single ClientHello message) > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d30a36059466a542 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we suppose all tickets are sent by the server at once, = I am wondering if we have any case where the server will send more tickets = that the number provided by the hint.=C2=A0

Yours,=C2=A0=
Daniel

On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario <hkario@redhat.com> wrote:
On Saturday, 5 October 2019 14:= 08:45 CEST Christopher Wood wrote:
> On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote:
> > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <hkario@redhat.com> wrote:=
> > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migau= lt wrote:
> > > > > I understand the meaning of count is the higher li= mit of ticket and
> > > > > the
> > > > > server can provides any tickets between 0 and coun= t. If that is
> > > > > correct,
> > > > > this could be clearly stated and indication to cho= se an appropriated
> > > >
> > > > value
> > > >
> > > > > for each cases may be provided.
> > > > >
> > > > > I would rather see the count value as a hard line = from the server
> > > > > with a
> > > > > MUST NOT instead of a SHOULD NOT statement.
> > > >
> > > > see my previous comments: this ignores existence of pos= t handshake
> > > > authentication, ticket lifetimes and KeyUpdate
> > >
> > > I think we agree on the problem which is it is hard to have = a specific
> > > count as tickets may be sent at multiple time during the key= exchange or
> > > the later during the session. If the "SHOULD" is a= ddressing this aspect
> > > I
> > > believe that more text is needed.. From my perspective, what= I proposed
> > > I
> > > imagined that count was related to the maximum number of tic= ket provided
> > > **each time the server is sending tickets**. The reason for = having the
> > > same
> > > number is that the server does not know how the client will = use these
> > > tickets and the client does not know precisely when the serv= er sends the
> > > tickets. So at the end the number of tickets sent is likely = to be
> > > n*count
> > > when n represents the number of times during the session tic= kets are
> > > provided.
> > >
> > > My understanding of the SHOULD is that it makes legitimate f= or a server
> > > to
> > > ignore the count value provided by the client.
> >
> > yes, it looks like we are in agreement
> >
> > Sounds like something that should be spelled out explicitly in th= e draft.
> > I.e. it should talk about groups of tickets, not tickets in conne= ction,
> > and it should definitely not specify the maximum number of ticket= s a
> > server can send in a connection.
>
> Since it's meant as a hint, removing that clause (maximum number o= f tickets
> a server can send in a connection) is reasonable, and sounds like it s= hould
> address the concerns here. (Assuming we also include text which says > servers should obviously place a cap on what they send, as they do tod= ay.)
> Would you agree? I'm really trying to avoid this becoming overly c= omplex,
> as it's a very small feature.

yes, having a "server SHOULD place a cap on the number of tickets it s= ends at
once" with a note in security section that "not having such a lim= it may expose
the server to DoS or amplification attacks" would be enough

(note that without client certificate authentication, the server can use ea= rly
exit from handshake method and thus send the extensions just as a result of= a
single ClientHello message)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d30a36059466a542-- From nobody Tue Oct 8 07:28:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770512084D for ; Tue, 8 Oct 2019 07:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XU-H1VLR6BGl for ; Tue, 8 Oct 2019 07:28:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B650120843 for ; Tue, 8 Oct 2019 07:28:14 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A769310CC205; Tue, 8 Oct 2019 14:28:13 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 028305DE5C; Tue, 8 Oct 2019 14:28:12 +0000 (UTC) From: Hubert Kario To: Daniel Migault Cc: tls Date: Tue, 08 Oct 2019 16:28:12 +0200 Message-ID: <15867803.7oPl4jV29m@pintsize.usersys.redhat.com> In-Reply-To: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <7141986.K9k3K6lWjT@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3900847.uKFYVagsbe"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.65]); Tue, 08 Oct 2019 14:28:13 +0000 (UTC) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 14:28:18 -0000 --nextPart3900847.uKFYVagsbe Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 8 October 2019 16:04:18 CEST Daniel Migault wrote: > If we suppose all tickets are sent by the server at once, I am wondering = if > we have any case where the server will send more tickets that the number > provided by the hint. long lasting connection and a ticket encryption key expiring =20 > Yours, > Daniel >=20 > On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario wrote: > > On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote: > > > On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote: > > > > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > > > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario > >=20 > > wrote: > > > > > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote: > > > > > > > I understand the meaning of count is the higher limit of tick= et > >=20 > > and > >=20 > > > > > > > the > > > > > > > server can provides any tickets between 0 and count. If that = is > > > > > > > correct, > > > > > > > this could be clearly stated and indication to chose an > >=20 > > appropriated > >=20 > > > > > > value > > > > > >=20 > > > > > > > for each cases may be provided. > > > > > > >=20 > > > > > > > I would rather see the count value as a hard line from the > > > > > > > server > > > > > > > with a > > > > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > >=20 > > > > > > see my previous comments: this ignores existence of post handsh= ake > > > > > > authentication, ticket lifetimes and KeyUpdate > > > > >=20 > > > > > I think we agree on the problem which is it is hard to have a > >=20 > > specific > >=20 > > > > > count as tickets may be sent at multiple time during the key > >=20 > > exchange or > >=20 > > > > > the later during the session. If the "SHOULD" is addressing this > >=20 > > aspect > >=20 > > > > > I > > > > > believe that more text is needed.. From my perspective, what I > >=20 > > proposed > >=20 > > > > > I > > > > > imagined that count was related to the maximum number of ticket > >=20 > > provided > >=20 > > > > > **each time the server is sending tickets**. The reason for having > >=20 > > the > >=20 > > > > > same > > > > > number is that the server does not know how the client will use > > > > > these > > > > > tickets and the client does not know precisely when the server se= nds > >=20 > > the > >=20 > > > > > tickets. So at the end the number of tickets sent is likely to be > > > > > n*count > > > > > when n represents the number of times during the session tickets = are > > > > > provided. > > > > >=20 > > > > > My understanding of the SHOULD is that it makes legitimate for a > >=20 > > server > >=20 > > > > > to > > > > > ignore the count value provided by the client. > > > >=20 > > > > yes, it looks like we are in agreement > > > >=20 > > > > Sounds like something that should be spelled out explicitly in the > >=20 > > draft. > >=20 > > > > I.e. it should talk about groups of tickets, not tickets in > > > > connection, > > > > and it should definitely not specify the maximum number of tickets a > > > > server can send in a connection. > > >=20 > > > Since it's meant as a hint, removing that clause (maximum number of > >=20 > > tickets > >=20 > > > a server can send in a connection) is reasonable, and sounds like it > >=20 > > should > >=20 > > > address the concerns here. (Assuming we also include text which says > > > servers should obviously place a cap on what they send, as they do > >=20 > > today.) > >=20 > > > Would you agree? I'm really trying to avoid this becoming overly > > > complex, > > > as it's a very small feature. > >=20 > > yes, having a "server SHOULD place a cap on the number of tickets it se= nds > > at > > once" with a note in security section that "not having such a limit may > > expose > > the server to DoS or amplification attacks" would be enough > >=20 > > (note that without client certificate authentication, the server can use > > early > > exit from handshake method and thus send the extensions just as a result > > of a > > single ClientHello message) > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > > Republic_______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3900847.uKFYVagsbe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2cnPwACgkQkqjRuAHS 9fVYvRAAlU2LalC3IEdXuLOfCyIjWPOByTZkPlP8KRWERJEkjB5w8/EHlXFHh4qT apj6bFAbft9g3xe2OGoPtmtDiLyd5G6BYrAQ/wXZdMDCijtw6WRnjAbTI3P6Upvz qsyB2s0I+MqVVucCgZ27c/QKtTtDwsybpLfcVvfhmB0yMGZEpzot2jO9CP4JcbA6 r4YeiQ+dpmu9sTiQkXnx24j2DWcYAAGxMFZ9OCSeHgtwbS6jxOfRIduKlUfiE3vk NoyNLr2gdmQYz9WdZpFgYaibrTAyhV7QEZvZxOBykGp4L8h2PTNDMvmC5ARHopMQ 7PfZeUpOa9XGfAxGbqdsYjtksm03kXy0RcxRC/VtgQEJVvWKwpMFyKBBN2kOvjIf obljJmmpxlJ0s6/hnPVEvYUJYM+scPRPCkLuA3OxgN6BCVsRydMq6tTl6BP9BKmC OqzSNS6lVbZpL9t5SLVW0ZG0ivVgThX8+jKJmcop/B7HtdsQuLlmC5jgawP86ixh eDzHqJBz+Vakz2h/Fbpp5nr3zb+rn3gR9aXRi1+SukIljb4eY//r6mcxafUQ/6ev BQQTCfsFS9EDtxeIC7DDx0E6f/RxGNiihOlHa/I+QSqSpQbuysabf6jzs28mh8Q8 oWRFa99UfXdIh22wvnlUpVYo3cq4/EXKijBxKSJg39DaJuV625A= =iAZy -----END PGP SIGNATURE----- --nextPart3900847.uKFYVagsbe-- From nobody Tue Oct 8 09:46:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0942120058 for ; Tue, 8 Oct 2019 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=XPgLiESh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XGgudQvx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czJVr6nLAM-0 for ; Tue, 8 Oct 2019 09:46:48 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759A312004C for ; Tue, 8 Oct 2019 09:46:48 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CC6372F1; Tue, 8 Oct 2019 12:46:47 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 08 Oct 2019 12:46:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=Rty6P BrgtPmrA2DELo6rym6dW+VdVopAzByX5kKHYLE=; b=XPgLiEShBrr3c/N/GDryD q0P/okK/2a5/7/F0aagiS+LvF++Nmlk8kCyjnvSXV1IqxtdUw9FeAvk9KMq2SEC9 40ouWKuyTxbkSaNGsWFUlfixxrIS+qVLwXrFTYxYzV3UrxGYbnWeSsyDN75KAf2L LDMXFkjnDUcagrGHN7XczFHnB/17YV7Vgl19HDf3zhgHv/mYO2ScvEvJAGUyRpKL IXleFGx8CnvX8peVG04UubRJrOelQZeSJ4AMvUCeFnb9zEZBcRaXmze8F6zd2cmR rrtYjcHc7z+kMpzAOAPA/7fOuI+i5khNMThbAwny8afUWvoBoQywTHE4G0ctHvl1 Q== 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=fm1; bh=Rty6PBrgtPmrA2DELo6rym6dW+VdVopAzByX5kKHY LE=; b=XGgudQvx2h0GBJCiTeaPU5ySh8BLgQqcBvO49pCfYZyI/BT+XfmBReQwj y4vZsZEKMWAqrkN0PNB0V0y/yEPPOW2O+3D9R2tPmo4jpl/iKCXrgI7y1gn4ocmt vGIMi0fmTdx80f5A0FfnJTxrV4OBm0zJyXtdNuZTq6uwbfltmER9LfzSKH9HuA7w BY7Xtb3e/eoWKZ60bSVeh43MXac5UG7EjdViKEQ5db2mWpRqH0zPvdML0URfEKG3 y86CU1dxfuE8A+p4pRz4RU0pFU0mS24rynEMwwl71d7KtHBsUKs6ysIvR2p70kEA 0DlAy1j+iAlBhQc5OOa3+DguWufRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrheelgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucffohhmrghinhepsghhrghmrdgrtgdruhhkpdhgihhthhhusgdrtghomhdpihgv thhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsg hithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0EBC03C00A2; Tue, 8 Oct 2019 12:46:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> In-Reply-To: References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> Date: Tue, 08 Oct 2019 09:46:26 -0700 From: "Christopher Wood" To: "Mohit Sethi M" , "TLS@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 16:46:52 -0000 On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote: > =20 > Hi Chris, >=20 > For the benefit of the list, let me summarize that the selfie attack i= s=20 > only relevant where multiple parties share the same PSK and use the=20= > same PSK for outgoing and incoming connections. These situations are=20= > rather rare, but I accept that TLS is widely used (and sometimes=20 > misused) in many places. >=20 > The Selfie attack only happens when an entity with the PSK acts=20 > maliciously. So I think the fact that you write in the draft: "each=20= > node must be trusted not to impersonate another node's role" does not=20= > take into account that there must be a malicious node for the selfie=20= > attack to happen in the first place.=20 >=20 > Drucker and Gueron's paper recommends that "every participating party=20= > gets (during the setup of the network) a unique identity" and "the=20 > client and the server must verify the validity of the claimed=20 > identities.". The reality however is that in most group PSK scenarios,= =20 > the nodes don't have any strong identities that can be verified.=20 >=20 > What you should instead (or additionally) say in the text is that a=20= > node should check that the client_mac and server_mac (or any other=20 > identities used) *are never the same*.=20 This seems implicit in the text as written. Could I ask you to submit a = PR against [1] to clarify? Thanks, Chris [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer > Without this check, the selfie=20 > attack would still be possible. And at least this does not require=20 > strong identity verification for preventing selfie attacks.=20 >=20 > --Mohit >=20 > On 10/5/19 2:41 PM, Christopher Wood wrote: > > Hi Feng, >=20 > For what it's worth, the latest version of the PSK importers draft=20 > includes a "context" field into which identity information can be fed:= >=20 > =20 > https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#ap= pendix-B >=20 > Best, > Chris >=20 > On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote: > >> Hi John, >=20 > Reflection attacks are indeed older, but the selfie attack is a bit=20= > different. It's actually a variant of the unknown key share attack. A=20= > typical example of the UKS attack is the one reported on MQV by Kalisk= i=20 > in 2001 (see "An unknown key-share attack on the MQV key agreement=20 > protocol" in ACM TISSEC 2001). In that example, the adversary plays=20= > message between two users to cause confusion in the identity, but in=20= > Selfie, the adversary plays message with only one user and uses anothe= r=20 > instance of the user to cause confusion in the identity. When we=20 > reported this variant of UKS in [3], we were not aware of anything lik= e=20 > that in the literature. >=20 > Cheers, > Feng >=20 > =EF=BB=BFOn 24/09/2019, 16:17, "John Mattsson" wrote: >=20 > Hi, > =20 > I think these reflection attacks are much older than this. I quick= =20 > search for reflection attack security protocol gives a lot of old=20 > results, The description of reflection attack in the following lecture= =20 > material from 2009 looks just like the "selfie attack" on TLS 1.3 > http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf > =20 > With multiple sections there are other things that change as well.= =20 > If two nodes unintentionally initiate simultaneous ClientHello to each= =20 > other, even if they only want a single secure connection (I have seen=20= > live systems where this happens in practice), an attacker can select=20= > which ClientHello to block (e.g. the one with the strongest=20 > cryptographic parameters). The following security property would then=20= > no longer hold : > =20 > "Downgrade protection: The cryptographic parameters should be t= he > same on both sides and should be the same as if the peers ha= d been > communicating in the absence of an attack" > =20 > (I have not looked at what the definitions in [BBFGKZ16] say). > =20 > Cheers, > John > =20 > -----Original Message----- > From: TLS on behalf of "Hao, Feng"=20 > >> > Date: Tuesday, 24 September 2019 at 16:09 > To: Mohit Sethi M ,= =20 > "Owen Friel (ofriel)" , Jonathan Hoyland=20 > >> > Cc: "TLS@ietf.org" > Subject: Re: [TLS] Selfie attack was Re: Distinguishing between=20= > external/resumption PSKs > =20 > =20 > On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M"=20 > >> mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org>=20 > wrote: > =20 > Hi all, > =20 > On the topic of external PSKs in TLS 1.3, I found a=20 > publication on the=20 > Selfie attack:=20 > >> https://protect2.fireeye.com/url?k=3Ddd432f13-81c9e5ad-dd436f88-869= a17b5b21b-dc6c6f0a5dd21faf&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F201= 9%2F347 > =20 > Perhaps this was already discussed on the list. I thought=20= > that sharing=20 > it again wouldn't hurt while we discuss how servers=20 > distinguish between=20 > external and resumption PSKs. > =20 > I just read the paper with interest. It occurs to me that the=20= > selfie attack is consistent with the "impersonation attack" that we=20= > reported on SPEKE in 2014; see Sec 4.1 [1] and the updated version wit= h=20 > details on how SPEKE is revised in ISO/IEC 11770-4 [2]. The same attac= k=20 > can be traced back to 2010 in [3] where a "worm-hole attack" (Fig. 5,=20= > [3]) is reported on the self-communication mode of HMQV. The essence o= f=20 > these attacks is the same: Bob tricks Alice into thinking that she is=20= > talking to authenticated Bob, but she is actually talking to herself.=20= > In [3], we explained that the attack was missed from the "security=20 > proofs" as the proofs didn't consider multiple sessions.=20 > =20 > The countermeasure we proposed in [1-3] was to ensure the user= =20 > identity is unique in key exchange processes: in case of multiple=20 > sessions that may cause confusion in the user identity, an extension=20= > should be added to the user identity to distinguish the instances. The= =20 > underlying intuition is that one should know "unambiguously" whom they= =20 > are communicating with, and perform authentication based on that. The=20= > discovery of this type of attacks and the proposed solution are=20 > inspired by the "explicitness principle" (Ross Anderson and Roger=20 > Needham, Crypto'95), which states the importance of being explicit on=20= > user identities and other attributes in a public key protocol; also se= e=20 > [3]. I hope it might be useful to people who work on TLS PSK. > =20 > [1]=20 > >> https://protect2.fireeye.com/url?k=3D5a822513-0608efad-5a826588-869= a17b5b21b-eb260151f78b0718&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F201= 4%2F585.pdf > [2] https://arxiv.org/abs/1802.04900 > [3]=20 > >> https://protect2.fireeye.com/url?k=3Dd5bf88ff-89354241-d5bfc864-869= a17b5b21b-0e9b3bf58e104f32&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F201= 0%2F136.pdf=20 > =20 > =20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > =20 > =20 > =20 >=20 > _______________________________________________ > 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 Tue Oct 8 11:19:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA44120071 for ; Tue, 8 Oct 2019 11:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 Lrr1LMYoa2lf for ; Tue, 8 Oct 2019 11:19:09 -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 7CD4F120058 for ; Tue, 8 Oct 2019 11:19:09 -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 x98I1sNS025799; Tue, 8 Oct 2019 19:19:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=w0tzomPF4tXxd60Sj6dY9LM8v1Be0kFXdV1O5swvpZg=; b=j3VUn5V+/4qBH+4RLHhybnujbsExMvuvyeJO915CJvo9K1O7GICIAXuxPN7xNFC9UNPr ltQ7Tcaxf+g8GGFAJpXNn8spNu37Ra2vgxcgYkn6V9vNxxhN6+Y4KoiyCMtgga18xBjN pw/xQ8W4aw/KoMXWsg8bLDicsMTFxKKJKY0Yg6zak+TEOcGsogBlIoPAoqLGI153YCqn PUf/AeWYRt8CpUCG4x2P1Sb4v3JN+0/6mfmmOVZoLkZ7MuxNDfPwlrEUJWEIZ2lN9Ybm P1E+ymLYFru0tJXeynMXQQz19LetlmNS+lRmoDN+pFXepRAXLQ2avKeObNjRaZ59XQpT +A== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vekk8rbr2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Oct 2019 19:19:04 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x98I2ZtL017985; Tue, 8 Oct 2019 14:19:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint7.akamai.com with ESMTP id 2veph067jm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 08 Oct 2019 14:19:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 8 Oct 2019 14:18:55 -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.1473.005; Tue, 8 Oct 2019 14:18:55 -0400 From: "Salz, Rich" To: Rob Sayre , "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0A Date: Tue, 8 Oct 2019 18:18:54 +0000 Message-ID: <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.79] Content-Type: multipart/alternative; boundary="_000_28C7A74D5F9D4E1AA2D2155417DA51C0akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-08_07:, , 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=971 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910080143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-08_07:2019-10-08,2019-10-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1011 mlxscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 spamscore=0 suspectscore=0 phishscore=0 mlxlogscore=956 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910080143 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2019 18:19:11 -0000 --_000_28C7A74D5F9D4E1AA2D2155417DA51C0akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgT25lIGlzc3VlIG5vdCBjb3ZlcmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgU05JIGVuY3J5 cHRpb24gZnJvbSBDRE5zIHRvIE9yaWdpbiBzZXJ2ZXJzLg0KDQpJIHRoaW5rIGRlbGliZXJhdGVs eSBzby4gIFVzZXItYWdlbnQgdG8gb3JpZ2luICh3aGVyZSBzb21ldGltZXMgdGhlIG9yaWdpbiBp cyBhIENETiBvciBvdGhlciBpbnRlcm1lZGlhcnkpIGlzIHRoZSBtYWluIGNhc2UuDQoNCkFrYW1h aSwgZm9yIGV4YW1wbGUsIGlzIG5vdCBwbGFubmluZyBvbiBkb2luZyBFU05JIHRvIGN1c3RvbWVy IHNvIGZhci4NCg== --_000_28C7A74D5F9D4E1AA2D2155417DA51C0akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <054F7479FE282046AE44D260329D7C9A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMDU3MTcxMTE0Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTk2MDAwOTg5MCAxOTk4NjI5NzQ0 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYW5zaS1m b250LXdlaWdodDpib2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4t dG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPk9uZSBpc3N1ZSBub3Qg Y292ZXJlZCBpbiB0aGlzIGRvY3VtZW50IGlzIFNOSSBlbmNyeXB0aW9uIGZyb20gQ0ROcyB0byBP cmlnaW4gc2VydmVycy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgZGVsaWJlcmF0ZWx5IHNvLiZuYnNwOyBVc2VyLWFnZW50IHRvIG9yaWdpbiAod2hlcmUgc29t ZXRpbWVzIHRoZSBvcmlnaW4gaXMgYSBDRE4gb3Igb3RoZXIgaW50ZXJtZWRpYXJ5KSBpcyB0aGUg bWFpbiBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ba2FtYWks IGZvciBleGFtcGxlLCBpcyBub3QgcGxhbm5pbmcgb24gZG9pbmcgRVNOSSB0byBjdXN0b21lciBz byBmYXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_28C7A74D5F9D4E1AA2D2155417DA51C0akamaicom_-- From nobody Tue Oct 8 11:51:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD51200B9 for ; Tue, 8 Oct 2019 11:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 wEmsc1uIMzcF for ; Tue, 8 Oct 2019 11:51:06 -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 517A3120071 for ; Tue, 8 Oct 2019 11:51:06 -0700 (PDT) Received: from xse312.mail2web.com ([66.113.197.58] helo=xse.mail2web.com) by mx62.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iHuZb-0004fW-GE for tls@ietf.org; Tue, 08 Oct 2019 20:51:04 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46nmdd6vR4z2rGr for ; Tue, 8 Oct 2019 11:51:01 -0700 (PDT) Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iHuZZ-0000o8-Rr for tls@ietf.org; Tue, 08 Oct 2019 11:51:01 -0700 Received: (qmail 23501 invoked from network); 8 Oct 2019 18:51:01 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Oct 2019 18:51:01 -0000 To: Christopher Wood , Mohit Sethi M , "TLS@ietf.org" References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 8 Oct 2019 11:51:00 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> Content-Type: multipart/alternative; boundary="------------277421B694DE4DA25B58DAC5" Content-Language: en-US X-Originating-IP: 66.113.197.58 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.56) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhV4+gv3aA3n6mh SCKkTiS/oETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4ZzTxFC3+A7GtrWRSDXTLnmgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+e8hb1lxHddBtWcfnl7xl+wmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdGd9U9Oojh2QY0MMPWjRsTVhMmX9VvKuj6psZloQqgYBwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPmz5tsQu9R3vp aAMkTA7gTKoJngF7rJQgeWTjF5V/EGvRE/OZn1eaM2+HO7U9rBRulBO8u0ag4+i9kLOW9cRnakdu 2lX9U0U/jnlrPw5p8im8gM5yDzctcfgaSyAJ9MhDntZcYflIMbaTJGx1xg/L1K0TsbHEjYgdNBiy P9ZBJKhKJwCelAgxI3HE4I5TUXrjZhJMfwB51UnuCmvd5x2m+/FyaTa45tBCkCGfE3N3Ud/JZuM7 jUXIESohoO51xWmU8ZNfCyuJJ0v8KnjP4iInSCXF9RIyzE5v2PXonJNwz+hs86LodOZj79xdSjzK bqR5XHk0qi1hkw/hDGKWkPVYlXF3BhZxGgZFOwvGprxNGaa6/2rAztFeklLxGNN3KHaPkMjB65Ki hPq1I9TXHnOlSkg/OIORZDl9o+TmclcfPTQwNGP0PwcsocAqk8Y/wQ+e4HndwcgUdq9CmjcVQOst ghA= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 18:51:08 -0000 This is a multi-part message in MIME format. --------------277421B694DE4DA25B58DAC5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 10/8/2019 9:46 AM, Christopher Wood wrote: > On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote: >> >> Hi Chris, >> >> For the benefit of the list, let me summarize that the selfie attack is >> only relevant where multiple parties share the same PSK and use the >> same PSK for outgoing and incoming connections. These situations are >> rather rare, but I accept that TLS is widely used (and sometimes >> misused) in many places. I may be getting old but the way Mohit writes it, it seems that the attack happens when the security of a group relies on a secret shared by all members of the group, and can then be compromised when one of the group members misbehaves. How is that a new threat? If groups are defined by a shared secret, then corruption of a group member reveals that shared secret to the attacker and open the path for all kinds of exploitation. In what sense is the "selfie" attack different from that generic threat? -- Christian Huitema --------------277421B694DE4DA25B58DAC5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

On 10/8/2019 9:46 AM, Christopher Wood wrote:

On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote:

 
Hi Chris,

For the benefit of the list, let me summarize that the selfie attack is 
only relevant where multiple parties share the same PSK and use the 
same PSK for outgoing and incoming connections. These situations are 
rather rare, but I accept that TLS is widely used (and sometimes 
misused) in many places.


I may be getting old but the way Mohit writes it, it seems that the attack happens when the security of a group relies on a secret shared by all members of the group, and can then be compromised when one of the group members misbehaves. How is that a new threat? If groups are defined by a shared secret, then corruption of a group member reveals that shared secret to the attacker and open the path for all kinds of exploitation. In what sense is the "selfie" attack different from that generic threat?

-- Christian Huitema

--------------277421B694DE4DA25B58DAC5-- From nobody Tue Oct 8 12:08:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45D61200BA for ; Tue, 8 Oct 2019 12:07:59 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QruJm8FlP_xx for ; Tue, 8 Oct 2019 12:07:57 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.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 3EE21120071 for ; Tue, 8 Oct 2019 12:07:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BKJBeT+F+Q7at9aoIpTJ3WBYeC7yqeq2O/nfZ5apiyn1iyl6228hFmCejy4HQtD5r/LLU1zH7knwCAXjNBJyeb0SgJUkmcAQb4HO5IqR9ixQuwGiGHQRZsaX4BKRTkdS+Qyza4OdlaCnUPBH8OQYdokExDeSdebElyI+FhMLxH5FitNibegaORdS74/ZefljAAcXVX9Q0tqcQ4+JSe7G9vzQRkKYMPwWBDX9ISZ6mJtehu3FgByN0A8anoOOeT8VbBfciCvZXgYxazyr9n2j5mmn6tgbJanyySOvAZNTC+vDrSLhtkrk7lnyaSiJFZT3DScAj+G0/6M8BSrG/x8HVQ== 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=O03rEziaqDLbAlR0b3gLKmGgBLgfHT4eql1ExdO8o/0=; b=AJ0YLcHvtEQFEdpRGe/7KoAZ3SKPbLbve1kRLwiuZ4DXoa+7qnxQqxz5YK8VPPX9D2rjU2r1+ol0oQemPqU4G7S2opTTOt2tD1hDfdEPKCpbodVR8U4foxojwcDCj/ewOT6c1sqYeGl0GSSTt9kHtQbbffcgrcrY+whUzgAOA0DBphBH2PKpgQUV0kngJMoLpqAdfo83yO57xn2TyDpawtRS5RhQutzy9HRnPhbrumZtDr6bzniPFXMH575/0E2c60CkW1Qp2S5Q8p+Q2XXKpd8GRJwkToQLGAPQ9aJo4d/su6i+tZm/SlwGEIoHe4jB6aMk1/6dmvwKt0R21MfT5A== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O03rEziaqDLbAlR0b3gLKmGgBLgfHT4eql1ExdO8o/0=; b=mjY4PlJvJJBAfde+e9ob67RcOrHoB4hTekzZBG4dcTrgpbvCFeNSAAMMMHc8Is9jEbY6cuf50kF+R6TnIbrp8jMXeYUZOgNV0j6uz400bNY5OF8jQAYFY3BbAvWJ9LLgdBvE4LGaCciIEBsVfIS+/BMmej+DF1tMBXDnE38d2+E= Received: from DB6PR0701MB2904.eurprd07.prod.outlook.com (10.168.84.145) by DB6PR0701MB2837.eurprd07.prod.outlook.com (10.168.83.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Tue, 8 Oct 2019 19:07:55 +0000 Received: from DB6PR0701MB2904.eurprd07.prod.outlook.com ([fe80::44f6:c300:7e19:6d75]) by DB6PR0701MB2904.eurprd07.prod.outlook.com ([fe80::44f6:c300:7e19:6d75%11]) with mapi id 15.20.2347.015; Tue, 8 Oct 2019 19:07:55 +0000 From: Mohit Sethi M To: Christian Huitema , Christopher Wood , Mohit Sethi M , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb6JZ9ydCGu6h0WNgLEAne6JU6dQ9FwAgAAizgCAAAS3gA== Date: Tue, 8 Oct 2019 19:07:55 +0000 Message-ID: <28313e8d-48d1-723e-9548-1e9fb3718491@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> In-Reply-To: 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:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [2001:14bb:140:26ac:193b:4683:69c6:f65d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c9d9a21-a1e6-4934-2754-08d74c22d322 x-ms-traffictypediagnostic: DB6PR0701MB2837:|DB6PR0701MB2837: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2958; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(366004)(189003)(199004)(11346002)(2501003)(6506007)(53546011)(102836004)(446003)(8676002)(81166006)(186003)(81156014)(46003)(25786009)(76176011)(99286004)(606006)(316002)(8936002)(58126008)(14444005)(6116002)(256004)(71200400001)(71190400001)(2906002)(236005)(6512007)(6436002)(6306002)(54896002)(6486002)(478600001)(6246003)(2616005)(110136005)(66946007)(66476007)(66556008)(14454004)(7736002)(966005)(36756003)(65956001)(229853002)(65806001)(5660300002)(31686004)(86362001)(486006)(66446008)(476003)(76116006)(31696002)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0701MB2837; H:DB6PR0701MB2904.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WfNHcww65bh+OJm4O/TaiyFxMYWGr/qEJuMjR+Q34u4dxgILnGI8LyvFSHjwp97nUnAqYqqZN6ToqmrqttddmDN9nSABiPI3XLdcjQe/K4vEyt9OHLD+kp9zMQ9iWOS1ZxeaU1jbO/xzjoLGRvjjR1a/u/AJzErTh4SctTD/TrzrB91pEb8A6jmam8M+b/qAZItE6baoAb962+fwihDn3mMAY63eLRKDG+bRApabOpbNdYWnRWvrb7iH5eJnpPq/H3CnLsKDzkHZWs+D9iB0Lbpp4OnHDPCSe0CmIFJVBaRZK7HtopcFnIO4y8ZUHS4IQM6rP+CQ2Xut/wnHyyuDsOxRsl9dffj+Xsp8HYA44fmQSV9lKE6/M232NDqFCFPuR71BhF+5VFrg4Ic4BHSAMDtbhjQC4Yd7GBs5WehuLuOVnxNfP2yJXOaYGBuCVBdkp8XC3uHw9D1o6NePMhyuxg== Content-Type: multipart/alternative; boundary="_000_28313e8d48d1723e95481e9fb3718491ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c9d9a21-a1e6-4934-2754-08d74c22d322 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2019 19:07:55.0324 (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: 1cIxm2Ma3oYuJUj7blOP0N68rXYTV9u8BGJsJgGoQmKKZhflkzePEfzacQfFPl4sTqXs1k9dhhd9vVnyk4XHmoN3o6sA2+KXcISnr5Q/xnk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2837 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 19:08:00 -0000 --_000_28313e8d48d1723e95481e9fb3718491ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hyaXN0aWFuLA0KDQpJdCB3YXMgbXkgcG9vciBhdHRlbXB0IGF0IGV4cGxhaW5pbmcgdGhl IGF0dGFjay4gVGhlIGF0dGFjayBjYW4gaGFwcGVuIGFzIGxvbmcgYXMgYSBub2RlIHNlbmRzIG91 dGJvdW5kIGNvbm5lY3Rpb25zIChhcyBhIFRMUyBjbGllbnQpIGFuZCBhY2NlcHRzIGluYm91bmQg Y29ubmVjdGlvbnMgKGFzIGEgVExTIHNlcnZlcikgd2l0aCB0aGUgc2FtZSBleHRlcm5hbCBQU0sg YW5kIGlkZW50aXR5LiBUaGlzIGlzIGxpa2VseSB0byBoYXBwZW4gaW4gc29tZSBmb3JtIG9mIGdy b3VwIGNvbW11bmljYXRpb24gYnV0IG5vdCBuZWNlc3NhcmlseS4NCg0KSW4gc3VjaCBhIHNjZW5h cmlvLCBhIG1hbGljaW91cyBub2RlIEV2ZSBjYW4gZm9vbCBBbGljZSB0byBvcGVuIGEgY29ubmVj dGlvbiB0byBoZXJzZWxmIChoZW5jZSB0aGUgbmFtZSBTZWxmaWUpLg0KDQpBZG1pdHRlZGx5LCBV S1MvbWlzYmluZGluZy9zZWxmaWUgYXJlIHNvbWV3aGF0IGhhcmQgdG8gY29tcHJlaGVuZCBzb21l dGltZXMgKGF0IGxlYXN0IGZvciBtZSkuDQoNCi0tTW9oaXQNCg0KT24gMTAvOC8xOSA5OjUxIFBN LCBDaHJpc3RpYW4gSHVpdGVtYSB3cm90ZToNCg0KT24gMTAvOC8yMDE5IDk6NDYgQU0sIENocmlz dG9waGVyIFdvb2Qgd3JvdGU6DQoNCk9uIFR1ZSwgT2N0IDgsIDIwMTksIGF0IDI6NTUgQU0sIE1v aGl0IFNldGhpIE0gd3JvdGU6DQoNCg0KDQpIaSBDaHJpcywNCg0KRm9yIHRoZSBiZW5lZml0IG9m IHRoZSBsaXN0LCBsZXQgbWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMNCm9u bHkgcmVsZXZhbnQgd2hlcmUgbXVsdGlwbGUgcGFydGllcyBzaGFyZSB0aGUgc2FtZSBQU0sgYW5k IHVzZSB0aGUNCnNhbWUgUFNLIGZvciBvdXRnb2luZyBhbmQgaW5jb21pbmcgY29ubmVjdGlvbnMu IFRoZXNlIHNpdHVhdGlvbnMgYXJlDQpyYXRoZXIgcmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExT IGlzIHdpZGVseSB1c2VkIChhbmQgc29tZXRpbWVzDQptaXN1c2VkKSBpbiBtYW55IHBsYWNlcy4N Cg0KDQpJIG1heSBiZSBnZXR0aW5nIG9sZCBidXQgdGhlIHdheSBNb2hpdCB3cml0ZXMgaXQsIGl0 IHNlZW1zIHRoYXQgdGhlIGF0dGFjayBoYXBwZW5zIHdoZW4gdGhlIHNlY3VyaXR5IG9mIGEgZ3Jv dXAgcmVsaWVzIG9uIGEgc2VjcmV0IHNoYXJlZCBieSBhbGwgbWVtYmVycyBvZiB0aGUgZ3JvdXAs IGFuZCBjYW4gdGhlbiBiZSBjb21wcm9taXNlZCB3aGVuIG9uZSBvZiB0aGUgZ3JvdXAgbWVtYmVy cyBtaXNiZWhhdmVzLiBIb3cgaXMgdGhhdCBhIG5ldyB0aHJlYXQ/IElmIGdyb3VwcyBhcmUgZGVm aW5lZCBieSBhIHNoYXJlZCBzZWNyZXQsIHRoZW4gY29ycnVwdGlvbiBvZiBhIGdyb3VwIG1lbWJl ciByZXZlYWxzIHRoYXQgc2hhcmVkIHNlY3JldCB0byB0aGUgYXR0YWNrZXIgYW5kIG9wZW4gdGhl IHBhdGggZm9yIGFsbCBraW5kcyBvZiBleHBsb2l0YXRpb24uIEluIHdoYXQgc2Vuc2UgaXMgdGhl ICJzZWxmaWUiIGF0dGFjayBkaWZmZXJlbnQgZnJvbSB0aGF0IGdlbmVyaWMgdGhyZWF0Pw0KDQot LSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86 VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMN Cg0K --_000_28313e8d48d1723e95481e9fb3718491ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <2B17DB7F5E7A104E9C0652900931D92C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgQ2hyaXN0aWFuLDwvcD4NCjxwPkl0IHdhcyBteSBw b29yIGF0dGVtcHQgYXQgZXhwbGFpbmluZyB0aGUgYXR0YWNrLiBUaGUgYXR0YWNrIGNhbiBoYXBw ZW4gYXMgbG9uZyBhcyBhIG5vZGUgc2VuZHMgb3V0Ym91bmQgY29ubmVjdGlvbnMgKGFzIGEgVExT IGNsaWVudCkgYW5kIGFjY2VwdHMgaW5ib3VuZCBjb25uZWN0aW9ucyAoYXMgYSBUTFMgc2VydmVy KSB3aXRoIHRoZSBzYW1lIGV4dGVybmFsIFBTSyBhbmQgaWRlbnRpdHkuIFRoaXMgaXMgbGlrZWx5 IHRvIGhhcHBlbiBpbiBzb21lDQogZm9ybSBvZiBncm91cCBjb21tdW5pY2F0aW9uIGJ1dCBub3Qg bmVjZXNzYXJpbHkuIDxicj4NCjwvcD4NCjxwPkluIHN1Y2ggYSBzY2VuYXJpbywgYSBtYWxpY2lv dXMgbm9kZSBFdmUgY2FuIGZvb2wgQWxpY2UgdG8gb3BlbiBhIGNvbm5lY3Rpb24gdG8gaGVyc2Vs ZiAoaGVuY2UgdGhlIG5hbWUgU2VsZmllKS48L3A+DQo8cD5BZG1pdHRlZGx5LCBVS1MvbWlzYmlu ZGluZy9zZWxmaWUgYXJlIHNvbWV3aGF0IGhhcmQgdG8gY29tcHJlaGVuZCBzb21ldGltZXMgKGF0 IGxlYXN0IGZvciBtZSkuDQo8YnI+DQo8L3A+DQo8cD4tLU1vaGl0PGJyPg0KPC9wPg0KPGRpdiBj bGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxMC84LzE5IDk6NTEgUE0sIENocmlzdGlhbiBIdWl0 ZW1hIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlk OmE3MGU0MjBjLWVlYWItYjQ0Ni01N2E4LWE0OTZhMDU0MWY4OUBodWl0ZW1hLm5ldCI+DQo8cD5P biAxMC84LzIwMTkgOTo0NiBBTSwgQ2hyaXN0b3BoZXIgV29vZCB3cm90ZTo8YnI+DQo8L3A+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6OTBkZGMxMTYtZjVkOS00YjIyLThiODAt ZTMxODM1ZTA5ZjEwQHd3dy5mYXN0bWFpbC5jb20iPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXBy ZSIgd3JhcD0iIj5PbiBUdWUsIE9jdCA4LCAyMDE5LCBhdCAyOjU1IEFNLCBNb2hpdCBTZXRoaSBN IHdyb3RlOg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBzdHlsZT0iY29sb3I6ICMw MDAwMDA7Ij4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+IA0KSGkgQ2hyaXMs DQoNCkZvciB0aGUgYmVuZWZpdCBvZiB0aGUgbGlzdCwgbGV0IG1lIHN1bW1hcml6ZSB0aGF0IHRo ZSBzZWxmaWUgYXR0YWNrIGlzIA0Kb25seSByZWxldmFudCB3aGVyZSBtdWx0aXBsZSBwYXJ0aWVz IHNoYXJlIHRoZSBzYW1lIFBTSyBhbmQgdXNlIHRoZSANCnNhbWUgUFNLIGZvciBvdXRnb2luZyBh bmQgaW5jb21pbmcgY29ubmVjdGlvbnMuIFRoZXNlIHNpdHVhdGlvbnMgYXJlIA0KcmF0aGVyIHJh cmUsIGJ1dCBJIGFjY2VwdCB0aGF0IFRMUyBpcyB3aWRlbHkgdXNlZCAoYW5kIHNvbWV0aW1lcyAN Cm1pc3VzZWQpIGluIG1hbnkgcGxhY2VzLjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPHA+PGJyPg0KPC9wPg0KPHA+SSBtYXkgYmUgZ2V0dGluZyBvbGQgYnV0IHRoZSB3YXkg TW9oaXQgd3JpdGVzIGl0LCBpdCBzZWVtcyB0aGF0IHRoZSBhdHRhY2sgaGFwcGVucyB3aGVuIHRo ZSBzZWN1cml0eSBvZiBhIGdyb3VwIHJlbGllcyBvbiBhIHNlY3JldCBzaGFyZWQgYnkgYWxsIG1l bWJlcnMgb2YgdGhlIGdyb3VwLCBhbmQgY2FuIHRoZW4gYmUgY29tcHJvbWlzZWQgd2hlbiBvbmUg b2YgdGhlIGdyb3VwIG1lbWJlcnMgbWlzYmVoYXZlcy4gSG93IGlzIHRoYXQgYSBuZXcNCiB0aHJl YXQ/IElmIGdyb3VwcyBhcmUgZGVmaW5lZCBieSBhIHNoYXJlZCBzZWNyZXQsIHRoZW4gY29ycnVw dGlvbiBvZiBhIGdyb3VwIG1lbWJlciByZXZlYWxzIHRoYXQgc2hhcmVkIHNlY3JldCB0byB0aGUg YXR0YWNrZXIgYW5kIG9wZW4gdGhlIHBhdGggZm9yIGFsbCBraW5kcyBvZiBleHBsb2l0YXRpb24u IEluIHdoYXQgc2Vuc2UgaXMgdGhlICZxdW90O3NlbGZpZSZxdW90OyBhdHRhY2sgZGlmZmVyZW50 IGZyb20gdGhhdCBnZW5lcmljIHRocmVhdD88L3A+DQo8cD4tLSBDaHJpc3RpYW4gSHVpdGVtYTxi cj4NCjwvcD4NCjxicj4NCjxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFkZXIiPjwv ZmllbGRzZXQ+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQo8 YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86VExTQGlldGYu b3JnIj5UTFNAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_28313e8d48d1723e95481e9fb3718491ericssoncom_-- From nobody Tue Oct 8 16:48:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D451200D6 for ; Tue, 8 Oct 2019 16:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=Cv27LHmf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U73E06rW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjgWu0ojmmz4 for ; Tue, 8 Oct 2019 16:48:30 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A170120046 for ; Tue, 8 Oct 2019 16:48:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A8EB5738; Tue, 8 Oct 2019 19:48:29 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 08 Oct 2019 19:48:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=pkz5i1O/gsOfE/pt3E/BxVPi47+1xlY fGh9AGz4dbzo=; b=Cv27LHmfRtfGnP/P1l4kCrsus9EKhPEYxl3PvsnUbthijqx SCUWhEk0TsKm+ERUq8FHppxWGz7gj47YIQpiPcqDzo1ymUwIj495xD5JCZku2r6+ yDMZ++tKlmVtudxeVUjY3Jrh5KVazVD7dKvbIZKAkHUhKTjiRCYtJtl3CYYT896o XqobwpEjDZ+btqoLnuQAvqYYTT8HXzNPWdhU8HrqXqdY1O8Tu/b6ZpFTRd2QJXjQ Zmyy4R5muYXI/FwVFI1RO3vsSvwGMgGoHKuGi2JszAsbqY9kpCfRQNVnJLPHHCWa B4oEPFaY1Y3MFQLF6D1Xk8XFk46VrqBwtlPcz7g== 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=fm1; bh=pkz5i1 O/gsOfE/pt3E/BxVPi47+1xlYfGh9AGz4dbzo=; b=U73E06rWpmizx1wpIbyp1U org/ZZ22qVB44dipOkR+j8/GUQxJG8i9XKDuZh0Ah3ftxK7bcwJcSNbUEkwZk1NM Xw9H8jZkQAP2FjsjPKmNoF68s8R+mCdjm8hvepa+HtUqS6lcStWUECxhUIEyeAAF yUWkEACGKVZqzRIqnelF3j4FDTV98FfhS4kz/X9AsJCL759V7FuGsC890Jfcthfp CxF88XztSYD3x6Sq/TBVAtNjmr1Tbs4I2+RApBYNRpzNQmy8MDw+1vWiBVvMeO6w Jh2EEbOY36swJtHqYSb5MKueRJJloW8Rf/d/9MK2JBXSsEnYLi9N9/UEuIp0KyJg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedtgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A19653C00A1; Tue, 8 Oct 2019 19:48:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <3a51cdaa-d04c-48b8-89b9-07d1510dba1a@www.fastmail.com> In-Reply-To: References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> Date: Tue, 08 Oct 2019 16:48:08 -0700 From: "Christopher Wood" To: "Christian Huitema" , "Mohit Sethi M" , "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 08 Oct 2019 23:48:32 -0000 On Tue, Oct 8, 2019, at 11:51 AM, Christian Huitema wrote: > > On 10/8/2019 9:46 AM, Christopher Wood wrote: > > > On Tue, Oct 8, 2019, at 2:55 AM, Mohit Sethi M wrote: > >> > Hi Chris, > > For the benefit of the list, let me summarize that the selfie attack is > only relevant where multiple parties share the same PSK and use the > same PSK for outgoing and incoming connections. These situations are > rather rare, but I accept that TLS is widely used (and sometimes > misused) in many places. > > > I may be getting old but the way Mohit writes it, it seems that the > attack happens when the security of a group relies on a secret shared > by all members of the group, and can then be compromised when one of > the group members misbehaves. How is that a new threat? If groups are > defined by a shared secret, then corruption of a group member reveals > that shared secret to the attacker and open the path for all kinds of > exploitation. In what sense is the "selfie" attack different from that > generic threat? In my opinion, it's not. Best, Chris From nobody Wed Oct 9 00:23:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1764D1200E3 for ; Wed, 9 Oct 2019 00:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nZiCZo1Pgqnw for ; Wed, 9 Oct 2019 00:22:59 -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 489D3120074 for ; Wed, 9 Oct 2019 00:22:59 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id z19so2847335ior.0 for ; Wed, 09 Oct 2019 00:22:59 -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=2waZdYWFheO3F8Me5OOPoErcQbjo60uk3c8vLMFalLI=; b=h6t5EiVolgFNxD1X8BNp5Y7rdMpyGFUe7ShMtKTZE4+dEI6SevlvKcwlAbUNxemwdI AK4XKOl2AQKCVe8W93hA9kHuIw31PxW1JVVUqM6xYCaPcMEbvGWzDZe5Dw/9o5c83+3G kp8F/fHjbfVqd5FEOPJXfJ0x+UdAVi4JbEAukxiHLV9UBaTUbKO+VnzDDQ7T4h5Oby7h lcVieK/8BtaEB4oEAax6yQhalWw4m9/UDIcqGdwbnc6JXvQgo+FSx6ODZ6uItc26YdtD 5BvlNOnmOGLLbkKNSIxmgpTbkhGYFOdJ5LkYF2HuCX3Yfz2rV6Zz3LfD/xQa7Q6nQ1Vi BqIg== 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=2waZdYWFheO3F8Me5OOPoErcQbjo60uk3c8vLMFalLI=; b=UEQxCmerL0NVWZuNjuu/9B/rMs1dEQFTEbenQKp6xoFuDDHrAHfdpv2JqYGeJzDEM9 /671Z29kQgNnXrMKrgfwFrOoAPYNa+VPfhSxaegOdWP4vBmPJNmo1Ps8mLgyCKXZCyFq MS6j/utRhnAYBvD5faqLgmiH6/rX9V3rAT806XzeFzx2qFPlFfea5h0DiAMKTkFNYqyO Ytrdgs2NoR4O5dQnnl0p0HiSf+//lL1Cdj9qEIcjGIFybkL9QDNThoWo+7S1OxALHC7x qeCJ2NGYslMGTWvLscz/UAk8ei/hFxs5jNKMMak3tm6wqFnNORjtu4RYR+qwprPO26tc fDaQ== X-Gm-Message-State: APjAAAV4TlXcPfrbZX+4x1qI6peoEm/tRUhKuwPFJuyRz7gjNSwRH01c JoLMaZNpLUJ5VUgkH8lguBo0LtqJx5p45aMmiKY= X-Google-Smtp-Source: APXvYqyODGgnvEX6UMgAKsZqKmPNid+oU+maGrwmfh1YnQQgemCAiWzgb8E30yJCTyayg6ta+KVoLpsTNeoSyqufLKg= X-Received: by 2002:a92:d987:: with SMTP id r7mr1912982iln.254.1570605778391; Wed, 09 Oct 2019 00:22:58 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> In-Reply-To: <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> From: Rob Sayre Date: Wed, 9 Oct 2019 14:22:46 +0700 Message-ID: To: "Salz, Rich" Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000080da9705947527ae" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 07:23:01 -0000 --00000000000080da9705947527ae Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 1:19 AM Salz, Rich wrote: > > - One issue not covered in this document is SNI encryption from CDNs > to Origin servers. > > > > I think deliberately so. User-agent to origin (where sometimes the origin > is a CDN or other intermediary) is the main case. > Well, TLS is a transport layer protocol. I think my suggestion might apply to any client that's sending a certificate. A link from CDN to Origin is just a particularly easy-to-deploy use case, since client certificates are already in wide use and IPv6 tends to work flawlessly. thanks, Rob --00000000000080da9705947527ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 1:19 AM Salz, Rich= <rsalz@akamai.com> wrote:
  • One issue not covered in this document is SNI encryption from CDNs= to Origin servers.

=C2=A0

I think deliberately so.=C2=A0 User-agent to origin = (where sometimes the origin is a CDN or other intermediary) is the main cas= e.


Well, TLS is a tra= nsport layer protocol. I think my suggestion might apply to any client that= 's sending a certificate.

A link from CDN to O= rigin is just a particularly easy-to-deploy use case, since client certific= ates are already in wide use and IPv6 tends to work flawlessly.
<= br>
thanks,
Rob
--00000000000080da9705947527ae-- From nobody Wed Oct 9 01:34:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B4412008D for ; Wed, 9 Oct 2019 01:34:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vFh1UdIKuwCY for ; Wed, 9 Oct 2019 01:34:51 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70049.outbound.protection.outlook.com [40.107.7.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 D907512000F for ; Wed, 9 Oct 2019 01:34:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gwI6pODhMST5DkiC+Nau0mBoM0yxNYJleCxi4NFIqiv73I7V2lsRapfoQuYpCgvjoWySO+/AWGazWZcu+1vaalUkltKLm9ZoA7WYBAt9kBEzBQLhLuASrgRhIqchx6AyFEVHe/5SER9hxnFUssh/2kR344FZlJ1lfHpjyXUbuDY2mMbA/e7j/wMaDVjvo3JOUTzHOk5MQIMeTcjOZEJVo+mksiXp5z+rKRBGYifo34PhgRQB3mkrJSomLb7tgFy8paowJfmq7+CmiN6M+LRu87eSRRK7IO9RoQqUJoFZOjFK6oTgm8YuBQTBWoflqV3wn+YbfGKW5EoJgWnMXBVhiw== 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=L1DpeJfU4oLMx5jT1XYOucCUd/O4JI/pvomaCY/EJxM=; b=W5yKHlol2qFlM3B64ITl6MJLPZ3nxN/DOBXpYH1h5jWTB6QNPTl7rz+fFbXo9QhOpOyFoYkuGITwkisXkNivk+IZZPbBus3SYKcmmJDfpagLasK6PvhNdpQYR8yEpfGfVJ+KDqJdtrx2KOxbhobelHfPQtZMsaf/3jCEDb46QbP7vh03qcraEYdjHHczL5Bah7n7YNTGHe2lzdUkQROnWO/6dbSm6X9c8WjDe0wjICWhn4oAOMbFAVJYQ0Mjfhq9/MDWDP0kpi6BzwehBWAJEuQEqoKJ2EV1JYL9UASzYpItbNVdqa9F6YFwHglZJXoyyBL9s1qyt7AaEkttiGcFgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=warwick.ac.uk; dmarc=pass action=none header.from=warwick.ac.uk; dkim=pass header.d=warwick.ac.uk; arc=none Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com (20.178.104.28) by DB7PR01MB4154.eurprd01.prod.exchangelabs.com (52.135.133.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.23; Wed, 9 Oct 2019 08:34:48 +0000 Received: from DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::64bb:99b3:3e20:83ea]) by DB7PR01MB5435.eurprd01.prod.exchangelabs.com ([fe80::64bb:99b3:3e20:83ea%7]) with mapi id 15.20.2327.026; Wed, 9 Oct 2019 08:34:48 +0000 From: "Hao, Feng" To: Christopher Wood CC: "tls@ietf.org" Thread-Topic: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs Thread-Index: AQHVe3H9CjIT5rIIxkyi892bPekIVadSEqoA Date: Wed, 9 Oct 2019 08:34:48 +0000 Message-ID: References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Feng.Hao@warwick.ac.uk; x-originating-ip: [217.114.50.58] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d0d6d50a-c2a1-46a0-ce68-08d74c938b93 x-ms-traffictypediagnostic: DB7PR01MB4154: x-ms-exchange-purlcount: 7 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(136003)(346002)(366004)(376002)(199004)(189003)(13464003)(53754006)(51914003)(6246003)(476003)(81166006)(786003)(305945005)(7736002)(6486002)(966005)(58126008)(478600001)(486006)(316002)(86362001)(91956017)(186003)(6306002)(14454004)(81156014)(446003)(8676002)(11346002)(26005)(66066001)(14444005)(6512007)(71200400001)(3846002)(66946007)(66446008)(102836004)(6436002)(2906002)(99286004)(25786009)(4326008)(66476007)(76116006)(53546011)(66556008)(6506007)(64756008)(6916009)(76176011)(229853002)(8936002)(6116002)(256004)(5660300002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR01MB4154; H:DB7PR01MB5435.eurprd01.prod.exchangelabs.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: warwick.ac.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zzuTpQpzlExkTrBJEHVtyWT1GfAgkE8X31PFLctEhQL8SyFfqMBcbyPKKXBd3oguRiPtltmhAYq4QhT3XPVyZbkd0y0PuP6v2tMQA7pXFFoNX8Po/740w9+Glx4eWDSBGPWjQcExqwc+Z8vwYyr2KV3UqabSvxRuQ8U04x2G9YjUax1aqaf4QKASdeVrykkP1Z0TTNbJQy9ZS7Hk/y3gcJ9WvgKXuRNuvzYaSjrHfybV82093U7y/nUz+9At32QxGDNxCXmmpBZbXN62DB3WNKUI8Ovz0Nw/FY+fLaAZI6L5ksr+lkNeq60wI9sPUYllLqDBA48Hv+eM54Zy24EEo6z1UjqzerXHfcRrZGymwzV/iuyvWiyTdEpcGXJ3elmp87UUeAIRx05o3hvQ1V/j9g9JOgx7dF7+utzQphSV+VYp/kSpBe9KdaWbO3Zh4EV/ZvQ1pxQR3aM+zgPblcINIQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: warwick.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: d0d6d50a-c2a1-46a0-ce68-08d74c938b93 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2019 08:34:48.0588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 09bacfbd-47ef-4465-9265-3546f2eaf6bc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ms/LBNov8Z9r/abUH0+OrK8CEvBKtG2F5xPEkQttkgSeshMkc8zZNSZ/bxDUIP7iLvo/j6DOU2uD/rVY7wKYBkkuRy/Lcq+h5t2EscrAbWw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR01MB4154 Archived-At: Subject: Re: [TLS] Selfie attack was Re: Distinguishing between external/resumption PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 09 Oct 2019 08:34:54 -0000 Hi Chris, Thanks for the link. The use of a =B3context=B2 field is reasonable. As lon= g as the client and server check the two MAC identities and ensure they are different, this specific selfie attack should be presented. I=B9m not sure how TLS PSK deals with the case of having parallel key exchange sessions between two nodes. If that=B9s allowed, and the same =B3context field=B2 is= used in the parallel sessions, there might still be a possible UKS attack. Either the parallel sessions are disabled, or if they are allowed, additional context should be added to ensure the identities of the two nodes remain unique even within parallel sessions. Cheers, Feng On 05/10/2019, 12:41, "TLS on behalf of Christopher Wood" wrote: >Hi Feng, > >For what it's worth, the latest version of the PSK importers draft >includes a "context" field into which identity information can be fed: > > =20 >https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01#append >ix-B > >Best, >Chris > >On Tue, Sep 24, 2019, at 9:19 AM, Hao, Feng wrote: >> Hi John, >>=20 >> Reflection attacks are indeed older, but the selfie attack is a bit >> different. It's actually a variant of the unknown key share attack. A >> typical example of the UKS attack is the one reported on MQV by Kaliski >> in 2001 (see "An unknown key-share attack on the MQV key agreement >> protocol" in ACM TISSEC 2001). In that example, the adversary plays >> message between two users to cause confusion in the identity, but in >> Selfie, the adversary plays message with only one user and uses another >> instance of the user to cause confusion in the identity. When we >> reported this variant of UKS in [3], we were not aware of anything like >> that in the literature. >>=20 >> Cheers, >> Feng >>=20 >> On 24/09/2019, 16:17, "John Mattsson" >>wrote: >>=20 >> Hi, >> =20 >> I think these reflection attacks are much older than this. I quick >> search for reflection attack security protocol gives a lot of old >> results, The description of reflection attack in the following lecture >> material from 2009 looks just like the "selfie attack" on TLS 1.3 >> http://www.cs.bham.ac.uk/~tpc/cwi/Teaching/Files/Lecture4_6up.pdf >> =20 >> With multiple sections there are other things that change as well. >> If two nodes unintentionally initiate simultaneous ClientHello to each >> other, even if they only want a single secure connection (I have seen >> live systems where this happens in practice), an attacker can select >> which ClientHello to block (e.g. the one with the strongest >> cryptographic parameters). The following security property would then >> no longer hold : >> =20 >> "Downgrade protection: The cryptographic parameters should be the >> same on both sides and should be the same as if the peers had >>been >> communicating in the absence of an attack" >> =20 >> (I have not looked at what the definitions in [BBFGKZ16] say). >> =20 >> Cheers, >> John >> =20 >> -----Original Message----- >> From: TLS on behalf of "Hao, Feng" >> >> Date: Tuesday, 24 September 2019 at 16:09 >> To: Mohit Sethi M , >> "Owen Friel (ofriel)" , Jonathan Hoyland >> >> Cc: "TLS@ietf.org" >> Subject: Re: [TLS] Selfie attack was Re: Distinguishing between >> external/resumption PSKs >> =20 >> =20 >> On 23/09/2019, 18:50, "TLS on behalf of Mohit Sethi M" >> > mohit.m.sethi=3D40ericsson.com@dmarc.ietf.org> wrote: >> =20 >> Hi all, >> =20 >> On the topic of external PSKs in TLS 1.3, I found a >> publication on the >> Selfie attack: >>=20 >>https://protect2.fireeye.com/url?k=3Ddd432f13-81c9e5ad-dd436f88-869a17b5b= 21 >>b-dc6c6f0a5dd21faf&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F2019%2F347 >> =20 >> Perhaps this was already discussed on the list. I thought >> that sharing=20 >> it again wouldn't hurt while we discuss how servers >> distinguish between >> external and resumption PSKs. >> =20 >> I just read the paper with interest. It occurs to me that the >> selfie attack is consistent with the "impersonation attack" that we >> reported on SPEKE in 2014; see Sec 4.1 [1] and the updated version with >> details on how SPEKE is revised in ISO/IEC 11770-4 [2]. The same attack >> can be traced back to 2010 in [3] where a "worm-hole attack" (Fig. 5, >> [3]) is reported on the self-communication mode of HMQV. The essence of >> these attacks is the same: Bob tricks Alice into thinking that she is >> talking to authenticated Bob, but she is actually talking to herself. >> In [3], we explained that the attack was missed from the "security >> proofs" as the proofs didn't consider multiple sessions. >> =20 >> The countermeasure we proposed in [1-3] was to ensure the user >> identity is unique in key exchange processes: in case of multiple >> sessions that may cause confusion in the user identity, an extension >> should be added to the user identity to distinguish the instances. The >> underlying intuition is that one should know "unambiguously" whom they >> are communicating with, and perform authentication based on that. The >> discovery of this type of attacks and the proposed solution are >> inspired by the "explicitness principle" (Ross Anderson and Roger >> Needham, Crypto'95), which states the importance of being explicit on >> user identities and other attributes in a public key protocol; also see >> [3]. I hope it might be useful to people who work on TLS PSK. >> =20 >> [1]=20 >>=20 >>https://protect2.fireeye.com/url?k=3D5a822513-0608efad-5a826588-869a17b5b= 21 >>b-eb260151f78b0718&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F2014%2F585.p= df >> [2] https://arxiv.org/abs/1802.04900 >> [3]=20 >>=20 >>https://protect2.fireeye.com/url?k=3Dd5bf88ff-89354241-d5bfc864-869a17b5b= 21 >>b-0e9b3bf58e104f32&q=3D1&u=3Dhttps%3A%2F%2Feprint.iacr.org%2F2010%2F136.p= df >> =20 >> =20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> =20 >> =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 From nobody Wed Oct 9 04:51:57 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BFB1200B7 for ; Wed, 9 Oct 2019 04:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 GbDGrvRKBxJr for ; Wed, 9 Oct 2019 04:51: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 F3F191200A3 for ; Wed, 9 Oct 2019 04:51:52 -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 x99Bpj1J011440; Wed, 9 Oct 2019 12:51:49 +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=xp378uG8RaTboc02r8IT/05E8XOQ2AVoYKDZv/h+lhE=; b=pH5zzr1/vWkO1wj1iTjeVkf/RaJWL+rWGebZKuiE7WP3tNLi/QZH7BqFT7l1MFBeu3UF 0KI6fq5a/kAMq0QMiA06hNFAsaM+8FQX5tCjxRQUGeVO7Cec1jlSncpisHH3WXwBQVMn 1Rn49wCYCLf1hjPM2g8m7/SI6/hMGGfNYnReL3+Yj/MeyTMkhVld2hiBil+OlP3H2G6e Pgee4ozAJnr8GR6thrcTp88kpQxxg2gbqNG+wqXU7nXdMbRhQC/04TxE+u6QuIiIfGAT 7X9XogX2xMweoRlfg7V6CntV0q3P//mMsw1RfbR68cnO641/pwv2hZ0eUXdKU8zuYA66 NA== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2veg8fc7nj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 12:51:49 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x99Bm2Z3007220; Wed, 9 Oct 2019 07:51:47 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint8.akamai.com with ESMTP id 2vepgxxse7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 07:51:46 -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.1473.3; Wed, 9 Oct 2019 06:51:46 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1473.005; Wed, 9 Oct 2019 06:51:45 -0500 From: "Salz, Rich" To: Rob Sayre CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAA== Date: Wed, 9 Oct 2019 11:51:44 +0000 Message-ID: References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.214] Content-Type: multipart/alternative; boundary="_000_F932C81B95E94044B9759AFCD09CF7FAakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-09_05:, , 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=871 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910090111 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-09_05:2019-10-08,2019-10-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 phishscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=856 suspectscore=0 bulkscore=0 adultscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090112 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 11:51:55 -0000 --_000_F932C81B95E94044B9759AFCD09CF7FAakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2VsbCwgVExTIGlzIGEgdHJhbnNwb3J0IGxheWVyIHByb3RvY29sLiBJIHRoaW5rIG15 IHN1Z2dlc3Rpb24gbWlnaHQgYXBwbHkgdG8gYW55IGNsaWVudCB0aGF0J3Mgc2VuZGluZyBhIGNl cnRpZmljYXRlLg0KDQpJ4oCZbSBub3QgZGlzYWdyZWVpbmcsIEnigJltIGp1c3QgZXhwbGFpbmlu ZyB3aHkgaXQgd2FzbuKAmXQgYSBmb2N1cy4NCg0KDQogICogICBBIGxpbmsgZnJvbSBDRE4gdG8g T3JpZ2luIGlzIGp1c3QgYSBwYXJ0aWN1bGFybHkgZWFzeS10by1kZXBsb3kgdXNlIGNhc2UsIHNp bmNlIGNsaWVudCBjZXJ0aWZpY2F0ZXMgYXJlIGFscmVhZHkgaW4gd2lkZSB1c2UgYW5kIElQdjYg dGVuZHMgdG8gd29yayBmbGF3bGVzc2x5Lg0KDQpJdCBkb2VzPyAgR2VlLCBjb29sLg0KDQo= --_000_F932C81B95E94044B9759AFCD09CF7FAakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <160C503CEB3B2D4DA1A95B45907A0EB0@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tMjUyODAwNjc4MDEwNDY0Mjc0 Mm1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0yNTI4MDA2NzgwMTA0NjQyNzQybXNvbGlzdHBh cmFncmFwaCwgZGl2LmdtYWlsLW0yNTI4MDA2NzgwMTA0NjQyNzQybXNvbGlzdHBhcmFncmFwaA0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzI1MjgwMDY3ODAxMDQ2NDI3NDJtc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyNzczNzM0MTM7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk5NjU1MTU5 NiAxNjg2MDM1ODAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTI2NDg3NTEyMTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTUwMDc4ODc1Njt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPldlbGwsIFRMUyBpcyBhIHRyYW5zcG9ydCBsYXllciBwcm90 b2NvbC4gSSB0aGluayBteSBzdWdnZXN0aW9uIG1pZ2h0IGFwcGx5IHRvIGFueSBjbGllbnQgdGhh dCdzIHNlbmRpbmcgYSBjZXJ0aWZpY2F0ZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJltIG5vdCBkaXNhZ3JlZWluZywgSeKAmW0ganVzdCBleHBsYWluaW5nIHdoeSBp dCB3YXNu4oCZdCBhIGZvY3VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+QSBsaW5rIGZyb20gQ0RO IHRvIE9yaWdpbiBpcyBqdXN0IGEgcGFydGljdWxhcmx5IGVhc3ktdG8tZGVwbG95IHVzZSBjYXNl LCBzaW5jZSBjbGllbnQgY2VydGlmaWNhdGVzIGFyZSBhbHJlYWR5IGluIHdpZGUgdXNlIGFuZCBJ UHY2IHRlbmRzIHRvIHdvcmsgZmxhd2xlc3NseS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgZG9lcz8mbmJzcDsgR2VlLCBjb29sLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_F932C81B95E94044B9759AFCD09CF7FAakamaicom_-- From nobody Wed Oct 9 04:55:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 801331200B7 for ; Wed, 9 Oct 2019 04:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 143kG4aKE0Si for ; Wed, 9 Oct 2019 04:55:22 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 689F912008B for ; Wed, 9 Oct 2019 04:55:22 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id b136so4323842iof.3 for ; Wed, 09 Oct 2019 04:55: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; bh=Zo+yQl0/r+PE1xf2/4V5BTXVaX+NH5LYrtkYIm2PXNs=; b=GJuHSTRK3OY98C+KcjWMMxpudwG4wMTvvUVMSLHiCU+Sedf4QV+atrxHYILZEGXlnH UiB4VJzI6n2qtVy+Qhfcrpwot2szwKXs1ZKgm5zyqOr3oD2m9LP2GYhfQIWb9j6X9Xtg ejv84Omuj7n8Bn5W9NF/tWqZGEtaGlk2bUic3qslUYFdVTbYXcSqJpSpqVSqaNWxMRWJ y+r8DWkG4OqtZ/Q2Ln1mDcncKTaHONAEp69/Ho9N+2muVSSRSbLOu+0YZvCkqaLecpLy RWC9YQm0z16eoocvvvi175ulw6yIghWPatl64nEkaXCmhVpyEoCYHnapJlWQBCxRthZ/ 6Cog== 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=Zo+yQl0/r+PE1xf2/4V5BTXVaX+NH5LYrtkYIm2PXNs=; b=Il2r8qCFM/ilYWoGfw45BgsrlHQvqbuNTgz3usdtIXYgIW7I8RwWD5kd+Itr7/JSb7 7MsOWKAkalnMVK/caIFYJ55Jd1u3iJ/G6EIY07+q6VMSScAvtA7oR6oYSaLxVpchWkz7 +JZHvLpeZ8LXwDVzPpzKdHnIL9V+WL+6paG3L/3ErqNrJUXOjNrop5iuih3zwjQzCnRl SO/5dLzmhwAzdFqjdP5rXfW180vcPodAQ+YTbVPcavOl6FruRLsUrnCdFYLnLvkXmPze nG1SoBhjZ5+clxptPvDtddLiG7ALSdZ3V78Mv0RYomUKdRa/5bTi7TuAvVP913Ed61tE KKJw== X-Gm-Message-State: APjAAAWztbkvjK/4AkDi3h6T3/ZzYulz+3oJkWxyt3mgCeV71PQJdbmW egeIc6ObMSCNhAz/0l9FlQk1fpEPyM2Q31tV6gU= X-Google-Smtp-Source: APXvYqwlU4UZTRZRqnG8eJgSbrGqNtpWCCr0qVpi6hBY539C6xCYCPeFIsOyKWT7lYz/FeDptix+NdheRQ6qMv1Esuo= X-Received: by 2002:a6b:b807:: with SMTP id i7mr2921314iof.254.1570622121515; Wed, 09 Oct 2019 04:55:21 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 18:55:10 +0700 Message-ID: To: "Salz, Rich" Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a11e6b059478f501" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 11:55:25 -0000 --000000000000a11e6b059478f501 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 6:51 PM Salz, Rich wrote: > > - A link from CDN to Origin is just a particularly easy-to-deploy use > case, since client certificates are already in wide use and IPv6 tends to > work flawlessly. > > > > It does? Gee, cool. > This response sounds like anger. I'm sorry I've caused you to feel angry. It might be best to discuss technical concerns. Do you think an SNI field sent with a client certificate is a bad idea? I'm not a cryptographer, so I thought I would suggest the approach and see what people thought. thanks, Rob --000000000000a11e6b059478f501 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 6:51 PM Salz, Rich= <rsalz@akamai.com> wrote:
  • A link from CDN to Origin is just a particularly easy-to-deploy u= se case, since client certificates are already in wide use and IPv6 tends t= o work flawlessly.

=C2=A0

It does?=C2=A0 Gee, cool.


This response sounds like anger. I'm sorry = I've caused you to feel angry.

It might be bes= t to discuss technical concerns. Do you think an SNI field sent with a clie= nt certificate is a bad idea? I'm not a cryptographer, so I thought I w= ould suggest the approach and see what people thought.

=
thanks,
Rob
--000000000000a11e6b059478f501-- From nobody Wed Oct 9 05:21:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668771200D7 for ; Wed, 9 Oct 2019 05:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 qAbtVUUCjmRF for ; Wed, 9 Oct 2019 05:20:56 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702AB1200C3 for ; Wed, 9 Oct 2019 05:20:56 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id y3so2258692ljj.6 for ; Wed, 09 Oct 2019 05:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xocpzkDPVy17NvGjtfVdxYKvHt112fZQA2GtJoEa7J0=; b=gqeyAsS/+hjSeHytzH/HWMYdm6i36T6t+x1d1bqg31pieVznIqAWhCqqhOmUSB0SWH IMuSiPQSQPUrPsl4Joq9AzT6xZ44uy2apzaBSKuJlRAb2pYwwEkoOZvYed4fkR8TwY+Z jChZK7AjXDgAAhH9g32R3jfpQ6PjPnS7Z91JTah6g78RF/j/YUaqYb3I/uYjPJnj/lA5 ORkaa7OKrrta+BGaZDsxnrel2oOnOgAf9r1+k1kDphnvT3it5XmiDkg8A2UHx6/DT5I+ gTA/W4D1J1D53OdzFsWDQrHSMmT4sY+MSQXIoNu6CK014ELWiPD4EVcDYB5qM/JJ+tHT neTQ== 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=xocpzkDPVy17NvGjtfVdxYKvHt112fZQA2GtJoEa7J0=; b=ZxEn0407JopUWPhA3EDErCPTk/mNjexxbQ67DM7f6dQ8w7Pe7UKootlxTXac98AXMH OaG8CoBm1lbXY00FSyTPdSf+cZIalQkyuB+2b04JMbWuXDlrEV7u+DO/TXzT/hfd1v9q 4Iw7M4y39cmKA5+dw1vclZzTgao4iPLYGfDhfk2XxU2Bw9Vb2kzOFm3+AUhsYQ2Ukfwv 8N/XFA0KfXV8Ac6i+SeiSchaDAKguS0hHh646Dn589KE6BWWXXKV3ROkhL5Y6otBeoz2 eePQkcL9IL46IcIX5ZRiscR5NHIn2Pw8T6m/OvFmcyFOpP33tw0GzK1cGjLykQHNAKns +CZA== X-Gm-Message-State: APjAAAX2fT8oxNXcnB68VlvpLwl9r0LGCI9VRRaaxUrHBKmCnrLwFtyx Qkfj3z80mpK8ps/v6f3cmR4aDtxIe8tHoI0jrl3mTQ== X-Google-Smtp-Source: APXvYqxKiIDCCkQYKNpO81Iat3Z3dYoq1deymRe0TE3mP+rqRYBp4d/lYObR5tvQHX1FjIu7JReLhL9h2UyVLbF4MiU= X-Received: by 2002:a2e:3a14:: with SMTP id h20mr2061401lja.29.1570623654480; Wed, 09 Oct 2019 05:20:54 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 05:20:18 -0700 Message-ID: To: Rob Sayre Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000006a660594795172" Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 09 Oct 2019 12:20:59 -0000 --000000000000006a660594795172 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 7, 2019 at 10:29 AM Rob Sayre wrote: > On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla wrote: > >> >>>>> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new documents. >>>>> >>>> >>>> A few points. >>>> >>>> 1. It doesn't pull it in. There's no reference and there's just an >>>> informative statement. >>>> >>> >>> Shouldn't there be an informative reference? >>> >> >> To what? >> > > Hi, I missed this response. This discussion seems a bit tedious, but > > 1) it doesn't seem like a particularly valid claim to say that the > document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a > missing reference. > Well I suppose you're entitled to your opinion, but no, I don't think that's true. We have a very specific meaning for normative dependency and in no way would this be one. At most this would be an informative reference. In any case, this is not the proper place for this discussion. If you want this document changed, you'll need to take it to the RTCWEB WG. > This thread also has some other unusual claims: > > On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell > wrote: > > we can't "UPDATE" an I-D. > > Not true. If you need to refer to something that's been IESG-approved but > still in the RFC queue, you can leave a note for the RFC editor to update > the reference to the eventual RFC number. > > On Wed, Oct 2, 2019 at 8:17 PM Sean Turner wrote: > > You can change the text, but I do not believe it will change the > implementations. > > If true, changing the text would seem to be uncontroversial. > > Anyway, leaving strange text like this DTLS 1.0 stuff in the webrtc > document is one thing (although I'm surprised the IESG allowed it). > Claiming that a document like draft-ietf-tls-oldversions-deprecate can't > update documents from a concluded WG is another. > > If the IETF can't get consensus on actually deprecating DTLS 1.0, maybe > something similar to the text from draft-ietf-rtcweb-security-arch should > be added to draft-ietf-tls-oldversions-deprecate. > > "Earlier specifications required DTLS 1.0. Endpoints which support only > DTLS 1.2 might encounter interoperability issues." > > That would seem to subvert the point of the draft--I think this is the > point that the original post in this thread was making. > When we agreed to discuss this draft, there was an explicit discussion of the fact that this was the IETF's opinion based on security and protocol maturity but that we expected the transition to take longer in some domains than others, so I wouldn't have a problem with that kind of text, as I think it's factually accurate and implicit. -Ekr > thanks, > Rob > --000000000000006a660594795172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 7, 2019 at 10:29 AM Rob S= ayre <sayrer@gmail.com> wrote= :
On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla <ekr@rtfm.com> wrote:
=

It s= eems strange to put DTLS 1.0 (based on TLS 1.1) into new documents.

A few points.

1. It doesn't pull it in. There's no r= eference and there's just an informative statement.

Shouldn't there be an informative refere= nce?

To what?
=

Hi, I missed this response. This dis= cussion seems a bit tedious, but

1) it doesn't= seem like a particularly valid claim to say that the document "doesn&= #39;t pull" in DTLS 1.0 when the rationale for that claim is a missing= reference.

Well I = suppose you're entitled to your opinion, but no, I don't think that= 's true. We have a very specific meaning for normative dependency and i= n no way would this be one. At most this would be an informative reference.=

In any case, this is not the proper place for thi= s discussion. If you want this document changed, you'll need to take it= to the RTCWEB WG.

=

This thread also has some other unusual claims:

On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <stephen.farrell@cs= .tcd.ie> wrote:
> we can't "UPDATE" an I-D.
<= /div>

Not true. If you need to refer to something that&#= 39;s been IESG-approved but still in the RFC queue, you can leave a note fo= r the RFC editor to update the reference to the eventual RFC number.
<= div>
On Wed, Oct 2, 2019 at 8:17 PM Sean Turner <sean@sn3rd.com> wrote:<= /div>
> You can change the text, but I do not believe it will change= the implementations.

If true, changing the te= xt would seem to be uncontroversial.

Anyway, leavi= ng strange text like this DTLS 1.0 stuff in the webrtc document is one thin= g (although I'm surprised the IESG allowed it). Claiming that a documen= t like draft-ietf-tls-oldversions-deprecate can't update documents from= a concluded WG is another.

If the IETF can't = get consensus on actually deprecating DTLS 1.0, maybe something similar to = the text from=C2=A0draft-ietf-rtcweb-security-arch should be added to draft= -ietf-tls-oldversions-deprecate.

"Earlier spe= cifications required DTLS 1.0. Endpoints which support only DTLS 1.2 might = encounter interoperability issues."

That woul= d seem to subvert the point of the draft--I think this is the point that th= e original post in this thread was making.

When we agreed to discuss this draft, there was an = explicit discussion of the fact that this was the IETF's opinion based = on security and protocol maturity but that we expected the transition to ta= ke longer in some domains than others, so I wouldn't have a problem wit= h that kind of text, as I think it's factually accurate and implicit.

-Ekr


thanks,
Rob
--000000000000006a660594795172-- From nobody Wed Oct 9 05:22:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86DFE1200C3 for ; Wed, 9 Oct 2019 05:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 Bx-sWspx-jc6 for ; Wed, 9 Oct 2019 05:22:53 -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 BA78C12008B for ; Wed, 9 Oct 2019 05:22:52 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id m7so2297740lji.2 for ; Wed, 09 Oct 2019 05:22:52 -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=y+7vEZOKpN5eKhNwBUSyeg1anzF8S+o60hOE+dhpTh8=; b=j5iSZNqQZ8CtASU8LgntluHHaDy2IkHEosjqs0gU8PEPMffqvY3mqTkwDG3IC/6Wlj 5otGQCaBhyl1uclAcAaVktaimNj7dmwsMWlatYvEBrW2eWOYxxTbUaZrUYThL1GFLm1C 9tIgs4PIlZxgBlrEiO/oOgfc+ktq5m4K6WAnEcZ/YTu4O/UMrHWe4UdBl6xc0ckPXWP0 lr/BjVQm48Qgg51suGG6xhPr83NBHh4/VypLfA67fDjlYRPBGrvghdB3/XquAKKajYzm A6+/TzSUKTIU1ApqVI1HymVNXW0kLg2Z9ObPUf1DG/z5H72MUIbx4rHAz8FSmMS6bZBn 7mLQ== 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=y+7vEZOKpN5eKhNwBUSyeg1anzF8S+o60hOE+dhpTh8=; b=mFEDTdlKDMfY1jwOvnABJdRPsiS7LdtuZfnCNPmsbPWznZ5gnKJIliTi7vrZ4r6suh ge5I/eVCOUc2m/bOe6JyNUnIwIXiBHc1yW+wE9WbYKy7Qu+x9fjyQu7ty2TZ5kr2Oevk y3j2P/eQkZOSInvI+Z2IaYsma0JzDSkxiDeHyonmmFWNfDylu8kgdUkVHtA4j2M3vbuz ja9Ihw8yHKCiZ0slJB8kEZiqbbGbP+jBiq2oApQsTjIr2+VC1DujPX89r5iIzursClfq 7VkxMS50LNKRvRrykm2VMLs5/um03Fz+3N+XTISZGue+NErmKh0wgBMqXnF9bRtKHoCD eZPA== X-Gm-Message-State: APjAAAXbTcFd2Op2G2fAeKvYau67fwozV0r9GdGB1cMiD7T9D3wido7K 1x/l04tqUxJ82kUG7FVojpBhN85HBz8Mp9oJ+gJD8Q== X-Google-Smtp-Source: APXvYqwVrcR/DcecYLafb2/bAMx/FRjjAA2Z09JprC6DVYxdao7MiHBN/j/nZcPAnrwjRnlmJtbp4FyoZ5w3xDlShow= X-Received: by 2002:a2e:8310:: with SMTP id a16mr2215067ljh.48.1570623770892; Wed, 09 Oct 2019 05:22:50 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 05:22:14 -0700 Message-ID: To: Rob Sayre Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000f0aee505947957c5" Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 09 Oct 2019 12:22:57 -0000 --000000000000f0aee505947957c5 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 5:20 AM Eric Rescorla wrote: > > > On Mon, Oct 7, 2019 at 10:29 AM Rob Sayre wrote: > >> On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla wrote: >> >>> >>>>>> It seems strange to put DTLS 1.0 (based on TLS 1.1) into new >>>>>> documents. >>>>>> >>>>> >>>>> A few points. >>>>> >>>>> 1. It doesn't pull it in. There's no reference and there's just an >>>>> informative statement. >>>>> >>>> >>>> Shouldn't there be an informative reference? >>>> >>> >>> To what? >>> >> >> Hi, I missed this response. This discussion seems a bit tedious, but >> >> 1) it doesn't seem like a particularly valid claim to say that the >> document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a >> missing reference. >> > > Well I suppose you're entitled to your opinion, but no, I don't think > that's true. We have a very specific meaning for normative dependency and > in no way would this be one. At most this would be an informative reference. > > In any case, this is not the proper place for this discussion. If you want > this document changed, you'll need to take it to the RTCWEB WG. > > >> This thread also has some other unusual claims: >> >> On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell >> wrote: >> > we can't "UPDATE" an I-D. >> >> Not true. If you need to refer to something that's been IESG-approved but >> still in the RFC queue, you can leave a note for the RFC editor to update >> the reference to the eventual RFC number. >> >> On Wed, Oct 2, 2019 at 8:17 PM Sean Turner wrote: >> > You can change the text, but I do not believe it will change the >> implementations. >> >> If true, changing the text would seem to be uncontroversial. >> >> Anyway, leaving strange text like this DTLS 1.0 stuff in the webrtc >> document is one thing (although I'm surprised the IESG allowed it). >> Claiming that a document like draft-ietf-tls-oldversions-deprecate can't >> update documents from a concluded WG is another. >> >> If the IETF can't get consensus on actually deprecating DTLS 1.0, maybe >> something similar to the text from draft-ietf-rtcweb-security-arch should >> be added to draft-ietf-tls-oldversions-deprecate. >> >> "Earlier specifications required DTLS 1.0. Endpoints which support only >> DTLS 1.2 might encounter interoperability issues." >> >> That would seem to subvert the point of the draft--I think this is the >> point that the original post in this thread was making. >> > > When we agreed to discuss > adopt. this draft, there was an explicit discussion of the fact that this was the > IETF's opinion based on security and protocol maturity but that we expected > the transition to take longer in some domains than others, so I wouldn't > have a problem with that kind of text, as I think it's factually accurate > and implicit. > > -Ekr > > >> thanks, >> Rob >> > --000000000000f0aee505947957c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 5:20 AM Eric R= escorla <ekr@rtfm.com> wrote:
=


On Mon, Oct 7, 2019 at 10:29 AM Rob Sayre <sayrer@gmail.com> wrote:=
On Mon, Oct 7, 2019 at 1:25 AM Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>

It se= ems strange to put DTLS 1.0 (based on TLS 1.1) into new documents.

A few points.

1. It doesn't pull it in. There's no re= ference and there's just an informative statement.

Shouldn't there be an informative referen= ce?

To what?
<= /div>

Hi, I missed this response. This disc= ussion seems a bit tedious, but

1) it doesn't = seem like a particularly valid claim to say that the document "doesn&#= 39;t pull" in DTLS 1.0 when the rationale for that claim is a missing = reference.

Well I s= uppose you're entitled to your opinion, but no, I don't think that&= #39;s true. We have a very specific meaning for normative dependency and in= no way would this be one. At most this would be an informative reference.<= /div>

In any case, this is not the proper place for this= discussion. If you want this document changed, you'll need to take it = to the RTCWEB WG.

<= div>
This thread also has some other unusual claims:

On Tue, Oct 1, 2019 at 7:34 PM Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
> we can't "UPDATE" an I-D.

Not true. If you need to refer to something that= 9;s been IESG-approved but still in the RFC queue, you can leave a note for= the RFC editor to update the reference to the eventual RFC number.

On Wed, Oct 2, 2019 at 8:17 PM Sean Turner <sean@sn3rd.com> wrote:
> You can change the text, but I do not believe it will change th= e implementations.

If true, changing the text = would seem to be uncontroversial.

Anyway, leaving = strange text like this DTLS 1.0 stuff in the webrtc document is one thing (= although I'm surprised the IESG allowed it). Claiming that a document l= ike draft-ietf-tls-oldversions-deprecate can't update documents from a = concluded WG is another.

If the IETF can't get= consensus on actually deprecating DTLS 1.0, maybe something similar to the= text from=C2=A0draft-ietf-rtcweb-security-arch should be added to draft-ie= tf-tls-oldversions-deprecate.

"Earlier specif= ications required DTLS 1.0. Endpoints which support only DTLS 1.2 might enc= ounter interoperability issues."

That would s= eem to subvert the point of the draft--I think this is the point that the o= riginal post in this thread was making.

When we agreed to discuss

adopt.


this draft, there was an explicit discussion of the fact tha= t this was the IETF's opinion based on security and protocol maturity b= ut that we expected the transition to take longer in some domains than othe= rs, so I wouldn't have a problem with that kind of text, as I think it&= #39;s factually accurate and implicit.

-Ekr


t= hanks,
Rob
--000000000000f0aee505947957c5-- From nobody Wed Oct 9 05:28:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14801200D7; Wed, 9 Oct 2019 05:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 8m9TFQdO6wnx; Wed, 9 Oct 2019 05:28:15 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 E730E1200B7; Wed, 9 Oct 2019 05:28:14 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id u8so4520554iom.5; Wed, 09 Oct 2019 05:28: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=M7fxamHMpV7TYiaXQY1qaMR/Nq78R0yu3fDcJJ2uYEE=; b=fncyKhUYPcsYsnrYkhW53zN7f4yQ8rVFwFSmCBr518WhFoOJR2/e1wnCn8+/ltk+Yr DZLtcB8XOVFN65VO0X/O43Fd145d8Xng0DxIxpRqUQggFprCZN3BXMDf2EB/+LKBzIIC TRz5H6OmHjoy8ex/3ku3W/QejjPpz2mkR8mhnnO9S9DABOpQF2sA6AnLddTfHA1RY+WW /0TH3LcBnDxp2Q0pcpzVbvn5K7ZypGwmJ6SBv+vZNwYt73uqgg7e5ijiiglbS9Q3Zg2u sfNOTutzPK+HoC9xcK2P/3ljDurlGgsrD5p2zytV+nxPY5FFqfVEUgQdZlWOf7rCdoCw GHKA== 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=M7fxamHMpV7TYiaXQY1qaMR/Nq78R0yu3fDcJJ2uYEE=; b=qgIHWDdJ1LBm1DxODki9Q9E5JzEzb7BxJRtsJXfo1K8Q3CJcDn0y09yF7xDFqgA+VL sd/MhIPLfT/6ZNG2AruxNznME0JtX7rNTiSMWGvEvxxD5nDfBe1QibsuXOLP6hftWHbT TH2TENaUZHtHuMRuhaOhMVK8bELokf0k3ENSu84SZ8BrNEiNVyg9jpUIhfyGQaZsj38g 6l2VTxCzX4iz3GNGzHvpVouj+ofBHCoI0AQC93N2s77BWWPDNZD+e6Cg2fNHwmSlaisW hDMkhXipf6cRglXgpyGncLbvuWnhJGtv061h/zsavijKR//FAcrilE/QLLQbKLracZoO O7zA== X-Gm-Message-State: APjAAAXkzPDsAtrvG4rCRt7QYenGVmt07BBcKnc6QDQtFOdDhctqxumO r0+gEKGPB8CdRIZNqQbBHLAjuRWTqWqf2KTdSQ8= X-Google-Smtp-Source: APXvYqwiu9VnNu5Jwz9ijuDxm/eQ15QzHifTd3+wwiN1gYyNaALLbhjn49QQ+epvpmlgr4844JQ7bx2eejYCFRCjLYY= X-Received: by 2002:a6b:f90f:: with SMTP id j15mr1708427iog.257.1570624094219; Wed, 09 Oct 2019 05:28:14 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 19:28:02 +0700 Message-ID: To: Eric Rescorla Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , IESG Secretary , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000003633a70594796bae" Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 09 Oct 2019 12:28:17 -0000 --0000000000003633a70594796bae Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla wrote: > >> 1) it doesn't seem like a particularly valid claim to say that the >> document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a >> missing reference. >> > > Well I suppose you're entitled to your opinion, but no, I don't think > that's true. We have a very specific meaning for normative dependency and > in no way would this be one. At most this would be an informative reference. > > In any case, this is not the proper place for this discussion. If you want > this document changed, you'll need to take it to the RTCWEB WG. > Honestly, thank you for the sincere response. After I read more of the many relevant documents, it became clear that draft-ietf-tls-oldversions-deprecate says implementations MUST NOT negotiate DTLS 1.0, while RFC 6347 and draft-ietf-rtcweb-security-arch encourage negotiation that results in endpoints agreeing on DTLS 1.0. That seems like the inconsistency to discuss. thanks, Rob --0000000000003633a70594796bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 7:20 PM Eric Resco= rla <ekr@rtfm.com> wrote:

1) it doesn't seem like a particularly val= id claim to say that the document "doesn't pull" in DTLS 1.0 = when the rationale for that claim is a missing reference.
=

Well I suppose you're entitled t= o your opinion, but no, I don't think that's true. We have a very s= pecific meaning for normative dependency and in no way would this be one. A= t most this would be an informative reference.

In = any case, this is not the proper place for this discussion. If you want thi= s document changed, you'll need to take it to the RTCWEB WG.

Honestly, thank you for the sincere= response.

After I read more of the many relevant = documents, it became clear that=C2=A0draft-ietf-tls-oldversions-deprecate s= ays implementations MUST NOT negotiate DTLS 1.0, while RFC=C2=A06347 and dr= aft-ietf-rtcweb-security-arch encourage=C2=A0negotiation that results in en= dpoints agreeing on DTLS 1.0.

That seems like the = inconsistency to discuss.

thanks,
Rob
--0000000000003633a70594796bae-- From nobody Wed Oct 9 05:31:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14587120089 for ; Wed, 9 Oct 2019 05:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 swIlki5BM3VB for ; Wed, 9 Oct 2019 05:31:56 -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 7BEDC12002E for ; Wed, 9 Oct 2019 05:31:56 -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 x99CQqbu006831; Wed, 9 Oct 2019 13:31:55 +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=lgL2D9uHy50HVj4rm0SV+aXlPMlmP7MVOE9fZiS6JUo=; b=iThgZIqcyLLwsnTK2yIXQDmKkEDEBGHrD4Qiw+t2jdWxVQU/E/Torb/3SGGd8Pse3Jok LFtAOh1dbW0mTyQgteXlah/6frByymc8dNOGtEypi5YhPLff8KgPG6Lg04/U0AdkhNDB 97sKY8Mv+nhRn41KwCtwSMRT5GXwMvvqS2a7nBCruf8TSd93+PLyAYjqzNhcOfecP1Wr nUc4FnXpRKFQLMUG7USj2l2ZuCrDxtF9lNRAXpViYF6VsbLDav3u8nz/W2qTraJJV9HX 6RWmDbmiheY5Sw2icB4PtQYKmw1r6xGfhpvP5OEm5rxa7YoJMTDYdANBlAQvs6yqcul2 Rw== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vejtvb39k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 13:31:55 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x99CHbmM013518; Wed, 9 Oct 2019 08:31:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint3.akamai.com with ESMTP id 2vepgyxsvq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 08:31:51 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 05:31:28 -0700 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.1473.005; Wed, 9 Oct 2019 07:31:28 -0500 From: "Salz, Rich" To: Rob Sayre CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAIAARAMA///HFYA= Date: Wed, 9 Oct 2019 12:31:28 +0000 Message-ID: <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.214] Content-Type: multipart/alternative; boundary="_000_80F168B07F304FDABD0F4C787802F0D5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-09_05:, , 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=907 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910090116 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-09_05:2019-10-08,2019-10-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 priorityscore=1501 impostorscore=0 phishscore=0 spamscore=0 mlxlogscore=877 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090118 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:31:58 -0000 --_000_80F168B07F304FDABD0F4C787802F0D5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQSBsaW5rIGZyb20gQ0ROIHRvIE9yaWdpbiBpcyBqdXN0IGEgcGFydGljdWxhcmx5IGVh c3ktdG8tZGVwbG95IHVzZSBjYXNlLCBzaW5jZSBjbGllbnQgY2VydGlmaWNhdGVzIGFyZSBhbHJl YWR5IGluIHdpZGUgdXNlIGFuZCBJUHY2IHRlbmRzIHRvIHdvcmsgZmxhd2xlc3NseS4NCg0KSXQg ZG9lcz8gIEdlZSwgY29vbC4NCkkgd2FzIGJlaW5nIHNhcmNhc3RpYywgbm90IGFuZ3J5LiBJIHNo b3VsZG7igJl0IGhhdmUgZG9uZSBzby4NCg0KQnV0IG5vdyBJIGFtIG5vdCBzdXJlIHdoYXQgeW91 IGFyZSBhc2tpbmcgZm9yLiAgQXNraW5nIGFib3V0IENETiB0byBPcmlnaW4gdXNpbmcgRVNOSSBv ciBFU05JIHdpdGggYSBjbGllbnQgY2VydD8NCg== --_000_80F168B07F304FDABD0F4C787802F0D5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <339DE196BC083148BD6087031A1B1A1B@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFp bC1tLTc4Mzk1NzMzMjExODg4MDg2OTBtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tLTc4Mzk1 NzMzMjExODg4MDg2OTBtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbS03ODM5NTczMzIxMTg4 ODA4NjkwbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy03ODM5NTcz MzIxMTg4ODA4NjkwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6MTY0MTMwMjkxMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMxNjAw NTk1Mjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVs IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTc4Mzk1NzMzMjExODg4MDg2OTBtc29s aXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQSBsaW5rIGZy b20gQ0ROIHRvIE9yaWdpbiBpcyBqdXN0IGEgcGFydGljdWxhcmx5IGVhc3ktdG8tZGVwbG95IHVz ZSBjYXNlLCBzaW5jZSBjbGllbnQgY2VydGlmaWNhdGVzIGFyZSBhbHJlYWR5IGluIHdpZGUgdXNl IGFuZCBJUHY2IHRlbmRzIHRvIHdvcmsgZmxhd2xlc3NseS48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjExLjU1cHQiPg0KSXQgZG9lcz8mbmJzcDsg R2VlLCBjb29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB3YXMgYmVpbmcgc2FyY2FzdGljLCBub3QgYW5ncnkuIEkgc2hvdWxkbuKAmXQgaGF2 ZSBkb25lIHNvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgbm93 IEkgYW0gbm90IHN1cmUgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IuJm5ic3A7IEFza2luZyBhYm91 dCBDRE4gdG8gT3JpZ2luIHVzaW5nIEVTTkkgb3IgRVNOSSB3aXRoIGEgY2xpZW50IGNlcnQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_80F168B07F304FDABD0F4C787802F0D5akamaicom_-- From nobody Wed Oct 9 05:41:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8397D120089 for ; Wed, 9 Oct 2019 05:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 GT64C5UqQ4i2 for ; Wed, 9 Oct 2019 05:41:18 -0700 (PDT) Received: from mail-yw1-xc2d.google.com (mail-yw1-xc2d.google.com [IPv6:2607:f8b0:4864:20::c2d]) (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 575C412002E for ; Wed, 9 Oct 2019 05:41:18 -0700 (PDT) Received: by mail-yw1-xc2d.google.com with SMTP id w140so756980ywd.0 for ; Wed, 09 Oct 2019 05:41:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bPw74xp7BIRph9Y05mojh+N09fw4sotvUBlj94M8PAc=; b=HtTOXuOq0itVJaKvLB5iLQOCXdoCEP8TH1LWiuPiiN9MwmjXMNR2D0oHcsrje2T70v tA4OWLDfi+sjwKf8zWkHcY2SKrxM/0D5aMShoh0SIoH/4MYiMt1fwRaHJ0edBrE9B+PO 1qEtLwn6UIRbPzuW05wvWzgaXYquq6/yAAQqk= 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=bPw74xp7BIRph9Y05mojh+N09fw4sotvUBlj94M8PAc=; b=qkaMU1Xkq9+BumgtWiPLTE9wunvBq4eGv9jebsRxfWC7aw/vdxhT8O2KbqogcomSN8 0HS5w9KOaCzkaBT68KOoamJFgXlmsGLbqu5QW5qfX+GF5n5das1+E1wlPYaF/+4r/emK NKSaCglPFf8HtJZ4JfMjvoDLJcA9rgz4cQ5i/HfiQMOCxIic+XRYv8jv/psnAw2+nWP1 6qgAPpDhF8b5EjjUpLWNr1oE+LLycM5gOALda1c/KUyowAH6Fa2Csf0pxc2bSWNUVLi+ pVMqFKO5y1eVAo3XUTT9h2uQiOrEJCtLkkYPEwSBpal+vHHPy7AoTs4Xa80fHh+CVIzO T+oQ== X-Gm-Message-State: APjAAAVWaH82XAVNN/QDt1+6TEPJHHA3HI4KVM7ixcxdk89Qpiwt3ez8 /OZWDjafoW8Ov5wW4jHeLqrI/PnGtHYMcvxhPu4pEQ== X-Google-Smtp-Source: APXvYqzSAPJUnkfN4At4ymIkr5Dqz4wprjnLoar/ENJk0n/mzL8WF9ogfyQKfppfOzwDYegyq7jmKu/2MP9qGONAKio= X-Received: by 2002:a81:a405:: with SMTP id b5mr2586968ywh.380.1570624877061; Wed, 09 Oct 2019 05:41:17 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> In-Reply-To: From: Kyle Rose Date: Wed, 9 Oct 2019 08:41:05 -0400 Message-ID: To: Rob Sayre Cc: Rich Salz , "" Content-Type: multipart/alternative; boundary="000000000000df7fd2059479995b" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:41:22 -0000 --000000000000df7fd2059479995b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm struggling to understand the issue you're raising. There's typically nothing special about the CDN to origin TLS interaction. If the origin supports ESNI, why couldn't it advertise that? The CDN node could just pick it up like any other TLS client would.* The one way in which CDN to origin interactions may differ greatly from client to origin interactions is the aggregation of many sessions to the same origin inside the same connection, but this is at the application layer. This aggregation may improve privacy by decoupling incoming traffic from upstream requests through persistent connections and/or pre-cached content. Can you more precisely define your concern? Kyle *Not clear that it would be helpful, since the origin is probably obvious from the destination IP, but I think the whole ESNI discussion presumes traffic analysis is either hopelessly na=C3=AFve or impossible, so I'll jus= t stipulate that and proceed from there. On Wed, Oct 9, 2019, 7:55 AM Rob Sayre wrote: > On Wed, Oct 9, 2019 at 6:51 PM Salz, Rich wrote: > >> >> - A link from CDN to Origin is just a particularly easy-to-deploy use >> case, since client certificates are already in wide use and IPv6 tend= s to >> work flawlessly. >> >> >> >> It does? Gee, cool. >> > > This response sounds like anger. I'm sorry I've caused you to feel angry. > > It might be best to discuss technical concerns. Do you think an SNI field > sent with a client certificate is a bad idea? I'm not a cryptographer, so= I > thought I would suggest the approach and see what people thought. > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000df7fd2059479995b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm struggling to understand the issue you're rai= sing.

There's typically no= thing special about the CDN to origin TLS interaction. If the origin suppor= ts ESNI, why couldn't it advertise that? The CDN node could just pick i= t up like any other TLS client would.*

The one way in which CDN to origin interactions may differ g= reatly from client to origin interactions is the aggregation of many sessio= ns to the same origin inside the same connection, but this is at the applic= ation layer. This aggregation may improve privacy by decoupling incoming tr= affic from upstream requests through persistent connections and/or pre-cach= ed content.

Can you more= precisely define your concern?

Kyle

*Not clea= r that it would be helpful, since the origin is probably obvious from the d= estination IP, but I think the whole ESNI discussion presumes traffic analy= sis is either hopelessly na=C3=AFve or impossible, so I'll just stipula= te that and proceed from there.

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 9, 2019, 7:55 AM Rob Sayre= <sayrer@gmail.com> wrote:
On = Wed, Oct 9, 2019 at 6:51 PM Salz, Rich <rsalz@akamai.com> wrote:
  • A link from CDN to Origin is just a particula= rly easy-to-deploy use case, since client certificates are already in wide = use and IPv6 tends to work flawlessly.

=C2=A0

It does?=C2=A0 Gee, cool.


This response sounds like anger. I'm sorry = I've caused you to feel angry.

It might be bes= t to discuss technical concerns. Do you think an SNI field sent with a clie= nt certificate is a bad idea? I'm not a cryptographer, so I thought I w= ould suggest the approach and see what people thought.

=
thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000df7fd2059479995b-- From nobody Wed Oct 9 05:47:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DED5120089 for ; Wed, 9 Oct 2019 05:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 OdlhjZjkzXGY for ; Wed, 9 Oct 2019 05:47:19 -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 08E6E12002E for ; Wed, 9 Oct 2019 05:47:19 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id c25so4544346iot.12 for ; Wed, 09 Oct 2019 05:47: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=ii2MdXpMUwSuJrqVkYe0WApcXlTU4t5UC8ddvYpgtmI=; b=jpKgAuIAwxTJugm4rhXEPUptO8+CbVxSluLcngszQYtu+RgkWrFvKNZjz7bpxn8qKv SdVppWA1yHe5Jf5iks8+TbcJ1r3sCOt5bwZAJZ2SxuzmEX1V3VwDPBos0MQxXiktG5G+ aRdrhvQUrx8VCDvPRUGvWwOUmpSqBFY03wKu83r7juSmGdsCZypbV+kKWcutUuyIvMSq ic+LIRpfFUFzAWwMJfq24wb2K2SluqV04cvwDRSjRMx3cI9dIu9bWrFZGDM2Vmkz2CxJ DqLfyyBfN54cRdgBQd2jWOdpMJNKNNcV46ICqa5zVMWye1M8plsL3JZ4fnn5nmWLrml3 KUBg== 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=ii2MdXpMUwSuJrqVkYe0WApcXlTU4t5UC8ddvYpgtmI=; b=E+mNmDTKZ5ha8byNptC/o9QxBak/ef8a2vAzq8cPa2JKbRQZbpQ8uU3hBUifYRZxkA Kw49ZsIkk19ddXKzvvsmMOVdDe04B2Ln5xOFBE8QqRfwm/YaiREYaXd7T84/QmQOk6/M Oz8albRRYJcPN03iWoyN5Nal3+wTOm+zJ8qXZ+PuV2QR1DKw08lMxHUO9dbiOVuKQ5/z F20T5Q3z5X6Ok/LFX6vbw+QcGd7jZK8vUYREpGOJ547GE3b17QlBm2QZ3BFUGRTHrCK0 R+lN1CGxKzFqlPmKSS8pkMnye4k1H2nyBUUlY2obhuECJjKN/SG8P7UnRB7q3KgQUg1/ 5+MA== X-Gm-Message-State: APjAAAWMELYR4PL1g2N+pbrxM+zAFe5rHjxctR5pJUUQWrxjx2S/M3qN Q2I5N1TC/k4yip1h92rtzwIYV5M1QaY/vYEREJI= X-Google-Smtp-Source: APXvYqysJeU91LcpYV2NmxvKxnOkyxXDEtjvJJUAABuMgMnzWzl2+Pdc1Ot/NqmPf8XgLmhDa0R8ceIg+WDNTJgHlQo= X-Received: by 2002:a92:d987:: with SMTP id r7mr20198iln.254.1570625238049; Wed, 09 Oct 2019 05:47:18 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> In-Reply-To: <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> From: Rob Sayre Date: Wed, 9 Oct 2019 19:47:06 +0700 Message-ID: To: "Salz, Rich" Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000063ab94059479af0a" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:47:21 -0000 --00000000000063ab94059479af0a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 7:31 PM Salz, Rich wrote: > > - A link from CDN to Origin is just a particularly easy-to-deploy use > case, since client certificates are already in wide use and IPv6 tends= to > work flawlessly. > > > > It does? Gee, cool. > > I was being sarcastic, not angry. I shouldn=E2=80=99t have done so. > > > > But now I am not sure what you are asking for. Asking about CDN to Origi= n > using ESNI or ESNI with a client cert? > I'm wondering what the backhaul traffic from CDN to Origin looks like, even if a user-agent request to the CDN used ESNI. I noticed that many CDNs provide client certificates. In TLS handshakes that use a client certificate, it seems like the SNI might be able to be sent with the second message from the client (alongside the client certificate). thanks, Rob --00000000000063ab94059479af0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 7:31 PM Salz, = Rich <rsalz@akamai.com> wrote= :
  • A link from CDN to Origin is just a particularly easy-to-deploy use case, s= ince client certificates are already in wide use and IPv6 tends to work fla= wlessly.

=C2=A0

It does?=C2=A0 Gee, cool.

I was being sarcastic, not angry. I shouldn=E2=80=99= t have done so.

=C2=A0

But now I am not sure what you are asking for.=C2=A0= Asking about CDN to Origin using ESNI or ESNI with a client cert?


I'm wondering what the ba= ckhaul traffic from CDN to Origin looks like, even if a user-agent request = to the CDN used ESNI. I noticed that many CDNs provide client certificates.=

In TLS handshakes that use a client certificate, = it seems like the SNI might be able to be sent with the second message from= the client (alongside the client certificate).

th= anks,
Rob
=C2=A0
--00000000000063ab94059479af0a-- From nobody Wed Oct 9 05:51:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001E11200C3 for ; Wed, 9 Oct 2019 05:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swauYOLE2nHl for ; Wed, 9 Oct 2019 05:51:53 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 715BA120089 for ; Wed, 9 Oct 2019 05:51:53 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id n14so2338041ljj.10 for ; Wed, 09 Oct 2019 05:51:53 -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=yw8qfqhIBi3YLFzqeVHVMyAG7i4TnPoY1ZxLlJGzYzg=; b=yZ1eX6uz7fY4epA0A4RMrsWT7XjjE+v7QIQYAF7EDVXG8LpBwH9cv0gFdTDmpzScgc dktvcTOPtgrlzArWLygSqS8bgfKRXzJ2gOYNfPkMITkv1VF7olqGDBn/fsO9pXEebuGD c/LtdWfRbVZnDZU1sf2UZK925swpJw/jat9TgN5mSKcCSqIvSv76gg2tNbgL/a8AA415 WDXKZRw9yWdacyUp0FerkDt1djl1YR2CZGW9xMkFXcCfZ8r/K2MY+ZmRZRGuV4t4QTta /pVzx+vhAYVpkVgfVo3CEhOkNzBV8MyS3JK6iSv1nbXF7ThMS8D0Sl3qSbHrvMKAkIhH 76CQ== 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=yw8qfqhIBi3YLFzqeVHVMyAG7i4TnPoY1ZxLlJGzYzg=; b=jE9poSXsyJYcpYWgKS7E+nDmM6bLtg9mq83HksXuYTmBgbRyvZXmkPU+V54CXuULq0 kpYYnqtR1EzaOuVTnpPyY558D0sHw2svW5COe7qXkLVJ8+xz61w0G2D+NW3RrunkJlb/ WfEtMy4FwVK+urYuwlsWVaPwCTA9m3egPg2TnjT3qRpOT7P0N0F6TRPxOSP6az7Mbgo3 9/2eC+wvQFKo7ak0EOItk1lVS96u8Fo/neN4fmm4wkJFKs9QmMlH9JR/4JqImRkkRK9P /i+HuA7PROO8AGUroo/yZE49UP+6EJ4H8DCwt4H5Pbnaz0+YyKuThn0bFlnfoAyR2Nqe hagQ== X-Gm-Message-State: APjAAAWAoNdLpOs8RSA9rGYs7hc0VP0ttcm9MV/cdli3+rwf0gyKkjkG dM96dT3A0pY2z/s9h4RUI8MxAyka0e5oW0Vfqh2pRQ== X-Google-Smtp-Source: APXvYqx//6oFv0tADw2/KRqnYl9D0cQRtttUWBLdAP/LeyKa7Oh17YVv1MTKFBr8wBjweIRZkmfSqGpzTeKMddY9B68= X-Received: by 2002:a05:651c:237:: with SMTP id z23mr2236024ljn.93.1570625511551; Wed, 09 Oct 2019 05:51:51 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 05:51:15 -0700 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b10a46059479bfc0" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:51:56 -0000 --000000000000b10a46059479bfc0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 5:47 AM Rob Sayre wrote: > > > On Wed, Oct 9, 2019 at 7:31 PM Salz, Rich wrote: > >> >> - A link from CDN to Origin is just a particularly easy-to-deploy use >> case, since client certificates are already in wide use and IPv6 tend= s to >> work flawlessly. >> >> >> >> It does? Gee, cool. >> >> I was being sarcastic, not angry. I shouldn=E2=80=99t have done so. >> >> >> >> But now I am not sure what you are asking for. Asking about CDN to >> Origin using ESNI or ESNI with a client cert? >> > > I'm wondering what the backhaul traffic from CDN to Origin looks like, > even if a user-agent request to the CDN used ESNI. I noticed that many CD= Ns > provide client certificates. > > In TLS handshakes that use a client certificate, it seems like the SNI > might be able to be sent with the second message from the client (alongsi= de > the client certificate). > How would that work? The SNI is used by the server to determine what certificate to send. That's why it's sent in CH. -Ekr > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000b10a46059479bfc0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 5:47 AM Rob Sa= yre <sayrer@gmail.com> wrote:=


On Wed, Oct 9, 2019 at 7:31 PM Salz, Rich <rsalz@akamai.com> wr= ote:
  • A link from CDN to Origin is just a particularly easy-to-deploy use case, s= ince client certificates are already in wide use and IPv6 tends to work fla= wlessly.

=C2=A0

It does?=C2=A0 Gee, cool.

I was being sarcastic, not angry. I shouldn=E2=80=99= t have done so.

=C2=A0

But now I am not sure what you are asking for.=C2=A0= Asking about CDN to Origin using ESNI or ESNI with a client cert?


I'm wondering what the ba= ckhaul traffic from CDN to Origin looks like, even if a user-agent request = to the CDN used ESNI. I noticed that many CDNs provide client certificates.=

In TLS handshakes that use a client certificate, = it seems like the SNI might be able to be sent with the second message from= the client (alongside the client certificate).

How would that work? The SNI is used by the server t= o determine what certificate to send. That's why it's sent in CH.

-Ekr


thanks,
Rob
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000b10a46059479bfc0-- From nobody Wed Oct 9 05:55:09 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ECC12002E for ; Wed, 9 Oct 2019 05:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pzIAuHTWS89Z for ; Wed, 9 Oct 2019 05:55:06 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 D9AA81200D7 for ; Wed, 9 Oct 2019 05:55:05 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id b19so4714787iob.4 for ; Wed, 09 Oct 2019 05:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pWdtCmne1Z6QOk/jyk2pVmXoucwxBA5BMBjyFSrOygQ=; b=OoRpPF0cLcYcFWfPZc/KEtEmPiRav9EfX7BknVgQtCVT4pk8sen3g2POQzIRKOrDJW 2hY/S108WWdsKMXUVUT6TC5TPHu+M8tu1dYhCy7vscJpIP+3/Cnt5ydaABMy+hTrrs7x nO5Lxl4PU9gFV6U4DK9rVCfV/NCWs1Ns5L9SW39b1nwpP74hIbJWNzse+ZQCRlFvjor+ sIrb37fn5dWrfSNJgtkVnwwwg0qXS9S8cGB9qZAnPHRlHGIRkLl0bfKViEtH0rnxf5Tb yydr/eLZMDXj3sDJf+jDkY72ONKv61UzW1ecn8O79QFBV46Yh2L32JBqDP6FlqGv+5DY Zbgw== 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=pWdtCmne1Z6QOk/jyk2pVmXoucwxBA5BMBjyFSrOygQ=; b=AiyUEpxZSb2tv0OmRDOMzYesih0hzc/XmmiQCpB7cFI5FryYvd3s1MkloLtJxmDW7A sta7veelLhMA0tKzgZTGDGp2WtVYEuNIdh5licg9Nabg/OxTWygki1bA/EE40EebI1MR gpLy3qsZ4fcH0pQ2afM/bJJqYAnn3jZ8+SwFfZdm2xG5IpQjjdg0oA3bhSTnAe9mutZj DvsaNneYiZ2piPqIitVpyRA/OHN4wgP1DnVz1AZHM0l2mweJh3Fvjv4J3VjPOPmTAKWU Kwh+UVRERzlJwqD4SYZWxc0bdoM0mpEHl9sI6vs1cJXn80pAlDMgUfi+ARH8ucn3PXv8 2EWA== X-Gm-Message-State: APjAAAWe7MYZBdJ64E0KUO7xQXIKZJm0zayMOqXkT+c2PsmUB9iCp36L 6VMOWIXFemU5OCDXha8gu/wbV7E+iHzHCOxyCbo= X-Google-Smtp-Source: APXvYqw8O7vN4AM5+M28ruMiAB8pHaUV6kg6XZSPwHe8LIy5br+dOkK0U/c0WrWMHKtAi/O7/aahCrTY0MwfN4iJHEU= X-Received: by 2002:a92:9892:: with SMTP id a18mr2956895ill.189.1570625705101; Wed, 09 Oct 2019 05:55:05 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 19:54:53 +0700 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003a50ab059479cbf8" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:55:08 -0000 --0000000000003a50ab059479cbf8 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 7:51 PM Eric Rescorla wrote: > > How would that work? The SNI is used by the server to determine what > certificate to send. That's why it's sent in CH. > I understand why SNI is needed for IPv4 addresses. But, if I have Cloudflare (or any CDN) configured for a domain, and the origin is only available via IPv6, the need for a disambiguating SNI in the ClientHello from CDN to Origin is not clear. thanks, Rob --0000000000003a50ab059479cbf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 7:51 PM Eric Resco= rla <ekr@rtfm.com> wrote:

How wou= ld that work? The SNI is used by the server to determine what certificate t= o send. That's why it's sent in CH.
<= div>
I understand why SNI is needed for IPv4 addresses.
=

But, if I have Cloudflare (or any CDN) configured for a= domain, and the origin is only available via IPv6, the need for a disambig= uating SNI in the ClientHello from CDN to Origin is not clear.
thanks,
Rob=C2=A0
--0000000000003a50ab059479cbf8-- From nobody Wed Oct 9 05:56:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242941200C3 for ; Wed, 9 Oct 2019 05:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 Jxh5tsAcMKxS for ; Wed, 9 Oct 2019 05:56:32 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8CC12002E for ; Wed, 9 Oct 2019 05:56:32 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id z125so689493ybc.4 for ; Wed, 09 Oct 2019 05:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HM+zHlhi58i94Rric50G071V9/giQ7JHpqOIK0Wx690=; b=gNc/NG4dgwPfgZUkpKIVg7wQuc1/h+NHk1ivLKANyFCKWhTt4udn4wpg2qBUigFRnQ 924FlwhV4zdardDoELoka2HhwBU1+3EVo+ZinXMGyoOOxUJ2kPqau6Bl/OcFPXrIYlKD TdWFJTYabjTIuK5h3CAh7H1JhCOabSIYeygik= 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=HM+zHlhi58i94Rric50G071V9/giQ7JHpqOIK0Wx690=; b=ed7Z+ElmPbL0ZQqxJmDPKES5OSbQPfVXAeSLEnhcUvP5/xCD9q4wqwbXI3slFuGgrI XyonNroQICSmp8WJf9zIvBD3FkKgwFYt74dVkVjzyaRUyYo+0vyMvAHNB31JIuF6rx1Q 9FM/lr7Ou3a2u7047AscUnfSMwAwX7aaptRFsdZ7A7S6SMR8eE0QBDnSezs8KJZOAKze hVmF/9pxFF7sfclpYij2WLfKgobPwusVN6UGwS/WFJ14agkbtdiJ5CqudRmAN7+ryvKI 1dQeMZw4cY+JsahN+HYglm49HoD4BUbtIEXhIJb8IrFanXF9ANXL0tOTZ+s97SnVP8+4 vX8g== X-Gm-Message-State: APjAAAVfGAIEQ2sOGTQIlYAxGIjBx1Ap9EZYiBmsgR3bk8R+TePrZSKh f3iPD5AU1nHr/GBxOcptcWuyTENP6/9s0B+VewGNZQ== X-Google-Smtp-Source: APXvYqza2P6TeX8LngP1MxBdOdymyY5Y5ExaRcdf3Z5rSjam0azW6tEvIhX/XcrkkX6gDO4QgWFwm0+umEUMtBShU6E= X-Received: by 2002:a25:414f:: with SMTP id o76mr1712862yba.401.1570625791172; Wed, 09 Oct 2019 05:56:31 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> In-Reply-To: From: Kyle Rose Date: Wed, 9 Oct 2019 08:56:19 -0400 Message-ID: To: Rob Sayre Cc: Rich Salz , "" Content-Type: multipart/alternative; boundary="0000000000005bbb79059479d00d" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:56:34 -0000 --0000000000005bbb79059479d00d Content-Type: text/plain; charset="UTF-8" > > I'm wondering what the backhaul traffic from CDN to Origin looks like, > even if a user-agent request to the CDN used ESNI. I noticed that many CDNs > provide client certificates. > Some origins do require client certificates, but not all. This is up to the customer. In TLS handshakes that use a client certificate, it seems like the SNI > might be able to be sent with the second message from the client (alongside > the client certificate). > As I alluded to in the footnote from my last reply, I'm not sure how much value this would have since the identity of the origin is typically evident from the destination IP. Kyle > --0000000000005bbb79059479d00d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm wondering wh= at the backhaul traffic from CDN to Origin looks like, even if a user-agent= request to the CDN used ESNI. I noticed that many CDNs provide client cert= ificates.
<= br>
Some origins do require client certificates, but= not all. This is up to the customer.

In TLS handshakes that use a = client certificate, it seems like the SNI might be able to be sent with the= second message from the client (alongside the client certificate).

As I alluded to in the footnote from my last reply, I'm not s= ure how much value this would have since the identity of the origin is typi= cally evident from the destination IP.

Kyle
=
--0000000000005bbb79059479d00d-- From nobody Wed Oct 9 05:59:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9414C1200FB for ; Wed, 9 Oct 2019 05:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 9LZ0ScMTG1s8 for ; Wed, 9 Oct 2019 05:59:15 -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 E5F4B1200C3 for ; Wed, 9 Oct 2019 05:59:14 -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 x99Cv3lH004802; Wed, 9 Oct 2019 13:59:10 +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=VkFHRO3wmZpTYy4lHLvCd6fvfLfyEq0XQ3wLwbE6oK0=; b=PFdnb8HouCfzVl6vLQeYUCjauPKgWhZquUPxz6OwXiQ/sgOWhjn0X+GHPw+0vgn69de8 Lmno4egJy98JKObgn1iGKYoD3aHANUNFgj6tes+yRnTc/pRPj7q9fUa3MPWwLhV0Cypw OIiprd/L4WyNjt+Tt11gvKOnpIKHHG6Oq9Jtqohd+OY+/8IuqQ90jTrxClThFB3VvOHY UaDT3yDCBuoFs3kvsK0IWZx9pqjF4UXuXmFHFHtBpSisdd5gyvunDeOUs7MndwfQMngn egisxjz6XvEP8dujS0TyVkwOIx6cue+BlsGXU11xkAjUJRDC+C5RLSKeEhQNTgZEu9vW 6Q== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vekk8uu16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 13:59:10 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x99ClKjY029412; Wed, 9 Oct 2019 08:59:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint3.akamai.com with ESMTP id 2vepgyy529-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 08:59:09 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 07:59:07 -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.1473.005; Wed, 9 Oct 2019 07:59:07 -0500 From: "Salz, Rich" To: Rob Sayre , Eric Rescorla CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAIAARAMA///HFYCAAEduAIAAASmAgAABBID//74fAA== Date: Wed, 9 Oct 2019 12:59:06 +0000 Message-ID: <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.214] Content-Type: multipart/alternative; boundary="_000_83192EC86A24463880AC6D2AF9C68BBBakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-09_05:, , 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=683 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910090122 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-09_05:2019-10-08,2019-10-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 spamscore=0 suspectscore=0 phishscore=0 mlxlogscore=654 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090124 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 12:59:17 -0000 --_000_83192EC86A24463880AC6D2AF9C68BBBakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQnV0LCBpZiBJIGhhdmUgQ2xvdWRmbGFyZSAob3IgYW55IENETikgY29uZmlndXJlZCBm b3IgYSBkb21haW4sIGFuZCB0aGUgb3JpZ2luIGlzIG9ubHkgYXZhaWxhYmxlIHZpYSBJUHY2LCB0 aGUgbmVlZCBmb3IgYSBkaXNhbWJpZ3VhdGluZyBTTkkgaW4gdGhlIENsaWVudEhlbGxvIGZyb20g Q0ROIHRvIE9yaWdpbiBpcyBub3QgY2xlYXIuDQoNClRoYXQgYXNzdW1lcyB0aGF0IHRoZXJlIGlz IGEgb25lLXRvLW9uZSBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIGFuIG9yaWdpbiBhbmQgaXRzIGNl cnRpZmljYXRlLCB3aGljaCBpc27igJl0IHRydWUuICBJIG1pZ2h0IGhhdmUg4oCcYXBpLmV4YW1w bGUuY29t4oCdIGFuZCDigJxuZXctYXBpLmV4YW1wbGUuY29t4oCdIGF0IHRoZSBzYW1lIElQIGFk ZHJlc3MuDQoNCg== --_000_83192EC86A24463880AC6D2AF9C68BBBakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <2553BF1FDF5D5849B030F1D2BB44A4AE@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NTg5MTQ4MDI7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMDc3MDI2MDYgLTE1OTIyMjUzMjQg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDow Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1hbnNpLWZv bnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+QnV0LCBpZiBJIGhhdmUg Q2xvdWRmbGFyZSAob3IgYW55IENETikgY29uZmlndXJlZCBmb3IgYSBkb21haW4sIGFuZCB0aGUg b3JpZ2luIGlzIG9ubHkgYXZhaWxhYmxlIHZpYSBJUHY2LCB0aGUgbmVlZCBmb3IgYSBkaXNhbWJp Z3VhdGluZyBTTkkgaW4gdGhlIENsaWVudEhlbGxvIGZyb20gQ0ROIHRvIE9yaWdpbiBpcw0KIG5v dCBjbGVhci48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYXQgYXNzdW1lcyB0aGF0IHRoZXJlIGlzIGEgb25lLXRvLW9uZSBjb3JyZXNwb25kZW5j ZSBiZXR3ZWVuIGFuIG9yaWdpbiBhbmQgaXRzIGNlcnRpZmljYXRlLCB3aGljaCBpc27igJl0IHRy dWUuJm5ic3A7IEkgbWlnaHQgaGF2ZSDigJxhcGkuZXhhbXBsZS5jb23igJ0gYW5kIOKAnG5ldy1h cGkuZXhhbXBsZS5jb23igJ0gYXQgdGhlIHNhbWUgSVAgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_83192EC86A24463880AC6D2AF9C68BBBakamaicom_-- From nobody Wed Oct 9 06:04:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992A2120106 for ; Wed, 9 Oct 2019 06:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, 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 o-dwLC4sZOTX for ; Wed, 9 Oct 2019 06:04:12 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848D91200FB for ; Wed, 9 Oct 2019 06:04:12 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z19so4840630ior.0 for ; Wed, 09 Oct 2019 06:04:12 -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=6PCIabYOQEQW1tzH2LdnenZf3Fcl6fHp8HeGISLZJmc=; b=lqKqME9yfzT7LkOcYYLOg4UmRSTuv88qxUmsHUysTiU5zP6o1W3DAbhxwIZ0VNWie5 zOMUb4+HVQgikD+jMiGnbdMi4guGvEtxAAB7rMoRrWgMkY+oFLASvXeOamsPz8qeY3yG pHkKoppAVE5YBWnuEptCzHr3z/tHafm30TxBhAPDL4iufBCTa9CpmfmMZw/CIhL+Fwl9 jntBkQ28iK962e+t/eO4mZGsK3VTD+slx8bwaZWXcw0yZJbAQHz2ZWopRoJ64BLUPeUG tV5hZ/I2FqlvHxjV4PHagAt9tIBEkquw37uK0oG/m+8J3nFwwjJcZXHV6M85aJr0WnBI pvHg== 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=6PCIabYOQEQW1tzH2LdnenZf3Fcl6fHp8HeGISLZJmc=; b=njXHk0STeH3ibzHm0+P2s0ytr71q2Na5gSXWA/KUZLyuQRucHBxpaKvGMrn4UStUZg MyFUqHFgKIeuDmPQFlGbpuJDeMLOvYDJSu/smRooJOU33H5J8UnL8PuDbAJ3tuFVED0G FrwQh2A0R5v/CE4gPOJE2IspKka+Mo6oY7FKFMZNmzDXPHA03GM9ZiZI6WZP7VwG6SeG bqTjhicy/F6btvVN2TjdtvkYYWro8IOvsLHbtUMbkbvg3o7GsU4ivxBGd4F2jl4hsb0s C0pbyX6kaMWMZJg296U6MlS/ofwcNSIyI1ui6h3sEgGtLjgQ9J6YwR6azQZnAdjqAfQh 0hzA== X-Gm-Message-State: APjAAAVwFvGuYvUu/0SUXwVEXcbPHadIcNkRZAmjNquDi6o99jJgjJmP QOCmmLpGICgwhJyWYRhY4axUkyjQSFgQVuuLrDk= X-Google-Smtp-Source: APXvYqxbWP2K9SmTQmC/Bp+Q4BecKnAWjVyCBBQt0hLUMgbTv7ZAis32k4It/+HYA/vMHVR3darI77gTXSQ5P5pobXs= X-Received: by 2002:a5e:9b0b:: with SMTP id j11mr3011747iok.189.1570626251820; Wed, 09 Oct 2019 06:04:11 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> From: Rob Sayre Date: Wed, 9 Oct 2019 20:04:00 +0700 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d0922f059479ebc5" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 13:04:15 -0000 --000000000000d0922f059479ebc5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 7:59 PM Salz, Rich wrote: > > - But, if I have Cloudflare (or any CDN) configured for a domain, and > the origin is only available via IPv6, the need for a disambiguating S= NI in > the ClientHello from CDN to Origin is not clear. > > > > That assumes that there is a one-to-one correspondence between an origin > and its certificate, which isn=E2=80=99t true. I might have =E2=80=9Capi= .example.com=E2=80=9D > and =E2=80=9Cnew-api.example.com=E2=80=9D at the same IP address. > I don't think that's quite what I'm proposing. I'm proposing (optionally) sending the SNI with a client certificate. I agree that SNI in ClientHello is needed to choose server certificates for IPv4, for the reason you say. thanks, Rob --000000000000d0922f059479ebc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 7:59 PM Salz, Rich= <rsalz@akamai.com> wrote:
  • But, if I have Cloudflare (or any CDN) configured for a domain, a= nd the origin is only available via IPv6, the need for a disambiguating SNI= in the ClientHello from CDN to Origin is not clear.

=C2=A0

That assumes that there is a one-to-one corresponden= ce between an origin and its certificate, which isn=E2=80=99t true.=C2=A0 I= might have =E2=80=9Ca= pi.example.com=E2=80=9D and =E2=80=9Cnew-api.example.com=E2=80=9D at the same IP addr= ess.


I don't thin= k that's quite what I'm proposing. I'm proposing (optionally) s= ending the SNI with a client certificate. I agree that SNI in ClientHello i= s needed to choose server certificates for IPv4, for the reason you say.

thanks,
Rob=C2=A0
--000000000000d0922f059479ebc5-- From nobody Wed Oct 9 06:04:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA5A12010C for ; Wed, 9 Oct 2019 06:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 dg54XDB6BjZN for ; Wed, 9 Oct 2019 06:04:47 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85EA12010E for ; Wed, 9 Oct 2019 06:04:46 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id w6so1615042lfl.2 for ; Wed, 09 Oct 2019 06:04:46 -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=iHVhl7veIYFyvCr17xY8VgE+CSX9K8s0M8NEfbAsq0Y=; b=HOWviSJfP0bDplgzjXlZ/GcJEp4JEyALZaWES6P0y96Mrv9orUfCgKlEZRlhfppcJm Ft46RIiiDGy56p0kAKwgrfwnfIFryIrrXK+J+n7xly0kguqNk4xvqYywcjQ2T53xXMXh d1LQ08sqxOLq/PuuCgfyPRXnfUFHxQDhY/WlBryOUHCgOa0ivsgYc47slGNxyF2WFVmx LWEX7hL8slMLneguRDW7TvElnO8QlJ+DseHF3qhdmVUedeHKETF7TMoivr/G4esAQfQA IZzbPgmux3KcPcBi1+uhsqm3cXGr1hRMGKlgAJJwn18xyEC4qw9d0fJ3vFFtDbwNC3Ry lzsg== 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=iHVhl7veIYFyvCr17xY8VgE+CSX9K8s0M8NEfbAsq0Y=; b=Wk54u3Ccwn/de7FV04PVM+nU4bvtBZGkHFS4vvl3uXBlcrEkmuqjBN7nBUek08C1S9 4CC4gAddq2bxoov96zza7K8KhHDwnhuyjK11NsM5oZ6btVFKxF19xucIwbySOIpmArcc lsKiBIiqMkdaDASm5KIBY6qCb0hHHu3icTw+Uk32LZbAIZ450X5nlQhJ6FJhqC8bz5o+ RBW4tEKL1uK7SrO4MwHKne+NQj0iqyXXyYcvS6H76Pg/laxMyYy7zMv3IJgkDU75h1Ot xWXOcgg3iD2xK+xP9vTaVz+YNSLZzUXGhFAUbDmISnaSk94lmRYOOB0FmS3qGbW1lSd4 4AGg== X-Gm-Message-State: APjAAAUOPtLa4h1clDUUt4+DauNIgiEWQvU6saB1nf64KJHVP2o981XQ FtxsdoXasXHHr0z6YEzGN45ahj3lloi58/seCibBBg== X-Google-Smtp-Source: APXvYqwUTW5F1nsPOGYnHAH+3BvqI+X6RSagNv08H+digXVEw1gasWmM+uWxmhRFqQR6MapIyKD8Ri0LPeId5xXOZBY= X-Received: by 2002:a19:23cc:: with SMTP id j195mr2030473lfj.91.1570626284830; Wed, 09 Oct 2019 06:04:44 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 06:04:08 -0700 Message-ID: To: Rob Sayre Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000c85664059479ed62" Archived-At: Subject: Re: [TLS] Publication has been requested for 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, 09 Oct 2019 13:04:50 -0000 --000000000000c85664059479ed62 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 5:28 AM Rob Sayre wrote: > On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla wrote: > >> >>> 1) it doesn't seem like a particularly valid claim to say that the >>> document "doesn't pull" in DTLS 1.0 when the rationale for that claim is a >>> missing reference. >>> >> >> Well I suppose you're entitled to your opinion, but no, I don't think >> that's true. We have a very specific meaning for normative dependency and >> in no way would this be one. At most this would be an informative reference. >> >> In any case, this is not the proper place for this discussion. If you >> want this document changed, you'll need to take it to the RTCWEB WG. >> > > Honestly, thank you for the sincere response. > > After I read more of the many relevant documents, it became clear > that draft-ietf-tls-oldversions-deprecate says implementations MUST NOT > negotiate DTLS 1.0, while RFC 6347 and draft-ietf-rtcweb-security-arch > encourage negotiation that results in endpoints agreeing on DTLS 1.0. > We should take 6347 and draft-ietf-rtcweb-security-arch separately. When we have protocol version X and we introduce X+1, we're almost never saying "you shouldn't negotiate X", because that would totally break the transition story. Rather, we're saying "X and X+1 can coexist". Then, once X+1 becomes sufficiently popular that you no longer need to support X, we can say "you shouldn't even support X" (whether we should say that depends on the details of X). So, 6347 was totally reasonable at the time and I expect the guidance in this document to override 6347 which all seems quite normal. draft-ietf-rtcweb-security arch doesn't precisely encourage you to implement DTLS 1.0; there's no normative language at all (even in the non-2119 sense). It makes s factual statement about the history of the document and about the impact of implementing only DTLS 1.2 and leaves it up to the implementor what to do with that statement. I agree that the fact that it bothers to mention it might be read as implying that people should do DTLS 1.0, but that's not actually in the text. Indeed, I could imagine this document including both this text *and* a MUST NOT implement DTLS 1.0 (that's actually how one has to interpret the union of draft-ietf-rtcweb-security-arch and draft-ietf-tls-oldversions-deprecate), with the understanding that the point of the "might encounter interoperability issues" is to document the impact of the MUST NOT requirement. With that said, as I mentioned in my earlier response, it was understood when we adopted this draft that this was kind of a 6119 "MUST (but we know you won't)" situation. See, for instance. the comments from DKG in the minutes here: "DKG: we can afford to publish this without driving numbers down to zero. Multiple audiences for documents like this, can make sure this is useful for many audiences. Clear advice for implementers: can't remove entirely, but here are things you can do. We publish this now to drive adoption, not wait for adoption to drive" https://datatracker.ietf.org/meeting/102/materials/minutes-102-tls-11 -Ekr --000000000000c85664059479ed62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 5:28 AM Rob Sa= yre <sayrer@gmail.com> wrote:=
On Wed, Oct 9, 2019 at 7:20 PM Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>

1) it doesn't seem like a particularly = valid claim to say that the document "doesn't pull" in DTLS 1= .0 when the rationale for that claim is a missing reference.

Well I suppose you're entitle= d to your opinion, but no, I don't think that's true. We have a ver= y specific meaning for normative dependency and in no way would this be one= . At most this would be an informative reference.

= In any case, this is not the proper place for this discussion. If you want = this document changed, you'll need to take it to the RTCWEB WG.

Honestly, thank you for the sinc= ere response.

After I read more of the many releva= nt documents, it became clear that=C2=A0draft-ietf-tls-oldversions-deprecat= e says implementations MUST NOT negotiate DTLS 1.0, while RFC=C2=A06347 and= draft-ietf-rtcweb-security-arch encourage=C2=A0negotiation that results in= endpoints agreeing on DTLS 1.0.

We should take 6347 and draft-ietf-rtcweb-security-arch separately.=

When we have protocol version X and we introduce = X+1, we're almost never saying "you shouldn't negotiate X"= ;, because that would totally break the transition story. Rather, we're= saying "X and X+1 can coexist". Then, once X+1 becomes sufficien= tly popular that you no longer need to support X, we can say "you shou= ldn't even support X" (whether we should say that depends on the d= etails of X). So, 6347 was totally reasonable at the time and I expect the = guidance in this document to override 6347 which all seems quite normal.

draft-ietf-rtcweb-security arch doesn't precisel= y encourage you to implement DTLS 1.0; there's no normative language at= all (even in the non-2119 sense). It makes s factual statement about the h= istory of the document and about the impact of implementing only DTLS 1.2 a= nd leaves it up to the implementor what to do with that statement. I agree = that the fact that it bothers to mention it might be read as implying that = people should do DTLS 1.0, but that's not actually in the text. Indeed,= I could imagine this document including both this text *and* a MUST NOT im= plement DTLS 1.0 (that's actually how one has to interpret the union of= draft-ietf-rtcweb-security-arch and draft-ietf-tls-oldversions-deprecate),= with the understanding that the point of the "might encounter interop= erability issues" is to document the impact of the MUST NOT requiremen= t.

With that said, as I mentioned in my earlier re= sponse, it was understood when we adopted this draft that this was kind of = a 6119 "MUST (but we know you won't)" situation. See, for ins= tance. the comments from DKG in the minutes here:

= "DKG: we can afford to publish this without driving numbers down to ze= ro. Multiple audiences for documents like this, can make sure this is usefu= l for many audiences. Clear advice for implementers: can't remove entir= ely, but here are things you can do. We publish this now to drive adoption,= not wait for adoption to drive" https://datatracker.ietf.org/m= eeting/102/materials/minutes-102-tls-11

-Ekr






--000000000000c85664059479ed62-- From nobody Wed Oct 9 06:06:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253611200FB for ; Wed, 9 Oct 2019 06:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4MVeFyQ21Td for ; Wed, 9 Oct 2019 06:06:17 -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 E609C1200C3 for ; Wed, 9 Oct 2019 06:06:16 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id w67so1612582lff.4 for ; Wed, 09 Oct 2019 06:06:16 -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=H04BwD735n8JbI7Q2dUq5vnxFUglY+n8NFq77g6flQQ=; b=wF/54CtcRGrqeVMLm1Ozwlz9zx6v5DVsrwTbyZrqB6ss/gOhgQTjtIEOg+cEZONbo5 BEa7u4Q1K4tjxdsvfwkgzdERRe6uJ9E8XZpcBWgCi5hZui/Z+DbnNn9MkDvf7YPN+C3q 0453QIZiW7z2aCjh++b/b+4NgeySqTpfbiPfVgkg/hzYK5rv0jlXtaUv3liJO2wMO6zM rBvW41t3oKupIf5SGjI2ntTZpoycFJzl1k5dcgroA9SuzA4on+5Ne/oSrDHo06Byqh0+ AHE1euKWEKec8cfyvQkVE/1RKupLC8XO7bFQKKOaFiufHh7l3q4MZEqqwAYIO+BMilYL AYTA== 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=H04BwD735n8JbI7Q2dUq5vnxFUglY+n8NFq77g6flQQ=; b=n2mK9E9l2R8WqsZLsgyGXMeqqxo/aFEbKahfYvY92G5aZ+kmPLHVL9Zfq5fKXW2hSb 9dJs5ZtcN0ufBXhGFEcS3wQY8EpF+adJ7CEOEy3VYOSf6nv6R4Q3VHiELE8SI6Bojy4N sNItLrx4u0hjKaCzicqtUziOxxNNHab8AQd7b3tCNd8qlGMp8f4FkGXn/C+VcrL9Zc+d c555BRaTNLT9DjBM4dm5QObtik7TKXphMNS2g7Vz0AMHIfbqnXFX2WMemfd/tXx7MOWZ AN+dv8LE0xhgNV4+ZbCMHvQpTa2VzQc12uHzHo/cnSG4uAR5zkZ92NVgrYo02LYc/VmX uvWA== X-Gm-Message-State: APjAAAUf/hAeaL1EwwylOoZbmRWUlVGCptci8AJ7Q/fRaA66r9CV74dJ f3Ih1WJVn8GcGT3XKlA3evOtKffcn9q1JOBpPr1Xig== X-Google-Smtp-Source: APXvYqzGXw1oQxJr70xtlW/G2dxC2mueoukEczYgf6CFhXwoYOiFmrEVTlSwoWGtH4aV8R2TYHcHs6K+AaHJVQ7EkUM= X-Received: by 2002:ac2:4a75:: with SMTP id q21mr2039787lfp.94.1570626375218; Wed, 09 Oct 2019 06:06:15 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 06:05:38 -0700 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b8eaa059479f330" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 13:06:19 -0000 --0000000000002b8eaa059479f330 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 6:04 AM Rob Sayre wrote: > On Wed, Oct 9, 2019 at 7:59 PM Salz, Rich wrote: > >> >> - But, if I have Cloudflare (or any CDN) configured for a domain, and >> the origin is only available via IPv6, the need for a disambiguating = SNI in >> the ClientHello from CDN to Origin is not clear. >> >> >> >> That assumes that there is a one-to-one correspondence between an origin >> and its certificate, which isn=E2=80=99t true. I might have =E2=80=9Cap= i.example.com=E2=80=9D >> and =E2=80=9Cnew-api.example.com=E2=80=9D at the same IP address. >> > > I don't think that's quite what I'm proposing. I'm proposing (optionally) > sending the SNI with a client certificate. > What are you trying to accomplish by doing that? -Ekr I agree that SNI in ClientHello is needed to choose server certificates for > IPv4, for the reason you say. > > thanks, > Rob > --0000000000002b8eaa059479f330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 6:04 AM Rob Sa= yre <sayrer@gmail.com> wrote:=
On Wed, Oct 9, 2019 at 7:59 PM Salz, Rich <rsalz@akamai.com> wrote:=
  • But, if I have Cloudflare (or any CDN) config= ured for a domain, and the origin is only available via IPv6, the need for = a disambiguating SNI in the ClientHello from CDN to Origin is not clear.

=C2=A0

That assumes that there is a one-to-one corresponden= ce between an origin and its certificate, which isn=E2=80=99t true.=C2=A0 I= might have =E2=80=9Ca= pi.example.com=E2=80=9D and =E2=80=9Cnew-api.example.com=E2=80=9D at the same IP addr= ess.


I don't thin= k that's quite what I'm proposing. I'm proposing (optionally) s= ending the SNI with a client certificate.

What are you trying to accomplish by doing that?

-Ekr


I agree that SNI in ClientHello is needed to choose server certi= ficates for IPv4, for the reason you say.

thanks,<= /div>
Rob=C2=A0
--0000000000002b8eaa059479f330-- From nobody Wed Oct 9 06:09:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188BD1200FB for ; Wed, 9 Oct 2019 06:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 WCJBzTSI1JAB for ; Wed, 9 Oct 2019 06:09:30 -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 5D4B81200C3 for ; Wed, 9 Oct 2019 06:09:30 -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 x99D7R0g011135; Wed, 9 Oct 2019 14:09:29 +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=yEC8lyZ0STjAht1eRu+s334B6nXZ1FOG7wJf4nn0LHU=; b=BmAY32+YKVDBdwNNLj3O9kg909Lto3aIl/coNKGkfwpqXQW4BScP2QRSVtuuom53HKzm y9amPVBRSHfFoYrI6u9w9pDDIawz86AR4btOR21oQLNnjAv1as+ibdBSURmlvF8Zql7k abpxE1Oi3Mp89Lqm6TQe9lslgKzxUgXMcJ/+ZpgEMDHL0MIgvWDiM01yV9zfjTbSZ4Bz SZZKkjDHY1uCRz4ek2Jf7A3oe7yiyqXLeP/2vo7Lr8vnwenXPJRfZDzh76YCbIwLtzjm Ygd0y/zPqYkiT8/zVI/fdR9cilEH3slyvBYAysNmYIOV/f2iFxphe1PSza7E7Fi8o9e2 dQ== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vejq4xsx0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 14:09:28 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x99D39fO013734; Wed, 9 Oct 2019 09:09:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint7.akamai.com with ESMTP id 2veph0cwgj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Oct 2019 09:09:26 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 9 Oct 2019 08:09:25 -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.1473.005; Wed, 9 Oct 2019 08:09:25 -0500 From: "Salz, Rich" To: Rob Sayre CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAIAARAMA///HFYCAAEduAIAAASmAgAABBID//74fAIAARG0A//++dAA= Date: Wed, 9 Oct 2019 13:09:24 +0000 Message-ID: <0F7FB959-CE62-4444-91BD-00956B7B2C61@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.214] Content-Type: multipart/alternative; boundary="_000_0F7FB959CE62444491BD00956B7B2C61akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-09_05:, , 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=890 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910090124 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-09_05:2019-10-08,2019-10-09 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 adultscore=0 mlxlogscore=875 spamscore=0 clxscore=1015 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910090125 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 13:09:32 -0000 --_000_0F7FB959CE62444491BD00956B7B2C61akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBkb24ndCB0aGluayB0aGF0J3MgcXVpdGUgd2hhdCBJJ20gcHJvcG9zaW5nLiBJJ20g cHJvcG9zaW5nIChvcHRpb25hbGx5KSBzZW5kaW5nIHRoZSBTTkkgd2l0aCBhIGNsaWVudCBjZXJ0 aWZpY2F0ZS4gSSBhZ3JlZSB0aGF0IFNOSSBpbiBDbGllbnRIZWxsbyBpcyBuZWVkZWQgdG8gY2hv b3NlIHNlcnZlciBjZXJ0aWZpY2F0ZXMgZm9yIElQdjQsIGZvciB0aGUgcmVhc29uIHlvdSBzYXku DQoNCkkgZGlkbuKAmXQgc2F5IElQdjQuICBJIG1pZ2h0IGhhdmUgYWxsIG15IOKAnHZpcnR1YWwg b3JpZ2luc+KAnSBiZWhpbmQgYSBzaW5nbGUgSVAgYWRkcmVzcywgb3IgYSBjb3VwbGUgb2YgdGhl bS4NCg0K --_000_0F7FB959CE62444491BD00956B7B2C61akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9E321119C2E05C45AF05317AA20B4CDB@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tLTM0NzY0NTUxMzg4NTcwNzI1 NTJtc29saXN0cGFyYWdyYXBoLCBsaS5nbWFpbC1tLTM0NzY0NTUxMzg4NTcwNzI1NTJtc29saXN0 cGFyYWdyYXBoLCBkaXYuZ21haWwtbS0zNDc2NDU1MTM4ODU3MDcyNTUybXNvbGlzdHBhcmFncmFw aA0KCXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXy0zNDc2NDU1MTM4ODU3MDcyNTUybXNvbGlzdHBh cmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjA4NDY0 NDczOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzU1 NDA3NjE0IDQ3NDg5MjMxNiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEwMjAwODUzOTE7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0xMzU0MzE5NDA4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+SSBkb24ndCB0aGluayB0aGF0J3MgcXVpdGUgd2hh dCBJJ20gcHJvcG9zaW5nLiBJJ20gcHJvcG9zaW5nIChvcHRpb25hbGx5KSBzZW5kaW5nIHRoZSBT Tkkgd2l0aCBhIGNsaWVudCBjZXJ0aWZpY2F0ZS4gSSBhZ3JlZSB0aGF0IFNOSSBpbiBDbGllbnRI ZWxsbyBpcyBuZWVkZWQgdG8gY2hvb3NlIHNlcnZlciBjZXJ0aWZpY2F0ZXMNCiBmb3IgSVB2NCwg Zm9yIHRoZSByZWFzb24geW91IHNheS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZGlkbuKAmXQgc2F5IElQdjQuJm5ic3A7IEkgbWlnaHQgaGF2ZSBhbGwgbXkg4oCcdmly dHVhbCBvcmlnaW5z4oCdIGJlaGluZCBhIHNpbmdsZSBJUCBhZGRyZXNzLCBvciBhIGNvdXBsZSBv ZiB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0F7FB959CE62444491BD00956B7B2C61akamaicom_-- From nobody Wed Oct 9 06:43:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A40120115 for ; Wed, 9 Oct 2019 06:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=alipay.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-uoGbihnzKE for ; Wed, 9 Oct 2019 06:43:34 -0700 (PDT) Received: from out0-136.mail.aliyun.com (out0-136.mail.aliyun.com [140.205.0.136]) (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 D4A2C12010C for ; Wed, 9 Oct 2019 06:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1570628603; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; bh=s0Xics7B7ZpQS3iVTcxZUQWI1QNjm7ScZZEfnbHiDz0=; b=TJiQ7GWuddjDD9R2jIiJApbGr6lJ+MkS9hiwTHzXZhyQFI4sn/AGs3q3CAlT6dRMajuGGnh6bTHNvY3Dho1NUOff64A3aF6fs8PkaHdsyu97cGQY7zZjsNuBGXSKGI+djKqy8/mg3xMVwDsmEy8G/8P5aWRpEbz0bSLV655lYtE= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R621e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03303; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FiJVSNU_1570628600; Received: from 30.27.196.20(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.FiJVSNU_1570628600) by smtp.aliyun-inc.com(127.0.0.1); Wed, 09 Oct 2019 21:43:21 +0800 From: Paul Yang Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FCEA78EF-7CDB-4B92-8AE0-16B6A52D667D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 9 Oct 2019 21:43:18 +0800 In-Reply-To: Cc: Rich Salz , "TLS@ietf.org" To: Rob Sayre References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 13:43:36 -0000 --Apple-Mail=_FCEA78EF-7CDB-4B92-8AE0-16B6A52D667D Content-Type: multipart/alternative; boundary="Apple-Mail=_54DEA8AC-F8DC-43AD-9A86-728CCAB77BC8" --Apple-Mail=_54DEA8AC-F8DC-43AD-9A86-728CCAB77BC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2019, at 9:04 PM, Rob Sayre wrote: >=20 > On Wed, Oct 9, 2019 at 7:59 PM Salz, Rich > wrote: > But, if I have Cloudflare (or any CDN) configured for a domain, and = the origin is only available via IPv6, the need for a disambiguating SNI = in the ClientHello from CDN to Origin is not clear. >=20 >=20 > That assumes that there is a one-to-one correspondence between an = origin and its certificate, which isn=E2=80=99t true. I might have = =E2=80=9Capi.example.com =E2=80=9D and = =E2=80=9Cnew-api.example.com =E2=80=9D at = the same IP address. >=20 >=20 > I don't think that's quite what I'm proposing. I'm proposing = (optionally) sending the SNI with a client certificate. I agree that SNI = in ClientHello is needed to choose server certificates for IPv4, for the = reason you say. Are you suggesting: =E2=80=9CIn an IPv6 backend/origin scenario, the SNI = should be sent along with client certificate instead of within = ClientHello message=E2=80=9D? =46rom my understandings, either IPv4 or IPv6 should have nothing to do = with the concept =E2=80=9Cvirtual host=E2=80=9D, so a client (say, a CDN = node) connects to either an IPv4/IPv6 server (say, an origin server), = the SNI should applies the same in the TLS layer. >=20 > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Regards, Paul Yang --Apple-Mail=_54DEA8AC-F8DC-43AD-9A86-728CCAB77BC8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 9, 2019, at 9:04 PM, Rob Sayre <sayrer@gmail.com> = wrote:

On Wed, Oct 9, 2019 = at 7:59 PM Salz, Rich <rsalz@akamai.com> wrote:
  • But, if I have Cloudflare (or any CDN) = configured for a domain, and the origin is only available via IPv6, the = need for a disambiguating SNI in the ClientHello from CDN to Origin is not clear.

 

That assumes that there is a = one-to-one correspondence between an origin and its certificate, which = isn=E2=80=99t true.  I might have =E2=80=9Capi.example.com=E2=80=9D and =E2=80=9Cnew-api.example.com=E2=80=9D at the same IP = address.


I don't think that's quite what I'm = proposing. I'm proposing (optionally) sending the SNI with a client = certificate. I agree that SNI in ClientHello is needed to choose server = certificates for IPv4, for the reason you = say.

Are you suggesting: =E2=80=9CIn an IPv6 = backend/origin scenario, the SNI should be sent along with client = certificate instead of within ClientHello message=E2=80=9D?

=46rom my understandings, either IPv4 or IPv6 = should have nothing to do with the concept =E2=80=9Cvirtual host=E2=80=9D,= so a client (say, a CDN node) connects to either an IPv4/IPv6 server = (say, an origin server), the SNI should applies the same in the TLS = layer.


thanks,
Rob 
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


Regards,

Paul Yang

= --Apple-Mail=_54DEA8AC-F8DC-43AD-9A86-728CCAB77BC8-- --Apple-Mail=_FCEA78EF-7CDB-4B92-8AE0-16B6A52D667D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl2d4/YACgkQ5HtIVEj/ IsplNg/9FfLtYRK/SrpuIVFN0Ln91uFJLOJNszjz9edULZEsQk0bREh7MoUOxmLT GVHmhH3KWfOCFORIrLDNfLj/FPI9HggF/G5oc1CKIgMvg3v7oFqftvCIsuRl7U8K dZNmp8PjuM3RBe9yffFNXYyYPnF4d8N+ALPW98FzQ83xthnBVh7rcKKUStG4o11D Xc7fDDNgGeq4ObfCz7jTpj5ZP/hrwloFxmYk1YLj/iuaW0BET6skT2EAQZdAU9/h H5PPPDz/6LyhfepMuMImCWhfHupkRRPMSc1R8hWrP6Z5vZo+vJ6iaRH0hx2uqf+q 7epTgu/0/mNmPCEa3VOSn/f+KllfzhppMbUBIu9aLYtXF8k/JT5NSdqAJQpG4Bhe YfeWMlHB8bmXDoWhpTqlvy3hl0qs1sjViCCQlQQnC2tCogAVfa07euFB55XY83u4 X65cOCwHFC6HAJuDiaID/IY2Tz35hHn5TNmbjpE/+lm9hJGL63vyAZUuI4I9r4NV 15zsL30rW58CY/ENxbvOFZ3RGuVPzUkM/ngLCFjctOCR9NqCFxRYhLzVUFiXG6SR FBZdyl6Q0DmtYOdNzjfAIMgDj/DytRQ9XSYABiE1iENXOiMTCDD6tjOctWgJDQu3 CUEMW1byqFFEq4+QZK+3F0/DZ8qf8KAI5XQz7dGUPUaOtRT5qCE= =DJFZ -----END PGP SIGNATURE----- --Apple-Mail=_FCEA78EF-7CDB-4B92-8AE0-16B6A52D667D-- From nobody Wed Oct 9 06:46:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E9012011D for ; Wed, 9 Oct 2019 06:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9oBJlkpfRyQQ for ; Wed, 9 Oct 2019 06:46:46 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 57CFD120115 for ; Wed, 9 Oct 2019 06:46:46 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id c25so4982980iot.12 for ; Wed, 09 Oct 2019 06:46:46 -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=5IVhoqZQBI1GGY8Q/zxeWajkFfFnMe2wwJAZK4MFlUo=; b=l1rq6A0jmHYrz81Pr7Xq3Jn7y2LQRJOHpTMnd1Zny0QFsybPDnFhNgwJliXF8g9U+u afpqgIH0B9c9o3PnjJL+sr+t/Dfb7+NRKFJ+9Jzfp/V+HaDKgS8mjhhvQi85wsbek+7r f/WtvnmX+KfK3DbD8lClraQFeq0DQ9HtEelIH9HIqWle8SHN969FtDx13710er2D+For UMm6MRiFq6zo6eSAAO0c/Bbnr94m2+BVzexHIUBCH+JCNtvs6iLum385zbTeTwXK5lv8 J1WM71CbVOh3Np2bjfIfOmOTW7Hu9ol1MIMaO5GTgqllcVxYG6oc4vUMzVwBHeL5uJ2I KKSQ== 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=5IVhoqZQBI1GGY8Q/zxeWajkFfFnMe2wwJAZK4MFlUo=; b=tWA/GfOKjpixAzOUreMzRYkOj49F3Ji00n9xwu3gY2rUglwNPcrpY05O0QaU9jtKET FqUmxVVPZCL7Bcdzb3e+/oRHiyHb/VVId83bpl7q12QfKUujuMIa3wSFS2SH3ECi69G9 m/Y47T+wN9i/CAdMp8GRZZnG927fYZpkUTn+FsNqSjifp0ERofiA3MutMLx+5ElbVHng ddHtNDiHrEgKgGaTGP0J+MblPclEKbESh6gsdM4u7yTQLiQiaQETsZfB2stbWuAytsCk 5vwOzSiyvfDbT2b/fqd32Pse290J0dUuTm0UfdPZUn5MEczdvnbxsISTuOFz/7i9fMQ5 prPA== X-Gm-Message-State: APjAAAVNu5+yTpjRTfyh+506M/OJ98wBUFD6WTVEA122jUTGDzmUH2yC dkvMyCTA6733W5+ni0Y928nbgZGV9LFxzl7Uxwg= X-Google-Smtp-Source: APXvYqwIUBTvTI8Fvh7y4RD7BAUdpmwiw1NCNGVRFms/457iCucBV51hTAuLPWf1MQPjj2blwOvC0rGjr0/6SunNLbg= X-Received: by 2002:a5e:9b0b:: with SMTP id j11mr3205398iok.189.1570628805566; Wed, 09 Oct 2019 06:46:45 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Rob Sayre Date: Wed, 9 Oct 2019 20:46:34 +0700 Message-ID: To: Paul Yang Cc: Rich Salz , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000007a61b05947a843e" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 13:46:48 -0000 --00000000000007a61b05947a843e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 8:43 PM Paul Yang wrote: > > From my understandings, either IPv4 or IPv6 should have nothing to do wit= h > the concept =E2=80=9Cvirtual host=E2=80=9D > Hi Paul, That is correct. However, the scarcity of IPv4 addresses is one major factor driving the need for virtual hosts. Thank you for reading the mailing list in detail. thanks, Rob --00000000000007a61b05947a843e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 8:43 PM Paul Yang = <kaishen.yy@alipay.com> = wrote:

=
From my understandings, either IPv4 or IPv6 should have nothing to do = with the concept =E2=80=9Cvirtual host=E2=80=9D

Hi Paul,

That is correct. However= , the scarcity of IPv4 addresses is one major factor driving the need for v= irtual hosts.

Thank you for reading the mailin= g list in detail.

thanks,
Rob=C2=A0
--00000000000007a61b05947a843e-- From nobody Wed Oct 9 07:17:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CD2120115 for ; Wed, 9 Oct 2019 07:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=alipay.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4q3NSP_4d9RU for ; Wed, 9 Oct 2019 07:17:54 -0700 (PDT) Received: from out0-137.mail.aliyun.com (out0-137.mail.aliyun.com [140.205.0.137]) (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 2CAEF120077 for ; Wed, 9 Oct 2019 07:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1570630657; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; bh=mm8MixlRvGl4iWFn7oq1o/892SXUx8uzK4ORZOkm3y4=; b=RGNaqGwZaqqco0xG6d4HQ7TPDN6JhrnRITAKRyfF3BEaD8SwX5EKiE6Q83xdoZ+T0y2F+eTerN5CmkyTgy75574HG+HRniO8DeeYvVl+qJxIEal+/6tMEFdktLVDTPGPwMtC/Bw+TIQ4CmFEjwlV1Y4tE529Yk2lSPU3h00STAo= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03300; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_---.FiMLGFE_1570630654; Received: from 30.27.196.20(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.FiMLGFE_1570630654) by smtp.aliyun-inc.com(127.0.0.1); Wed, 09 Oct 2019 22:17:34 +0800 From: Paul Yang Message-Id: <8D9F60B9-E507-4465-B761-BAD37B6E1156@alipay.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F4E1568D-A345-4ADE-B229-3F705CDEB020"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 9 Oct 2019 22:17:33 +0800 In-Reply-To: Cc: Rich Salz , "TLS@ietf.org" To: Rob Sayre References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 14:17:56 -0000 --Apple-Mail=_F4E1568D-A345-4ADE-B229-3F705CDEB020 Content-Type: multipart/alternative; boundary="Apple-Mail=_B66AC4A9-2B40-4208-87D8-FACD304D02E2" --Apple-Mail=_B66AC4A9-2B40-4208-87D8-FACD304D02E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 9, 2019, at 9:46 PM, Rob Sayre wrote: >=20 > On Wed, Oct 9, 2019 at 8:43 PM Paul Yang > wrote: >=20 > =46rom my understandings, either IPv4 or IPv6 should have nothing to = do with the concept =E2=80=9Cvirtual host=E2=80=9D >=20 > Hi Paul, >=20 > That is correct. However, the scarcity of IPv4 addresses is one major = factor driving the need for virtual hosts. Yes, that=E2=80=99s right. So even IPv6 addresses are enormous enough to = hold every domain name, we still can=E2=80=99t assume it=E2=80=99s all = used in this way in practice. An administrator can always configure the = origin server as hosting multiple domain names on one IPv6 address. It = may not be very reasonable for doing so, but it could be done in that = way. Actually popular web servers as NGINX supports such kind of = configurations, for instance. For TLS protocol, when being used between an IPv6 CDN node and an origin = server, the SNI still need to be present in ClientHello to address the = above circumstance; otherwise, the IPv6 origin may fail to choose the = right host/certificate to finish the handshake. >=20 > Thank you for reading the mailing list in detail. >=20 > thanks, > Rob Regards, Paul Yang --Apple-Mail=_B66AC4A9-2B40-4208-87D8-FACD304D02E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Oct 9, 2019, at 9:46 PM, Rob Sayre <sayrer@gmail.com> = wrote:

On Wed, Oct 9, 2019 = at 8:43 PM Paul Yang <kaishen.yy@alipay.com> wrote:

=46rom my understandings, either IPv4 or IPv6 should have = nothing to do with the concept =E2=80=9Cvirtual = host=E2=80=9D

Hi Paul,

That is correct. However, the scarcity = of IPv4 addresses is one major factor driving the need for virtual = hosts.

Yes, that=E2=80=99s right. So even IPv6 addresses = are enormous enough to hold every domain name, we still can=E2=80=99t = assume it=E2=80=99s all used in this way in practice. An administrator = can always configure the origin server as hosting multiple domain names = on one IPv6 address. It may not be very reasonable for doing so, but it = could be done in that way. Actually popular web servers as NGINX = supports such kind of configurations, for instance.

For TLS protocol, when being used between an IPv6 = CDN node and an origin server, the SNI still need to be present in = ClientHello to address the above circumstance; otherwise, the IPv6 = origin may fail to choose the right host/certificate to finish the = handshake.


Thank you for reading = the mailing list in detail.

thanks,
Rob 


Regards,

Paul Yang

= --Apple-Mail=_B66AC4A9-2B40-4208-87D8-FACD304D02E2-- --Apple-Mail=_F4E1568D-A345-4ADE-B229-3F705CDEB020 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEndC1x/yVcklg1DZ15HtIVEj/IsoFAl2d6/0ACgkQ5HtIVEj/ IsrF1w/+LVQOMlNKkOm7VRIpyFwSSA2vuVVr/IAjbZecqT+mhLmcvzrnmfxYeVgE nm6jM0AB0XbTn6WuFYOUiy42ZxwryggjKzGoY8bEqO8M0Dio8KMu6CTtUq4bp/iX 6e7/7NBloIKoAJTTkVHTamAGHoYpmDcFlcv+CvKWkJINEb7HBK9+5P4FR+QEzjpZ 2vigxxF8byWIBRtvuBzLvrbBBU5mMgDixPpVec04aifz8xRF8EretdRSwC69g4vz jaYwpHmnY7fjLSNqprQM8I6wCGMMybrzA1n564Y2f5yMt3nvgrTWnq31994RjI97 W/AWF3anMwcyysmJ6/ijiqkBMK6xjxADHZcn+IKhEF6g4zs4n28hrEPwtG0jHaB/ bQkIjIg22PoBVjf0Kp4bMlvEmgcjuGJ6thVhVI3WShe55Oot8G4FBoe3RdOKssMh k+fQkwm4mBHwlNzwaIoXsgfElakvaPNFRXX4ZID0pSNxJIhwGSihhslMNY8AG1Tx K9xkeQTCWU0rQEP6Oo2eqboWuBkoo8MD+zv2AzcUln7A8qJJiCDBPdNy52zEKuuU tzLSpLkQwJjS5GY/4Znxthp8kCDbN++v/xsPUonnD+pWpPhGPL79ByDI9T68ox1C jKdbuECwigkhJhSbOhcugSOPX1FjBfbIeY6UO05IgrGg2MvIvV8= =4xYH -----END PGP SIGNATURE----- --Apple-Mail=_F4E1568D-A345-4ADE-B229-3F705CDEB020-- From nobody Wed Oct 9 07:20:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5726120818 for ; Wed, 9 Oct 2019 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KKyM8YrmAgef for ; Wed, 9 Oct 2019 07:20:23 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 E00D5120220 for ; Wed, 9 Oct 2019 07:20:22 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id n197so5291160iod.9 for ; Wed, 09 Oct 2019 07:20: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; bh=biM+gitkhvQIhTTjUFTt6G8ZXZk8/QllBppFKKRK41Q=; b=J6JUDQSTmR3uKh2Cyw+MSzbOxCMUmeUt/rrilgupsrBD006QouVaKman0L8WWOAs5O XwjLWpgxRYzU6uc8qI0PCU59L8TD0LuJ1aJYRqaV2/ZDOWCFuhLs1bDS2h5Ut2S52EX7 g0cE0l+i2ghIZLlSKxfGrAFC+VPKm255rHBMayDIcIx79WM/W4uqHxPKmzti1PZX4o89 WCeoJaQhRamvclIdstTZfY1KMfV4JCAT2oKUi32+qXIHfOnHanOgBCikMPQqHrSnDciC RKnMH8TrNjo1OCKXU6WJXUIXSNFH+6kK5g8C6MhusG2n/1ApT1PspTj/LnWzrIaowTAU haYA== 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=biM+gitkhvQIhTTjUFTt6G8ZXZk8/QllBppFKKRK41Q=; b=YBA9lVsryPCjCZj17WaIsSN0kz+A6OtJpCkxOOSs7NXco/Ig0RWz/FB03cgRJdWrl0 ojuE4w+9pR5aUPGh7inErJj9WvOid36i9SQY4CpPbC3qFJ6XF4W66OUt4z9CHjfKEzaY 6V3RAXmCXd/GVdSu8S9qQh806ZiLoKxFyupp8CsMKEE3yTnQKTnSAOxFaHhhi2dJHuJW aVlaM/uqS+ZwSrEuDGExARfnFlK5X7mDfO88f88psfZrdn/h+NscmuV3t+YZYrxZqGZX vW2p+DyT/1V+owKuSnr7mC/EXI2LDl51LOOYtUfFS/qd/0GUcDwrvPnI9lbQZnnlzh+q 4qrw== X-Gm-Message-State: APjAAAWK5EhdqtXpk/9Yapp00psOTUEMkllUUkyObR5z9ix7PkHBf0PV uAeZMqBu3NQ7jb0WLKJ3lVEFdluy5wskLJZ8yG4= X-Google-Smtp-Source: APXvYqyWQZSoEp8xJQpF9YnWigZ4coWwhVta2u5eEkqKxLMzwIAYqNMgrIBHsWoE+Tz3G0PBOjFOcThwSvKfTUX2Jw0= X-Received: by 2002:a6b:e910:: with SMTP id u16mr3582596iof.196.1570630821993; Wed, 09 Oct 2019 07:20:21 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <8D9F60B9-E507-4465-B761-BAD37B6E1156@alipay.com> In-Reply-To: <8D9F60B9-E507-4465-B761-BAD37B6E1156@alipay.com> From: Rob Sayre Date: Wed, 9 Oct 2019 21:20:10 +0700 Message-ID: To: Paul Yang Cc: Rich Salz , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000037e38805947afce2" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 14:20:25 -0000 --00000000000037e38805947afce2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Oct 9, 2019 at 9:17 PM Paul Yang wrote: > > > On Oct 9, 2019, at 9:46 PM, Rob Sayre wrote: > > On Wed, Oct 9, 2019 at 8:43 PM Paul Yang wrote: > >> >> From my understandings, either IPv4 or IPv6 should have nothing to do >> with the concept =E2=80=9Cvirtual host=E2=80=9D >> > > Hi Paul, > > That is correct. However, the scarcity of IPv4 addresses is one major > factor driving the need for virtual hosts. > > > Yes, that=E2=80=99s right. So even IPv6 addresses are enormous enough to = hold > every domain name, we still can=E2=80=99t assume it=E2=80=99s all used in= this way in > practice. An administrator can always configure the origin server as > hosting multiple domain names on one IPv6 address. It may not be very > reasonable for doing so, but it could be done in that way. Actually popul= ar > web servers as NGINX supports such kind of configurations, for instance. > > For TLS protocol, when being used between an IPv6 CDN node and an origin > server, the SNI still need to be present in ClientHello to address the > above circumstance; otherwise, the IPv6 origin may fail to choose the rig= ht > host/certificate to finish the handshake. > Hello, I agree that it needs to be possible to include the SNI in ClientHello, but not required. thanks, Rob --00000000000037e38805947afce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 9:17 PM Paul Y= ang <kaishen.yy@alipay.com&= gt; wrote:


On Oct 9, 2019, at 9:46 PM, Rob Sayre <sayrer@gmail.com> wrote:

On Wed, Oct 9, 2019 at 8:43 PM Paul Yang &l= t;kaishen.yy@ali= pay.com> wrote:

From my understa= ndings, either IPv4 or IPv6 should have nothing to do with the concept =E2= =80=9Cvirtual host=E2=80=9D

Hi = Paul,

That is correct. However, the scarcity of IP= v4 addresses is one major factor driving the need for virtual hosts.

Yes, that=E2=80=99s r= ight. So even IPv6 addresses are enormous enough to hold every domain name,= we still can=E2=80=99t assume it=E2=80=99s all used in this way in practic= e. An administrator can always configure the origin server as hosting multi= ple domain names on one IPv6 address. It may not be very reasonable for doi= ng so, but it could be done in that way. Actually popular web servers as NG= INX supports such kind of configurations, for instance.

For TLS protocol, when being used between an IPv6 CDN node and an ori= gin server, the SNI still need to be present in ClientHello to address the = above circumstance; otherwise, the IPv6 origin may fail to choose the right= host/certificate to finish the handshake.

Hello,

I agree that it needs to = be possible to include the SNI in ClientHello, but not required.
=
thanks,
Rob
=C2=A0
--00000000000037e38805947afce2-- From nobody Wed Oct 9 08:18:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007B212083B for ; Wed, 9 Oct 2019 08:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Q-4RwTY8xg7E for ; Wed, 9 Oct 2019 08:18:28 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 B11BB1201CE for ; Wed, 9 Oct 2019 08:18:27 -0700 (PDT) Received: from xse354.mail2web.com ([66.113.197.100] helo=xse.mail2web.com) by mx62.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iIDjH-0007Pm-VB for tls@ietf.org; Wed, 09 Oct 2019 17:18:26 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46pHrd01gVz6yWw for ; Wed, 9 Oct 2019 08:17:21 -0700 (PDT) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iIDiK-0006tB-SG for tls@ietf.org; Wed, 09 Oct 2019 08:17:20 -0700 Received: (qmail 15596 invoked from network); 9 Oct 2019 15:17:20 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.46.231]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Oct 2019 15:17:20 -0000 To: Rob Sayre , Paul Yang Cc: "TLS@ietf.org" References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <8D9F60B9-E507-4465-B761-BAD37B6E1156@alipay.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <15062b36-8691-24e8-9764-2976d4fac0fe@huitema.net> Date: Wed, 9 Oct 2019 08:17:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------530FE494E176D333B47EC3A4" Content-Language: en-US X-Originating-IP: 66.113.197.100 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.13) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVAavk0w1k7hSo vuZkBsBUlETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4Z1rKFPBF8ocIvRqqrC5ObSgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+e8hb1lxHddBtWcfnl7xl+wmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdGd9U9Oojh2QY0MMPWjRsTVhMmX9VvKuj6psZloQqgYBwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPmz5tsQu9R3vp aAMkTA7gTKoJngF7rJQgeWTjF5V/EGvRVCQJzA8QlRu9fnFLFjLKYRO8u0ag4+i9kLOW9cRnakdu 2lX9U0U/jnlrPw5p8im8gM5yDzctcfgaSyAJ9MhDntZcYflIMbaTJGx1xg/L1K0Za/sGUQBejHG7 Mb8LDrziJwCelAgxI3HE4I5TUXrjZoeSHJmh7APCufmViWgq3Ajcs8I0sS2QA06J2qo5iDoVZuM7 jUXIESohoO51xWmU8arIkot+L4UUUitD9p2Q4zPGipiYlbVUQHv2ETe39daw2fa5Z8JMyvt2otFY eJV5EEl45oFndAaW0zhwtclwNLITiSzBvtjMqHJKbcoJ3LAWa8Mrc8quJ4btPpt/2FLuFDHRLWyH Qs+3RVQ97CmIM68WJB4pGe8YrEHjBXb8vVkXYd/jKzjiuDYHz/0WYr1rU3B7HfKjI1eYNYaA4ur2 /Is= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 15:18:31 -0000 This is a multi-part message in MIME format. --------------530FE494E176D333B47EC3A4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I struggle a bit to understand how this thread is related to the SNI Encryption Requirements document. Rob, you raise the question of using and possibly hiding the SNI when using TLS to protect communication between servers. That's a fine debate, but I don't see how this specific usage of TLS and SNI affects the draft or change the requirements on SNI encryption mechanics. We also have an interesting process issue, because this draft already went through WG last call, IETF last call, and IESG review. At this stage, it would take a huge issue to stop the presses and rework the document. -- Christian Huitema On 10/9/2019 7:20 AM, Rob Sayre wrote: > > > On Wed, Oct 9, 2019 at 9:17 PM Paul Yang > wrote: > > > >> On Oct 9, 2019, at 9:46 PM, Rob Sayre > > wrote: >> >> On Wed, Oct 9, 2019 at 8:43 PM Paul Yang > > wrote: >> >> >> From my understandings, either IPv4 or IPv6 should have >> nothing to do with the concept =E2=80=9Cvirtual host=E2=80=9D >> >> >> Hi Paul, >> >> That is correct. However, the scarcity of IPv4 addresses is one >> major factor driving the need for virtual hosts. > > Yes, that=E2=80=99s right. So even IPv6 addresses are enormous enou= gh to > hold every domain name, we still can=E2=80=99t assume it=E2=80=99s = all used in > this way in practice. An administrator can always configure the > origin server as hosting multiple domain names on one IPv6 > address. It may not be very reasonable for doing so, but it could > be done in that way. Actually popular web servers as NGINX > supports such kind of configurations, for instance. > > For TLS protocol, when being used between an IPv6 CDN node and an > origin server, the SNI still need to be present in ClientHello to > address the above circumstance; otherwise, the IPv6 origin may > fail to choose the right host/certificate to finish the handshake. > > > Hello, > > I agree that it needs to be possible to include the SNI in > ClientHello, but not required. > > thanks, > Rob > =C2=A0 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------530FE494E176D333B47EC3A4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I struggle a bit to understand how this thread is related to the SNI Encryption Requirements document. Rob, you raise the question of using and possibly hiding the SNI when using TLS to protect communication between servers. That's a fine debate, but I don't see how this specific usage of TLS and SNI affects the draft or change the requirements on SNI encryption mechanics. We also have an interesting process issue, because this draft already went through WG last call, IETF last call, and IESG review. At this stage, it would take a huge issue to stop the presses and rework the document.

-- Christian Huitema

On 10/9/2019 7:20 AM, Rob Sayre wrote:


On Wed, Oct 9, 2019 at 9:17 PM Paul Yang <kaishen.yy@alipay.com> wrote:


On Oct 9, 2019, at 9:46 PM, Rob Sayre <sayrer@gmail.com> wrote:

On Wed, Oct 9, 2019 at 8:43 PM Paul Yang <kaishen.yy@alipay.com> wrote:

From my understandings, either IPv4 or IPv6 should have nothing to do with the concept “virtual host”

Hi Paul,

That is correct. However, the scarcity of IPv4 addresses is one major factor driving the need for virtual hosts.

Yes, that’s right. So even IPv6 addresses are enormous enough to hold every domain name, we still can’t assume it’s all used in this way in practice. An administrator can always configure the origin server as hosting multiple domain names on one IPv6 address. It may not be very reasonable for doing so, but it could be done in that way. Actually popular web servers as NGINX supports such kind of configurations, for instance.

For TLS protocol, when being used between an IPv6 CDN node and an origin server, the SNI still need to be present in ClientHello to address the above circumstance; otherwise, the IPv6 origin may fail to choose the right host/certificate to finish the handshake.

Hello,

I agree that it needs to be possible to include the SNI in ClientHello, but not required.

thanks,
Rob
 

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--------------530FE494E176D333B47EC3A4-- From nobody Wed Oct 9 08:22:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41AD11200B7 for ; Wed, 9 Oct 2019 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2wf97mX0K82B for ; Wed, 9 Oct 2019 08:22:33 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F204120089 for ; Wed, 9 Oct 2019 08:22:33 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id q1so5909810ion.1 for ; Wed, 09 Oct 2019 08:22:33 -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=53HWDhEKs1mVE9gv2GCTJctRoCVbQsooJgM0fxn5tlc=; b=QhjnCRleNskPN0p/dGtkj0cUvSaP9QxMHbeA6USdpVe3iCDYBZcFSiNq59ZiBgIfv4 POYc5cc5pEXi0nDXLInc66cX5bXOOTbsEz+Pw6p9U1NSa9bXT5bkG2nqRmRCjiWG+L6a HGviAsV5gCzZcN4kUop2LUVzxCc9XqH5ywFgGSGKF+F2Qx4fiEto02dGWQgz7ZGGBYkB OScf2z7b0kbatXyFzlEobkrra6g0qwqxCgbbYtRUbq/mQvv3b/b1yHMBXsM2meNPlqe3 nI5qpweQg4Rf32gfkQ+nu7j7rXZKXEDPE1vP6xxc6fLqisIQ0Yidf7cyjOX5MF9vSdxX I7Sw== 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=53HWDhEKs1mVE9gv2GCTJctRoCVbQsooJgM0fxn5tlc=; b=Gnmj5EY+hWONlMXYLdWz9P7dEJoOwJbnHa3pw3ZyiahZsl6HgzszW7nI8AgUHDU2Vf S5lIgQiOBaZ+LICZKFonnbSKP0wMh7u1n/LkM7KHF9fW3fv5ER0Dr+vz72iO6949/Z0B Re9ZMQGbDaQvw7onUJtx6gInruqUgJ2vJyzF3V8svEYpGLoKBpTTSWGLMyRsS711Cypn hcuRvS4AhxvW0FgWffTcuY8xnOTj81IiABU9OquPtTNKoVIn8R9XN3A5xpeMa6GIy/e3 Mm1uG9nJxUI+xroSWaV32t4F9Bhi0CZUQqRsymp6upcclC0910MDFdTdxUtj6MvJwGPu 7yEA== X-Gm-Message-State: APjAAAVicS3cLvV/b4/MxoHOX+o9UsQ0WvEHnO8+lLd1nf5CX8JtuIzV x1I9CuePKqNiI1nV2sF6i1vFHp8nXEEwOU4fqsw= X-Google-Smtp-Source: APXvYqxpkFdHzyfsNgKjZ+pHnY0R8ztUATzo247usTLCOuADW02UHf7ZSR1KZ4Fk1p9LWUuV52lbN06fib7RQ1cBBCc= X-Received: by 2002:a05:6638:928:: with SMTP id 8mr3524980jak.124.1570634552208; Wed, 09 Oct 2019 08:22:32 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <8D9F60B9-E507-4465-B761-BAD37B6E1156@alipay.com> <15062b36-8691-24e8-9764-2976d4fac0fe@huitema.net> In-Reply-To: <15062b36-8691-24e8-9764-2976d4fac0fe@huitema.net> From: Rob Sayre Date: Wed, 9 Oct 2019 22:22:19 +0700 Message-ID: To: Christian Huitema Cc: Paul Yang , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008e726a05947bda5a" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Wed, 09 Oct 2019 15:22:35 -0000 --0000000000008e726a05947bda5a Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 10:18 PM Christian Huitema wrote: > I struggle a bit to understand how this thread is related to the SNI > Encryption Requirements document. Rob, you raise the question of using and > possibly hiding the SNI when using TLS to protect communication between > servers. That's a fine debate, but I don't see how this specific usage of > TLS and SNI affects the draft or change the requirements on SNI encryption > mechanics. We also have an interesting process issue, because this draft > already went through WG last call, IETF last call, and IESG review. At this > stage, it would take a huge issue to stop the presses and rework the > document. > Hello, I didn't realize the document was at that phase. Also, my suggestion can be added at any time. So, I don't think this discussion should hold up any progression in the IETF process. Sorry for any confusion. I support moving this document forward. thanks, Rob --0000000000008e726a05947bda5a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 10:18 PM Christian= Huitema <huitema@huitema.net= > wrote:
=20 =20 =20

I struggle a bit to understand how this thread is related to the SNI Encryption Requirements document. Rob, you raise the question of using and possibly hiding the SNI when using TLS to protect communication between servers. That's a fine debate, but I don= 9;t see how this specific usage of TLS and SNI affects the draft or change the requirements on SNI encryption mechanics. We also have an interesting process issue, because this draft already went through WG last call, IETF last call, and IESG review. At this stage, it would take a huge issue to stop the presses and rework the document.


Hello,
<= div>
I didn't realize the document was at that phase. Als= o, my suggestion can be added at any time.

So, I d= on't think this discussion should hold up any progression in the IETF p= rocess.

Sorry for any confusion.

I support moving this document forward.

th= anks,
Rob

=C2=A0
--0000000000008e726a05947bda5a-- From nobody Wed Oct 9 17:47:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBF0120072 for ; Wed, 9 Oct 2019 17:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 8Uev1fttFe1N for ; Wed, 9 Oct 2019 17:47:36 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 6B35F120046 for ; Wed, 9 Oct 2019 17:47:36 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id s7so2788519vsl.2 for ; Wed, 09 Oct 2019 17:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zVOD4U0ew60aaYNOGjWx5+/lnjJqAGau6ovEqSGFXb8=; b=DV1W5LIjqxpxUGaJxykrmRc7ATru9JJVPQOGmK7FZt8PP6KYRCKrSiZyrhAYuAWZR2 Rzry8LnjjZEjSndyxUZDHC16fxqNtfJc+LCsB7WtN3qniS7Dal0CU2QBeJuRy+QOejdB k7F8Hbl5N4B3nOy/DgCrp/qlHVnzjTRNnlTEo= 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=zVOD4U0ew60aaYNOGjWx5+/lnjJqAGau6ovEqSGFXb8=; b=OlWaig79xcIhl1z/EWQHSSqeRw0Bj4K3dHmRD3eoTaSbLPE7n+bloWeqh0ffHFUMal One9eWtbnGAVbk7HSfx933ge0KQ439Ok3tqYV+/Uy8wxw3GI/FZiE5VFi9qw8s+6p8wM 6TRA3a0I1sGoQ55ezwbS0Gl5G80yjKnOA6H/X02DgP4Pm2aUJKjwsvM3YHP+Is1mWK7p +k92DoCmTWUDIktip+5gftn7Q3v30ZrAwNTtQ3gIvHmAF4gCZ1UgtUf+Vx/EsHtafx2U qR1ENRYRY2zxX5XbKKnFXsKwvZmCDcu6KlE3gHhbOg+N+jXYEVAXadzvgUAJxADQyIC0 MX+g== X-Gm-Message-State: APjAAAW3jJoDHBLDkLle4RuGfQyz4V5UpBvrpx+MDRYIbzjdQAXLQGuk DxC+O5tv/HSm7L2VSqoeZx0D/nZI1oIJWY4KAg3DoA== X-Google-Smtp-Source: APXvYqyoBXc3zuaH0EzKO1vDw85PmnKEZo5E5jJUoZEfYhoEjJE2EwbKT/gDIJrGAB7TMLsOd7q4AFemDXhXCAxc5vE= X-Received: by 2002:a67:e1d3:: with SMTP id p19mr3587391vsl.212.1570668455149; Wed, 09 Oct 2019 17:47:35 -0700 (PDT) MIME-Version: 1.0 References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> In-Reply-To: <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> From: Nick Sullivan Date: Wed, 9 Oct 2019 17:47:18 -0700 Message-ID: To: Christer Holmberg Cc: "gen-art@ietf.org" , "draft-ietf-tls-exported-authenticator.all@ietf.org" , "ietf@ietf.org" , "" Content-Type: multipart/alternative; boundary="0000000000005506bc059483bf4c" Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 00:47:39 -0000 --0000000000005506bc059483bf4c Content-Type: text/plain; charset="UTF-8" Thanks again for your review! The PR is on Github ( https://github.com/tlswg/tls-exported-authenticator/pull/50) and will be incorporated into a new version of the document that addresses both your comments and those by Yaron Sheffer. On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >Some answers to your questions inline. I'm not sure further changes along > the lines suggested here are needed, but I'm open to arguments that point > in that direction. > > I am mostly fine with your answers. Just a couple of comments inline still. > > --- > > MIN_2: > > >>>> Can the mechanism be used also for DTLS? > >>> > >>> I think the answer is yes. I don't see any reason to disallow the use > of Exported Authenticators in DTLS. > >> > >> Would it be useful to clarify that? > > > > Going through what the modified text would look like, it seems like a > substantial amount of re-writing (even the title!) for what amounts to an > unclear use case. > > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't directly > define exporters, I'm disinclined to define how EAs would work with DTLS. > If someone > > has a strong use case for EA in DTLS, it may be worth considering it. > > Would it then be useful with a statement saying that it might be possible > to use exporters also with DTLS, but that such usage is outside the scope > of the document and needs to be specified in a separate document? > I added a line to this effect. > > --- > > MIN_3: > > >>>> The documents talk about additional certificates. If I only have one > additional > >>>> certificate, can I use that for multiple authenticators throughout > the TLS > >>>> session? > >>> > >>> Yes, there is nothing disallowing the creation of multiple exported > authenticators with the same certificate. > >> > >> Would it be useful to clarify that? > > > > I'm not convinced this is a realistic use case. Since exported > authenticators are based on the exporter, there is no inherent ordering. > > If you re-authenticate with the same certificate, there's nothing > asserting freshness of the second certificate. Is there something in > > the text that suggests that using a certificate multiple times is > disallowed? If there's no suggestion that this is not possible that > > needs to be corrected, I don't see the benefit of calling out this > specific use case. > > I don't think there is any text suggesting that it is disallowed. But, if > you don't think it is a realistic use case I'll take your word for it :) > > --- > > ED_2: > > >>>> Section 3 says: "The authenticator request is a structured message > that can be > >>>> created..." Section 4 says: "The authenticator is a structured > message that can > >>>> be exported..." > >>>> > >>>> In the 2nd paragraph of Section 4 it is stated that "authenticator" > is sent > >>>> based on an "authenticator request". I wonder if that could be stated > already > >>>> in the beginning of Section 4, to further clarify the difference > between them. > >>>> E.g., > >>>> > >>>> "The authenticator is a structured message, triggered by an > authenticator > >>>> request, that can be exported from either party of a TLS connection." > >>> > >>> The issue is that servers can generate spontaneous exported > authenticators without > >>> an authenticator request. > >> > >> Where is this written? Did I miss it? > > > > Section 4: > > An authenticator message can be constructed by either the client or > > the server given an established TLS connection, a certificate, and a > > corresponding private key. Clients MUST NOT send an authenticator > > without a preceding authenticator request; for servers an > > authenticator request is optional. For authenticators that do not > > correspond to authenticator requests, the certificate_request_context > > is chosen by the server. > > Ok. Looks good. > > Regards, > > Christer > > > --0000000000005506bc059483bf4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again for your review! The PR is on Github (https= ://github.com/tlswg/tls-exported-authenticator/pull/50) and will be inc= orporated into a new version of the document that addresses both your comme= nts and those by Yaron Sheffer.

On Thu, Sep 19, 2019 at 11:29 PM = Christer Holmberg <chr= ister.holmberg@ericsson.com> wrote:
Hi,

>Some answers to your questions inline. I'm not sure further changes= along the lines suggested here are needed, but I'm open to arguments t= hat point in that direction.

I am mostly fine with your answers. Just a couple of comments inline still.=

---

MIN_2:

>>>> Can the mechanism be used also for DTLS?
>>>
>>> I think the answer is yes. I don't see any reason to disal= low the use of Exported Authenticators in DTLS.
>>
>> Would it be useful to clarify that?
>=C2=A0
> Going through what the modified text would look like, it seems like a = substantial amount of re-writing (even the title!) for what amounts to an u= nclear use case.
> Keeping in mind that DTLS 1.3 hasn't been finalized and doesn'= t directly define exporters, I'm disinclined to define how EAs would wo= rk with DTLS. If someone
> has a strong use case for EA in DTLS, it may be worth considering it.= =C2=A0
=C2=A0
Would it then be useful with a statement saying that it might be possible t= o use exporters also with DTLS, but that such usage is outside the scope of= the document and needs to be specified in a separate document?

I added a line to this effect.

---

MIN_3:

>>>> The documents talk about additional certificates. If I onl= y have one additional
>>>> certificate, can I use that for multiple authenticators th= roughout the TLS
>>>> session?
>>>
>>> Yes, there is nothing disallowing the creation of multiple exp= orted authenticators with the same certificate.
>>
>> Would it be useful to clarify that?
>
> I'm not convinced this is a realistic use case. Since exported aut= henticators are based on the exporter, there is no inherent ordering.
> If you re-authenticate with the same certificate, there's nothing = asserting freshness of the second certificate. Is there something in
> the text that suggests that using a certificate multiple times is disa= llowed? If there's no suggestion that this is not possible that
> needs to be corrected, I don't see the benefit of calling out this= specific use case.

I don't think there is any text suggesting that it is disallowed. But, = if you don't think it is a realistic use case I'll take your word f= or it :)

---

ED_2:

>>>> Section 3 says: "The authenticator request is a struc= tured message that can be
>>>> created..." Section 4 says: "The authenticator i= s a structured message that can
>>>> be exported..."
>>>>
>>>> In the 2nd paragraph of Section 4 it is stated that "= authenticator" is sent
>>>> based on an "authenticator request". I wonder if= that could be stated already
>>>> in the beginning of Section 4, to further clarify the diff= erence between them.
>>>> E.g.,
>>>>
>>>> "The authenticator is a structured message, triggered= by an authenticator
>>>> request, that can be exported from either party of a TLS c= onnection."
>>>
>>> The issue is that servers can generate spontaneous exported au= thenticators without
>>> an authenticator request.
>>
>> Where is this written? Did I miss it?
>
> Section 4:
>=C2=A0 =C2=A0An authenticator message can be constructed by either the = client or
>=C2=A0 =C2=A0the server given an established TLS connection, a certific= ate, and a
>=C2=A0 =C2=A0corresponding private key.=C2=A0 Clients MUST NOT send an = authenticator
>=C2=A0 =C2=A0without a preceding authenticator request; for servers an<= br> >=C2=A0 =C2=A0authenticator request is optional.=C2=A0 For authenticator= s that do not
>=C2=A0 =C2=A0correspond to authenticator requests, the certificate_requ= est_context=C2=A0
>=C2=A0 =C2=A0is chosen by the server.
=C2=A0
Ok. Looks good.

Regards,

Christer


--0000000000005506bc059483bf4c-- From nobody Wed Oct 9 18:05:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B812004C for ; Wed, 9 Oct 2019 18:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=AssxROBs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=xF+rvJ/k Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYrXZmBRb5PT for ; Wed, 9 Oct 2019 18:05:21 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7321120020 for ; Wed, 9 Oct 2019 18:05:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B640861B for ; Wed, 9 Oct 2019 21:05:20 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 09 Oct 2019 21:05:20 -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=fm3; bh=XC6wTRpses8C7fagcs5RUezSdNwp4v3 MIrLm7O+K/MI=; b=AssxROBsaO4DLYA0G1aMhHIaxWkKpaVYy2+SKBDe5vF7mic CCiUMHzo25jWJdbaRjEAupZDjm/PXHinSDNdETEc1AjndL+sTLW/xm5QfA9jmfrU cuo9O63T3/nPEKaKUcuYmsYndnBxKQXyNcQY+QhjyxR8i58SmuWlUBqwbdnSqoTq d5P6Bhh2cO7f2PARYTuNpQLU5/ufYaQgdg/eVhejURWFA5ed8+QBGF6oP518eOF1 LMCiOlYszTuRMIk9/8B13fMTQ7o89WmhUQ6BuoAAM2xKCH/27Yj8XlAiAuQNdq/Y J1mZPOoaJaZIWk2tzdirsbyAfATIQAm+bJEQB+Q== 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=fm1; bh=XC6wTR pses8C7fagcs5RUezSdNwp4v3MIrLm7O+K/MI=; b=xF+rvJ/kwcAkA3ZTlfXLe+ 9c7wie6SU097jcp0Yxgm3tdV2BOajx3Len8gZcu4jz+dFmxgF5sm6tGb41RWDwXQ CQo+NhuAspYY9g3vD8/i/D9vLDGPDId3qxgc9Zf6ywZeHCVPJuDbesO/h/RcZJ53 eTg07rfyaYoi25pAslRDcy7XjSrM3ZdPaZJHMjiDVgnh9eSvvfQ2AaES+5j8OI3u BW7w6+1lMbjhpyqctq4EbVumOQrN0keKA/2FrjrPy0ltGnZ2JaTBM5mA+DYepWvA a8rdlIpVf2tYVIWj8cwhy53KR7wf+i3yRFPdujh5A3xaw37DfnOkfER87dn/Px6A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D2BBEE00AF; Wed, 9 Oct 2019 21:05:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <2781261d-bfa2-4c40-9ca4-6a3a1c9266df@www.fastmail.com> In-Reply-To: <8c2b10b3-bfc2-44b0-997a-1cab0789f1b7@www.fastmail.com> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8c2b10b3-bfc2-44b0-997a-1cab0789f1b7@www.fastmail.com> Date: Thu, 10 Oct 2019 12:04:59 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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: Thu, 10 Oct 2019 01:05:24 -0000 I think that the discussion Victor started about the number of tickets you might want to supply being different for a resumed connection is a sensible one, but I would caution against servers making inferences, especially in light of a very clear signal from clients. Advice for client implementations might be wise, so that servers are less motivated to make these sorts of decisions. Nits-wise, there are lots of lowercase instances of "may", which is fine, but most can be replaced with "can", except one that I think could be a "MAY": Clients may send this extension in ClientHello. Otherwise, I only skimmed this. If I get a chance, I might send more detailed editorial comments, but I didn't see any technical reason to hold this back from WGLC. On Sat, Sep 28, 2019, at 09:59, Christopher Wood wrote: > This version addresses some of the comments we received from Hubert a > while back. We think it's ready to go for WGLC, modulo whatever nits > folks find. :-) > > Best, > Chris (no hat) > > On Fri, Sep 27, 2019, at 4:47 PM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the Transport Layer Security WG of the IETF. > > > > Title : TLS Ticket Requests > > Authors : Tommy Pauly > > David Schinazi > > Christopher A. Wood > > Filename : draft-ietf-tls-ticketrequests-02.txt > > Pages : 6 > > Date : 2019-09-27 > > > > Abstract: > > TLS session tickets enable stateless connection resumption for > > clients without server-side, per-client state. Servers vend an > > arbitrary number of session tickets to clients, at their discretion, > > upon connection establishment. Clients store and use tickets when > > resuming future connections. This document describes a mechanism by > > which clients may specify the desired number of tickets needed for > > future connections. This extension aims to provide a means for > > servers to determine the number of tickets to generate in order to > > reduce ticket waste, while simultaneously priming clients for future > > connection attempts. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-02 > > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-02 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-02 > > > > > > Please note that it may take a couple of minutes from the time of submission > > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 9 18:15:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D39120044 for ; Wed, 9 Oct 2019 18:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=Ot+qAKgP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QabBCmB/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B84W6P7gthMy for ; Wed, 9 Oct 2019 18:15:39 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD47120020 for ; Wed, 9 Oct 2019 18:15:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9728862B for ; Wed, 9 Oct 2019 21:15:38 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 09 Oct 2019 21:15:38 -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=fm3; bh=Xv/3joQpOpuvUABQ/J9Mi0Kec52AwHh n/shnAkuT+3s=; b=Ot+qAKgPCLgTMmk5pcMJGa75fFdOsPJS/zKDstKoqykdP3t W6114wBmE93ffYslg7R8dBq06nsQ9MBO51rPGFIIFydQPgrK/VfhkeD2RkbO+JdF dT6usdC62UKzoyCfElvpelux57xfKwcr48aF5Lyi+ZeVI7c25sg7Jx1nRJIFx8Kq iOcRhKMF7crvD8Cr1Yf7Fa/CLwkNCH5kiWLH/CUy0XYiUMOC8Qmwd/oWssGMo02L kMusg15EdXHURqD/F+46ZgX7BrFS64wgJje3M+bAYfN6oLf4TKkASmnwKAE8wPc4 CAReg37bl6kaCgvg7mSHu6/a/GZs9pk11CZufJA== 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=fm1; bh=Xv/3jo QpOpuvUABQ/J9Mi0Kec52AwHhn/shnAkuT+3s=; b=QabBCmB/Bbweh5JFjnTSUo 7sHUCvJ7m6rdf51RS3Rnjkbt4zDMn326XgcrnIcpZ7+oPd0Acx3HtbxHrifzTigI os2jPozZuF4HM1quEmQ54ezRfsBJXpGC9G8jJ6IAeEbm/j1tbJrg/yruLr/lRDQV EBirIxxH8Iw6uacPguXDTpiU9TmbfuG7HETo+ayXvcYLxvKawaiFotgQ936V0gpq yHiWkGU63T2gN6dnSNlj9AqsGppBNwaJK2REGlf9QPQJOxk5dBiLOhaskKkYDjAx rOx8y4zQxCqpTPOWdbwRmewEu5up2DF4ToSHt8Ertx35VAl0gHXcHeuDiXu6zc9w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucffoh hmrghinhepmhiilhdrlhgrnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D7767E00A5; Wed, 9 Oct 2019 21:15:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <0408bdf3-dc7d-4e1d-8592-4b1913888de8@www.fastmail.com> In-Reply-To: References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> Date: Thu, 10 Oct 2019 12:15:15 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Publication_has_been_requested_for_draft-ietf-tl?= =?utf-8?q?s-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: Thu, 10 Oct 2019 01:15:41 -0000 On Thu, Oct 10, 2019, at 00:04, Eric Rescorla wrote: > draft-ietf-rtcweb-security arch doesn't precisely encourage you to > implement DTLS 1.0; there's no normative language at all (even in the > non-2119 sense). It makes s factual statement about the history of the > document and about the impact of implementing only DTLS 1.2 and leaves > it up to the implementor what to do with that statement. I agree that > the fact that it bothers to mention it might be read as implying that > people should do DTLS 1.0, but that's not actually in the text. Indeed, > I could imagine this document including both this text *and* a MUST NOT > implement DTLS 1.0 (that's actually how one has to interpret the union > of draft-ietf-rtcweb-security-arch and > draft-ietf-tls-oldversions-deprecate), with the understanding that the > point of the "might encounter interoperability issues" is to document > the impact of the MUST NOT requirement. This is, I think, the best interpretation of the current situation. At best, you make the same inference you always do: disabling DTLS 1.0 right away comes with some interoperability risks. Just to add some data on this point: browsers are looking to disable DTLS 1.0 at around the same time, but our data about DTLS 1.0 usage isn't as good as for TLS 1.0, so this is less of a firm commitment. For instance, this (https://mzl.la/31255vp) is a much higher proportion of the overall, but it is also quite noisy. Either way, I expect this to go away at the same time or soon after. We're a little more comfortable being a more aggressive with WebRTC. From nobody Wed Oct 9 18:26:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5352120044 for ; Wed, 9 Oct 2019 18:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=Anb2rW4R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IQY0rHr8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbf7tWIQOwm8 for ; Wed, 9 Oct 2019 18:26:33 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF6C120020 for ; Wed, 9 Oct 2019 18:26:33 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 06FA8601 for ; Wed, 9 Oct 2019 21:26:32 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 09 Oct 2019 21: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 :subject:content-type; s=fm3; bh=uB+uDpkmxaQLisE2mEDxpaCpp/T0Rwu jiyWe3KL+6PE=; b=Anb2rW4RmOAMRZdop4aCePZNjADQR1tiCTuwvOlu6Qo4KY1 z5kaMrAwkY+Di44abMRaV8qLfHKY5MQd/U6YOkM6pUfFAKfkMwz+vYn0IMHCdaIH OvJTxOsPk5oX0xQ14WaOzNl8BDtkmZcYCfCzTSlhP1kk8vaJE+sX775LNtUYhTg9 GYfoZ17g0DcfAeLSXkinqt6jDeLjcOAOpmDxNxju4XGCSq9rRufVP5aWvJuV42RJ 9v3TC4teR3A2o+rRYcqJhbu1ykHOXpjsA/vKBqKuFCZIpzFIV1fw/YwWpo3u2/DP doK8D1lBGKYvVERZ0Wju2b5SNsdZ6oNv4f/DvBA== 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=fm1; bh=uB+uDp kmxaQLisE2mEDxpaCpp/T0RwujiyWe3KL+6PE=; b=IQY0rHr8L/kyssuo7dJEBp wkyaYHUci6g/13UzryLdnNFhKGnptBv3o5Da3tPullXBDsw5ieEe+unVG3f9Y4+Q 8Q4nx6VmXj5CpZDn0CZGiUu0j4iiFmqQovqHfupoTbye60u8i/jJJepnnMsHl5b1 WXio6U+UoKBLP0w+YrKKuT9OXKuBRU2ZjlhOm4wRlTZ4o0Hu4EFck5ORdblq/wi7 E9WAHI9VKTzA+ZN3mPMu8ALIImaWJMskWIon6HPJ1d9rYGMnM0FytCiqNNY+xdnK 6r3dbiKKLZpOyFApcq8IlUnRvWdj0k4oFHuIGm4RHnKW5Iyk1QUR/XEWQXNQP+sQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A097E00A5; Wed, 9 Oct 2019 21:26:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com> In-Reply-To: References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> Date: Thu, 10 Oct 2019 12:26:11 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Genart_last_call_review_of_draft-ietf-tls-export?= =?utf-8?q?ed-authenticator-09?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 01:26:36 -0000 I think that the DTLS thing doesn't require as much rewriting as observed. Just say that when you say "TLS" you mean "TLS or DTLS" somewhere up front. As to what a transport needs to provide, I think that there is no real text to add regarding DTLS. You *could* say that as the application protocol is responsible for carrying the messages, might find that using a DTLS connection introduces new problems. Specially, these are big messages and they are likely to require fragmentation and reassembly if DTLS is used. Also, if the protocol depends on these messages being reliably delivered, it will want to provide some sort of loss recovery mechanism. On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote: > Thanks again for your review! The PR is on Github > (https://github.com/tlswg/tls-exported-authenticator/pull/50) and will > be incorporated into a new version of the document that addresses both > your comments and those by Yaron Sheffer. > > On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg > wrote: > > Hi, > > > > >Some answers to your questions inline. I'm not sure further changes along the lines suggested here are needed, but I'm open to arguments that point in that direction. > > > > I am mostly fine with your answers. Just a couple of comments inline still. > > > > --- > > > > MIN_2: > > > > >>>> Can the mechanism be used also for DTLS? > > >>> > > >>> I think the answer is yes. I don't see any reason to disallow the use of Exported Authenticators in DTLS. > > >> > > >> Would it be useful to clarify that? > > > > > > Going through what the modified text would look like, it seems like a substantial amount of re-writing (even the title!) for what amounts to an unclear use case. > > > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't directly define exporters, I'm disinclined to define how EAs would work with DTLS. If someone > > > has a strong use case for EA in DTLS, it may be worth considering it. > > > > Would it then be useful with a statement saying that it might be possible to use exporters also with DTLS, but that such usage is outside the scope of the document and needs to be specified in a separate document? > > I added a line to this effect. > > > > --- > > > > MIN_3: > > > > >>>> The documents talk about additional certificates. If I only have one additional > > >>>> certificate, can I use that for multiple authenticators throughout the TLS > > >>>> session? > > >>> > > >>> Yes, there is nothing disallowing the creation of multiple exported authenticators with the same certificate. > > >> > > >> Would it be useful to clarify that? > > > > > > I'm not convinced this is a realistic use case. Since exported authenticators are based on the exporter, there is no inherent ordering. > > > If you re-authenticate with the same certificate, there's nothing asserting freshness of the second certificate. Is there something in > > > the text that suggests that using a certificate multiple times is disallowed? If there's no suggestion that this is not possible that > > > needs to be corrected, I don't see the benefit of calling out this specific use case. > > > > I don't think there is any text suggesting that it is disallowed. But, if you don't think it is a realistic use case I'll take your word for it :) > > > > --- > > > > ED_2: > > > > >>>> Section 3 says: "The authenticator request is a structured message that can be > > >>>> created..." Section 4 says: "The authenticator is a structured message that can > > >>>> be exported..." > > >>>> > > >>>> In the 2nd paragraph of Section 4 it is stated that "authenticator" is sent > > >>>> based on an "authenticator request". I wonder if that could be stated already > > >>>> in the beginning of Section 4, to further clarify the difference between them. > > >>>> E.g., > > >>>> > > >>>> "The authenticator is a structured message, triggered by an authenticator > > >>>> request, that can be exported from either party of a TLS connection." > > >>> > > >>> The issue is that servers can generate spontaneous exported authenticators without > > >>> an authenticator request. > > >> > > >> Where is this written? Did I miss it? > > > > > > Section 4: > > > An authenticator message can be constructed by either the client or > > > the server given an established TLS connection, a certificate, and a > > > corresponding private key. Clients MUST NOT send an authenticator > > > without a preceding authenticator request; for servers an > > > authenticator request is optional. For authenticators that do not > > > correspond to authenticator requests, the certificate_request_context > > > is chosen by the server. > > > > Ok. Looks good. > > > > Regards, > > > > Christer > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 9 18:28:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999D6120044 for ; Wed, 9 Oct 2019 18:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=Yezm6c0R; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nsZt0WQ9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YI-TOBsfLg9Y for ; Wed, 9 Oct 2019 18:28:35 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF12A120020 for ; Wed, 9 Oct 2019 18:28:35 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EF56F644 for ; Wed, 9 Oct 2019 21:28:34 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 09 Oct 2019 21:28:35 -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=fm3; bh=aulSzr/R/KbXNdxcEY7E5jU2bzPwG04 56o7fOMHJOzM=; b=Yezm6c0RUeaMJKbA/EDMWn1WHZ5572Q1rL013dXuanrg5ZL gxay0BNb0SYc0DcrG0LQvXN1WUzG8RSmBL8x8Qim+cLB+Z0SRIhWIDjEmfBnBor9 jK5Av4LVJTKrUWx8SE50G+TRYza5NN7N9gigshAoWifk6VO7hR3IytppDusMxnE5 TN3jnLEXTo2uEJvPE1naJLXowvJu89PpyHqgd5y2PdfyCJVF8X8x22aAatUVQzA+ cQt1FanFBa1APRtn7YUyTz5AjlZ5mz0/K7+zrh+Q/wyoBLRXYQVnA62XS3LrVnfn VVUb6PfUUV1PROWmAjQWpqVWzF61kVymX9SYU2w== 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=fm1; bh=aulSzr /R/KbXNdxcEY7E5jU2bzPwG0456o7fOMHJOzM=; b=nsZt0WQ9uK3cKxn25a55o9 D8RHbTvokmr5RtlQKzurdk6arpIDQ/FOeq/nvYuidJ96YZy4PHa+Xw3K8L+X043v ijIIcnRdFMDP+AkZSOHAOYYGDugny64owISt22CM8p+XpcBLp/mMEHcfcfbWCoB6 8S9Tqjpny2ZkN9/jKJPcgJZdFF6ovTNo6cChqqLj/sszS4RKD0fVSBwR5Wa6ziqG LsCgsVMbphFIecbok7SkndewJJH80QmBZcQ/oxKgiDR1t7+g2xur7bWmcy7oOZTR EX5cP2eQLkNqN4jWTU10zZUtUDVpGGDJNaL2/khOjW7lgS706WjOmvJVtzZqC3yA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5CF78E00AF; Wed, 9 Oct 2019 21:28:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <2ab22d60-60e3-49bf-9bd2-fff97b1748c7@www.fastmail.com> In-Reply-To: <31e3f9ed-6b24-4526-af75-e2c190a3d707@www.fastmail.com> References: <31e3f9ed-6b24-4526-af75-e2c190a3d707@www.fastmail.com> Date: Thu, 10 Oct 2019 12:28:14 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] IANA changes for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 01:28:38 -0000 These are pretty long strings. That means more hash iterations to get these values. Are we comfortable with that? Even excluding the prefix, the first is 39 octets. On Thu, Oct 3, 2019, at 06:58, Christopher Wood wrote: > Hi folks, > > draft-ietf-tls-exported-authenticator requires some IANA changes that > were not discussed during WGLC. The proposed changes are below. Please > let the list know by next week (10/9) if you object to them, and if so, > please explain why. > > > Value: EXPORTER-server authenticator handshake context > > DTLS-OK: Y > > Recommended: Y > > Reference: [ RFC-to-be ] > > Note: > > > > Value: EXPORTER-client authenticator finished key > > DTLS-OK: Y > > Recommended: Y > > Reference: [ RFC-to-be ] > > Note: > > > > Value: EXPORTER-server authenticator finished key > > DTLS-OK: Y > > Recommended: Y > > Reference: [ RFC-to-be ] > > Note: > > Thanks! > Chris > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 9 19:01:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AC6120072 for ; Wed, 9 Oct 2019 19:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=nR0QCkDx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TWYvN2Si Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V9VG3QnNfQk for ; Wed, 9 Oct 2019 19:01:20 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BED3120020 for ; Wed, 9 Oct 2019 19:01:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9306C5DA for ; Wed, 9 Oct 2019 22:01:19 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 09 Oct 2019 22:01:19 -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=fm3; bh=CQDxSVKOgkpCnkypM0VUPtl8snCf83+ 0Knn+72tFSZ0=; b=nR0QCkDxGOcccBQgVsZpunyJAvsk2JzbCWAhJ1h90DxGQA/ yr9CVSDuJ85fY+kRGt0iupiYp1jQDQZbcdCxG8Z1oTGAzKVBB1vTFo3HCvPhLTpw KF+qyDeIpHp/H+GGfYWWgYxeW+QBWUdrgRGeDUI7QjJ76pdySoBUnCBauCtz3CPm w6j8DtMTiQkjIzezsJKWM+6RWWYXR2FSgXEYS09Sw4kUuWCLq2qzHXCbwfIBcmik KFINy1bSiWmxxJYvzc1GziCyNEAIGRMRA/SPI9JqSIVGJL8h0FvT1vUkkFlZph54 CC5uibljAV1omvOFyNXJmnn+zX2GDAzqwhtOStg== 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=fm1; bh=CQDxSV KOgkpCnkypM0VUPtl8snCf83+0Knn+72tFSZ0=; b=TWYvN2Si7fIyhNoFo5ngNZ hwltf/kw/SvX3Vzm3Sr8/OkK9I2VECitvgeU4EmTGfxaC30boPR7+yDTCVF7u/hp irVGN1Tyhwdar7CjWZBavNDFWFnOL0q+F0I1LtNaTU60AYenWupqFf2wt89smFW6 cAiUginmrEzd9zu+Nvcvl/KUZ0MJhyGCIW8ahPjUm+UX0m984JMbmcLntOUTce6W cUjzy1R6qfp0gSnXPyxME7f3MGUGBL/tXRJ9XqHPnf4HXqRydgJDB9URhgLb4J4Y 1+LuqgqSSK073Xz7fogH02taom/G3+ZcL/qdT6JC26DpFjljDf+zyK4Ixmbrto5Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedriedvgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 918C3E00AF; Wed, 9 Oct 2019 22:01:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <69c7cfbd-fe9f-40fa-b92b-e4b65fa6cb5d@www.fastmail.com> In-Reply-To: References: Date: Thu, 10 Oct 2019 13:00:58 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS Key Separation PR X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 02:01:22 -0000 tl;dr keep the space. I had a little trouble reproducing the 12 from RFC 8446, so I double-checked. ... Working from the base for SHA-256: The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one to allow for padding. Therefore we have 55 bytes to use without having to run two blocks through SHA-256. HMAC-Hash = H(K XOR opad || H(K XOR ipad || text)) Here `K XOR ipad` is the 32 bytes output size of SHA-256, so we are down to 23 bytes for text before it adds a block. HKDF-Expand = HMAC-Hash(PRK, info | 0x01) This takes one more. Down to 22. HKDF-Expand-Label passes info in the form of: struct { uint16 length = Length; opaque label<7..255> = "tls13 " + Label; opaque context<0..255> = Context; } HkdfLabel; which has a minimal overhead of 2 + 1 + len("tls13 ") + 1 = 10. So we get 12. "c ap traffic" is 12 bytes long, so yeah it *looks* like we're stuck if we care about not adding too many extra hash iterations. ... But if you look at the key schedule, we always provide a context for those cases we use "c ap traffic". Those will always spill over into the next iteration as Context is 32 bytes. So for those cases, we have a whole 32 bytes extra to play with. The only cases with an empty Context are "derived" and "res binder"|"ext binder". Those max out at 10, so we seem to have two whole bytes of wiggle room. You can safely add the space. On Wed, Oct 2, 2019, at 08:40, Eric Rescorla wrote: > Hi folks, > > As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key separation. > > See: > https://github.com/tlswg/dtls13-spec/pull/99 > > Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13" > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Oct 9 20:00:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1466C120072; Wed, 9 Oct 2019 20:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PPHGEyN1y8Vp; Wed, 9 Oct 2019 20:00:31 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4CB9012006B; Wed, 9 Oct 2019 20:00:31 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id a1so10389578ioc.6; Wed, 09 Oct 2019 20:00:31 -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=mVExM+llfGKpNpmz2TLkM1FuuMlTX2EZezp9dkxbzSQ=; b=jBfQOmXhPFUnbszWZVzm+fAWC0WoKFulDxR6W5EOd9pW20eM4XJ0dE0/7vTAJxe0OC Nut0pf1svI+1nFWjsTn2hZO8ZQEgtDNSP5JyzOBBgNgZYnv+2YGlGc8aD6qelBr1LHNS G+UACfWHqmmITHnJnx9E3I0I2jkyvF/fEF8D7RFVJUGjKAYfCiEI7CvNcq7lx0i4SZ+Q n/J7t6I0mLC50kRyt1JuTpri9OPXbeabU5vWiORTv/pFVH1aliLd3xzJCZgTkzwcboHJ KSSPMhpY8EMxyU/HINkHBRm9gqyBJafqow8NK2Ipkwq+OrCvR4//A2L155Vhf4asH93u jiGw== 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=mVExM+llfGKpNpmz2TLkM1FuuMlTX2EZezp9dkxbzSQ=; b=cinOOP6xKfQgDLeTEBuNkfrlLhC3WeHPBc0xkl+U/Rx57AiakMBS6iodeNOqavORzK cM4SdoagRoXcrWrI9FwUZtINE6MS+sx6gy9FyrJ6+cEIPRPUj0h/cyOgUuPIGR8glhhF rOiSUfn/iRla2n5ofbKCf/oJe+kFO7tSQDeTE2/NOS8g9/43bmSV23s/KlG15NtrR74b xjxDamWMrNNNTqdfOW0SrrIULFsVzfh+zsUwaW90lT/0kYTmBk8Ym8RBhNkkyG3h4h5k N1Jvozj2edOVDEMjvgn81WvfkSPCnTjNWtWMGAQHvNyFKNyclAkN5qWzLh9dsb6o7vx8 gbDQ== X-Gm-Message-State: APjAAAXR2yC7siCFnKmk4Ak/1N6KmryNbgNgG5mvvuGUngEpHkjWWLms czKwgPLoptmVkFz9X+zLJaM30Q/yazsnafBbVjo= X-Google-Smtp-Source: APXvYqyMgB3f01Dc0dQUN1/olZRoehkXCf5/IjnRkCg8B3eXRLvHBvjiaSaNESeE9dyvTQMAcYHGhzBuHGr6C33WC60= X-Received: by 2002:a5d:8f83:: with SMTP id l3mr3681835iol.73.1570676430460; Wed, 09 Oct 2019 20:00:30 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 10:00:18 +0700 Message-ID: To: Eric Rescorla Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000b1dc9c0594859a1d" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 03:00:34 -0000 --000000000000b1dc9c0594859a1d Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 8:04 PM Eric Rescorla wrote: > So, 6347 was totally reasonable at the time and I expect the guidance in > this document to override 6347 which all seems quite normal. > Right, that makes sense. > > draft-ietf-rtcweb-security arch doesn't precisely encourage you to > implement DTLS 1.0; there's no normative language at all (even in the > non-2119 sense). > It does have a normative reference to RFC 6347, and seems to be referencing this part of it: "Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS 1.0 of course)" I can understand the WG's "MUST (but we know you won't)" situation. Trying to write spec text for those situations always ends badly over time (imho), but maybe editing the draft itself would be controversial. It does look like draft-ietf-tls-oldversions-deprecate should update the draft, if it's changed so that it updates DTLS-using RFCs. For example, if the document had been published in 2017, would there even be a debate? thanks, Rob --000000000000b1dc9c0594859a1d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 8:04 PM Eric Resco= rla <ekr@rtfm.com> wrote:
=C2=A0So, 6347 was totally reasonable= at the time and I expect the guidance in this document to override 6347 wh= ich all seems quite normal.

Right, that makes sense.
=C2=A0

draft-ietf-rtcweb-security arch doesn&= #39;t precisely encourage you to implement DTLS 1.0; there's no normati= ve language at all (even in the non-2119 sense).

It does have a normative reference to RFC 6347, and= seems to be referencing this part of it: "Implementations that speak = both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTLS= 1.0 (using DTLS 1.0 of course)"

I can un= derstand the WG's=C2=A0"MUST (but we know you won't)" sit= uation. Trying to write spec text for those situations always ends badly ov= er time (imho), but maybe editing the draft itself would be controversial.= =C2=A0

It does look like draft-ietf-tls-oldversion= s-deprecate should update the draft, if it's changed so that it updates= DTLS-using RFCs. For example, if the document had been published in 2017, = would there even be a debate?

thanks,
Ro= b

--000000000000b1dc9c0594859a1d-- From nobody Wed Oct 9 20:49:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287B7120046 for ; Wed, 9 Oct 2019 20:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 z3DcLKNrvWs2 for ; Wed, 9 Oct 2019 20:49:07 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E15012006B for ; Wed, 9 Oct 2019 20:49:07 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id d1so4604008ljl.13 for ; Wed, 09 Oct 2019 20:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e+f7jicrAboKYNULPc9XFZe/zsB0j+LJVjyTFvqHfR4=; b=CBiUKvB8j61OQ925Uk767MBQPAT2fo6mgTB+/d+XMmJjrMJjhI3aKXnNCg6JegZBHT qitqWtTiI0cOdGeBpQ94PTzVQMTxjvl3Myl23xgzc1Y5CC5T3CYMDfH12OeQ9VIbK84y yZXenZvfZqbB6UdPF8wUVC1Sx43yA8NWpwPA2JGwXm5YZTK9whVyIX1P8uKnbskzViVI HItV7Bz84vXo0VYo0LEkFMCyKRG/lQ0RXQn9yxf2yqPGkmqpv8Hu0DNAdREBBCA5+GtP 5cI+5bZNu0P+0X7fHh9LivAUskMT+xtKsFiAdIQyusulQpRKIx4ZxCnu57z+5gByMTYr SJBg== 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=e+f7jicrAboKYNULPc9XFZe/zsB0j+LJVjyTFvqHfR4=; b=effcnLdwWUz3LZ+fgzheTGwqaP2qZv0uUzYf3sJ7FozQDH0AVfWDpvlstamivdJSMh a/uYLRoCGspmb0XEqTrOv56oMZQm85MMXMkcf2Z+FwPSyqKC6J2/AujhfmD6iYQ5zowN SFX+3B/fmYsahgOcFnUH5SY2HDimcGiYnEjAegXLSf5+NJE4MhDOtMa/gQtDUm8asBeY SRbgOSTiTHgEd3sNo1OK+WNWM9H1EeQ7244+1pby1eZ6OINHHoTaVQw3Ep4q2Wm2wfor CIweR0eRFVbU3u6iCqc/Sbd2Jm2m9rbpyORVDNx/rqvdmktxCMtZ51SCo25IVSK8HfFK 3MNQ== X-Gm-Message-State: APjAAAVwXO2/cyiiSKHh+D7EhOCYzzjwgsn8gNgIKEcI97VcHPx4MDfm Pru0spQ2R6it1BetQp6Q6vBajKvWFQZRUdk85QOJOA== X-Google-Smtp-Source: APXvYqz9xlNfLQnM09l+gpr3FSJdmTH4w+HcWce5y8JlxVs48OB7LL/DCo2ZXBuV81KedBhTedeJ6fuejjCUy2LK9yg= X-Received: by 2002:a2e:3a14:: with SMTP id h20mr4386604lja.29.1570679345376; Wed, 09 Oct 2019 20:49:05 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Eric Rescorla Date: Wed, 9 Oct 2019 20:48:28 -0700 Message-ID: To: Rob Sayre Cc: Cullen Jennings , "tls@ietf.org" , Sean Turner via Datatracker , "tls-chairs@ietf.org" , John Mattsson , Benjamin Kaduk Content-Type: multipart/alternative; boundary="0000000000007002c9059486487d" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 03:49:10 -0000 --0000000000007002c9059486487d Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 8:00 PM Rob Sayre wrote: > On Wed, Oct 9, 2019 at 8:04 PM Eric Rescorla wrote: > >> So, 6347 was totally reasonable at the time and I expect the guidance in >> this document to override 6347 which all seems quite normal. >> > > Right, that makes sense. > > >> >> draft-ietf-rtcweb-security arch doesn't precisely encourage you to >> implement DTLS 1.0; there's no normative language at all (even in the >> non-2119 sense). >> > > It does have a normative reference to RFC 6347, and seems to be > referencing this part of it: "Implementations that speak both DTLS 1.2 and > DTLS 1.0 can interoperate with those that speak only DTLS 1.0 (using DTLS > 1.0 of course)" > Yes, but this section of 6347 will be overriden by the present document I can understand the WG's "MUST (but we know you won't)" situation. Trying > to write spec text for those situations always ends badly over time (imho), > but maybe editing the draft itself would be controversial. > > It does look like draft-ietf-tls-oldversions-deprecate should update the > draft, if it's changed so that it updates DTLS-using RFCs. For example, if > the document had been published in 2017, would there even be a debate? > Yes. You don't need to mark the transitive closure of all dependent RFCs as Updated. -Ekr > thanks, > Rob > > --0000000000007002c9059486487d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 8:00 PM Rob Sa= yre <sayrer@gmail.com> wrote:=
On Wed, Oct 9, 2019 at 8:04 PM Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>
=C2=A0So, 6347 was totally reasona= ble at the time and I expect the guidance in this document to override 6347= which all seems quite normal.

<= div>Right, that makes sense.
=C2=A0

draft-ietf-rtcweb-security arch doesn= 't precisely encourage you to implement DTLS 1.0; there's no normat= ive language at all (even in the non-2119 sense).

It does have a normative reference to RFC 6347, an= d seems to be referencing this part of it: "Implementations that speak= both DTLS 1.2 and DTLS 1.0 can interoperate with those that speak only DTL= S 1.0 (using DTLS 1.0 of course)"

Yes, but this section of 6347 will be overriden by the pr= esent document


<= div>I can understand the WG's=C2=A0"MUST (but we know you won'= t)" situation. Trying to write spec text for those situations always e= nds badly over time (imho), but maybe editing the draft itself would be con= troversial.=C2=A0

It does look like draft-ietf-tls= -oldversions-deprecate should update the draft, if it's changed so that= it updates DTLS-using RFCs. For example, if the document had been publishe= d in 2017, would there even be a debate?

Yes. You don't need to mark the transitive closure of a= ll dependent RFCs as Updated.

-Ekr
<= br>

thanks,
Rob
=

--0000000000007002c9059486487d-- From nobody Wed Oct 9 20:53:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363131200B2; Wed, 9 Oct 2019 20:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 B2l38Lm2no3M; Wed, 9 Oct 2019 20:53:33 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 0B40A12008C; Wed, 9 Oct 2019 20:53:33 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id a1so10583512ioc.6; Wed, 09 Oct 2019 20:53:33 -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=M59yfR0vLAL6tsxgxCLKFq2YsSCip/PCsLM24uAMk+w=; b=lopiL5UUTdZ8s+nJ6T3E/TRBXisldUmTpyBXSxG/x2rwN76r7Ir9M324uxbARp923Q HuJFj2Cn30bNTV4COKo6j2tmTXqV0WMHf1+wVssvKyGKDXb9kc8lVwOJswTpd++yjVvB oESWObC67lxqrGZRQmnxlLYu0RUaIiWKmDXGfNYsAcLs0BrnnJu4T4ZRCELPYDkqNoRW 4bnVwhfvRb2tlu+ethZn81O3GW1iyW1X9+omnipJ2p0Ty1Lq9RU17GS1e7rXlIhVjU/J IAV/zeygDHLp8Afq9ALSxSR8L+Z6fr+P3bgrjmhUAH49sDKCRGcD2+JniS2Djb6sIctz +AcQ== 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=M59yfR0vLAL6tsxgxCLKFq2YsSCip/PCsLM24uAMk+w=; b=COxqvtW2FM4ixY1ReghdsZVSXDqoLIBGNgp2oJsQ2FVmIr4D71DiwNKi//S7juIi+N eBk+lDqEcMIPkB8cv6H2TOcRq3WQXsSHM9ud7qj5Gxy7M8/hYaXT8G2r/2Efba4Ia+Hg 1a5YNinwzAWKMv4N4v+P394/m2yvXYd11+QF4gGbgfMaBIhT+pvWp87PZfZacI2jPwIK YhbxZ+LzLmZkeYfxoNyQmOo9sMneEuPjxtAxcfxUj/MIlai3k7kdobB6EvBx+PhX0wx8 on9XNsple22/KqhvxQFhCypgA32HqI4b35GrPdL98Tabng7jrhksva5GzBuWDUmU4LYe YAow== X-Gm-Message-State: APjAAAUjYZpzjkQ2/nTwRjvoCqEvUefSVDSoAFTd7CopKCflyGsFSwZx 6A4lFKZWXYD/Q8K9YuP8RVkYlap49MVj0T+1s6U= X-Google-Smtp-Source: APXvYqx2p1VrnsxUnhymdJZRf7t0PjgnR7+g/Jt6269FYKjysrrSVioVPiC0VG0dfZ0cLIGWO6wnQM0awDo1S4RMRDM= X-Received: by 2002:a02:cd8e:: with SMTP id l14mr7727779jap.30.1570679612196; Wed, 09 Oct 2019 20:53:32 -0700 (PDT) MIME-Version: 1.0 References: <156172485494.20653.307396745611384846.idtracker@ietfa.amsl.com> <989F828F-B427-47A6-A114-4EAEA67D43D7@ericsson.com> <00C5D54E-40C7-4E95-AD2D-9BC60D972685@sn3rd.com> <5bcf3b7c-5501-70f0-4ce7-384f885c39e7@cs.tcd.ie> <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 10:53:20 +0700 Message-ID: To: Eric Rescorla Cc: Benjamin Kaduk , Cullen Jennings , John Mattsson , Sean Turner via Datatracker , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000574e200594865848" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 03:53:35 -0000 --000000000000574e200594865848 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 10, 2019 at 10:49 AM Eric Rescorla wrote: > > You don't need to mark the transitive closure of all dependent RFCs as > Updated. > Isn=E2=80=99t that one of the things the draft is doing, though? thanks, Rob --000000000000574e200594865848 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Oct 10, 2019 at 10:49 AM Eric Rescorla <ekr@rtfm.com> wrote:

You don't need to mark the= transitive closure of all dependent RFCs as Updated.
Isn=E2=80=99t that one of the th= ings the draft is doing, though?

thanks,
Rob
--000000000000574e200594865848-- From nobody Wed Oct 9 22:16:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12321120043 for ; Wed, 9 Oct 2019 22:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T3Ntxwq-f7kF for ; Wed, 9 Oct 2019 22:16:53 -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 4E1DD12001E for ; Wed, 9 Oct 2019 22:16:53 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id b19so10903619iob.4 for ; Wed, 09 Oct 2019 22:16:53 -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=fPfwOhSmOrMklXRiX9/kIGTy4yj51oKAHLaf2/rhYEw=; b=rYqwSF5RLX2c1W+Qz/Lu+aH3/vGFUp049Gcv45Ogc2eCF3Nen4g/8nMYJcghc5t/3z p6JK90yM1XTTgfp4GMhConJ83TcGpufpdM2Wc9HfbA4b3ItZsxrS3F0S1zcwqU0+ReSF bcWnmn/3HUJJSa8q9b0kkeu24d+AJPFkDSFPU5KDFf0NuWKJv9pBknIoVIca7XzQKmNg nJR9TiiuAkteb0J8QiCbu8Nc9Kne3QNW7qvX0cnmn2rQD3QtKYWvNHFA0aADjEpDCL+b /KZiARSWi+oySR8tDf2MyNmJuzBpZwYNkiOcU54YqdAlA64YPWVPlZ1Dk4CDiWEOS3NG 8eXQ== 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=fPfwOhSmOrMklXRiX9/kIGTy4yj51oKAHLaf2/rhYEw=; b=rqJTiJEYV+4xvSk9POM4XLRDCaCmhn15X7Cec1uAsAHarKTEO54D8bBimA8/98NukS rccsl4rg6hZfzQJOvXi64B6xooONnsCtXPbIBHbeDnTbHToIx9bjdlFygQlwq30TWD2V 0McvPxwLXQ2P0UZogwr9EIgVUm3OGPcT8KxSeIZTzFLuiRh6s/dGXGIkPuW9CcMqDHa8 h1U65QY22b2ZEITdCalv79dgnNi8tVqrPI0GUA2NdTSy+HvxFFiHGAhoVw/mGFTE+KQi RMfDe5uTtaSFXrFYtfhngA2JoevyEIfRqkieZe8sn2G8P7T67wZGRFPkVARfH4twLoqB yIxA== X-Gm-Message-State: APjAAAXNt2fUqVmIoqdj+oo0si+wuU/J7cYhd+NtibfnwwMuHGZ4+P/W vg5Kgxlp0XsXFEI+XPlzFOyVmGT3IMUY55ZHI2Q= X-Google-Smtp-Source: APXvYqwKCPcDbXmtlYXwTdRlyVewweepSfdiSTQvDQT6b2nXLyOvN6vDhjRiFTQGg/wYS5MT+P91rEHsMjTt1zNjXQk= X-Received: by 2002:a6b:f40f:: with SMTP id i15mr8085527iog.54.1570684612481; Wed, 09 Oct 2019 22:16:52 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 12:16:40 +0700 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000619772059487821b" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 05:16:55 -0000 --000000000000619772059487821b Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote: > >> I don't think that's quite what I'm proposing. I'm proposing (optionally) >> sending the SNI with a client certificate. >> > > What are you trying to accomplish by doing that? > I want to keep the SNI encrypted in TLS hops that use client certificates, but where ESNI won't work. For example, how is the SNI transmitted in the parens here: [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] I don't think a DNS-based solution like ESNI will work for that second hop, because the origin tends to be identified by an IP address rather than a domain name. thanks, Rob --000000000000619772059487821b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 9, 2019 at 8:06 PM Eric Resco= rla <ekr@rtfm.com> wrote:
I don't think that's quite what I'm proposing. I= 9;m proposing (optionally) sending the SNI with a client certificate.

What are you trying to accomp= lish by doing that?

I wan= t to keep the SNI encrypted in TLS hops that use client certificates, but w= here ESNI won't work.

For example, how is the = SNI transmitted in the parens here:

[ Client ] ---= --> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ]=C2=A0<= /div>

I don't think a DNS-based solution like ESNI w= ill work for that second hop, because the origin tends to be identified by = an IP address rather than a domain name.

thanks,
Rob
--000000000000619772059487821b-- From nobody Wed Oct 9 23:52:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA387120044 for ; Wed, 9 Oct 2019 23:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 zoo5GHNj1qV6 for ; Wed, 9 Oct 2019 23:52:41 -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 3F728120033 for ; Wed, 9 Oct 2019 23:52:41 -0700 (PDT) Received: from xse3.mail2web.com ([66.113.196.3] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iISJT-000QfW-Pt for tls@ietf.org; Thu, 10 Oct 2019 08:52:40 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46phbp6fC6z1kyv for ; Wed, 9 Oct 2019 23:52:38 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iISJS-000757-QR for tls@ietf.org; Wed, 09 Oct 2019 23:52:38 -0700 Received: (qmail 18149 invoked from network); 10 Oct 2019 06:52:38 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.46.231]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Oct 2019 06:52:38 -0000 To: Rob Sayre , Eric Rescorla Cc: "TLS@ietf.org" References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <6500d2cd-5f62-0a00-3923-d9bc864a83e4@huitema.net> Date: Wed, 9 Oct 2019 23:52:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F4283FE4F6B185DE8238CD29" Content-Language: en-US X-Originating-IP: 66.113.196.3 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.3/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.3/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4a3/GJE3EBfL400XV90gyKCgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+ef7heanb/rBmrs7JMJfZdiPM2DmctUkuqITdPZ8a3LuY6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhMjx7v77N42Z/zX3DQBtZa/0j9rMdVQseW3F+doIupqmER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnFIqCLCdAp1y ZulYn20NGB12Yb/vIh25WdNEuByaThX0fKmWIdEXiQc4ouypg0FdaUm67ZN3qrJEsP3LZzqo5rx0 U/H2B/GSlvPp6NxayIHamhlKb/lC+C9AijoWgc8vkIGThCScvU0cCIiHSQbmcVJQWRvB876+07vu qtuiFdbiS9y9uNbs1DqwO711CiNzc5SdVUj/uc29gpaw1qlDqzTDvvmSZ61LqpFYaVCvgii6ctgz cDoFd+96Xw4QUNtTnZIVJDJOyMvgpjQe7zxV4WXM3WDxevtXAyOJWeijld3q86LodOZj79xdSjzK bqR5XHk0qi1hkw/hDGKWkPVYlXF3BhZxGgZFOwvGprxNGaa6/2rAztFeklLxGNN3KHaPkMjB65Ki hPq1I9TXHnOlSkg/OIORZDl9o+TmclcfPTQwNGP0PwcsocAqk8Y/wQ+e4HndwcgUdq9CmjcVQOst ghA= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 06:52:44 -0000 This is a multi-part message in MIME format. --------------F4283FE4F6B185DE8238CD29 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/9/2019 10:16 PM, Rob Sayre wrote: > On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla > wrote: > > > I don't think that's quite what I'm proposing. I'm proposing > (optionally) sending the SNI with a client certificate. > > > What are you trying to accomplish by doing that? > > > I want to keep the SNI encrypted in TLS hops that use client > certificates, but where ESNI won't work. > > For example, how is the SNI transmitted in the parens here: > > [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ]=C2= =A0 > > I don't think a DNS-based solution like ESNI will work for that second > hop, because the origin tends to be identified by an IP address rather > than a domain name. If the Origin is identified by IP address, an observer on path between CDN and Origin just has to look at the IP address to find out whatever information was in the SNI. Do you have a specific threat in mind? It cannot be about just the CDN and the Origin server, because observers can easily assess whether CDN X serves origin O. Are you concerned that the observer will correlate incoming traffic from client to CDN with outgoing traffic from CDN to Origin? This is an issue common to pretty much every relay service. I understand that Tor has specific algorithms for dealing with that, involving for example insertion of delays at the relay points. Is that the kind of work that you have in mind? I am not sure that it would fit easily within the TLS charter, but there are other working groups... -- Christian Huitema --------------F4283FE4F6B185DE8238CD29 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 10/9/2019 10:16 PM, Rob Sayre wrote:
On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <ekr@rtfm.com> wrote:

I don't think that's quite what I'm proposing. I'm proposing (optionally) sending the SNI with a client certificate.

What are you trying to accomplish by doing that?

I want to keep the SNI encrypted in TLS hops that use client certificates, but where ESNI won't work.

For example, how is the SNI transmitted in the parens here:

[ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] 

I don't think a DNS-based solution like ESNI will work for that second hop, because the origin tends to be identified by an IP address rather than a domain name.


If the Origin is identified by IP address, an observer on path between CDN and Origin just has to look at the IP address to find out whatever information was in the SNI.

Do you have a specific threat in mind? It cannot be about just the CDN and the Origin server, because observers can easily assess whether CDN X serves origin O. Are you concerned that the observer will correlate incoming traffic from client to CDN with outgoing traffic from CDN to Origin?

This is an issue common to pretty much every relay service. I understand that Tor has specific algorithms for dealing with that, involving for example insertion of delays at the relay points. Is that the kind of work that you have in mind? I am not sure that it would fit easily within the TLS charter, but there are other working groups...

-- Christian Huitema


--------------F4283FE4F6B185DE8238CD29-- From nobody Wed Oct 9 23:59:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE472120044 for ; Wed, 9 Oct 2019 23:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lvY0geYpBTmY for ; Wed, 9 Oct 2019 23:59:52 -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 906B0120033 for ; Wed, 9 Oct 2019 23:59:52 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id h144so11308276iof.7 for ; Wed, 09 Oct 2019 23:59:52 -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=9anxsqopoEy0GPCqBpw09ry9K1W6gjFxWbi8OYlGDK0=; b=H+ZGi31k/V1IOaxQm6TL+4vziQw0fDHT3auRBZmrPY8e5OpvcePn7Xl45x0MHCz00b L7CSKOQ6pbsvR5jGUsDhKDZTH6LIqIZW4Nd5rlvjaRqhiOZMSf+6T62BYk2dH+xrp3JV pWGIzdnLilR+JVP+tFPkXdUDvP7RFOTLQRzg/GeDE0VLEh2f/YaS3KzbxJ3g5dKEzt3A 1WZzWU93l8ERb5iUaqF7ZbDNZdwMPPY89wea+FZLYrajgIWCt9DlJ0Y+yCe+zBPsOhiM yqPI+9nf30y2Ic0EQJhmZyj6Ctub/1mt2YCOR7vwDoTzJQjrApFIMyAdxzJAjUIjKEa6 VgNg== 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=9anxsqopoEy0GPCqBpw09ry9K1W6gjFxWbi8OYlGDK0=; b=r4fhJyeBJD8auKwWiXMc2IB7tKjkOL8BB5nu40vUl4wXybmeJqYmfyqGOYRh0jJedf esUPK2edCg9P7LFHYfAXIguhOgUxPd0pY9bi9iyi27hCEShtZ/8dycK+wRaxOymFiIbn RCCtrGfwA0Pz/8W2ius/pVuRBYEPg1likC8tynuc/RMJq361vRAAGEtTUtZGZgzQlrwb dEt6l2UntJBTi2erWzffMuUdm7Sd3G/xeqabQfeigVqdvw+McG4zYlIehMoiwgby62ZA DvV33bCxx+/5G7z9XSecf9WyaLCHOG8IsiTJy7GL6D+NaSEi4JFwn/rODW8TJM1qQJjG cNqQ== X-Gm-Message-State: APjAAAVnqk5NdVfX+9tS9YyxEN7tMpWY9/yAOxoHfm6zwNGGJEukZBVL uVx4GjVTqCDQJ39USO8jZKjUrL8WlZ+eakF/tOyUJgK4mamONg== X-Google-Smtp-Source: APXvYqx3Nq0LnefUgjNTnCjzrUnTJeCsOGc8a/iTdYAillZ5eVBCnujeEC2sk4TjX2ziLy/e0ihVtKmUvdVKqcxKc90= X-Received: by 2002:a05:6638:928:: with SMTP id 8mr8576639jak.124.1570690791657; Wed, 09 Oct 2019 23:59:51 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <6500d2cd-5f62-0a00-3923-d9bc864a83e4@huitema.net> In-Reply-To: <6500d2cd-5f62-0a00-3923-d9bc864a83e4@huitema.net> From: Rob Sayre Date: Thu, 10 Oct 2019 13:59:40 +0700 Message-ID: To: Christian Huitema Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b05727059488f2ec" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 06:59:54 -0000 --000000000000b05727059488f2ec Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 1:52 PM Christian Huitema wrote: > If the Origin is identified by IP address, an observer on path between CDN > and Origin just has to look at the IP address to find out whatever > information was in the SNI. > I don't think that is true for subdomains, and I also don't think it is true if a client certificate is required (that would need to be checked before routing traffic to an application). Is there a sensible argument for leaving this traffic in the clear? thanks, Rob --000000000000b05727059488f2ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 10, 2019 at 1:52 PM Christian= Huitema <huitema@huitema.net= > wrote:

If the Origin is identified by IP address, an observer on path between CDN and Origin just has to look at the IP address to find out whatever information was in the SNI.

I= don't think that is true for subdomains, and I also don't think it= is true if a client certificate is required (that would need to be checked= before routing traffic to an application).=C2=A0

= Is there a sensible argument for leaving this traffic in the clear?

thanks,
Rob=C2=A0
--000000000000b05727059488f2ec-- From nobody Thu Oct 10 05:38:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4462C1200E5 for ; Thu, 10 Oct 2019 05:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb8ZKfsH_ea7 for ; Thu, 10 Oct 2019 05:38:08 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 A9493120113 for ; Thu, 10 Oct 2019 05:38:07 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id d1so5984813ljl.13 for ; Thu, 10 Oct 2019 05:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jrPG+wuOSqDOV49gyjgFkQ9y4X9Bif/1IWdzGQaCG84=; b=QJhCThjX67kb5gGTUCy9X/KoKNyjDZwIzZFymvxo59ZERYvDB1THehpobPZDYTkFAf mpRzIOIS70i+GBv9ctJiRwQfPJ9cPc8FR/C2VkFp3yDPLU0HhY5Ez9TW0GXdM6alOf7E Jg4wGqU7dOZUk10rE352/PN3gAZpLHkHbdcp5y8fIdZ9xp2qheQP2KvmitaVzG+AgfXz 2t2/wAs6nYJTCkDoQL0jdCEk/gMjMB5zyczSO0CIBrqFzBjkb8yzdKh8FIeV4KrKt8s6 WfGlmhTC9/JjkwZJVNL+rxZsbfNSK4D5EC2yZqTw6MWTBUwCrpGwP4r8Z5eRpYOIMnDC 2kPw== 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=jrPG+wuOSqDOV49gyjgFkQ9y4X9Bif/1IWdzGQaCG84=; b=q33l0Ab2ZxW7i/Wv2eUMqrDisrlJ2RyV/VWhGjiGwIxrKoxvvs0Db9mzVCh4Yadajz /AuUGn8UBoOb9XUuvU6pDA+WkXDOWOUJiYPM7HF8Sve/cbrVDCX6h4t9KCty9pF1rtg2 2Y2XGvU9gfoDlg2QqkgYi0UMsSaDumIgMpJBJRdlGtxvP/8dZHqUoY7Miraf53/s+mrv il1Jj93ScUCYUmRNFXrneVdJoW8Wq4OuTPWhR6yL7jUdCoXI+fAtKDtfjx8Ov2qN8bWc Pik/98NtG+7/LEbJrVRzt45LerwOl2XAR+OCp0RjVnheXfJk/BfMd5YgDqUhgJhZWDcE V9qQ== X-Gm-Message-State: APjAAAV4gSc9ljN4cdtn2/WEDmoSqJAmRbFEZ2dwNj6RLMRViBxrjewO 95Azb6owYzRNYV3DsqzTk1PHKpeGObs6QjtGRXHoeqdmWfE= X-Google-Smtp-Source: APXvYqxzTF3toK98/rS6u8r7AewPPMPOx/qh0LUhI9i7ZhmA3kHpklkOuKc8JffuoBkrkT1RPoAM1eryM2CBi62hMJo= X-Received: by 2002:a05:651c:1031:: with SMTP id w17mr6228478ljm.38.1570711085748; Thu, 10 Oct 2019 05:38:05 -0700 (PDT) MIME-Version: 1.0 References: <69c7cfbd-fe9f-40fa-b92b-e4b65fa6cb5d@www.fastmail.com> In-Reply-To: <69c7cfbd-fe9f-40fa-b92b-e4b65fa6cb5d@www.fastmail.com> From: Eric Rescorla Date: Thu, 10 Oct 2019 05:37:29 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="0000000000004faa6505948dac57" Archived-At: Subject: Re: [TLS] DTLS Key Separation PR X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 12:38:11 -0000 --0000000000004faa6505948dac57 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 7:01 PM Martin Thomson wrote: > tl;dr keep the space. > > I had a little trouble reproducing the 12 from RFC 8446, so I > double-checked. > > .... > > Working from the base for SHA-256: > > The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one > to allow for padding. Therefore we have 55 bytes to use without having to > run two blocks through SHA-256. > > HMAC-Hash = H(K XOR opad || H(K XOR ipad || text)) > > Here `K XOR ipad` is the 32 bytes output size of SHA-256, so we are down > to 23 bytes for text before it adds a block. > In HMAC the key consumes an entire input block, so that you are guaranteed a compression function cycle before the data is added: 1) append zeros to the end of K to create a B byte string (e.g., if K is of length 20 bytes and B=64, then K will be appended with 44 zero bytes 0x00) (2) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with ipad https://tools.ietf.org/rfcmarkup?doc=2104#section-2 This shifts everything to the right 32 bytes, which, because context is 32 bytes, gets us back to 12, I think, though I haven't re-worked through it. Here's Ilari's original analysis, if that's helpful: https://mailarchive.ietf.org/arch/msg/tls/n_TFape7L4HHoKLxGo8CkimZziI -Ekr > HKDF-Expand = HMAC-Hash(PRK, info | 0x01) > > This takes one more. Down to 22. > > HKDF-Expand-Label passes info in the form of: > > struct { > uint16 length = Length; > opaque label<7..255> = "tls13 " + Label; > opaque context<0..255> = Context; > } HkdfLabel; > > which has a minimal overhead of 2 + 1 + len("tls13 ") + 1 = 10. So we get > 12. > > "c ap traffic" is 12 bytes long, so yeah it *looks* like we're stuck if we > care about not adding too many extra hash iterations. > > .... > > But if you look at the key schedule, we always provide a context for those > cases we use "c ap traffic". Those will always spill over into the next > iteration as Context is 32 bytes. So for those cases, we have a whole 32 > bytes extra to play with. The only cases with an empty Context are > "derived" and "res binder"|"ext binder". Those max out at 10, so we seem > to have two whole bytes of wiggle room. > > You can safely add the space. > > On Wed, Oct 2, 2019, at 08:40, Eric Rescorla wrote: > > Hi folks, > > > > As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key > separation. > > > > See: > > https://github.com/tlswg/dtls13-spec/pull/99 > > > > Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13" > > > > -Ekr > > > > _______________________________________________ > > 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 > --0000000000004faa6505948dac57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 7:01 PM Martin= Thomson <mt@lowentropy.net>= wrote:
tl;dr ke= ep the space.

I had a little trouble reproducing the 12 from RFC 8446, so I double-checke= d.

....

Working from the base for SHA-256:

The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one to= allow for padding.=C2=A0 Therefore we have 55 bytes to use without having = to run two blocks through SHA-256.

HMAC-Hash =3D H(K XOR opad || H(K XOR ipad || text))

Here `K XOR ipad` is the 32 bytes output size of SHA-256, so we are down to= 23 bytes for text before it adds a block.

<= div>In HMAC the key consumes an entire input block, so that you are guarant= eed a compression function cycle before the data is added:

1) append zeros=
 to the end of K to create a B byte string
        (e.g., if K is of length 20 bytes and B=3D64, then K will be
         appended with 44 zero bytes 0x00)
    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
        (1) with ipad

https://tools.ietf.org/rfcmarkup?doc=3D2104#section-2
This shifts everything to the right 32 bytes, which, because =
context is 32 bytes, gets us back to 12, I think, though I haven't re-w=
orked through it. 

Here's Ilari's original analy=
sis, if that's helpful:
https://mailarchive.ietf.org/arch/msg=
/tls/n_TFape7L4HHoKLxGo8CkimZziI

-Ekr

=



=C2=A0
HKDF-Expand =3D=C2=A0 HMAC-Hash(PRK, info | 0x01)

This takes one more.=C2=A0 Down to 22.

HKDF-Expand-Label passes info in the form of:

=C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 length =3D Length;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque label<7..255> =3D &qu= ot;tls13 " + Label;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque context<0..255> =3D C= ontext;
=C2=A0 =C2=A0 =C2=A0 =C2=A0} HkdfLabel;

which has a minimal overhead of 2 + 1 + len("tls13 ") + 1 =3D 10.= =C2=A0 So we get 12.

"c ap traffic" is 12 bytes long, so yeah it *looks* like we'r= e stuck if we care about not adding too many extra hash iterations.

....

But if you look at the key schedule, we always provide a context for those = cases we use "c ap traffic".=C2=A0 Those will always spill over i= nto the next iteration as Context is 32 bytes.=C2=A0 So for those cases, we= have a whole 32 bytes extra to play with.=C2=A0 The only cases with an emp= ty Context are "derived" and "res binder"|"ext bin= der".=C2=A0 Those max out at 10, so we seem to have two whole bytes of= wiggle room.

You can safely add the space.

On Wed, Oct 2, 2019, at 08:40, Eric Rescorla wrote:
> Hi folks,
>
> As discussed in Montreal, I've prepared a PR to give us DTLS/TLS k= ey separation.
>
> See:
> https://github.com/tlswg/dtls13-spec/pull/99 >
> Sadly. we didn't have enough space for "dtls13 " so I we= nt for "dtls13"
>
> -Ekr
>
> _______________________________________________
> 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
--0000000000004faa6505948dac57-- From nobody Thu Oct 10 07:07:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7D1200C1 for ; Thu, 10 Oct 2019 07:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7hmgm4rQgjNr for ; Thu, 10 Oct 2019 07:07:52 -0700 (PDT) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 2197C120099 for ; Thu, 10 Oct 2019 07:07:52 -0700 (PDT) Received: by mail-vk1-xa2d.google.com with SMTP id v78so1366965vke.4 for ; Thu, 10 Oct 2019 07:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/ARW+97LjpsSr/uBJxgkV4R+I4QeI0LHKHlU1qW7jkU=; b=h+2KVkoCey9Lbo4CDmIvP5LpSN/MxPQVqLZ8poO0XNm2qaBP9pJ6I/pOg2GpsrrSin PoYMHTmEPqFLDnF+440bNPrX+xKhP1v6An4tNgH51uFqTRkYRLpHNOXoJH3nCvwvz6/Q eVcMmh6bL91f95Nlq2ayC+HtZlYi1oqduNBgw= 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=/ARW+97LjpsSr/uBJxgkV4R+I4QeI0LHKHlU1qW7jkU=; b=eXlw/mrbPFJDbSAE8wcY8/m402A+o+hseQ8uFXvT+OwUTT6mlIW3kWo48FZguqHTyo cUyBPWh3NY5msJNBqotUy1F8v1iJlgn10ZOyfmUhjaFuAtd8TOtbXiZsyTWLZ/9Ct4l7 ur+0BpC+yPyqndh+RTA6l0Gi9KOFXw56S4YJ/0ivJmeaHzuelAZ1pwv1AZycy9qNhMz2 Xl8e+C2kEewaD5S2XOohDWHW9XUt2qoqNHr24vqwm71aJi1njGLE3ym9BqKhEKbjhbt0 0xLpL8EBLRq/9fl4t4UAGcgb3/iV4AA4FaBU8T5Drj+//n995KazHpmlJlbbxyUUZ7Xl SI9Q== X-Gm-Message-State: APjAAAVgaCH7Xp1nCla58wdq8bbKgd9NRcItOMQ+9qUBlsQXKnupkGhJ 2M1U3drewWgPlTh5duN9Sd9Pfw2uyFfEeUvKWb+D1dEDEIw= X-Google-Smtp-Source: APXvYqzmCYbl4U1H1DwUj+e+U6+Rg0BeoopKhrittiR3UxQOqKHXGe/diclT5otwd8WCk8bP5eOonRCqic2pGaqV7sk= X-Received: by 2002:a1f:1d15:: with SMTP id d21mr5462689vkd.55.1570716470690; Thu, 10 Oct 2019 07:07:50 -0700 (PDT) MIME-Version: 1.0 References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com> In-Reply-To: <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com> From: Nick Sullivan Date: Thu, 10 Oct 2019 07:07:39 -0700 Message-ID: To: Martin Thomson Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000004791bd05948eeddb" Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 14:07:56 -0000 --0000000000004791bd05948eeddb Content-Type: text/plain; charset="UTF-8" The main concern I had about including DTLS explicitly in this document was because exporters are not officially defined for DTLS. However, some other documents assume they are portable so maybe this is an overly conservative choice. On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson wrote: > I think that the DTLS thing doesn't require as much rewriting as > observed. Just say that when you say "TLS" you mean "TLS or DTLS" > somewhere up front. > > As to what a transport needs to provide, I think that there is no real > text to add regarding DTLS. You *could* say that as the application > protocol is responsible for carrying the messages, might find that using a > DTLS connection introduces new problems. Specially, these are big messages > and they are likely to require fragmentation and reassembly if DTLS is > used. Also, if the protocol depends on these messages being reliably > delivered, it will want to provide some sort of loss recovery mechanism. > > On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote: > > Thanks again for your review! The PR is on Github > > (https://github.com/tlswg/tls-exported-authenticator/pull/50) and will > > be incorporated into a new version of the document that addresses both > > your comments and those by Yaron Sheffer. > > > > On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg > > wrote: > > > Hi, > > > > > > >Some answers to your questions inline. I'm not sure further changes > along the lines suggested here are needed, but I'm open to arguments that > point in that direction. > > > > > > I am mostly fine with your answers. Just a couple of comments inline > still. > > > > > > --- > > > > > > MIN_2: > > > > > > >>>> Can the mechanism be used also for DTLS? > > > >>> > > > >>> I think the answer is yes. I don't see any reason to disallow the > use of Exported Authenticators in DTLS. > > > >> > > > >> Would it be useful to clarify that? > > > > > > > > Going through what the modified text would look like, it seems like > a substantial amount of re-writing (even the title!) for what amounts to an > unclear use case. > > > > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't > directly define exporters, I'm disinclined to define how EAs would work > with DTLS. If someone > > > > has a strong use case for EA in DTLS, it may be worth considering > it. > > > > > > Would it then be useful with a statement saying that it might be > possible to use exporters also with DTLS, but that such usage is outside > the scope of the document and needs to be specified in a separate document? > > > > I added a line to this effect. > > > > > > --- > > > > > > MIN_3: > > > > > > >>>> The documents talk about additional certificates. If I only have > one additional > > > >>>> certificate, can I use that for multiple authenticators > throughout the TLS > > > >>>> session? > > > >>> > > > >>> Yes, there is nothing disallowing the creation of multiple > exported authenticators with the same certificate. > > > >> > > > >> Would it be useful to clarify that? > > > > > > > > I'm not convinced this is a realistic use case. Since exported > authenticators are based on the exporter, there is no inherent ordering. > > > > If you re-authenticate with the same certificate, there's nothing > asserting freshness of the second certificate. Is there something in > > > > the text that suggests that using a certificate multiple times is > disallowed? If there's no suggestion that this is not possible that > > > > needs to be corrected, I don't see the benefit of calling out this > specific use case. > > > > > > I don't think there is any text suggesting that it is disallowed. > But, if you don't think it is a realistic use case I'll take your word for > it :) > > > > > > --- > > > > > > ED_2: > > > > > > >>>> Section 3 says: "The authenticator request is a structured > message that can be > > > >>>> created..." Section 4 says: "The authenticator is a structured > message that can > > > >>>> be exported..." > > > >>>> > > > >>>> In the 2nd paragraph of Section 4 it is stated that > "authenticator" is sent > > > >>>> based on an "authenticator request". I wonder if that could be > stated already > > > >>>> in the beginning of Section 4, to further clarify the difference > between them. > > > >>>> E.g., > > > >>>> > > > >>>> "The authenticator is a structured message, triggered by an > authenticator > > > >>>> request, that can be exported from either party of a TLS > connection." > > > >>> > > > >>> The issue is that servers can generate spontaneous exported > authenticators without > > > >>> an authenticator request. > > > >> > > > >> Where is this written? Did I miss it? > > > > > > > > Section 4: > > > > An authenticator message can be constructed by either the client or > > > > the server given an established TLS connection, a certificate, and a > > > > corresponding private key. Clients MUST NOT send an authenticator > > > > without a preceding authenticator request; for servers an > > > > authenticator request is optional. For authenticators that do not > > > > correspond to authenticator requests, the > certificate_request_context > > > > is chosen by the server. > > > > > > Ok. Looks good. > > > > > > Regards, > > > > > > Christer > > > > > > > > _______________________________________________ > > 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 > --0000000000004791bd05948eeddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The main concern I had about including DTLS explicit= ly in this document was because exporters are not officially defined for DT= LS. However, some other documents assume they are portable so maybe this is= an overly conservative choice.

On Wed, Oct 9, 2019 at 6:26 PM Ma= rtin Thomson <mt@lowentropy.net= > wrote:
I think that the DTLS t= hing doesn't require as much rewriting as observed.=C2=A0 Just say that= when you say "TLS" you mean "TLS or DTLS" somewhere up= front.

As to what a transport needs to provide, I think that there is no real text= to add regarding DTLS.=C2=A0 You *could* say that as the application proto= col is responsible for carrying the messages, might find that using a DTLS = connection introduces new problems.=C2=A0 Specially, these are big messages= and they are likely to require fragmentation and reassembly if DTLS is use= d.=C2=A0 Also, if the protocol depends on these messages being reliably del= ivered, it will want to provide some sort of loss recovery mechanism.

On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote:
> Thanks again for your review! The PR is on Github
> (https://github.com/tlswg/tls-export= ed-authenticator/pull/50) and will
> be incorporated into a new version of the document that addresses both=
> your comments and those by Yaron Sheffer.
>
> On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
> > Hi,
> >
> >=C2=A0 >Some answers to your questions inline. I'm not sure= further changes along the lines suggested here are needed, but I'm ope= n to arguments that point in that direction.
> >
> >=C2=A0 I am mostly fine with your answers. Just a couple of commen= ts inline still.
> >
> >=C2=A0 ---
> >
> >=C2=A0 MIN_2:
> >
> >=C2=A0 >>>> Can the mechanism be used also for DTLS? > >=C2=A0 >>>
> >=C2=A0 >>> I think the answer is yes. I don't see any= reason to disallow the use of Exported Authenticators in DTLS.
> >=C2=A0 >>
> >=C2=A0 >> Would it be useful to clarify that?
> >=C2=A0 >
> >=C2=A0 > Going through what the modified text would look like, = it seems like a substantial amount of re-writing (even the title!) for what= amounts to an unclear use case.
> >=C2=A0 > Keeping in mind that DTLS 1.3 hasn't been finalize= d and doesn't directly define exporters, I'm disinclined to define = how EAs would work with DTLS. If someone
> >=C2=A0 > has a strong use case for EA in DTLS, it may be worth = considering it.
> >
> >=C2=A0 Would it then be useful with a statement saying that it mig= ht be possible to use exporters also with DTLS, but that such usage is outs= ide the scope of the document and needs to be specified in a separate docum= ent?
>
> I added a line to this effect.
> >
> >=C2=A0 ---
> >
> >=C2=A0 MIN_3:
> >
> >=C2=A0 >>>> The documents talk about additional certif= icates. If I only have one additional
> >=C2=A0 >>>> certificate, can I use that for multiple a= uthenticators throughout the TLS
> >=C2=A0 >>>> session?
> >=C2=A0 >>>
> >=C2=A0 >>> Yes, there is nothing disallowing the creation= of multiple exported authenticators with the same certificate.
> >=C2=A0 >>
> >=C2=A0 >> Would it be useful to clarify that?
> >=C2=A0 >
> >=C2=A0 > I'm not convinced this is a realistic use case. Si= nce exported authenticators are based on the exporter, there is no inherent= ordering.
> >=C2=A0 > If you re-authenticate with the same certificate, ther= e's nothing asserting freshness of the second certificate. Is there som= ething in
> >=C2=A0 > the text that suggests that using a certificate multip= le times is disallowed? If there's no suggestion that this is not possi= ble that
> >=C2=A0 > needs to be corrected, I don't see the benefit of = calling out this specific use case.
> >
> >=C2=A0 I don't think there is any text suggesting that it is d= isallowed. But, if you don't think it is a realistic use case I'll = take your word for it :)
> >
> >=C2=A0 ---
> >
> >=C2=A0 ED_2:
> >
> >=C2=A0 >>>> Section 3 says: "The authenticator re= quest is a structured message that can be
> >=C2=A0 >>>> created..." Section 4 says: "The= authenticator is a structured message that can
> >=C2=A0 >>>> be exported..."
> >=C2=A0 >>>>
> >=C2=A0 >>>> In the 2nd paragraph of Section 4 it is st= ated that "authenticator" is sent
> >=C2=A0 >>>> based on an "authenticator request&qu= ot;. I wonder if that could be stated already
> >=C2=A0 >>>> in the beginning of Section 4, to further = clarify the difference between them.
> >=C2=A0 >>>> E.g.,
> >=C2=A0 >>>>
> >=C2=A0 >>>> "The authenticator is a structured me= ssage, triggered by an authenticator
> >=C2=A0 >>>> request, that can be exported from either = party of a TLS connection."
> >=C2=A0 >>>
> >=C2=A0 >>> The issue is that servers can generate spontan= eous exported authenticators without
> >=C2=A0 >>> an authenticator request.
> >=C2=A0 >>
> >=C2=A0 >> Where is this written? Did I miss it?
> >=C2=A0 >
> >=C2=A0 > Section 4:
> >=C2=A0 > An authenticator message can be constructed by either = the client or
> >=C2=A0 > the server given an established TLS connection, a cert= ificate, and a
> >=C2=A0 > corresponding private key. Clients MUST NOT send an au= thenticator
> >=C2=A0 > without a preceding authenticator request; for servers= an
> >=C2=A0 > authenticator request is optional. For authenticators = that do not
> >=C2=A0 > correspond to authenticator requests, the certificate_= request_context
> >=C2=A0 > is chosen by the server.
> >
> >=C2=A0 Ok. Looks good.
> >
> >=C2=A0 Regards,
> >
> >=C2=A0 Christer
> >
> >
> _______________________________________________
> 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
--0000000000004791bd05948eeddb-- From nobody Thu Oct 10 07:37:00 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29361200C1 for ; Thu, 10 Oct 2019 07:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_hp_6WrAvbM for ; Thu, 10 Oct 2019 07:36:54 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75048120018 for ; Thu, 10 Oct 2019 07:36:53 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id c195so4568735lfg.9 for ; Thu, 10 Oct 2019 07:36:53 -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=BKbxl0Llj5SNsAm7793ZM2v7TvXBNai78KLepuMeQaI=; b=cm535rWRFfVG5pEXHY13X1Cxy8KirO5IpokuvnGpHTy/Dof3bn57ly4knxq0PKQqK+ tYmL5PUzLspwrP+ECedp71RFk9Dt4UFf5DkH2URe/jaRfemO+esOuCrcAkYO2e0Jcpk0 O6FelrbJgZfL/3OJ6cJ1zpytdqYDi/9IDgYdnPpzytO9DpvWOIVTxChJWdy5q5jEqRUt NCIIaMZyMScnDr6FpChh2w3rl0qhC6dhdJzjYSAkFWwS8HsHVY3O24ftl8niV6tUFEdG QkcVlVSxiSqAJo6BVHPbiuTfIRTl5hlYot6bhPFCDWm1DQhUxYq8KYkUMUaFDFhuNrcK Nreg== 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=BKbxl0Llj5SNsAm7793ZM2v7TvXBNai78KLepuMeQaI=; b=ZyXaXNQkEBlK407AGXqv6RKNGo632FQiqp8ZMgfPHC8/yhcxYqPRq1x6Y2dMegQ6T7 YlYOE+Xg+HOyckwQgQVSK74mMFw108SOGM0Lg1dgjSbHXuZcUN1RKFE16lhmZVOui2s2 kZPHHejLEb2IjtVm5j6eF2w2SdVkb6eZv9VxvVj7y6oDIzdCSwCIEm3ohbEzHdWwNHV8 eKQr7Pc+wBYY4PoYNKbVtUTp2tnAOv4xoCz3G5PZk5r5cHTRg+3M2PZaMLIKm9zwOXqX qlQPILAiTHt7AWm261G8NVQops1dVwCJWnBBSnPdYdwTRHwMFkZimob3PM0AvC1n25Ku LYwQ== X-Gm-Message-State: APjAAAV9uMdF4FALJCGVbBF+Z3NpF4zBkLPIklwLth27Gs/3Y8aQvjLm 92l5S/8OtgPLLdXZ+iPD1JEJhq0MRPrAVKKf/jpTZA== X-Google-Smtp-Source: APXvYqzRaG8qyJyEcZEeeVKE7QEik+mtfFWHKUfiDRJtwg6KAxpNFPkzX2pwHNidvn73IKy1ZDXxpnkajq3tfUzjZsU= X-Received: by 2002:a19:7404:: with SMTP id v4mr1223420lfe.129.1570718211653; Thu, 10 Oct 2019 07:36:51 -0700 (PDT) MIME-Version: 1.0 References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> <0cf4806b-3825-4d25-8be0-13c27533b08d@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Thu, 10 Oct 2019 07:36:14 -0700 Message-ID: To: Nick Sullivan Cc: Martin Thomson , "" Content-Type: multipart/alternative; boundary="0000000000000c569e05948f5561" Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 14:36:59 -0000 --0000000000000c569e05948f5561 Content-Type: text/plain; charset="UTF-8" Well, DTLS is one of the primary consumers of exporters https://tools.ietf.org/rfcmarkup?doc=5764, so as a practical matter I think we've accepted that. I'm not aware of a practical problem with exporters and DTLS, but if there is one, we should document it and address it. -Ekr On Thu, Oct 10, 2019 at 7:08 AM Nick Sullivan wrote: > The main concern I had about including DTLS explicitly in this document > was because exporters are not officially defined for DTLS. However, some > other documents assume they are portable so maybe this is an overly > conservative choice. > > On Wed, Oct 9, 2019 at 6:26 PM Martin Thomson wrote: > >> I think that the DTLS thing doesn't require as much rewriting as >> observed. Just say that when you say "TLS" you mean "TLS or DTLS" >> somewhere up front. >> >> As to what a transport needs to provide, I think that there is no real >> text to add regarding DTLS. You *could* say that as the application >> protocol is responsible for carrying the messages, might find that using a >> DTLS connection introduces new problems. Specially, these are big messages >> and they are likely to require fragmentation and reassembly if DTLS is >> used. Also, if the protocol depends on these messages being reliably >> delivered, it will want to provide some sort of loss recovery mechanism. >> >> On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote: >> > Thanks again for your review! The PR is on Github >> > (https://github.com/tlswg/tls-exported-authenticator/pull/50) and will >> > be incorporated into a new version of the document that addresses both >> > your comments and those by Yaron Sheffer. >> > >> > On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg >> > wrote: >> > > Hi, >> > > >> > > >Some answers to your questions inline. I'm not sure further changes >> along the lines suggested here are needed, but I'm open to arguments that >> point in that direction. >> > > >> > > I am mostly fine with your answers. Just a couple of comments inline >> still. >> > > >> > > --- >> > > >> > > MIN_2: >> > > >> > > >>>> Can the mechanism be used also for DTLS? >> > > >>> >> > > >>> I think the answer is yes. I don't see any reason to disallow >> the use of Exported Authenticators in DTLS. >> > > >> >> > > >> Would it be useful to clarify that? >> > > > >> > > > Going through what the modified text would look like, it seems >> like a substantial amount of re-writing (even the title!) for what amounts >> to an unclear use case. >> > > > Keeping in mind that DTLS 1.3 hasn't been finalized and doesn't >> directly define exporters, I'm disinclined to define how EAs would work >> with DTLS. If someone >> > > > has a strong use case for EA in DTLS, it may be worth considering >> it. >> > > >> > > Would it then be useful with a statement saying that it might be >> possible to use exporters also with DTLS, but that such usage is outside >> the scope of the document and needs to be specified in a separate document? >> > >> > I added a line to this effect. >> > > >> > > --- >> > > >> > > MIN_3: >> > > >> > > >>>> The documents talk about additional certificates. If I only >> have one additional >> > > >>>> certificate, can I use that for multiple authenticators >> throughout the TLS >> > > >>>> session? >> > > >>> >> > > >>> Yes, there is nothing disallowing the creation of multiple >> exported authenticators with the same certificate. >> > > >> >> > > >> Would it be useful to clarify that? >> > > > >> > > > I'm not convinced this is a realistic use case. Since exported >> authenticators are based on the exporter, there is no inherent ordering. >> > > > If you re-authenticate with the same certificate, there's nothing >> asserting freshness of the second certificate. Is there something in >> > > > the text that suggests that using a certificate multiple times is >> disallowed? If there's no suggestion that this is not possible that >> > > > needs to be corrected, I don't see the benefit of calling out this >> specific use case. >> > > >> > > I don't think there is any text suggesting that it is disallowed. >> But, if you don't think it is a realistic use case I'll take your word for >> it :) >> > > >> > > --- >> > > >> > > ED_2: >> > > >> > > >>>> Section 3 says: "The authenticator request is a structured >> message that can be >> > > >>>> created..." Section 4 says: "The authenticator is a structured >> message that can >> > > >>>> be exported..." >> > > >>>> >> > > >>>> In the 2nd paragraph of Section 4 it is stated that >> "authenticator" is sent >> > > >>>> based on an "authenticator request". I wonder if that could be >> stated already >> > > >>>> in the beginning of Section 4, to further clarify the >> difference between them. >> > > >>>> E.g., >> > > >>>> >> > > >>>> "The authenticator is a structured message, triggered by an >> authenticator >> > > >>>> request, that can be exported from either party of a TLS >> connection." >> > > >>> >> > > >>> The issue is that servers can generate spontaneous exported >> authenticators without >> > > >>> an authenticator request. >> > > >> >> > > >> Where is this written? Did I miss it? >> > > > >> > > > Section 4: >> > > > An authenticator message can be constructed by either the client or >> > > > the server given an established TLS connection, a certificate, and >> a >> > > > corresponding private key. Clients MUST NOT send an authenticator >> > > > without a preceding authenticator request; for servers an >> > > > authenticator request is optional. For authenticators that do not >> > > > correspond to authenticator requests, the >> certificate_request_context >> > > > is chosen by the server. >> > > >> > > Ok. Looks good. >> > > >> > > Regards, >> > > >> > > Christer >> > > >> > > >> > _______________________________________________ >> > 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 > --0000000000000c569e05948f5561 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, DTLS is one of the primary consumers of exporte= rs https://tools.ie= tf.org/rfcmarkup?doc=3D5764, so as a practical matter I think we've= accepted that. I'm not aware of a practical problem with exporters and= DTLS, but if there is one, we should document it and address it.

-Ekr


On Thu, Oct 10, 2019 at 7:08 AM Ni= ck Sullivan <nick=3D4= 0cloudflare.com@dmarc.ietf.org> wrote:
The main concern I had= about including DTLS explicitly in this document was because exporters are= not officially defined for DTLS. However, some other documents assume they= are portable so maybe this is an overly conservative choice.

On = Wed, Oct 9, 2019 at 6:26 PM Martin Thomson <mt@lowentropy.net> wrote:
I think that the DTLS thing doe= sn't require as much rewriting as observed.=C2=A0 Just say that when yo= u say "TLS" you mean "TLS or DTLS" somewhere up front.<= br>
As to what a transport needs to provide, I think that there is no real text= to add regarding DTLS.=C2=A0 You *could* say that as the application proto= col is responsible for carrying the messages, might find that using a DTLS = connection introduces new problems.=C2=A0 Specially, these are big messages= and they are likely to require fragmentation and reassembly if DTLS is use= d.=C2=A0 Also, if the protocol depends on these messages being reliably del= ivered, it will want to provide some sort of loss recovery mechanism.

On Thu, Oct 10, 2019, at 11:47, Nick Sullivan wrote:
> Thanks again for your review! The PR is on Github
> (https://github.com/tlswg/tls-export= ed-authenticator/pull/50) and will
> be incorporated into a new version of the document that addresses both=
> your comments and those by Yaron Sheffer.
>
> On Thu, Sep 19, 2019 at 11:29 PM Christer Holmberg
> <christer.holmberg@ericsson.com> wrote:
> > Hi,
> >
> >=C2=A0 >Some answers to your questions inline. I'm not sure= further changes along the lines suggested here are needed, but I'm ope= n to arguments that point in that direction.
> >
> >=C2=A0 I am mostly fine with your answers. Just a couple of commen= ts inline still.
> >
> >=C2=A0 ---
> >
> >=C2=A0 MIN_2:
> >
> >=C2=A0 >>>> Can the mechanism be used also for DTLS? > >=C2=A0 >>>
> >=C2=A0 >>> I think the answer is yes. I don't see any= reason to disallow the use of Exported Authenticators in DTLS.
> >=C2=A0 >>
> >=C2=A0 >> Would it be useful to clarify that?
> >=C2=A0 >
> >=C2=A0 > Going through what the modified text would look like, = it seems like a substantial amount of re-writing (even the title!) for what= amounts to an unclear use case.
> >=C2=A0 > Keeping in mind that DTLS 1.3 hasn't been finalize= d and doesn't directly define exporters, I'm disinclined to define = how EAs would work with DTLS. If someone
> >=C2=A0 > has a strong use case for EA in DTLS, it may be worth = considering it.
> >
> >=C2=A0 Would it then be useful with a statement saying that it mig= ht be possible to use exporters also with DTLS, but that such usage is outs= ide the scope of the document and needs to be specified in a separate docum= ent?
>
> I added a line to this effect.
> >
> >=C2=A0 ---
> >
> >=C2=A0 MIN_3:
> >
> >=C2=A0 >>>> The documents talk about additional certif= icates. If I only have one additional
> >=C2=A0 >>>> certificate, can I use that for multiple a= uthenticators throughout the TLS
> >=C2=A0 >>>> session?
> >=C2=A0 >>>
> >=C2=A0 >>> Yes, there is nothing disallowing the creation= of multiple exported authenticators with the same certificate.
> >=C2=A0 >>
> >=C2=A0 >> Would it be useful to clarify that?
> >=C2=A0 >
> >=C2=A0 > I'm not convinced this is a realistic use case. Si= nce exported authenticators are based on the exporter, there is no inherent= ordering.
> >=C2=A0 > If you re-authenticate with the same certificate, ther= e's nothing asserting freshness of the second certificate. Is there som= ething in
> >=C2=A0 > the text that suggests that using a certificate multip= le times is disallowed? If there's no suggestion that this is not possi= ble that
> >=C2=A0 > needs to be corrected, I don't see the benefit of = calling out this specific use case.
> >
> >=C2=A0 I don't think there is any text suggesting that it is d= isallowed. But, if you don't think it is a realistic use case I'll = take your word for it :)
> >
> >=C2=A0 ---
> >
> >=C2=A0 ED_2:
> >
> >=C2=A0 >>>> Section 3 says: "The authenticator re= quest is a structured message that can be
> >=C2=A0 >>>> created..." Section 4 says: "The= authenticator is a structured message that can
> >=C2=A0 >>>> be exported..."
> >=C2=A0 >>>>
> >=C2=A0 >>>> In the 2nd paragraph of Section 4 it is st= ated that "authenticator" is sent
> >=C2=A0 >>>> based on an "authenticator request&qu= ot;. I wonder if that could be stated already
> >=C2=A0 >>>> in the beginning of Section 4, to further = clarify the difference between them.
> >=C2=A0 >>>> E.g.,
> >=C2=A0 >>>>
> >=C2=A0 >>>> "The authenticator is a structured me= ssage, triggered by an authenticator
> >=C2=A0 >>>> request, that can be exported from either = party of a TLS connection."
> >=C2=A0 >>>
> >=C2=A0 >>> The issue is that servers can generate spontan= eous exported authenticators without
> >=C2=A0 >>> an authenticator request.
> >=C2=A0 >>
> >=C2=A0 >> Where is this written? Did I miss it?
> >=C2=A0 >
> >=C2=A0 > Section 4:
> >=C2=A0 > An authenticator message can be constructed by either = the client or
> >=C2=A0 > the server given an established TLS connection, a cert= ificate, and a
> >=C2=A0 > corresponding private key. Clients MUST NOT send an au= thenticator
> >=C2=A0 > without a preceding authenticator request; for servers= an
> >=C2=A0 > authenticator request is optional. For authenticators = that do not
> >=C2=A0 > correspond to authenticator requests, the certificate_= request_context
> >=C2=A0 > is chosen by the server.
> >
> >=C2=A0 Ok. Looks good.
> >
> >=C2=A0 Regards,
> >
> >=C2=A0 Christer
> >
> >
> _______________________________________________
> 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
--0000000000000c569e05948f5561-- From nobody Thu Oct 10 08:53:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2A11202DD for ; Thu, 10 Oct 2019 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 m4YEvuZdA3H1 for ; Thu, 10 Oct 2019 08:53:19 -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 8499A120802 for ; Thu, 10 Oct 2019 08:53:19 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9AFqfNv031195; Thu, 10 Oct 2019 16:53:17 +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=F+tZWFW+1S0HtuPGaN4jQ3wokvGe66/OYu3uZDcKur4=; b=X7DEntlcWGU8GF/RKPXe2JdAg8rLEmHj/L2VcW7QxJ9/u6lNwZy1P1+1Z9e7NypVUFu3 hfbWkKRQsMspWp0g8n9QuUInusbaioczQEHw3V/MC2jR7qTCu5bTKbb2hOzg79UVG9QE menIGr4ptCsDLFzozv94zQmxFYDkASSYStvOn6mMKOaqueIk2HaYC5f2ETnTEO1p5ID0 QbRknvqlf28ra1ytKiI1goDTo2unkeUCNWMQjFFVEdp7XMt72/rtbqtcSazHleYjltY9 su3an8sKk3aesC6BNfTnj7yn8BTec2Df2/GBP4Bfvg39YLI35KhN44vwrXNB5WOwehXO Sw== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2veg1u1dbv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 16:53:17 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9AFmDoW008191; Thu, 10 Oct 2019 11:53:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint7.akamai.com with ESMTP id 2veph0pf4c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 11:53:15 -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.1473.3; Thu, 10 Oct 2019 10:53:14 -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.1473.005; Thu, 10 Oct 2019 10:53:14 -0500 From: "Salz, Rich" To: Rob Sayre , Eric Rescorla CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAIAARAMA///HFYCAAEduAIAAASmAgAABBID//74fAIAARG0AgAAAdACAAQ9OAIAAbsyA Date: Thu, 10 Oct 2019 15:53:14 +0000 Message-ID: <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.161] Content-Type: multipart/alternative; boundary="_000_7F634AD9590941B0AB08D6FA6AB0C816akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-10_05:, , 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-1908290000 definitions=main-1910100145 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-10_05:2019-10-10,2019-10-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 adultscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910100146 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 15:53:33 -0000 --_000_7F634AD9590941B0AB08D6FA6AB0C816akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSB3YW50IHRvIGtlZXAgdGhlIFNOSSBlbmNyeXB0ZWQgaW4gVExTIGhvcHMgdGhhdCB1 c2UgY2xpZW50IGNlcnRpZmljYXRlcywgYnV0IHdoZXJlIEVTTkkgd29uJ3Qgd29yay4NCg0KSSBo YXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoaXMsIHNlZSBiZWxvdy4NCg0KDQogICogICBGb3Ig ZXhhbXBsZSwgaG93IGlzIHRoZSBTTkkgdHJhbnNtaXR0ZWQgaW4gdGhlIHBhcmVucyBoZXJlOg0K DQoNCiAgKiAgIFsgQ2xpZW50IF0gLS0tLS0+IChFU05JKSAtLS0tLT4gWyBDRE4gXSAtLS0tLT4g KD8/PykgLS0tLS0+IFsgT3JpZ2luIF0NCg0KSXQgaXMgdHJhbnNtaXR0ZWQgaW4gdGhlIGNsZWFy LiAgVGhlcmUgaXMgbm8gYXJjaGl0ZWN0dXJhbCByZWFzb24gd2h5IGl0IGNvdWxkIG5vdCBiZSBF U05JLiAgQnV0IGluIG15IGV4cGVyaWVuY2UsIHRoZXJl4oCZcyBub3QgbXVjaCBwb2ludCBpbiBp dCwgZWl0aGVyLg0KDQpXaGF0IGRvIHlvdSBtZWFuIGJ5IGNsaWVudCBjZXJ0PyAgVGhlIENETi0+ T3JpZ2luIGhvcCBjYW5ub3QgcHJlc2VudCBvcmlnaW5hbCBDbGllbnTigJlzIGNlcnRpZmljYXRl IGJlY2F1c2UgKGluIGdlbmVyYWwsIG1heWJlIHRoZXJlIGFyZSBzb21lIGV4Y2VwdGlvbnMpIHRo ZSBDRE4gZG9lcyBub3QgaGF2ZSB0aGUgcHJpdmF0ZSBrZXkgc28gaXQgY2Fubm90IGRvIHRoZSBu ZWNlc3NhcnkgY3J5cHRvIG9wZXJhdGlvbnMuICBUaGF04oCZcyB0aGUgcmlnaHQgdGhpbmcgdG8g ZG8sIG90aGVyd2lzZSBhbnlvbmUgY291bGQgcHJlc2VudCBhbnkgY2xpZW50IGNlcnQgYW5kIGNs YWltIHRvIGJlIHRoZSBDbGllbnQuICBJbnN0ZWFkLCB0aGUgQ2xpZW50IGNlcnRpZmljYXRlIChv ciBwYXJ0cyBvZiBpdCBzdWNoIGFzIHRoZSBzdWJqZWN0RE4pIGFyZSBwcmVzZW50ZWQgaW4gbmV3 bHktYWRkZWQgSFRUUCBoZWFkZXJzLiAgVGhlIG9yaWdpbiBpcyBjb25maWd1cmVkIHRvIHRydXN0 IHRob3NlIGhlYWRlcnMsIGRlcGVuZGluZyBvbiB0aGUgQ0ROL09yaWdpbiByZWxhdGlvbnNoaXAg 4oCTIGl0IGNvdWxkIGJlIHRoZSBDRE4gaGFzIGl04oCZcyBvd24gY2xpZW50IGNlcnQsIGl0IGNv dWxkIGJlIHZpYSBJUCBmaWx0ZXJzLCBldGMuDQoNCg0KICAqICAgSSBkb24ndCB0aGluayBhIERO Uy1iYXNlZCBzb2x1dGlvbiBsaWtlIEVTTkkgd2lsbCB3b3JrIGZvciB0aGF0IHNlY29uZCBob3As IGJlY2F1c2UgdGhlIG9yaWdpbiB0ZW5kcyB0byBiZSBpZGVudGlmaWVkIGJ5IGFuIElQIGFkZHJl c3MgcmF0aGVyIHRoYW4gYSBkb21haW4gbmFtZS4NCg0KSW4gb3VyIGV4cGVyaWVuY2UsIHRoZSBv cmlnaW4gaXMgaWRlbnRpZmllZCBieSBhIEROUyBuYW1lLiAgSSBjb3VsZCBkb3VibGUtY2hlY2ss IGJ1dCBJIGRvbuKAmXQgdGhpbmsgKmFueSogb2Ygb3VyIGN1c3RvbWVyIG9yaWdpbnMgYXJlIGlk ZW50aWZpZWQgYnkgSVAgYWRkcmVzcy4NCg0K --_000_7F634AD9590941B0AB08D6FA6AB0C816akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <26DABEC52D3E734EBA5EF80FF51BA6C2@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTM4NjAyODQ3Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTczMzM1MDcyIDgxMTUzMTU4MCA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZh bWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkkgd2FudCB0byBrZWVwIHRo ZSBTTkkgZW5jcnlwdGVkIGluIFRMUyBob3BzIHRoYXQgdXNlIGNsaWVudCBjZXJ0aWZpY2F0ZXMs IGJ1dCB3aGVyZSBFU05JIHdvbid0IHdvcmsuPG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhhdmUgc29tZSBxdWVzdGlvbnMgYWJvdXQgdGhpcywgc2VlIGJlbG93LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+Rm9yIGV4YW1wbGUsIGhvdyBpcyB0aGUgU05JIHRyYW5zbWl0dGVk IGluIHRoZSBwYXJlbnMgaGVyZTo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPlsgQ2xpZW50IF0gLS0tLS0mZ3Q7IChFU05JKSAtLS0tLSZndDsgWyBDRE4gXSAtLS0t LSZndDsgKD8/PykgLS0tLS0mZ3Q7IFsgT3JpZ2luIF0mbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgdHJhbnNtaXR0ZWQgaW4gdGhlIGNsZWFy LiZuYnNwOyBUaGVyZSBpcyBubyBhcmNoaXRlY3R1cmFsIHJlYXNvbiB3aHkgaXQgY291bGQgbm90 IGJlIEVTTkkuJm5ic3A7IEJ1dCBpbiBteSBleHBlcmllbmNlLCB0aGVyZeKAmXMgbm90IG11Y2gg cG9pbnQgaW4gaXQsIGVpdGhlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBkbyB5b3Ug bWVhbiBieSBjbGllbnQgY2VydD8mbmJzcDsgVGhlIENETi0mZ3Q7T3JpZ2luIGhvcCBjYW5ub3Qg cHJlc2VudCBvcmlnaW5hbCBDbGllbnTigJlzIGNlcnRpZmljYXRlIGJlY2F1c2UgKGluIGdlbmVy YWwsIG1heWJlIHRoZXJlIGFyZSBzb21lIGV4Y2VwdGlvbnMpIHRoZSBDRE4gZG9lcyBub3QgaGF2 ZSB0aGUgcHJpdmF0ZSBrZXkgc28gaXQgY2Fubm90IGRvIHRoZSBuZWNlc3NhcnkgY3J5cHRvIG9w ZXJhdGlvbnMuJm5ic3A7DQogVGhhdOKAmXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvLCBvdGhlcndp c2UgYW55b25lIGNvdWxkIHByZXNlbnQgYW55IGNsaWVudCBjZXJ0IGFuZCBjbGFpbSB0byBiZSB0 aGUgQ2xpZW50LiZuYnNwOyBJbnN0ZWFkLCB0aGUgQ2xpZW50IGNlcnRpZmljYXRlIChvciBwYXJ0 cyBvZiBpdCBzdWNoIGFzIHRoZSBzdWJqZWN0RE4pIGFyZSBwcmVzZW50ZWQgaW4gbmV3bHktYWRk ZWQgSFRUUCBoZWFkZXJzLiZuYnNwOyBUaGUgb3JpZ2luIGlzIGNvbmZpZ3VyZWQgdG8gdHJ1c3Qg dGhvc2UNCiBoZWFkZXJzLCBkZXBlbmRpbmcgb24gdGhlIENETi9PcmlnaW4gcmVsYXRpb25zaGlw IOKAkyBpdCBjb3VsZCBiZSB0aGUgQ0ROIGhhcyBpdOKAmXMgb3duIGNsaWVudCBjZXJ0LCBpdCBj b3VsZCBiZSB2aWEgSVAgZmlsdGVycywgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SSBkb24n dCB0aGluayBhIEROUy1iYXNlZCBzb2x1dGlvbiBsaWtlIEVTTkkgd2lsbCB3b3JrIGZvciB0aGF0 IHNlY29uZCBob3AsIGJlY2F1c2UgdGhlIG9yaWdpbiB0ZW5kcyB0byBiZSBpZGVudGlmaWVkIGJ5 IGFuIElQIGFkZHJlc3MgcmF0aGVyIHRoYW4gYSBkb21haW4gbmFtZS48bzpwPjwvbzpwPjwvbGk+ PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3VyIGV4cGVyaWVuY2UsIHRoZSBvcmln aW4gaXMgaWRlbnRpZmllZCBieSBhIEROUyBuYW1lLiZuYnNwOyBJIGNvdWxkIGRvdWJsZS1jaGVj aywgYnV0IEkgZG9u4oCZdCB0aGluayAqPGI+YW55PC9iPiogb2Ygb3VyIGN1c3RvbWVyIG9yaWdp bnMgYXJlIGlkZW50aWZpZWQgYnkgSVAgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7F634AD9590941B0AB08D6FA6AB0C816akamaicom_-- From nobody Thu Oct 10 09:06:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A41120812 for ; Thu, 10 Oct 2019 09:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 UQY_BrnFPYHG for ; Thu, 10 Oct 2019 09:06:25 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 624311202DD for ; Thu, 10 Oct 2019 09:06:25 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id v2so14886912iob.10 for ; Thu, 10 Oct 2019 09:06:25 -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=/FRsZEtRaJ9vSWOkMsV4E6THe98krVeQxOe5xlzkMCY=; b=RJvBndc2uJRRpbzaHVn0UVQw6uZu9NAAs+pMThmNTMWDRM8tKCRoJbsf5Zp3tKepuI mMhxx5gFkmdDBnTr/XLKk4I2tEti87HTE7pEW3Jx8zCsyjqlLyDt2u961Z0E/fQ7Mrbp mt7yrTkcSOwQJYapRdHq7iUVxuJTzHBhjCrJzfOmp3LdBPlj1EKyURN4sRlHrIuw2DFE ub3PC3TBCDSdHAYRa2Mp55DFSmQ7WVCW5ronU56vHgiUN/6qF9M3zQwA7Z7ZfWMOPLnk 5Nvv1sMoqGCMlAOokCk07eRkkL3Nszx1ybCGH+CYY2VEukvY/jRc+dmOxHVO7Ssh3+rU +GLA== 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=/FRsZEtRaJ9vSWOkMsV4E6THe98krVeQxOe5xlzkMCY=; b=TtOhExFWvHcdgCFULs0swlMjpxXBojofR5CDoDPSovcd3wYX9+8nE0Wmt0jEu0QvTR TzfEXQjJxhAFm6zbVKyNBuBrGjsTvDF20WKCfYp4MrP317eFdLhKkzs1d3heydZ+Zp1m Pbm5bCN+lIMWlgesocB8BE9uGEdXA0fYeWwyjjYyi2suohQC2t5olQ6PD/A4VNXU49Tp DIlhv1hV6iEY2/JkiWFeDzcns8M/hOEsaIJCeGLiiDuJq/uYLEcrmYrrC6rX96HynMZB SjIyPwFitsxQyJrTp8rPkxLMrDU2dzaycrnA4Wed7c81AtEOhKta+MwD3F3B18B3hq7z uM9A== X-Gm-Message-State: APjAAAVCtM3Fzj/DAv98isguGBCtqFzR8SMwj075zf32sY848lsd7FTE /6mQh8wtz5KN2H08S8wVip8oADBLh7CDCoFpKaE= X-Google-Smtp-Source: APXvYqwpSkKWbog71ZFZFD20wfxOxzp6B1RY537SLhe3m3BhoBZu8IJPT4Dygu+rNSlT3PI4nW5X1c+Ft3voaeLSHBc= X-Received: by 2002:a5d:9297:: with SMTP id s23mr11780857iom.49.1570723584583; Thu, 10 Oct 2019 09:06:24 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> In-Reply-To: <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> From: Rob Sayre Date: Thu, 10 Oct 2019 23:06:12 +0700 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004cb06005949095e7" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 16:06:38 -0000 --0000000000004cb06005949095e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 10, 2019 at 10:53 PM Salz, Rich wrote: > > - For example, how is the SNI transmitted in the parens here: > > > > - [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin > ] > > > > It is transmitted in the clear. There is no architectural reason why it > could not be ESNI. But in my experience, there=E2=80=99s not much point = in it, > either. > I am not sure I agree. > > > What do you mean by client cert? The CDN->Origin hop cannot present > original Client=E2=80=99s certificate... > That's true. I was talking about something like this: https://support.cloudflare.com/hc/en-us/articles/204899617-Authenticated-Or= igin-Pulls Only the CDN is authenticated in that situation. > > > > - I don't think a DNS-based solution like ESNI will work for that > second hop, because the origin tends to be identified by an IP address > rather than a domain name. > > > > In our experience, the origin is identified by a DNS name. I could > double-check, but I don=E2=80=99t think **any** of our customer origins a= re > identified by IP address. > How does that work without introducing a CDN loop? Do you require the origins to have obscure domain names? FWIW, the Cloudflare control panel just has an IP address field. :) thanks. Rob --0000000000004cb06005949095e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 10, 2019 at 10:53 PM Salz, Ri= ch <rsalz@akamai.com> wrote:= =C2=A0

  • For example, how is the SNI transmitted in the parens here:=

=C2=A0

  • [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) ----= -> [ Origin ]=C2=A0

=C2=A0

It is transmitted in the clear.=C2=A0 There is no ar= chitectural reason why it could not be ESNI.=C2=A0 But in my experience, th= ere=E2=80=99s not much point in it, either.


I am not sure I agree.
=C2=A0

=C2=A0

What do you mean by client cert?=C2=A0 The CDN->O= rigin hop cannot present original Client=E2=80=99s certificate...

=

That's true. I was talking= about something like this:

Only the CDN is authenticated in that situati= on.

=C2=A0

=C2=A0

  • I don't think a DNS-based solution like ESNI will work for tha= t second hop, because the origin tends to be identified by an IP address ra= ther than a domain name.

=C2=A0

In our experience, the origin is identified by a DNS= name.=C2=A0 I could double-check, but I don=E2=80=99t think *any* o= f our customer origins are identified by IP address.

<= /blockquote>

How does that work without introducing a CD= N loop? Do you require the origins to have obscure domain names? FWIW, the = Cloudflare control panel just has an IP address field. :)

thanks.
Rob
=C2=A0
--0000000000004cb06005949095e7-- From nobody Thu Oct 10 09:07:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C401B120804 for ; Thu, 10 Oct 2019 09:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 00o6-DZrQMh1 for ; Thu, 10 Oct 2019 09:07:18 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D4712080E for ; Thu, 10 Oct 2019 09:07:18 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id m13so6747099ljj.11 for ; Thu, 10 Oct 2019 09:07: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=CUa/6Kl62X/P5MUrCCdyWFzhGSGUKAjB9cE/qgQgu4s=; b=VnZyJkrP6prQKz8Y8rEKmKL+z/ndH9JJwY2Ev+f1Zy3gxwkQi1NMpAGVjHc28O4NJW iACLIXV+EckQNzjV3RCAKI44dSepujzC+bkqqqwoCxUP5k0fD8eTHF/F/OxPSz56RIBz dHLkRj1J5Uw5Mx/IZ1EWIl0ux+508Kq70ZVhJoxkY+NjYd3tjnRjrVi4kubKXHMKaNlR RrVJi8jrg0xf5Wq8AzGqe2ey6+R8GteNk/ucj5WnPqv86rtbfu5If1zYwpqf5FIN6XK1 cRoYNdvKrYG5RFsMsEN9zBstzUZ2UhbECME6NLxEIF9fTZkW7X31t2TJ960WbdhfmHeI tOMA== 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=CUa/6Kl62X/P5MUrCCdyWFzhGSGUKAjB9cE/qgQgu4s=; b=Sg1R484n0nka8Bv4v1btE+32kktvpMFC7/bcHt8+Ml2TxoD33N6jXO3BVsIfo1kwJn TDjvm5PwsyYbwNFpRgzckJkd9jXtR6VTo2YTfSGXRuxyeZTJIOwF98n0MvICMUenO8Ki FK1nN6KmJNVeO7Q9mUyr+8WLZQ0sPehgvQybJNpAAayaGMs4bSV4V/mtU5VmhBx0j47C HKfi9JnNMmLgooovnG32sFxxQGqEwtYeEHZECwarr4ntEEwCB8rrqftODIOoqA6HS5LW 7KoAYv33wRu3rH3Qa2GWLGk4oU2+HC2js+r6LbMPQ5snTe1NM1xFoXEFdx6jDNu9orPu tYDg== X-Gm-Message-State: APjAAAUbYtji55X58XKZcvo5WXs59MrH0D1a5sOJald3Oiv+hQVX3mzc g0kV69NTERfribr1lCS4uTwqgb2DQyxTDRflBdw= X-Google-Smtp-Source: APXvYqzvR1iO/OaglcWrq27o9es4T79eyHPdTtIYwCPendAiT3IGJ4AdJNHbAsIbTcgufmDYrGpMPnXD7GV+4wPgi3o= X-Received: by 2002:a05:651c:120b:: with SMTP id i11mr2971972lja.123.1570723636376; Thu, 10 Oct 2019 09:07:16 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> In-Reply-To: <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> From: Watson Ladd Date: Thu, 10 Oct 2019 09:07:04 -0700 Message-ID: To: "Salz, Rich" Cc: Rob Sayre , Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000062f9b90594909874" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 16:07:28 -0000 --00000000000062f9b90594909874 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 10, 2019, 8:54 AM Salz, Rich wrote: > > - I want to keep the SNI encrypted in TLS hops that use client > certificates, but where ESNI won't work. > > > > I have some questions about this, see below. > > > > - For example, how is the SNI transmitted in the parens here: > > > > - [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin > ] > > > > It is transmitted in the clear. There is no architectural reason why it > could not be ESNI. But in my experience, there=E2=80=99s not much point = in it, > either. > > > > What do you mean by client cert? The CDN->Origin hop cannot present > original Client=E2=80=99s certificate because (in general, maybe there ar= e some > exceptions) the CDN does not have the private key so it cannot do the > necessary crypto operations. That=E2=80=99s the right thing to do, other= wise > anyone could present any client cert and claim to be the Client. Instead= , > the Client certificate (or parts of it such as the subjectDN) are present= ed > in newly-added HTTP headers. The origin is configured to trust those > headers, depending on the CDN/Origin relationship =E2=80=93 it could be t= he CDN has > it=E2=80=99s own client cert, it could be via IP filters, etc. > > > > - I don't think a DNS-based solution like ESNI will work for that > second hop, because the origin tends to be identified by an IP address > rather than a domain name. > > > > In our experience, the origin is identified by a DNS name. I could > double-check, but I don=E2=80=99t think **any** of our customer origins a= re > identified by IP address. > At least one customer of the CDN I work for (namely my own website) uses an IP address. Shared hosting behind a CDN does exist where clients of the service provider are signed up to the CDN, and it might be interesting to use ESNI there but the privacy risks are less extreme absent a global passive adversary. Protecting client to shared infrastructure is what ESNI aims to do. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000062f9b90594909874 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 10, 2019, 8:54 AM Salz, Rich <rsalz@akamai.com> wrote:
  • I want to keep the SNI encrypted in TLS hops that use client certificates= , but where ESNI won't work.

=C2=A0

I have some questions about this, see below.<= u>

=C2=A0

  • For example, how is the SNI transmitted in the parens here:=

=C2=A0

  • [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [= Origin ]=C2=A0

=C2=A0

It is transmitted in the clear.=C2=A0 There is no ar= chitectural reason why it could not be ESNI.=C2=A0 But in my experience, th= ere=E2=80=99s not much point in it, either.

=C2=A0

What do you mean by client cert?=C2=A0 The CDN->O= rigin hop cannot present original Client=E2=80=99s certificate because (in = general, maybe there are some exceptions) the CDN does not have the private= key so it cannot do the necessary crypto operations.=C2=A0 That=E2=80=99s the right thing to do, otherwise anyone could present any c= lient cert and claim to be the Client.=C2=A0 Instead, the Client certificat= e (or parts of it such as the subjectDN) are presented in newly-added HTTP = headers.=C2=A0 The origin is configured to trust those headers, depending on the CDN/Origin relationship =E2=80=93 it could be th= e CDN has it=E2=80=99s own client cert, it could be via IP filters, etc.=

=C2=A0

  • I don't think a DNS-based solution like ESNI will work for that secon= d hop, because the origin tends to be identified by an IP address rather th= an a domain name.

=C2=A0

In our experience, the origin is identified by a DNS= name.=C2=A0 I could double-check, but I don=E2=80=99t think *any* o= f our customer origins are identified by IP address.

<= /blockquote>

At le= ast one customer of the CDN I work for=C2=A0 (namely my own website) uses a= n IP address.

Shared hos= ting behind a CDN does exist where clients of the service provider are sign= ed up to the CDN, and it might be interesting=C2=A0 to use ESNI there but t= he privacy risks are less extreme absent a global passive adversary. Protec= ting client to shared infrastructure is what ESNI aims to do.

=C2=A0

_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000062f9b90594909874-- From nobody Thu Oct 10 09:15:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529BA1200E0 for ; Thu, 10 Oct 2019 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 1FWo7pXJMtZG for ; Thu, 10 Oct 2019 09:15:03 -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 8E2F61200C3 for ; Thu, 10 Oct 2019 09:15:03 -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 x9AG2KxK031671; Thu, 10 Oct 2019 17:15:02 +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=7jI5JGXrfK+RnDkdfJsDIKvOljVUPhf9nkcEJDm8yxU=; b=cA3nJMszDdgNpIJ/NZMJJBAYO9VrkTA0OVpaxEBjGThc7Iy/sw7LaO6S+3Vs2tflrlgo +fDZE6/Nl25KVSl2LkD8AdFzP7WCWd3WaVe0cImVKmW18/kfOL5t3lxpywy6NcgMAUbH u23GUI8DBFC8tWQJ1MbfcZmHQ1Xcltpg65AhGyqcCGSG+SqyOgjPVKu0I9V7SSTFWuDw DCbVwoOLduOsY9vwDGz2hGKNA5qxiYC5edg8lMDnCauzheJQG+lN+OcXq7iaxRibZquu Lk/6YTN8lLQ5xrfGuduJAp2wq/prnWSlo3jnGlvwLHwvMR/O0ykkLFRDNdprY6pal8U0 4A== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vejtvh0gf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 17:15:01 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9AG4jVJ029448; Thu, 10 Oct 2019 12:15:01 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint7.akamai.com with ESMTP id 2veph0pkc0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 12:15:00 -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.1473.3; Thu, 10 Oct 2019 11:14:58 -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.1473.005; Thu, 10 Oct 2019 11:14:58 -0500 From: "Salz, Rich" To: Watson Ladd CC: Rob Sayre , Eric Rescorla , "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAIAARAMA///HFYCAAEduAIAAASmAgAABBID//74fAIAARG0AgAAAdACAAQ9OAIAAbsyAgABG7AD//78mgA== Date: Thu, 10 Oct 2019 16:14:57 +0000 Message-ID: References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.161] Content-Type: multipart/alternative; boundary="_000_A987F56A3C3F43978C9C4F1B80D14CEFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-10_05:, , 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=607 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910100148 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-10_05:2019-10-10,2019-10-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 adultscore=0 priorityscore=1501 impostorscore=0 phishscore=0 spamscore=0 mlxlogscore=592 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910100148 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 16:15:06 -0000 --_000_A987F56A3C3F43978C9C4F1B80D14CEFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQXQgbGVhc3Qgb25lIGN1c3RvbWVyIG9mIHRoZSBDRE4gSSB3b3JrIGZvciAgKG5hbWVs eSBteSBvd24gd2Vic2l0ZSkgdXNlcyBhbiBJUCBhZGRyZXNzLg0KDQpTdXJlLCBJIGdldCBpdC4g IFdoaWNoIGlzIHdoeSBJIHNhaWQg4oCcaW4gb3VyIGV4cGVyaWVuY2Uu4oCdIDopDQoNCg0KICAq ICAgU2hhcmVkIGhvc3RpbmcgYmVoaW5kIGEgQ0ROIGRvZXMgZXhpc3Qgd2hlcmUgY2xpZW50cyBv ZiB0aGUgc2VydmljZSBwcm92aWRlciBhcmUgc2lnbmVkIHVwIHRvIHRoZSBDRE4sIGFuZCBpdCBt aWdodCBiZSBpbnRlcmVzdGluZyAgdG8gdXNlIEVTTkkgdGhlcmUgYnV0IHRoZSBwcml2YWN5IHJp c2tzIGFyZSBsZXNzIGV4dHJlbWUgYWJzZW50IGEgZ2xvYmFsIHBhc3NpdmUgYWR2ZXJzYXJ5LiBQ cm90ZWN0aW5nIGNsaWVudCB0byBzaGFyZWQgaW5mcmFzdHJ1Y3R1cmUgaXMgd2hhdCBFU05JIGFp bXMgdG8gZG8uDQoNClRoZSByZWFsIHBvaW50IG9mIHRoaXMgbm90ZTogIHN0cm9uZyArMSBmb3Ig dGhpcy4NCg0K --_000_A987F56A3C3F43978C9C4F1B80D14CEFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tLTM4NDU5NDAzNjQyNDgwNDIzbXNvbGlz dHBhcmFncmFwaCwgbGkubS0zODQ1OTQwMzY0MjQ4MDQyM21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5t LTM4NDU5NDAzNjQyNDgwNDIzbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXy0z ODQ1OTQwMzY0MjQ4MDQyM21zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjM0OTY0NjY2MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTkx ODUzMTgzMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjQ2OTA1OTQwNTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTk3MzgxMjk5MiAy MTIzNDE2NDIyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwt c3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6Nzg4MjgxMDUzOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoyMzYxOTU0NDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjc5 MDE3NjA1NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2OTM2NzEwODI7fQ0KQGxpc3QgbDM6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNA0KCXttc28tbGlzdC1pZDoyMTE4OTg1MzI2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotNTAwMTA1NTI2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvNSI+QXQgbGVhc3Qgb25lIGN1c3RvbWVyIG9mIHRoZSBDRE4gSSB3b3JrIGZvciZuYnNw OyAobmFtZWx5IG15IG93biB3ZWJzaXRlKSB1c2VzIGFuIElQIGFkZHJlc3MuPG86cD48L286cD48 L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdXJlLCBJIGdldCBpdC4mbmJzcDsgV2hpY2ggaXMg d2h5IEkgc2FpZCDigJxpbiBvdXIgZXhwZXJpZW5jZS7igJ0gOik8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzUiPlNoYXJlZCBob3N0aW5nIGJlaGluZCBhIENETiBkb2VzIGV4aXN0IHdoZXJlIGNsaWVudHMg b2YgdGhlIHNlcnZpY2UgcHJvdmlkZXIgYXJlIHNpZ25lZCB1cCB0byB0aGUgQ0ROLCBhbmQgaXQg bWlnaHQgYmUgaW50ZXJlc3RpbmcmbmJzcDsgdG8gdXNlIEVTTkkgdGhlcmUgYnV0IHRoZSBwcml2 YWN5IHJpc2tzIGFyZSBsZXNzDQogZXh0cmVtZSBhYnNlbnQgYSBnbG9iYWwgcGFzc2l2ZSBhZHZl cnNhcnkuIFByb3RlY3RpbmcgY2xpZW50IHRvIHNoYXJlZCBpbmZyYXN0cnVjdHVyZSBpcyB3aGF0 IEVTTkkgYWltcyB0byBkby48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlYWwg cG9pbnQgb2YgdGhpcyBub3RlOiZuYnNwOyBzdHJvbmcgJiM0MzsxIGZvciB0aGlzLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A987F56A3C3F43978C9C4F1B80D14CEFakamaicom_-- From nobody Thu Oct 10 09:17:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD7412006E; Thu, 10 Oct 2019 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 ceiKy_S2xuvK; Thu, 10 Oct 2019 09:17:08 -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 352A71200DF; Thu, 10 Oct 2019 09:17:08 -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 x9AGGw78005156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 12:17:00 -0400 Date: Thu, 10 Oct 2019 09:16:57 -0700 From: Benjamin Kaduk To: Rob Sayre Cc: Stephen Farrell , Eric Rescorla , Sean Turner via Datatracker , John Mattsson , "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" Message-ID: <20191010161657.GA76545@kduck.mit.edu> References: <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 16:17:10 -0000 On Tue, Oct 08, 2019 at 08:25:51PM +0700, Rob Sayre wrote: > On Tue, Oct 8, 2019 at 7:05 PM Benjamin Kaduk wrote: > > > it's largely up to the sponsoring AD. > > > > Is that true? I'm not sure which procedure you're describing. Per https://www.rfc-editor.org/current_queue.php , draft-ietf-rctweb-security-arch is in the RFC Editor queue, state "EDIT*R" (copyediting, with some extra task for the RFC Editor staff, presumably v2-->v3 XML conversion). As far as the IETF is concerned, the document is done and approved, and the only changes expected are editorial ones made by the RFC Editor and editorial ones made during AUTH48. Any substantive or technical changes during AUTH48 require at a minimum approval by the sponsoring AD, and if substantial enough, approval from the WG and possibly re-running IETF LC and IESG review. While it's true that we can do the latter procedures at any time until the RFC is officially published, it's a pretty heavyweight process and we generally only do it when there are actual technical errors, and not just for things that we might do differently if we were starting from scratch now. The decision about whether to make changes to the technical content thus lies with the sponsoring AD for that document. > At any rate, I think one issue is with the abstract > of draft-ietf-tls-oldversions-deprecate: > > "This document also deprecates Datagram TLS (DTLS) version 1.0 [RFC6347] > (but not DTLS version 1.2, and there is no DTLS version 1.1). > This document updates many RFCs that normatively refer to TLSv1.0 or > TLSv1.1 as described herein. This document also updates RFC 7525 and hence > is part of BCP195." > > What it doesn't do is state that it updates RFCs that normatively refer to > DTLS 1.0 and/or DTLS 1.2. It seems like it should, since RFC 6347 states: > "Implementations that speak both DTLS 1.2 and DTLS 1.0 can interoperate > with those that speak only DTLS 1.0 (using DTLS 1.0 of course), just as TLS > 1.2 implementations can interoperate with previous versions of TLS...". I disagree that draft-ietf-tls-oldversions-deprecate needs to update all consumers of DTLS 1.0/1.2, at least for the reason you give. Those documents properly refer to RFC 6347 (or 4347), and it is that RFC that we are updating now. We do not directly change those consuming documents' needs, but rather do so indirectly. > Although I favor deprecating DTLS 1.0 conclusively and thoroughly, there is > an argument for eliding DTLS entirely > in draft-ietf-tls-oldversions-deprecate, NIST SP800-52r2 explicitly states > that it doesn't cover DTLS, but that document is the only citation in the > "Support for Deprecation" section of draft-ietf-tls-oldversions-deprecate. That's a fair question to ask, and I trust the chairs to shepherd any additional discussion needed. That said, since DTLS is basically a small delta on top of TLS, if we are deprecating a TLS version for cause, it seems likely to me that it is also appropriate to deprecate the closely related DTLS version. > Updating in-flight documents to avoid citing soon-to-be-deprecated TLS RFCs > is something I expect Area Directors to be doing. It's a predictable > problem. Sure -- drafts coming in for IESG review are going to get flagged for any (D)TLS 1.0 usage. However, I disagree with characterizing draft-ietf-rtcweb-security-arch as "in flight" -- from the IETF perspective it's approved and done, and the barrier to making any further substantive changes is extremely high. -Ben From nobody Thu Oct 10 09:18:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC73F120232 for ; Thu, 10 Oct 2019 09:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 jFHsggfEDs6w for ; Thu, 10 Oct 2019 09:18:22 -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 957C1120241 for ; Thu, 10 Oct 2019 09:18:22 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9AG2NpI007492; Thu, 10 Oct 2019 17:18:16 +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=xVOaPUnrxKzXHriMP9FBHi1tsANMa9XvmLmq93Rnwts=; b=ZmZ4dlsEgCx4VYQ9xryEDRFYKwMZ1+xnAmzxNR8p+yIsdWH82zMprfSK9dxWTofUvjxK iVzC3coLJNit56/PFFhupYTPxC77eqQ+4/fn9vqeVHjb3OY4zRB9yCyuhDj2WsaKEZeV 0ElKdl5GxKODZHdG4q7fX1p69DZ5M/20b+zYCJ8O/2BobudU/Xky8fvuuCpMfCVXKa+S 3zn8p73u893EXCbfxgG3vvjGlRcv4aFYrkrHpVAJsaRM3tJp5I1p3B4cBpyMu0B6Hnf4 8lDTn6IC40VD9zpN4jCiFUBxd7j5LPlFYQe+x8JwlAd+EcxopOmnZZagATW/1aNUBH+K zg== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2veg1u1gju-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 17:18:16 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9AG4KeA028117; Thu, 10 Oct 2019 12:18:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint8.akamai.com with ESMTP id 2vepgyaefk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 12:18:14 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.165.124) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 10 Oct 2019 09:18:05 -0700 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.1473.005; Thu, 10 Oct 2019 11:18:05 -0500 From: "Salz, Rich" To: Rob Sayre CC: Eric Rescorla , "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVfeEan68Gaya+/0+PCTwF7OLHjKdRDe0AgAEeEACAABjcAIAARAMA///HFYCAAEduAIAAASmAgAABBID//74fAIAARG0AgAAAdACAAQ9OAIAAbsyAgABGrgD//8BDAA== Date: Thu, 10 Oct 2019 16:18:04 +0000 Message-ID: <59F21D9B-10BB-4E12-9AFF-5D88AB7DCA35@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.161] Content-Type: multipart/alternative; boundary="_000_59F21D9B10BB4E129AFF5D88AB7DCA35akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-10_05:, , 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=864 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910100148 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-10_05:2019-10-10,2019-10-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 phishscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 priorityscore=1501 mlxlogscore=850 mlxscore=0 adultscore=0 bulkscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910100148 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 16:18:25 -0000 --_000_59F21D9B10BB4E129AFF5D88AB7DCA35akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gb3VyIGV4cGVyaWVuY2UsIHRoZSBvcmlnaW4gaXMgaWRlbnRpZmllZCBieSBhIEROUyBuYW1l LiAgSSBjb3VsZCBkb3VibGUtY2hlY2ssIGJ1dCBJIGRvbuKAmXQgdGhpbmsgKmFueSogb2Ygb3Vy IGN1c3RvbWVyIG9yaWdpbnMgYXJlIGlkZW50aWZpZWQgYnkgSVAgYWRkcmVzcy4NCg0KDQogICog ICBIb3cgZG9lcyB0aGF0IHdvcmsgd2l0aG91dCBpbnRyb2R1Y2luZyBhIENETiBsb29wPyBEbyB5 b3UgcmVxdWlyZSB0aGUgb3JpZ2lucyB0byBoYXZlIG9ic2N1cmUgZG9tYWluIG5hbWVzPyBGV0lX LCB0aGUgQ2xvdWRmbGFyZSBjb250cm9sIHBhbmVsIGp1c3QgaGFzIGFuIElQIGFkZHJlc3MgZmll bGQuIDopDQoNCkl04oCZcyBub3Qgb2JzY3VyZSwgaXTigJlzIGluIEROUyA6KSAgQnV0IHllcywg dGhlIOKAnHRydWXigJ0gb3JpZ2luIGhhcyBhIGRpZmZlcmVudCBuYW1lLg0KDQpPbmUgcmVhc29u IGZvciB1c2luZyBETlMgaXMgdGhhdCBiaWcgc2l0ZXMgb2Z0ZW4gdXNlIGEgbXVsdGktQ0ROIGxv YWQgYmFsYW5jZXIuICBUaGV5IGNhbiBzaGlmdCBpbiBhcyBsaXR0bGUgYXMgMTAtMzAgc2Vjb25k cy4NCg0K --_000_59F21D9B10BB4E129AFF5D88AB7DCA35akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <69B817CF7D7632438E97C7A02469BA78@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5nbWFpbC1tMzUxOTEzNTMwMzUzMTE3MzQ3 NW1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdtYWlsLW0zNTE5MTM1MzAzNTMxMTczNDc1bXNvbGlzdHBh cmFncmFwaCwgZGl2LmdtYWlsLW0zNTE5MTM1MzAzNTMxMTczNDc1bXNvbGlzdHBhcmFncmFwaA0K CXttc28tc3R5bGUtbmFtZTpnbWFpbC1tXzM1MTkxMzUzMDM1MzExNzM0NzVtc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTY1MzA0NzI7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00OTkzNDI5 NDggNDA1MDQ2NDggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNjk4Nzk4MjI7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjE1NDI3MjkyMDg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1p ZDoxNzEyOTI1MDcxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDY4NTUzMDAwO30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTk2MzQ4ODQ0MzsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTI2MTA2MDIwODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBvdXIgZXhwZXJpZW5jZSwgdGhlIG9y aWdpbiBpcyBpZGVudGlmaWVkIGJ5IGEgRE5TIG5hbWUuJm5ic3A7IEkgY291bGQgZG91YmxlLWNo ZWNrLCBidXQgSSBkb27igJl0IHRoaW5rICo8Yj5hbnk8L2I+KiBvZiBvdXIgY3VzdG9tZXIgb3Jp Z2lucyBhcmUgaWRlbnRpZmllZCBieSBJUCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzQiPkhvdyBkb2VzIHRoYXQgd29yayB3aXRob3V0IGludHJvZHVjaW5nIGEgQ0ROIGxvb3A/ IERvIHlvdSByZXF1aXJlIHRoZSBvcmlnaW5zIHRvIGhhdmUgb2JzY3VyZSBkb21haW4gbmFtZXM/ IEZXSVcsIHRoZSBDbG91ZGZsYXJlIGNvbnRyb2wgcGFuZWwganVzdCBoYXMgYW4gSVAgYWRkcmVz cyBmaWVsZC4gOik8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SXTigJlzIG5vdCBvYnNjdXJlLCBpdOKAmXMgaW4gRE5TIDopJm5ic3A7IEJ1dCB5ZXMsIHRoZSDi gJx0cnVl4oCdIG9yaWdpbiBoYXMgYSBkaWZmZXJlbnQgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T25lIHJlYXNvbiBmb3IgdXNpbmcgRE5TIGlzIHRoYXQgYmlnIHNpdGVzIG9mdGVuIHVz ZSBhIG11bHRpLUNETiBsb2FkIGJhbGFuY2VyLiZuYnNwOyBUaGV5IGNhbiBzaGlmdCBpbiBhcyBs aXR0bGUgYXMgMTAtMzAgc2Vjb25kcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_59F21D9B10BB4E129AFF5D88AB7DCA35akamaicom_-- From nobody Thu Oct 10 09:19:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACB6120113 for ; Thu, 10 Oct 2019 09:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 s5tGM3gvENqv for ; Thu, 10 Oct 2019 09:19:35 -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 88311120826 for ; Thu, 10 Oct 2019 09:19:34 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id h144so14981557iof.7 for ; Thu, 10 Oct 2019 09:19:34 -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=1EOGUWjmFokF3Mv+HvBtiDVPy9kdG7sDosTGvw+sTZ8=; b=Cx0tQrm46EMn2ORmQoP/Yugv4rv0pW9V1c8PT9P9hqP0DbPnJ2u2nDOQOsvfMP+D/W HpUX4BGFk9rkHh3cAleKlkrksP05pAoK8xzHi/WAckSsY87u1fMXQeP/D1H0KOh+b0wj OQqPZnywSVt/2/rsBM2HVfujHVPGI7T15TWUexrKwWyoRGq/BNCXplfLzrnaXKGE6Ofw lCJcbi5OrqwY9FPNH8WJJW7K7RxM1qBmUA5cH9vi8kIvLOl7eGdkCjHjRTRY42glfZC/ hyHFd1tkQ2QiBlgKqijYHmbDgH4mP7eWgCgnBFGcDLWmQxDf24sbqu0eUAXn/hlDZEAO rPkg== 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=1EOGUWjmFokF3Mv+HvBtiDVPy9kdG7sDosTGvw+sTZ8=; b=Ap3yf3r860k+HcgSruQMFGLMV32pJg1VLaZer9MyycEsJQv2KevNJZ/3FazCNDua5P WIaaRdw4nH0f2l+/X7h7p56h+EtJisMHJJKp+OkJl6V1BtHhB3hM8ps6x3Cf9vZaEiO9 gUEU+SX+rViPooUGowM+h2dfJbb0qTy6q7tXAF4homWmf73c7d6zWq/oH0uCyNvTK1Rv gTp9Lua0Dbyl/gqT4J6n+4FKHTj1HsZVxIQBbJH2f5B7BmsxocXLgcgbDzzFJHsNouis l/COxmuNRXS9JT0kqvbm6AdkSa2RdAXD8FfyN8xnzuZ/Le5xj8khzPsmt8M3jYodcBLr G4jA== X-Gm-Message-State: APjAAAVZuo8KyH4zHab06HgqNV0SbYOTYn0VsT5Yrx9zunyFWbooNrXs wsU3byjgxmrb5kZKJMsFxc+0TlIL72KsMNI0iZI= X-Google-Smtp-Source: APXvYqxuR+WQezxqUpYc5No084cSV1JtqdTGyYhl6kiLN1vwyKYTWo1NSgVgI+ZfNgVHfDFvF2yiJg5lhnd26dUzIr8= X-Received: by 2002:a6b:f90f:: with SMTP id j15mr10230060iog.257.1570724373781; Thu, 10 Oct 2019 09:19:33 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> In-Reply-To: From: Rob Sayre Date: Thu, 10 Oct 2019 23:19:21 +0700 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , "TLS@ietf.org" , Watson Ladd Content-Type: multipart/alternative; boundary="00000000000056e2d7059490c481" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 16:19:37 -0000 --00000000000056e2d7059490c481 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 10, 2019 at 11:15 PM Salz, Rich wrote: > > - At least one customer of the CDN I work for (namely my own website) > uses an IP address. > > > > Sure, I get it. Which is why I said =E2=80=9Cin our experience.=E2=80=9D= :) > > > > - Shared hosting behind a CDN does exist where clients of the service > provider are signed up to the CDN, and it might be interesting to use= ESNI > there but the privacy risks are less extreme absent a global passive > adversary. Protecting client to shared infrastructure is what ESNI aim= s to > do. > > > > The real point of this note: strong +1 for this. > Well, either way, it will be interesting to find out if insecure back haul traffic becomes a point of competition. :) thanks, Rob --00000000000056e2d7059490c481 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Oct 10, 2019 at 11:15 PM Salz, Rich <rsalz@akamai.com> wrote:
  • At least one customer of the CDN I work for=C2=A0 (namely my own websit= e) uses an IP address.

=C2=A0

Sure, I get it.=C2=A0 Which is why I said =E2=80=9Ci= n our experience.=E2=80=9D :)

=C2=A0

  • Shared hosting behind a CDN does exist where clients of the service pro= vider are signed up to the CDN, and it might be interesting=C2=A0 to use ES= NI there but the privacy risks are less extreme absent a global passive adversary. Protecting client to shared inf= rastructure is what ESNI aims to do.

=C2=A0

The real point of this note:=C2=A0 strong +1 for thi= s.


Well, either way, it will be interesting to find out if insecure = back haul traffic becomes a point of competition. :)

thanks,
Rob


--00000000000056e2d7059490c481-- From nobody Thu Oct 10 09:44:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEECA120180 for ; Thu, 10 Oct 2019 09:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PXCAmzWAslo0 for ; Thu, 10 Oct 2019 09:44:19 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 F40B612006E for ; Thu, 10 Oct 2019 09:44:18 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id h144so15162737iof.7 for ; Thu, 10 Oct 2019 09:44: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=YWya60eZPCv4QszF8OsBqR1PRroG971LctxB0basp0Y=; b=tMeNXFNhYbefKf5HhnO1Mbv6DiWD6aru6GgMLT+sdNTrcIKKBy7OcSm66fjYoV1Y94 jyT3oZSCUCobqSudgd+ilNnoWY7vl0l1dZYsheOQ3U1o0ItzJQc0ISSPWYPlW/FECROF Pkbi33f2u7+OAJYeO2a+o1DbAdb8kBdvQqD6KYdv03hAa8I6E6GwLOCo8gRX8wzfdS5N t9LE1e0yoEdL7K8W1QWL/Izr/HNsRDSfW/sTS2e3vA5KJaTJGacDUX51agZuRp088Y9b tIjGCiRfRrSB8B3kI1DVmNyQQhK1SiRmtTEBATr58fIBW/RbQNRDMWVkdgAH6CY50xc1 pU3A== 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=YWya60eZPCv4QszF8OsBqR1PRroG971LctxB0basp0Y=; b=ql7V1TMMSXpW06+SjMLi+E3yThZnXvvwJnvPoxww1nJYX2lY4Oom/8oNJ1qZ4XovBq VSvfJoGA93zRymeiNdVO2nkIYiVkq/DkBh2tBhsZG1M92heDziZKrXkmooAoePcD+0Jo PO1JjPQBsRmsmf8ZsFhWpSnivqqcmTw0jzQMKsxVFgs7O7GuSHck08pf+i+Nf+h6VygZ df7zhSk/mgs9N3hjZsVNXBW1+/W2cloRsUz0MQtqmt2mqjQgSSrO0goQDnOZ8RUNnwP7 G9B1SlOcBejrfwjxoG4s+R2zKfeotqPD9zN2jM3ULEfGp6USdzEZbw+go5xfC2bqdNO9 fLnA== X-Gm-Message-State: APjAAAX+UPMk3pkeAElgSzgwgheqJZHcyaA/BpeF6dXO4pF/dHBhEjdZ Ifmq5XLBq4VwUQovNkpPvqBk4OBYtaI1NYxS2e4= X-Google-Smtp-Source: APXvYqyIIk1h75eAu4HeesCj48/xVJcKPNfFQ1uh35coJiMpktrneO8Lh161p/vKKXAIdaYAZmv7BbpmpiXzI1Bkt1Q= X-Received: by 2002:a6b:f40f:: with SMTP id i15mr11203734iog.54.1570725858106; Thu, 10 Oct 2019 09:44:18 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <7F634AD9-5909-41B0-AB08-D6FA6AB0C816@akamai.com> <59F21D9B-10BB-4E12-9AFF-5D88AB7DCA35@akamai.com> In-Reply-To: <59F21D9B-10BB-4E12-9AFF-5D88AB7DCA35@akamai.com> From: Rob Sayre Date: Thu, 10 Oct 2019 23:44:06 +0700 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cfe22d0594911cfb" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 16:44:21 -0000 --000000000000cfe22d0594911cfb Content-Type: text/plain; charset="UTF-8" M On Thu, Oct 10, 2019 at 11:18 PM Salz, Rich wrote: > One reason for using DNS is that big sites often use a multi-CDN load > balancer. They can shift in as little as 10-30 seconds. > Also, just to level-set the conversation, I am extremely familiar with this routine (see sayrer.com) It seems like load-balanced IPs with an API would do the job better than DNS. At the time I had to deal with these problems, DNS was the only choice, and every CDN vendor seemed incompetent and unreliable. So I can understand why DNS is still the default. thanks, Rob --000000000000cfe22d0594911cfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
M
On Thu, Oct 10, 2019 at 11:18 PM Salz, Rich = <rsalz@akamai.com> wrote:

One reason for using DNS is that big sites often use= a multi-CDN load balancer.=C2=A0 They can shift in as little as 10-30 seco= nds.


Also, just to level-set the conversation, I am extremely familiar= with this routine (see sayrer.com)
=

It seems like load-balanced I= Ps with an API would do the job better than DNS. At the time I had to deal = with these problems, DNS was the only choice, and every CDN vendor seemed i= ncompetent and unreliable. So I can understand why DNS is still the default= .

thanks,
Rob

--000000000000cfe22d0594911cfb-- From nobody Thu Oct 10 10:45:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057E31200F6; Thu, 10 Oct 2019 10:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Hx34WaxS8ygx; Thu, 10 Oct 2019 10:45:26 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 71762120115; Thu, 10 Oct 2019 10:45:26 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id a1so15644106ioc.6; Thu, 10 Oct 2019 10:45:26 -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=CHkOi3h9ra1tIFk26LVUfdQXrHbBU02sMwvED6B4ZH4=; b=e9kbqBCtSgIH0jm86Mt5LK0mOfM1TVxJjq7JlxLDtliUaCot0DuMGtrqp9P6GCPdbv z32RZa9Tydc3STxillGW7H6gp3qPzbnkTXIG4JIfRZ22jQ9vynuI4RMEGvUx/axKuPNy Go1I99YHGy+9G7cOogq9oIC7hsVM7myZzJEFVYV9GxqCx+tqMBoZ7FlX97dNyMoo7Dvm VhK9b7v8M6icTzwi2ncE+bNrZ5tn3YMq1iBGl+qznAp7mrKda9UIXR1KHAFeGHRorzc7 NDiJZFFXi9QrZ+w8KIKf1Hyo6Da6PEJDJQKPsfE8lIJOxUtwuV21WbXbYcbk9qjfrWLj 39Ng== 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=CHkOi3h9ra1tIFk26LVUfdQXrHbBU02sMwvED6B4ZH4=; b=ZfxwoTQu0pZJorlg04xXlv1zbMjcK5Ke9dx7+JePmTUxjpzjp9KGwgnt5Yh7QHYPYU TKTfP8VrB//N44SXR+TEd/Hj7cZzlvpQZbCHLD/fteheVSvBel8BNnkR6GOmrp+tO0qE TSmDlpph4zuHMKKHgs71wLTn8KjM1ZF2J69LCbhN4bW4aYYHF79CDFBAkmMLGxKBfe8L 9acOyPuNtnzqCZUVReHLipELXK8Gj7I5tjIUeErXizfd045Wp6CPEa+sCKHqEkBB6FYy +f3wQqnc9qA6hLpx2GYEBEnfGfvdjjQLWGpU/hYkhkZR3nDqx1VcFR6MZgu7nPMmIb2A QnnA== X-Gm-Message-State: APjAAAV2KI0i3jx9UGgrV1b6eUpeQ5MBUGHDghaAm9U+YvbQGR2cqVJh HoK+MOUzORK/IpW0K/58ulxcMSeNII/i0df7BYw= X-Google-Smtp-Source: APXvYqxTpSM4VvLktpOLpbVAva1BdAk554TZk/k/LwQbLNtyWoF09bFkG98+05XExiZxXO5uK2E/woEE3k96wjQp2j0= X-Received: by 2002:a5d:9297:: with SMTP id s23mr12323777iom.49.1570729525648; Thu, 10 Oct 2019 10:45:25 -0700 (PDT) MIME-Version: 1.0 References: <6F040DD1-C2E2-4FD2-BB37-E1B6330230BD@ericsson.com> <149BDA3C-14CF-459F-90D4-5F53DBEF9808@iii.ca> <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> <20191010161657.GA76545@kduck.mit.edu> In-Reply-To: <20191010161657.GA76545@kduck.mit.edu> From: Rob Sayre Date: Fri, 11 Oct 2019 00:45:11 +0700 Message-ID: To: Benjamin Kaduk Cc: Stephen Farrell , Eric Rescorla , Sean Turner via Datatracker , John Mattsson , "tls@ietf.org" , IESG Secretary , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006a223f059491f712" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 17:45:28 -0000 --0000000000006a223f059491f712 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk wrote: > The decision about > whether to make changes to the technical content thus lies with the > sponsoring AD for that document. > > I don't think that is true. Here is one comment from the document shepherd: https://mailarchive.ietf.org/arch/msg/tls/GfbxWMXoSufeAozlzs7i-Tv-MV0 This one of those situations where the IETF rules are deliberately ambiguous (I know most of the rules...). > I disagree that draft-ietf-tls-oldversions-deprecate needs to update all > consumers of DTLS 1.0/1.2, at least for the reason you give. Those > documents properly refer to RFC 6347 (or 4347), and it is that RFC that we > are updating now. We do not directly change those consuming documents' > needs, but rather do so indirectly. > That is not what the draft does. For example, it updates RFC 4823, "FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet". Have you read the draft? > from the IETF perspective > it's approved and done, and the barrier to making any further substantive > changes is extremely high. > Nope, it can get changed. And it can get updated too. It's just a text file, and the rules are fluid. :) thanks, Rob --0000000000006a223f059491f712 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 10, 2019 at 11:17 PM Benjamin= Kaduk <kaduk@mit.edu= > wrote:
The decision about
whether to make changes to the technical content thus lies with the
sponsoring AD for that document.


I don't think that is true. Here i= s one comment from the document shepherd:

This one of those situations where the IETF r= ules are deliberately ambiguous (I know most of the rules...).
= =C2=A0
I disagree that draft-ietf-tls-oldversions-deprecate needs to update all consumers of DTLS 1.0/1.2, at least for the reason you give.=C2=A0 Those documents properly refer to RFC 6347 (or 4347), and it is that RFC that we<= br> are updating now.=C2=A0 We do not directly change those consuming documents= '
needs, but rather do so indirectly.

Tha= t is not what the draft does. For example, it updates=C2=A0RFC 4823, "= FTP Transport for Secure Peer-to-Peer Business Data Interchange over the In= ternet".

Have you read the draft?
= =C2=A0
from the IETF= perspective
it's approved and done, and the barrier to making any further substanti= ve
changes is extremely high.

Nope, it can= get changed. And it can get updated too. It's just a text file, and th= e rules are fluid. :)

thanks,
Rob=C2=A0<= /div>
--0000000000006a223f059491f712-- From nobody Thu Oct 10 11:08:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3878120115 for ; Thu, 10 Oct 2019 11:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wZIAlWEtrEW for ; Thu, 10 Oct 2019 11:08:38 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4161200F6 for ; Thu, 10 Oct 2019 11:08:38 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id r2so5083004lfn.8 for ; Thu, 10 Oct 2019 11:08:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BXIpuazogoZasqI/WuUCj4A+vE8EDgeY9CCG+DJeV9I=; b=00AOJYpqljyj4rtCWGNEuamftgo+izLWcXl3eKidKaF8KuzCoXBJzMn+oB+Kbp1uKM fJM1ZF0MwfpMYZUTgu8CoVJvlGK0HiKpBZxVm+rz+CK6fc/U7Z4YPY58zrwkX0Qp+JAR j70S4V3PA6cVZ1hbPLjFqaTlwC/rK3MEsDsQzJGgxcJoNwKx/8tlNZlyNqbOEFNyMdDp /fcB71qCYTlRDBVmdWQgw3q6uVvw/pinYFhWB8syIYyiHpOzo6VWayURdD3F+1so5BC3 OHdLxuqSjwUEktDJdc9xlSvDZz6e1S2m4P3xBKlny0FWhOYpy/K+Evwa9BJ4CF+7f5xS PrMw== 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=BXIpuazogoZasqI/WuUCj4A+vE8EDgeY9CCG+DJeV9I=; b=hU6PAvEDSlDsXjbRgQe8Fftmv/xXcikYUNeTEYOPYs6HjFYMQym9lTb1iG2JauiiG+ zHWcFmqonXc/o0RBhkJaKq0NWLHBMTQK4A7c5C4WNX1oJv3+/PGMZNNeRwwVCSm8pClx BbdUQ+j2/1ZyCi+0w50BMTLfJL6ydA/HyhILgZnr1xJPOh1mtBbKQjC3Z/TWZo2h26SF RtwvwoGERpGzlRre0Kzlih0CEvPKRhy+KtDtjDDYhwAM1NqtSKM+gDs+M+CqoeJN6DzJ RQF3JYGzTvdvndJopArUPlept7FZ1KzpUbYwRJBN/eHIQAys76rtM9K88+lI41nvmj8Z puUw== X-Gm-Message-State: APjAAAVI/RbJtY9YUIJ3VNeZ/gqaaKhUB1ULxYvC9qx+1i8OPKGNLEgu mGuwPF+STNZYGOfgbmlBfTfnzNYvcFrg0kS7KNHv0A== X-Google-Smtp-Source: APXvYqzTv20O5f6dV1lqbidXDSiuDnp6GtJjKVgYg2nRy8yBTXbPz0lD7x3Twb/v6//0CzQFfOrnT+m27A65lAfoOHU= X-Received: by 2002:ac2:4a75:: with SMTP id q21mr6593155lfp.94.1570730916747; Thu, 10 Oct 2019 11:08:36 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Eric Rescorla Date: Thu, 10 Oct 2019 11:07:59 -0700 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000054d0cd0594924aef" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 18:08:41 -0000 --00000000000054d0cd0594924aef Content-Type: text/plain; charset="UTF-8" On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote: > On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote: > >> >>> I don't think that's quite what I'm proposing. I'm proposing >>> (optionally) sending the SNI with a client certificate. >>> >> >> What are you trying to accomplish by doing that? >> > > I want to keep the SNI encrypted in TLS hops that use client certificates, > but where ESNI won't work. > > For example, how is the SNI transmitted in the parens here: > > [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] > > I don't think a DNS-based solution like ESNI will work for that second > hop, because the origin tends to be identified by an IP address rather than > a domain name. > I feel like we're perhaps talking past each other, so I'm going to start back at the beginning. In the ordinary case of Client -> Origin or Client -> CDN, the SNI principally serves to tell the server which origin the client wants and thus which certificate to serve. For this reason, it has to go in the CH. In the case of CDN -> Origin, it seems like SNI could serve the same purpose (say that the origin server is hosting multiple servers), in which case it seems like the same requirements apply. OTOH, if the origin server just hosts one origin, then you could potentially have the SNI delivered later (as you suggest), but then why have SNI delivered at all? What am I missing? -Ekr > thanks, > Rob > --00000000000054d0cd0594924aef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 9, 2019 at 10:16 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <ekr@rtfm.com> wrote:
=

I don't think that's quite what I'm proposing. = I'm proposing (optionally) sending the SNI with a client certificate. <= /div>

What are you trying to ac= complish by doing that?

I= want to keep the SNI encrypted in TLS hops that use client certificates, b= ut where ESNI won't work.

For example, how is = the SNI transmitted in the parens here:

[ Client ]= -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ]=C2= =A0

I don't think a DNS-based solution like ES= NI will work for that second hop, because the origin tends to be identified= by an IP address rather than a domain name.
=

I feel like we're perhaps talking past each other, = so I'm going to start back at the beginning.

I= n the ordinary case of Client -> Origin or Client -> CDN, the SNI pri= ncipally serves to tell the server which origin the client wants and thus w= hich certificate to serve. For this reason, it has to go in the CH.

In the case of CDN -> Origin, it seems like SNI could = serve the same purpose (say that the origin server is hosting multiple serv= ers), in which case it seems like the same requirements apply. OTOH, if the= origin server just hosts one origin, then you could potentially have the S= NI delivered later (as you suggest), but then why have SNI delivered at all= ?

What am I missing?
-Ekr
=




=

thanks,
Rob
--00000000000054d0cd0594924aef-- From nobody Thu Oct 10 11:19:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998B7120125 for ; Thu, 10 Oct 2019 11:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Nj8GvCNafBCo for ; Thu, 10 Oct 2019 11:19:54 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 4B9F4120113 for ; Thu, 10 Oct 2019 11:19:54 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id u8so15875182iom.5 for ; Thu, 10 Oct 2019 11:19: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=ziKek17lTwROmhiUbZxdKcMUL1oj8NbgeLIMdgdEeQs=; b=mshkxXH46V7jQB8W73dqZetHPanY/EsfyxwLM0m2XK2vD1C/rKc9g34OJgNGB353LB 6bz21iHtDnJzliPuQeYs4hLRMK29inwKANVbLpFRWoXRsUYLV4aZSvpYiHh7DTf4x6fF 9gOoaa2pA+XDotM1C71IC3kzlyWQ8ze2P6fm1WImYyxuo1mcWBMbFhNE5ypQ1AuLLTxs EscHzVk6aIgHcWVpWjmZk7t3VGg5zw0wFOXUgY+XsJ/X17TjwQu9jQMSExgiScdxNyKd 1XMWlbbitPAk0Jy7WTL0QhLukWzJQaRcQb+gppu4aEE0VOrbEON1mdeqGXCnlWPIidHD ezFA== 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=ziKek17lTwROmhiUbZxdKcMUL1oj8NbgeLIMdgdEeQs=; b=RYBV21LVRjrc1+FgLDuCJt1qlr3zscryv0x5ExFIBUIHyGc989yYqxHPWck531TAao tYZ5ExXSMNBglojLOZmSTyDILC97tFMUz9WScr20Qi84VfNEVXvHz1NQTHzDwdd+/vxi MX0RtxIR2FjqzlEuS08pK/MazBAZO9LtHhj5bDpbydraHMMyeNflD+rrF1Y8dwZVtPLi MmKIFN75smgQVDWd7shKSX2G6zSKB4Ty2pQL0cel9fN2iWXaTtfjB11wUXcDxt5z08cm PGsZfGYUYPXSfXAxSo361KB5EUmGtAt28dNWe4slAXha7X6R/1YlWrssRXYOfJJ2+S3b 2LfQ== X-Gm-Message-State: APjAAAWQgrUBHCPlCRU4rSqw5s6C4nHW/upsDB+4CtI9KNWigFVVoh5v ZsIxV/63mAXNsDTRPifqYs1Koe+lYjiQq6UXpOE= X-Google-Smtp-Source: APXvYqzuLdjP36gD5ZZ1/s56od1+ukzdy6LGsuRiKTdHNDENFiMtD/gSWvTXcKyZBkL1UtwVW+zLqdjqT1bccRxzJww= X-Received: by 2002:a02:c646:: with SMTP id k6mr12453175jan.53.1570731593346; Thu, 10 Oct 2019 11:19:53 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Rob Sayre Date: Fri, 11 Oct 2019 01:19:40 +0700 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a8b156059492725f" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 18:19:57 -0000 --000000000000a8b156059492725f Content-Type: text/plain; charset="UTF-8" On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla wrote: > > > On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote: > >> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote: >> >>> >>>> I don't think that's quite what I'm proposing. I'm proposing >>>> (optionally) sending the SNI with a client certificate. >>>> >>> >>> What are you trying to accomplish by doing that? >>> >> >> I want to keep the SNI encrypted in TLS hops that use client >> certificates, but where ESNI won't work. >> >> For example, how is the SNI transmitted in the parens here: >> >> [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] >> >> I don't think a DNS-based solution like ESNI will work for that second >> hop, because the origin tends to be identified by an IP address rather than >> a domain name. >> > > I feel like we're perhaps talking past each other, so I'm going to start > back at the beginning. > > In the ordinary case of Client -> Origin or Client -> CDN, the SNI > principally serves to tell the server which origin the client wants and > thus which certificate to serve. For this reason, it has to go in the CH. > In general, I agree with you. But only because client certificates are relatively rare for end users. If a client certificate is required, the server probably can't send application data in its first response. > > In the case of CDN -> Origin, it seems like SNI could serve the same > purpose (say that the origin server is hosting multiple servers), in which > case it seems like the same requirements apply. OTOH, if the origin server > just hosts one origin, then you could potentially have the SNI delivered > later (as you suggest), but then why have SNI delivered at all? > Two reasons: 1) the SNI could contain subdomain data, like "username.example.com" 2) if there is a client certificate, the SNI might be relevant in deciding whether to accept it I understand that the intermediary (CDN, etc) will be able to observe the SNI, but it's not clear why it's ok that any passive observer to the origin should be able to. thanks, Rob --000000000000a8b156059492725f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 11, 2019 at 1:08 AM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">

On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre <sayrer@gmail.com> wro= te:
On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <ekr@rtfm.com> wrote:
<= div>
I don't think that's quite what I'm proposin= g. I'm proposing (optionally) sending the SNI with a client certificate= .

What are you trying to= accomplish by doing that?

I want to keep the SNI encrypted in TLS hops that use client certificates= , but where ESNI won't work.

For example, how = is the SNI transmitted in the parens here:

[ Clien= t ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ]= =C2=A0

I don't think a DNS-based solution like= ESNI will work for that second hop, because the origin tends to be identif= ied by an IP address rather than a domain name.

I feel like we're perhaps talking past each othe= r, so I'm going to start back at the beginning.

In the ordinary case of Client -> Origin or Client -> CDN, the SNI = principally serves to tell the server which origin the client wants and thu= s which certificate to serve. For this reason, it has to go in the CH.

In general, I agree with you.= But only because client certificates are relatively rare for end users.

If a client certificate is required, the server prob= ably can't send application data in its first response.
=C2= =A0

In the case of CDN -> Or= igin, it seems like SNI could serve the same purpose (say that the origin s= erver is hosting multiple servers), in which case it seems like the same re= quirements apply. OTOH, if the origin server just hosts one origin, then yo= u could potentially have the SNI delivered later (as you suggest), but then= why have SNI delivered at all?

Two reasons:

1) the SNI could contain subdo= main data, like "username.exam= ple.com"
2) if there is a client certificate, the SNI mi= ght be relevant in deciding whether to accept it

I= understand that the intermediary (CDN, etc) will be able to observe the SN= I, but it's not clear why it's ok that any passive observer to the = origin should be able to.

thanks,
Rob=C2= =A0

=C2=A0
--000000000000a8b156059492725f-- From nobody Thu Oct 10 11:39:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C668C120111; Thu, 10 Oct 2019 11:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uOOUv-wiLVw4; Thu, 10 Oct 2019 11:38:57 -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 9479E120127; Thu, 10 Oct 2019 11:38:57 -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 x9AIcqvT019338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 14:38:54 -0400 Date: Thu, 10 Oct 2019 11:38:52 -0700 From: Benjamin Kaduk To: Rob Sayre Cc: "tls@ietf.org" , "tls-chairs@ietf.org" Message-ID: <20191010183852.GG76545@kduck.mit.edu> References: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> <20191010161657.GA76545@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 18:39:00 -0000 On Fri, Oct 11, 2019 at 12:45:11AM +0700, Rob Sayre wrote: > On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk wrote: > > > The decision about > > whether to make changes to the technical content thus lies with the > > sponsoring AD for that document. > > > > > I don't think that is true. Here is one comment from the document shepherd: > https://mailarchive.ietf.org/arch/msg/tls/GfbxWMXoSufeAozlzs7i-Tv-MV0 I don't think the cited message supports your claim (instead, it's just commenting on whether changing the text would have any value independently of the mechanics for doing so). > This one of those situations where the IETF rules are deliberately > ambiguous (I know most of the rules...). I'm the AD for the TLS WG, and am charged with enforcing the rules. If you tell me a rule that I'm not enforcing or am misinterpreting, I'm happy to adjust accordingly, but in the absence of such concrete details, I'm going to trust my knowledge of the rules more than yours. > > > I disagree that draft-ietf-tls-oldversions-deprecate needs to update all > > consumers of DTLS 1.0/1.2, at least for the reason you give. Those > > documents properly refer to RFC 6347 (or 4347), and it is that RFC that we > > are updating now. We do not directly change those consuming documents' > > needs, but rather do so indirectly. > > > > That is not what the draft does. For example, it updates RFC 4823, "FTP > Transport for Secure Peer-to-Peer Business Data Interchange over the > Internet". "for the reason you give" being the operative phrase. > Have you read the draft? Not recently; as noted upthread, it's in my queue of "publication requested" documents accumulated backlog, but I have to do an AD evaluation before it goes to IETF LC. > > > from the IETF perspective > > it's approved and done, and the barrier to making any further substantive > > changes is extremely high. > > > > Nope, it can get changed. And it can get updated too. It's just a text > file, and the rules are fluid. :) I did not say it was impossible, just that there is a very high barrier and in my assessment the value does not justify the cost of changing it. But as I've said repeatedly, I'm not the AD whose judgment matters, and I am confused at why you're continuing to engage on the topic in this forum. -Ben From nobody Thu Oct 10 11:45:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB89120125 for ; Thu, 10 Oct 2019 11:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9ANXU811vPB for ; Thu, 10 Oct 2019 11:45:41 -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 D8B41120089 for ; Thu, 10 Oct 2019 11:45:40 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id x80so5187906lff.3 for ; Thu, 10 Oct 2019 11:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHgvRSOSqIdv9U6dXlsVWRwQEHdTDstEin4SvRaP6YA=; b=LQYbURCHi9l1VZ8DXI0d4bArXzBwPflfDSUhob8VYDNnDucbqgyGVqegXVsID1p6mD phnf9nX6fzj002rWETvhGnwjRgJQpjCC2XCwqdI0gPEHh7AA/OLg2aTQAV89G5XBKqRl UnOtE0jXNKeH6WHiJPxfK/WRcfEGR7xktUeqA44k9tMgbSpxkixWzUeBICkXvOCajlks 2goobA1ysRN4sCakZmOgkEApGoHfQV23KlgZvwaW0TnskCYGRz0dztjJcwoad6npDTcT Lmyh/zfjHVv6w8ZqcJ4lfV5vyopPdi7mHotnisjMItcCJxaPHAiILgrSRtaB7RxjVhns 3jCQ== 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=oHgvRSOSqIdv9U6dXlsVWRwQEHdTDstEin4SvRaP6YA=; b=hxUjAdCm5fo7lu/WjvDSIuSpCD5I28/1uqDQhepZwl+A3rbZ4N6OAceipNiYmhMjif Ewibj+HNVTXe3mi5np8+w7yi+oAZfeKCMhNIYDLAZZMBsalUNj1lNCFaWvy4zZvUkMKn ng7J5bzqmD+nyh1rmQw4u6WSE5oXaa6E/CWaW8ClKOia7PqAMS5axVODGRva27hJ9nnB Q3/5vCXN3CSVEAF26ULtODM9T08JF4sgRInTwaYqy7tH4vBi0/A7AY8K3inleIliWwFD 9PZ+KstGQZ6eT5FmbBnHGW9M2GGPgpr4gAy5/gJ+yCGIAl6s/4sSaSNac/p61DsEeOJb OP9g== X-Gm-Message-State: APjAAAWsPj1cr78a1x+6Qj6xuKB6LD9k8XbB38Pz9Uez0gIG/EjQGg3b sMRZ68ThfsEywlxy0PaOqXLt+bA+QB/VNyx4DJwgSA== X-Google-Smtp-Source: APXvYqyooZkEWpUnCq9BTVSBOcT0eAjdX4wrHjiQ6YTMIzOdIXAdLQz86w02NwOD0ena3QHBj9J7txNmq7c6NPp+RD0= X-Received: by 2002:ac2:4a75:: with SMTP id q21mr6667182lfp.94.1570733139035; Thu, 10 Oct 2019 11:45:39 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Eric Rescorla Date: Thu, 10 Oct 2019 11:45:00 -0700 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ca1af8059492ce3d" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 18:45:44 -0000 --000000000000ca1af8059492ce3d Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 11:19 AM Rob Sayre wrote: > > > On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla wrote: > >> >> >> On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre wrote: >> >>> On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla wrote: >>> >>>> >>>>> I don't think that's quite what I'm proposing. I'm proposing >>>>> (optionally) sending the SNI with a client certificate. >>>>> >>>> >>>> What are you trying to accomplish by doing that? >>>> >>> >>> I want to keep the SNI encrypted in TLS hops that use client >>> certificates, but where ESNI won't work. >>> >>> For example, how is the SNI transmitted in the parens here: >>> >>> [ Client ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origin ] >>> >>> I don't think a DNS-based solution like ESNI will work for that second >>> hop, because the origin tends to be identified by an IP address rather than >>> a domain name. >>> >> >> I feel like we're perhaps talking past each other, so I'm going to start >> back at the beginning. >> >> In the ordinary case of Client -> Origin or Client -> CDN, the SNI >> principally serves to tell the server which origin the client wants and >> thus which certificate to serve. For this reason, it has to go in the CH. >> > > In general, I agree with you. But only because client certificates are > relatively rare for end users. > > If a client certificate is required, the server probably can't send > application data in its first response. > OK, I think we've now reached where we are talking past each other. At a very high level, here's the TLS 1.3 handshake: C->S: CH (w/ SNI) S->C: SH, CERT, CV, FIN C->S: [CERT, CV], FIN In order for the server to send the certificate, which, as you can see, is in its first flight, it has to have the SNI available. This means that it has to go in the client's first flight. But the client's certificate is in the client's second flight. And the client has to have the server's certificate before it sends its certificate, because otherwise it can't authenticate the server and so an active attacker can get the client's cert. If you still disagree, maybe you could show me the ladder diagram you have in mind? -Ekr > >> >> In the case of CDN -> Origin, it seems like SNI could serve the same >> purpose (say that the origin server is hosting multiple servers), in which >> case it seems like the same requirements apply. OTOH, if the origin server >> just hosts one origin, then you could potentially have the SNI delivered >> later (as you suggest), but then why have SNI delivered at all? >> > > Two reasons: > > 1) the SNI could contain subdomain data, like "username.example.com" > 2) if there is a client certificate, the SNI might be relevant in deciding > whether to accept it > > I understand that the intermediary (CDN, etc) will be able to observe the > SNI, but it's not clear why it's ok that any passive observer to the origin > should be able to. > > thanks, > Rob > > > --000000000000ca1af8059492ce3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 10, 2019 at 11:19 AM Rob = Sayre <sayrer@gmail.com> wrot= e:


On Fri, Oct 11, 2019 at 1:08 AM Eric Rescorla <= ekr@rtfm.com> wrot= e:


On Wed, Oct 9, 2019 at 10:16 PM Rob Sayre <sayrer@gmail.com> = wrote:
On Wed, Oct 9, 2019 at 8:06 PM Eric Rescorla <= ekr@rtfm.com> wrot= e:

I don't think that's quite what I'm propo= sing. I'm proposing (optionally) sending the SNI with a client certific= ate.

What are you trying= to accomplish by doing that?

=
I want to keep the SNI encrypted in TLS hops that use client certifica= tes, but where ESNI won't work.

For example, h= ow is the SNI transmitted in the parens here:

[ Cl= ient ] -----> (ESNI) -----> [ CDN ] -----> (???) -----> [ Origi= n ]=C2=A0

I don't think a DNS-based solution l= ike ESNI will work for that second hop, because the origin tends to be iden= tified by an IP address rather than a domain name.

I feel like we're perhaps talking past each o= ther, so I'm going to start back at the beginning.

=
In the ordinary case of Client -> Origin or Client -> CDN, the S= NI principally serves to tell the server which origin the client wants and = thus which certificate to serve. For this reason, it has to go in the CH.

In general, I agree with y= ou. But only because client certificates are relatively rare for end users.=

If a = client certificate is required, the server probably can't send applicat= ion data in its first response.

OK, I think we've now reached where we are talking past each oth= er.

At a very high level, here's the TLS 1.3 h= andshake:

C->S: CH (w/ SNI)
S->C: = SH, CERT, CV, FIN
C->S: [CERT, CV], FIN

In order for the server to send the certificate, which, as you can see, = is in its first flight, it has to have the SNI available. This means that i= t has to go in the client's first flight. But the client's certific= ate is in the client's second flight. And the client has to have the se= rver's certificate before it sends its certificate, because otherwise i= t can't authenticate the server and so an active attacker can get the c= lient's cert.

If you still disagree, maybe you= could show me the ladder diagram you have in mind?

-Ekr

=C2=A0

In the case of CDN -> Origin, it seems li= ke SNI could serve the same purpose (say that the origin server is hosting = multiple servers), in which case it seems like the same requirements apply.= OTOH, if the origin server just hosts one origin, then you could potential= ly have the SNI delivered later (as you suggest), but then why have SNI del= ivered at all?

Two reason= s:

1) the SNI could contain subdomain data, like &= quot;username.exa= mple.com"
2) if there is a client certificate, the SNI m= ight be relevant in deciding whether to accept it

= I understand that the intermediary (CDN, etc) will be able to observe the S= NI, but it's not clear why it's ok that any passive observer to the= origin should be able to.

thanks,
Rob= =C2=A0

=C2=A0
--000000000000ca1af8059492ce3d-- From nobody Thu Oct 10 11:59:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684A41200EF for ; Thu, 10 Oct 2019 11:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9sxjTzXYMECt for ; Thu, 10 Oct 2019 11:59:45 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 52D07120089 for ; Thu, 10 Oct 2019 11:59:45 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id b136so16152257iof.3 for ; Thu, 10 Oct 2019 11:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pBzyQQQ2ZEzzFNM9gCqYrFj4Ck+kfzGiqfYyHAQMAoY=; b=niH1ElbUTUCwli19ouFLfYmroO39kajg62kkA3I6N+6UWbHAFLLdTHwFB6Ga93XKCR E1O1ltrOo/yDB7NKeaWjRVlDX42dHEaYGeXZMtUDdy6eBgq8Eug0E3JBDK7zrWB4qjjd 83T1Hb4taqKu52OCUAhCp8nS+T5zRJGdg9U82YerhqeG0k+dAbboAHwHFXY6RmgBYhsA 2PcLQ7QeYtdi7lzKW//YVDHZH6uFc/x3BCFXd46JxfmIPoj3IDMSCevwiMtzaTdD0HqT Ry0pHjaILcUY5cFN8DmNw5dNQ6mq+Kqp0HO3bG4QK/jRzZGT24SSyMlYJYXKl//WeQzA 36wg== 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=pBzyQQQ2ZEzzFNM9gCqYrFj4Ck+kfzGiqfYyHAQMAoY=; b=baziOB0Ujejz6FXYhnSgjPElZNcsTFIgxE0POMpcEYNdEXL7UYLEnYMwEs7drBU94u n2BEjN+tssZ6ZkY/dfIocJrDFgjTOFwW0dNGWgB8jlr1vd9A7IoydiYscgwqWR9K15tW obTbLg9dhZTkgq8afiKBcWzrH0neS6RxwBsr3ju2RfkKC0ckTfUAW90rqj6rV2ZOJMFG poCDjQ/r9/eNxjXkdgcvlw8iB211CHszj2hTiigS2j96K2kUK7JIvR8RPErfy/K+qj6e 0o25Q3mZ5Gpk2AjJ6WllWD8KSmYPPty78cxW68ypf984MJWcO2+hS58gG7q7rLa4Hd+u GgHA== X-Gm-Message-State: APjAAAXMgfdMYemHO2E1JcFiBg+GwdiE++qBIQJh9FNaEjCs5iikyqoR G3mPaAhGnwfK8onlExfjToPcu8FIdXd95GtWivY= X-Google-Smtp-Source: APXvYqyiYBzPslJSvoQMluFafFPtePxU639jWkssd9Xo32Te6Dqmidfk2mOjOcmYss+a/2f29jWiJcIrzfM0J5KsGDA= X-Received: by 2002:a6b:b807:: with SMTP id i7mr12657094iof.254.1570733984497; Thu, 10 Oct 2019 11:59:44 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Rob Sayre Date: Fri, 11 Oct 2019 01:59:32 +0700 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ec7d505949301ca" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 18:59:47 -0000 --0000000000002ec7d505949301ca Content-Type: text/plain; charset="UTF-8" On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla wrote: > > OK, I think we've now reached where we are talking past each other. > > At a very high level, here's the TLS 1.3 handshake: > > C->S: CH (w/ SNI) > S->C: SH, CERT, CV, FIN > C->S: [CERT, CV], FIN > > In order for the server to send the certificate, which, as you can see, is > in its first flight, it has to have the SNI available. > I think this is the disconnect. The situation you describe is common (sharing an IPv4 address), and I definitely understand why the SNI needs to be in the ClientHello in that situation. > This means that it has to go in the client's first flight. But the > client's certificate is in the client's second flight. And the client has > to have the server's certificate before it sends its certificate, because > otherwise it can't authenticate the server and so an active attacker can > get the client's cert. > > If you still disagree, maybe you could show me the ladder diagram you have > in mind? > The ladder diagram I have in mind is exactly as described in the TLS 1.3 RFC. Assume that the server can't send application data on its first flight, and that the client must send a certificate on its second flight. Then, assume that useful data can be transmitted in subdomain labels to a server that has issued a wildcard certificate. thanks, Rob --0000000000002ec7d505949301ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2019 at 1:45 AM Eric Resc= orla <ekr@rtfm.com> wrote:

OK, I = think we've now reached where we are talking past each other.

At a very high level, here's the TLS 1.3 handshake:

C->S: CH (w/ SNI)
S->C: SH, CERT, CV,= FIN
C->S: [CERT, CV], FIN

In order f= or the server to send the certificate, which, as you can see, is in its fir= st flight, it has to have the SNI available.

I think this is the disconnect. The situation you desc= ribe is common (sharing an IPv4 address), and I definitely understand why t= he SNI needs to be in the ClientHello in that situation.
=C2=A0
This means that it has to go in the client'= s first flight. But the client's certificate is in the client's sec= ond flight. And the client has to have the server's certificate before = it sends its certificate, because otherwise it can't authenticate the s= erver and so an active attacker can get the client's cert.
If you still disagree, maybe you could show me the ladder diag= ram you have in mind?

The= ladder diagram I have in mind is exactly as described in the TLS 1.3 RFC. = Assume that the server can't send application data on its first flight,= and that the client must send a certificate on its second flight.

Then, assume that useful data can be transmitted in subdom= ain labels to a server that has issued a=C2=A0wildcard certificate.

thanks,
Rob
--0000000000002ec7d505949301ca-- From nobody Thu Oct 10 13:38:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7D71200FF; Thu, 10 Oct 2019 13:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 d2VRBPyfaDuO; Thu, 10 Oct 2019 13:38:08 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F92C1200F6; Thu, 10 Oct 2019 13:38:08 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id q1so16825784ion.1; Thu, 10 Oct 2019 13:38:08 -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=Hz75JMZrjpDlULJi5uwelGMiK6qnGHOuw1NPtHVdAQg=; b=ZC4xsnLxRiqZKit6EUF6qMcjWhMA9p1jPrgKW5TO5JlKqWnzsM8JSYt2s///38Pcpt tkQF4IPxzU0ALF9WmrwV8rSXtlAC3zhkNmM+oWDgeoeRc4ciS3MSL5yek1V4cNHuUM5p ZLUP606svSIeOxZd2jyeA0z2SKy/5Rx2S+cJIGiTblU7UaUG3PHUaV6+hI4s3E6JEEz4 A3XPBBCD9adyIkQnm1t0MonSJTYEWaAx7fa1AsTRm2QNQPmHzbObeh4VEXZpJoarXYfG bO3Tf9yVmuOIuUdN4SreyTdE0V4ig/XSLQok1UQav6SHO8h2K95TqMQ4CdHGS7z1GQ1F 95Eg== 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=Hz75JMZrjpDlULJi5uwelGMiK6qnGHOuw1NPtHVdAQg=; b=As9IA4BwmcMI1Ru4HF6cdBij6VkUe4ZWZl08/QTnVAXnB+2174JyOG0gxjCk+gTbFI bLQ0sclo5dZpNjLEQoXOsjWbqI2d1vAS7O/yCNrk1n50tCIMfYiVJ7guHQ1PYd0bfGKE Z/hnTZU/QPr8a+rGN5PDUPug1I4cFGo1BoZ4zNZuz8fPTooCv+itqfzrDbbYuilD2X64 ercIvNoqfdCR0D082zvspkSitIQO9+3z+yYdrRC9kNqmiJNqDxy1LMpzzTuDx6G3LL4N I/YJIRW3YC7nq0uZZjUy+XM4AXnlKEL5epoF81CpP24ylYQDTWPVWuepx5zUaR8bvWA6 bYTw== X-Gm-Message-State: APjAAAViE7lIfspIh4WR2vgSyU4WRZY5QzqRkk4iqREfV3VtRMKMoRPw hhnIBVNpEH73JWQTk7ZcJ+IR7NIIF5Oe7vRuoGg= X-Google-Smtp-Source: APXvYqxqal1ze8RxZfAh3D4ZctzkRWcRutQDC0pFa+oPulj7XxHPAqIMIJDqJD+Kz7rcJg1bFKK56VmmR5sppX2eXHw= X-Received: by 2002:a02:c646:: with SMTP id k6mr13283113jan.53.1570739887466; Thu, 10 Oct 2019 13:38:07 -0700 (PDT) MIME-Version: 1.0 References: <858a91dc-eb59-de20-4abb-7845d55f8a1b@cs.tcd.ie> <20191008120506.GF76545@kduck.mit.edu> <20191010161657.GA76545@kduck.mit.edu> <20191010183852.GG76545@kduck.mit.edu> In-Reply-To: <20191010183852.GG76545@kduck.mit.edu> From: Rob Sayre Date: Fri, 11 Oct 2019 03:37:55 +0700 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" , "tls-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000006edf40594946140" Archived-At: Subject: Re: [TLS] Publication has been requested for 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: Thu, 10 Oct 2019 20:38:10 -0000 --00000000000006edf40594946140 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 11, 2019 at 1:38 AM Benjamin Kaduk wrote: > On Fri, Oct 11, 2019 at 12:45:11AM +0700, Rob Sayre wrote: > > On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk wrote: > > > > > The decision about > > > whether to make changes to the technical content thus lies with the > > > sponsoring AD for that document. > > > > > > > > I don't think that is true. Here is one comment from the document > shepherd: > > https://mailarchive.ietf.org/arch/msg/tls/GfbxWMXoSufeAozlzs7i-Tv-MV0 > > I don't think the cited message supports your claim (instead, it's just > commenting on whether changing the text would have any value independently > of the mechanics for doing so). > It says "You can change the text". thanks, Rob --00000000000006edf40594946140 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2019 at 1:38 AM Benjamin = Kaduk <kaduk@mit.edu> wrote:
=
On Fri, Oct 11, 2019 at 12:45:11AM +0700, Rob Sayre wrote:
> On Thu, Oct 10, 2019 at 11:17 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> > The decision about
> > whether to make changes to the technical content thus lies with t= he
> > sponsoring AD for that document.
> >
> >
> I don't think that is true. Here is one comment from the document = shepherd:
> https://mailarchive.ietf.o= rg/arch/msg/tls/GfbxWMXoSufeAozlzs7i-Tv-MV0

I don't think the cited message supports your claim (instead, it's = just
commenting on whether changing the text would have any value independently<= br> of the mechanics for doing so).

It says &quo= t;You can change the text".

thanks,
Rob=C2=A0
--00000000000006edf40594946140-- From nobody Thu Oct 10 13:57:21 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4388120115 for ; Thu, 10 Oct 2019 13:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pv-4Sut2GtrW for ; Thu, 10 Oct 2019 13:57:16 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 F1C931200F6 for ; Thu, 10 Oct 2019 13:57:15 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id b19so16899732iob.4 for ; Thu, 10 Oct 2019 13:57:15 -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=o5Wbe0+Jj9EksNCInDVNKUPQGpDelUVJFB0FS7tv/uo=; b=m7iUzvGyd8N+xSn6/fgC1bk5aLlPh799SczN9iW3sxxLUAEeS2dfrsmyZUzEsyy7pE XAgBnRsZ7DyDi1/++Urdmp9YGvyQAJI94g05UBL/XJkBEV8yZ4egIVSlJDyxmdaOWNEk qb8OIi1I+PkgJ9FoR3A3nbjXke4JYVkxob++0zycdTJQAExf7wPaICt08l0Yhgvp2MNY 76QS5TqjQp/hyv1lXZgfBvilF08v8cuQ7CXdWT9ey0Yp1KnTqDQNZar8AzCgABTq6Udc +cAq4dRHr7s43q0aYtuQ86DuaonZQKmHwM5y+6izsD18C+rHtRmZNm0YMf4Gohd9iIj3 Tauw== 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=o5Wbe0+Jj9EksNCInDVNKUPQGpDelUVJFB0FS7tv/uo=; b=eiC3p0d+AQhIdgCUQZTGgpxfC+isjqY7d9YWsr5gP6TpBswdlbkabT4mc1eU2SkSwL Fz3VFsrsnvpenpDjoJWxkcz3cZ1jki7g/xjJjCbLF3xgk3YmWVMZQubNDrSFmrMzSOvC 52pgrxBFCutABK9t5orjh+TX3VGoJ7aG6id4SB/ZnghvPsVrNH2q9fMk/K3wsbEjSZvn z88SegGg0FASZFSASS3OAyC8bLM4KT6+oDKNVWdXUPIJpcw1KZlQuH/I/IpMx2PhXew3 BoNP6ZBpacYUuvJaopULBWB8n8GU2JaHat0rJnwqMyTyMUYJhYJNe0ClSeGi8cO73y+V BNGg== X-Gm-Message-State: APjAAAW14cjvBq921Df1kttY2XTEWv/yv3Qg9o3SdDaHfSwA9qK1YBSZ lFFK8aW+/2jmsXrWb0rIIAXXLQES5BZRM1NffLinog== X-Google-Smtp-Source: APXvYqwf/tiWlAt2Mb5yG9epNXxL0B/+epz1XEvLuSj+YNMSHqu2k9Z2xk5LujkDS49+Q/g/EqzqWvRgCFhYVEr7izE= X-Received: by 2002:a02:c4cd:: with SMTP id h13mr13628683jaj.142.1570741034778; Thu, 10 Oct 2019 13:57:14 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Ben Schwartz Date: Thu, 10 Oct 2019 16:57:02 -0400 Message-ID: To: Rob Sayre Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000073f586059494a580" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 20:57:19 -0000 --00000000000073f586059494a580 Content-Type: multipart/alternative; boundary="0000000000006a1dce059494a532" --0000000000006a1dce059494a532 Content-Type: text/plain; charset="UTF-8" Normally, virtual-hosted TLS servers are known to a client by their domain name, and the client uses DNS to find an IP address corresponding to this domain name. The ESNI drafts are largely written in reference to this configuration. I think Rob is describing the case where a TLS client is contacting a virtual-hosted origin that is defined by an IP address and an X.509 Common Name, but for which it does not have a domain name. In this case, reading ESNI public keys out of the DNS is not an option, because there is no domain name to look up. This situation does seem to be reasonably common for connections where the client is a CDN, and the server is an origin backend. (In that case, the domain name may exist, but its IP address and ESNI keys will be the CDN's, not the backend's.) The obvious solution is for the TLS client (i.e. the CDN) to support direct entry of ESNI public keys alongside the IP address. Users who want to be able to rotate their ESNI keys more easily should use a backend identified by a domain name that is distinct from the user-facing origin hostname. I don't think there's any need to couple SNI encryption to use of client certificates, nor is there any need to alter the ESNI protocol. On Thu, Oct 10, 2019 at 3:00 PM Rob Sayre wrote: > On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla wrote: > >> >> OK, I think we've now reached where we are talking past each other. >> >> At a very high level, here's the TLS 1.3 handshake: >> >> C->S: CH (w/ SNI) >> S->C: SH, CERT, CV, FIN >> C->S: [CERT, CV], FIN >> >> In order for the server to send the certificate, which, as you can see, >> is in its first flight, it has to have the SNI available. >> > > I think this is the disconnect. The situation you describe is common > (sharing an IPv4 address), and I definitely understand why the SNI needs to > be in the ClientHello in that situation. > > >> This means that it has to go in the client's first flight. But the >> client's certificate is in the client's second flight. And the client has >> to have the server's certificate before it sends its certificate, because >> otherwise it can't authenticate the server and so an active attacker can >> get the client's cert. >> >> If you still disagree, maybe you could show me the ladder diagram you >> have in mind? >> > > The ladder diagram I have in mind is exactly as described in the TLS 1.3 > RFC. Assume that the server can't send application data on its first > flight, and that the client must send a certificate on its second flight. > > Then, assume that useful data can be transmitted in subdomain labels to a > server that has issued a wildcard certificate. > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006a1dce059494a532 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Normally, virtual-hosted TLS servers are known to a c= lient by their domain name, and the client uses DNS to find an IP address c= orresponding to this domain name.=C2=A0 The ESNI drafts are largely written= in reference to this configuration.

I think Rob i= s describing the case where a TLS client is contacting a virtual-hosted ori= gin that is defined by an IP address and an X.509 Common Name, but for whic= h it does not have a domain name.=C2=A0 In this case, reading ESNI public k= eys out of the DNS is not an option, because there is no domain name to loo= k up.=C2=A0 This situation does seem to be reasonably common for connection= s where the client is a CDN, and the server is an origin backend.=C2=A0 (In= that case, the domain name may exist, but its IP address and ESNI keys wil= l be the CDN's, not the backend's.)

Th= e obvious solution is for the TLS client (i.e. the CDN) to support direct e= ntry of ESNI public keys alongside the IP address.=C2=A0 Users who want to = be able to rotate their ESNI keys more easily should use a backend identifi= ed by a domain name that is distinct from the user-facing origin hostname.<= /div>

I don't think there's any need to couple S= NI encryption to use of client certificates, nor is there any need to alter= the ESNI protocol.

On Thu, Oct 10, 2019 at 3:00 PM Rob Sayre <sayrer@gmail.com> wrote:
On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla <ekr@rtfm.com> wrote:

OK, I think w= e've now reached where we are talking past each other.

At a very high level, here's the TLS 1.3 handshake:
=
C->S: CH (w/ SNI)
S->C: SH, CERT, CV, FIN
C->S: [CERT, CV], FIN

In order for the = server to send the certificate, which, as you can see, is in its first flig= ht, it has to have the SNI available.
<= br>
I think this is the disconnect. The situation you describe is= common (sharing an IPv4 address), and I definitely understand why the SNI = needs to be in the ClientHello in that situation.
=C2=A0
This means that it has to go in the client's firs= t flight. But the client's certificate is in the client's second fl= ight. And the client has to have the server's certificate before it sen= ds its certificate, because otherwise it can't authenticate the server = and so an active attacker can get the client's cert.

If you still disagree, maybe you could show me the ladder diagram yo= u have in mind?

The ladde= r diagram I have in mind is exactly as described in the TLS 1.3 RFC. Assume= that the server can't send application data on its first flight, and t= hat the client must send a certificate on its second flight.

=
Then, assume that useful data can be transmitted in subdomain la= bels to a server that has issued a=C2=A0wildcard certificate.
thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000006a1dce059494a532-- --00000000000073f586059494a580 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDWH8158uMPq2y/GgPlUy6q 2MnOQV1Hb/T3+PrE60Xx0zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMTAyMDU3MTVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAFSbA+dzLOl7XKXbuRyhtrDongfQTMoB9LKP/Jb9i l482/VPJ2oeNel5R/c0gbVTOcZFsuFyJPDx2XPjtOdbeXi0Ao5PSiuxz0vKikwLMrtHUq18WtsHz tp/hAKfgEf7mWQhl5O4BTtQ8HgOo0sZq+XWs3ZM+25Z6sfQGjlUgwdEvtYXxi1XWYPFdu/+2+tSQ /tYRf6o4WtO0DJ9sugqgLaD0tsVE3kSxMgUoK+0FEZ2vLJZg3hbu9M1aAOXvKNIix5JcSvl42YiU v4Iof802/dEXath6WE2s3Ao9EMJoLSfCIAGMUIQZzoqFiKwZHbI68xkE32oiAEnxrhUlV588pg== --00000000000073f586059494a580-- From nobody Thu Oct 10 14:20:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37E2120142 for ; Thu, 10 Oct 2019 14:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mW3VAUtBvuj for ; Thu, 10 Oct 2019 14:20:44 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8655D120125 for ; Thu, 10 Oct 2019 14:20:44 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id q12so5459202lfc.11 for ; Thu, 10 Oct 2019 14:20:44 -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=ZH663P4Lf7b7iBEwrYeCGdU7REQuAik7RB94b8xOMYA=; b=1F/q8q26rMngatREXeFfskp2zFmUI/Zv9tvgEo7HT4qUU7vzAHC+Lxu9oE/RcXWW7i hTxbPgDs61fQmK77c7GPqnX+3D+Hr27+otZkjdpeIw0AN1NI2Y+rAdDxFUNcZ2jrExsV YWb7AI/jM4ozIeAtyzxtayYOoj8KdntU1+SJOOUeOpEJDCw8yIVSEI0LMjXlAP0RslRB 9yyjZMiuVNfrp/2SV7v6yGmvG/L1POj+qHM991Ox+kM71Rk/bsItXK+4IH9nrT1MYaYC 3h04ZWgfoB4Sv0HJagm01JOEOKdAKTg4LWwTqE2ZQW1E9nfMFQ7LF7hGSYFEdubaZaaj YwBQ== 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=ZH663P4Lf7b7iBEwrYeCGdU7REQuAik7RB94b8xOMYA=; b=RdTmIG8TLRKxIuCr+0YvxQQPn7YYH+1uDQNxRtrsgygjFVoyZpX6+isgvG/lK+gyPF 97QvDNii/8ceYyqkmoT54kLfbME1hhuXFeb28OcOeGKPhqp+RyEjec31mP+oKwg3pk7s GgWt3V1+xl9y7mED4aUlSBeU4UuWuc91BaGd/f3mX/eSfuQlTfPS19Za8phVooJg+4IO JqH3v2XhgIw1XLBD8DrccYNXim13jH0WmtPgwPaND0a3AO8FVP+G3dDxLBYCTMnedGmf JWCYT/8O2ouCTZwxRZJYfpwlMhgL42Nt6aE+PJVmnPLbrqMmZJs2CfjS6ufHM/qGP4LL ixow== X-Gm-Message-State: APjAAAU1wPCSth8oRXaRo7OCbkicBb5sgaBdWJGYUMLXrzPjTYdfP350 KgC97nOk4VtnUdlQoPGxL2R+9QWvg9xyuTHD9leAPQ== X-Google-Smtp-Source: APXvYqyy2ohRagwL8tYHFIrHQbPVakKF+GUTxRNXaF8pmylG1KO63yXvp1HWatMPYyHXBteYaU+CylRAA+kUNeooGdI= X-Received: by 2002:ac2:4a75:: with SMTP id q21mr6955758lfp.94.1570742442662; Thu, 10 Oct 2019 14:20:42 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> In-Reply-To: From: Eric Rescorla Date: Thu, 10 Oct 2019 14:20:06 -0700 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005436eb059494f98a" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Thu, 10 Oct 2019 21:20:47 -0000 --0000000000005436eb059494f98a Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 11:59 AM Rob Sayre wrote: > On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla wrote: > >> >> OK, I think we've now reached where we are talking past each other. >> >> At a very high level, here's the TLS 1.3 handshake: >> >> C->S: CH (w/ SNI) >> S->C: SH, CERT, CV, FIN >> C->S: [CERT, CV], FIN >> >> In order for the server to send the certificate, which, as you can see, >> is in its first flight, it has to have the SNI available. >> > > I think this is the disconnect. The situation you describe is common > (sharing an IPv4 address), and I definitely understand why the SNI needs to > be in the ClientHello in that situation. > > >> This means that it has to go in the client's first flight. But the >> client's certificate is in the client's second flight. And the client has >> to have the server's certificate before it sends its certificate, because >> otherwise it can't authenticate the server and so an active attacker can >> get the client's cert. >> >> If you still disagree, maybe you could show me the ladder diagram you >> have in mind? >> > > The ladder diagram I have in mind is exactly as described in the TLS 1.3 > RFC. Assume that the server can't send application data on its first > flight, and that the client must send a certificate on its second flight. > > Then, assume that useful data can be transmitted in subdomain labels to a > server that has issued a wildcard certificate. > What are you anticipating the server would do with the SNI? Ordinarily we expect the host header to be used for host identification purposes. -Ekr > thanks, > Rob > --0000000000005436eb059494f98a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 10, 2019 at 11:59 AM Rob = Sayre <sayrer@gmail.com> wrot= e:
On Fri, Oct 11, 2019 at 1:45 AM Eric Rescorla <ekr@rtfm.com> wrote:

= OK, I think we've now reached where we are talking past each other.

At a very high level, here's the TLS 1.3 handshak= e:

C->S: CH (w/ SNI)
S->C: SH, CER= T, CV, FIN
C->S: [CERT, CV], FIN

In o= rder for the server to send the certificate, which, as you can see, is in i= ts first flight, it has to have the SNI available.

I think this is the disconnect. The situation yo= u describe is common (sharing an IPv4 address), and I definitely understand= why the SNI needs to be in the ClientHello in that situation.
= =C2=A0
This means that it has to go in the cli= ent's first flight. But the client's certificate is in the client&#= 39;s second flight. And the client has to have the server's certificate= before it sends its certificate, because otherwise it can't authentica= te the server and so an active attacker can get the client's cert.

If you still disagree, maybe you could show me the lad= der diagram you have in mind?

=
The ladder diagram I have in mind is exactly as described in the TLS 1= .3 RFC. Assume that the server can't send application data on its first= flight, and that the client must send a certificate on its second flight.<= /div>

Then, assume that useful data can be transmitted i= n subdomain labels to a server that has issued a=C2=A0wildcard certificate.=

What are you anticipatin= g the server would do with the SNI? Ordinarily we expect the host header to= be used for host identification purposes.

-Ek= r


thanks,
<= div>Rob
--0000000000005436eb059494f98a-- From nobody Thu Oct 10 15:36:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A461200E0 for ; Thu, 10 Oct 2019 15:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=lsoePMyg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jPEVCuQP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0sI_MPNRvqA for ; Thu, 10 Oct 2019 15:36:43 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33481200D7 for ; Thu, 10 Oct 2019 15:36:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 5BF2C61F for ; Thu, 10 Oct 2019 18:36:42 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 10 Oct 2019 18:36:42 -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=fm3; bh=gZAPAHM88W/I7wurzIxEcO2L4gXqr+L NgpDibvnGniw=; b=lsoePMyguFb41F7Qm+3/isXJkcadGT12MpE+jL769FB5BO0 kpM8HQNjSIjI2InpVsTTEoz5gLc9MrXQ5N6RkJE/u5eAwYwqG26vrtHhCVVgr1Ih 2VdLzbHcNxsl96AeNauXjX0XpJ+Va8w+BBkY0EEtA+kp+RXPJawzrIL6qNRmEzkQ DuYjcFBSgLernhsTqNYiruqVYZrFgRnNVoPSMKDk+34F6nctc9qwBxsF/DSg7OxJ 7dIT87Og9x84Rd9Lw2BiJFZM0iNLFdciI8m3WAjcpzE5OjnV0Dg0jTb+8LP4WH7w 6knHlIKhJZZpRYi4RbJ1osdqU7AYvJOokMVKciw== 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=fm1; bh=gZAPAH M88W/I7wurzIxEcO2L4gXqr+LNgpDibvnGniw=; b=jPEVCuQP+gpNH48xF/dsws UH4/yFUpGMEScagaLRz5FhvDkmw9s9QAjjhFlPJ6JVdpOSnSgvUJlIBU7zI0cPpY aPS814cDeNYa92mtv1qz9OjEU4Nl6zfHKxIg0oDAKlfrvYjvrGyjGKRynKOfEUdg uR6slT5PsvLRAMDF+vXLeU3R01Mhxa40q/hkDUE7LIsD/ML157A8rpUZqxurjRYA /EXRfbtbWCah/J638HaAHc1L+HP+4KIK7th83E2Tuv7m15cjGPOleJUYKfcGpljD qf8w0T909b6ebUbtWflhYpfBvN7dR0HrzQQUGgnqTtkhJolQwxXWerq4ss2AIuFg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieeggdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7D589E00A5; Thu, 10 Oct 2019 18:36:41 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> Date: Fri, 11 Oct 2019 09:36:19 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?SNI_from_CDN_to_Origin_=28was_I-D_Action=3A_draf?= =?utf-8?q?t-ietf-tls-sni-encryption-08=2Etxt=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 22:36:44 -0000 On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote: > The obvious solution is for the TLS client (i.e. the CDN) to support > direct entry of ESNI public keys alongside the IP address. Users who > want to be able to rotate their ESNI keys more easily should use a > backend identified by a domain name that is distinct from the > user-facing origin hostname. I was about to say the same thing. No need to get fancy. From nobody Thu Oct 10 16:02:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365AE1200D7 for ; Thu, 10 Oct 2019 16:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=SYQu/FA6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CfgxUk2V Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gpbepq7SeRUu for ; Thu, 10 Oct 2019 16:02:09 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2AE12003E for ; Thu, 10 Oct 2019 16:02:09 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id F35F754C; Thu, 10 Oct 2019 19:02:08 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Thu, 10 Oct 2019 19:02:09 -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=fm3; bh=V+xEwiwdxgmBUyCcLANs3NyL5KG2 CRe0av01v7TyCF4=; b=SYQu/FA6xb2/tD76VAWkf+xnSLXauYY0uu0dX47+Dc4s VAoX4UUnh15d9O24a2NrhFpOuWXb9yOwdCa/un7aGUQfne7hAMzzqSL9PdlVHPr6 DNBiPrPULcZP9c3GYmT3YZhky9Em5mHT0f9q3DyTn6vJEoBJEyQ5Kv3RgBofgPGk 81gMdeUreTswofAr3i8OesyM2yy9ahzjDcOb9O5+AFzoJQEgZ51p2vtVrOBDFso4 imenC4KyIyy/TOvz8EJqDf314BIv8I2cjiaMhmxzYTqU12lmDqsPid+GBtaviz9C wCB4WfC2qpPVlrM7SHrlVg8V0l1jTBUEO3FeYaiJYQ== 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=fm1; bh=V+xEwi wdxgmBUyCcLANs3NyL5KG2CRe0av01v7TyCF4=; b=CfgxUk2VujeGWwPOw9m4E0 IC3dGLmP7Oi2fDmzh0uqP8FzoHonXD5/wbzEnF0G9sEkTUMdWcktGSnI3P1RBN2D FpGmXjEGkeLuWJ61djhWFDz2n9XfyubP0Hr4xSjYw8meN6ftpKcnb/9uGpiI7omM 4dAM1rar3PesyRwOdXqT8zTIuysXn+H/TTndZGaYqNGu9twVloN4wvAnbT6N4q8S 5KdxnVCnEPO0g6igGexdBr5h+o1d56pTKH0H4wdKYoepJS8QwbGrBEhHMlHz0EPY yRz8DDj7TWg5VsoymVgGMOPnmREdXdyW79vJsaN6F5VcKG76+1Epcvm5mFErofbA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieeggdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id DE03EE00A5; Thu, 10 Oct 2019 19:02:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <69c7cfbd-fe9f-40fa-b92b-e4b65fa6cb5d@www.fastmail.com> Date: Fri, 11 Oct 2019 10:01:48 +1100 From: "Martin Thomson" To: "'Eric Rescorla'" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS Key Separation PR X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 10 Oct 2019 23:02:12 -0000 Thanks, that was my mistake. I confirmed with our code and we are indeed right up to the line. On Thu, Oct 10, 2019, at 23:37, Eric Rescorla wrote: > > > On Wed, Oct 9, 2019 at 7:01 PM Martin Thomson wrote: > > tl;dr keep the space. > > > > I had a little trouble reproducing the 12 from RFC 8446, so I double-checked. > > > > .... > > > > Working from the base for SHA-256: > > > > The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one to allow for padding. Therefore we have 55 bytes to use without having to run two blocks through SHA-256. > > > > HMAC-Hash = H(K XOR opad || H(K XOR ipad || text)) > > > > Here `K XOR ipad` is the 32 bytes output size of SHA-256, so we are down to 23 bytes for text before it adds a block. > > In HMAC the key consumes an entire input block, so that you are > guaranteed a compression function cycle before the data is added: > > 1) append zeros to the end of K to create a B byte string > (e.g., if K is of length 20 bytes and B=64, then K will be > appended with 44 zero bytes 0x00) > (2) XOR (bitwise exclusive-OR) the B byte string computed in step > (1) with ipad > > https://tools.ietf.org/rfcmarkup?doc=2104#section-2This shifts > everything to the right 32 bytes, which, because context is 32 bytes, > gets us back to 12, I think, though I haven't re-worked through it. > > Here's Ilari's original analysis, if that's helpful: > https://mailarchive.ietf.org/arch/msg/tls/n_TFape7L4HHoKLxGo8CkimZziI > > -Ekr > > > > > > HKDF-Expand = HMAC-Hash(PRK, info | 0x01) > > > > This takes one more. Down to 22. > > > > HKDF-Expand-Label passes info in the form of: > > > > struct { > > uint16 length = Length; > > opaque label<7..255> = "tls13 " + Label; > > opaque context<0..255> = Context; > > } HkdfLabel; > > > > which has a minimal overhead of 2 + 1 + len("tls13 ") + 1 = 10. So we get 12. > > > > "c ap traffic" is 12 bytes long, so yeah it *looks* like we're stuck if we care about not adding too many extra hash iterations. > > > > .... > > > > But if you look at the key schedule, we always provide a context for those cases we use "c ap traffic". Those will always spill over into the next iteration as Context is 32 bytes. So for those cases, we have a whole 32 bytes extra to play with. The only cases with an empty Context are "derived" and "res binder"|"ext binder". Those max out at 10, so we seem to have two whole bytes of wiggle room. > > > > You can safely add the space. > > > > On Wed, Oct 2, 2019, at 08:40, Eric Rescorla wrote: > > > Hi folks, > > > > > > As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key separation. > > > > > > See: > > > https://github.com/tlswg/dtls13-spec/pull/99 > > > > > > Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13" > > > > > > -Ekr > > > > > > _______________________________________________ > > > 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 Oct 10 20:11:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1412F1200D7 for ; Thu, 10 Oct 2019 20:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 3Hp-U_43Qc8g for ; Thu, 10 Oct 2019 20:11:37 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 A5D16120073 for ; Thu, 10 Oct 2019 20:11:37 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id n26so18387427ioj.8 for ; Thu, 10 Oct 2019 20:11:37 -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=S1jcNu8XROEiy2McHjbwShFZgpopaDo4dW/60NeDHko=; b=ZXHi8a5EWrLzZzqSG7ErxZUE2zkAkfknZcI+9FFlY4zv45x3kMpr3WOWKBZHHEQqBZ pSrKogMqt16/5wpWZ85N22hAy/0xos95cF1o2YdXGVp9d9+9BuCcLJYmhkm09nGAKDXJ bNGk2htBnJ45iX8GiSU2wH2dkLmIjuawydNEBnFxcaMIcOmZtZBcbFFil5tgm4iRNF3M KTeYahE+t/6mI3sopPPYBqFZNt1ys36H65ZAFv20/BVqL4PJ89mHhgLaLRDn1sDXSofX naoxyYE+bcrfYs+zZN4Np5f7xkP94Q61ng+EHhDFMrjkPXLf5JZSmpXggWWwaNVkSt72 ycuA== 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=S1jcNu8XROEiy2McHjbwShFZgpopaDo4dW/60NeDHko=; b=tafBHfOeZZ4VnXrX/oiVhzgJhNrmptDF+bLJAikiE1O/c7Q/8bJkDtR9VV+0txE07p ZCNZiXR3Vv4egD9ASJ7Xm8xgi9z2oY7xX+LllcsY0zTR+So0UnTPhiCeGZdHySQnriq3 PgWSuV39lSGU90yAq4aksmQKHcvUzYMqioG+2KCqA+XNWLNPJGJ7/wcozgjr5rn1QvsY InvXd7jECNcIorAiq3HWaL2oB1a6LebQFRlCEqcouRaRKhM29EdsJC1yrtvM432ZiU6g MOphrMbr+vsAwie7SPtlkPsGiiAh330xrvnaLDdSLG2HEo3uEfRFE2uAstRZYvTEZPup xJ5A== X-Gm-Message-State: APjAAAWlXggde6MxHhBStgK5dZiJ17Ss8Uk//ozokjDx1z2oXhWG0h5f 34zEZUhjWui8MvPeAVw2zH7znm+kZ23I48Nm/MTJTiDufs5v/g== X-Google-Smtp-Source: APXvYqyEz7KGk0XMFjMek1wpuy25r1zrBUqKWCNukDmwA8P6w/H91eCZwNHpg/xZsuIunReETeAJsV0VXDpLqeVwXFw= X-Received: by 2002:a05:6638:2a1:: with SMTP id d1mr4048001jaq.103.1570763496723; Thu, 10 Oct 2019 20:11:36 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> From: Rob Sayre Date: Fri, 11 Oct 2019 10:11:24 +0700 Message-ID: To: Martin Thomson Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003f9aee059499e0d9" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 03:11:39 -0000 --0000000000003f9aee059499e0d9 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson wrote: > On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote: > > The obvious solution is for the TLS client (i.e. the CDN) to support > > direct entry of ESNI public keys alongside the IP address. Users who > > want to be able to rotate their ESNI keys more easily should use a > > backend identified by a domain name that is distinct from the > > user-facing origin hostname. > > I was about to say the same thing. No need to get fancy. > Isn't that more complicated than sending the SNI in the second client message, though? thanks, Rob --0000000000003f9aee059499e0d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2019 at 5:37 AM Martin Th= omson <mt@lowentropy.net> wr= ote:
On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote:
> The obvious solution is for the TLS client (i.e. the CDN) to support <= br> > direct entry of ESNI public keys alongside the IP address. Users who <= br> > want to be able to rotate their ESNI keys more easily should use a > backend identified by a domain name that is distinct from the
> user-facing origin hostname.

I was about to say the same thing.=C2=A0 No need to get fancy.

Isn't that more complicated than sending the SN= I in the second client message, though?

thanks,
Rob=C2=A0
--0000000000003f9aee059499e0d9-- From nobody Thu Oct 10 20:15:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E5E1200D7 for ; Thu, 10 Oct 2019 20:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 QlJhu5dFhqHG for ; Thu, 10 Oct 2019 20:15:39 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1EC120045 for ; Thu, 10 Oct 2019 20:15:39 -0700 (PDT) Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id ECBF82B5AA8 for ; Thu, 10 Oct 2019 23:15:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: <2781261d-bfa2-4c40-9ca4-6a3a1c9266df@www.fastmail.com> Date: Thu, 10 Oct 2019 23:07:10 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: <5816BBD1-14EE-4B72-AEC4-AC7D576C4823@dukhovni.org> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8c2b10b3-bfc2-44b0-997a-1cab0789f1b7@www.fastmail.com> <2781261d-bfa2-4c40-9ca4-6a3a1c9266df@www.fastmail.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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, 11 Oct 2019 03:15:41 -0000 > On Oct 9, 2019, at 9:04 PM, Martin Thomson wrote: >=20 > I think that the discussion Victor started about the number of tickets = you might want to supply being different for a resumed connection is a = sensible one, but I would caution against servers making inferences, = especially in light of a very clear signal from clients. Advice for = client implementations might be wise, so that servers are less motivated = to make these sorts of decisions. THanks for the above. I share much the sentiment. There's just one thing I see no way to do, without a somewhat more nuanced interaction between client and server. * The client has a what it believes to be a valid ticket and is willing to re-use it, and would prefer to avoid the cost of replacing it on each resumption. * The server is happy to allow re-use of still valid tickets by clients, but needs to know whether the client wants a new ticket (because it never re-uses). * The server would like to vend a new ticket only when the old one needs to be refreshed (ticket lifetime or STEK rotation). In the context of the draft as-is, such a client and server have a time arriving at a mutually compatible configuration. 1. If the client requests zero tickets, the server might decide the client never wants tickets. Perhaps here, we could say that if the client in fact presented a resumption PSK, then it should get zero tickets most of the time, but 1 if the ticket needs to be replaced. [ This may not quite work right if the presented resumption PSK turned out to already be expired and a full handshake took place. In that case the server may not retain any knowledge of the original resumption attempt by the time the handshake is complete. And for PSKs that fail to decrypt, it may not be possible to know whether the PSK even was a ticket-based resumption attempt or not. ] 2. If the client requests one ticket, the server can't distinguish between clients that want 1-to-1 replacement, because they implement single-use, and those that only want one if needed. 3. When a client gets a new ticket, it has no idea whether the original one is still valid, and so must discard the old and switch to the new. So servers that vend a new ticket each time force clients to constantly update their ticket store, which is sometimes problematic. Therefore, I am trying to see whether there's a bit of wiggle-room here for better coordination between server and client. The simplest I've been able to come up with is to make 0 mean send no tickets, and 1 mean send 1 as needed, and for n >=3D 2, mean send n-1 unconditionally. But perhaps some else has a more elegant design that addresses the above? --=20 Viktor. From nobody Thu Oct 10 20:28:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615F8120045 for ; Thu, 10 Oct 2019 20:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 KqKG8HQJEsrh for ; Thu, 10 Oct 2019 20:28:19 -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 018D8120025 for ; Thu, 10 Oct 2019 20:28:18 -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 x9B3Qoaq005231; Fri, 11 Oct 2019 04:28:16 +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=mjvTGR4+o2Xe7IW4F3IMfqBV8jiqHW+s+3jvrVzKebY=; b=RkUjyFj+E8idyXYI8CRKsyGQ6ZcMtkVup67WoUCN/6wpmbfzrPS52c0AydRWxyr9Cmn4 KBpvmaZv6UrlhHeVwWl0QcJ+oghU2rK2M9ApoEHRgZh73ppelqveNHAzfp5muMLlr3NR 3u1e7Wgznc4iaKIDFiDbE+JI9gCirTR/DxHRV4mFeq0P0WsgaDFxHHxpi5RtDFlXdSSH fBJJAiMtvUltN4CL5YUlooO3AB8FSawWPaAzHr6uPi95y9uJTFWtMVVQBBrk8+C4bsF5 7KXZBEGydv42xaiNC1ApEUV8lbhvxS52dPPMMfpxFqP3FWsgCto1a63NCs3oFLeru7G+ 4Q== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vejq57u2j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 04:28:16 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9B3H2sK003228; Thu, 10 Oct 2019 23:28:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 2veph10kuv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Oct 2019 23:28:13 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 10 Oct 2019 22:28:11 -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.1473.005; Thu, 10 Oct 2019 22:28:11 -0500 From: "Salz, Rich" To: Rob Sayre , Martin Thomson CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVf+GsnWryPMhc506+pN76L/UXB6dU2M8A Date: Fri, 11 Oct 2019 03:28:10 +0000 Message-ID: References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.141] Content-Type: multipart/alternative; boundary="_000_D6F41392CB9C493584BB3045D342607Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-11_01:, , 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=886 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910110028 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-11_01:2019-10-10,2019-10-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 suspectscore=0 priorityscore=1501 bulkscore=0 adultscore=0 mlxlogscore=871 spamscore=0 clxscore=1015 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910110029 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 03:28:21 -0000 --_000_D6F41392CB9C493584BB3045D342607Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pklzbid0IHRoYXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIHNlbmRpbmcgdGhlIFNOSSBpbiB0aGUg c2Vjb25kIGNsaWVudCBtZXNzYWdlLCB0aG91Z2g/DQoNClRoZSBzZXJ2ZXIgbmVlZHMgdG8ga25v dyB3aGljaCBjZXJ0IHRvIHVzZSBhZnRlciBpdCByZWNlaXZlcyB0aGUgKmZpcnN0KiBjbGllbnQg bWVzc2FnZS4NCg0K --_000_D6F41392CB9C493584BB3045D342607Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <79ABF8F886BF7B43A4DC862DBCBA3300@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5Jc24ndCB0aGF0IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBzZW5kaW5nIHRoZSBTTkkgaW4gdGhl IHNlY29uZCBjbGllbnQgbWVzc2FnZSwgdGhvdWdoPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBzZXJ2ZXIgbmVlZHMgdG8ga25vdyB3aGljaCBj ZXJ0IHRvIHVzZSBhZnRlciBpdCByZWNlaXZlcyB0aGUgKjxiPmZpcnN0PC9iPiogY2xpZW50IG1l c3NhZ2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D6F41392CB9C493584BB3045D342607Bakamaicom_-- From nobody Thu Oct 10 20:49:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836FE1200B7 for ; Thu, 10 Oct 2019 20:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lwFbj8Xw5qj5 for ; Thu, 10 Oct 2019 20:49:31 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 63BC912004C for ; Thu, 10 Oct 2019 20:49:31 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id w12so18490247iol.11 for ; Thu, 10 Oct 2019 20:49:31 -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=LBkguoJWku27DNyAGwlCoYheKte+Qs2yi7qiZ/Bq7fM=; b=BemxbLZ1pYGAk1a8bgJwvSXbxeXYfDREsajdnjno3JWbin8ovK0SPyBBy+S8jC7ZpD 0/8VJknZeihPkem5zAMFsKtlvr7CGbkHeK2TsOx6PNuek9cSm1bw/FnZ/bdvXWG/SiDQ 0wjXxZ2xh/XVpbI89hwtTC2dzMexWTOjnIj3BTUi8j9CCRofG6Jv4iUChsFA7HhpXnri rxmMQgYJjNtua3QpqVXru40oId/7YfKD9clLaNUavGiCYVCcXa9QxvX6fcO7G5fnN7vd yVtVrwS3TDdx/rD+XUF3vuE1n7ewq0ZgZykYZ6EBEnMEl4ADhTWJMNJS1R/1wH5HeJDr 3dQw== 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=LBkguoJWku27DNyAGwlCoYheKte+Qs2yi7qiZ/Bq7fM=; b=YGEi3Q+XmP8nJeeDw38UMod7xPeergCXpku5OgutAuoo3b0hCsr70F6QlDC5tV95ZH aSQs3TTokuE5b6tLiTjbfeuKGuKkg6CKs7mTnAo82LalYMK4c9b1jpWQ6Zsj5dWjAD22 l+XCEAmTQvbaJO8Gv3OxhCa02T1CqapVh+chYhV97wxqT1m/2lNUZUrj59qeReoybA0F uKoIOL6ks1zBwx3P5+xiDVIaHPpFggAvpChUrFAbi6xDqr+fJcUoJx+9HnNcMuZ9vFYk l5Oa3qbvI92nk10QRwgSRexocTl2okLa8926UIdejnB5fY/fvhTnuHVSP7I4RVnU5Ihh 7+qg== X-Gm-Message-State: APjAAAXVGeUS+TaPYY1i8U3QclCdA8MmfF36EnBnOwDksgNxbcchMJ7g Wl/5FSZBbSu2wentbDHTlyQwadP7rlg+4kk+KQY= X-Google-Smtp-Source: APXvYqyQHJgBYcUtGHADEsdEKVwrXxIKPJCa1v8WQQdn5qxuj33HPNxKabubrW9RhHtuKHxi7oFnbfztQSs7oZhQ76c= X-Received: by 2002:a6b:b807:: with SMTP id i7mr15379409iof.254.1570765770568; Thu, 10 Oct 2019 20:49:30 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Fri, 11 Oct 2019 10:49:18 +0700 Message-ID: To: "Salz, Rich" Cc: Martin Thomson , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c7b96f05949a67fb" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 03:49:34 -0000 --000000000000c7b96f05949a67fb Content-Type: text/plain; charset="UTF-8" On Fri, Oct 11, 2019 at 10:28 AM Salz, Rich wrote: > *>*Isn't that more complicated than sending the SNI in the second client > message, though? > > > The server needs to know which cert to use after it receives the **first** > client message. > If the CDN ---> Origin traffic is IPv6, there's no need to serve multiple certs from one IP address. But, if the original request was for "username.example.com" to a CDN IPv4 address shared by many sites, my question is how "username.example.com" would reach the origin and remain encrypted. I think a few people have suggested uploading ESNI keys to the CDN, but it's not clear to me what domain they would be for. Maybe the best thing to do is just set up a site that documents whether the CDN is sending SNI in the clear. I'm not really attached to any given solution, but that will probably help them find one. thanks, Rob --000000000000c7b96f05949a67fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2019 at 10:28 AM Salz, Ri= ch <rsalz@akamai.c= om> wrote:

>Isn= 't that more complicated than sending the SNI in the second client mess= age, though?


The server needs to know which cert to use after it receives the *first<= /b>* client message.


= If the CDN ---> Origin traffic is IPv6, there's no need to serve mul= tiple certs from one IP address.

But, if the origi= nal request was for "username.= example.com" to a CDN IPv4 address shared by many sites, my questi= on is how=C2=A0"username.examp= le.com" would reach the origin and remain encrypted. I think a few= people have suggested uploading ESNI keys to the CDN, but it's not cle= ar to me what domain they would be for.

Maybe the = best thing to do is just set up a site that documents whether the CDN is se= nding SNI in the clear. I'm not really attached to any given solution, = but that will probably help them find one.

thanks,=
Rob
--000000000000c7b96f05949a67fb-- From nobody Fri Oct 11 00:00:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26371200F7; Fri, 11 Oct 2019 00:00:09 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 i9KNvFvFmY_C; Fri, 11 Oct 2019 00:00:07 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50046.outbound.protection.outlook.com [40.107.5.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 035C112008B; Fri, 11 Oct 2019 00:00:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fIinv3GNBlU7vg5k4xuVfRMiQuebsfQUgdLHWLUe66UPjF2iDPU6j9SODfD7lLbktFGxzgKsZBaLrrD4EAh1OcfB+blPfcB9LayfLRXYnocgLxr8WdOqz9q0zj0v/MuNwc5pT7+oAQxK5wVhXbsCVBq64Xe0IJjVGnZACPSV5SiUd6l/BhH3FoEzzJd3gWbM3GCSWg1nrB3pM0ppWswmtWPu0EUWYqWE6zkNrOkr+Bt6j2TaxlS2Lsvrp4sWFH7mQpw5UkPqETjLTNnrVL+3vQQNjw9HoYEl/MKSumyQCAsnE4xbROnIf78lmgAmNlPwa4JUI0n6iwLWE5Nk2rJUwg== 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=dNh73YD33BCxI7XyMMf689J6XS9bIsk8RPuz3khxZdI=; b=PVuq5jePRSfDXDz/a6X2v/0NQD8XC0Er/b776rMF6jbntyfuyUORvH2uQjdMtnRxZVCSFaGVvj4Xu6GfQ6FvSLkePutjk4IO9oUOXXyJ0S74MlOer6CFFJHOd3XsFBnU0peW/NCVd2md63IgfnG1NZTTjgpi0dGhE0pM5ZwVb9aqVOUBDeoj+tJFSLJLL7PlUEYa79l674KJYVhnnNVXcHsXt4kxuTRd4vsOdkUPBLJH6WfwEXMBs5sUhdTOzcmVcVCMX+NppcpM3DOnyKVjkB4O4cY0WxzGxcR12uor0XVba4r+2U62iVoOBxzrSC7Jx1/L0w6WkGLwmokSxBSyrw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dNh73YD33BCxI7XyMMf689J6XS9bIsk8RPuz3khxZdI=; b=neX2RA2aldL0sjS3ZpvSVviFeRBBjMNpXhYq6kgLH3lo+cVUJEWCOsc0B2mwCXMFU80kMYshU70Cpi3k3h2H7QcPGa87QFoxXeDjMZIXqnuSsKmlkgMSQh4MNxB7f2gh3PSkwO5Tvy63SMaQf6armQWObIsJhs5+XoflXpwJux8= Received: from HE1PR07MB3161.eurprd07.prod.outlook.com (10.170.245.23) by HE1PR07MB3516.eurprd07.prod.outlook.com (10.170.248.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Fri, 11 Oct 2019 07:00:00 +0000 Received: from HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::14d0:5c4f:26b7:b6e9]) by HE1PR07MB3161.eurprd07.prod.outlook.com ([fe80::14d0:5c4f:26b7:b6e9%3]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 07:00:00 +0000 From: Christer Holmberg To: Nick Sullivan CC: "gen-art@ietf.org" , "draft-ietf-tls-exported-authenticator.all@ietf.org" , "ietf@ietf.org" , "" Thread-Topic: Genart last call review of draft-ietf-tls-exported-authenticator-09 Thread-Index: AQHVbmsQQiMh+1FWRUS8h+cw2bI1hKcy5WaAgAC48gCAALCBAIAe3NkAgAIswIA= Date: Fri, 11 Oct 2019 06:59:59 +0000 Message-ID: <7F09A9E2-6455-45EB-808A-2951DCCA26AB@ericsson.com> References: <156249708979.14501.13745976049183757305@ietfa.amsl.com> <7BDE969A-7B5F-4979-B4E9-7E6C03C0A1B1@ericsson.com> <57E5EB36-6A59-45A7-A2F4-1E1626391742@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com; x-originating-ip: [89.166.49.243] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 755e078a-c313-4220-87e8-08d74e18a215 x-ms-traffictypediagnostic: HE1PR07MB3516: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(54094003)(189003)(199004)(66066001)(446003)(6436002)(4326008)(2616005)(476003)(256004)(14444005)(14454004)(316002)(486006)(71200400001)(71190400001)(11346002)(58126008)(8676002)(6486002)(5660300002)(54906003)(44832011)(81156014)(81166006)(6246003)(86362001)(229853002)(66446008)(236005)(2906002)(606006)(7736002)(33656002)(6916009)(66946007)(3846002)(6116002)(186003)(66476007)(6512007)(76176011)(64756008)(53546011)(478600001)(6506007)(66556008)(99286004)(102836004)(54896002)(6306002)(76116006)(8936002)(25786009)(91956017)(26005)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3516; H:HE1PR07MB3161.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pkihoj7h4DMadsg8lLPsA8rXP0c1WeiamYd98WjvBbZpH7pqylH+BdBTCO64mtDEIeGtemhDCxSXy9E7JcBjvKXpE6+HD7XrOx3VapiF271XYBJmrUL+BoNBEgMphGw9BdgSr0XHLMnB0I3Ps55fWZZYS4kL6qZUFJxEFzTPixZJ5u3AVpdX0TGcguWaTYM7wSaXs9Lcd3KHQBWC17pyg+4PeVbSF0ZkXoxWOFyX828Y7RDH8d5zGa48s6hZ+V2VPsUYCHfw6SobCmX7dzSidR0rKFl2DPYrNywtOv/Lzvs0c2V5i/J4tkOvGEiFsBbWUdHHT7Q89pcnsdCMRPljoHeIxeOBDY7PRD68ePinLMh9BTg8gNmxBOUzwmqrySyFqZWvNilJ25t9T7auH+sm5RytvV0QxS6VB0a4hbRSI/GxfS2HWVLqj+JTgFY3x10/5Pmj2L9E8k1hWks4JeseHg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7F09A9E2645545EB808A2951DCCA26ABericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 755e078a-c313-4220-87e8-08d74e18a215 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 07:00:00.0526 (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: m4qDH5qG4dKybgqophQ7mXu+JdAHDz1aebaVdvSKRUWx4C1hjdVIXRC7jPrD+mLVqQikAmRXz92ll3xDFKZyujY8LGk+VMPiy5hiGh40kqc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3516 Archived-At: Subject: Re: [TLS] Genart last call review of draft-ietf-tls-exported-authenticator-09 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 07:00:10 -0000 --_000_7F09A9E2645545EB808A2951DCCA26ABericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5UaGFua3MgYWdhaW4gZm9yIHlvdXIgcmV2aWV3ISBUaGUgUFIgaXMgb24gR2l0aHVi IChodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3IvcHVs bC81MDxodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3VybD9rPTQ0ZTRjYjZjLTE4NmQxMTQw LTQ0ZTQ4YmY3LTBjYzQ3YWQ5M2RhMi1kNjc0YmQ0MWEwOTRkNGJiJnE9MSZ1PWh0dHBzJTNBJTJG JTJGZ2l0aHViLmNvbSUyRnRsc3dnJTJGdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3IlMkZwdWxs JTJGNTA+KSBhbmQgd2lsbCBiZSBpbmNvcnBvcmF0ZWQgaW50byBhIG5ldw0KPnZlcnNpb24gb2Yg dGhlIGRvY3VtZW50IHRoYXQgYWRkcmVzc2VzIGJvdGggeW91ciBjb21tZW50cyBhbmQgdGhvc2Ug YnkgWWFyb24gU2hlZmZlci4NCg0KTG9va3MgZ29vZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KT24gVGh1LCBTZXAgMTksIDIwMTkgYXQgMTE6MjkgUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KPlNvbWUgYW5zd2VycyB0byB5b3VyIHF1ZXN0aW9u cyBpbmxpbmUuIEknbSBub3Qgc3VyZSBmdXJ0aGVyIGNoYW5nZXMgYWxvbmcgdGhlIGxpbmVzIHN1 Z2dlc3RlZCBoZXJlIGFyZSBuZWVkZWQsIGJ1dCBJJ20gb3BlbiB0byBhcmd1bWVudHMgdGhhdCBw b2ludCBpbiB0aGF0IGRpcmVjdGlvbi4NCg0KSSBhbSBtb3N0bHkgZmluZSB3aXRoIHlvdXIgYW5z d2Vycy4gSnVzdCBhIGNvdXBsZSBvZiBjb21tZW50cyBpbmxpbmUgc3RpbGwuDQoNCi0tLQ0KDQpN SU5fMjoNCg0KPj4+PiBDYW4gdGhlIG1lY2hhbmlzbSBiZSB1c2VkIGFsc28gZm9yIERUTFM/DQo+ Pj4NCj4+PiBJIHRoaW5rIHRoZSBhbnN3ZXIgaXMgeWVzLiBJIGRvbid0IHNlZSBhbnkgcmVhc29u IHRvIGRpc2FsbG93IHRoZSB1c2Ugb2YgRXhwb3J0ZWQgQXV0aGVudGljYXRvcnMgaW4gRFRMUy4N Cj4+DQo+PiBXb3VsZCBpdCBiZSB1c2VmdWwgdG8gY2xhcmlmeSB0aGF0Pw0KPg0KPiBHb2luZyB0 aHJvdWdoIHdoYXQgdGhlIG1vZGlmaWVkIHRleHQgd291bGQgbG9vayBsaWtlLCBpdCBzZWVtcyBs aWtlIGEgc3Vic3RhbnRpYWwgYW1vdW50IG9mIHJlLXdyaXRpbmcgKGV2ZW4gdGhlIHRpdGxlISkg Zm9yIHdoYXQgYW1vdW50cyB0byBhbiB1bmNsZWFyIHVzZSBjYXNlLg0KPiBLZWVwaW5nIGluIG1p bmQgdGhhdCBEVExTIDEuMyBoYXNuJ3QgYmVlbiBmaW5hbGl6ZWQgYW5kIGRvZXNuJ3QgZGlyZWN0 bHkgZGVmaW5lIGV4cG9ydGVycywgSSdtIGRpc2luY2xpbmVkIHRvIGRlZmluZSBob3cgRUFzIHdv dWxkIHdvcmsgd2l0aCBEVExTLiBJZiBzb21lb25lDQo+IGhhcyBhIHN0cm9uZyB1c2UgY2FzZSBm b3IgRUEgaW4gRFRMUywgaXQgbWF5IGJlIHdvcnRoIGNvbnNpZGVyaW5nIGl0Lg0KDQpXb3VsZCBp dCB0aGVuIGJlIHVzZWZ1bCB3aXRoIGEgc3RhdGVtZW50IHNheWluZyB0aGF0IGl0IG1pZ2h0IGJl IHBvc3NpYmxlIHRvIHVzZSBleHBvcnRlcnMgYWxzbyB3aXRoIERUTFMsIGJ1dCB0aGF0IHN1Y2gg dXNhZ2UgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIGRvY3VtZW50IGFuZCBuZWVkcyB0byBi ZSBzcGVjaWZpZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudD8NCg0KSSBhZGRlZCBhIGxpbmUgdG8g dGhpcyBlZmZlY3QuDQoNCi0tLQ0KDQpNSU5fMzoNCg0KPj4+PiBUaGUgZG9jdW1lbnRzIHRhbGsg YWJvdXQgYWRkaXRpb25hbCBjZXJ0aWZpY2F0ZXMuIElmIEkgb25seSBoYXZlIG9uZSBhZGRpdGlv bmFsDQo+Pj4+IGNlcnRpZmljYXRlLCBjYW4gSSB1c2UgdGhhdCBmb3IgbXVsdGlwbGUgYXV0aGVu dGljYXRvcnMgdGhyb3VnaG91dCB0aGUgVExTDQo+Pj4+IHNlc3Npb24/DQo+Pj4NCj4+PiBZZXMs IHRoZXJlIGlzIG5vdGhpbmcgZGlzYWxsb3dpbmcgdGhlIGNyZWF0aW9uIG9mIG11bHRpcGxlIGV4 cG9ydGVkIGF1dGhlbnRpY2F0b3JzIHdpdGggdGhlIHNhbWUgY2VydGlmaWNhdGUuDQo+Pg0KPj4g V291bGQgaXQgYmUgdXNlZnVsIHRvIGNsYXJpZnkgdGhhdD8NCj4NCj4gSSdtIG5vdCBjb252aW5j ZWQgdGhpcyBpcyBhIHJlYWxpc3RpYyB1c2UgY2FzZS4gU2luY2UgZXhwb3J0ZWQgYXV0aGVudGlj YXRvcnMgYXJlIGJhc2VkIG9uIHRoZSBleHBvcnRlciwgdGhlcmUgaXMgbm8gaW5oZXJlbnQgb3Jk ZXJpbmcuDQo+IElmIHlvdSByZS1hdXRoZW50aWNhdGUgd2l0aCB0aGUgc2FtZSBjZXJ0aWZpY2F0 ZSwgdGhlcmUncyBub3RoaW5nIGFzc2VydGluZyBmcmVzaG5lc3Mgb2YgdGhlIHNlY29uZCBjZXJ0 aWZpY2F0ZS4gSXMgdGhlcmUgc29tZXRoaW5nIGluDQo+IHRoZSB0ZXh0IHRoYXQgc3VnZ2VzdHMg dGhhdCB1c2luZyBhIGNlcnRpZmljYXRlIG11bHRpcGxlIHRpbWVzIGlzIGRpc2FsbG93ZWQ/IElm IHRoZXJlJ3Mgbm8gc3VnZ2VzdGlvbiB0aGF0IHRoaXMgaXMgbm90IHBvc3NpYmxlIHRoYXQNCj4g bmVlZHMgdG8gYmUgY29ycmVjdGVkLCBJIGRvbid0IHNlZSB0aGUgYmVuZWZpdCBvZiBjYWxsaW5n IG91dCB0aGlzIHNwZWNpZmljIHVzZSBjYXNlLg0KDQpJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFu eSB0ZXh0IHN1Z2dlc3RpbmcgdGhhdCBpdCBpcyBkaXNhbGxvd2VkLiBCdXQsIGlmIHlvdSBkb24n dCB0aGluayBpdCBpcyBhIHJlYWxpc3RpYyB1c2UgY2FzZSBJJ2xsIHRha2UgeW91ciB3b3JkIGZv ciBpdCA6KQ0KDQotLS0NCg0KRURfMjoNCg0KPj4+PiBTZWN0aW9uIDMgc2F5czogIlRoZSBhdXRo ZW50aWNhdG9yIHJlcXVlc3QgaXMgYSBzdHJ1Y3R1cmVkIG1lc3NhZ2UgdGhhdCBjYW4gYmUNCj4+ Pj4gY3JlYXRlZC4uLiIgU2VjdGlvbiA0IHNheXM6ICJUaGUgYXV0aGVudGljYXRvciBpcyBhIHN0 cnVjdHVyZWQgbWVzc2FnZSB0aGF0IGNhbg0KPj4+PiBiZSBleHBvcnRlZC4uLiINCj4+Pj4NCj4+ Pj4gSW4gdGhlIDJuZCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0IGl0IGlzIHN0YXRlZCB0aGF0ICJh dXRoZW50aWNhdG9yIiBpcyBzZW50DQo+Pj4+IGJhc2VkIG9uIGFuICJhdXRoZW50aWNhdG9yIHJl cXVlc3QiLiBJIHdvbmRlciBpZiB0aGF0IGNvdWxkIGJlIHN0YXRlZCBhbHJlYWR5DQo+Pj4+IGlu IHRoZSBiZWdpbm5pbmcgb2YgU2VjdGlvbiA0LCB0byBmdXJ0aGVyIGNsYXJpZnkgdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiB0aGVtLg0KPj4+PiBFLmcuLA0KPj4+Pg0KPj4+PiAiVGhlIGF1dGhlbnRp Y2F0b3IgaXMgYSBzdHJ1Y3R1cmVkIG1lc3NhZ2UsIHRyaWdnZXJlZCBieSBhbiBhdXRoZW50aWNh dG9yDQo+Pj4+IHJlcXVlc3QsIHRoYXQgY2FuIGJlIGV4cG9ydGVkIGZyb20gZWl0aGVyIHBhcnR5 IG9mIGEgVExTIGNvbm5lY3Rpb24uIg0KPj4+DQo+Pj4gVGhlIGlzc3VlIGlzIHRoYXQgc2VydmVy cyBjYW4gZ2VuZXJhdGUgc3BvbnRhbmVvdXMgZXhwb3J0ZWQgYXV0aGVudGljYXRvcnMgd2l0aG91 dA0KPj4+IGFuIGF1dGhlbnRpY2F0b3IgcmVxdWVzdC4NCj4+DQo+PiBXaGVyZSBpcyB0aGlzIHdy aXR0ZW4/IERpZCBJIG1pc3MgaXQ/DQo+DQo+IFNlY3Rpb24gNDoNCj4gICBBbiBhdXRoZW50aWNh dG9yIG1lc3NhZ2UgY2FuIGJlIGNvbnN0cnVjdGVkIGJ5IGVpdGhlciB0aGUgY2xpZW50IG9yDQo+ ICAgdGhlIHNlcnZlciBnaXZlbiBhbiBlc3RhYmxpc2hlZCBUTFMgY29ubmVjdGlvbiwgYSBjZXJ0 aWZpY2F0ZSwgYW5kIGENCj4gICBjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5LiAgQ2xpZW50cyBN VVNUIE5PVCBzZW5kIGFuIGF1dGhlbnRpY2F0b3INCj4gICB3aXRob3V0IGEgcHJlY2VkaW5nIGF1 dGhlbnRpY2F0b3IgcmVxdWVzdDsgZm9yIHNlcnZlcnMgYW4NCj4gICBhdXRoZW50aWNhdG9yIHJl cXVlc3QgaXMgb3B0aW9uYWwuICBGb3IgYXV0aGVudGljYXRvcnMgdGhhdCBkbyBub3QNCj4gICBj b3JyZXNwb25kIHRvIGF1dGhlbnRpY2F0b3IgcmVxdWVzdHMsIHRoZSBjZXJ0aWZpY2F0ZV9yZXF1 ZXN0X2NvbnRleHQNCj4gICBpcyBjaG9zZW4gYnkgdGhlIHNlcnZlci4NCg0KT2suIExvb2tzIGdv b2QuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg== --_000_7F09A9E2645545EB808A2951DCCA26ABericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <4CDBB776566BFD4E8635A0703FA77B53@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCAyLjBjbSA3MC44NXB0IDIuMGNtO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O1RoYW5rcyBhZ2FpbiBmb3IgeW91ciByZXZpZXch IFRoZSBQUiBpcyBvbiBHaXRodWIgKDwvc3Bhbj48YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZp cmVleWUuY29tL3VybD9rPTQ0ZTRjYjZjLTE4NmQxMTQwLTQ0ZTQ4YmY3LTBjYzQ3YWQ5M2RhMi1k Njc0YmQ0MWEwOTRkNGJiJmFtcDtxPTEmYW1wO3U9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJG dGxzd2clMkZ0bHMtZXhwb3J0ZWQtYXV0aGVudGljYXRvciUyRnB1bGwlMkY1MCI+PHNwYW4gbGFu Zz0iRU4tVVMiPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMtZXhwb3J0ZWQtYXV0aGVudGlj YXRvci9wdWxsLzUwPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1VUyI+KQ0KIGFuZCB3aWxsIGJl IGluY29ycG9yYXRlZCBpbnRvIGEgbmV3PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPnZlcnNpb24gb2YgdGhlIGRvY3VtZW50IHRoYXQgYWRkcmVzc2VzIGJvdGggeW91ciBjb21t ZW50cyBhbmQgdGhvc2UgYnkgWWFyb24gU2hlZmZlci48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TG9va3MgZ29vZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBTZXAgMTksIDIwMTkgYXQgMTE6MjkgUE0gQ2hyaXN0ZXIgSG9s bWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i PmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0K PGJyPg0KJmd0O1NvbWUgYW5zd2VycyB0byB5b3VyIHF1ZXN0aW9ucyBpbmxpbmUuIEknbSBub3Qg c3VyZSBmdXJ0aGVyIGNoYW5nZXMgYWxvbmcgdGhlIGxpbmVzIHN1Z2dlc3RlZCBoZXJlIGFyZSBu ZWVkZWQsIGJ1dCBJJ20gb3BlbiB0byBhcmd1bWVudHMgdGhhdCBwb2ludCBpbiB0aGF0IGRpcmVj dGlvbi48YnI+DQo8YnI+DQpJIGFtIG1vc3RseSBmaW5lIHdpdGggeW91ciBhbnN3ZXJzLiBKdXN0 IGEgY291cGxlIG9mIGNvbW1lbnRzIGlubGluZSBzdGlsbC48YnI+DQo8YnI+DQotLS08YnI+DQo8 YnI+DQpNSU5fMjo8YnI+DQo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IENhbiB0aGUgbWVjaGFuaXNt IGJlIHVzZWQgYWxzbyBmb3IgRFRMUz88YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgSSB0aGluayB0aGUgYW5zd2VyIGlzIHllcy4gSSBkb24ndCBzZWUgYW55IHJlYXNvbiB0byBk aXNhbGxvdyB0aGUgdXNlIG9mIEV4cG9ydGVkIEF1dGhlbnRpY2F0b3JzIGluIERUTFMuPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXb3VsZCBpdCBiZSB1c2VmdWwgdG8gY2xhcmlmeSB0aGF0 Pzxicj4NCiZndDsmbmJzcDs8YnI+DQomZ3Q7IEdvaW5nIHRocm91Z2ggd2hhdCB0aGUgbW9kaWZp ZWQgdGV4dCB3b3VsZCBsb29rIGxpa2UsIGl0IHNlZW1zIGxpa2UgYSBzdWJzdGFudGlhbCBhbW91 bnQgb2YgcmUtd3JpdGluZyAoZXZlbiB0aGUgdGl0bGUhKSBmb3Igd2hhdCBhbW91bnRzIHRvIGFu IHVuY2xlYXIgdXNlIGNhc2UuDQo8YnI+DQomZ3Q7IEtlZXBpbmcgaW4gbWluZCB0aGF0IERUTFMg MS4zIGhhc24ndCBiZWVuIGZpbmFsaXplZCBhbmQgZG9lc24ndCBkaXJlY3RseSBkZWZpbmUgZXhw b3J0ZXJzLCBJJ20gZGlzaW5jbGluZWQgdG8gZGVmaW5lIGhvdyBFQXMgd291bGQgd29yayB3aXRo IERUTFMuIElmIHNvbWVvbmUNCjxicj4NCiZndDsgaGFzIGEgc3Ryb25nIHVzZSBjYXNlIGZvciBF QSBpbiBEVExTLCBpdCBtYXkgYmUgd29ydGggY29uc2lkZXJpbmcgaXQuJm5ic3A7PGJyPg0KJm5i c3A7PGJyPg0KV291bGQgaXQgdGhlbiBiZSB1c2VmdWwgd2l0aCBhIHN0YXRlbWVudCBzYXlpbmcg dGhhdCBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byB1c2UgZXhwb3J0ZXJzIGFsc28gd2l0aCBEVExT LCBidXQgdGhhdCBzdWNoIHVzYWdlIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVu dCBhbmQgbmVlZHMgdG8gYmUgc3BlY2lmaWVkIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQ/PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFkZGVkIGEgbGluZSB0byB0aGlzIGVmZmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KLS0tPGJyPg0KPGJyPg0KTUlOXzM6PGJyPg0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBUaGUgZG9jdW1lbnRzIHRhbGsgYWJvdXQgYWRkaXRpb25hbCBjZXJ0aWZpY2F0ZXMuIElmIEkg b25seSBoYXZlIG9uZSBhZGRpdGlvbmFsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBjZXJ0aWZpY2F0 ZSwgY2FuIEkgdXNlIHRoYXQgZm9yIG11bHRpcGxlIGF1dGhlbnRpY2F0b3JzIHRocm91Z2hvdXQg dGhlIFRMUzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgc2Vzc2lvbj88YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgWWVzLCB0aGVyZSBpcyBub3RoaW5nIGRpc2FsbG93aW5nIHRoZSBj cmVhdGlvbiBvZiBtdWx0aXBsZSBleHBvcnRlZCBhdXRoZW50aWNhdG9ycyB3aXRoIHRoZSBzYW1l IGNlcnRpZmljYXRlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV291bGQgaXQgYmUgdXNl ZnVsIHRvIGNsYXJpZnkgdGhhdD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gbm90IGNvbnZpbmNl ZCB0aGlzIGlzIGEgcmVhbGlzdGljIHVzZSBjYXNlLiBTaW5jZSBleHBvcnRlZCBhdXRoZW50aWNh dG9ycyBhcmUgYmFzZWQgb24gdGhlIGV4cG9ydGVyLCB0aGVyZSBpcyBubyBpbmhlcmVudCBvcmRl cmluZy4NCjxicj4NCiZndDsgSWYgeW91IHJlLWF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBzYW1lIGNl cnRpZmljYXRlLCB0aGVyZSdzIG5vdGhpbmcgYXNzZXJ0aW5nIGZyZXNobmVzcyBvZiB0aGUgc2Vj b25kIGNlcnRpZmljYXRlLiBJcyB0aGVyZSBzb21ldGhpbmcgaW4NCjxicj4NCiZndDsgdGhlIHRl eHQgdGhhdCBzdWdnZXN0cyB0aGF0IHVzaW5nIGEgY2VydGlmaWNhdGUgbXVsdGlwbGUgdGltZXMg aXMgZGlzYWxsb3dlZD8gSWYgdGhlcmUncyBubyBzdWdnZXN0aW9uIHRoYXQgdGhpcyBpcyBub3Qg cG9zc2libGUgdGhhdA0KPGJyPg0KJmd0OyBuZWVkcyB0byBiZSBjb3JyZWN0ZWQsIEkgZG9uJ3Qg c2VlIHRoZSBiZW5lZml0IG9mIGNhbGxpbmcgb3V0IHRoaXMgc3BlY2lmaWMgdXNlIGNhc2UuPGJy Pg0KPGJyPg0KSSBkb24ndCB0aGluayB0aGVyZSBpcyBhbnkgdGV4dCBzdWdnZXN0aW5nIHRoYXQg aXQgaXMgZGlzYWxsb3dlZC4gQnV0LCBpZiB5b3UgZG9uJ3QgdGhpbmsgaXQgaXMgYSByZWFsaXN0 aWMgdXNlIGNhc2UgSSdsbCB0YWtlIHlvdXIgd29yZCBmb3IgaXQgOik8YnI+DQo8YnI+DQotLS08 YnI+DQo8YnI+DQpFRF8yOjxicj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgU2VjdGlvbiAzIHNh eXM6ICZxdW90O1RoZSBhdXRoZW50aWNhdG9yIHJlcXVlc3QgaXMgYSBzdHJ1Y3R1cmVkIG1lc3Nh Z2UgdGhhdCBjYW4gYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNyZWF0ZWQuLi4mcXVvdDsgU2Vj dGlvbiA0IHNheXM6ICZxdW90O1RoZSBhdXRoZW50aWNhdG9yIGlzIGEgc3RydWN0dXJlZCBtZXNz YWdlIHRoYXQgY2FuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBiZSBleHBvcnRlZC4uLiZxdW90Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEluIHRoZSAybmQgcGFy YWdyYXBoIG9mIFNlY3Rpb24gNCBpdCBpcyBzdGF0ZWQgdGhhdCAmcXVvdDthdXRoZW50aWNhdG9y JnF1b3Q7IGlzIHNlbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGJhc2VkIG9uIGFuICZxdW90O2F1 dGhlbnRpY2F0b3IgcmVxdWVzdCZxdW90Oy4gSSB3b25kZXIgaWYgdGhhdCBjb3VsZCBiZSBzdGF0 ZWQgYWxyZWFkeTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgaW4gdGhlIGJlZ2lubmluZyBvZiBTZWN0 aW9uIDQsIHRvIGZ1cnRoZXIgY2xhcmlmeSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZW0uPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBFLmcuLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7ICZxdW90O1RoZSBhdXRoZW50aWNhdG9yIGlzIGEgc3RydWN0dXJlZCBtZXNz YWdlLCB0cmlnZ2VyZWQgYnkgYW4gYXV0aGVudGljYXRvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg cmVxdWVzdCwgdGhhdCBjYW4gYmUgZXhwb3J0ZWQgZnJvbSBlaXRoZXIgcGFydHkgb2YgYSBUTFMg Y29ubmVjdGlvbi4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhl IGlzc3VlIGlzIHRoYXQgc2VydmVycyBjYW4gZ2VuZXJhdGUgc3BvbnRhbmVvdXMgZXhwb3J0ZWQg YXV0aGVudGljYXRvcnMgd2l0aG91dDxicj4NCiZndDsmZ3Q7Jmd0OyBhbiBhdXRoZW50aWNhdG9y IHJlcXVlc3QuIDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hlcmUgaXMgdGhpcyB3cml0 dGVuPyBEaWQgSSBtaXNzIGl0Pzxicj4NCiZndDs8YnI+DQomZ3Q7IFNlY3Rpb24gNDo8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwO0FuIGF1dGhlbnRpY2F0b3IgbWVzc2FnZSBjYW4gYmUgY29uc3RydWN0 ZWQgYnkgZWl0aGVyIHRoZSBjbGllbnQgb3I8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3RoZSBzZXJ2 ZXIgZ2l2ZW4gYW4gZXN0YWJsaXNoZWQgVExTIGNvbm5lY3Rpb24sIGEgY2VydGlmaWNhdGUsIGFu ZCBhPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5LiZuYnNw OyBDbGllbnRzIE1VU1QgTk9UIHNlbmQgYW4gYXV0aGVudGljYXRvcjxicj4NCiZndDsmbmJzcDsg Jm5ic3A7d2l0aG91dCBhIHByZWNlZGluZyBhdXRoZW50aWNhdG9yIHJlcXVlc3Q7IGZvciBzZXJ2 ZXJzIGFuPGJyPg0KJmd0OyZuYnNwOyAmbmJzcDthdXRoZW50aWNhdG9yIHJlcXVlc3QgaXMgb3B0 aW9uYWwuJm5ic3A7IEZvciBhdXRoZW50aWNhdG9ycyB0aGF0IGRvIG5vdDxicj4NCiZndDsmbmJz cDsgJm5ic3A7Y29ycmVzcG9uZCB0byBhdXRoZW50aWNhdG9yIHJlcXVlc3RzLCB0aGUgY2VydGlm aWNhdGVfcmVxdWVzdF9jb250ZXh0Jm5ic3A7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDtpcyBjaG9z ZW4gYnkgdGhlIHNlcnZlci48YnI+DQombmJzcDs8YnI+DQpPay4gTG9va3MgZ29vZC48YnI+DQo8 YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7F09A9E2645545EB808A2951DCCA26ABericssoncom_-- From nobody Fri Oct 11 00:38:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73C120125 for ; Fri, 11 Oct 2019 00:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 MJAGwSBwB6SJ for ; Fri, 11 Oct 2019 00:38:52 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00054.outbound.protection.outlook.com [40.107.0.54]) (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 DF3A2120123 for ; Fri, 11 Oct 2019 00:38:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b0d5ZPYrK+CN9uxtXA7eIdB/dbGr8fJRXNUhh7MW5Jn4jbB93u5SaRG2Cm174kGcVZDiXbhIGqm5k70HZ3omZ8TUM7rl+uJkgVGMqN9gwznAUO+DkQNP3WoHByiUsCHJ8gotzCMNrCtrm0IBnEXWQGDChywUlbGe8cWtQXNvNZ8+TCXb7mjR0HgKRZgF0osqNHsxF6nhh0exrxcJ3tYL5ciENSYjYqSKQ3SEq4ME1KpEadWgy6WqaNcc+npnMPo2nliEhZ8/lT0yE7r+Bo9OdP/xEXSpZz+9yuhrgP5hqEu8FDwbGs12iNfZYrxMhjR9sG3WnH5MBkVRhuWnGcxbIA== 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=Zgs4SKRHshqI0qWAm/RWN5HjjgZ21guyHDN3MRbYmAk=; b=T+iMPRU0mtKNjsWfFdsCbbFOwaMDsvfLnOkZwFzcvr9A51Tl71BkwZnVQeOh6oLKSLNcUiO7L/r3DwJun/JS+NbmEfJgDlaF+cKQ3SStHdu1yHC/pTfb+89O/YVyhGRDYwSf8Hnb/8cvHqVAYgoLqBjZrQ+ooXCuJmoggrU9QsaL0pH2IpEqPoFno7qN2lzhu6LgHomyxD/dW8pinzo3uCfogiJWuFW/IAJYCQ0AriJC1VNqnTgJfQy53OMJIQ2xEzf7r31Wq/s8IEwxJLYr2KmhOXU0+CSLJuf5hacojZ+d7EDh6UcpYL2IGmfs3FwUQ6shB2L52bjw4ENpilkRCw== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zgs4SKRHshqI0qWAm/RWN5HjjgZ21guyHDN3MRbYmAk=; b=HnI2C0j16FNtAea5yspYp/aCSw2RjGQvYoCbe4arC91lKu3ZZ1Q52fYHUMdhRAr1+i7FZf3BETeAiKYIQpw9MJG2sjOoAQKI0bAEhfKTAKE5npWrHTFKcg7arR1TIA+Wy1h7KaKC9c5HxvEBn6xHaR+CT3tZKJGeEBDwGi1+rE8= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3308.eurprd07.prod.outlook.com (10.170.246.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.10; Fri, 11 Oct 2019 07:38:49 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 07:38:49 +0000 From: John Mattsson To: Mohit Sethi M , Christian Huitema , Christopher Wood , Mohit Sethi M , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb7LOQnBEvPvDUirCjFHsuP0MadQ9FsAgAAizgCAAAS6gIAEF/wA Date: Fri, 11 Oct 2019 07:38:49 +0000 Message-ID: References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> <28313e8d-48d1-723e-9548-1e9fb3718491@ericsson.com> In-Reply-To: <28313e8d-48d1-723e-9548-1e9fb3718491@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 71da253a-d7fe-4040-61aa-08d74e1e0e6c x-ms-traffictypediagnostic: HE1PR07MB3308:|HE1PR07MB3308: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(189003)(199004)(66066001)(478600001)(25786009)(86362001)(606006)(966005)(14454004)(2501003)(71190400001)(8936002)(8676002)(81166006)(81156014)(7736002)(2906002)(790700001)(6116002)(71200400001)(3846002)(66946007)(66476007)(66556008)(64756008)(66446008)(14444005)(229853002)(36756003)(6246003)(6512007)(54896002)(6436002)(6306002)(236005)(33656002)(76116006)(99286004)(6486002)(58126008)(6506007)(53546011)(102836004)(110136005)(76176011)(5660300002)(256004)(91956017)(446003)(316002)(26005)(186003)(11346002)(44832011)(476003)(2616005)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3308; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: q7uE4F1d+44KRh8oZ9gX3NcXFCh4p33XQaSOwu3A8rfaLt8OsTWgQIhnF1xuXVV/Ok9r4h89mgSgXVoQtHRrD3emQ1aBazRrC+J2rVti02jjH0yeRKbsgwfYt4kCh4L3spmEf2FH0pQbeWL+3jyddSn9TS09Qy+jZhrytrJ+po6R6HyM2nzFT4qoJdoNExv4RZW4UyNAB0XStt5Cq5eCT8Pef1h/FSurBO952vuD5GnQ+1bK+3kn1LFEPFdfrT5A/JLqu3+KVKrC82cO+aH/I7dFelxOa1que9wyDWY9+tbvin3ZYDe4HQ/DI5HybWFtOJtm9TJQxPzzWpZJ7Cb/kJ655mKe6oZaJi7sgqI1a3TlwxA9INd3KBi24GHUNct6cdETiWG7R1oj+Dou3jBYhj9LlRYgpaHcO4JGB+C2WRINoQPxtj7uDcg6eaMqeWKTMocEDsRHp2rdQSuNZj6uKA== Content-Type: multipart/alternative; boundary="_000_C5ACF4AEE2C941B3BBF20122D35662DFericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 71da253a-d7fe-4040-61aa-08d74e1e0e6c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 07:38:49.2794 (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: EHtAxUCin/LV2TQsi/gPaDfyp22hGR4cwlA9lrVdtCh1mh8x5mj7+c9Xh2HJVXe8eXMX7Sy0qhn/3WDYJaCCBrhoCBT42tQpirFSrGw+qdg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3308 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 07:38:57 -0000 --_000_C5ACF4AEE2C941B3BBF20122D35662DFericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE1vaGl0LA0KDQoNCg0KUmUtcmVhZGluZyB0aGUgU2VsZmllIHBhcGVyIEkgc2VlIHRo YXQgdGhlIGF1dGhvcnMgZGVmaW5lIENsaWVudCBBbGljZSBhbmQgU2VydmVyIEFsaWNlIGFzIGRp ZmZlcmVudCBtZW1iZXJzIG9mIHRoZSBncm91cC4gVGhhdCBtYWtlcyB0aGluZ3MgY2xlYXJlci4g SSB0aGluayB0aGVyZSBhcmUgdGhyZWUgY2FzZXM6DQoNCg0KDQogIDEuICBVc2UgY2FzZXMgd2hl cmUgb25seSBDbGllbnQgQWxpY2UgYW5kIFNlcnZlciBCb2Igc2hhcmVzIHRoZSBQU0sgYXJlIG5v dCB2dWxuZXJhYmxlIHRvIHRoZSBTZWxmaWUgYXR0YWNrLg0KDQoNCg0KICAxLiAgQ2FzZXMgd2hl cmUgQWxpY2UsIEJvYiwgYW5kIENhZXNhciBzaGFyZSBhbiBleHRlcm5hbCBQU0sgc2VlbSBsaWtl IG1pc2NvbmZpZ3VyYXRpb24sIEkgYXNzdW1lIFRMUyAxLjMganVzdCBmb3Jnb3QgdG8gZXhwbGlj aXRseSBmb3JiaWQgdGhlbS4NCg0KDQoNCiAgMS4gIFRoZSBpbnRlcmVzdGluZyB1c2UgY2FzZSBp ZiB3aGVyZSBDbGllbnQgQWxpY2UsIFNlcnZlciBBbGljZSwgQ2xpZW50IEJvYiwgYW5kIFNlcnZl ciBCb2Igc2hhcmVzIGEgUFNLLiBUaGF0IGlzIGEgdmVyeSB2YWxpZCB1c2UgY2FzZSBhbmQgb25l IHRoYXQgaXMgY3VycmVudGx5IGRlcGxveWVkIGluIHNldmVyYWwgc3lzdGVtcy4NCg0KDQoNClRv IGRvIGFzIHRoZSBTZWxmaWUgYXV0aG9ycyBzdWdnZXN0IOKAnEEgUFNLIE1VU1QgTk9UIGJlIHNo YXJlZCBiZXR3ZWVuIG1vcmUgdGhhbiBvbmUgY2xpZW50IGFuZCBvbmUgc2VydmVy4oCdIHNlZW1z IHdheSB0b28gZHJhc3RpYyBhcyBpcyBmb3JiaWRzIDMgYWJvdmUuIEZvciAzIEkgdGhpbmsgdGhl IFNlbGZpZSBhdHRhY2sgY2FuIGJlIHZlcnkgZWFzaWx5IG1pdGlnYXRlZCBieSBmb3JjaW5nIGNs aWVudHMgdG8gY2hlY2sgaW5jb21pbmcgU2VydmVySGVsbG8ucmFuZG9tLg0KDQoNCg0KSSB0aGlu ayBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIHVwZGF0ZXMgZm9yIFJGQyA4NDQ2IHdvdWxk IGJlIGVub3VnaDoNCg0KDQoNCuKAnEEgUFNLIE1VU1QgTk9UIGJlIHNoYXJlZCBiZXR3ZWVuIG1v cmUgdGhhbiB0d28gZW5kcG9pbnRz4oCdDQoNCg0KDQrigJxBbiBlbmRwb2ludCByZWNlaXZpbmcg YSBDbGllbnRIZWxsbyB3aXRoIFBTSyBhdXRoZW50aWNhdGlvbiBNVVNUIGNoZWNrIHRoYXQgdGhl IENsaWVudEhlbGxvLnJhbmRvbSBpcyBub3QgZXF1YWwgdG8gYSBDbGllbnRIZWxsby5yYW5kb20g dGhhdCB0aGUgZW5kcG9pbnQgcHJldmlvdXNseSBzZW50IGFuZCBoYXMgbm90IHJlY2VpdmVkIGEg U2VydmVySGVsbG8u4oCdDQoNCg0KDQpDaGVlcnMsDQoNCkpvaG4NCg0KRnJvbTogVExTIDx0bHMt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0 aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBUdWVzZGF5LCA4IE9jdG9i ZXIgMjAxOSBhdCAyMTowOA0KVG86IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEu bmV0PiwgQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD4sIE1vaGl0IFNldGhp IE0gPG1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPiwgIlRMU0BpZXRmLm9yZyIgPHRsc0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBTZWxmaWUgYXR0YWNrDQoNCg0KSGkgQ2hyaXN0aWFu LA0KDQpJdCB3YXMgbXkgcG9vciBhdHRlbXB0IGF0IGV4cGxhaW5pbmcgdGhlIGF0dGFjay4gVGhl IGF0dGFjayBjYW4gaGFwcGVuIGFzIGxvbmcgYXMgYSBub2RlIHNlbmRzIG91dGJvdW5kIGNvbm5l Y3Rpb25zIChhcyBhIFRMUyBjbGllbnQpIGFuZCBhY2NlcHRzIGluYm91bmQgY29ubmVjdGlvbnMg KGFzIGEgVExTIHNlcnZlcikgd2l0aCB0aGUgc2FtZSBleHRlcm5hbCBQU0sgYW5kIGlkZW50aXR5 LiBUaGlzIGlzIGxpa2VseSB0byBoYXBwZW4gaW4gc29tZSBmb3JtIG9mIGdyb3VwIGNvbW11bmlj YXRpb24gYnV0IG5vdCBuZWNlc3NhcmlseS4NCg0KSW4gc3VjaCBhIHNjZW5hcmlvLCBhIG1hbGlj aW91cyBub2RlIEV2ZSBjYW4gZm9vbCBBbGljZSB0byBvcGVuIGEgY29ubmVjdGlvbiB0byBoZXJz ZWxmIChoZW5jZSB0aGUgbmFtZSBTZWxmaWUpLg0KDQpBZG1pdHRlZGx5LCBVS1MvbWlzYmluZGlu Zy9zZWxmaWUgYXJlIHNvbWV3aGF0IGhhcmQgdG8gY29tcHJlaGVuZCBzb21ldGltZXMgKGF0IGxl YXN0IGZvciBtZSkuDQoNCi0tTW9oaXQNCk9uIDEwLzgvMTkgOTo1MSBQTSwgQ2hyaXN0aWFuIEh1 aXRlbWEgd3JvdGU6DQoNCk9uIDEwLzgvMjAxOSA5OjQ2IEFNLCBDaHJpc3RvcGhlciBXb29kIHdy b3RlOg0KDQpPbiBUdWUsIE9jdCA4LCAyMDE5LCBhdCAyOjU1IEFNLCBNb2hpdCBTZXRoaSBNIHdy b3RlOg0KDQoNCg0KSGkgQ2hyaXMsDQoNCg0KDQpGb3IgdGhlIGJlbmVmaXQgb2YgdGhlIGxpc3Qs IGxldCBtZSBzdW1tYXJpemUgdGhhdCB0aGUgc2VsZmllIGF0dGFjayBpcw0KDQpvbmx5IHJlbGV2 YW50IHdoZXJlIG11bHRpcGxlIHBhcnRpZXMgc2hhcmUgdGhlIHNhbWUgUFNLIGFuZCB1c2UgdGhl DQoNCnNhbWUgUFNLIGZvciBvdXRnb2luZyBhbmQgaW5jb21pbmcgY29ubmVjdGlvbnMuIFRoZXNl IHNpdHVhdGlvbnMgYXJlDQoNCnJhdGhlciByYXJlLCBidXQgSSBhY2NlcHQgdGhhdCBUTFMgaXMg d2lkZWx5IHVzZWQgKGFuZCBzb21ldGltZXMNCg0KbWlzdXNlZCkgaW4gbWFueSBwbGFjZXMuDQoN Cg0KDQpJIG1heSBiZSBnZXR0aW5nIG9sZCBidXQgdGhlIHdheSBNb2hpdCB3cml0ZXMgaXQsIGl0 IHNlZW1zIHRoYXQgdGhlIGF0dGFjayBoYXBwZW5zIHdoZW4gdGhlIHNlY3VyaXR5IG9mIGEgZ3Jv dXAgcmVsaWVzIG9uIGEgc2VjcmV0IHNoYXJlZCBieSBhbGwgbWVtYmVycyBvZiB0aGUgZ3JvdXAs IGFuZCBjYW4gdGhlbiBiZSBjb21wcm9taXNlZCB3aGVuIG9uZSBvZiB0aGUgZ3JvdXAgbWVtYmVy cyBtaXNiZWhhdmVzLiBIb3cgaXMgdGhhdCBhIG5ldyB0aHJlYXQ/IElmIGdyb3VwcyBhcmUgZGVm aW5lZCBieSBhIHNoYXJlZCBzZWNyZXQsIHRoZW4gY29ycnVwdGlvbiBvZiBhIGdyb3VwIG1lbWJl ciByZXZlYWxzIHRoYXQgc2hhcmVkIHNlY3JldCB0byB0aGUgYXR0YWNrZXIgYW5kIG9wZW4gdGhl IHBhdGggZm9yIGFsbCBraW5kcyBvZiBleHBsb2l0YXRpb24uIEluIHdoYXQgc2Vuc2UgaXMgdGhl ICJzZWxmaWUiIGF0dGFjayBkaWZmZXJlbnQgZnJvbSB0aGF0IGdlbmVyaWMgdGhyZWF0Pw0KDQot LSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCg0KVExTIG1haWxpbmcgbGlzdA0KDQpUTFNAaWV0Zi5vcmc8bWFp bHRvOlRMU0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHMNCg== --_000_C5ACF4AEE2C941B3BBF20122D35662DFericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5I VE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFBy ZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjE1ODYxMDc1NjI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi02OTk3NzExOTggMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3 IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1Nzk7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTk4ODc4MjcwNDsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA1NDM0ODg4NCAx MzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3 OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tR0IiPlRoYW5rcyBNb2hpdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPlJlLXJlYWRp bmcgdGhlIFNlbGZpZSBwYXBlciBJIHNlZSB0aGF0IHRoZSBhdXRob3JzIGRlZmluZSBDbGllbnQg QWxpY2UgYW5kIFNlcnZlciBBbGljZSBhcyBkaWZmZXJlbnQgbWVtYmVycyBvZiB0aGUgZ3JvdXAu IFRoYXQgbWFrZXMgdGhpbmdzIGNsZWFyZXIuIEkgdGhpbmsgdGhlcmUgYXJlIHRocmVlIGNhc2Vz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdp bi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJFTi1HQiI+VXNlIGNh c2VzIHdoZXJlIG9ubHkgQ2xpZW50IEFsaWNlIGFuZCBTZXJ2ZXIgQm9iIHNoYXJlcyB0aGUgUFNL IGFyZSBub3QgdnVsbmVyYWJsZSB0byB0aGUgU2VsZmllIGF0dGFjay48bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIg c3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28t bGlzdDpsMSBsZXZlbDEgbGZvMiI+PHNwYW4gbGFuZz0iRU4tR0IiPkNhc2VzIHdoZXJlIEFsaWNl LCBCb2IsIGFuZCBDYWVzYXIgc2hhcmUgYW4gZXh0ZXJuYWwgUFNLIHNlZW0gbGlrZSBtaXNjb25m aWd1cmF0aW9uLCBJIGFzc3VtZSBUTFMgMS4zIGp1c3QgZm9yZ290IHRvIGV4cGxpY2l0bHkgZm9y YmlkIHRoZW0uPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxv bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIzIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjxzcGFuIGxhbmc9 IkVOLUdCIj5UaGUgaW50ZXJlc3RpbmcgdXNlIGNhc2UgaWYgd2hlcmUgQ2xpZW50IEFsaWNlLCBT ZXJ2ZXIgQWxpY2UsIENsaWVudCBCb2IsIGFuZCBTZXJ2ZXIgQm9iIHNoYXJlcyBhIFBTSy4gVGhh dCBpcyBhIHZlcnkgdmFsaWQgdXNlIGNhc2UgYW5kIG9uZSB0aGF0IGlzIGN1cnJlbnRseSBkZXBs b3llZCBpbiBzZXZlcmFsIHN5c3RlbXMuPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj5U byBkbyBhcyB0aGUgU2VsZmllIGF1dGhvcnMgc3VnZ2VzdCDigJxBIFBTSyBNVVNUIE5PVCBiZSBz aGFyZWQgYmV0d2VlbiBtb3JlIHRoYW4gb25lIGNsaWVudCBhbmQgb25lIHNlcnZlcuKAnSBzZWVt cyB3YXkgdG9vIGRyYXN0aWMgYXMgaXMgZm9yYmlkcyAzIGFib3ZlLiBGb3IgMyBJIHRoaW5rIHRo ZSBTZWxmaWUgYXR0YWNrIGNhbiBiZSB2ZXJ5IGVhc2lseSBtaXRpZ2F0ZWQgYnkNCiBmb3JjaW5n IGNsaWVudHMgdG8gY2hlY2sgaW5jb21pbmcgU2VydmVySGVsbG8ucmFuZG9tLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1HQiI+SSB0aGluayBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nIHVwZGF0 ZXMgZm9yIFJGQyA4NDQ2IHdvdWxkIGJlIGVub3VnaDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCcQSBQU0sgTVVT VCBOT1QgYmUgc2hhcmVkIGJldHdlZW4gbW9yZSB0aGFuIHR3byBlbmRwb2ludHPigJ08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7igJxBbiBl bmRwb2ludCByZWNlaXZpbmcgYSBDbGllbnRIZWxsbyB3aXRoIFBTSyBhdXRoZW50aWNhdGlvbiBN VVNUIGNoZWNrIHRoYXQgdGhlIENsaWVudEhlbGxvLnJhbmRvbSBpcyBub3QgZXF1YWwgdG8gYSBD bGllbnRIZWxsby5yYW5kb20gdGhhdCB0aGUgZW5kcG9pbnQgcHJldmlvdXNseSBzZW50IGFuZCBo YXMgbm90DQogcmVjZWl2ZWQgYSBTZXJ2ZXJIZWxsby7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t R0IiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1HQiI+Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VExTICZs dDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIE1vaGl0IFNldGhpIE0gJmx0 O21vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ RGF0ZTogPC9iPlR1ZXNkYXksIDggT2N0b2JlciAyMDE5IGF0IDIxOjA4PGJyPg0KPGI+VG86IDwv Yj5DaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDssIENocmlzdG9w aGVyIFdvb2QgJmx0O2Nhd0BoZWFwaW5nYml0cy5uZXQmZ3Q7LCBNb2hpdCBTZXRoaSBNICZsdDtt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSZndDssICZxdW90O1RMU0BpZXRmLm9yZyZxdW90OyAm bHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1RMU10gU2VsZmll IGF0dGFjazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5IaSBDaHJpc3RpYW4sPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JdCB3YXMgbXkgcG9v ciBhdHRlbXB0IGF0IGV4cGxhaW5pbmcgdGhlIGF0dGFjay4gVGhlIGF0dGFjayBjYW4gaGFwcGVu IGFzIGxvbmcgYXMgYSBub2RlIHNlbmRzIG91dGJvdW5kIGNvbm5lY3Rpb25zIChhcyBhIFRMUyBj bGllbnQpIGFuZCBhY2NlcHRzIGluYm91bmQgY29ubmVjdGlvbnMgKGFzIGEgVExTIHNlcnZlcikg d2l0aCB0aGUgc2FtZSBleHRlcm5hbCBQU0sgYW5kIGlkZW50aXR5LiBUaGlzDQogaXMgbGlrZWx5 IHRvIGhhcHBlbiBpbiBzb21lIGZvcm0gb2YgZ3JvdXAgY29tbXVuaWNhdGlvbiBidXQgbm90IG5l Y2Vzc2FyaWx5LiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+SW4gc3VjaCBhIHNjZW5hcmlvLCBhIG1hbGljaW91cyBub2RlIEV2ZSBjYW4gZm9vbCBBbGlj ZSB0byBvcGVuIGEgY29ubmVjdGlvbiB0byBoZXJzZWxmIChoZW5jZSB0aGUgbmFtZSBTZWxmaWUp LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWRtaXR0ZWRs eSwgVUtTL21pc2JpbmRpbmcvc2VsZmllIGFyZSBzb21ld2hhdCBoYXJkIHRvIGNvbXByZWhlbmQg c29tZXRpbWVzIChhdCBsZWFzdCBmb3IgbWUpLg0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij4tLU1vaGl0PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTAvOC8xOSA5OjUx IFBNLCBDaHJpc3RpYW4gSHVpdGVtYSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAxMC84LzIwMTkgOTo0NiBBTSwgQ2hyaXN0 b3BoZXIgV29vZCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij5PbiBUdWUsIE9jdCA4LCAyMDE5LCBhdCAyOjU1IEFNLCBNb2hpdCBTZXRoaSBN IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ SGkgQ2hyaXMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Rm9yIHRoZSBiZW5lZml0IG9mIHRoZSBsaXN0LCBsZXQgbWUgc3VtbWFyaXpl IHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+b25s eSByZWxldmFudCB3aGVyZSBtdWx0aXBsZSBwYXJ0aWVzIHNoYXJlIHRoZSBzYW1lIFBTSyBhbmQg dXNlIHRoZSA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zYW1lIFBTSyBmb3Igb3V0Z29pbmcg YW5kIGluY29taW5nIGNvbm5lY3Rpb25zLiBUaGVzZSBzaXR1YXRpb25zIGFyZSA8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5yYXRoZXIgcmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExTIGlzIHdp ZGVseSB1c2VkIChhbmQgc29tZXRpbWVzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPm1pc3Vz ZWQpIGluIG1hbnkgcGxhY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JIG1heSBiZSBnZXR0 aW5nIG9sZCBidXQgdGhlIHdheSBNb2hpdCB3cml0ZXMgaXQsIGl0IHNlZW1zIHRoYXQgdGhlIGF0 dGFjayBoYXBwZW5zIHdoZW4gdGhlIHNlY3VyaXR5IG9mIGEgZ3JvdXAgcmVsaWVzIG9uIGEgc2Vj cmV0IHNoYXJlZCBieSBhbGwgbWVtYmVycyBvZiB0aGUgZ3JvdXAsIGFuZCBjYW4gdGhlbiBiZSBj b21wcm9taXNlZCB3aGVuIG9uZSBvZiB0aGUgZ3JvdXAgbWVtYmVycyBtaXNiZWhhdmVzLg0KIEhv dyBpcyB0aGF0IGEgbmV3IHRocmVhdD8gSWYgZ3JvdXBzIGFyZSBkZWZpbmVkIGJ5IGEgc2hhcmVk IHNlY3JldCwgdGhlbiBjb3JydXB0aW9uIG9mIGEgZ3JvdXAgbWVtYmVyIHJldmVhbHMgdGhhdCBz aGFyZWQgc2VjcmV0IHRvIHRoZSBhdHRhY2tlciBhbmQgb3BlbiB0aGUgcGF0aCBmb3IgYWxsIGtp bmRzIG9mIGV4cGxvaXRhdGlvbi4gSW4gd2hhdCBzZW5zZSBpcyB0aGUgJnF1b3Q7c2VsZmllJnF1 b3Q7IGF0dGFjayBkaWZmZXJlbnQgZnJvbSB0aGF0IGdlbmVyaWMNCiB0aHJlYXQ/PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4tLSBDaHJpc3RpYW4gSHVpdGVt YTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VExT IG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C5ACF4AEE2C941B3BBF20122D35662DFericssoncom_-- From nobody Fri Oct 11 01:55:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0396C120020 for ; Fri, 11 Oct 2019 01:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=NOvb+Kmz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G6MdHIYr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m_ubxEaH7x92 for ; Fri, 11 Oct 2019 01:55:30 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8A44120044 for ; Fri, 11 Oct 2019 01:55:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2B3C03A4 for ; Fri, 11 Oct 2019 04:55:30 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Fri, 11 Oct 2019 04:55: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=fm3; bh=mpawr0eF/pVTGfBuCzn2GhRvMuUCyaM 0VVu7YAa14ZU=; b=NOvb+KmzEXHoG6PypqZMTYPfy9wwgMho9pOSUVlKZYTk/OI On2G7wGqrmVwYX1wPNneQW1u7kmQXIXHM0z7jPnMQMZvEqdjZMcDvG3+wR446uAP KgupKrDj5E86X5HOp7Opvo0nZ9VHPjeRvCFNHoxOIjpkfMvhUIpJ1Fi/ZkE5cLKI c9p8x0txujSangEVYfPvvUJV9w4ep5mEkpE5XqDGiU+oZgNXPwp37gkffFKVyOfX yqALtAY2Qmga/zYPPeCZg5LZeD7SWQbKFL7hay1xvXZ06mI6lTp6puaI1nkeMtBg SkwGrkiindv40MdYEVoYR1Mp7jMU0BlAsYsXGDg== 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=fm1; bh=mpawr0 eF/pVTGfBuCzn2GhRvMuUCyaM0VVu7YAa14ZU=; b=G6MdHIYroq3iIJzhoxDGt2 Z4A+Aosvo3mSbj+kKv2b8Qvm1s84UEH76qs42pwWXpL2cU8tcu0O8UU3ml9bqrI8 i32QAeDINGZbyxU75OhD2Z/752VtjJnNoBGczzc1BRW8J/7Uxvm5iraJl1Ftzwmi 3A08APmtNsnAqYOH88LaU5/8/EHRrx1SfbByOe9N6y5LukRudIEaB6j5XO6aI3th XI5Gp2FHOeYGw5GWzIKfN0eRF9TJf9ICgmcNdmyfVeABPmIdwcSlr5rYJT7shmY8 gJWp9raW0Ond+MiR4T8/JHC23fmZ2iI7zNCxYgbJ02XiUMu7P7l/yR1UoJ6Bpucw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieehgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 35FE2E00A5; Fri, 11 Oct 2019 04:55:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <0c195775-2039-4239-9a4c-66d5c650e9ae@www.fastmail.com> In-Reply-To: <5816BBD1-14EE-4B72-AEC4-AC7D576C4823@dukhovni.org> References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8c2b10b3-bfc2-44b0-997a-1cab0789f1b7@www.fastmail.com> <2781261d-bfa2-4c40-9ca4-6a3a1c9266df@www.fastmail.com> <5816BBD1-14EE-4B72-AEC4-AC7D576C4823@dukhovni.org> Date: Fri, 11 Oct 2019 19:55:10 +1100 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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, 11 Oct 2019 08:55:32 -0000 On Fri, Oct 11, 2019, at 14:07, Viktor Dukhovni wrote: > * The client has a what it believes to be a valid ticket > and is willing to re-use it, and would prefer to avoid > the cost of replacing it on each resumption. > > * The server is happy to allow re-use of still valid > tickets by clients, but needs to know whether the > client wants a new ticket (because it never re-uses). > > * The server would like to vend a new ticket only when the > old one needs to be refreshed (ticket lifetime or STEK > rotation). > > In the context of the draft as-is, such a client and server > have a time arriving at a mutually compatible configuration. Yeah, I agree that this is a little thorny. However, the client asking for one extra and the server vending one more is a relatively small extra expense AND we discourage reuse in the general case. So, at least from my perspective, this isn't that serious a problem and shouldn't block publication. I'm not especially happy with the idea of having 1 mean "maybe 1". Having 1 mean 1 is far less dangerous. I think that I would prefer to go for an application- or configuration-level signal for this, if it is an important use case to consider. It's not like it is impossible to have an client say "I really need a ticket" at the application layer, and the server to receive that and call `tls.send_ticket()` (that's a function that NSS provides, for instance). From nobody Fri Oct 11 05:12:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01447120071 for ; Fri, 11 Oct 2019 05:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 A0-VgJy0D6Gd for ; Fri, 11 Oct 2019 05:12:14 -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 BC612120019 for ; Fri, 11 Oct 2019 05:12:14 -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 x9BCCD8g028952; Fri, 11 Oct 2019 13:12: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 : mime-version; s=jan2016.eng; bh=L0vsuOEzzI3kmIobIpKK/bbxp+WEs4gtXRgVgGb8nCk=; b=ijXnEoYsfpG3Rk2btMMIPzntorF8Z58MbtT7n4IN+6UmXX+wH09gRYLXqAfRekMfpxuC JtX0JiIYsJNfm8tQX74sS0+NWcM+J0bUMZdYghgWVxMbBfN1GtHPwENtf5bv0CKaj2/+ +NQcLkpq9xs6iANOsrxIyPeYCIew+fDx4vWdiHKIt7In0V5uQjBY0u9ffrpd9CmmsvDw P8DNsmwSQocCpi7ejAarB/pFo0jO3zO7aIxU7fvd/sDMF2apSb+Gxd4phZtsCfohQlve weAFFUs8BrSFgrN2EAmyDKmetzCHJG2bCOHF4y4Gecp/qlCWDWyDiHQOe6aMBFjbTye8 9A== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2veje9rjw6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 13:12:13 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9BC2BZ6010651; Fri, 11 Oct 2019 08:12:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint3.akamai.com with ESMTP id 2veph1829t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 08:12:10 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Oct 2019 07:12:03 -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.1473.005; Fri, 11 Oct 2019 07:12:03 -0500 From: "Salz, Rich" To: Rob Sayre CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVf+GsnWryPMhc506+pN76L/UXB6dU2M8AgABI9gCAAEloAA== Date: Fri, 11 Oct 2019 12:12:03 +0000 Message-ID: <8DE5E2AB-5737-4B82-A4D6-ED1B20D33FE2@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.141] Content-Type: multipart/alternative; boundary="_000_8DE5E2AB57374B82A4D6ED1B20D33FE2akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-11_08:, , 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=974 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910110115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-11_08:2019-10-10,2019-10-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=959 suspectscore=0 clxscore=1015 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 impostorscore=0 bulkscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910110117 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 12:12:16 -0000 --_000_8DE5E2AB57374B82A4D6ED1B20D33FE2akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pklzbid0IHRoYXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIHNlbmRpbmcgdGhlIFNOSSBpbiB0aGUg c2Vjb25kIGNsaWVudCBtZXNzYWdlLCB0aG91Z2g/DQoNClRoZSBzZXJ2ZXIgbmVlZHMgdG8ga25v dyB3aGljaCBjZXJ0IHRvIHVzZSBhZnRlciBpdCByZWNlaXZlcyB0aGUgKmZpcnN0KiBjbGllbnQg bWVzc2FnZS4NCg0KDQogICogICBJZiB0aGUgQ0ROIC0tLT4gT3JpZ2luIHRyYWZmaWMgaXMgSVB2 NiwgdGhlcmUncyBubyBuZWVkIHRvIHNlcnZlIG11bHRpcGxlIGNlcnRzIGZyb20gb25lIElQIGFk ZHJlc3MuDQoNCkN1c3RvbWVycyBkb27igJl0IHdhbnQgdG8gYmUgbGltaXRlZCB0byB0aGF0LCBm b3IgcmVhc29ucyBJ4oCZdmUgdHJpZWQgdG8gZXhwbGFpbiBiZWZvcmUuDQoNCg== --_000_8DE5E2AB57374B82A4D6ED1B20D33FE2akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NDIzMzQyNTk7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE2MzA2NTkzNCAxNzk0OTE2MTYgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8L3NwYW4+PC9iPklzbid0IHRo YXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIHNlbmRpbmcgdGhlIFNOSSBpbiB0aGUgc2Vjb25kIGNs aWVudCBtZXNzYWdlLCB0aG91Z2g/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48YnI+DQpUaGUgc2VydmVyIG5lZWRzIHRvIGtub3cgd2hpY2ggY2VydCB0byB1 c2UgYWZ0ZXIgaXQgcmVjZWl2ZXMgdGhlICo8Yj5maXJzdDwvYj4qIGNsaWVudCBtZXNzYWdlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SWYgdGhlIENETiAtLS0mZ3Q7IE9y aWdpbiB0cmFmZmljIGlzIElQdjYsIHRoZXJlJ3Mgbm8gbmVlZCB0byBzZXJ2ZSBtdWx0aXBsZSBj ZXJ0cyBmcm9tIG9uZSBJUCBhZGRyZXNzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DdXN0b21lcnMgZG9u4oCZdCB3YW50IHRvIGJlIGxpbWl0ZWQgdG8gdGhh dCwgZm9yIHJlYXNvbnMgSeKAmXZlIHRyaWVkIHRvIGV4cGxhaW4gYmVmb3JlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8DE5E2AB57374B82A4D6ED1B20D33FE2akamaicom_-- From nobody Fri Oct 11 05:32:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC5C120071 for ; Fri, 11 Oct 2019 05:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 vOFsofBbrw-M for ; Fri, 11 Oct 2019 05:32:15 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140052.outbound.protection.outlook.com [40.107.14.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01F9120019 for ; Fri, 11 Oct 2019 05:32:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eALx5xr7JJNv03Q9+YRVuhDozvo43i2Tarm8rZodjic+HV4tLWWBJV8Eb2ICpZJkR2v7ZJk1Hc6wMxJTrCdPgH10JqcBsuJgNx3Vjm29g1RvzCBJZVseQizzrV9Xtydd2lkoEk5BU6zYSckFfUIgqrVYiEQBG2VaIdWuCnKw9cSj18MPKWuXu2ewqfIV/J591lkE6g0RHIgRN89v5AVU8ZcKFS7buEdPkJ858gqkxl2J5jYYaT11VTnzjxZRjslGgrKdCVVtnltvIDMIVAYub+FvgCAaxj60GoKjnZWvGjDBmtMhERrGb5cgiOxS9RCVolOmVCSY0zXmarORJVNBCA== 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=AO8DmtiKhGDUvaJI6Pby+cP3rfh0xJtJNzjz9hYG/bk=; b=i1QlZEwbt5ZkvmOYmlXs0v7GXKMsb/m29mA//sZAXna0HhwCJEwMg5ML4/4xrEEk0usQC07Lrsh28+3Egwzl62rKdk/rag4k9uo9Vdm4MeO0Sq6LfGtmF014aqnV9uz8FYjKbZAb1v3nJ2YwTCWwO8ssn6c042BM+3ugdxR7Qezi6obpsEg75OkL1CgMMTl0zezB5xf4ZkLJMq2cK2Z45jKCTeR721NfcFXIf0jU9Zk0aNScp00LwczOOreV1KCK8vBJ/I4pMH1AAsUKGc1JK7Rbf5ZJsVXNYipvmPe6hRNpDAvt5+rrDEFz5VWjJVqHzLWuNcHpcpspF1cmeD0CIA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AO8DmtiKhGDUvaJI6Pby+cP3rfh0xJtJNzjz9hYG/bk=; b=OOvsVoylRy3d4WnNM3cvqLBll+U/jqNXP74RvvPgs7Q4FFI517TbwRNIttw4DrzgvdaS4hwyJjhJPPV2WhMwp3AUQEDJv0qtqmUc4Qa9q4k9sfayKyLxC2AmLOgNImuYIDxHnPFE1lZUtaVGjSz4OesjJrspXjgqeDLb82qh9xY= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2892.eurprd07.prod.outlook.com (10.168.94.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Fri, 11 Oct 2019 12:32:11 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f%6]) with mapi id 15.20.2347.016; Fri, 11 Oct 2019 12:32:11 +0000 From: Mohit Sethi M To: Christopher Wood , Mohit Sethi M , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb6JZ9ydCGu6h0WNgLEAne6JU6dQ9FwAgARv9AA= Date: Fri, 11 Oct 2019 12:32:11 +0000 Message-ID: <16d43a2e-7995-5036-5a67-649b360be497@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> In-Reply-To: <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.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:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [82.203.244.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e6b4998-5ada-49de-69ea-08d74e470a20 x-ms-traffictypediagnostic: HE1PR0701MB2892:|HE1PR0701MB2892: x-ms-exchange-purlcount: 8 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(396003)(346002)(13464003)(53754006)(199004)(189003)(186003)(71190400001)(76116006)(6306002)(6246003)(66946007)(66476007)(66446008)(66556008)(64756008)(110136005)(6512007)(478600001)(71200400001)(6506007)(2501003)(53546011)(14454004)(966005)(99286004)(102836004)(76176011)(26005)(6486002)(316002)(8676002)(31686004)(6436002)(58126008)(5660300002)(86362001)(7736002)(305945005)(6116002)(31696002)(81166006)(8936002)(14444005)(256004)(2906002)(3846002)(11346002)(446003)(2616005)(476003)(25786009)(486006)(229853002)(65806001)(65956001)(36756003)(66066001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2892; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: maoDwIAAF7lsaQZnsHMhnDQkMjb60lA7HwuXM2zkqzQiPa71RmeXY1MmS/IDObUGdnCyf4lE/0cqNIvGKSqo/Jg67OzuQz7qIlo0yg/fVIzMqPNLvkMNiRN0VyB+AmX7e8KC6RI6fZcBtUHYuHfUvC6IwVnyt0vrncFf1NOpTcnOc7bP6caaLfHbN8gwx5vGRVUxsK8fWlQ4WAU7bIIu+k6odc6nsA/thPkRvFUWzBlNZE70JoykHVQpwfClUGwrC0Madue+nmsLF6w7r7OTWEtxkxrOO+2yCEUjUZ5t8FAt3DxD0q47DrWSKKclVO8lCayA1oMsB47CuiHVpG4AVOmcoQh1pCG+0V6RFVaTh42K+ZeGtIc/wHYnr87ACHuPy6D4jxwkNa+7QCiv6fReSpRUeaITdr/e9UjxxYtnoXHz9R4L9MKx8LjmioJNrfnQRt/a5ILzB+KsCnIFI1vP4Q== Content-Type: text/plain; charset="utf-8" Content-ID: <87A34D79F4450941972BA23A99FF36F3@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e6b4998-5ada-49de-69ea-08d74e470a20 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 12:32:11.4805 (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: 7TngwAG+PZqPB7Bny1+ev1xLiLAPV4QBTMYhw7D/DhSNBbzr4ne9glZJlrTjbFnKXm1eIpwSZUxRgQEhd9xlRzToFuWf7L0DQkpNrTaTfAQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2892 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 12:32:18 -0000 SGksDQoNCkkgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCBmb3IgdGhlIGRyYWZ0IHRvIGltcHJvdmUg dGhlIHNlY3Rpb24gb24gDQphZGRyZXNzaW5nIHNlbGZpZSBhdHRhY2tzLiBGb3IgdGhlIGJlbmVm aXQgb2YgdGhlIGxpc3QsIGhlcmUgaXMgdGhlIA0KcHJvcG9zZWQgdGV4dDoNCg0KPiBUaGUgVExT IGV4dGVybmFsIFBTSyBhdXRoZW50aWNhdGlvbiBtYWtlcyB0aGUgaW1wbGljaXQgYXNzdW1wdGlv biB0aGF0IA0KPiBlYWNoIFBTSyBpcyBrbm93biBvbmx5IHRvIG9uZSBjbGllbnQgYW5kIG9uZSBz ZXJ2ZXIsIHdoaWNoIGRvIG5vdCANCj4gc3dpdGNoIHJvbGVzIHdpdGggdGhlIHNhbWUgUFNLLg0K Pg0KPiBJZiBtdWx0aXBsZSBjbGllbnRzIG9yIG11bHRpcGxlIHNlcnZlcnMgc2hhcmUgYSBQU0ss IFRMUyBvbmx5IA0KPiBhdXRoZW50aWNhdGVzIHRoZSBlbnRpcmUgZ3JvdXAuIE5vdCBvbmx5IGNh biBhIGNvbXByb21pc2VkIGdyb3VwIA0KPiBtZW1iZXIgaW1wZXJzb25hdGUgYW5vdGhlciBncm91 cCBtZW1iZXIsIGJ1dCBhIG1hbGljaW91cyBub24tbWVtYmVyIA0KPiBjYW4gcmVyb3V0ZSBoYW5k c2hha2VzIGJldHdlZW4gaG9uZXN0IGdyb3VwIG1lbWJlcnMgdG8gY29ubmVjdCB0aGVtIGluIA0K PiB1bmludGVuZGVkIHdheXMuIFRoaXMgcmVyb3V0aW5nIGlzIGEgdHlwZSBvZiBpZGVudGl0eSBt aXNiaW5kaW5nIA0KPiBhdHRhY2sgW0tyYXdjenlrXVtTZXRoaV0uDQo+DQo+IFNlbGZpZSBhdHRh Y2sgW1NlbGZpZV0gaXMgYSBzcGVjaWFsIGNhc2Ugb2YgdGhlIHJlcm91dGluZyBhdHRhY2sgDQo+ IGFnYWluc3QgYSBncm91cCBtZW1iZXIgdGhhdCBjYW4gYWN0IGJvdGggYXMgVExTIHNlcnZlciBh bmQgY2xpZW50LiBJbiANCj4gdGhlIHNlbGZpZSBhdHRhY2ssIGEgbWFsaWNpb3VzIG5vbi1tZW1i ZXIgcmVyb3V0ZXMgYSBjb25uZWN0aW9uIGZyb20gDQo+IHRoZSBjbGllbnQgdG8gdGhlIHNlcnZl ciBvbiB0aGUgc2FtZSBlbmRwb2ludC4NCj4NCj4gUmVyb3V0aW5nIGFuZCBzZWxmaWUgYXR0YWNr cyBjYW4gYmUgZGV0ZWN0ZWQgYnkgYmluZGluZyB0aGUgVExTIA0KPiBoYW5kc2hha2UgdG8gZ2xv YmFsbHkgdW5pcXVlIG5vZGUgaWRlbnRpZmllcnMgdXNpbmcgdGhlIGZvbGxvd2luZyANCj4gY29u dGV4dCBzdHJpbmc6DQo+DQo+IHN0cnVjdCB7DQo+IMKgwqDCoMKgwqDCoCBvcGFxdWUgY2xpZW50 X2lkPDAuLjJeMTYtMT47DQo+IMKgwqDCoMKgwqDCoCBvcGFxdWUgc2VydmVyX2lkPDAuLjJeMTYt MT47DQo+IMKgwqDCoMKgIH0gQ29udGV4dDsNCj4NCj4gV2hlbiB0aGUgUFNLIGlzIHNoYXJlZCBi eSBvbmx5IHR3byBlbmRwb2ludHMsIGl0IGlzIG5vdCBuZWNlc3NhcnkgdG8gDQo+IGtub3cgdGhl IGlkZW50aWZpZXIocykgb2YgdGhlIG90aGVyIGVuZHBvaW50LiBJbnN0ZWFkLCBpdCBpcyANCj4g c3VmZmljaWVudCB0byBjaGVjayB0aGF0IHRoZSBpZGVudGlmaWVyIG9mIHRoZSBvdGhlciBlbmRw b2ludCBpbiANCj4gY29udGV4dCBpcyBub3QgZXF1YWwgdG8gYW55IG9mIG9uZeKAmXMgb3duIGlk ZW50aWZpZXJzLiBUbyBzaW1wbGlmeSANCj4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBjaGVjaywg aXQgaXMgUkVDT01NRU5ERUQgdGhhdCBlYWNoIGVuZHBvaW50IA0KPiBzZWxlY3RzIG9uZSBnbG9i YWxseSB1bmlxdWUgaWRlbnRpZmllciBhbmQgdXNlcyBpdCBpbiBhbGwgUFNLIA0KPiBoYW5kc2hh a2VzLiBUaGUgdW5pcXVlIGlkZW50aWZpZXIgY2FuLCBmb3IgZXhhbXBsZSwgYmUgb25lIG9mIGl0 cyBNQUMgDQo+IGFkZHJlc3NlcyBvciBhIDMyLWJ5dGUgcmFuZG9tIG51bWJlci4NCj4NCj4gV2hl biB0aGUgUFNLIGlzIGEgZ3JvdXAga2V5LCB0aGUgY29tcGFyaXNvbiB3aXRoIG9uZeKAmXMgb3du IGlkZW50aWZpZXJzIA0KPiB3aWxsIG9ubHkgcHJldmVudCBzZWxmaWUgYXR0YWNrcyBidXQgbm90 IG1hbGljaW91cyByZXJvdXRpbmcgb2YgdGhlIA0KPiBjb25uZWN0aW9uIHRvIGFub3RoZXIgZ3Jv dXAgbWVtYmVyLiBUbyBwcmV2ZW50IG1hbGljaW91cyByZXJvdXRpbmcgaW4gDQo+IGdyb3Vwcywg ZWFjaCBlbmRwb2ludCBuZWVkcyB0byBrbm93IHRoZSBpZGVudGlmaWVyIG9mIHRoZSBvdGhlciAN Cj4gZW5kcG9pbnQgd2l0aCB3aGljaCB0aGV5IHdhbnQgdG8gY29ubmVjdCBhbmQgY29tcGFyZSBp dCB3aXRoIHRoZSBvdGhlciANCj4gZW5kcG9pbnTigJlzIGlkZW50aWZpZXIgaW4gY29udGV4dC4g T2YgY291cnNlLCB0aGlzIG9ubHkgcHJldmVudHMgDQo+IGF0dGFja3MgYnkgbm9uLW1lbWJlcnM7 IHRoZSBlbmRwb2ludHMgdGhhdCBzaGFyZSB0aGUgZ3JvdXAga2V5IGNhbiANCj4gYWx3YXlzIGlt cGVyc29uYXRlIGVhY2ggb3RoZXIuDQoNCi0tTW9oaXQNCg0KT24gMTAvOC8xOSA3OjQ2IFBNLCBD aHJpc3RvcGhlciBXb29kIHdyb3RlOg0KPiBPbiBUdWUsIE9jdCA4LCAyMDE5LCBhdCAyOjU1IEFN LCBNb2hpdCBTZXRoaSBNIHdyb3RlOg0KPj4gICANCj4+IEhpIENocmlzLA0KPj4NCj4+IEZvciB0 aGUgYmVuZWZpdCBvZiB0aGUgbGlzdCwgbGV0IG1lIHN1bW1hcml6ZSB0aGF0IHRoZSBzZWxmaWUg YXR0YWNrIGlzDQo+PiBvbmx5IHJlbGV2YW50IHdoZXJlIG11bHRpcGxlIHBhcnRpZXMgc2hhcmUg dGhlIHNhbWUgUFNLIGFuZCB1c2UgdGhlDQo+PiBzYW1lIFBTSyBmb3Igb3V0Z29pbmcgYW5kIGlu Y29taW5nIGNvbm5lY3Rpb25zLiBUaGVzZSBzaXR1YXRpb25zIGFyZQ0KPj4gcmF0aGVyIHJhcmUs IGJ1dCBJIGFjY2VwdCB0aGF0IFRMUyBpcyB3aWRlbHkgdXNlZCAoYW5kIHNvbWV0aW1lcw0KPj4g bWlzdXNlZCkgaW4gbWFueSBwbGFjZXMuDQo+Pg0KPj4gVGhlIFNlbGZpZSBhdHRhY2sgb25seSBo YXBwZW5zIHdoZW4gYW4gZW50aXR5IHdpdGggdGhlIFBTSyBhY3RzDQo+PiBtYWxpY2lvdXNseS4g U28gSSB0aGluayB0aGUgZmFjdCB0aGF0IHlvdSB3cml0ZSBpbiB0aGUgZHJhZnQ6ICJlYWNoDQo+ PiBub2RlIG11c3QgYmUgdHJ1c3RlZCBub3QgdG8gaW1wZXJzb25hdGUgYW5vdGhlciBub2RlJ3Mg cm9sZSIgZG9lcyBub3QNCj4+IHRha2UgaW50byBhY2NvdW50IHRoYXQgdGhlcmUgbXVzdCBiZSBh IG1hbGljaW91cyBub2RlIGZvciB0aGUgc2VsZmllDQo+PiBhdHRhY2sgdG8gaGFwcGVuIGluIHRo ZSBmaXJzdCBwbGFjZS4NCj4+DQo+PiBEcnVja2VyIGFuZCBHdWVyb24ncyBwYXBlciByZWNvbW1l bmRzIHRoYXQgImV2ZXJ5IHBhcnRpY2lwYXRpbmcgcGFydHkNCj4+IGdldHMgKGR1cmluZyB0aGUg c2V0dXAgb2YgdGhlIG5ldHdvcmspIGEgdW5pcXVlIGlkZW50aXR5IiBhbmQgInRoZQ0KPj4gY2xp ZW50IGFuZCB0aGUgc2VydmVyIG11c3QgdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiB0aGUgY2xhaW1l ZA0KPj4gaWRlbnRpdGllcy4iLiBUaGUgcmVhbGl0eSBob3dldmVyIGlzIHRoYXQgaW4gbW9zdCBn cm91cCBQU0sgc2NlbmFyaW9zLA0KPj4gdGhlIG5vZGVzIGRvbid0IGhhdmUgYW55IHN0cm9uZyBp ZGVudGl0aWVzIHRoYXQgY2FuIGJlIHZlcmlmaWVkLg0KPj4NCj4+IFdoYXQgeW91IHNob3VsZCBp bnN0ZWFkIChvciBhZGRpdGlvbmFsbHkpIHNheSBpbiB0aGUgdGV4dCBpcyB0aGF0IGENCj4+IG5v ZGUgc2hvdWxkIGNoZWNrIHRoYXQgdGhlIGNsaWVudF9tYWMgYW5kIHNlcnZlcl9tYWMgKG9yIGFu eSBvdGhlcg0KPj4gaWRlbnRpdGllcyB1c2VkKSAqYXJlIG5ldmVyIHRoZSBzYW1lKi4NCj4gVGhp cyBzZWVtcyBpbXBsaWNpdCBpbiB0aGUgdGV4dCBhcyB3cml0dGVuLiBDb3VsZCBJIGFzayB5b3Ug dG8gc3VibWl0IGEgUFIgYWdhaW5zdCBbMV0gdG8gY2xhcmlmeT8NCj4NCj4gVGhhbmtzLA0KPiBD aHJpcw0KPg0KPiBbMV0gaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL2RyYWZ0LWlldGYtdGxzLWV4 dGVybmFsLXBzay1pbXBvcnRlcg0KPg0KPj4gV2l0aG91dCB0aGlzIGNoZWNrLCB0aGUgc2VsZmll DQo+PiBhdHRhY2sgd291bGQgc3RpbGwgYmUgcG9zc2libGUuIEFuZCBhdCBsZWFzdCB0aGlzIGRv ZXMgbm90IHJlcXVpcmUNCj4+IHN0cm9uZyBpZGVudGl0eSB2ZXJpZmljYXRpb24gZm9yIHByZXZl bnRpbmcgc2VsZmllIGF0dGFja3MuDQo+Pg0KPj4gLS1Nb2hpdA0KPj4NCj4+IE9uIDEwLzUvMTkg Mjo0MSBQTSwgQ2hyaXN0b3BoZXIgV29vZCB3cm90ZToNCj4+PiBIaSBGZW5nLA0KPj4gRm9yIHdo YXQgaXQncyB3b3J0aCwgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBQU0sgaW1wb3J0ZXJzIGRy YWZ0DQo+PiBpbmNsdWRlcyBhICJjb250ZXh0IiBmaWVsZCBpbnRvIHdoaWNoIGlkZW50aXR5IGlu Zm9ybWF0aW9uIGNhbiBiZSBmZWQ6DQo+Pg0KPj4gICAgIA0KPj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLWV4dGVybmFsLXBzay1pbXBvcnRlci0wMSNhcHBlbmRp eC1CDQo+Pg0KPj4gQmVzdCwNCj4+IENocmlzDQo+Pg0KPj4gT24gVHVlLCBTZXAgMjQsIDIwMTks IGF0IDk6MTkgQU0sIEhhbywgRmVuZyB3cm90ZToNCj4+Pj4gSGkgSm9obiwNCj4+IFJlZmxlY3Rp b24gYXR0YWNrcyBhcmUgaW5kZWVkIG9sZGVyLCBidXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMgYSBi aXQNCj4+IGRpZmZlcmVudC4gSXQncyBhY3R1YWxseSBhIHZhcmlhbnQgb2YgdGhlIHVua25vd24g a2V5IHNoYXJlIGF0dGFjay4gQQ0KPj4gdHlwaWNhbCBleGFtcGxlIG9mIHRoZSBVS1MgYXR0YWNr IGlzIHRoZSBvbmUgcmVwb3J0ZWQgb24gTVFWIGJ5IEthbGlza2kNCj4+IGluIDIwMDEgKHNlZSAi QW4gdW5rbm93biBrZXktc2hhcmUgYXR0YWNrIG9uIHRoZSBNUVYga2V5IGFncmVlbWVudA0KPj4g cHJvdG9jb2wiIGluIEFDTSBUSVNTRUMgMjAwMSkuIEluIHRoYXQgZXhhbXBsZSwgdGhlIGFkdmVy c2FyeSBwbGF5cw0KPj4gbWVzc2FnZSBiZXR3ZWVuIHR3byB1c2VycyB0byBjYXVzZSBjb25mdXNp b24gaW4gdGhlIGlkZW50aXR5LCBidXQgaW4NCj4+IFNlbGZpZSwgdGhlIGFkdmVyc2FyeSBwbGF5 cyBtZXNzYWdlIHdpdGggb25seSBvbmUgdXNlciBhbmQgdXNlcyBhbm90aGVyDQo+PiBpbnN0YW5j ZSBvZiB0aGUgdXNlciB0byBjYXVzZSBjb25mdXNpb24gaW4gdGhlIGlkZW50aXR5LiBXaGVuIHdl DQo+PiByZXBvcnRlZCB0aGlzIHZhcmlhbnQgb2YgVUtTIGluIFszXSwgd2Ugd2VyZSBub3QgYXdh cmUgb2YgYW55dGhpbmcgbGlrZQ0KPj4gdGhhdCBpbiB0aGUgbGl0ZXJhdHVyZS4NCj4+DQo+PiBD aGVlcnMsDQo+PiBGZW5nDQo+Pg0KPj4g77u/T24gMjQvMDkvMjAxOSwgMTY6MTcsICJKb2huIE1h dHRzc29uIiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4NCj4+ICAgICAg SGksDQo+PiAgICAgIA0KPj4gICAgICBJIHRoaW5rIHRoZXNlIHJlZmxlY3Rpb24gYXR0YWNrcyBh cmUgbXVjaCBvbGRlciB0aGFuIHRoaXMuIEkgcXVpY2sNCj4+IHNlYXJjaCBmb3IgcmVmbGVjdGlv biBhdHRhY2sgc2VjdXJpdHkgcHJvdG9jb2wgZ2l2ZXMgYSBsb3Qgb2Ygb2xkDQo+PiByZXN1bHRz LCBUaGUgZGVzY3JpcHRpb24gb2YgcmVmbGVjdGlvbiBhdHRhY2sgaW4gdGhlIGZvbGxvd2luZyBs ZWN0dXJlDQo+PiBtYXRlcmlhbCBmcm9tIDIwMDkgbG9va3MganVzdCBsaWtlIHRoZSAic2VsZmll IGF0dGFjayIgb24gVExTIDEuMw0KPj4gICAgICBodHRwOi8vd3d3LmNzLmJoYW0uYWMudWsvfnRw Yy9jd2kvVGVhY2hpbmcvRmlsZXMvTGVjdHVyZTRfNnVwLnBkZg0KPj4gICAgICANCj4+ICAgICAg V2l0aCBtdWx0aXBsZSBzZWN0aW9ucyB0aGVyZSBhcmUgb3RoZXIgdGhpbmdzIHRoYXQgY2hhbmdl IGFzIHdlbGwuDQo+PiBJZiB0d28gbm9kZXMgdW5pbnRlbnRpb25hbGx5IGluaXRpYXRlIHNpbXVs dGFuZW91cyBDbGllbnRIZWxsbyB0byBlYWNoDQo+PiBvdGhlciwgZXZlbiBpZiB0aGV5IG9ubHkg d2FudCBhIHNpbmdsZSBzZWN1cmUgY29ubmVjdGlvbiAoSSBoYXZlIHNlZW4NCj4+IGxpdmUgc3lz dGVtcyB3aGVyZSB0aGlzIGhhcHBlbnMgaW4gcHJhY3RpY2UpLCBhbiBhdHRhY2tlciBjYW4gc2Vs ZWN0DQo+PiB3aGljaCBDbGllbnRIZWxsbyB0byBibG9jayAoZS5nLiB0aGUgb25lIHdpdGggdGhl IHN0cm9uZ2VzdA0KPj4gY3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzKS4gVGhlIGZvbGxvd2luZyBz ZWN1cml0eSBwcm9wZXJ0eSB3b3VsZCB0aGVuDQo+PiBubyBsb25nZXIgaG9sZCA6DQo+PiAgICAg IA0KPj4gICAgICAgICJEb3duZ3JhZGUgcHJvdGVjdGlvbjogIFRoZSBjcnlwdG9ncmFwaGljIHBh cmFtZXRlcnMgc2hvdWxkIGJlIHRoZQ0KPj4gICAgICAgICAgICBzYW1lIG9uIGJvdGggc2lkZXMg YW5kIHNob3VsZCBiZSB0aGUgc2FtZSBhcyBpZiB0aGUgcGVlcnMgaGFkIGJlZW4NCj4+ICAgICAg ICAgICAgY29tbXVuaWNhdGluZyBpbiB0aGUgYWJzZW5jZSBvZiBhbiBhdHRhY2siDQo+PiAgICAg IA0KPj4gICAgICAoSSBoYXZlIG5vdCBsb29rZWQgYXQgd2hhdCB0aGUgZGVmaW5pdGlvbnMgaW4g W0JCRkdLWjE2XSBzYXkpLg0KPj4gICAgICANCj4+ICAgICAgQ2hlZXJzLA0KPj4gICAgICBKb2hu DQo+PiAgICAgIA0KPj4gICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gICAgICBG cm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIkhhbywgRmVuZyIN Cj4+Pj4gPEZlbmcuSGFvQHdhcndpY2suYWMudWs+DQo+PiAgICAgIERhdGU6IFR1ZXNkYXksIDI0 IFNlcHRlbWJlciAyMDE5IGF0IDE2OjA5DQo+PiAgICAgIFRvOiBNb2hpdCBTZXRoaSBNIDxtb2hp dC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiwNCj4+ICJPd2VuIEZyaWVs IChvZnJpZWwpIiA8b2ZyaWVsQGNpc2NvLmNvbT4sIEpvbmF0aGFuIEhveWxhbmQNCj4+Pj4gPGpv bmF0aGFuLmhveWxhbmRAZ21haWwuY29tPg0KPj4gICAgICBDYzogIlRMU0BpZXRmLm9yZyIgPHRs c0BpZXRmLm9yZz4NCj4+ICAgICAgU3ViamVjdDogUmU6IFtUTFNdIFNlbGZpZSBhdHRhY2sgd2Fz IFJlOiBEaXN0aW5ndWlzaGluZyBiZXR3ZWVuDQo+PiBleHRlcm5hbC9yZXN1bXB0aW9uIFBTS3MN Cj4+ICAgICAgDQo+PiAgICAgICAgICANCj4+ICAgICAgICAgIE9uIDIzLzA5LzIwMTksIDE4OjUw LCAiVExTIG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRoaSBNIg0KPj4+PiA8dGxzLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mDQo+PiBtb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJj LmlldGYub3JnPg0KPj4gPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ29uYmVoYWxmb2Ztb2hp dC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4+ICAgICAg ICAgIA0KPj4gICAgICAgICAgICAgIEhpIGFsbCwNCj4+ICAgICAgICAgICAgICANCj4+ICAgICAg ICAgICAgICBPbiB0aGUgdG9waWMgb2YgZXh0ZXJuYWwgUFNLcyBpbiBUTFMgMS4zLCBJIGZvdW5k IGENCj4+IHB1YmxpY2F0aW9uIG9uIHRoZQ0KPj4gICAgICAgICAgICAgIFNlbGZpZSBhdHRhY2s6 DQo+Pj4+IGh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9ZGQ0MzJmMTMtODFjOWU1 YWQtZGQ0MzZmODgtODY5YTE3YjViMjFiLWRjNmM2ZjBhNWRkMjFmYWYmcT0xJnU9aHR0cHMlM0El MkYlMkZlcHJpbnQuaWFjci5vcmclMkYyMDE5JTJGMzQ3DQo+PiAgICAgICAgICAgICAgDQo+PiAg ICAgICAgICAgICAgUGVyaGFwcyB0aGlzIHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0aGUgbGlz dC4gSSB0aG91Z2h0DQo+PiB0aGF0IHNoYXJpbmcNCj4+ICAgICAgICAgICAgICBpdCBhZ2FpbiB3 b3VsZG4ndCBodXJ0IHdoaWxlIHdlIGRpc2N1c3MgaG93IHNlcnZlcnMNCj4+IGRpc3Rpbmd1aXNo IGJldHdlZW4NCj4+ICAgICAgICAgICAgICBleHRlcm5hbCBhbmQgcmVzdW1wdGlvbiBQU0tzLg0K Pj4gICAgICAgICAgICAgIA0KPj4gICAgICAgICAgSSBqdXN0IHJlYWQgdGhlIHBhcGVyIHdpdGgg aW50ZXJlc3QuIEl0IG9jY3VycyB0byBtZSB0aGF0IHRoZQ0KPj4gc2VsZmllIGF0dGFjayBpcyBj b25zaXN0ZW50IHdpdGggdGhlICJpbXBlcnNvbmF0aW9uIGF0dGFjayIgdGhhdCB3ZQ0KPj4gcmVw b3J0ZWQgb24gU1BFS0UgaW4gMjAxNDsgc2VlIFNlYyA0LjEgWzFdIGFuZCB0aGUgdXBkYXRlZCB2 ZXJzaW9uIHdpdGgNCj4+IGRldGFpbHMgb24gaG93IFNQRUtFIGlzIHJldmlzZWQgaW4gSVNPL0lF QyAxMTc3MC00IFsyXS4gVGhlIHNhbWUgYXR0YWNrDQo+PiBjYW4gYmUgdHJhY2VkIGJhY2sgdG8g MjAxMCBpbiBbM10gd2hlcmUgYSAid29ybS1ob2xlIGF0dGFjayIgKEZpZy4gNSwNCj4+IFszXSkg aXMgcmVwb3J0ZWQgb24gdGhlIHNlbGYtY29tbXVuaWNhdGlvbiBtb2RlIG9mIEhNUVYuIFRoZSBl c3NlbmNlIG9mDQo+PiB0aGVzZSBhdHRhY2tzIGlzIHRoZSBzYW1lOiBCb2IgdHJpY2tzIEFsaWNl IGludG8gdGhpbmtpbmcgdGhhdCBzaGUgaXMNCj4+IHRhbGtpbmcgdG8gYXV0aGVudGljYXRlZCBC b2IsIGJ1dCBzaGUgaXMgYWN0dWFsbHkgdGFsa2luZyB0byBoZXJzZWxmLg0KPj4gSW4gWzNdLCB3 ZSBleHBsYWluZWQgdGhhdCB0aGUgYXR0YWNrIHdhcyBtaXNzZWQgZnJvbSB0aGUgInNlY3VyaXR5 DQo+PiBwcm9vZnMiIGFzIHRoZSBwcm9vZnMgZGlkbid0IGNvbnNpZGVyIG11bHRpcGxlIHNlc3Np b25zLg0KPj4gICAgICAgICAgDQo+PiAgICAgICAgICBUaGUgY291bnRlcm1lYXN1cmUgd2UgcHJv cG9zZWQgaW4gWzEtM10gd2FzIHRvIGVuc3VyZSB0aGUgdXNlcg0KPj4gaWRlbnRpdHkgaXMgdW5p cXVlIGluIGtleSBleGNoYW5nZSBwcm9jZXNzZXM6IGluIGNhc2Ugb2YgbXVsdGlwbGUNCj4+IHNl c3Npb25zIHRoYXQgbWF5IGNhdXNlIGNvbmZ1c2lvbiBpbiB0aGUgdXNlciBpZGVudGl0eSwgYW4g ZXh0ZW5zaW9uDQo+PiBzaG91bGQgYmUgYWRkZWQgdG8gdGhlIHVzZXIgaWRlbnRpdHkgdG8gZGlz dGluZ3Vpc2ggdGhlIGluc3RhbmNlcy4gVGhlDQo+PiB1bmRlcmx5aW5nIGludHVpdGlvbiBpcyB0 aGF0IG9uZSBzaG91bGQga25vdyAidW5hbWJpZ3VvdXNseSIgd2hvbSB0aGV5DQo+PiBhcmUgY29t bXVuaWNhdGluZyB3aXRoLCBhbmQgcGVyZm9ybSBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiB0aGF0 LiBUaGUNCj4+IGRpc2NvdmVyeSBvZiB0aGlzIHR5cGUgb2YgYXR0YWNrcyBhbmQgdGhlIHByb3Bv c2VkIHNvbHV0aW9uIGFyZQ0KPj4gaW5zcGlyZWQgYnkgdGhlICJleHBsaWNpdG5lc3MgcHJpbmNp cGxlIiAoUm9zcyBBbmRlcnNvbiBhbmQgUm9nZXINCj4+IE5lZWRoYW0sIENyeXB0byc5NSksIHdo aWNoIHN0YXRlcyB0aGUgaW1wb3J0YW5jZSBvZiBiZWluZyBleHBsaWNpdCBvbg0KPj4gdXNlciBp ZGVudGl0aWVzIGFuZCBvdGhlciBhdHRyaWJ1dGVzIGluIGEgcHVibGljIGtleSBwcm90b2NvbDsg YWxzbyBzZWUNCj4+IFszXS4gSSBob3BlIGl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBwZW9wbGUgd2hv IHdvcmsgb24gVExTIFBTSy4NCj4+ICAgICAgICAgIA0KPj4gICAgICAgICAgWzFdDQo+Pj4+IGh0 dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9NWE4MjI1MTMtMDYwOGVmYWQtNWE4MjY1 ODgtODY5YTE3YjViMjFiLWViMjYwMTUxZjc4YjA3MTgmcT0xJnU9aHR0cHMlM0ElMkYlMkZlcHJp bnQuaWFjci5vcmclMkYyMDE0JTJGNTg1LnBkZg0KPj4gICAgICAgICAgWzJdIGh0dHBzOi8vYXJ4 aXYub3JnL2Ficy8xODAyLjA0OTAwDQo+PiAgICAgICAgICBbM10NCj4+Pj4gaHR0cHM6Ly9wcm90 ZWN0Mi5maXJlZXllLmNvbS91cmw/az1kNWJmODhmZi04OTM1NDI0MS1kNWJmYzg2NC04NjlhMTdi NWIyMWItMGU5YjNiZjU4ZTEwNGYzMiZxPTEmdT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9y ZyUyRjIwMTAlMkYxMzYucGRmDQo+PiAgICAgICAgICANCj4+ICAgICAgICAgIA0KPj4gICAgICAg ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ICAg ICAgICAgIFRMUyBtYWlsaW5nIGxpc3QNCj4+ICAgICAgICAgIFRMU0BpZXRmLm9yZw0KPj4gICAg ICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4+ICAgICAg ICAgIA0KPj4gICAgICANCj4+ICAgICAgDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRMUyBtYWlsaW5nIGxpc3QNCj4+Pj4gVExTQGll dGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFRM UyBtYWlsaW5nIGxpc3QNCj4+PiBUTFNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From nobody Fri Oct 11 05:33:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1E1120019 for ; Fri, 11 Oct 2019 05:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 TV73eqXasRvP for ; Fri, 11 Oct 2019 05:33:46 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on061f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::61f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB55120071 for ; Fri, 11 Oct 2019 05:33:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RP+tuVqzpBQbi+cvdw1KYarV5OSd1SltkBS1miMnliAHulZI4riro1fA102/gpnxxnNCwDMx021FX6ah6Cr8f+NKd4MKv9dMHiuLkpaPuRuZVLZp23k9t88W1D1kUZjfjHmnENPBgdYqPqj3+SDYA/3RHMxK22uqbMO4RIIYY0FW1tDxXsloRHUIBfuBw98Sdu57qkn8XBAzuk0wdUToLDLOTTGgT9vfazIiujaWT/HEgeIyx6qBCHXnee2A+50e16uJQ6ruCWFq4ukV3FEX8AEBbxUbhiMuq31/L3+2N9rbIw7358draf7gcBe//95MmnYBgnuG/VzonvGhEg+NsA== 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=S1dnlAjHuKE06Qwf9vi8GvzU/1uvmV1Xk+tLCzCG9to=; b=eX5ph1ulEzJQfzP/ilgJFR8EbBSmXHqUNv8D5doVuM0QYRCwVrss03hm6LMXfljL4Qlas+Dzt1LLPAS5hjhUmm2uGl88XA596qruQ6+A89Pq7xCyhnPlMQzjtlwti592b3lFk2FuIObmSTKFq5WOE/lUoY3fVqtZTOHKHvrfzKjIEwEsmAepkgB2HcZqqEKfv+K0gofqE+yawqnZkrcPb2fBUw+UcWNCm/btuYhOu4wygPTisKYEsZvLcsqUOjVZ4V4u5DEJEz7lGneKi+dHYEHKrc+fJL50seNjOEp6iSp1kB9KAN6fo/LdmBXnjSeeNDgnQjh33DhsIGdxowUffA== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S1dnlAjHuKE06Qwf9vi8GvzU/1uvmV1Xk+tLCzCG9to=; b=I1/PazG29fw5xfdyUawEkqRfI4aSYmWmaoy1yNtQhkH/Z2cEuOSpmcmsuI0w4MIclaBMqc4c0Ha/wW6mW64hYUg/kNyfXVZCV7/DAh28R/Hfdo2VxAO/CtgD+f4Lk6zSt8QfF6aRCSXqfnK2NEWKUaJw/bL1Kuo+93UQ8H9Kfig= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2892.eurprd07.prod.outlook.com (10.168.94.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Fri, 11 Oct 2019 12:33:43 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f%6]) with mapi id 15.20.2347.016; Fri, 11 Oct 2019 12:33:43 +0000 From: Mohit Sethi M To: Christopher Wood , Christian Huitema , Mohit Sethi M , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb6JZ9ydCGu6h0WNgLEAne6JU6dQ9FwAgAAizgCAAFMEAIAD+pGA Date: Fri, 11 Oct 2019 12:33:43 +0000 Message-ID: <1f34cc42-45be-a580-a889-ab9bb60a7f38@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> <3a51cdaa-d04c-48b8-89b9-07d1510dba1a@www.fastmail.com> In-Reply-To: <3a51cdaa-d04c-48b8-89b9-07d1510dba1a@www.fastmail.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:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [82.203.244.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d73b379-b684-4eb2-5b96-08d74e474115 x-ms-traffictypediagnostic: HE1PR0701MB2892:|HE1PR0701MB2892: x-ms-exchange-purlcount: 2 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3513; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(396003)(346002)(199004)(189003)(186003)(71190400001)(76116006)(6306002)(6246003)(66946007)(66476007)(66446008)(66556008)(64756008)(110136005)(6512007)(478600001)(71200400001)(6506007)(2501003)(53546011)(14454004)(966005)(99286004)(102836004)(76176011)(26005)(6486002)(316002)(8676002)(31686004)(6436002)(58126008)(5660300002)(86362001)(7736002)(305945005)(6116002)(31696002)(81166006)(8936002)(14444005)(256004)(2906002)(3846002)(11346002)(446003)(2616005)(476003)(25786009)(486006)(229853002)(65806001)(65956001)(36756003)(66066001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2892; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QpJ6acyBJzRpSEjA5AZjLpqUoU0TGAXxkD/dcmF+fUqgqOwU7LSMAufMVFeoxzoC+mcvKIALNAWVlgW9ltY5/CAgTBxdlfIOo6Znd8VGXMHO7gNTIppZyxQSTFluCtPAr3cf0SPaassMjDdIIxWPsjExQ739IwXZdX2D0qdSgSwJ1tGUu0u7NctHdECKdMwnGu2i+clvwMVzaDZXWhVYntug+klIkan6/IHS6qD/GkwpfICjqH5G2+fSr3sVtydFsPkYgQe8hF9KDmJsnPuQufig8foOYenXVh3DpRaOa57NlC9gXgFTbIKIWSa7yEtkp+zwpg66TCitOrBF4+54FxBHa67jTpOkC1tEzKCItB/gpuyMgp21AC5qZeKtjHKMi6lfBmYXf1aMZO6SgHXUwuUbquQ0uVTlEZPacVunenwnoeo0GZjdSYPA0t0nNLpla21iylSeaOM3tfRg9UbyrQ== Content-Type: text/plain; charset="utf-8" Content-ID: <2046589C269D67498AD64AC9B0E5FD02@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d73b379-b684-4eb2-5b96-08d74e474115 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 12:33:43.6078 (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: c8yQL9zkpw3slMmQYtHxOZcph5Vmgw4PgBtAtBLE98kxDDvWJx7kjejE29TZWXdPDhofCttMondwdT5v9eIogSiP/yqeEHnnZr0Fa4Z3evo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2892 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 12:33:50 -0000 SGkgQ2hyaXMgYW5kIENocmlzdGlhbiwNCg0KSSB3b3VsZCBkaXNhZ3JlZS4gVGhlIGltcG9ydGFu dCB0aGluZyB0byBub3RlIGlzIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgDQppcyBub3QgYSB0cmFk aXRpb25hbCBpbnNpZGVyIGF0dGFjayB3aGVyZSBzb21lb25lIHdpdGggdGhlIFBTSyANCm1pc2Jl aGF2ZXMuIElmIHlvdSBsb29rIGF0IHRoZSBwYXBlciAoaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcv MjAxOS8zNDcpLCANCnlvdSB3aWxsIG5vdGljZSB0aGF0IEV2ZSBjYW4gZm9vbCBBbGljZSBpbnRv IG9wZW5pbmcgYSBjb25uZWN0aW9uIHdpdGggDQpoZXJzZWxmIHdpdGhvdXQga25vd2luZyB0aGUg UFNLIHRoYXQgQWxpY2Ugc2hhcmVzIHdpdGggQm9iLiBJZiBFdmUga25ldyANCnRoZSBQU0ssIHRo ZW4gY2VydGFpbmx5IGl0IGNvdWxkIHByZXRlbmQgdG8gYmUgYW55IG9uZSBvZiB0aGUgcGFydGll cyBpbiANCnRoZSBncm91cCB0aGF0IHNoYXJlcyB0aGUgUFNLLg0KDQotLU1vaGl0DQoNCk9uIDEw LzkvMTkgMjo0OCBBTSwgQ2hyaXN0b3BoZXIgV29vZCB3cm90ZToNCj4gT24gVHVlLCBPY3QgOCwg MjAxOSwgYXQgMTE6NTEgQU0sIENocmlzdGlhbiBIdWl0ZW1hIHdyb3RlOg0KPj4gICANCj4+IE9u IDEwLzgvMjAxOSA5OjQ2IEFNLCBDaHJpc3RvcGhlciBXb29kIHdyb3RlOg0KPj4NCj4+PiBPbiBU dWUsIE9jdCA4LCAyMDE5LCBhdCAyOjU1IEFNLCBNb2hpdCBTZXRoaSBNIHdyb3RlOg0KPj4+PiAg IA0KPj4gSGkgQ2hyaXMsDQo+Pg0KPj4gRm9yIHRoZSBiZW5lZml0IG9mIHRoZSBsaXN0LCBsZXQg bWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sgaXMNCj4+IG9ubHkgcmVsZXZhbnQg d2hlcmUgbXVsdGlwbGUgcGFydGllcyBzaGFyZSB0aGUgc2FtZSBQU0sgYW5kIHVzZSB0aGUNCj4+ IHNhbWUgUFNLIGZvciBvdXRnb2luZyBhbmQgaW5jb21pbmcgY29ubmVjdGlvbnMuIFRoZXNlIHNp dHVhdGlvbnMgYXJlDQo+PiByYXRoZXIgcmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExTIGlzIHdp ZGVseSB1c2VkIChhbmQgc29tZXRpbWVzDQo+PiBtaXN1c2VkKSBpbiBtYW55IHBsYWNlcy4NCj4+ DQo+Pg0KPj4gSSBtYXkgYmUgZ2V0dGluZyBvbGQgYnV0IHRoZSB3YXkgTW9oaXQgd3JpdGVzIGl0 LCBpdCBzZWVtcyB0aGF0IHRoZQ0KPj4gYXR0YWNrIGhhcHBlbnMgd2hlbiB0aGUgc2VjdXJpdHkg b2YgYSBncm91cCByZWxpZXMgb24gYSBzZWNyZXQgc2hhcmVkDQo+PiBieSBhbGwgbWVtYmVycyBv ZiB0aGUgZ3JvdXAsIGFuZCBjYW4gdGhlbiBiZSBjb21wcm9taXNlZCB3aGVuIG9uZSBvZg0KPj4g dGhlIGdyb3VwIG1lbWJlcnMgbWlzYmVoYXZlcy4gSG93IGlzIHRoYXQgYSBuZXcgdGhyZWF0PyBJ ZiBncm91cHMgYXJlDQo+PiBkZWZpbmVkIGJ5IGEgc2hhcmVkIHNlY3JldCwgdGhlbiBjb3JydXB0 aW9uIG9mIGEgZ3JvdXAgbWVtYmVyIHJldmVhbHMNCj4+IHRoYXQgc2hhcmVkIHNlY3JldCB0byB0 aGUgYXR0YWNrZXIgYW5kIG9wZW4gdGhlIHBhdGggZm9yIGFsbCBraW5kcyBvZg0KPj4gZXhwbG9p dGF0aW9uLiBJbiB3aGF0IHNlbnNlIGlzIHRoZSAic2VsZmllIiBhdHRhY2sgZGlmZmVyZW50IGZy b20gdGhhdA0KPj4gZ2VuZXJpYyB0aHJlYXQ/DQo+IEluIG15IG9waW5pb24sIGl0J3Mgbm90Lg0K Pg0KPiBCZXN0LA0KPiBDaHJpcw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQo= From nobody Fri Oct 11 05:36:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BED9120071 for ; Fri, 11 Oct 2019 05:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 mVN3n4xhtAFP for ; Fri, 11 Oct 2019 05:36:53 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50074.outbound.protection.outlook.com [40.107.5.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48C87120088 for ; Fri, 11 Oct 2019 05:36:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aVK1X4rm0MaMr/7UOME6VpGpLw+mG3prDTRdNhvp+hbryBRvWb5B2nd1gqYgwBRmFDRQL/8BeCie/9tdwYJJhktbp+5TU+AvXcPfSkqPwZNpZOPdtj0rEqmasA0545EtM9tHiedufgmGdl9Oqs+RE8rACasHBHetcME3q85IMLcjEMhOeFCaY9QHaTwplc5ImKhYTcXdnSeLdM39Pr7/wUvqCJ7YmPgp3ms7f5Jyj1jHIEMf/f4Brq+pUMLdYaqs8WZJzamjJfU7nXqp9BuDgTm96L88TrYeCiUaxxPM6lC/1VAfKlX4UtCdXoku7Rm8YnBx991rlfTKbreMen4PKQ== 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=mn7MCTNUq9RK3M/WGEgzSkldMK+TKY5s95P4XTZnbGQ=; b=mOz+4sc8e4FagUamYpBXRUETvoOB2Eg+1kW7hsrvSG54iInbPyUjRawBKuVz1tMuxOuNi/sBUFsWy0dQ9/sJlDmaAii6rUYM8Y4HifVAvoO/X2bfHtTYY/RoqVZDnK0whWgUPJpJFIfgTwz5R4r28aeVSTYklM7KrHNY9HHl16fdxikOI1FfDVtGC9FOxUhHYWXwW9NLVPz3m+qFdy07ohy9rdQkmy7fNCREF4lf3VFbBtIeKo3lZzM2JKTQzhYPwfclQv6DhsFGnYcB60qThGduAcxwkLxzoBfYyttK8NL+8WMszBujKAcFwdl0/W3RFaWs++MNTkyeAJtg5+bZ8g== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mn7MCTNUq9RK3M/WGEgzSkldMK+TKY5s95P4XTZnbGQ=; b=AihLIZc9KRN2L85SBzP8ryT2XOVhi3Tpa06Zy7R4OtLC1mv9E+5lZrrCWItPEXJVMzIMoCbE2d6LK9RUr1kkybbL1STUO5dQUuk6x6BSGXVUdHVmIPx+nsWi9XTpUHQEswUlWpAGakqQBxcgaz5mJtp44Yz68S4cOK9zufVmUu8= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2892.eurprd07.prod.outlook.com (10.168.94.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.13; Fri, 11 Oct 2019 12:36:47 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::f073:9f5c:2438:ea1f%6]) with mapi id 15.20.2347.016; Fri, 11 Oct 2019 12:36:47 +0000 From: Mohit Sethi M To: John Mattsson , Mohit Sethi M , Christian Huitema , Christopher Wood , Mohit Sethi M , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb6JZ9ydCGu6h0WNgLEAne6JU6dQ9FwAgAAizgCAAAS3gIAD9nmAgABTPwA= Date: Fri, 11 Oct 2019 12:36:47 +0000 Message-ID: <83d858da-e180-029b-e6a1-58778948f811@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> <28313e8d-48d1-723e-9548-1e9fb3718491@ericsson.com> In-Reply-To: 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:60.0) Gecko/20100101 Thunderbird/60.8.0 authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-originating-ip: [82.203.244.107] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62abf312-2448-49bd-698a-08d74e47ae76 x-ms-traffictypediagnostic: HE1PR0701MB2892:|HE1PR0701MB2892: x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(136003)(39860400002)(376002)(396003)(346002)(199004)(189003)(186003)(71190400001)(76116006)(6306002)(6246003)(66946007)(66476007)(66446008)(66556008)(64756008)(236005)(110136005)(6512007)(606006)(478600001)(71200400001)(6506007)(2501003)(53546011)(14454004)(54896002)(966005)(99286004)(102836004)(76176011)(26005)(6486002)(316002)(8676002)(31686004)(6436002)(58126008)(5660300002)(86362001)(7736002)(6116002)(790700001)(31696002)(81166006)(8936002)(14444005)(256004)(2906002)(3846002)(11346002)(446003)(2616005)(476003)(25786009)(486006)(229853002)(65806001)(65956001)(36756003)(66066001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2892; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UgumRBB1DfJdrUfK0PVDRa8C9k8J4iIeQswexLLhTyBpbsz1CPWbMdBhb7iofdnSi/9eFwOBl85Z/FTLRcpQMPGQkzdKeCowAKe/AKthKTzv75Ct4xN/Qd2pBQT4ZLj/4SpVRLsLwnFjyAv6DI9vFGTFvKI1bHeBkl/pgg8qrn60/55J943Z12P0RV5cfwtkcVWjBFl/VOiTBcUGlAewAlqQvzaZpGrrmHy13PwQiUOKrZypHEmCNPv8Jm49RSsSFObCPWPBXq9YapZFNSINUL4aqtuwnIEToEGhEj8M3LBUvOUfrDM0mXUsn53Kp8/NLwVplP+EsKJvQs98J/0hDUC5oXkcTzOd/ZWbMIZgt9qjPPjUb0f2utId7LinqK8L4931q6RSlvXKC3se3v4LyaJKOCsKBtrwbLub4g4+iqfPQi+SuCHzdSCZCt/U/eHq4GXAqhQlSkNyg4ME1cB8gg== Content-Type: multipart/alternative; boundary="_000_83d858dae180029be6a158778948f811ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62abf312-2448-49bd-698a-08d74e47ae76 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 12:36:47.0635 (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: /V1ctAe56yzvnR3iN6YAcdqGbc/zdeXezuuaxPywJw0m+inbI/CGhAfVOSB3pWlmfWN+rDzBOCNGJ0qv7a95ojznaLtiVuqUviSrNUQkt6A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2892 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 12:36:56 -0000 --_000_83d858dae180029be6a158778948f811ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KSSBob3BlIHlvdSBhbHNvIGNoZWNrIHRoZSB0ZXh0IGZvciBhZGRyZXNzaW5n IFNlbGZpZSBhdHRhY2tzIGluIHRoZSBwdWxsIHJlcXVlc3QgSSBjcmVhdGVkIENocmlzLiBTb21l IG1vcmUgY29tbWVudHMgYmVsb3cuDQoNCi0tTW9oaXQNCg0KT24gMTAvMTEvMTkgMTA6MzggQU0s IEpvaG4gTWF0dHNzb24gd3JvdGU6DQoNClRoYW5rcyBNb2hpdCwNCg0KDQoNClJlLXJlYWRpbmcg dGhlIFNlbGZpZSBwYXBlciBJIHNlZSB0aGF0IHRoZSBhdXRob3JzIGRlZmluZSBDbGllbnQgQWxp Y2UgYW5kIFNlcnZlciBBbGljZSBhcyBkaWZmZXJlbnQgbWVtYmVycyBvZiB0aGUgZ3JvdXAuIFRo YXQgbWFrZXMgdGhpbmdzIGNsZWFyZXIuIEkgdGhpbmsgdGhlcmUgYXJlIHRocmVlIGNhc2VzOg0K DQoNCg0KICAxLiAgVXNlIGNhc2VzIHdoZXJlIG9ubHkgQ2xpZW50IEFsaWNlIGFuZCBTZXJ2ZXIg Qm9iIHNoYXJlcyB0aGUgUFNLIGFyZSBub3QgdnVsbmVyYWJsZSB0byB0aGUgU2VsZmllIGF0dGFj ay4NCg0KDQoNCiAgMS4gIENhc2VzIHdoZXJlIEFsaWNlLCBCb2IsIGFuZCBDYWVzYXIgc2hhcmUg YW4gZXh0ZXJuYWwgUFNLIHNlZW0gbGlrZSBtaXNjb25maWd1cmF0aW9uLCBJIGFzc3VtZSBUTFMg MS4zIGp1c3QgZm9yZ290IHRvIGV4cGxpY2l0bHkgZm9yYmlkIHRoZW0uDQoNCg0KDQogIDEuICBU aGUgaW50ZXJlc3RpbmcgdXNlIGNhc2UgaWYgd2hlcmUgQ2xpZW50IEFsaWNlLCBTZXJ2ZXIgQWxp Y2UsIENsaWVudCBCb2IsIGFuZCBTZXJ2ZXIgQm9iIHNoYXJlcyBhIFBTSy4gVGhhdCBpcyBhIHZl cnkgdmFsaWQgdXNlIGNhc2UgYW5kIG9uZSB0aGF0IGlzIGN1cnJlbnRseSBkZXBsb3llZCBpbiBz ZXZlcmFsIHN5c3RlbXMuDQoNCg0KDQpUbyBkbyBhcyB0aGUgU2VsZmllIGF1dGhvcnMgc3VnZ2Vz dCDigJxBIFBTSyBNVVNUIE5PVCBiZSBzaGFyZWQgYmV0d2VlbiBtb3JlIHRoYW4gb25lIGNsaWVu dCBhbmQgb25lIHNlcnZlcuKAnSBzZWVtcyB3YXkgdG9vIGRyYXN0aWMgYXMgaXMgZm9yYmlkcyAz IGFib3ZlLiBGb3IgMyBJIHRoaW5rIHRoZSBTZWxmaWUgYXR0YWNrIGNhbiBiZSB2ZXJ5IGVhc2ls eSBtaXRpZ2F0ZWQgYnkgZm9yY2luZyBjbGllbnRzIHRvIGNoZWNrIGluY29taW5nIFNlcnZlckhl bGxvLnJhbmRvbS4NCg0KDQoNCkkgdGhpbmsgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZyB1 cGRhdGVzIGZvciBSRkMgODQ0NiB3b3VsZCBiZSBlbm91Z2g6DQoNCg0KDQrigJxBIFBTSyBNVVNU IE5PVCBiZSBzaGFyZWQgYmV0d2VlbiBtb3JlIHRoYW4gdHdvIGVuZHBvaW50c+KAnQ0KDQpXaGF0 IGlzIGEgYnVnIGZvciB5b3UgbWF5YmUgaXMgYSBmZWF0dXJlIGZvciBzb21lb25lIGVsc2UuIEkg d2lzaCB3ZSBjb3VsZCBwdXQgdGhlIHJlcXVpcmVtZW50IHlvdSBzdWdnZXN0IGJ1dCB0aGVyZSBh cmUgc2V2ZXJhbCBwZW9wbGUgd2hvIHVzZSBQU0tzIHRoYXQgYXJlIHNoYXJlZCBieSBtb3JlIHRo YW4gdHdvIG5vZGVzLg0KDQoNCg0KDQrigJxBbiBlbmRwb2ludCByZWNlaXZpbmcgYSBDbGllbnRI ZWxsbyB3aXRoIFBTSyBhdXRoZW50aWNhdGlvbiBNVVNUIGNoZWNrIHRoYXQgdGhlIENsaWVudEhl bGxvLnJhbmRvbSBpcyBub3QgZXF1YWwgdG8gYSBDbGllbnRIZWxsby5yYW5kb20gdGhhdCB0aGUg ZW5kcG9pbnQgcHJldmlvdXNseSBzZW50IGFuZCBoYXMgbm90IHJlY2VpdmVkIGEgU2VydmVySGVs bG8u4oCdDQoNClRoaXMgaXMgb25lIHBvc3NpYmxlIHNvbHV0aW9uLiBJbiBlZmZlY3QgeW91IGFy ZSB1c2luZyB0aGUgQ2xlaW50SGVsbG8ucmFuZG9tIGFuZCBTZXJ2ZXJIZWxsby5yYW5kb20gYXMg ZW5kcG9pbnQgaWRlbnRpZmllcnMuIEhvd2V2ZXIsIGl0IHNlZW1zIGNsZWFuZXIgdG8gbm90IHJl LXVzZSByYW5kb20gbm9uY2VzIGZyb20gdGhlIGNyeXB0b2dyYXBoaWMgcHJvdG9jb2xzIGFzIGlk ZW50aWZpZXJzLg0KDQoNCg0KQ2hlZXJzLA0KDQpKb2huDQoNCkZyb206IFRMUyA8dGxzLWJvdW5j ZXNAaWV0Zi5vcmc+PG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIE1v aGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+ PG1haWx0bzptb2hpdC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPg0KRGF0 ZTogVHVlc2RheSwgOCBPY3RvYmVyIDIwMTkgYXQgMjE6MDgNClRvOiBDaHJpc3RpYW4gSHVpdGVt YSA8aHVpdGVtYUBodWl0ZW1hLm5ldD48bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+LCBDaHJp c3RvcGhlciBXb29kIDxjYXdAaGVhcGluZ2JpdHMubmV0PjxtYWlsdG86Y2F3QGhlYXBpbmdiaXRz Lm5ldD4sIE1vaGl0IFNldGhpIE0gPG1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPjxtYWlsdG86 bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+LCAiVExTQGlldGYub3JnIjxtYWlsdG86VExTQGll dGYub3JnPiA8dGxzQGlldGYub3JnPjxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtUTFNdIFNlbGZpZSBhdHRhY2sNCg0KDQpIaSBDaHJpc3RpYW4sDQoNCkl0IHdhcyBteSBwb29y IGF0dGVtcHQgYXQgZXhwbGFpbmluZyB0aGUgYXR0YWNrLiBUaGUgYXR0YWNrIGNhbiBoYXBwZW4g YXMgbG9uZyBhcyBhIG5vZGUgc2VuZHMgb3V0Ym91bmQgY29ubmVjdGlvbnMgKGFzIGEgVExTIGNs aWVudCkgYW5kIGFjY2VwdHMgaW5ib3VuZCBjb25uZWN0aW9ucyAoYXMgYSBUTFMgc2VydmVyKSB3 aXRoIHRoZSBzYW1lIGV4dGVybmFsIFBTSyBhbmQgaWRlbnRpdHkuIFRoaXMgaXMgbGlrZWx5IHRv IGhhcHBlbiBpbiBzb21lIGZvcm0gb2YgZ3JvdXAgY29tbXVuaWNhdGlvbiBidXQgbm90IG5lY2Vz c2FyaWx5Lg0KDQpJbiBzdWNoIGEgc2NlbmFyaW8sIGEgbWFsaWNpb3VzIG5vZGUgRXZlIGNhbiBm b29sIEFsaWNlIHRvIG9wZW4gYSBjb25uZWN0aW9uIHRvIGhlcnNlbGYgKGhlbmNlIHRoZSBuYW1l IFNlbGZpZSkuDQoNCkFkbWl0dGVkbHksIFVLUy9taXNiaW5kaW5nL3NlbGZpZSBhcmUgc29tZXdo YXQgaGFyZCB0byBjb21wcmVoZW5kIHNvbWV0aW1lcyAoYXQgbGVhc3QgZm9yIG1lKS4NCg0KLS1N b2hpdA0KT24gMTAvOC8xOSA5OjUxIFBNLCBDaHJpc3RpYW4gSHVpdGVtYSB3cm90ZToNCg0KT24g MTAvOC8yMDE5IDk6NDYgQU0sIENocmlzdG9waGVyIFdvb2Qgd3JvdGU6DQoNCk9uIFR1ZSwgT2N0 IDgsIDIwMTksIGF0IDI6NTUgQU0sIE1vaGl0IFNldGhpIE0gd3JvdGU6DQoNCg0KDQpIaSBDaHJp cywNCg0KDQoNCkZvciB0aGUgYmVuZWZpdCBvZiB0aGUgbGlzdCwgbGV0IG1lIHN1bW1hcml6ZSB0 aGF0IHRoZSBzZWxmaWUgYXR0YWNrIGlzDQoNCm9ubHkgcmVsZXZhbnQgd2hlcmUgbXVsdGlwbGUg cGFydGllcyBzaGFyZSB0aGUgc2FtZSBQU0sgYW5kIHVzZSB0aGUNCg0Kc2FtZSBQU0sgZm9yIG91 dGdvaW5nIGFuZCBpbmNvbWluZyBjb25uZWN0aW9ucy4gVGhlc2Ugc2l0dWF0aW9ucyBhcmUNCg0K cmF0aGVyIHJhcmUsIGJ1dCBJIGFjY2VwdCB0aGF0IFRMUyBpcyB3aWRlbHkgdXNlZCAoYW5kIHNv bWV0aW1lcw0KDQptaXN1c2VkKSBpbiBtYW55IHBsYWNlcy4NCg0KDQoNCkkgbWF5IGJlIGdldHRp bmcgb2xkIGJ1dCB0aGUgd2F5IE1vaGl0IHdyaXRlcyBpdCwgaXQgc2VlbXMgdGhhdCB0aGUgYXR0 YWNrIGhhcHBlbnMgd2hlbiB0aGUgc2VjdXJpdHkgb2YgYSBncm91cCByZWxpZXMgb24gYSBzZWNy ZXQgc2hhcmVkIGJ5IGFsbCBtZW1iZXJzIG9mIHRoZSBncm91cCwgYW5kIGNhbiB0aGVuIGJlIGNv bXByb21pc2VkIHdoZW4gb25lIG9mIHRoZSBncm91cCBtZW1iZXJzIG1pc2JlaGF2ZXMuIEhvdyBp cyB0aGF0IGEgbmV3IHRocmVhdD8gSWYgZ3JvdXBzIGFyZSBkZWZpbmVkIGJ5IGEgc2hhcmVkIHNl Y3JldCwgdGhlbiBjb3JydXB0aW9uIG9mIGEgZ3JvdXAgbWVtYmVyIHJldmVhbHMgdGhhdCBzaGFy ZWQgc2VjcmV0IHRvIHRoZSBhdHRhY2tlciBhbmQgb3BlbiB0aGUgcGF0aCBmb3IgYWxsIGtpbmRz IG9mIGV4cGxvaXRhdGlvbi4gSW4gd2hhdCBzZW5zZSBpcyB0aGUgInNlbGZpZSIgYXR0YWNrIGRp ZmZlcmVudCBmcm9tIHRoYXQgZ2VuZXJpYyB0aHJlYXQ/DQoNCi0tIENocmlzdGlhbiBIdWl0ZW1h DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpUTFMgbWFpbGluZyBsaXN0DQoNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0K DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxp c3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K --_000_83d858dae180029be6a158778948f811ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiIHRleHQ9IiMwMDAwMDAiPg0KPHA+SGkgSm9obiw8L3A+DQo8cD5JIGhvcGUgeW91IGFsc28g Y2hlY2sgdGhlIHRleHQgZm9yIGFkZHJlc3NpbmcgU2VsZmllIGF0dGFja3MgaW4gdGhlIHB1bGwg cmVxdWVzdCBJIGNyZWF0ZWQgQ2hyaXMuIFNvbWUgbW9yZSBjb21tZW50cyBiZWxvdy4NCjxicj4N CjwvcD4NCjxwPi0tTW9oaXQ8YnI+DQo8L3A+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgi Pk9uIDEwLzExLzE5IDEwOjM4IEFNLCBKb2huIE1hdHRzc29uIHdyb3RlOjxicj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkM1QUNGNEFFLUUyQzktNDFCMy1CQkYy LTAxMjJEMzU2NjJERkBlcmljc3Nvbi5jb20iPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250 ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQNCiAgICAgICAgbWVkaXVtKSI+DQo8c3R5 bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29Q bGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V Uzt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg UHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44 NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6MTU4NjEwNzU2MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTY5OTc3MTE5OCAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1 NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTg4NzgyNzA0Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDU0MzQ4ODg0 IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3 NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1HQiI+VGhhbmtzIE1vaGl0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+UmUt cmVhZGluZyB0aGUgU2VsZmllIHBhcGVyIEkgc2VlIHRoYXQgdGhlIGF1dGhvcnMgZGVmaW5lIENs aWVudCBBbGljZSBhbmQgU2VydmVyIEFsaWNlIGFzIGRpZmZlcmVudCBtZW1iZXJzIG9mIHRoZSBn cm91cC4gVGhhdCBtYWtlcyB0aGluZ3MgY2xlYXJlci4gSSB0aGluayB0aGVyZSBhcmUgdGhyZWUg Y2FzZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0i bWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjxzcGFuIGxhbmc9IkVOLUdCIj5V c2UgY2FzZXMgd2hlcmUgb25seSBDbGllbnQgQWxpY2UgYW5kIFNlcnZlciBCb2Igc2hhcmVzIHRo ZSBQU0sgYXJlIG5vdCB2dWxuZXJhYmxlIHRvIHRoZSBTZWxmaWUgYXR0YWNrLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6 MGNtIiBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJFTi1HQiI+Q2FzZXMgd2hlcmUg QWxpY2UsIEJvYiwgYW5kIENhZXNhciBzaGFyZSBhbiBleHRlcm5hbCBQU0sgc2VlbSBsaWtlIG1p c2NvbmZpZ3VyYXRpb24sIEkgYXNzdW1lIFRMUyAxLjMganVzdCBmb3Jnb3QgdG8gZXhwbGljaXRs eSBmb3JiaWQgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjMiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PHNwYW4g bGFuZz0iRU4tR0IiPlRoZSBpbnRlcmVzdGluZyB1c2UgY2FzZSBpZiB3aGVyZSBDbGllbnQgQWxp Y2UsIFNlcnZlciBBbGljZSwgQ2xpZW50IEJvYiwgYW5kIFNlcnZlciBCb2Igc2hhcmVzIGEgUFNL LiBUaGF0IGlzIGEgdmVyeSB2YWxpZCB1c2UgY2FzZSBhbmQgb25lIHRoYXQgaXMgY3VycmVudGx5 IGRlcGxveWVkIGluIHNldmVyYWwgc3lzdGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t R0IiPlRvIGRvIGFzIHRoZSBTZWxmaWUgYXV0aG9ycyBzdWdnZXN0IOKAnEEgUFNLIE1VU1QgTk9U IGJlIHNoYXJlZCBiZXR3ZWVuIG1vcmUgdGhhbiBvbmUgY2xpZW50IGFuZCBvbmUgc2VydmVy4oCd IHNlZW1zIHdheSB0b28gZHJhc3RpYyBhcyBpcyBmb3JiaWRzIDMgYWJvdmUuIEZvciAzIEkgdGhp bmsgdGhlIFNlbGZpZSBhdHRhY2sgY2FuIGJlIHZlcnkgZWFzaWx5IG1pdGlnYXRlZCBieQ0KIGZv cmNpbmcgY2xpZW50cyB0byBjaGVjayBpbmNvbWluZyBTZXJ2ZXJIZWxsby5yYW5kb20uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIGxhbmc9IkVOLUdCIj5JIHRoaW5rIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmcg dXBkYXRlcyBmb3IgUkZDIDg0NDYgd291bGQgYmUgZW5vdWdoOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7IiBsYW5nPSJF Ti1HQiI+4oCcQSBQU0sgTVVTVCBOT1QgYmUgc2hhcmVkIGJldHdlZW4gbW9yZSB0aGFuIHR3byBl bmRwb2ludHPigJ08L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnI+DQpXaGF0 IGlzIGEgYnVnIGZvciB5b3UgbWF5YmUgaXMgYSBmZWF0dXJlIGZvciBzb21lb25lIGVsc2UuIEkg d2lzaCB3ZSBjb3VsZCBwdXQgdGhlIHJlcXVpcmVtZW50IHlvdSBzdWdnZXN0IGJ1dCB0aGVyZSBh cmUgc2V2ZXJhbCBwZW9wbGUgd2hvIHVzZSBQU0tzIHRoYXQgYXJlIHNoYXJlZCBieSBtb3JlIHRo YW4gdHdvIG5vZGVzLg0KPGJyPg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0i bWlkOkM1QUNGNEFFLUUyQzktNDFCMy1CQkYyLTAxMjJEMzU2NjJERkBlcmljc3Nvbi5jb20iPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDsi IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAg TmV3JnF1b3Q7IiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXINCiAgICAgICAgICAgIE5ldyZxdW90OyIgbGFuZz0iRU4tR0IiPuKAnEFuIGVuZHBvaW50IHJl Y2VpdmluZyBhIENsaWVudEhlbGxvIHdpdGggUFNLIGF1dGhlbnRpY2F0aW9uIE1VU1QgY2hlY2sg dGhhdCB0aGUgQ2xpZW50SGVsbG8ucmFuZG9tIGlzIG5vdCBlcXVhbCB0byBhIENsaWVudEhlbGxv LnJhbmRvbSB0aGF0IHRoZSBlbmRwb2ludCBwcmV2aW91c2x5IHNlbnQNCiBhbmQgaGFzIG5vdCBy ZWNlaXZlZCBhIFNlcnZlckhlbGxvLuKAnTwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwPjxicj4NClRoaXMgaXMgb25lIHBvc3NpYmxlIHNvbHV0aW9uLiBJbiBlZmZlY3QgeW91 IGFyZSB1c2luZyB0aGUgQ2xlaW50SGVsbG8ucmFuZG9tIGFuZCBTZXJ2ZXJIZWxsby5yYW5kb20g YXMgZW5kcG9pbnQgaWRlbnRpZmllcnMuIEhvd2V2ZXIsIGl0IHNlZW1zIGNsZWFuZXIgdG8gbm90 IHJlLXVzZSByYW5kb20gbm9uY2VzIGZyb20gdGhlIGNyeXB0b2dyYXBoaWMgcHJvdG9jb2xzIGFz IGlkZW50aWZpZXJzLg0KPGJyPg0KPC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0i bWlkOkM1QUNGNEFFLUUyQzktNDFCMy1CQkYyLTAxMjJEMzU2NjJERkBlcmljc3Nvbi5jb20iPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDsi IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tR0IiPkNoZWVycyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1HQiI+ Sm9objxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyIgbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERg0KICAgICAgICAgIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5UTFMgPGEgY2xhc3M9Im1v ei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIj4N CiZsdDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRo aSBNIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzptb2hpdC5t LnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIj4NCiZsdDttb2hpdC5tLnNldGhp PTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnJmd0OzwvYT48YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgOCBPY3RvYmVyIDIwMTkgYXQgMjE6MDg8YnI+DQo8Yj5UbzogPC9iPkNocmlzdGlh biBIdWl0ZW1hIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpo dWl0ZW1hQGh1aXRlbWEubmV0Ij4NCiZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzwvYT4sIENo cmlzdG9waGVyIFdvb2QgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFp bHRvOmNhd0BoZWFwaW5nYml0cy5uZXQiPg0KJmx0O2Nhd0BoZWFwaW5nYml0cy5uZXQmZ3Q7PC9h PiwgTW9oaXQgU2V0aGkgTSA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJt YWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20iPg0KJmx0O21vaGl0Lm0uc2V0aGlAZXJp Y3Nzb24uY29tJmd0OzwvYT4sIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9 Im1haWx0bzpUTFNAaWV0Zi5vcmciPg0KJnF1b3Q7VExTQGlldGYub3JnJnF1b3Q7PC9hPiA8YSBj bGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj4m bHQ7dGxzQGlldGYub3JnJmd0OzwvYT48YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtUTFNdIFNl bGZpZSBhdHRhY2s8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGkgQ2hyaXN0aWFu LDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SXQgd2FzIG15 IHBvb3IgYXR0ZW1wdCBhdCBleHBsYWluaW5nIHRoZSBhdHRhY2suIFRoZSBhdHRhY2sgY2FuIGhh cHBlbiBhcyBsb25nIGFzIGEgbm9kZSBzZW5kcyBvdXRib3VuZCBjb25uZWN0aW9ucyAoYXMgYSBU TFMgY2xpZW50KSBhbmQgYWNjZXB0cyBpbmJvdW5kIGNvbm5lY3Rpb25zIChhcyBhIFRMUyBzZXJ2 ZXIpIHdpdGggdGhlIHNhbWUgZXh0ZXJuYWwgUFNLIGFuZCBpZGVudGl0eS4gVGhpcw0KIGlzIGxp a2VseSB0byBoYXBwZW4gaW4gc29tZSBmb3JtIG9mIGdyb3VwIGNvbW11bmljYXRpb24gYnV0IG5v dCBuZWNlc3NhcmlseS4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPkluIHN1Y2ggYSBzY2VuYXJpbywgYSBtYWxpY2lvdXMgbm9kZSBFdmUgY2FuIGZvb2wg QWxpY2UgdG8gb3BlbiBhIGNvbm5lY3Rpb24gdG8gaGVyc2VsZiAoaGVuY2UgdGhlIG5hbWUgU2Vs ZmllKS48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkFkbWl0 dGVkbHksIFVLUy9taXNiaW5kaW5nL3NlbGZpZSBhcmUgc29tZXdoYXQgaGFyZCB0byBjb21wcmVo ZW5kIHNvbWV0aW1lcyAoYXQgbGVhc3QgZm9yIG1lKS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS1Nb2hpdDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDEwLzgvMTkg OTo1MSBQTSwgQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMTAvOC8yMDE5IDk6NDYgQU0sIENo cmlzdG9waGVyIFdvb2Qgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBPY3QgOCwgMjAxOSwgYXQgMjo1NSBBTSwgTW9oaXQgU2V0 aGkgTSB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkhpIENocmlzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkZvciB0aGUgYmVuZWZpdCBvZiB0aGUgbGlzdCwgbGV0IG1lIHN1bW1h cml6ZSB0aGF0IHRoZSBzZWxmaWUgYXR0YWNrIGlzIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pm9ubHkgcmVsZXZhbnQgd2hlcmUgbXVsdGlwbGUgcGFydGllcyBzaGFyZSB0aGUgc2FtZSBQU0sg YW5kIHVzZSB0aGUgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c2FtZSBQU0sgZm9yIG91dGdv aW5nIGFuZCBpbmNvbWluZyBjb25uZWN0aW9ucy4gVGhlc2Ugc2l0dWF0aW9ucyBhcmUgPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+cmF0aGVyIHJhcmUsIGJ1dCBJIGFjY2VwdCB0aGF0IFRMUyBp cyB3aWRlbHkgdXNlZCAoYW5kIHNvbWV0aW1lcyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5t aXN1c2VkKSBpbiBtYW55IHBsYWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBtYXkgYmUg Z2V0dGluZyBvbGQgYnV0IHRoZSB3YXkgTW9oaXQgd3JpdGVzIGl0LCBpdCBzZWVtcyB0aGF0IHRo ZSBhdHRhY2sgaGFwcGVucyB3aGVuIHRoZSBzZWN1cml0eSBvZiBhIGdyb3VwIHJlbGllcyBvbiBh IHNlY3JldCBzaGFyZWQgYnkgYWxsIG1lbWJlcnMgb2YgdGhlIGdyb3VwLCBhbmQgY2FuIHRoZW4g YmUgY29tcHJvbWlzZWQgd2hlbiBvbmUgb2YgdGhlIGdyb3VwIG1lbWJlcnMgbWlzYmVoYXZlcy4N CiBIb3cgaXMgdGhhdCBhIG5ldyB0aHJlYXQ/IElmIGdyb3VwcyBhcmUgZGVmaW5lZCBieSBhIHNo YXJlZCBzZWNyZXQsIHRoZW4gY29ycnVwdGlvbiBvZiBhIGdyb3VwIG1lbWJlciByZXZlYWxzIHRo YXQgc2hhcmVkIHNlY3JldCB0byB0aGUgYXR0YWNrZXIgYW5kIG9wZW4gdGhlIHBhdGggZm9yIGFs bCBraW5kcyBvZiBleHBsb2l0YXRpb24uIEluIHdoYXQgc2Vuc2UgaXMgdGhlICZxdW90O3NlbGZp ZSZxdW90OyBhdHRhY2sgZGlmZmVyZW50IGZyb20gdGhhdCBnZW5lcmljDQogdGhyZWF0PzxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+LS0gQ2hyaXN0aWFuIEh1 aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PlRMUyBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiPlRMU0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RscyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRhY2htZW50SGVhZGVyIj48L2Zp ZWxkc2V0Pg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KPGEg Y2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyI+VExTQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPg0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_83d858dae180029be6a158778948f811ericssoncom_-- From nobody Fri Oct 11 05:48:46 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09971120088 for ; Fri, 11 Oct 2019 05:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dNHZt8UJZ7A0 for ; Fri, 11 Oct 2019 05:48:40 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30057.outbound.protection.outlook.com [40.107.3.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DB1120019 for ; Fri, 11 Oct 2019 05:48:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FAXBPaZtMn2a1YHfxSuvdbQaopPkz8wEyRDTOpmUOLJa7Rd06OG5C6GXo/19pum8WuoG2irN1WOyIbDuy3rwacHJdqLlBPo0ucYdKeRTsMjdcg7v4uIMK7Gq5hUtBMRgtiyrK+CydySLfZwkixfyGf3K5YKxZOvDuZnZ3zEbxb4ATZVvph/bCl0K3IrIQhsPX+Le1O3xiwIS8CW0mOq0I50UDBaGL4et9WAjbTAopZL50FzIIjFPLy6LWoKs0kKCLyOJwc/LlLgBpIC5ZKhHI+r6rSH9XAb4+nja4DRbrT4vgCa7d6P1um5vCKEA4iiLQt0tqrPolXeXpoOLduUMKA== 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=nGk7/oi7aJS6RcnaSzC/Bo+lRqUuV/m1vmIdyD1ib4Q=; b=RPWPdbQjry90S+2BtjxP3OemOpqL5tyckGEHjMIoe21Z41EmaRuHvZHlZ4pXTufOVLU8xWyme1TtPCfaRH1QkJ4RdATLw/bhHSdgzkoxr8sUwrQbSM2rhrpr2uR8LzvZPdjYjdl8fEihZ2V6WwENxtcz0WW3OEa210eW6ih1MjHyMw1fGgRqtChYwBI5lI+DvWTDELTGycriXJZywOIa+8txKch6LVjeQl+llpJcFXtcpC8zQD8u4ACVECOH1ZHq2gDWoGpRqSomys4K8ZdJNQ0aVLfNx0ublHw93/fchUBSgmexVctUJceBhiG8DUk/qh+OQVL777YuE5d1MuGBKQ== 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=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nGk7/oi7aJS6RcnaSzC/Bo+lRqUuV/m1vmIdyD1ib4Q=; b=m09GOXJjWM02YoM9SiqRH4LCZlX7VpM1KtD1TXxIPX9OwBBo5NWoHkQ9ftNhqVugavYBvAcc4xieXOQXmz+YLCFo4jxJkX5pNinFLByMeJ33hNKLsa+z5xrVn0jawW1njFhwx8yKK5oocC7PDCpYO3FD0NJwMQzIr9FRS5o6TvU= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4316.eurprd07.prod.outlook.com (20.176.168.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Fri, 11 Oct 2019 12:48:34 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2347.021; Fri, 11 Oct 2019 12:48:34 +0000 From: John Mattsson To: Mohit Sethi M , Christopher Wood , Mohit Sethi M , "TLS@ietf.org" Thread-Topic: [TLS] Selfie attack Thread-Index: AQHVfb7LOQnBEvPvDUirCjFHsuP0MadQ9FsAgARv9oCAACYaAA== Date: Fri, 11 Oct 2019 12:48:34 +0000 Message-ID: <80FA66B9-C275-4BED-93CF-C70CA42E3A1C@ericsson.com> References: <964aab95-1a42-df82-e8e4-cf7ee15ba0f8@ericsson.com> <896F89B2-37D0-4674-881D-FB9FE4874978@ericsson.com> <90ddc116-f5d9-4b22-8b80-e31835e09f10@www.fastmail.com> <16d43a2e-7995-5036-5a67-649b360be497@ericsson.com> In-Reply-To: <16d43a2e-7995-5036-5a67-649b360be497@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [192.176.1.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f124d0da-cf42-4beb-5d4d-08d74e495437 x-ms-traffictypediagnostic: HE1PR07MB4316:|HE1PR07MB4316: x-ms-exchange-purlcount: 8 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0187F3EA14 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(396003)(346002)(39860400002)(53754006)(199004)(189003)(13464003)(76116006)(64756008)(66446008)(66556008)(5660300002)(91956017)(229853002)(478600001)(66946007)(110136005)(30864003)(14454004)(86362001)(8676002)(256004)(316002)(36756003)(14444005)(7736002)(966005)(58126008)(81166006)(81156014)(6512007)(6116002)(3846002)(102836004)(6306002)(53546011)(6506007)(2501003)(26005)(2906002)(66476007)(25786009)(99286004)(76176011)(6246003)(71190400001)(2616005)(476003)(446003)(33656002)(486006)(44832011)(8936002)(11346002)(186003)(71200400001)(6486002)(66066001)(6436002)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4316; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JSIMFdQy2gNq6xll1UEYejNzger6sDdHZvVUrms4ZQoCSOv1rt/hfWJ3FA1jOxDiCC0OPRyPOFebjrh6VSzj3Peo4Df7BLibdvc0tmOVOG2/fUOfWd35MinTcpJWek9laY1xOCeOeuF8S2rpVSXzUOkQU9a1yroeigA62K8a95tvJK9THQ5Duq9YnWGapqaL6ZnBp04H5nMlQx1qfxZioFhKARpkQ0YwYJAV89zsT9G1bNs4c/qJaLx+lVv9yEdg0GANePeS8QiqDAh+gKJRkWPYiMTbM1fY0sPBGU1H5dapX1aEIZ0BYSk99eO3Dwsn9DO5uyHjMkscBuIZB7wMppU/m8Tfzdduszb7sJQHU7VdtZAfd7qQ/8AwStdc0Eu4C4ua3YSKhfU0rw2lNNaNDkIKNXtH9Nu/5jCpoS7+ojFxF+R/0zMtOnv35BHbfMbGzDDUFpcmuo0p4jE81kXoag== Content-Type: text/plain; charset="utf-8" Content-ID: <05D848505E165A40B40BB8DF632AC080@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f124d0da-cf42-4beb-5d4d-08d74e495437 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2019 12:48:34.7688 (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: OI8FLvEraK+N8MNiY2H96zbP6uql6ADdtXa3uMhGA/ZGZxMRjHs4A8CTsCQs/zUNV7mCNfEcXfgBe/i/76i9X6F0C/RsJWi+QQHoUAEGmtE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4316 Archived-At: Subject: Re: [TLS] Selfie attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 12:48:44 -0000 SSB0aGluayB0aGluZ3MgbWl0aWdhdGluZyB0aGUgU2VsZmllIGF0dGFjayBzaG91bGQgYmUgZG9u ZSBpbiBhbiBlcnJhdGEgdG8gUkZDIDg0NDYgb3IgaW4gYSBkcmFmdCB1cGRhdGluZyBSRkMgODQ0 Ni4gSWYgZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWltcG9ydGVyIGlzIHRoZSBtaXRpZ2F0 aW9uIGFnYWluc3Qgc2VsZmllIGF0dGFja3MgSSB0aGluayBpdCBuZWVkcyB0byB1cGRhdGUgUkZD IDg0NDYuDQoNCkpvaG4NCg0K77u/LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRM UyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNb2hpdCBTZXRoaSBNIDxtb2hp dC5tLnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPg0KRGF0ZTogRnJpZGF5LCAx MSBPY3RvYmVyIDIwMTkgYXQgMTQ6MzINClRvOiBDaHJpc3RvcGhlciBXb29kIDxjYXdAaGVhcGlu Z2JpdHMubmV0PiwgTW9oaXQgU2V0aGkgTSA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+LCAi VExTQGlldGYub3JnIiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFNlbGZpZSBh dHRhY2sNCg0KICAgIEhpLA0KICAgIA0KICAgIEkgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCBmb3Ig dGhlIGRyYWZ0IHRvIGltcHJvdmUgdGhlIHNlY3Rpb24gb24gDQogICAgYWRkcmVzc2luZyBzZWxm aWUgYXR0YWNrcy4gRm9yIHRoZSBiZW5lZml0IG9mIHRoZSBsaXN0LCBoZXJlIGlzIHRoZSANCiAg ICBwcm9wb3NlZCB0ZXh0Og0KICAgIA0KICAgID4gVGhlIFRMUyBleHRlcm5hbCBQU0sgYXV0aGVu dGljYXRpb24gbWFrZXMgdGhlIGltcGxpY2l0IGFzc3VtcHRpb24gdGhhdCANCiAgICA+IGVhY2gg UFNLIGlzIGtub3duIG9ubHkgdG8gb25lIGNsaWVudCBhbmQgb25lIHNlcnZlciwgd2hpY2ggZG8g bm90IA0KICAgID4gc3dpdGNoIHJvbGVzIHdpdGggdGhlIHNhbWUgUFNLLg0KICAgID4NCiAgICA+ IElmIG11bHRpcGxlIGNsaWVudHMgb3IgbXVsdGlwbGUgc2VydmVycyBzaGFyZSBhIFBTSywgVExT IG9ubHkgDQogICAgPiBhdXRoZW50aWNhdGVzIHRoZSBlbnRpcmUgZ3JvdXAuIE5vdCBvbmx5IGNh biBhIGNvbXByb21pc2VkIGdyb3VwIA0KICAgID4gbWVtYmVyIGltcGVyc29uYXRlIGFub3RoZXIg Z3JvdXAgbWVtYmVyLCBidXQgYSBtYWxpY2lvdXMgbm9uLW1lbWJlciANCiAgICA+IGNhbiByZXJv dXRlIGhhbmRzaGFrZXMgYmV0d2VlbiBob25lc3QgZ3JvdXAgbWVtYmVycyB0byBjb25uZWN0IHRo ZW0gaW4gDQogICAgPiB1bmludGVuZGVkIHdheXMuIFRoaXMgcmVyb3V0aW5nIGlzIGEgdHlwZSBv ZiBpZGVudGl0eSBtaXNiaW5kaW5nIA0KICAgID4gYXR0YWNrIFtLcmF3Y3p5a11bU2V0aGldLg0K ICAgID4NCiAgICA+IFNlbGZpZSBhdHRhY2sgW1NlbGZpZV0gaXMgYSBzcGVjaWFsIGNhc2Ugb2Yg dGhlIHJlcm91dGluZyBhdHRhY2sgDQogICAgPiBhZ2FpbnN0IGEgZ3JvdXAgbWVtYmVyIHRoYXQg Y2FuIGFjdCBib3RoIGFzIFRMUyBzZXJ2ZXIgYW5kIGNsaWVudC4gSW4gDQogICAgPiB0aGUgc2Vs ZmllIGF0dGFjaywgYSBtYWxpY2lvdXMgbm9uLW1lbWJlciByZXJvdXRlcyBhIGNvbm5lY3Rpb24g ZnJvbSANCiAgICA+IHRoZSBjbGllbnQgdG8gdGhlIHNlcnZlciBvbiB0aGUgc2FtZSBlbmRwb2lu dC4NCiAgICA+DQogICAgPiBSZXJvdXRpbmcgYW5kIHNlbGZpZSBhdHRhY2tzIGNhbiBiZSBkZXRl Y3RlZCBieSBiaW5kaW5nIHRoZSBUTFMgDQogICAgPiBoYW5kc2hha2UgdG8gZ2xvYmFsbHkgdW5p cXVlIG5vZGUgaWRlbnRpZmllcnMgdXNpbmcgdGhlIGZvbGxvd2luZyANCiAgICA+IGNvbnRleHQg c3RyaW5nOg0KICAgID4NCiAgICA+IHN0cnVjdCB7DQogICAgPiAgICAgICAgb3BhcXVlIGNsaWVu dF9pZDwwLi4yXjE2LTE+Ow0KICAgID4gICAgICAgIG9wYXF1ZSBzZXJ2ZXJfaWQ8MC4uMl4xNi0x PjsNCiAgICA+ICAgICAgfSBDb250ZXh0Ow0KICAgID4NCiAgICA+IFdoZW4gdGhlIFBTSyBpcyBz aGFyZWQgYnkgb25seSB0d28gZW5kcG9pbnRzLCBpdCBpcyBub3QgbmVjZXNzYXJ5IHRvIA0KICAg ID4ga25vdyB0aGUgaWRlbnRpZmllcihzKSBvZiB0aGUgb3RoZXIgZW5kcG9pbnQuIEluc3RlYWQs IGl0IGlzIA0KICAgID4gc3VmZmljaWVudCB0byBjaGVjayB0aGF0IHRoZSBpZGVudGlmaWVyIG9m IHRoZSBvdGhlciBlbmRwb2ludCBpbiANCiAgICA+IGNvbnRleHQgaXMgbm90IGVxdWFsIHRvIGFu eSBvZiBvbmXigJlzIG93biBpZGVudGlmaWVycy4gVG8gc2ltcGxpZnkgDQogICAgPiBpbXBsZW1l bnRhdGlvbiBvZiB0aGlzIGNoZWNrLCBpdCBpcyBSRUNPTU1FTkRFRCB0aGF0IGVhY2ggZW5kcG9p bnQgDQogICAgPiBzZWxlY3RzIG9uZSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllciBhbmQgdXNl cyBpdCBpbiBhbGwgUFNLIA0KICAgID4gaGFuZHNoYWtlcy4gVGhlIHVuaXF1ZSBpZGVudGlmaWVy IGNhbiwgZm9yIGV4YW1wbGUsIGJlIG9uZSBvZiBpdHMgTUFDIA0KICAgID4gYWRkcmVzc2VzIG9y IGEgMzItYnl0ZSByYW5kb20gbnVtYmVyLg0KICAgID4NCiAgICA+IFdoZW4gdGhlIFBTSyBpcyBh IGdyb3VwIGtleSwgdGhlIGNvbXBhcmlzb24gd2l0aCBvbmXigJlzIG93biBpZGVudGlmaWVycyAN CiAgICA+IHdpbGwgb25seSBwcmV2ZW50IHNlbGZpZSBhdHRhY2tzIGJ1dCBub3QgbWFsaWNpb3Vz IHJlcm91dGluZyBvZiB0aGUgDQogICAgPiBjb25uZWN0aW9uIHRvIGFub3RoZXIgZ3JvdXAgbWVt YmVyLiBUbyBwcmV2ZW50IG1hbGljaW91cyByZXJvdXRpbmcgaW4gDQogICAgPiBncm91cHMsIGVh Y2ggZW5kcG9pbnQgbmVlZHMgdG8ga25vdyB0aGUgaWRlbnRpZmllciBvZiB0aGUgb3RoZXIgDQog ICAgPiBlbmRwb2ludCB3aXRoIHdoaWNoIHRoZXkgd2FudCB0byBjb25uZWN0IGFuZCBjb21wYXJl IGl0IHdpdGggdGhlIG90aGVyIA0KICAgID4gZW5kcG9pbnTigJlzIGlkZW50aWZpZXIgaW4gY29u dGV4dC4gT2YgY291cnNlLCB0aGlzIG9ubHkgcHJldmVudHMgDQogICAgPiBhdHRhY2tzIGJ5IG5v bi1tZW1iZXJzOyB0aGUgZW5kcG9pbnRzIHRoYXQgc2hhcmUgdGhlIGdyb3VwIGtleSBjYW4gDQog ICAgPiBhbHdheXMgaW1wZXJzb25hdGUgZWFjaCBvdGhlci4NCiAgICANCiAgICAtLU1vaGl0DQog ICAgDQogICAgT24gMTAvOC8xOSA3OjQ2IFBNLCBDaHJpc3RvcGhlciBXb29kIHdyb3RlOg0KICAg ID4gT24gVHVlLCBPY3QgOCwgMjAxOSwgYXQgMjo1NSBBTSwgTW9oaXQgU2V0aGkgTSB3cm90ZToN CiAgICA+PiAgIA0KICAgID4+IEhpIENocmlzLA0KICAgID4+DQogICAgPj4gRm9yIHRoZSBiZW5l Zml0IG9mIHRoZSBsaXN0LCBsZXQgbWUgc3VtbWFyaXplIHRoYXQgdGhlIHNlbGZpZSBhdHRhY2sg aXMNCiAgICA+PiBvbmx5IHJlbGV2YW50IHdoZXJlIG11bHRpcGxlIHBhcnRpZXMgc2hhcmUgdGhl IHNhbWUgUFNLIGFuZCB1c2UgdGhlDQogICAgPj4gc2FtZSBQU0sgZm9yIG91dGdvaW5nIGFuZCBp bmNvbWluZyBjb25uZWN0aW9ucy4gVGhlc2Ugc2l0dWF0aW9ucyBhcmUNCiAgICA+PiByYXRoZXIg cmFyZSwgYnV0IEkgYWNjZXB0IHRoYXQgVExTIGlzIHdpZGVseSB1c2VkIChhbmQgc29tZXRpbWVz DQogICAgPj4gbWlzdXNlZCkgaW4gbWFueSBwbGFjZXMuDQogICAgPj4NCiAgICA+PiBUaGUgU2Vs ZmllIGF0dGFjayBvbmx5IGhhcHBlbnMgd2hlbiBhbiBlbnRpdHkgd2l0aCB0aGUgUFNLIGFjdHMN CiAgICA+PiBtYWxpY2lvdXNseS4gU28gSSB0aGluayB0aGUgZmFjdCB0aGF0IHlvdSB3cml0ZSBp biB0aGUgZHJhZnQ6ICJlYWNoDQogICAgPj4gbm9kZSBtdXN0IGJlIHRydXN0ZWQgbm90IHRvIGlt cGVyc29uYXRlIGFub3RoZXIgbm9kZSdzIHJvbGUiIGRvZXMgbm90DQogICAgPj4gdGFrZSBpbnRv IGFjY291bnQgdGhhdCB0aGVyZSBtdXN0IGJlIGEgbWFsaWNpb3VzIG5vZGUgZm9yIHRoZSBzZWxm aWUNCiAgICA+PiBhdHRhY2sgdG8gaGFwcGVuIGluIHRoZSBmaXJzdCBwbGFjZS4NCiAgICA+Pg0K ICAgID4+IERydWNrZXIgYW5kIEd1ZXJvbidzIHBhcGVyIHJlY29tbWVuZHMgdGhhdCAiZXZlcnkg cGFydGljaXBhdGluZyBwYXJ0eQ0KICAgID4+IGdldHMgKGR1cmluZyB0aGUgc2V0dXAgb2YgdGhl IG5ldHdvcmspIGEgdW5pcXVlIGlkZW50aXR5IiBhbmQgInRoZQ0KICAgID4+IGNsaWVudCBhbmQg dGhlIHNlcnZlciBtdXN0IHZlcmlmeSB0aGUgdmFsaWRpdHkgb2YgdGhlIGNsYWltZWQNCiAgICA+ PiBpZGVudGl0aWVzLiIuIFRoZSByZWFsaXR5IGhvd2V2ZXIgaXMgdGhhdCBpbiBtb3N0IGdyb3Vw IFBTSyBzY2VuYXJpb3MsDQogICAgPj4gdGhlIG5vZGVzIGRvbid0IGhhdmUgYW55IHN0cm9uZyBp ZGVudGl0aWVzIHRoYXQgY2FuIGJlIHZlcmlmaWVkLg0KICAgID4+DQogICAgPj4gV2hhdCB5b3Ug c2hvdWxkIGluc3RlYWQgKG9yIGFkZGl0aW9uYWxseSkgc2F5IGluIHRoZSB0ZXh0IGlzIHRoYXQg YQ0KICAgID4+IG5vZGUgc2hvdWxkIGNoZWNrIHRoYXQgdGhlIGNsaWVudF9tYWMgYW5kIHNlcnZl cl9tYWMgKG9yIGFueSBvdGhlcg0KICAgID4+IGlkZW50aXRpZXMgdXNlZCkgKmFyZSBuZXZlciB0 aGUgc2FtZSouDQogICAgPiBUaGlzIHNlZW1zIGltcGxpY2l0IGluIHRoZSB0ZXh0IGFzIHdyaXR0 ZW4uIENvdWxkIEkgYXNrIHlvdSB0byBzdWJtaXQgYSBQUiBhZ2FpbnN0IFsxXSB0byBjbGFyaWZ5 Pw0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+IENocmlzDQogICAgPg0KICAgID4gWzFdIGh0 dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdXJsP2s9YmI2OGZiZTctZTdlMmQ5MjgtYmI2OGJi N2MtMGNjNDdhZDkzZWE0LWRkYWIzMzQyN2I0NDcxYzkmcT0xJnU9aHR0cHMlM0ElMkYlMkZnaXRo dWIuY29tJTJGdGxzd2clMkZkcmFmdC1pZXRmLXRscy1leHRlcm5hbC1wc2staW1wb3J0ZXINCiAg ICA+DQogICAgPj4gV2l0aG91dCB0aGlzIGNoZWNrLCB0aGUgc2VsZmllDQogICAgPj4gYXR0YWNr IHdvdWxkIHN0aWxsIGJlIHBvc3NpYmxlLiBBbmQgYXQgbGVhc3QgdGhpcyBkb2VzIG5vdCByZXF1 aXJlDQogICAgPj4gc3Ryb25nIGlkZW50aXR5IHZlcmlmaWNhdGlvbiBmb3IgcHJldmVudGluZyBz ZWxmaWUgYXR0YWNrcy4NCiAgICA+Pg0KICAgID4+IC0tTW9oaXQNCiAgICA+Pg0KICAgID4+IE9u IDEwLzUvMTkgMjo0MSBQTSwgQ2hyaXN0b3BoZXIgV29vZCB3cm90ZToNCiAgICA+Pj4gSGkgRmVu ZywNCiAgICA+PiBGb3Igd2hhdCBpdCdzIHdvcnRoLCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhl IFBTSyBpbXBvcnRlcnMgZHJhZnQNCiAgICA+PiBpbmNsdWRlcyBhICJjb250ZXh0IiBmaWVsZCBp bnRvIHdoaWNoIGlkZW50aXR5IGluZm9ybWF0aW9uIGNhbiBiZSBmZWQ6DQogICAgPj4NCiAgICA+ PiAgICAgDQogICAgPj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxz LWV4dGVybmFsLXBzay1pbXBvcnRlci0wMSNhcHBlbmRpeC1CDQogICAgPj4NCiAgICA+PiBCZXN0 LA0KICAgID4+IENocmlzDQogICAgPj4NCiAgICA+PiBPbiBUdWUsIFNlcCAyNCwgMjAxOSwgYXQg OToxOSBBTSwgSGFvLCBGZW5nIHdyb3RlOg0KICAgID4+Pj4gSGkgSm9obiwNCiAgICA+PiBSZWZs ZWN0aW9uIGF0dGFja3MgYXJlIGluZGVlZCBvbGRlciwgYnV0IHRoZSBzZWxmaWUgYXR0YWNrIGlz IGEgYml0DQogICAgPj4gZGlmZmVyZW50LiBJdCdzIGFjdHVhbGx5IGEgdmFyaWFudCBvZiB0aGUg dW5rbm93biBrZXkgc2hhcmUgYXR0YWNrLiBBDQogICAgPj4gdHlwaWNhbCBleGFtcGxlIG9mIHRo ZSBVS1MgYXR0YWNrIGlzIHRoZSBvbmUgcmVwb3J0ZWQgb24gTVFWIGJ5IEthbGlza2kNCiAgICA+ PiBpbiAyMDAxIChzZWUgIkFuIHVua25vd24ga2V5LXNoYXJlIGF0dGFjayBvbiB0aGUgTVFWIGtl eSBhZ3JlZW1lbnQNCiAgICA+PiBwcm90b2NvbCIgaW4gQUNNIFRJU1NFQyAyMDAxKS4gSW4gdGhh dCBleGFtcGxlLCB0aGUgYWR2ZXJzYXJ5IHBsYXlzDQogICAgPj4gbWVzc2FnZSBiZXR3ZWVuIHR3 byB1c2VycyB0byBjYXVzZSBjb25mdXNpb24gaW4gdGhlIGlkZW50aXR5LCBidXQgaW4NCiAgICA+ PiBTZWxmaWUsIHRoZSBhZHZlcnNhcnkgcGxheXMgbWVzc2FnZSB3aXRoIG9ubHkgb25lIHVzZXIg YW5kIHVzZXMgYW5vdGhlcg0KICAgID4+IGluc3RhbmNlIG9mIHRoZSB1c2VyIHRvIGNhdXNlIGNv bmZ1c2lvbiBpbiB0aGUgaWRlbnRpdHkuIFdoZW4gd2UNCiAgICA+PiByZXBvcnRlZCB0aGlzIHZh cmlhbnQgb2YgVUtTIGluIFszXSwgd2Ugd2VyZSBub3QgYXdhcmUgb2YgYW55dGhpbmcgbGlrZQ0K ICAgID4+IHRoYXQgaW4gdGhlIGxpdGVyYXR1cmUuDQogICAgPj4NCiAgICA+PiBDaGVlcnMsDQog ICAgPj4gRmVuZw0KICAgID4+DQogICAgPj4gT24gMjQvMDkvMjAxOSwgMTY6MTcsICJKb2huIE1h dHRzc29uIiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+IHdyb3RlOg0KICAgID4+DQogICAg Pj4gICAgICBIaSwNCiAgICA+PiAgICAgIA0KICAgID4+ICAgICAgSSB0aGluayB0aGVzZSByZWZs ZWN0aW9uIGF0dGFja3MgYXJlIG11Y2ggb2xkZXIgdGhhbiB0aGlzLiBJIHF1aWNrDQogICAgPj4g c2VhcmNoIGZvciByZWZsZWN0aW9uIGF0dGFjayBzZWN1cml0eSBwcm90b2NvbCBnaXZlcyBhIGxv dCBvZiBvbGQNCiAgICA+PiByZXN1bHRzLCBUaGUgZGVzY3JpcHRpb24gb2YgcmVmbGVjdGlvbiBh dHRhY2sgaW4gdGhlIGZvbGxvd2luZyBsZWN0dXJlDQogICAgPj4gbWF0ZXJpYWwgZnJvbSAyMDA5 IGxvb2tzIGp1c3QgbGlrZSB0aGUgInNlbGZpZSBhdHRhY2siIG9uIFRMUyAxLjMNCiAgICA+PiAg ICAgIGh0dHA6Ly93d3cuY3MuYmhhbS5hYy51ay9+dHBjL2N3aS9UZWFjaGluZy9GaWxlcy9MZWN0 dXJlNF82dXAucGRmDQogICAgPj4gICAgICANCiAgICA+PiAgICAgIFdpdGggbXVsdGlwbGUgc2Vj dGlvbnMgdGhlcmUgYXJlIG90aGVyIHRoaW5ncyB0aGF0IGNoYW5nZSBhcyB3ZWxsLg0KICAgID4+ IElmIHR3byBub2RlcyB1bmludGVudGlvbmFsbHkgaW5pdGlhdGUgc2ltdWx0YW5lb3VzIENsaWVu dEhlbGxvIHRvIGVhY2gNCiAgICA+PiBvdGhlciwgZXZlbiBpZiB0aGV5IG9ubHkgd2FudCBhIHNp bmdsZSBzZWN1cmUgY29ubmVjdGlvbiAoSSBoYXZlIHNlZW4NCiAgICA+PiBsaXZlIHN5c3RlbXMg d2hlcmUgdGhpcyBoYXBwZW5zIGluIHByYWN0aWNlKSwgYW4gYXR0YWNrZXIgY2FuIHNlbGVjdA0K ICAgID4+IHdoaWNoIENsaWVudEhlbGxvIHRvIGJsb2NrIChlLmcuIHRoZSBvbmUgd2l0aCB0aGUg c3Ryb25nZXN0DQogICAgPj4gY3J5cHRvZ3JhcGhpYyBwYXJhbWV0ZXJzKS4gVGhlIGZvbGxvd2lu ZyBzZWN1cml0eSBwcm9wZXJ0eSB3b3VsZCB0aGVuDQogICAgPj4gbm8gbG9uZ2VyIGhvbGQgOg0K ICAgID4+ICAgICAgDQogICAgPj4gICAgICAgICJEb3duZ3JhZGUgcHJvdGVjdGlvbjogIFRoZSBj cnlwdG9ncmFwaGljIHBhcmFtZXRlcnMgc2hvdWxkIGJlIHRoZQ0KICAgID4+ICAgICAgICAgICAg c2FtZSBvbiBib3RoIHNpZGVzIGFuZCBzaG91bGQgYmUgdGhlIHNhbWUgYXMgaWYgdGhlIHBlZXJz IGhhZCBiZWVuDQogICAgPj4gICAgICAgICAgICBjb21tdW5pY2F0aW5nIGluIHRoZSBhYnNlbmNl IG9mIGFuIGF0dGFjayINCiAgICA+PiAgICAgIA0KICAgID4+ICAgICAgKEkgaGF2ZSBub3QgbG9v a2VkIGF0IHdoYXQgdGhlIGRlZmluaXRpb25zIGluIFtCQkZHS1oxNl0gc2F5KS4NCiAgICA+PiAg ICAgIA0KICAgID4+ICAgICAgQ2hlZXJzLA0KICAgID4+ICAgICAgSm9obg0KICAgID4+ICAgICAg DQogICAgPj4gICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4+ICAgICAgRnJv bTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJIYW8sIEZlbmciDQog ICAgPj4+PiA8RmVuZy5IYW9Ad2Fyd2ljay5hYy51az4NCiAgICA+PiAgICAgIERhdGU6IFR1ZXNk YXksIDI0IFNlcHRlbWJlciAyMDE5IGF0IDE2OjA5DQogICAgPj4gICAgICBUbzogTW9oaXQgU2V0 aGkgTSA8bW9oaXQubS5zZXRoaT00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4sDQogICAg Pj4gIk93ZW4gRnJpZWwgKG9mcmllbCkiIDxvZnJpZWxAY2lzY28uY29tPiwgSm9uYXRoYW4gSG95 bGFuZA0KICAgID4+Pj4gPGpvbmF0aGFuLmhveWxhbmRAZ21haWwuY29tPg0KICAgID4+ICAgICAg Q2M6ICJUTFNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+DQogICAgPj4gICAgICBTdWJqZWN0OiBS ZTogW1RMU10gU2VsZmllIGF0dGFjayB3YXMgUmU6IERpc3Rpbmd1aXNoaW5nIGJldHdlZW4NCiAg ICA+PiBleHRlcm5hbC9yZXN1bXB0aW9uIFBTS3MNCiAgICA+PiAgICAgIA0KICAgID4+ICAgICAg ICAgIA0KICAgID4+ICAgICAgICAgIE9uIDIzLzA5LzIwMTksIDE4OjUwLCAiVExTIG9uIGJlaGFs ZiBvZiBNb2hpdCBTZXRoaSBNIg0KICAgID4+Pj4gPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZg0KICAgID4+IG1vaGl0Lm0uc2V0aGk9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5v cmc+DQogICAgPj4gPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ29uYmVoYWxmb2Ztb2hpdC5t LnNldGhpPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiB3cm90ZToNCiAgICA+PiAgICAg ICAgICANCiAgICA+PiAgICAgICAgICAgICAgSGkgYWxsLA0KICAgID4+ICAgICAgICAgICAgICAN CiAgICA+PiAgICAgICAgICAgICAgT24gdGhlIHRvcGljIG9mIGV4dGVybmFsIFBTS3MgaW4gVExT IDEuMywgSSBmb3VuZCBhDQogICAgPj4gcHVibGljYXRpb24gb24gdGhlDQogICAgPj4gICAgICAg ICAgICAgIFNlbGZpZSBhdHRhY2s6DQogICAgPj4+PiBodHRwczovL3Byb3RlY3QyLmZpcmVleWUu Y29tL3VybD9rPWRkNDMyZjEzLTgxYzllNWFkLWRkNDM2Zjg4LTg2OWExN2I1YjIxYi1kYzZjNmYw YTVkZDIxZmFmJnE9MSZ1PWh0dHBzJTNBJTJGJTJGZXByaW50LmlhY3Iub3JnJTJGMjAxOSUyRjM0 Nw0KICAgID4+ICAgICAgICAgICAgICANCiAgICA+PiAgICAgICAgICAgICAgUGVyaGFwcyB0aGlz IHdhcyBhbHJlYWR5IGRpc2N1c3NlZCBvbiB0aGUgbGlzdC4gSSB0aG91Z2h0DQogICAgPj4gdGhh dCBzaGFyaW5nDQogICAgPj4gICAgICAgICAgICAgIGl0IGFnYWluIHdvdWxkbid0IGh1cnQgd2hp bGUgd2UgZGlzY3VzcyBob3cgc2VydmVycw0KICAgID4+IGRpc3Rpbmd1aXNoIGJldHdlZW4NCiAg ICA+PiAgICAgICAgICAgICAgZXh0ZXJuYWwgYW5kIHJlc3VtcHRpb24gUFNLcy4NCiAgICA+PiAg ICAgICAgICAgICAgDQogICAgPj4gICAgICAgICAgSSBqdXN0IHJlYWQgdGhlIHBhcGVyIHdpdGgg aW50ZXJlc3QuIEl0IG9jY3VycyB0byBtZSB0aGF0IHRoZQ0KICAgID4+IHNlbGZpZSBhdHRhY2sg aXMgY29uc2lzdGVudCB3aXRoIHRoZSAiaW1wZXJzb25hdGlvbiBhdHRhY2siIHRoYXQgd2UNCiAg ICA+PiByZXBvcnRlZCBvbiBTUEVLRSBpbiAyMDE0OyBzZWUgU2VjIDQuMSBbMV0gYW5kIHRoZSB1 cGRhdGVkIHZlcnNpb24gd2l0aA0KICAgID4+IGRldGFpbHMgb24gaG93IFNQRUtFIGlzIHJldmlz ZWQgaW4gSVNPL0lFQyAxMTc3MC00IFsyXS4gVGhlIHNhbWUgYXR0YWNrDQogICAgPj4gY2FuIGJl IHRyYWNlZCBiYWNrIHRvIDIwMTAgaW4gWzNdIHdoZXJlIGEgIndvcm0taG9sZSBhdHRhY2siIChG aWcuIDUsDQogICAgPj4gWzNdKSBpcyByZXBvcnRlZCBvbiB0aGUgc2VsZi1jb21tdW5pY2F0aW9u IG1vZGUgb2YgSE1RVi4gVGhlIGVzc2VuY2Ugb2YNCiAgICA+PiB0aGVzZSBhdHRhY2tzIGlzIHRo ZSBzYW1lOiBCb2IgdHJpY2tzIEFsaWNlIGludG8gdGhpbmtpbmcgdGhhdCBzaGUgaXMNCiAgICA+ PiB0YWxraW5nIHRvIGF1dGhlbnRpY2F0ZWQgQm9iLCBidXQgc2hlIGlzIGFjdHVhbGx5IHRhbGtp bmcgdG8gaGVyc2VsZi4NCiAgICA+PiBJbiBbM10sIHdlIGV4cGxhaW5lZCB0aGF0IHRoZSBhdHRh Y2sgd2FzIG1pc3NlZCBmcm9tIHRoZSAic2VjdXJpdHkNCiAgICA+PiBwcm9vZnMiIGFzIHRoZSBw cm9vZnMgZGlkbid0IGNvbnNpZGVyIG11bHRpcGxlIHNlc3Npb25zLg0KICAgID4+ICAgICAgICAg IA0KICAgID4+ICAgICAgICAgIFRoZSBjb3VudGVybWVhc3VyZSB3ZSBwcm9wb3NlZCBpbiBbMS0z XSB3YXMgdG8gZW5zdXJlIHRoZSB1c2VyDQogICAgPj4gaWRlbnRpdHkgaXMgdW5pcXVlIGluIGtl eSBleGNoYW5nZSBwcm9jZXNzZXM6IGluIGNhc2Ugb2YgbXVsdGlwbGUNCiAgICA+PiBzZXNzaW9u cyB0aGF0IG1heSBjYXVzZSBjb25mdXNpb24gaW4gdGhlIHVzZXIgaWRlbnRpdHksIGFuIGV4dGVu c2lvbg0KICAgID4+IHNob3VsZCBiZSBhZGRlZCB0byB0aGUgdXNlciBpZGVudGl0eSB0byBkaXN0 aW5ndWlzaCB0aGUgaW5zdGFuY2VzLiBUaGUNCiAgICA+PiB1bmRlcmx5aW5nIGludHVpdGlvbiBp cyB0aGF0IG9uZSBzaG91bGQga25vdyAidW5hbWJpZ3VvdXNseSIgd2hvbSB0aGV5DQogICAgPj4g YXJlIGNvbW11bmljYXRpbmcgd2l0aCwgYW5kIHBlcmZvcm0gYXV0aGVudGljYXRpb24gYmFzZWQg b24gdGhhdC4gVGhlDQogICAgPj4gZGlzY292ZXJ5IG9mIHRoaXMgdHlwZSBvZiBhdHRhY2tzIGFu ZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gYXJlDQogICAgPj4gaW5zcGlyZWQgYnkgdGhlICJleHBs aWNpdG5lc3MgcHJpbmNpcGxlIiAoUm9zcyBBbmRlcnNvbiBhbmQgUm9nZXINCiAgICA+PiBOZWVk aGFtLCBDcnlwdG8nOTUpLCB3aGljaCBzdGF0ZXMgdGhlIGltcG9ydGFuY2Ugb2YgYmVpbmcgZXhw bGljaXQgb24NCiAgICA+PiB1c2VyIGlkZW50aXRpZXMgYW5kIG90aGVyIGF0dHJpYnV0ZXMgaW4g YSBwdWJsaWMga2V5IHByb3RvY29sOyBhbHNvIHNlZQ0KICAgID4+IFszXS4gSSBob3BlIGl0IG1p Z2h0IGJlIHVzZWZ1bCB0byBwZW9wbGUgd2hvIHdvcmsgb24gVExTIFBTSy4NCiAgICA+PiAgICAg ICAgICANCiAgICA+PiAgICAgICAgICBbMV0NCiAgICA+Pj4+IGh0dHBzOi8vcHJvdGVjdDIuZmly ZWV5ZS5jb20vdXJsP2s9NWE4MjI1MTMtMDYwOGVmYWQtNWE4MjY1ODgtODY5YTE3YjViMjFiLWVi MjYwMTUxZjc4YjA3MTgmcT0xJnU9aHR0cHMlM0ElMkYlMkZlcHJpbnQuaWFjci5vcmclMkYyMDE0 JTJGNTg1LnBkZg0KICAgID4+ICAgICAgICAgIFsyXSBodHRwczovL2FyeGl2Lm9yZy9hYnMvMTgw Mi4wNDkwMA0KICAgID4+ICAgICAgICAgIFszXQ0KICAgID4+Pj4gaHR0cHM6Ly9wcm90ZWN0Mi5m aXJlZXllLmNvbS91cmw/az1kNWJmODhmZi04OTM1NDI0MS1kNWJmYzg2NC04NjlhMTdiNWIyMWIt MGU5YjNiZjU4ZTEwNGYzMiZxPTEmdT1odHRwcyUzQSUyRiUyRmVwcmludC5pYWNyLm9yZyUyRjIw MTAlMkYxMzYucGRmDQogICAgPj4gICAgICAgICAgDQogICAgPj4gICAgICAgICAgDQogICAgPj4g ICAgICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICA+PiAgICAgICAgICBUTFMgbWFpbGluZyBsaXN0DQogICAgPj4gICAgICAgICAgVExTQGll dGYub3JnDQogICAgPj4gICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMNCiAgICA+PiAgICAgICAgICANCiAgICA+PiAgICAgIA0KICAgID4+ICAgICAgDQog ICAgPj4NCiAgICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgID4+IFRMUyBtYWlsaW5nIGxpc3QNCiAgICA+Pj4+IFRMU0BpZXRmLm9yZw0KICAg ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCiAgICA+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+PiBU TFMgbWFpbGluZyBsaXN0DQogICAgPj4+IFRMU0BpZXRmLm9yZw0KICAgID4+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IFRMUyBtYWlsaW5nIGxpc3QNCiAg ICA+IFRMU0BpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90bHMNCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Fri Oct 11 06:24:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6ACF120074 for ; Fri, 11 Oct 2019 06:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyJs3JQ5h8zY for ; Fri, 11 Oct 2019 06:24:10 -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 55BEC120073 for ; Fri, 11 Oct 2019 06:24:10 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id r2so7020886lfn.8 for ; Fri, 11 Oct 2019 06:24:10 -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=GgpTL/1gILWhSVH6odszgGdmag/gWLq5kuoIThKCj6U=; b=oyF8R1msM0X0V1ySfLQcUaR2uKPcrc8g/32WTe1krjJLZQtVid/Un02Wy9C4oAV9Il fHo2bVa0eriyz36GsL81qbbkCtsadTZ9hFNtm7G283wbxqfaern0Evk3xEGk/CTTT+ig f7+K0y2NN/FfIv8V6D5/qyj8qZc9z+yIxtbQXSzTVTtomJUv6p0PgVUOvVG7LvdkyyDx EVUQ0aexvQv1FO8synw7rSl4yipmvyZJgP0JE54R4dO/EIQuV8jjEJFj/yRoFOKFJC8X umyKp9TlDAqFC2TqIo9Pac9mQLg9xz/7jGseOIrRDE4mcZejmXoYZCrFapmLIOF2HLEi W98Q== 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=GgpTL/1gILWhSVH6odszgGdmag/gWLq5kuoIThKCj6U=; b=CIUFhYk4oNfz8fsLvHC1383Io6yj1PFYZ5AHgW7z+rFPKHz04a0cEpZ48DhPqVQkC/ 9XLUqtc38CYxBIeet+GIcJsvyeeFjFJVT1rk5ItwkHOOFQTqEOc9n2SJAqqPJ/yfReNW bxZ33ePqX8hXoNPCTGL89rmsKvsh0Efhi0b1La2E1xTDTKjESn7lu0B9USXiG7shT0sz ejGJN6G0rzWCYiLChjTovd20weZd6DT3ulvbKQYqAo6COZqIkfNzovpoLOlOQMSXN3Hi Mgf1v7sqnXs8NWhbfuHt23xtmrS4lJnskZN50eYvw6v9DezBoD2IFghQWaG/x97xv1pA 5Kow== X-Gm-Message-State: APjAAAVB01PbASXf0a9+hGE5LC/qfRE8JRtj3JZjJuDsjSS94N0BaIdn XNQEfVoBYVSGcTPGgJx74FGroN7/n8beZ4rTFU3C9g== X-Google-Smtp-Source: APXvYqzo7v8hFkPRcsHDH+5jfeNDID4gEY+M2qrhsCHi7C2947D1UiYEsT405bq/WY7l4Xo/2CjeY31V5i+yNx5b/DM= X-Received: by 2002:a19:4a02:: with SMTP id x2mr8229520lfa.17.1570800248546; Fri, 11 Oct 2019 06:24:08 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: From: Eric Rescorla Date: Fri, 11 Oct 2019 06:23:32 -0700 Message-ID: To: Rob Sayre Cc: Martin Thomson , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d3fb080594a26eb5" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 13:24:13 -0000 --000000000000d3fb080594a26eb5 Content-Type: text/plain; charset="UTF-8" On Thu, Oct 10, 2019 at 8:12 PM Rob Sayre wrote: > On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson wrote: > >> On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote: >> > The obvious solution is for the TLS client (i.e. the CDN) to support >> > direct entry of ESNI public keys alongside the IP address. Users who >> > want to be able to rotate their ESNI keys more easily should use a >> > backend identified by a domain name that is distinct from the >> > user-facing origin hostname. >> >> I was about to say the same thing. No need to get fancy. >> > > Isn't that more complicated than sending the SNI in the second client > message, though? > Well, both of these are more complicated than Host header. What's wrong with that? -Ekr > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d3fb080594a26eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Oct 10, 2019 at 8:12 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson <mt@lowentropy.net>= ; wrote:
On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote:
> The obvious solution is for the TLS client (i.e. the CDN) to support <= br> > direct entry of ESNI public keys alongside the IP address. Users who <= br> > want to be able to rotate their ESNI keys more easily should use a > backend identified by a domain name that is distinct from the
> user-facing origin hostname.

I was about to say the same thing.=C2=A0 No need to get fancy.

Isn't that more complicated than sending the SN= I in the second client message, though?
=
Well, both of these are more complicated than Host header. W= hat's wrong with that?

-Ekr


thanks,
Rob=C2=A0
<= /div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d3fb080594a26eb5-- From nobody Fri Oct 11 06:45:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1866C1200A4 for ; Fri, 11 Oct 2019 06:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 dbzQ5dP-b5Z3 for ; Fri, 11 Oct 2019 06:45:19 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 D0BD2120090 for ; Fri, 11 Oct 2019 06:45:19 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id n197so21535448iod.9 for ; Fri, 11 Oct 2019 06:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XV3cGTgQg4k5YAmzAVfU5HhOn+G/lkTE0z3XsBIQMkE=; b=Afd95lUrkcYwNHI6xFuDUTJVDz3EcVi9b/NgC5w41qZ6JYNRP74xDNzl5FT2qqKimt UfHX//F3/IoXaxt3qxuwC/dCEJmI2XKfweJM9Q32cz4Sn8Rw28Wicc0UOdOuxEGA805m TxzfNTn87nX+cGQPDYH/9Oc7FXtgb6Fz5K0n8e7CVQKiV+uZ8n0ZfkvzS8lXVmuZR/D/ NTpibDN4Ou/UzaBdC37bdk/J8+GtxdsQJdNN8Kd5iTyyv7aXNXTbr9Iy1ZL2yXNMwiPx tloRD7+J/l1gQg9C16YijUHFxt5aNDf0K08Z2jOkFRAg7EBqnFrQkPruwyM6rH2QYHuL Z/aA== 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=XV3cGTgQg4k5YAmzAVfU5HhOn+G/lkTE0z3XsBIQMkE=; b=CiBw+pc4cOaoi1J4CcQefGEWSNPtifaPogkPkmqk8xjYYhI7oMVtFn1hyaYcOcFFFd jLayVj3LnswQ71VXtX8DHm4nSPCzZcKb1XPnr8M4M4T1fPV4i4Nuu9zJVDhx5JT42qW4 Nn6CBxK6stnQh1wgtoHcGUp3qZ21W7BQKF2OI5vRmHziad3ILQy9luRJVO4/ha643dmU Az+N8jbQw41wCV56Hl9YaY/2p1I2njapooFWm5JfaTxTQ4xVlxQt062/AN8EGQl9n/tW AcjEhiPQV6GYueVwZii9pNLuHLPEnfxuemNl3BSjD+Er5L/aY6Xwf6ipTx9sbjWVhQA4 9f1g== X-Gm-Message-State: APjAAAXPYMKo3rEOpMuJlrbwXEkmcHXfbWgZvEYu2xRPlKs1pJqGqG4T 1Nylx2u9BlUThi7zMmcriB0eF7E7LjDlizBQYjSZiZm2RCv+9A== X-Google-Smtp-Source: APXvYqyQbx6jPCc+pDnWJ7O4TgTcapIoK3dLs3RUNkBB7WjFz5zVYq0KendzxZnewFo3I1wJdyl6wixkFkvBOusUdH8= X-Received: by 2002:a5d:8f83:: with SMTP id l3mr13793435iol.73.1570801519013; Fri, 11 Oct 2019 06:45:19 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Fri, 11 Oct 2019 20:45:05 +0700 Message-ID: To: Eric Rescorla Cc: Martin Thomson , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008db55a0594a2ba71" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 13:45:22 -0000 --0000000000008db55a0594a2ba71 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 11, 2019 at 8:24 PM Eric Rescorla wrote: > > > On Thu, Oct 10, 2019 at 8:12 PM Rob Sayre wrote: > >> On Fri, Oct 11, 2019 at 5:37 AM Martin Thomson wrote: >> >>> On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote: >>> > The obvious solution is for the TLS client (i.e. the CDN) to support >>> > direct entry of ESNI public keys alongside the IP address. Users who >>> > want to be able to rotate their ESNI keys more easily should use a >>> > backend identified by a domain name that is distinct from the >>> > user-facing origin hostname. >>> >>> I was about to say the same thing. No need to get fancy. >>> >> >> Isn't that more complicated than sending the SNI in the second client >> message, though? >> > > Well, both of these are more complicated than Host header. What's wrong > with that? > The SNI and the host header often have to match (or at least have a known mapping), because the origin server might want to prevent domain fronting. This might be less of an issue over IPv6, but I think that's the reason the two fields are currently more tightly-coupled than they were originally. This issue has turned out to be surprisingly subtle, and current practices seem to vary widely. My goal is to keep the SNI encrypted on the wire from CDN to Origin (I understand that the SNI is visible to the CDN). thanks, Rob --0000000000008db55a0594a2ba71 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 11, 2019 at 8:24 PM Eric Resc= orla <ekr@rtfm.com> wrote:


On Thu, Oct 10, 2019 at 8:12 PM = Rob Sayre <sayrer@= gmail.com> wrote:
On Fri, Oct 11, 2019 at 5:37 A= M Martin Thomson <mt@lowentropy.net> wrote:
On Fri, Oct 11, 2019, at 07:57= , Ben Schwartz wrote:
> The obvious solution is for the TLS client (i.e. the CDN) to support <= br> > direct entry of ESNI public keys alongside the IP address. Users who <= br> > want to be able to rotate their ESNI keys more easily should use a > backend identified by a domain name that is distinct from the
> user-facing origin hostname.

I was about to say the same thing.=C2=A0 No need to get fancy.

Isn't that more complicated than sending the SN= I in the second client message, though?
=
Well, both of these are more complicated than Host header. W= hat's wrong with that?

The SNI and the host header often have to match (or at least have a known= mapping), because the origin server might want to prevent domain fronting.= This might be less of an issue over IPv6, but I think that's the reaso= n the two fields are currently more tightly-coupled than they were original= ly.

This issue has turned out to be surprisingly s= ubtle, and current practices seem to vary widely. My goal is to keep the SN= I encrypted on the wire from CDN to Origin (I understand that the SNI is vi= sible to the CDN).

thanks,
Rob

--0000000000008db55a0594a2ba71-- From nobody Fri Oct 11 09:04:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19118120013 for ; Fri, 11 Oct 2019 09:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 ojEP-bTaZDXf for ; Fri, 11 Oct 2019 09:04:01 -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 177AC120045 for ; Fri, 11 Oct 2019 09:04:00 -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 x9BG2Row017662; Fri, 11 Oct 2019 17:03:54 +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=OjcyzuMrRfxwhirkdrtjX5yXwRLWaxY3NZ1ZDiSrOpA=; b=ouOAEf/58YcPKR0lQ/691FRniFTlGq+p/jRlWU60HvZjmvtCsefErLLyeir03K2gbwag +ZMpq/6uIH06vlqZZsnSFiOy3HTJ8Z2St+wGoz6df4ULu1DdD5D6yVjisuH7QbhUBMsG cgHK5WbCgG1cLvC+so2fzr9ED2RMr+azcpLHgZz/qVxOSUEwADrBdd5AuFHyOJ4pc5a+ 1/JHsoJJe2frl+/yJsHy0CMDfSAgh+Zt5GnwmwFqPpbcrFl/n+EZ2zVbILQdlVLWbv85 PKTe1iTjrqk9mawreze40SyBGGV6kR4oXiozT5Hd4cFhMUeQET++t7QZisoCkB0L3Qo8 cg== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2veg8fqq7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 17:03:54 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9BG2I1V003990; Fri, 11 Oct 2019 12:03:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint3.akamai.com with ESMTP id 2veph1bdg9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 12:03:53 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Oct 2019 11:03:47 -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.1473.005; Fri, 11 Oct 2019 11:03:47 -0500 From: "Salz, Rich" To: Rob Sayre CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVf+GsnWryPMhc506+pN76L/UXB6dVwjUAgAAGBoD//+OwgA== Date: Fri, 11 Oct 2019 16:03:46 +0000 Message-ID: References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.130] Content-Type: multipart/alternative; boundary="_000_D0B30308AF9145979057337D402FCF63akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-11_09:, , 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=741 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910110145 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-11_09:2019-10-10,2019-10-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 malwarescore=0 impostorscore=0 phishscore=0 priorityscore=1501 clxscore=1015 mlxlogscore=727 suspectscore=0 bulkscore=0 adultscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910110145 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 16:04:03 -0000 --_000_D0B30308AF9145979057337D402FCF63akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PlRoZSBTTkkgYW5kIHRoZSBob3N0IGhlYWRlciBvZnRlbiBoYXZlIHRvIG1hdGNoIChvciBhdCBs ZWFzdCBoYXZlIGEga25vd24gbWFwcGluZyksIGJlY2F1c2UgdGhlIG9yaWdpbiBzZXJ2ZXIgbWln aHQgd2FudCB0byBwcmV2ZW50IGRvbWFpbiBmcm9udGluZy4NCg0KTW9yZSBsaWtlbHkgdGhlIENE Ti4gIEFtYXpvbiBhbmQgR29vZ2xlIHVzZWQgdG8gZG8gdGhpcyBidXQgc3RvcHBlZCAoaHR0cHM6 Ly93d3cudGhldmVyZ2UuY29tLzIwMTgvNC8zMC8xNzMwNDc4Mi9hbWF6b24tZG9tYWluLWZyb250 aW5nLWdvb2dsZS1kaXNjb250aW51ZWQpLiAgSSBkb27igJl0IHNlZSBob3cgdGhlIG9yaWdpbiBp cyBpbnZvbHZlZC4NCg0KPiBNeSBnb2FsIGlzIHRvIGtlZXAgdGhlIFNOSSBlbmNyeXB0ZWQgb24g dGhlIHdpcmUgZnJvbSBDRE4gdG8gT3JpZ2luIChJIHVuZGVyc3RhbmQgdGhhdCB0aGUgU05JIGlz IHZpc2libGUgdG8gdGhlIENETikuDQoNClVzZSBETlMgZW50cmllcyBmb3IgdGhlIG9yaWdpbiB0 aGVuIEVTTkkgd29ya3MuICBJZiB5b3UgZm9sbG93IHlvdXIg4oCcSVB2NiB1bmlxdWVseSBpZGVu dGlmaWVzIHRoZSBvcmlnaW7igJ0gYXNzdW1wdGlvbiwgdGhlbiBFU05JIGlzIHBvaW50bGVzcy4N Cg0K --_000_D0B30308AF9145979057337D402FCF63akamaicom_ 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 IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5UaGUgU05JIGFuZCB0aGUgaG9zdCBoZWFkZXIgb2Z0ZW4gaGF2ZSB0byBtYXRjaCAob3IgYXQg bGVhc3QgaGF2ZSBhIGtub3duIG1hcHBpbmcpLCBiZWNhdXNlIHRoZSBvcmlnaW4gc2VydmVyIG1p Z2h0IHdhbnQgdG8gcHJldmVudCBkb21haW4gZnJvbnRpbmcuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1vcmUgbGlrZWx5IHRoZSBDRE4uJm5ic3A7IEFtYXpvbiBhbmQgR29vZ2xlIHVzZWQgdG8g ZG8gdGhpcyBidXQgc3RvcHBlZCAoPGEgaHJlZj0iaHR0cHM6Ly93d3cudGhldmVyZ2UuY29tLzIw MTgvNC8zMC8xNzMwNDc4Mi9hbWF6b24tZG9tYWluLWZyb250aW5nLWdvb2dsZS1kaXNjb250aW51 ZWQiPmh0dHBzOi8vd3d3LnRoZXZlcmdlLmNvbS8yMDE4LzQvMzAvMTczMDQ3ODIvYW1hem9uLWRv bWFpbi1mcm9udGluZy1nb29nbGUtZGlzY29udGludWVkPC9hPikuJm5ic3A7DQogSSBkb27igJl0 IHNlZSBob3cgdGhlIG9yaWdpbiBpcyBpbnZvbHZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgTXkgZ29hbCBpcyB0byBrZWVwIHRoZSBTTkkgZW5jcnlwdGVkIG9uIHRoZSB3 aXJlIGZyb20gQ0ROIHRvIE9yaWdpbiAoSSB1bmRlcnN0YW5kIHRoYXQgdGhlIFNOSSBpcyB2aXNp YmxlIHRvIHRoZSBDRE4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5V c2UgRE5TIGVudHJpZXMgZm9yIHRoZSBvcmlnaW4gdGhlbiBFU05JIHdvcmtzLiZuYnNwOyBJZiB5 b3UgZm9sbG93IHlvdXIg4oCcSVB2NiB1bmlxdWVseSBpZGVudGlmaWVzIHRoZSBvcmlnaW7igJ0g YXNzdW1wdGlvbiwgdGhlbiBFU05JIGlzIHBvaW50bGVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_D0B30308AF9145979057337D402FCF63akamaicom_-- From nobody Fri Oct 11 09:49:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D3312001A for ; Fri, 11 Oct 2019 09:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=ON9ORUdf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aklrwl2x Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q3wQfallfqO for ; Fri, 11 Oct 2019 09:49:02 -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 A8368120013 for ; Fri, 11 Oct 2019 09:49:02 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 112565E5 for ; Fri, 11 Oct 2019 12:49:02 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 11 Oct 2019 12:49:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=pMZvisMraLCUUY9EI5nHMPTGXt3qsfL Punz8FCaliUQ=; b=ON9ORUdfFoplLFdCeFx3SW0s8MLyD2u9zPh4WzgyUGR/3Ky g6bcc+5s/VuRxXRGBKuJjLIiHNnVydYzZ2NEfvcmjASN+oE1f9EmOT2A+HEZwlAU X6tc9+IE0TL83gmrCwH/BHYKOHki2SqLFUmbZzQk5uFs8mCLvSKLamFSdDl3mhOT ac+EfOB4U3R/V8GhJg65eu90RDSnHZstRB9vBhLO8SkfAAueFANxvap9+D7Jz8LF d1wzSJniSFkBA1AFU53VJGaYNAnZFcH6vUkTpj/QPCt+sCuymqYAbThOUcqCecu0 2XHEHPOo+EZ3sTQ9hLmCmooHGG875Iycfc3poow== 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=fm1; bh=pMZvis MraLCUUY9EI5nHMPTGXt3qsfLPunz8FCaliUQ=; b=aklrwl2xWSHr7rtO5VwyHE sAs8RSV6oHGZmhi7MkTex4YDBJJa8EeMLodkxTy8pCjpLfjwtcKXBYWkPl35Dohn vHbSFrCaDXU3cJ5x+9YNTa4sNNRD86/vnxWmXWIhdmXZpWO5zSaoW2Mzl8CELjZ/ f3fUMbKvdRjSjKqxCsVx2QEgHxlQDBlIaY8QFjg/2FyS9HONc2LDdlOPh+O4PLkp Y6k7J5u5liH/YM8L+fH0ok8RI3NhUmWbYGzALtxIubEQkDulPcfsVhLCdibFNqha VHse0vEOzGvYf0HaZuAUlxeqoC30E40s+aUfWixtlfnR45ziZtzRvrBD5F8KpBOQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieehgddutdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4FBD83C00A1; Fri, 11 Oct 2019 12:49:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: In-Reply-To: <83b19d14-e03f-467a-9119-148bed049509@www.fastmail.com> References: <7675f5ef-c394-4ec5-b0c4-ca59e7b0e2b7@www.fastmail.com> <83b19d14-e03f-467a-9119-148bed049509@www.fastmail.com> Date: Fri, 11 Oct 2019 09:48:41 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Binder key labels for imported PSKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 16:49:07 -0000 Hi folks, Since #15 has been resolved, we'd like to revisit the proposed key schedule label modification here: https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 Please have a look and comment! Thanks, Chris On Thu, Sep 5, 2019, at 4:46 PM, Martin Thomson wrote: > That's a much better answer than I was looking for :) > > That makes sense. The gap between theory and practice here is still > something that is worth spending some time on, but I can see how that > is something that we might want to keep out of this document. The goal > here is simple: take a PSK that is bound to one KDF and apply a > transform that will allow it to be used with TLS ... in a way where the > choice of cipher suite is not constrained by the properties of that PSK. > > Understanding your broader goals better leads me to conclude that issue > #15 > (https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/15) is more important to resolve. > > On Thu, Sep 5, 2019, at 20:56, Jonathan Hoyland wrote: > > Hi Martin, > > > > So I agree that on the micro-scale there is limited practical value to > > be gained from adding this binding. > > The theoretical benefits, which mean that the client and server agree > > that PSK Importers are being used are nice, but on their own might not > > justify a high-effort change. > > However, at the macro-scale I think this is an interesting and useful > > addition. > > In particular I think we can use this change to address what I see as a > > short-coming of TLS 1.3 in general. > > > > Being able to use TLS as a building block for other protocols is really > > powerful and useful, but the current mechanisms are unnecessarily > > restrictive. > > I have spent a lot of time thinking about exporter keys, and the way > > they let us combine other protocols with TLS. > > TLS has really nice, strong, properties, and being able to leverage > > them in other protocols makes designing complex protocols much easier, > > especially from a formal analysis perspective. > > > > One limitation of exporter keys, however, is that you need to use TLS > > as your first/base protocol. > > Whilst you can use exporter keys to securely run a protocol over the > > top of TLS and get the guarantees of both*, you cannot run TLS inside > > another protocol and easily get the security guarantees of both*. > > I think that this restriction is unnecessary. > > > > My overarching goal is to make it possible to securely put protocol > > building blocks before TLS. > > The way you would achieve this is by allowing such blocks to be chained > > together and then bound into the TLS handshake. > > Ideally, all protocols that wish to use TLS in this way would use this > > key-schedule extension, allowing for complex state to be built up and > > composed into the TLS handshake. > > > > PSK Importers are, to my mind, a good place to start. > > Agreeing on a change of hash function can be viewed as a very small, > > very simple protocol. > > The necessary modifications are small, and the benefits, whilst > > incremental, are clear. > > The modification to the key schedule means that both parties can be > > sure that the other agrees that they are using PSK Importers and > > further, that they agree on the original hash function and the new hash > > function. > > > > Other protocols can then also make use of this extension to the key > > schedule to achieve similar aims. > > The idea would be that any protocol that uses this label implies that > > it is providing a context field (which may or may not be empty). > > These protocols can then be chained together in an agreed order, and > > the agreement properties of TLS can be used to verify that both parties > > agree on the transcripts of the previous protocols. > > > > Making this change allows us to leverage this power in future to make > > any number of more useful protocols. > > However, without a key schedule change, there is no way for a Client > > and Server to be sure that their peer is actually using TLS as a > > building block, which kneecaps any ability to compose it with other > > protocols. > > In this case it means that a Client cannot be sure that it agrees with > > the Server on the status of their relationship, and vice versa. > > So to directly answer your question, the value of the distinction in > > this case is incremental, but opens the door for other > > extensions/protocols to leverage it to provide arbitrarily complex > > guarantees**. > > > > There may be a case for working on a backwards compatible way of doing > > this, where a client offers PSK Importers multiple times with binders > > computed both ways, but I don't think that it's necessarily a good > > idea. > > > > Regards, > > > > Jonathan > > > > * The guarantees it is possible to get from this key-schedule change > > are a little bit nuanced, because a PSK handshake doesn't rely on a > > long-term asymmetric key, but that's a discussion for another time. > > ** Modulo limitations on outward compound authentication. > > > > > > On Wed, 4 Sep 2019 at 02:46, Martin Thomson wrote: > > > I want to push on this a little harder. Not because I don't think that more formal protections in the line of key separation are bad (they are great), but more to dig into the real reasons driving this change. The justification I've gotten thus far is somewhat superficial, and I want to see if there is something fundamental that we can point at. > > > > > > When we built the ext/res distinction, there was a clear problem expressed. We had the potential for both to be used by the same servers at the same time (though not for the same connection) and distinguishing between them was important. It wasn't so much that agreement about provenance of keys was important, but more what it meant for that provenance to be confused. A resumption key implies a number of things about the new session that extend from the previous session, whereas a straight external key does not imply the same. If a client and server were to disagree on these properties, one might assume properties of the resulting session that the other did not and we would be in a bad place. > > > > > > It's true that servers are in complete control over how keys are identified, and so this could always be addressed by the server by ensuring that key identifiers clearly distinguish between the two types. However, that protection would be informal and ad hoc. We wouldn't guarantee that separation by any mechanism. By applying different labels to the binder key we produce, disagreement results in interoperability failure (both client and server could be wrong, but at least they then agree, which is the property we really need). > > > > > > As an aside, we could have used explicit labels in the protocol, but we decided that an implicit one was better. For the record, I still think that's a good design paradigm to apply. > > > > > > The concern with the ext/res distinction doesn't seem to apply equally here. For simplicity, I think that we should consider this a path into the "ext" bucket, so that we have an resumption/other analysis holding (as above), and an external/imported analysis to perform in order to arrive at the "other" category. The question then becomes whether to fully distinguish imported PSKs from "regular" external PSKs. > > > > > > I think that the context of use is important to consider. The imported PSK will enter the key schedule (as shown below) after having been through a derivation process that includes additional information: most importantly, the protocol version and the hash function that the resulting PSK will be bound to. That produces something that could coexist with other uniformly random PSKs of sufficient entropy (i.e., it wouldn't collide with "external" PSKs with non-negligible probability). Because neither imported nor external PSKs come with any different presumption about the session that is ultimately produced, the same rationale for ext/res doesn't apply, and I'm struggling to find any stronger justification. > > > > > > The cost of adding more separation is forced changes to code. With the design prior to this, the importer function was loosely coupled to the TLS stack. It would be possible to manufacture as many "external" PSKs as needed from an root "imported" PSK. The resulting outputs could be fed to endpoints that haven't been updated to support this new importer stuff. That's obviously less clean than having native support for this, because the amount and complexity of key provisioning is higher, but it could have worked. This now requires code changes to deploy. > > > > > > So I'm not seeing strong cause here. > > > > > > To me, the relevant question is: Do client and server need to agree that this is an imported PSK as distinct from another form of external PSK? Or, what is the value of this distinction? > > > > > > On Tue, Sep 3, 2019, at 09:29, Christopher Wood wrote: > > > > Hi folks, > > > > > > > > > > > > Per Jonathan Hoyland's recommendation, we're considering adding a new > > > > binder_key label ("imp binder") for imported PSKs. Specifically, this > > > > changes the key schedule from this: > > > > > > > > ~~~ > > > > 0 > > > > | > > > > v > > > > PSK -> HKDF-Extract = Early Secret > > > > | > > > > +-----> Derive-Secret(., "ext binder" | "res binder", "") > > > > | = binder_key > > > > ~~~ > > > > > > > > to this: > > > > > > > > ~~~ > > > > 0 > > > > | > > > > v > > > > PSK -> HKDF-Extract = Early Secret > > > > | > > > > +-----> Derive-Secret(., "ext binder" > > > > | | "res binder" > > > > | | "imp binder", "") > > > > | = binder_key > > > > ~~~ > > > > > > > > Details can be found in the PR [1]. > > > > > > > > This does not seem to affect the interoperability story (imported keys > > > > are further differentiated from non-imported keys). However, it's non > > > > trivial, so we'd like feedback from the group before merging the change. > > > > > > > > Thanks! > > > > Chris (no hat) > > > > > > > > [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 > > > > > > > > _______________________________________________ > > > > 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 > From nobody Fri Oct 11 09:53:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED54120105 for ; Fri, 11 Oct 2019 09:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=JUfgSwBt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lwCvKttL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mURpuXE10bgc for ; Fri, 11 Oct 2019 09:53:04 -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 050F3120121 for ; Fri, 11 Oct 2019 09:53:04 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 91D1D5A0 for ; Fri, 11 Oct 2019 12:53:03 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 11 Oct 2019 12:53:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=TRWZZQ9qKbYydqQr63QNwaojZINb3hy YoZcp4p8bDfg=; b=JUfgSwBtB6r2JDmVBaqd4dSXENja+7vr+BydKxiqEyhUBcq fSbql5ysiBlT/KnGFc2PFWAn0Q7FZS6Ccjl6c+nCZ1NZU+oE2zGRIJs3KbS6UgCU yATi+eYxuRQtUIhrY8gkNh7RznjbbJkHKn0mqkSH90vMe7eSANo8hCqNYCJFwG8j 5pBJs1yypKAnVBq3Rs0x4+jJ4NBGlsVeEqABgMvS96RV6lk4cCVKfANp/QEHrz8P m3DxrmQ04jqh58XTvWtTW1MWuHnlVSSS+fPXOX3sMR9JNRCXfMAVHOYKpw1QIO1V E+CD6EzHbP/5MZIMO5b7DoonBLNrXxWFXk7rtTA== 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=fm1; bh=TRWZZQ 9qKbYydqQr63QNwaojZINb3hyYoZcp4p8bDfg=; b=lwCvKttLo09u7DgKssXNnG kwiwmHQjCfYDK51zWbqlPJNfetDsr9EtFbS9YkrcJceKq5Kkyp2GFBWIITEpIOgR uF9TAj3JqJDKOgRA9441D0aQv9SEEwRr1ukjVc1aWTa0pMzPVd64bjsJhW3Y8Dy9 5zve3CRuDVVJQdNlMg30HVhJzQ3wRNuP2s+6IkRJaYacMEdZM7cyGO307TCEJXSN 7hB4atXTcDFNpFMgRfzmY8Qn23jB1ffWY4lha+L57lfQsU2Zl6718oyTCJMa3wvn ZkxlfN/on1QtlJtFpQZ+iY9RuqWmwiqKeHtxeUufBLqmRmsMk5KuF+JfIGAE5gfg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieehgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptg grfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E2BC63C00A1; Fri, 11 Oct 2019 12:53:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <221da99b-321d-464c-b746-78c53c8d6167@www.fastmail.com> In-Reply-To: <2ab22d60-60e3-49bf-9bd2-fff97b1748c7@www.fastmail.com> References: <31e3f9ed-6b24-4526-af75-e2c190a3d707@www.fastmail.com> <2ab22d60-60e3-49bf-9bd2-fff97b1748c7@www.fastmail.com> Date: Fri, 11 Oct 2019 09:52:42 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] IANA changes for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 16:53:15 -0000 On Wed, Oct 9, 2019, at 6:28 PM, Martin Thomson wrote: > These are pretty long strings. That means more hash iterations to get > these values. Are we comfortable with that? For what it's worth, I think it's fine. I'm not overly concerned with more hash iterations here. Best, Chris From nobody Fri Oct 11 09:57:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F4412001A for ; Fri, 11 Oct 2019 09:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vhOKN-05953b for ; Fri, 11 Oct 2019 09:57:34 -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 E7608120013 for ; Fri, 11 Oct 2019 09:57:33 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id a1so22981163ioc.6 for ; Fri, 11 Oct 2019 09:57:33 -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=m6mjEBYUjLQItiOX8ZaIrXdTrQJOpBBWOlUJ+Tq+s7s=; b=Q7r8hF/cXz2I0ZrGFBBpiN1UkXotBbOikJG84UwLS6uy+BFT4XQavGUQz2wIdtW34S I4voEPJmNd1UGYCXZ7FHmz4udBTVQqyCvTtelU+6fLLjWibMKp30LId2SCawBNBp+9wk EZVJSDRuxcFamRqSVv5UmMvDt3+Z+QHUJcJ0sjRFyKbEd3cHR9JOFUFpUTtI5tyj6cN5 yij/hlEuhhvAgqBlsq7Fui6JW+vpgppwg7JEO3ZauYsY2cHxzYufH6uYe8uHhHzBuhhG S3ZM3imoYc3LtCnIIk9hIf0QlM2QGs0h6k7twgcHCXD4QfO5iqlvOKVmB4Sa1v4/DTR3 QTkA== 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=m6mjEBYUjLQItiOX8ZaIrXdTrQJOpBBWOlUJ+Tq+s7s=; b=qBsdZE8faKfOCGhXzkPRDs1cPB3hnLgY77bw6JfiUJf/YYPmLdrHU4CraC4V8PfS9/ mXzVkilnndkj1zZT3/ibXlajMXHxqcZjvcHKF7kIzzR7qU6+dkrDeYxdo323B3dB1jM+ nP6sL/X7I5S1GrhuksKoevjP3wDQKT5MT5zuILjN82cmdFupL+T0qMeTZ+MyUQPTi1GN 6UohuDM9sbqkW7bOGs69WQDDT7ao15hbkWadVvHUHI5Izw+LUBOwKLUjBrCDT5xyLMGA 332O72tg7vFlMfnGd2cjQXfg34wHsd3zfpHB9s0Rvmf5+nBqKWNI3WTFqTRx9DT65P63 gimQ== X-Gm-Message-State: APjAAAXcIkyog7LFJsm4JePJ0vjUnVeUyU/79qx9MigdbmfzezemmgWg 1FXz7zDVsl2w5+4iN85sVWlEM0pOqwtCOCktyC6uEvqHAD4GKhr8 X-Google-Smtp-Source: APXvYqxWZgdB2CAupWMUo1ZzfYa98Ninafar4Nx+y9vqAA6TdqgwHYm9hfKUGVhNT2hEDC8esCqr6e7Ms8z/JHe+Vmg= X-Received: by 2002:a05:6638:928:: with SMTP id 8mr18391231jak.124.1570813053016; Fri, 11 Oct 2019 09:57:33 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: From: Rob Sayre Date: Fri, 11 Oct 2019 23:57:14 +0700 Message-ID: To: "Salz, Rich" Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000008a4210594a56ad4" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 16:57:38 -0000 --00000000000008a4210594a56ad4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 11, 2019 at 11:03 PM Salz, Rich wrote: > *>*The SNI and the host header often have to match (or at least have a > known mapping), because the origin server might want to prevent domain > fronting. > > > > More likely the CDN. Amazon and Google used to do this but stopped ( > https://www.theverge.com/2018/4/30/17304782/amazon-domain-fronting-google= -discontinued). > I don=E2=80=99t see how the origin is involved. > > > > > My goal is to keep the SNI encrypted on the wire from CDN to Origin (I > understand that the SNI is visible to the CDN). > > > > Use DNS entries for the origin then ESNI works. If you follow your =E2= =80=9CIPv6 > uniquely identifies the origin=E2=80=9D assumption, then ESNI is pointles= s. > Hello, I would like to reiterate the use case: How does a request of the form "username.example.com" get through a CDN to an Origin while leaving the SNI encrypted on the wire? It sounds like you're saying the domain name should change from the CDN to the Origin, but that doesn't seem like something that's automatically supported or interoperable. I also disagree with the argument that ESNI is pointless when =E2=80=9CIPv6 uniquely identifies the origin=E2=80=9D. thanks, Rob --00000000000008a4210594a56ad4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 11, 2019 at 11:03 PM Salz= , Rich <rsalz@akamai.com> wro= te:

>The= SNI and the host header often have to match (or at least have a known mapp= ing), because the origin server might want to prevent domain fronting.

=C2=A0

More likely the CDN.=C2=A0 Amazon and Google used to= do this but stopped (https://www= .theverge.com/2018/4/30/17304782/amazon-domain-fronting-google-discontinued= ).=C2=A0 I don=E2=80=99t see how the origin is involved.

=C2=A0

> My goal is to keep the SNI encrypted on the wir= e from CDN to Origin (I understand that the SNI is visible to the CDN).<= /u>

=C2=A0

Use DNS entries for the origin then ESNI works.=C2= =A0 If you follow your =E2=80=9CIPv6 uniquely identifies the origin=E2=80= =9D assumption, then ESNI is pointless.

<= div>
Hello,

I would like to reiterat= e the use case:

How does a request of the form &qu= ot;username.example.com" g= et through a CDN to an Origin while leaving the SNI encrypted on the wire?<= /div>

It sounds like you're saying the domain name s= hould change from the CDN to the Origin, but that doesn't seem like som= ething that's automatically supported or interoperable.

<= /div>
I also disagree with the argument that ESNI is pointless when =E2= =80=9CIPv6 uniquely identifies the origin=E2=80=9D.

thanks,
Rob

--00000000000008a4210594a56ad4-- From nobody Fri Oct 11 09:58:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379821200C5 for ; Fri, 11 Oct 2019 09:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=FzZGJZ1F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wv9AdOWe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKPl0lBvcwek for ; Fri, 11 Oct 2019 09:58:25 -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 3E9061200B8 for ; Fri, 11 Oct 2019 09:58:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CFCD460F for ; Fri, 11 Oct 2019 12:58:24 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 11 Oct 2019 12:58:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Qan7nFbpmB8k083qjCmZYutiCjvvKht q1K7tZfE/r+k=; b=FzZGJZ1FzoZ8vaD01jWWzubPBSoHb3r2UMMa5+4twJKrwId fFwDdY0vlaqUyhxte+zQso5iuURFwf0YDwlxpuchvlazW1lBbro0FgJFS6QfuAdO ToVgPmFkjyb/dX6nO4cpDBdDFWs6bnqpKMGVK5AJ3BVvKYiBjL3aXqu/yorQ1Kah 8ygbWNoWZb2dpkqERWp5E88eMuDXEQCtWfd4Ubvp1Vs+vQh8aN/UJCQUoEh5kjMp MPNtImngzrreOlinpKo1SQZjwf8XXbtONpJ1ARcfEERqf3MsgmImDpRGMONLGml8 qBMd7O48UxC2wfypA5b3MCsT9PrP9Frikk3fFRw== 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=fm1; bh=Qan7nF bpmB8k083qjCmZYutiCjvvKhtq1K7tZfE/r+k=; b=wv9AdOWeOuZFWEacaRmDLn SgQU7rf92WcOQ4mUZq+PSeLW8prF3P+EumbLCaQCv5Ccbl8oFqEhfvUoEE2qbcju Rlq+tv+VAGNueIf5FciDO5McUp2Bcty57mceHGkTxn7TJC+wrNkdcOhlbBSgo6wE slC8AVoDJnKNJUnulCq/cDNxvkZKcw2zPlRo2TrfXUAZ/LvQSnrDpINyHc+fU2kb 6Mky2XsxWQIIoNgcbxyJyZUGEp/WkuKNzdBFsFoJZLewYcPCR4+z9KFPH/6tNUo0 kzJS5IuJwEmLbpbPqNuqz+wn1l2Qby0tfTB4nbLTws1Ynf1qesDsSBGRH+Gxkl1Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieehgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2849A3C00A1; Fri, 11 Oct 2019 12:58:24 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <22c919a7-5df4-4b7c-a5da-a2a81fd1471d@www.fastmail.com> In-Reply-To: References: <69c7cfbd-fe9f-40fa-b92b-e4b65fa6cb5d@www.fastmail.com> Date: Fri, 11 Oct 2019 09:56:59 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS Key Separation PR X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 11 Oct 2019 16:58:37 -0000 This PR has been merged. Thanks, all! Best, Chris On Thu, Oct 10, 2019, at 4:01 PM, Martin Thomson wrote: > Thanks, that was my mistake. I confirmed with our code and we are > indeed right up to the line. > > On Thu, Oct 10, 2019, at 23:37, Eric Rescorla wrote: > > > > > > On Wed, Oct 9, 2019 at 7:01 PM Martin Thomson wrote: > > > tl;dr keep the space. > > > > > > I had a little trouble reproducing the 12 from RFC 8446, so I double-checked. > > > > > > .... > > > > > > Working from the base for SHA-256: > > > > > > The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one to allow for padding. Therefore we have 55 bytes to use without having to run two blocks through SHA-256. > > > > > > HMAC-Hash = H(K XOR opad || H(K XOR ipad || text)) > > > > > > Here `K XOR ipad` is the 32 bytes output size of SHA-256, so we are down to 23 bytes for text before it adds a block. > > > > In HMAC the key consumes an entire input block, so that you are > > guaranteed a compression function cycle before the data is added: > > > > 1) append zeros to the end of K to create a B byte string > > (e.g., if K is of length 20 bytes and B=64, then K will be > > appended with 44 zero bytes 0x00) > > (2) XOR (bitwise exclusive-OR) the B byte string computed in step > > (1) with ipad > > > > https://tools.ietf.org/rfcmarkup?doc=2104#section-2This shifts > > everything to the right 32 bytes, which, because context is 32 bytes, > > gets us back to 12, I think, though I haven't re-worked through it. > > > > Here's Ilari's original analysis, if that's helpful: > > https://mailarchive.ietf.org/arch/msg/tls/n_TFape7L4HHoKLxGo8CkimZziI > > > > -Ekr > > > > > > > > > > > HKDF-Expand = HMAC-Hash(PRK, info | 0x01) > > > > > > This takes one more. Down to 22. > > > > > > HKDF-Expand-Label passes info in the form of: > > > > > > struct { > > > uint16 length = Length; > > > opaque label<7..255> = "tls13 " + Label; > > > opaque context<0..255> = Context; > > > } HkdfLabel; > > > > > > which has a minimal overhead of 2 + 1 + len("tls13 ") + 1 = 10. So we get 12. > > > > > > "c ap traffic" is 12 bytes long, so yeah it *looks* like we're stuck if we care about not adding too many extra hash iterations. > > > > > > .... > > > > > > But if you look at the key schedule, we always provide a context for those cases we use "c ap traffic". Those will always spill over into the next iteration as Context is 32 bytes. So for those cases, we have a whole 32 bytes extra to play with. The only cases with an empty Context are "derived" and "res binder"|"ext binder". Those max out at 10, so we seem to have two whole bytes of wiggle room. > > > > > > You can safely add the space. > > > > > > On Wed, Oct 2, 2019, at 08:40, Eric Rescorla wrote: > > > > Hi folks, > > > > > > > > As discussed in Montreal, I've prepared a PR to give us DTLS/TLS key separation. > > > > > > > > See: > > > > https://github.com/tlswg/dtls13-spec/pull/99 > > > > > > > > Sadly. we didn't have enough space for "dtls13 " so I went for "dtls13" > > > > > > > > -Ekr > > > > > > > > _______________________________________________ > > > > 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 > From nobody Fri Oct 11 10:11:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48428120018 for ; Fri, 11 Oct 2019 10:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 uIL3Dddth4Gm for ; Fri, 11 Oct 2019 10:11:30 -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 EB19A12001A for ; Fri, 11 Oct 2019 10:11:29 -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 x9BGqEaM015189; Fri, 11 Oct 2019 18:11:29 +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=OFmD4rElhLyG0Kx/DDEQYfRRWZe5aS3BS3N9BoZXzGE=; b=CfxCcvGC5TJD3jPeiaXf18YrLulnZBuPZdSyC7q7WYSGUaQymXcDvhSs/lJxuV+6jYOC 4wtfO8Y8hUw+szGQV0eDDTjz0IE8HtN+gS+rWRg/KRsP0XmD7h6EofMn3+jE85yhRx+j OhfPk6jNcacEeD9HgAxXLfBSrBdybiqOE8UNOhaLA9GvpD7cvnBrshxsQ0/W48brorB6 FKb7NCt7I3szwe6ypHs22QrPOXK/4bEMHYb1604H6qEt7X8VkXEf/27bVaYKl8UIDJYy 2Qec6NpomfvBLdh1LGKOX2WuGjLd1YeFRQdCUMBKIlWlRpxQ23PKnZnbZ7xRTy1Z6dXI kA== Received: from prod-mail-ppoint3 (prod-mail-ppoint3.akamai.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vekk97ccp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 18:11:28 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9BH1rGC007047; Fri, 11 Oct 2019 13:11:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.117]) by prod-mail-ppoint3.akamai.com with ESMTP id 2veph1cdp2-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 11 Oct 2019 13:11:23 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 11 Oct 2019 12:11:09 -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.1473.005; Fri, 11 Oct 2019 12:11:09 -0500 From: "Salz, Rich" To: Rob Sayre CC: "TLS@ietf.org" Thread-Topic: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.txt) Thread-Index: AQHVf+GsnWryPMhc506+pN76L/UXB6dVwjUAgAAGBoD//+OwgIAAUf8A///A04A= Date: Fri, 11 Oct 2019 17:11:08 +0000 Message-ID: <4BB4C376-D4EE-4C3D-87D2-3611E6285801@akamai.com> References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191003 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.130] Content-Type: multipart/alternative; boundary="_000_4BB4C376D4EE4C3D87D23611E6285801akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-11_10:, , 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-1908290000 definitions=main-1910110149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-11_10:2019-10-10,2019-10-11 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 clxscore=1015 mlxscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 spamscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910110149 Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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, 11 Oct 2019 17:11:33 -0000 --_000_4BB4C376D4EE4C3D87D23611E6285801akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEhvdyBkb2VzIGEgcmVxdWVzdCBvZiB0aGUgZm9ybSAidXNlcm5hbWUuZXhhbXBs ZS5jb208aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X3VzZXJuYW1lLmV4YW1wbGUuY29tJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZy PTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmbT11anM2TGtiY19JR1RpdUxkY0RrOHN5aFdQMXY5bE5w enRsOU94WnVDdmFzJnM9aEJHSHV6d2ZzNjZsSVlSdzJsa3BuZUp1NzJ2a2VDOW01SEg0NkVKMGkz YyZlPT4iIGdldCB0aHJvdWdoIGEgQ0ROIHRvIGFuIE9yaWdpbiB3aGlsZSBsZWF2aW5nIHRoZSBT TkkgZW5jcnlwdGVkIG9uIHRoZSB3aXJlPw0KDQpUaGUgQ0ROIG5lZWRzIHRvIHNlZSB0aGUgZGVj cnlwdGVkIFNOSS4gIElmIHRoZSBDRE4gYW5kIG9yaWdpbiBzaGFyZSB0aGUgRVNOSSBrZXlzLCB0 aGUgQ0ROIGNhbiBqdXN0IHBhc3MgdGhlIG9yaWdpbmFsIEVTTkkgdmFsdWUgYWxvbmcuICBJZiB0 aGUgQ0ROIGFuZCBvcmlnaW4gZG8gbm90IHNoYXJlIEVTTkkga2V5cywgdGhlbiB0aGUgQ0ROIHdp bGwgaGF2ZSB0byByZS1lbmNyeXB0LiAgSWYgdGhhdCBpcyBhbiBpc3N1ZSB5b3UgaGF2ZW7igJl0 IGV4cGxhaW5lZCB3aHkgb3IgSSBtaXNzZWQuDQoNCg0KICAqICAgSXQgc291bmRzIGxpa2UgeW91 J3JlIHNheWluZyB0aGUgZG9tYWluIG5hbWUgc2hvdWxkIGNoYW5nZSBmcm9tIHRoZSBDRE4gdG8g dGhlIE9yaWdpbiwgYnV0IHRoYXQgZG9lc24ndCBzZWVtIGxpa2Ugc29tZXRoaW5nIHRoYXQncyBh dXRvbWF0aWNhbGx5IHN1cHBvcnRlZCBvciBpbnRlcm9wZXJhYmxlLg0KDQpJIGd1ZXNzIGl0IGRl cGVuZHMgb24gdGhlIENETi4gIEkgc2FpZCB0aGF04oCZcyBob3cgbXkgZW1wbG95ZXIgd29ya3Ms IHlvdSBzYWlkIENsb3VkRmxhcmUgZG9lc27igJl0IHdvcmsgdGhhdCB3YXksIGFuZCBJIGRpZG7i gJl0IHF1aXRlIHVuZGVyc3RhbmQgd2hhdCBXYXRzb24gc2FpZC4gOikNCg0KDQogICogICBJIGFs c28gZGlzYWdyZWUgd2l0aCB0aGUgYXJndW1lbnQgdGhhdCBFU05JIGlzIHBvaW50bGVzcyB3aGVu IOKAnElQdjYgdW5pcXVlbHkgaWRlbnRpZmllcyB0aGUgb3JpZ2lu4oCdLg0KDQpDYW4geW91IGV4 cGxhaW4gd2h5Pw0K --_000_4BB4C376D4EE4C3D87D23611E6285801akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <49BD7E784384B34D817DA7F8982CD040@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3OTIwOTczOTQ7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI5NzgxNTU4MCA2NDUwMTY2ODggNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5Ib3cgZG9lcyBhIHJlcXVlc3Qgb2YgdGhl IGZvcm0gJnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHAtM0FfX3VzZXJuYW1lLmV4YW1wbGUuY29tJmFtcDtkPUR3TUZhUSZhbXA7Yz05 NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209 dWpzNkxrYmNfSUdUaXVMZGNEazhzeWhXUDF2OWxOcHp0bDlPeFp1Q3ZhcyZhbXA7cz1oQkdIdXp3 ZnM2NmxJWVJ3MmxrcG5lSnU3MnZrZUM5bTVISDQ2RUowaTNjJmFtcDtlPSI+dXNlcm5hbWUuZXhh bXBsZS5jb208L2E+JnF1b3Q7DQogZ2V0IHRocm91Z2ggYSBDRE4gdG8gYW4gT3JpZ2luIHdoaWxl IGxlYXZpbmcgdGhlIFNOSSBlbmNyeXB0ZWQgb24gdGhlIHdpcmU/PG86cD48L286cD48L2xpPjwv dWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBDRE4gbmVlZHMgdG8gc2VlIHRoZSBkZWNy eXB0ZWQgU05JLiZuYnNwOyBJZiB0aGUgQ0ROIGFuZCBvcmlnaW4gc2hhcmUgdGhlIEVTTkkga2V5 cywgdGhlIENETiBjYW4ganVzdCBwYXNzIHRoZSBvcmlnaW5hbCBFU05JIHZhbHVlIGFsb25nLiZu YnNwOyBJZiB0aGUgQ0ROIGFuZCBvcmlnaW4gZG8gbm90IHNoYXJlIEVTTkkga2V5cywgdGhlbiB0 aGUgQ0ROIHdpbGwgaGF2ZSB0byByZS1lbmNyeXB0LiZuYnNwOyBJZiB0aGF0IGlzIGFuDQogaXNz dWUgeW91IGhhdmVu4oCZdCBleHBsYWluZWQgd2h5IG9yIEkgbWlzc2VkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+SXQgc291bmRzIGxpa2UgeW91J3JlIHNheWluZyB0aGUgZG9tYWluIG5hbWUgc2hv dWxkIGNoYW5nZSBmcm9tIHRoZSBDRE4gdG8gdGhlIE9yaWdpbiwgYnV0IHRoYXQgZG9lc24ndCBz ZWVtIGxpa2Ugc29tZXRoaW5nIHRoYXQncyBhdXRvbWF0aWNhbGx5IHN1cHBvcnRlZCBvciBpbnRl cm9wZXJhYmxlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGd1ZXNzIGl0IGRlcGVuZHMgb24gdGhlIENETi4mbmJzcDsgSSBzYWlkIHRoYXTigJlzIGhvdyBt eSBlbXBsb3llciB3b3JrcywgeW91IHNhaWQgQ2xvdWRGbGFyZSBkb2VzbuKAmXQgd29yayB0aGF0 IHdheSwgYW5kIEkgZGlkbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCB3aGF0IFdhdHNvbiBzYWlkLiA6 KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+SSBhbHNvIGRpc2FncmVlIHdpdGggdGhlIGFyZ3VtZW50 IHRoYXQgRVNOSSBpcyBwb2ludGxlc3Mgd2hlbiDigJxJUHY2IHVuaXF1ZWx5IGlkZW50aWZpZXMg dGhlIG9yaWdpbuKAnS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2FuIHlvdSBleHBsYWluIHdoeT8gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_4BB4C376D4EE4C3D87D23611E6285801akamaicom_-- From nobody Fri Oct 11 14:35:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60399120805 for ; Fri, 11 Oct 2019 14:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.865 X-Spam-Level: X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-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 ck_ORmnjZlFP for ; Fri, 11 Oct 2019 14:35:05 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C8B4120816 for ; Fri, 11 Oct 2019 14:35:05 -0700 (PDT) Received: from [10.200.2.180] (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id EAFC92B6D07 for ; Fri, 11 Oct 2019 17:35:03 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Viktor Dukhovni In-Reply-To: <0c195775-2039-4239-9a4c-66d5c650e9ae@www.fastmail.com> Date: Fri, 11 Oct 2019 17:35:03 -0400 Content-Transfer-Encoding: quoted-printable Reply-To: IETF TLS WG Message-Id: References: <156962803631.24993.3421537129925787732@ietfa.amsl.com> <8c2b10b3-bfc2-44b0-997a-1cab0789f1b7@www.fastmail.com> <2781261d-bfa2-4c40-9ca4-6a3a1c9266df@www.fastmail.com> <5816BBD1-14EE-4B72-AEC4-AC7D576C4823@dukhovni.org> <0c195775-2039-4239-9a4c-66d5c650e9ae@www.fastmail.com> To: IETF TLS WG X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.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, 11 Oct 2019 21:35:18 -0000 > On Oct 11, 2019, at 4:55 AM, Martin Thomson wrote: >=20 > Yeah, I agree that this is a little thorny. However, the client = asking for one extra and the server vending one more is a relatively = small extra expense AND we discourage reuse in the general case. So, at = least from my perspective, this isn't that serious a problem and = shouldn't block publication. In Postfix, multiple SMTP client processes share a 1 slot external session ticket cache, and expect to re-use tickets until a new one is issued by the server. This works poorly with servers that don't allow re-use, and updating the cache on each connection is rather wasteful on both ends. Presently, the Postfix SMTP server assumes clients of the same kind, and always only issues new tickets *as-needed*. If clients could signal their real requirements, that policy would no longer need to be hard-coded, it would just become a default for clients that don't send this extension. Perhaps the solution is to say that clients that don't send the extension get default application-specific behaviour, possibly "refresh only as-needed". If they prefer to always get a specific number of tickets, they can request that number. Then I guess I could attempt to honour the extension, and revert to default behaviour in its absence, making sure that the Postfix SMTP client either does not ask to send the extension, or invokes some appropriate OpenSSL interface to ask that it not be sent as appropriate. --=20 Viktor. From nobody Fri Oct 11 16:49:09 2019 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 D6450120059; Fri, 11 Oct 2019 16:49:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157083774081.29291.299126609228483357@ietfa.amsl.com> Date: Fri, 11 Oct 2019 16:49:00 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-33.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, 11 Oct 2019 23:49:01 -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 : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-33.txt Pages : 52 Date : 2019-10-11 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-33 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-33 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-33 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 11 21:22:03 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41B912081B for ; Fri, 11 Oct 2019 21:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfg0Acjx5Ywd for ; Fri, 11 Oct 2019 21:22:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38F8F120815 for ; Fri, 11 Oct 2019 21:22:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A9B79B801A8; Fri, 11 Oct 2019 21:21:49 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: lperrin@bellaliant.net, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20191012042149.A9B79B801A8@rfc-editor.org> Date: Fri, 11 Oct 2019 21:21:49 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (5874) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 12 Oct 2019 04:22:02 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5874 -------------------------------------- Type: Technical Reported by: Mr Laurie Perrin Section: 5.1 Original Text ------------- ... Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. Corrected Text -------------- ... Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data (i.e. those encapsulating an TLSInnerPlaintext record having a content field of length zero) MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. Notes ----- In the interest of clarity, it may be prudent to specify the type of record for which a fragment of length zero is being considered - it cannot be that of the TLSCiphertext itself, for "Application Data messages are always protected," therefore I infer this relates to the TLSInnerPlaintext content field (of length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment. Note: This comment also applies to previous versions of the TLS specification, in particular with the introduction of the respective text concerning zero-length fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment. Note: The implications of zero-length records must be considered with respect to potential vectors for denial of service. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Oct 12 00:19:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1E612004C for ; Sat, 12 Oct 2019 00:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 axoEWgwpxgw6 for ; Sat, 12 Oct 2019 00:19:00 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 7D5F012001E for ; Sat, 12 Oct 2019 00:19:00 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id b136so26364846iof.3 for ; Sat, 12 Oct 2019 00:19: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=Ar/kw8y4YAWTIMnwVEPT01Qjrm/T8xF6IfvuhVx6Gxc=; b=SZ6N3QgUbLXk3H+hF3dZPYKO9UNzm4YuBCwQFfqrn25UnAsdk/92z5EKjJzvwzB5ux 4AnvsCjiCnyKdDeg32JF4ibI3gEFsFi8VU1clmHJ4evM0AN6jxix+wbpz5PVzX2XWs6X KhyqwezBk+dQd4fyaMRYCELst3ZxLQ9K2nXwaYIC6Qj7OPopx+yNMBejvlilkXV094SN O+Q38x+Ypx1Csh0RsDwVsyD0JKOOilTL1VGr8iuT23JrYj/qCayGjsok8pfn5mVpmIqR XgfJTeWkFNwfjwh34zdqMlUJa0N23xwkAhtJuPcDAj58w839mQQOfF4WplQ0hTriSLIu rk7w== 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=Ar/kw8y4YAWTIMnwVEPT01Qjrm/T8xF6IfvuhVx6Gxc=; b=JobV/Oi8PgnBdqfUg732QxXt5kOsg9RwhfCAiKjWGr1Viz1AHVn/wtkN1LL3VHveWX p5l3xz6z8h0Z8hpODHC6U05A0NbXL9URJsLjRgHeYFtw3wUoHUTJuIPjOGL9CZPKk+h4 /pwJ6zHvd2CklJouekMteR+ok9IAg6xrdXNYGSRLBu9r9T0ifWZdzhp7JUM2G71ChcaS E3e8SrlIWLiSlWk+eU6GXQbMbiFpV7Xb2pustnFgNHxC8LF4WSO8QQiJBnBp4J3NUpOV Xjlkax7l/Y++xsSBIfTW3pHOaJt7iFG3Sbr7nxVxz457ZDGSSE58akHR3DaiVqFPuqta LmGA== X-Gm-Message-State: APjAAAW9tkHUgLOVwc1jWdWah/6uQEq7LC4CseAMS+fp09n8HlWgZwqU 6lDzcxfFmTUQdyw3DIJDZr08+o5rW5R8WZ/pOOE= X-Google-Smtp-Source: APXvYqz5ms4h2+uPKZUaQX42ay7NwDpJ50JzusyWidOz6lFY77C09NyvCzo6jtRYIqFPLrdtFC5xGedCLjEr5GAcZ94= X-Received: by 2002:a02:82:: with SMTP id 124mr5960275jaa.131.1570864739513; Sat, 12 Oct 2019 00:18:59 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> <4BB4C376-D4EE-4C3D-87D2-3611E6285801@akamai.com> In-Reply-To: <4BB4C376-D4EE-4C3D-87D2-3611E6285801@akamai.com> From: Rob Sayre Date: Sat, 12 Oct 2019 14:18:45 +0700 Message-ID: To: "Salz, Rich" Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c9fc330594b172d1" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Sat, 12 Oct 2019 07:19:03 -0000 --000000000000c9fc330594b172d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 12, 2019 at 12:11 AM Salz, Rich wrote: > > > - How does a request of the form "username.example.com > " > get through a CDN to an Origin while leaving the SNI encrypted on the = wire? > > > > The CDN needs to see the decrypted SNI. > Agreed. > If the CDN and origin share the ESNI keys, the CDN can just pass the > original ESNI value along. If the CDN and origin do not share ESNI keys, > then the CDN will have to re-encrypt. If that is an issue you haven=E2= =80=99t > explained why or I missed. > It's definitely one approach. I am not sure which keys should be used for the CDN -> Origin traffic, though. I suggested sending the SNI with the client cert, because it seemed simpler if client certs are already being used (an option I recommend for CDN -> Origin traffic). EKR's Host header suggestion may also be viable, but my goal is actually to make some TLS-level decisions about traffic based on the SNI. EKR's proposal also assumes some level of Host header / SNI divergence is allowed by the Origin host. These policies are not clear to me. For example, I'm not sure what rules a Cloudflare to Google Cloud Platform link would need to follow (this is a common enough setup that they have an egress agreement). > > - I also disagree with the argument that ESNI is pointless when =E2=80= =9CIPv6 > uniquely identifies the origin=E2=80=9D. > > > > Can you explain why? > I agree that a unique IPv6 address would expose the fact that a CDN is communicating with an Origin, but I also think subdomain data could be used for tracking, and so the SNI should still be encrypted. thanks, Rob --000000000000c9fc330594b172d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 12, 2019 at 12:11 AM Salz, Ri= ch <rsalz@akamai.c= om> wrote:

=C2=A0

  • How does a request of the form "username.exa= mple.com" get through a CDN to an Origin while leaving the SNI encrypted on the wire= ?

=C2=A0

The CDN needs to see the decrypted SNI.=C2=A0


Agreed.

=C2=A0

If the CDN and origin share = the ESNI keys, the CDN can just pass the original ESNI value along.=C2=A0 I= f the CDN and origin do not share ESNI keys, then the CDN will have to re-e= ncrypt.=C2=A0 If that is an issue you haven=E2=80=99t explained why or I missed.

=

It's definitely one approach. I am not= sure which keys should be used for the CDN -> Origin traffic, though. I= suggested sending the SNI with the client cert, because it seemed simpler = if client certs are already being used (an option I recommend for CDN ->= Origin traffic).

EKR's Host header suggestion= may also be viable, but my goal is actually to make some TLS-level decisio= ns about traffic based on the SNI. EKR's proposal also assumes some lev= el of Host header / SNI divergence is allowed by the Origin host. These pol= icies are not clear to me. For example, I'm not sure what rules a Cloud= flare to Google Cloud Platform link would need to follow (this is a common = enough setup that they have an egress agreement).

=C2=A0

  • I also disagree with the argument that ESNI i= s pointless when =E2=80=9CIPv6 uniquely identifies the origin=E2=80=9D.<= /u>

=C2=A0

Can you explain why?


I agree that a unique IPv6 address would expose the = fact that a CDN is communicating with an Origin, but I also think subdomain= data could be used for tracking, and so the SNI should still be encrypted.= =C2=A0

thanks,
Rob
--000000000000c9fc330594b172d1-- From nobody Sat Oct 12 07:10:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4C4120074 for ; Sat, 12 Oct 2019 07:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=FNA23Tjh; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=NnqLyQn1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LCeNxkEvoi0 for ; Sat, 12 Oct 2019 07:10:00 -0700 (PDT) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 45E7C120019 for ; Sat, 12 Oct 2019 07:10:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570889400; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=NzDGqd0IMaw0nPmCyf4J8tqB7TNM47Xz+2qVqHlIa0bL+HIe++Eg4LafOFl+gBoZ/DcOU8aZ++xLn QiRwNrNWxTmfJ8If5r7fwiGKMB5Fow/oAy+0xlLKW1Ly0fJxNBQWHasJ4sIaFh1DU0MRDjWe+m0anK KPTPYCX+tIjeNjQVLXsB/JnxeKiOAAP8QTR7r3dLKN2IIdZxqMIepBLuIvChgV80T/boMjmaQK90qn /mUlUkZp+GklLZh2HOrmvILf5eL36WhSKT3B+yQntWL6kUuOEDMk048YAoc/YPKlIU2YkFOkV5V8e5 m7KzbP2wqSTW949r9XcN2yRpGl8NV2g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=oD82RcvQUGc1/XkJa9GwHDDWprlq5LcxYG4ZUVc9sdo=; b=QVM7SYsv32KKcYFnGb++lyoXqmUo3v1CtM8EfGHZqNaU/rhxCuSmcvLEfO+KIUlUieE6WLda/uV2t 39hi3X8G6mDhtBY6PUnu5uTI9sOAbJR5wHeOl3t552HNHs4lBImsJ6iC58ho0F7GI0dTbSbVIP4hrN sECD7NZGmm5MQ43I4eRWK1zyaRbwlQSBueEWTN4tZsmKgTWH0uZMjbjd2ZDTf6zSmZ9tUncM4OkY0C mjEhK3HYHqbDwkEaxv6+ziYbDRgx3+OVF41T1H5WrGVb0iXVOzMlqAMmqgudZEi4j6P0u5QX7sWwnF VgXOMnxA8mLuY0GgFnsMN3QpRRfwmRA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.54; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=oD82RcvQUGc1/XkJa9GwHDDWprlq5LcxYG4ZUVc9sdo=; b=FNA23TjhI4d+5/IRNYROnPppGY7icRisXEWmAB+iTRk7r7hXVT1ci3RfPrV+v9Xm9A2xgFt8u8AWp 4PPYktfgmFZmAYS5vrj+iOaNfZ9opaVk3kV3Wu4dp9m8eEUQDP0N012/axN0KbrugvTlp+ABVIX9/C Rh/NMCfdUxUETT+U= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=oD82RcvQUGc1/XkJa9GwHDDWprlq5LcxYG4ZUVc9sdo=; b=NnqLyQn12dw2SUqeFmxwQtcfxzNiTrEqp62kPkGRhDO7evqU0ad5NHdUY8GQt0v1nllz8644s3hBb s7+z0KZjroqdjMx+3BsDjd5gf2/n7co+jepyc98iUXLcRkmRKS2Fiio6dSW6FhJ8SD6Rz3uWEEgA7p r3LB0UOatFzytn0fca9mwndjbqWfLV0yYiMk4ev2hmzI7uUPAqP4pIDd26q8LmeagA2FYBDUzkvX/P TBM8xxihviPVVpTKq2Q3LB7fme4LlCZrxjHUqfhLKz+CHhOg5OV4CHwWIvMQ4L1tv1HJ147yGGV3DO nIWsV0JS9ebovVXeFqVBnAwZd2cknrQ== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: f682537e-ecf9-11e9-955f-dfabc1efb494 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.54 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f54.google.com (unknown [209.85.210.54]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id f682537e-ecf9-11e9-955f-dfabc1efb494; Sat, 12 Oct 2019 14:09:54 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id s22so10332201otr.6 for ; Sat, 12 Oct 2019 07:09:54 -0700 (PDT) X-Gm-Message-State: APjAAAXTtbctfUjuSWsUJebJWZZZ26cDSJunauwr7swjO/3Ow7a2Zc2w WZRGUT7CECYug8YgiUTZ1xDc/VJ8o1OrbAKPQfI= X-Google-Smtp-Source: APXvYqzinsBE1qLmpN9KZ9arAz5p3ng+bBuDN2EGPLx407j/153lQ+QDpxmtH4opWKQsEI3N2vw3R70+x3lkqj3N+Qw= X-Received: by 2002:a9d:66d2:: with SMTP id t18mr1262930otm.154.1570889393625; Sat, 12 Oct 2019 07:09:53 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> <4BB4C376-D4EE-4C3D-87D2-3611E6285801@akamai.com> In-Reply-To: From: Patrick McManus Date: Sat, 12 Oct 2019 10:09:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000049e0a40594b73098" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Sat, 12 Oct 2019 14:10:04 -0000 --00000000000049e0a40594b73098 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable some thoughts after catching up on this thread: * cdn -> origin ime generally resolves via DNS for the same reason you want anything else to resolve via DNS: a level of indirection is handy for management. Occasionally it bypasses DNS for the same reasons you want anything to bypass DNS: a level of indirection adds tail risk and overhead. * origins sometimes have reasonable potential for ESNI anonymity sets themselves .. cloud hosting environments would be good examples. this should be encouraged. * it seems pretty unusual that a CDN and Origin would share keys.. the major use case of the CDN key is to cover an anonymity set that is a significant number of distinct customers. * using one v6 per origin (when you've got multiple origins available) isn't a great pattern imo - not only does it make ESNI rather useless (with an anonymity set of 1). but it fails to leverage the handshake and congestion control amortizations across origins that h2/h3 can and will be able to give you. We've built all the necessary http authority muxxing stuff into higher levels with SNI and HTTP at this point, there's no need to force it back into correlations withe the transport addresses. * a few folks do like to authenticate the cdn to the origin with client certs. That's nifty - but overall its pretty unpopular for the same reasons managing distributed keys are always unpopular - its a hassle to manage in the wild certs in a low risk way. DNS (scoped to ESNI - not as authentication replacement) is a bit nicer in this respect because you don't need to manage all the clients (multi cdn), but rather just a origin property.. tldr; imo none of this works if the origin does not have a decent anonymity set potential. If it does, just reuse esni for that hop rather than minting something new. On Sat, Oct 12, 2019 at 3:19 AM Rob Sayre wrote: > On Sat, Oct 12, 2019 at 12:11 AM Salz, Rich wrote: > >> >> >> - How does a request of the form "username.example.com >> " >> get through a CDN to an Origin while leaving the SNI encrypted on the= wire? >> >> >> >> The CDN needs to see the decrypted SNI. >> > > Agreed. > > > >> If the CDN and origin share the ESNI keys, the CDN can just pass the >> original ESNI value along. If the CDN and origin do not share ESNI keys= , >> then the CDN will have to re-encrypt. If that is an issue you haven=E2= =80=99t >> explained why or I missed. >> > > It's definitely one approach. I am not sure which keys should be used for > the CDN -> Origin traffic, though. I suggested sending the SNI with the > client cert, because it seemed simpler if client certs are already being > used (an option I recommend for CDN -> Origin traffic). > > EKR's Host header suggestion may also be viable, but my goal is actually > to make some TLS-level decisions about traffic based on the SNI. EKR's > proposal also assumes some level of Host header / SNI divergence is allow= ed > by the Origin host. These policies are not clear to me. For example, I'm > not sure what rules a Cloudflare to Google Cloud Platform link would need > to follow (this is a common enough setup that they have an egress > agreement). > > >> >> - I also disagree with the argument that ESNI is pointless when =E2= =80=9CIPv6 >> uniquely identifies the origin=E2=80=9D. >> >> >> >> Can you explain why? >> > > I agree that a unique IPv6 address would expose the fact that a CDN is > communicating with an Origin, but I also think subdomain data could be us= ed > for tracking, and so the SNI should still be encrypted. > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000049e0a40594b73098 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
some thoughts after catching up on this thread:

* cdn -> origin ime generally=C2=A0resolves via DNS for the sam= e reason=C2=A0you want anything else to resolve via DNS: a level of indirec= tion is handy for management. Occasionally it bypasses DNS for the same rea= sons you want anything to bypass DNS: a level of indirection adds tail risk= and overhead.

* origins sometimes have reasonable= potential for ESNI anonymity sets themselves .. cloud hosting environments= would be good examples. this should=C2=A0be encouraged.

* it seems pretty unusual that a CDN and Origin would share keys.. t= he major use case of the CDN key is to cover an anonymity set that is a sig= nificant number of distinct customers.

* using one= v6 per origin (when you've got multiple origins available) isn't a= great pattern imo - not only does it make ESNI rather useless (with an ano= nymity set of 1). but it fails to leverage the handshake and congestion con= trol amortizations across origins that h2/h3 can and will be able to give y= ou. We've built all the necessary http authority muxxing stuff into hig= her levels with SNI and HTTP at this point, there's no need to force it= back into correlations withe the transport addresses.

=
* a few folks do like to authenticate the cdn to the origin with clien= t certs. That's nifty - but overall its pretty unpopular for the same r= easons managing distributed keys are always unpopular - its a hassle to man= age in the wild certs in a low risk way. DNS (scoped to ESNI - not as authe= ntication replacement) is a bit nicer in this respect because you don't= need to manage all the clients (multi cdn), but rather just a origin prope= rty..

tldr; imo none of this works if the origin d= oes not have a decent anonymity set potential. If it does, just reuse esni = for that hop rather than minting something new.

On Sat, Oct 12, 2019= at 3:19 AM Rob Sayre <sayrer@gmail.= com> wrote:
On Sat, Oct 12, 2019 at 12:11 AM Salz,= Rich <rsalz@akama= i.com> wrote:

=C2=A0

  • How does a request of the form "username.exa= mple.com" get through a CDN to an Origin while leaving the SNI encrypted on the wire= ?

=C2=A0

The CDN needs to see the decrypted SNI.=C2=A0


Agreed.

=C2=A0

If the CDN and origin share = the ESNI keys, the CDN can just pass the original ESNI value along.=C2=A0 I= f the CDN and origin do not share ESNI keys, then the CDN will have to re-e= ncrypt.=C2=A0 If that is an issue you haven=E2=80=99t explained why or I missed.

=

It's definitely one approach. I am not= sure which keys should be used for the CDN -> Origin traffic, though. I= suggested sending the SNI with the client cert, because it seemed simpler = if client certs are already being used (an option I recommend for CDN ->= Origin traffic).

EKR's Host header suggestion= may also be viable, but my goal is actually to make some TLS-level decisio= ns about traffic based on the SNI. EKR's proposal also assumes some lev= el of Host header / SNI divergence is allowed by the Origin host. These pol= icies are not clear to me. For example, I'm not sure what rules a Cloud= flare to Google Cloud Platform link would need to follow (this is a common = enough setup that they have an egress agreement).

=C2=A0

  • I also disagree with the argument that ESNI i= s pointless when =E2=80=9CIPv6 uniquely identifies the origin=E2=80=9D.<= /u>

=C2=A0

Can you explain why?


I agree that a unique IPv6 address would expose the = fact that a CDN is communicating with an Origin, but I also think subdomain= data could be used for tracking, and so the SNI should still be encrypted.= =C2=A0

thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000049e0a40594b73098-- From nobody Sat Oct 12 08:37:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DEE120090 for ; Sat, 12 Oct 2019 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ztRK3awRz4Xm for ; Sat, 12 Oct 2019 08:37:53 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 A2749120052 for ; Sat, 12 Oct 2019 08:37:53 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id u8so27787263iom.5 for ; Sat, 12 Oct 2019 08:37:53 -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=VwJZzg+uJKvoDiQXhLbhDqufJ9mfsCxI27qlInn079Q=; b=IbN49B6hKkfiOW63k+aiezuXlUl6ovQ/PY1Chi42suHsOh1us3DYTZbJ3cJUF2/Ogq oqQHjEVhmbdbcieQJDaa6/FDACHW7fvmZAwPsFJuzvbFCGrK6Ttqizc4V1fGr5VmfKrP fRjgEgVbTPGm2iFzC4vgVw1dqmY6ZkZOtXxHvumJpbZTlvbeFNqyYj7oEXxuvMFZm59K nbcrYiV7vBeAn32W6oWBQI1wzZGzDZQoa23oHDab9ckXOqwQ5XeFt/JnnYeQLCBSPB9n 03qwo7BxBbCswPGdPAeIs83RkkndBU02pZcFAe+wY6oWaCU/0So+qYM8qFiB6b56xl8s 97MQ== 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=VwJZzg+uJKvoDiQXhLbhDqufJ9mfsCxI27qlInn079Q=; b=epg6zuJ6mYGjU+U0MMeJvnFcBJE5oRzGZ9B0Lv2EXs057p9UmcCiVwDIP0CM9wKIjA 6iDBT+VTy3NTkLJWy42VzvvGC0snGdzXkdozwyPDHvnOgfVWJOCYGik7jWNEIJsF7Okf LcAqwRJ4oV3V2lZQ6v+pqQ2aocJJqDr/RrGGmMHH6I6fzOY6owxtFhqkSgXRFrL5+jAj lih/dSVWmcOiONWPSIEf61orhWAvQGRw12ejGqQ0BUw7JOhb5awzqqAXDq91fP7smGTm ZsXDGF9Du3NKdFexMrP3g22nKYg1ji0m7ZrohYr+i9alAymH511i73fqNyLXrOXYo3gS L9vg== X-Gm-Message-State: APjAAAXeNHzzPQDkTDjA4Si3YLh1Ryws/+XvmMDobwZkfJ3DEExrIZYj rCqt326X67BYI4pJHtssNdBQylTwyNe1PMgiWIk= X-Google-Smtp-Source: APXvYqwUOqbe9+4RMgq4OZR7CWpLPA8zTBFXFj7WZCxMpMEw8f+xcjOvNv5HYbZVK0okoh4aBLUcd/RBZkC+hMSKnNU= X-Received: by 2002:a02:82:: with SMTP id 124mr8329457jaa.131.1570894672691; Sat, 12 Oct 2019 08:37:52 -0700 (PDT) MIME-Version: 1.0 References: <157048178892.4743.5417505225884589066@ietfa.amsl.com> <28C7A74D-5F9D-4E1A-A2D2-155417DA51C0@akamai.com> <80F168B0-7F30-4FDA-BD0F-4C787802F0D5@akamai.com> <83192EC8-6A24-4638-80AC-6D2AF9C68BBB@akamai.com> <9832ebfb-7c1f-4ce1-9bf3-d98845aad671@www.fastmail.com> <4BB4C376-D4EE-4C3D-87D2-3611E6285801@akamai.com> In-Reply-To: From: Rob Sayre Date: Sat, 12 Oct 2019 22:37:39 +0700 Message-ID: To: Patrick McManus Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f204a90594b86a7b" Archived-At: Subject: Re: [TLS] SNI from CDN to Origin (was I-D Action: draft-ietf-tls-sni-encryption-08.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: Sat, 12 Oct 2019 15:37:56 -0000 --000000000000f204a90594b86a7b Content-Type: text/plain; charset="UTF-8" On Sat, Oct 12, 2019 at 9:10 PM Patrick McManus wrote: > > tldr; imo none of this works if the origin does not have a decent > anonymity set potential. If it does, just reuse esni for that hop rather > than minting something new. > Thank you for the thoughtful response. I think it might be helpful to use a concrete example. The example I have in mind uses CDNs in two distinct ways. Let's say it's an HTML document from "username.example.com" that looks something like this: One use case for CDNs is to serve those jpegs with a TTL. I've often seen servers programmed to switch between CDNs in the HTML (or JSON, etc). So, the ops team for "username.example.com" might have a switch that changes "CDNHOST" from Level3 to Cogent (choose any of the big providers). This provides agility that does not rely on any CDN provider, and doesn't rely on DNS TTLs. That's good, because CDNs often encounter peering issues that are not in their control. This experience might be biased toward social media, where traffic is biased toward newer, popular content. The other use case concerns the HTML document from "username.example.com". This might be served with a zero-length TTL. This is done so that personalized API traffic can be served over private backhaul links, rather than the open Internet. Then, a Point-of-Presence data center will serve the traffic as closely as possible to the client (I know Patrick knows all of this, but I'm trying to be very clear for everyone). Two points from Patrick's message are confusing to me: - "using one v6 per origin (when you've got multiple origins available) isn't a great pattern imo" I meant to describe one IPv6 address per TLD+1 domain, so " username1.example.com" and "username2.example.com" could be served from the same IPv6 origin. It's not clear how to do this with an encrypted SNI from CDN to origin. I understand that some people think ESNI keys are the way to go, but I don't think anyone actually does this right now. - "a few folks do like to authenticate the cdn to the origin with client certs. That's nifty - but overall its pretty unpopular for the same reasons managing distributed keys are always unpopular..." It doesn't seem too complicated to me: https://support.cloudflare.com/hc/en-us/articles/204899617-Authenticated-Origin-Pulls Maybe it is complicated on the CDN side, but not for the origin. And it seems less complicated than uploading ESNI keys to the CDN. thanks, Rob --000000000000f204a90594b86a7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Oct 12, 2019 at 9:10 PM Patrick M= cManus <mcmanus@ducksong.com= > wrote:

tldr; imo none = of this works if the origin does not have a decent anonymity set potential.= If it does, just reuse esni for that hop rather than minting something new= .

Thank you for the thoughtful = response. I think it might be helpful to use a concrete example. The exampl= e I have in mind uses CDNs in two distinct ways.

L= et's say it's an HTML document from "username.example.com" that looks something like thi= s:

<html>
=C2=A0<body>
=
=C2=A0 =C2=A0<img src=3D"[CDNHOST]/foo.jpg">
=C2=A0 =C2=A0<img src=3D"[CDNHOST]/bar.jpg">
=C2= =A0 =C2=A0<img src=3D"[CDNHOST]/baz.jpg">
=C2= =A0</body>
</html>

One use c= ase for CDNs is to serve those jpegs with a TTL. I've often seen server= s programmed to switch between CDNs in the HTML (or JSON, etc). So, the ops= team for "username.example.co= m" might have a switch that changes "CDNHOST" from Level= 3 to Cogent (choose any of the big providers). This provides agility that d= oes not rely on any CDN provider, and doesn't rely on DNS TTLs. That= 9;s good, because CDNs often encounter peering issues that are not in their= control. This experience might be biased toward social media, where traffi= c is biased toward newer, popular content.

The oth= er use case concerns the HTML document from=C2=A0"username.example.com". This might be served wi= th a zero-length TTL. This is done so that personalized API traffic can be = served over private backhaul links, rather than the open Internet. Then, a = Point-of-Presence data center will serve the traffic as closely as possible= to the client (I know Patrick knows all of this, but I'm trying to be = very clear for everyone).

Two points from Patrick&= #39;s message are confusing to me:

- "usi= ng one v6 per origin (when you've got multiple origins available) isn&#= 39;t a great pattern imo"

I meant to describe= one IPv6 address per TLD+1 domain, so "username1.example.com" and "username2.example.com" could be served from the= same IPv6 origin. It's not clear how to do this with an encrypted SNI = from CDN to origin. I understand that some people think ESNI keys are the w= ay to go, but I don't think anyone actually does this right now.
<= div>
- "a few folks do like to authenticate the cdn to t= he origin with client certs. That's nifty - but overall its pretty unpo= pular for the same reasons managing distributed keys are always unpopular..= ."

It doesn't seem too complicated to me:=


Maybe it is complicated on the CDN side, but not for the = origin. And it seems less complicated than uploading ESNI keys to the CDN.<= /div>

thanks,
Rob
--000000000000f204a90594b86a7b-- From nobody Sat Oct 12 17:46:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFC412010E for ; Sat, 12 Oct 2019 17:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=WaT6lbqD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D7Ex7J9z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9CGd6mnmQPT for ; Sat, 12 Oct 2019 17:45:50 -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 6C010120125 for ; Sat, 12 Oct 2019 17:45:50 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id D13A3223B3 for ; Sat, 12 Oct 2019 20:45:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 12 Oct 2019 20:45:49 -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=nDa2/r65TjUbIJmrY9cTTEbarPwIZKKH0cL3rAW7w0k=; b=WaT6lbqD FpPAaKaGoyKdYsy2oj4GSIUzfRIb3f6fXm8v9M4cuu6Wo9CeuCuGokbm3rKt9sLn CCH3DqGEGDKU7zjwzmxAJHTjMqW65p7pKiFXshbNH52Ej/60UGShdirabpxBhvEH Z14JbrOsBxrzW///YYO3bc2PeINHiifzQGd/qIcZEtWe0TTnNlc01kIFoFEE9MVh RDAFu0XhxrjbYpX3GuCTpgiUS8H82DwG133ifzXkWhHmxfV51VX2xiJOQoGZ23Qk y/bF1BNmQKWHBgPrblNy6Y+NmfszHvbGhUUUFvSr48YOvTUarCySuKwxMj6LOHsZ G6mwqvh61Pxr3Q== 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=fm1; bh=nDa2/r65TjUbIJmrY9cTTEbarPwIZ KKH0cL3rAW7w0k=; b=D7Ex7J9z3t0AMG8vvzyp3/Cu55wDeMwSPSDZz9dCTCPtj GqXUmB4iHwCKcX5bq5V074gMbSLbgfyrY8r7q8V2im36HUDwTJKgpRnLG/j8y6ZH v0topxR2K6SoJ5h3jYumf4+9aViMH9MZ5kCh3RO0jUaj18wNtw5/U0XH5scot3Li OhujO2T2AZhN/AUtu93nMLI/xyP+ETbIOmrRFlxsoBe1qHIELdVbcx+6QXE58aYK mNS0+udx/+I8SnHrzaWbVA6lR+fa9AWWtpKOHUY+OgRLwbl6QvJUNuwuWgB4WV8/ +VjhDJVjzJ4q8WtPnMwdrI9my+YRNoGc0VUQKestA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrieekgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgspgfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepudduledrledrgeefrddvgedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgepvd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 24202D6005A for ; Sat, 12 Oct 2019 20:45:49 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 1B2D6C284F for ; Sun, 13 Oct 2019 00:45:46 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3461197537197109347==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: tls@ietf.org Message-Id: <20191013004546.1B2D6C284F@cloud.mnot.net> Date: Sun, 13 Oct 2019 00:45:46 +0000 (UTC) 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, 13 Oct 2019 00:46:06 -0000 --===============3461197537197109347== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/tls-subcerts (+0/-4/=F0=9F=92=AC12) 2 issues received 12 new comments: - #28 PSS (11 by grittygrease, siyengar, wbl, cjpatton, martinthomson) https://github.com/tlswg/tls-subcerts/issues/28 = - #33 Consider changing name from "Delegated Credentials" to "Delegated A= uthentication Keys" (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/33 = 4 issues closed: - Author affiliation https://github.com/tlswg/tls-subcerts/issues/29 = - Time to cut ties with LURK? https://github.com/tlswg/tls-subcerts/issue= s/30 = - Update references to ACME and TLS 1.3 https://github.com/tlswg/tls-subc= erts/issues/32 = - Mention interaction of DCs and tickets https://github.com/tlswg/tls-sub= certs/issues/34 = Pull requests ------------- * tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Add description about "cipher suites" via an ESNIKeys extension (by pen= gin7384) https://github.com/tlswg/draft-ietf-tls-esni/pull/184 = * tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Addressing selfie attacks (by ms-s) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/22 = 1 pull requests merged: - Add some security considerations text https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/21 = * tlswg/dtls13-spec (+1/-2/=F0=9F=92=AC1) 1 pull requests submitted: - s/HKDR/HKDF. (by chris-wood) https://github.com/tlswg/dtls13-spec/pull/100 = 1 pull requests received 1 new comments: - #99 Change the key label for DTLS to be "dtls13". Note that we have to = (1 by chris-wood) https://github.com/tlswg/dtls13-spec/pull/99 = 2 pull requests merged: - s/HKDR/HKDF. https://github.com/tlswg/dtls13-spec/pull/100 = - Change the key label for DTLS to be "dtls13". Note that we have to https://github.com/tlswg/dtls13-spec/pull/99 = * tlswg/tls-subcerts (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Nick/lastissues (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/35 = 1 pull requests merged: - Nick/lastissues https://github.com/tlswg/tls-subcerts/pull/35 = * tlswg/sniencryption (+1/-2/=F0=9F=92=AC1) 1 pull requests submitted: - Minor nits for draft-08 (by huitema) https://github.com/tlswg/sniencryption/pull/47 = 1 pull requests received 1 new comments: - #46 Roman's last comments (1 by huitema) https://github.com/tlswg/sniencryption/pull/46 = 2 pull requests merged: - Minor nits for draft-08 https://github.com/tlswg/sniencryption/pull/47 = - Roman's last comments https://github.com/tlswg/sniencryption/pull/46 = Repositories tracked by this digest: ----------------------------------- * 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 --===============3461197537197109347== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday October 13, 2019

Issues

tlswg/tls-subcerts (+0/-4/=F0=9F=92=AC12)

2 issues received 12 new comments:

4 issues closed:

Pull requests

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

1 pull requests submitted:

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

1 pull requests submitted:

1 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

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

1 pull requests submitted:

1 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============3461197537197109347==-- From nobody Sun Oct 13 18:13:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90C112006A for ; Sun, 13 Oct 2019 18:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 NqFiE2QLnCvF for ; Sun, 13 Oct 2019 18:13:04 -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 6555712001A for ; Sun, 13 Oct 2019 18:13:04 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id p10so14467089qkg.8 for ; Sun, 13 Oct 2019 18:13:04 -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=3lyFAWmcFL4+4GtwfGNjeJ29L+P4p8aUWhBAS77PGM0=; b=T69GEWK9qZPSRvIsB86cJRtCzxcfXI3l03UnwXWX5Hd/3PPlL+gkAbPdMgvAxJMBff 8rbXRegcramTAHuLCsfNBpIZ5T/iffxha+qSV+U6rFuRG0IB29YSUESvJDvDYUFVaw5u B2m9nATngxVk1g/PiEB/Ya9ElGNQpb7ALgJ7M= 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=3lyFAWmcFL4+4GtwfGNjeJ29L+P4p8aUWhBAS77PGM0=; b=aHuoaCKga2EMPhaA1JYozE5czCCXyKZk1apEbToecU/G9j96qVf0Z/VDxCfYOkIQYx 7ywkFOes6QbloJAbnTSa7yYRYnDOGcx0JhuJxJpU+1hLKDwpfen5d78OX4HD45w4T09Y jkY6n0eZCwY+ikfDOOHI+uN34XdfeoL4X1TF94uJ7YFqqnvCuNmw5hkKMF9QzzDQMPJW 8veEDrNoPQQdtg5elZd2GLcA4JHZRf7QcdIAg5zTJrX7Acr/XF6rCghGH5xESP0X66T+ l2CQHmQ5swGTzmSJh43ntBFpPnnrGhW55ZDW2cG+OjvqiJaALS/GjsFGp/jgNsapEE9w qAHg== X-Gm-Message-State: APjAAAVqNzlo+RS+kB7PNnYHYqyuZDitUCO+4icsW5OlVmUwDCLYoQ6I 8bO47PanOdnDVHAYImGnxBls03DpB74= X-Google-Smtp-Source: APXvYqwIDhtYALz8ZHJpAuV3CtaPYr2so/MzyrstJXEBg6gWearpHkAbIZ7maStXbXGzaKpOcPviJA== X-Received: by 2002:a05:620a:b07:: with SMTP id t7mr26767161qkg.382.1571015583196; Sun, 13 Oct 2019 18:13:03 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id r19sm8579517qte.63.2019.10.13.18.13.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Oct 2019 18:13:02 -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 12.4 \(3445.104.11\)) Message-Id: <12219D44-9FB9-4B55-9B86-6B9AB4FCC5C5@sn3rd.com> Date: Sun, 13 Oct 2019 21:13:01 -0400 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] 2nd WGLC for draft-ietf-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 01:13:06 -0000 This is the second working group last call for the "The Datagram = Transport Layer Security (DTLS) Protocol Version 1.3" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please review the document and send your comments to the list by 2359 UTC on 28 October 2019. Please note that we are now on at version -33. -30 was the subject of = the 1st WGLC and the WG should focus on changes introduced since -30 version. Diffs between -30 and -33 can be found at: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-30&url2=3Ddraft-= ietf-tls-dtls13-33 Note the the GH repo for this draft can be found at: https://github.com/tlswg/dtls13-spec Thanks, Chris, Joe, and Sean= From nobody Tue Oct 15 15:35:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6432712087E for ; Tue, 15 Oct 2019 15:35:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 4kUBW9--c2QY for ; Tue, 15 Oct 2019 15:35:01 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 0135F120814 for ; Tue, 15 Oct 2019 15:35:00 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id n2so6601516ual.11 for ; Tue, 15 Oct 2019 15:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/rSf3ql5W0IfLgTz+z0PoxvupGkWvm3TBnuxOeluNKs=; b=OG12o5WNBnrGaKX+gtMuu58HzSINX1240lIvQok2cC4Po1ArNmZLHy2b0M4zsVIJfz qsiPhw2WcWFV694ClLV3sbMyHPalyt22PLRQyUd6PUFkbFWZDyTb26xYsbomr14YEMtX Cv3jjzqkWRk57y/oPQ8B7Lw99gYXC6fu3iYwM= 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=/rSf3ql5W0IfLgTz+z0PoxvupGkWvm3TBnuxOeluNKs=; b=neUWbnlUAZvUF7uA5zZnTpJdSYHp3EPprAsVavqUmblZt2NNV8uPXyZkuGxon6XUuq jlFjLkW/z62zNiImXOyMmeezMZaihNSQ93LGUM1jQtAmiyN448lzhoaJ9a4xyp0eEGcx 6ejXS3MCMPW2BwLD+1q63tH5VHeDSuQqfriZupAkNiCoNmg6Bz/NuiOJ28Bog5FqeArd C8FEx/uQxYtInwR+Mt76nnkB7l0Z3RqbmjK5eL2hmHbOviWpOaPNcG7P1oyxua+U6jzc Rl2IcawG7aF6YBAZYps8QN5Ev3bpHTWSedVMMM0SgoWXHWtcsCSh6BZGYkmmNEPo+sf6 CzGw== X-Gm-Message-State: APjAAAUYwk7XblyvR4dOF1bXyxsVhQz2R2ZPO/l13ZYqKQtTVbieEHoJ TR9RYm30p+ydQ+xyJiKVhZTnFllmRevcveG36WOW92Pbwmo5Hw== X-Google-Smtp-Source: APXvYqzcI4sY4VLKScI0J1ESd8c+zgxPToDBPpM0sGQYhtw0/2Np92xL6wqZn0iXebG86e04FqqQRgAVjso2nExDdTs= X-Received: by 2002:ab0:1c58:: with SMTP id o24mr17408150uaj.58.1571178899293; Tue, 15 Oct 2019 15:34:59 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Tue, 15 Oct 2019 15:34:43 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000002c27210594fa98ed" Archived-At: Subject: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2019 22:35:14 -0000 --0000000000002c27210594fa98ed Content-Type: text/plain; charset="UTF-8" TLSWG, I'd like some feedback on a potential issue raised by Martin Thomson at the last IETF. The question is about the interaction between the SPKI and the signature scheme for RSA delegated credentials. The main concern is around the interaction between the rsaEncryption OID and the signature scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not explicitly in DCs (yet). This issue is tracked on Github as issues/28 . Given the feedback on Github, I see two main choices to resolve this issue: 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_* signature schemes. 2) Forbid RSA Credentials with the rsaEncryption OID (and associated signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature schemes. Does anyone have a strong preference for one of these options? My take: The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be backward-compatible with existing rsaEncryption OID certs while enabling RSA-PSS. We don't have this legacy in delegated credentials, so I'm inclined to prefer 2). The only reason I see to go for 1) is the risk of implementation difficulties. The RSA PSS OIDs are hard to get right in code. However, considering that RSA DCs are unlikely to be widely used in favor of elliptic-curve DCs, the implementation risk seems low and restricted to implementations who choose to support RSA DCs as an optional feature. Nick --0000000000002c27210594fa98ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TLSWG,

I'd like some fee= dback on a potential issue raised by Martin Thomson at the last IETF. The q= uestion is about the interaction between=C2=A0the SPKI and the signature sc= heme for RSA delegated credentials. The main concern is around the interact= ion between the rsaEncryption OID and the signature scheme, specifically PK= CS#1v1.5, which we disallow in TLS 1.3 but not explicitly in DCs (yet). Thi= s issue is tracked on Github as=C2=A0issues/28.

Gi= ven the feedback on Github, I see two main choices to resolve=C2=A0this iss= ue:

1) Allow RSA Credentials with the rsaEncryption OID in th= e SPKI to be used with the rsa_pss_rsae_* signature schemes, but disallow r= sa_pkcs1_* signature schemes.
2) Forbid RSA Credentials with the rsaEncr= yption OID (and associated signature schemes) and require an RSA PSS OIDs f= or rsa_pss_pss_* signature schemes.

Does anyone ha= ve a strong preference for one of these options?

M= y take:
The rsa_pss_rsae_* suites are a hack created to allow TLS= 1.3 to be backward-compatible with existing rsaEncryption OID certs while = enabling RSA-PSS. We don't have this legacy in delegated credentials, s= o I'm inclined to prefer 2).

The only reas= on I see to go for 1) is the risk of implementation difficulties. The RSA P= SS OIDs are hard to get right in code. However, considering that RSA DCs ar= e unlikely to be widely used in favor of elliptic-curve DCs, the implementa= tion risk seems low and restricted to implementations who choose to support= RSA DCs as an optional feature.

Nick

--0000000000002c27210594fa98ed-- From nobody Tue Oct 15 15:58:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2921D120104 for ; Tue, 15 Oct 2019 15:58:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 BrgqN_IUy_Uu for ; Tue, 15 Oct 2019 15:58:31 -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 C9AD912003E for ; Tue, 15 Oct 2019 15:58:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F173A300AB7 for ; Tue, 15 Oct 2019 18:58:29 -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 TF-R9op9dA8l for ; Tue, 15 Oct 2019 18:58:28 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 171003004AF; Tue, 15 Oct 2019 18:58:28 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0C498091-7628-4E45-A9E8-A10680E4429B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 15 Oct 2019 18:58:28 -0400 In-Reply-To: Cc: IETF TLS To: Nick Sullivan References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 15 Oct 2019 22:58:34 -0000 --Apple-Mail=_0C498091-7628-4E45-A9E8-A10680E4429B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii When we were working on RFC 4055, we thought it would be important to = allow a certified RSA public key to be bound to a specific algorithm = (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it = would be important for the certified RSA public key to be used with any = of the algorithms (constrained by key usage extension). Section 1.2 says: The rsaEncryption object identifier continues to identify the subject public key when the RSA private key owner does not wish to limit the use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. ... When the RSA private key owner wishes to limit the use of the public key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object identifier MUST be used in the algorithm field within the subject public key information ... When the RSA private key owner wishes to limit the use of the public key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object identifier MUST be used in the algorithm field within the subject public key information ... I would like to continue with the approach. Russ > On Oct 15, 2019, at 6:34 PM, Nick Sullivan = wrote: >=20 > TLSWG, >=20 > I'd like some feedback on a potential issue raised by Martin Thomson = at the last IETF. The question is about the interaction between the SPKI = and the signature scheme for RSA delegated credentials. The main concern = is around the interaction between the rsaEncryption OID and the = signature scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 = but not explicitly in DCs (yet). This issue is tracked on Github as = issues/28 . >=20 > Given the feedback on Github, I see two main choices to resolve this = issue: >=20 > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be = used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_* = signature schemes. > 2) Forbid RSA Credentials with the rsaEncryption OID (and associated = signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* = signature schemes. >=20 > Does anyone have a strong preference for one of these options? >=20 > My take: > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be = backward-compatible with existing rsaEncryption OID certs while enabling = RSA-PSS. We don't have this legacy in delegated credentials, so I'm = inclined to prefer 2). >=20 > The only reason I see to go for 1) is the risk of implementation = difficulties. The RSA PSS OIDs are hard to get right in code. However, = considering that RSA DCs are unlikely to be widely used in favor of = elliptic-curve DCs, the implementation risk seems low and restricted to = implementations who choose to support RSA DCs as an optional feature. >=20 > Nick >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_0C498091-7628-4E45-A9E8-A10680E4429B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii When = we were working on RFC 4055, we thought it would be important to allow a = certified RSA public key to be bound to a specific algorithm (e.g., = RSA-PSS or RSA-OAEP).  However, in transition, we thought it would = be important for the certified RSA public key to be used with any of the = algorithms (constrained by key usage extension).

Section 1.2 says:

  =  The rsaEncryption object identifier continues to identify the = subject
   public key when the RSA = private key owner does not wish to limit the
  =  use of the public key exclusively to either RSASSA-PSS or = RSAES-OAEP.

   ...

   When the RSA private key owner = wishes to limit the use of the public
  =  key exclusively to RSASSA-PSS, then the id-RSASSA-PSS = object
   identifier MUST be used in the = algorithm field within the subject
  =  public key information ...

   When the RSA private key = owner wishes to limit the use of the public
  =  key exclusively to RSAES-OAEP, then the id-RSAES-OAEP = object
   identifier MUST be used in the = algorithm field within the subject
  =  public key information ...

I would like to continue with the = approach.

Russ


On Oct = 15, 2019, at 6:34 PM, Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org> = wrote:

TLSWG,

I'd like some feedback on a potential = issue raised by Martin Thomson at the last IETF. The question is about = the interaction between the SPKI and the signature scheme for RSA = delegated credentials. The main concern is around the interaction = between the rsaEncryption OID and the signature scheme, specifically = PKCS#1v1.5, which we disallow in TLS 1.3 but not explicitly in DCs = (yet). This issue is tracked on Github as issues/28.

Given the feedback on Github, I see two = main choices to resolve this issue:

1) Allow RSA Credentials with the rsaEncryption OID in the = SPKI to be used with the rsa_pss_rsae_* signature schemes, but disallow = rsa_pkcs1_* signature schemes.
2) Forbid RSA Credentials = with the rsaEncryption OID (and associated signature schemes) and = require an RSA PSS OIDs for rsa_pss_pss_* signature schemes.

Does anyone have a = strong preference for one of these options?

My take:
The = rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be = backward-compatible with existing rsaEncryption OID certs while enabling = RSA-PSS. We don't have this legacy in delegated credentials, so I'm = inclined to prefer 2).

The only reason I see to go for 1) is = the risk of implementation difficulties. The RSA PSS OIDs are hard to = get right in code. However, considering that RSA DCs are unlikely to be = widely used in favor of elliptic-curve DCs, the implementation risk = seems low and restricted to implementations who choose to support RSA = DCs as an optional feature.

Nick

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

= --Apple-Mail=_0C498091-7628-4E45-A9E8-A10680E4429B-- From nobody Tue Oct 15 17:00:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BAC120835 for ; Tue, 15 Oct 2019 17:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=JHaPkc3D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B7Lj/mL7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wIUImiOcgF7 for ; Tue, 15 Oct 2019 17:00:20 -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 A4685120864 for ; Tue, 15 Oct 2019 17:00:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D145F21D6E for ; Tue, 15 Oct 2019 20:00:19 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Tue, 15 Oct 2019 20:00:19 -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=fm3; bh=Uare7ANPQW/TtfiP3QCb0jxD2C2oM8L RlRf0hOkHT94=; b=JHaPkc3DIjuUr+tmJqUH0sNMT3EkoZkfM6lFhTAPrlFCLY1 h+Zs8lLWfxjAsKMvmhpAEjZku4p3wRhEcVC03r7+KVwl4y6zmpF9dtdnHBOGYvid vLMBtbuHlRPL8GhqJglS14q7vdYVhAPa+5Zc5SKTx58w+WyiqRRy1zo/N2kJgdAv AxuXuyEh+T/JFpEyddFp8Cg+Br3RZNVDhCekq2dPuzaYivacOer9ue/BjvE/Q0VU ExewnDwrMmODMruHWWV8X8zR0DrtnW1wDmvoYnS77QCXR9lGrdyumsXK80gYMaVA bU70fvIgD3VjPDV/J1BcSIKHa8VZtyE8GWReH4Q== 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=fm1; bh=Uare7A NPQW/TtfiP3QCb0jxD2C2oM8LRlRf0hOkHT94=; b=B7Lj/mL7R+ZHg0mAM0A/0m ijMcxOSsUC/moVLzRJLwI7SLOqYOD5g5RiUnK/ThNlCdlTUiqdRRgnHPhxWEuasX /fLvgbyk+5l0HJ5+jAo5G/MuN7I8zUt522gAs8wXEkPPtEcfMQF9S1p8w6NdhOCc eZQ37rn5kXHR4UVbKo64utYYfmxd0uErPkBxB/FPuGP2N299Z6hlTP/qEHbrxziX mIbk8Eo1SdOtcRMUWC37RZqKuAiIXl1B2QRN8+k8cu8JE+bqDiGYkm1i+qupp1jn iPWIfPpABqFt9Ob8Ji6a6bIEItz8xblMfxFQVEfsOCl3akQRKDUhOBqnFMrCoqag == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeeggddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophih rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4C134E00A5; Tue, 15 Oct 2019 20:00:19 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> In-Reply-To: References: Date: Tue, 15 Oct 2019 16:59:59 -0700 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2019 00:00:26 -0000 I think that what Nick proposes is consistent with this, and it also matches my preference. Requiring a PSS OID is nice in that it creates a strong constraint. However, there is a wrinkle. The way you signal support for the signature scheme is through the signature_algorithms extension. If you advertise rsa_pss_pss_*, then that means that you are also indicating support for an end entity certificate with a PSS SPKI. Some certificate validation software hasn't been updated to support that and might choke if they got a PSS SPKI in a certificate. I don't know if we could support RSA without double checking our code. Adding support shouldn't be too hard, and we don't current advertise PSS support, so it's not a complete deal breaker for us, but it's worth highlighting. On Tue, Oct 15, 2019, at 15:58, Russ Housley wrote: > When we were working on RFC 4055, we thought it would be important to > allow a certified RSA public key to be bound to a specific algorithm > (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it > would be important for the certified RSA public key to be used with any > of the algorithms (constrained by key usage extension). > > Section 1.2 says: > > The rsaEncryption object identifier continues to identify the subject > public key when the RSA private key owner does not wish to limit the > use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. > > ... > > When the RSA private key owner wishes to limit the use of the public > key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object > identifier MUST be used in the algorithm field within the subject > public key information ... > > When the RSA private key owner wishes to limit the use of the public > key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object > identifier MUST be used in the algorithm field within the subject > public key information ... > > I would like to continue with the approach. > > Russ > > > > On Oct 15, 2019, at 6:34 PM, Nick Sullivan wrote: > > > > TLSWG, > > > > I'd like some feedback on a potential issue raised by Martin Thomson at the last IETF. The question is about the interaction between the SPKI and the signature scheme for RSA delegated credentials. The main concern is around the interaction between the rsaEncryption OID and the signature scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not explicitly in DCs (yet). This issue is tracked on Github as issues/28 . > > > > Given the feedback on Github, I see two main choices to resolve this issue: > > > > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_* signature schemes. > > 2) Forbid RSA Credentials with the rsaEncryption OID (and associated signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature schemes. > > > > Does anyone have a strong preference for one of these options? > > > > My take: > > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be backward-compatible with existing rsaEncryption OID certs while enabling RSA-PSS. We don't have this legacy in delegated credentials, so I'm inclined to prefer 2). > > > > The only reason I see to go for 1) is the risk of implementation difficulties. The RSA PSS OIDs are hard to get right in code. However, considering that RSA DCs are unlikely to be widely used in favor of elliptic-curve DCs, the implementation risk seems low and restricted to implementations who choose to support RSA DCs as an optional feature. > > > > Nick > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Oct 15 17:13:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88982120830 for ; Tue, 15 Oct 2019 17:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mt99pDvaDXQU for ; Tue, 15 Oct 2019 17:13:31 -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 AFD8312082D for ; Tue, 15 Oct 2019 17:13:31 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id v10so14419403vsc.7 for ; Tue, 15 Oct 2019 17:13:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UgZUpnuOddeC5JqTUMsId07lmxmlTlp7tdlr0H5NvmA=; b=KyXZJfsFIlOhMUiP+nP2+tOTtDHMkhkqru2EpsrCvUZPF3hO9o77TaTqkYXS4Rrprv zhbCKkf1QYxDHd3JFDaVybO7duGtQJCxEDJlBrX9lGKRKbPtcvscpatOFv73lnxRRYiF zUsTTxmdT4Ax4WVwjlYIRsH4XteGM9i1nNiDE= 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=UgZUpnuOddeC5JqTUMsId07lmxmlTlp7tdlr0H5NvmA=; b=sWYQ6+LD3OwcAcneI4wwQRE0a0US9UlrednuiPxIbatX9mrQZvfW0k6zinb77E8Pkt iXOqZEpTjabEmbhqzMtoScPTv89IcXfH+hr5p7SzNESmBpW95Mb52jq5/LOpId0V7uT4 3L3AdwtJpuW/AyqNjaPMA2Vk7oCdtX2SglvA3NCwF7370m1M0lXB3mpjrJd2T/wttMzz MhrUU1fblpCogFxuAdvfqx4h2A+euCNkPosOqma4wRSxt6vwhgdFaWuiXlhcpujIT2gQ C3irFDscH3J/KfB/4kqHFEi6VLXy28zDangyrS9c/2uK0RNVb1YX8nTpH2zTn+XZKdaU TgYQ== X-Gm-Message-State: APjAAAVAkBGwUJEvBYMeE0SYEwt3uP+0MSP1AJTLpgtqhpt8Z06WX/cS i3CxaUYz+BF9Ub4AwygCXjHsgpAFRLm0WJ/oeZTQt5wuCYgs2Q== X-Google-Smtp-Source: APXvYqy4lbQt0p+VncvkpTySMahxTrUpPzT+rlQGe9T4oRZJeieIHJV9JETJ2yusQKZByTCFlezJecstrKMlY7kFUYQ= X-Received: by 2002:a67:f98b:: with SMTP id b11mr21403868vsq.53.1571184810470; Tue, 15 Oct 2019 17:13:30 -0700 (PDT) MIME-Version: 1.0 References: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> In-Reply-To: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> From: Nick Sullivan Date: Tue, 15 Oct 2019 17:13:13 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="0000000000008170eb0594fbf822" Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2019 00:13:35 -0000 --0000000000008170eb0594fbf822 Content-Type: text/plain; charset="UTF-8" One may note that no matter what the choice is with respect to RSA, this particular wrinkle also applies more broadly. For example, if a client advertises support for ed25519 in "signature_algorithms" in order to support ed25519 delegated credentials, it should also be prepared to receive an ed25519 certificate. Nick On Tue, Oct 15, 2019 at 5:00 PM Martin Thomson wrote: > I think that what Nick proposes is consistent with this, and it also > matches my preference. Requiring a PSS OID is nice in that it creates a > strong constraint. > > However, there is a wrinkle. The way you signal support for the signature > scheme is through the signature_algorithms extension. If you advertise > rsa_pss_pss_*, then that means that you are also indicating support for an > end entity certificate with a PSS SPKI. Some certificate validation > software hasn't been updated to support that and might choke if they got a > PSS SPKI in a certificate. > > I don't know if we could support RSA without double checking our code. > Adding support shouldn't be too hard, and we don't current advertise PSS > support, so it's not a complete deal breaker for us, but it's worth > highlighting. > > On Tue, Oct 15, 2019, at 15:58, Russ Housley wrote: > > When we were working on RFC 4055, we thought it would be important to > > allow a certified RSA public key to be bound to a specific algorithm > > (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it > > would be important for the certified RSA public key to be used with any > > of the algorithms (constrained by key usage extension). > > > > Section 1.2 says: > > > > The rsaEncryption object identifier continues to identify the subject > > public key when the RSA private key owner does not wish to limit the > > use of the public key exclusively to either RSASSA-PSS or RSAES-OAEP. > > > > ... > > > > When the RSA private key owner wishes to limit the use of the public > > key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object > > identifier MUST be used in the algorithm field within the subject > > public key information ... > > > > When the RSA private key owner wishes to limit the use of the public > > key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object > > identifier MUST be used in the algorithm field within the subject > > public key information ... > > > > I would like to continue with the approach. > > > > Russ > > > > > > > On Oct 15, 2019, at 6:34 PM, Nick Sullivan 40cloudflare.com@dmarc.ietf.org> wrote: > > > > > > TLSWG, > > > > > > I'd like some feedback on a potential issue raised by Martin Thomson > at the last IETF. The question is about the interaction between the SPKI > and the signature scheme for RSA delegated credentials. The main concern is > around the interaction between the rsaEncryption OID and the signature > scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not > explicitly in DCs (yet). This issue is tracked on Github as issues/28 < > https://github.com/tlswg/tls-subcerts/issues/28>. > > > > > > Given the feedback on Github, I see two main choices to resolve this > issue: > > > > > > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI to be > used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1_* > signature schemes. > > > 2) Forbid RSA Credentials with the rsaEncryption OID (and associated > signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signature > schemes. > > > > > > Does anyone have a strong preference for one of these options? > > > > > > My take: > > > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to be > backward-compatible with existing rsaEncryption OID certs while enabling > RSA-PSS. We don't have this legacy in delegated credentials, so I'm > inclined to prefer 2). > > > > > > The only reason I see to go for 1) is the risk of implementation > difficulties. The RSA PSS OIDs are hard to get right in code. However, > considering that RSA DCs are unlikely to be widely used in favor of > elliptic-curve DCs, the implementation risk seems low and restricted to > implementations who choose to support RSA DCs as an optional feature. > > > > > > Nick > > > > > > _______________________________________________ > > > 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 > --0000000000008170eb0594fbf822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One may note that no matter what the choice is with respec= t to RSA, this particular wrinkle also applies more broadly. For example, i= f a client advertises support for=C2=A0ed25519 in "signature_algorithm= s" in order to support ed25519 delegated credentials, it should also b= e prepared to receive an ed25519 certificate.=C2=A0

Nick=

On Tue, Oct 15, 2019 at 5:00 PM Martin Thomson <mt@lowentropy.net> wrote:
I think that what Nick proposes is cons= istent with this, and it also matches my preference.=C2=A0 Requiring a PSS = OID is nice in that it creates a strong constraint.

However, there is a wrinkle.=C2=A0 The way you signal support for the signa= ture scheme is through the signature_algorithms extension.=C2=A0 If you adv= ertise rsa_pss_pss_*, then that means that you are also indicating support = for an end entity certificate with a PSS SPKI.=C2=A0 Some certificate valid= ation software hasn't been updated to support that and might choke if t= hey got a PSS SPKI in a certificate.

I don't know if we could support RSA without double checking our code.= =C2=A0 Adding support shouldn't be too hard, and we don't current a= dvertise PSS support, so it's not a complete deal breaker for us, but i= t's worth highlighting.

On Tue, Oct 15, 2019, at 15:58, Russ Housley wrote:
> When we were working on RFC 4055, we thought it would be important to =
> allow a certified RSA public key to be bound to a specific algorithm <= br> > (e.g., RSA-PSS or RSA-OAEP). However, in transition, we thought it > would be important for the certified RSA public key to be used with an= y
> of the algorithms (constrained by key usage extension).
>
> Section 1.2 says:
>
>=C2=A0 The rsaEncryption object identifier continues to identify the su= bject
>=C2=A0 public key when the RSA private key owner does not wish to limit= the
>=C2=A0 use of the public key exclusively to either RSASSA-PSS or RSAES-= OAEP.
>
>=C2=A0 ...
>
>=C2=A0 When the RSA private key owner wishes to limit the use of the pu= blic
>=C2=A0 key exclusively to RSASSA-PSS, then the id-RSASSA-PSS object
>=C2=A0 identifier MUST be used in the algorithm field within the subjec= t
>=C2=A0 public key information ...
>
>=C2=A0 When the RSA private key owner wishes to limit the use of the pu= blic
>=C2=A0 key exclusively to RSAES-OAEP, then the id-RSAES-OAEP object
>=C2=A0 identifier MUST be used in the algorithm field within the subjec= t
>=C2=A0 public key information ...
>
> I would like to continue with the approach.
>
> Russ
>
>
> > On Oct 15, 2019, at 6:34 PM, Nick Sullivan <nick=3D40cloudflare.com@= dmarc.ietf.org> wrote:
> >
> > TLSWG,
> >
> > I'd like some feedback on a potential issue raised by Martin = Thomson at the last IETF. The question is about the interaction between the= SPKI and the signature scheme for RSA delegated credentials. The main conc= ern is around the interaction between the rsaEncryption OID and the signatu= re scheme, specifically PKCS#1v1.5, which we disallow in TLS 1.3 but not ex= plicitly in DCs (yet). This issue is tracked on Github as issues/28 <https://github.com/tlswg/tls-subcerts/issues/28>.=
> >
> > Given the feedback on Github, I see two main choices to resolve t= his issue:
> >
> > 1) Allow RSA Credentials with the rsaEncryption OID in the SPKI t= o be used with the rsa_pss_rsae_* signature schemes, but disallow rsa_pkcs1= _* signature schemes.
> > 2) Forbid RSA Credentials with the rsaEncryption OID (and associa= ted signature schemes) and require an RSA PSS OIDs for rsa_pss_pss_* signat= ure schemes.
> >
> > Does anyone have a strong preference for one of these options? > >
> > My take:
> > The rsa_pss_rsae_* suites are a hack created to allow TLS 1.3 to = be backward-compatible with existing rsaEncryption OID certs while enabling= RSA-PSS. We don't have this legacy in delegated credentials, so I'= m inclined to prefer 2).
> >
> > The only reason I see to go for 1) is the risk of implementation = difficulties. The RSA PSS OIDs are hard to get right in code. However, cons= idering that RSA DCs are unlikely to be widely used in favor of elliptic-cu= rve DCs, the implementation risk seems low and restricted to implementation= s who choose to support RSA DCs as an optional feature.
> >
> > Nick
> >
> >=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
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008170eb0594fbf822-- From nobody Wed Oct 16 06:40:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0D5120108; Wed, 16 Oct 2019 06:40:46 -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_NONE=-0.0001, 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=armh.onmicrosoft.com header.b=dU21wJib; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=u2QCBJVt Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8BWV_inwGqD; Wed, 16 Oct 2019 06:40:44 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20047.outbound.protection.outlook.com [40.107.2.47]) (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 CACF9120103; Wed, 16 Oct 2019 06:40:43 -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=R0tnCGmANZf3GrIqw0BDtJZTpNRpZ8EisQcJTBDQ+Rk=; b=dU21wJib1sr2CzbnnlqTF8/TXg2BNHBjBLvq2kT3psdAzp24d+ewRtZQFH0y6mIi7kd4OG0w5r4oZ7uHJjdEfBvVUnY0DBH/zmhRn2O2+mmkAgnQSqIffuRfIx2VFTKPXKv0dyiwYGNxozVhZHN0hqr88yM2SU8NhT+rlflHjEs= Received: from VE1PR08CA0022.eurprd08.prod.outlook.com (2603:10a6:803:104::35) by AM6PR08MB3989.eurprd08.prod.outlook.com (2603:10a6:20b:b0::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Wed, 16 Oct 2019 13:40:37 +0000 Received: from DB5EUR03FT059.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::209) by VE1PR08CA0022.outlook.office365.com (2603:10a6:803:104::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Wed, 16 Oct 2019 13:40:37 +0000 Authentication-Results: spf=fail (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=none action=none header.from=arm.com; Received-SPF: Fail (protection.outlook.com: domain of arm.com does not designate 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT059.mail.protection.outlook.com (10.152.21.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Wed, 16 Oct 2019 13:40:36 +0000 Received: ("Tessian outbound 6481c7fa5a3c:v33"); Wed, 16 Oct 2019 13:40:34 +0000 X-CR-MTA-TID: 64aa7808 Received: from 55f405c3df37.1 (ip-172-16-0-2.eu-west-1.compute.internal [104.47.12.59]) by 64aa7808-outbound-1.mta.getcheckrecipient.com id 389183F3-6152-406E-AA60-99060F22B9F3.1; Wed, 16 Oct 2019 13:40:29 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2059.outbound.protection.outlook.com [104.47.12.59]) by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 55f405c3df37.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 16 Oct 2019 13:40:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PqiMFFTY//nsfVJpHW4bTPRaLIV35Tn5ySXagEmUUKKGn71ushMx7jBxph7N1feQq0tnFRwi7wEC3AGzq4ngIkbdrZ9Y2xyXfSATSts7U9kckwxpiQ34bHRygZ0FHPjZzmAUGXTS9BUqLzFzlB0eMoEPubW9wwRzFbLm6AaG9btG/xXDvOZzp3VmZn4Z86nnS7OI0yl3vU6OywwNX2FgOcUnfdzUSktP8IynnUDuIauvLfe1xLUb7zGaJxxKlmQCDh2LwLbj48/BMr/XKlnGIFOlbvoBlP8rfi6LvQTn+iAU9j1ENpzk8DgH2gPb+hPjRoq/0NYn6XewV69t/E1F3g== 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=cR5N/Bq366amcpSju8DCspeN2eGyC9NqxzjgEZyxRHc=; b=PTdIQ8bAlejF3BTV6TCryX6n7qI9s3ozetvKpLTW6QGpWeOX9Sbl9+SnABag+anHoh/rNfZ1rPcdjNmrvevIzpNbzIkCnuluYIH/bsxEP6qJJSJBP1VHubLDvCyEIPPBB74/FL9gWswLQ/x8QYMIFfRNU3CaPIGLtce3NQOuWYRaXtjkQYMndpG5ORx/OE7llPG2UwxSENaA2/BVrCQPQob3qBpuHYVLo1nz6scFiw+q0nR5U2bIaLbpkCUC94t2QQ0JGQwFNn/4AIRZ24yLQ/g4rLuyzeorJloc7ZhcmPRe8f7dNlt0cYYKW5NB50kP85viVczu0nlVzsfXrDj8/g== 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=cR5N/Bq366amcpSju8DCspeN2eGyC9NqxzjgEZyxRHc=; b=u2QCBJVtobTNozvJq82OU8Z7mnGmLEQob9AL5BrgbP7xzvSIY9Cx1KbXETblLae082ZZqpUbgV9z9fDTSCA/1em3IRHj455zWOnc7LhtEjN1N0vdWx3M/02vyn+LUbcqjJ1jsIMat9aAoqJfoYETTccnmSRgAKUsk9/oXT4liMo= Received: from VI1PR08MB5360.eurprd08.prod.outlook.com (52.133.245.74) by VI1PR08MB3870.eurprd08.prod.outlook.com (20.178.80.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Wed, 16 Oct 2019 13:40:27 +0000 Received: from VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31]) by VI1PR08MB5360.eurprd08.prod.outlook.com ([fe80::b003:8767:35c7:e31%2]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 13:40:27 +0000 From: Hannes Tschofenig To: John Mattsson , "hannes.tschofenig@gmx.net" , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVe2jJg2f9VjEFuEec6uHWJQ1CSKddU8Lw Date: Wed, 16 Oct 2019 13:40:27 +0000 Message-ID: References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> <024b01d5785d$51b3d7d0$f51b8770$@gmx.net> <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> In-Reply-To: <0B7954B0-275B-45BE-9353-695612B7F5D3@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 60c5849c-ccb4-4776-93b6-e0334875c308.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.123.83] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: b616f816-3cad-4943-5b92-08d7523e6d3f X-MS-Office365-Filtering-HT: Tenant X-MS-TrafficTypeDiagnostic: VI1PR08MB3870:|AM6PR08MB3989: X-MS-Exchange-PUrlCount: 1 X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:6790;OLM:6790; x-forefront-prvs: 0192E812EC X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(39860400002)(396003)(366004)(13464003)(189003)(199004)(305945005)(66556008)(6116002)(76116006)(66476007)(2906002)(2201001)(26005)(64756008)(6436002)(478600001)(6506007)(5660300002)(186003)(102836004)(53546011)(3846002)(966005)(74316002)(66946007)(33656002)(7736002)(66446008)(6246003)(7696005)(76176011)(11346002)(446003)(99286004)(66066001)(14454004)(71190400001)(71200400001)(8936002)(55016002)(486006)(52536014)(81166006)(476003)(2501003)(25786009)(8676002)(9686003)(81156014)(229853002)(14444005)(256004)(110136005)(86362001)(6306002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR08MB3870; H:VI1PR08MB5360.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: N9j5BWWyxcMhxg20NH5fD0GIBH1XQeSA+Ov114HFwAVIzkowWh3+hpumRo9z9zvZrnNO4pXAvrw5bNnl7/UaMzskwk5fDFft8/1aGJt5VuIdUoeGIK7d+PWIgbWFFYhsX4hxF7IqSiXaCsEAUYEqSfb30J8+p0iLc5mUGXyDWKxTCwLc2BMUMfV6N6srXLLz4yoZSC7Xpyc2JPO3ehiUPf9Ph3VE4FiWTBce6X5o0nH3PHozEpdFwqnokhxDoclMIthrpwwXN5wGyN/n+QxyWMHeipN8G83xZV+zD98nA5nLxXAnbmdEtIbgXHQfvNDSurj1Ivr52HWfJpF7FTISImCl7rjH/9jaYIcPpdc81luGYgQX+KLGy1OkzuBakn1Yv1mMhBduyBCG8LmFMETxtTV+DLSFjQRA6IhXqOQmbIaa8aLSuwOtbTPHBVdRZBuKFs2qphMcdslxb13gXQqjEQ== 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: VI1PR08MB3870 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT059.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(376002)(1110001)(339900001)(13464003)(199004)(189003)(40434004)(14444005)(11346002)(9686003)(336012)(446003)(47776003)(2201001)(6116002)(3846002)(8936002)(450100002)(74316002)(2906002)(33656002)(7736002)(229853002)(436003)(86362001)(5024004)(305945005)(52536014)(102836004)(6306002)(7696005)(70206006)(6506007)(53546011)(26826003)(22756006)(55016002)(14454004)(76130400001)(186003)(2501003)(76176011)(478600001)(26005)(966005)(5660300002)(316002)(476003)(8676002)(50466002)(81156014)(81166006)(99286004)(356004)(110136005)(486006)(6246003)(66066001)(70586007)(126002)(25786009)(23676004)(2486003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3989; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Fail; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 0f6e2a7c-f4b6-4c1b-669f-08d7523e67b3 X-Forefront-PRVS: 0192E812EC X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3ulNnLwMQ70mCKB6KErHTfxLvm+JdZvChcgewAo4h3U+mcEX7k9YWZK3szCbmuY+k5uuX5wdGjDFhaknTk7xmAZ3i0DDmQ59wpF56GcUAlw4hqHv45urChMEib8DmRjjwT587ghCgnBC95E3mdshS2A0jrEqHCh/xnO9Y6VZ5wiJ/VjuHUwVwdo8QBYj91aH8JdxJtVCHW1U4y6cfxeQCqBBf+2XLHpkQgaGJlb4kAKR6NUKYhDcrj3cVQwY6gydml1nZQnPeih2ys3UedGkTGaWlfttPWfZcxWu86zmk5+KIyBUaYNnh92GThClZQuzARxrwk9h69jBJEFE5eTfHNYm4SkvBCcgS/FuN/jA1pft8KfxYM+8cviP307FrLyvrlKleUQuSegDpr95n+UlHE7wRpTzIq3isMw9J564gTlGtktV8Gt5F+ZhUFPcLtt7IlsSbC4gtgJgx1gK0uYHIA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Oct 2019 13:40:36.9812 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b616f816-3cad-4943-5b92-08d7523e6d3f X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3989 Archived-At: Subject: Re: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2019 13:40:47 -0000 Sm9obiwgIHlvdSByZWZlcmVuY2UgUkZDIDc1NDAgYW5kIEkgYmVsaWV2ZSB5b3Ugd2FudGVkIHRv IHJlZmVyIHRvIFJGQyA3OTI1IGluc3RlYWQuDQoNClJGQyA3OTI1IHRhbGtzIGFib3V0IHRoZSBF eHRlbmRlZCBNYXN0ZXIgU2VjcmV0IGV4dGVuc2lvbiwgU2lnbmF0dXJlIEFsZ29yaXRobSBleHRl bnNpb24sIGFuZA0KT0NTUCBzdGFwbGluZy4NCg0KQ2lhbw0KSGFubmVzDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYWFnIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBKb2huIE1hdHRzc29uDQpTZW50OiBTYW1zdGFnLCA1LiBPa3RvYmVyIDIwMTkgMTI6 MzYNClRvOiBoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0OyBUTFNAaWV0Zi5vcmc7IHNhYWdAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2FhZ10gW1RMU10gTGVzc29ucyBsZWFybmVkIGZyb20gVExT IDEuMCBhbmQgVExTIDEuMSBkZXByZWNhdGlvbg0KDQoiaGFubmVzLnRzY2hvZmVuaWdAZ214Lm5l dCIgPGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ+IHdyb3RlOg0KDQo+IFBTOiBBcyBLYXRobGVl biBub3RlZCBUTFMgMS4yIGFuZCBEVExTIDEuMiBhcmUgcGVyZmVjdGx5IGZpbmUgaWYgeW91IGZv bGxvdyBSRkMgNzkyNS83NTI1Lg0KDQpXaGlsZSBUTFMgMS4yIGFuZCBEVExTIDEuMiBjYW4gYmUg Y29uZmlndXJlZCB0byBiZSBzZWN1cmUsIFJGQyA3NTI1IGlzIGRlZmluaXRlbHkgbm90IGVub3Vn aC4gUkZDIDc1NDAgd291bGQgYmUgYSBnb29kIHN0YXJ0LCBidXQgYWxzbyB0aGF0IHdvdWxkIG5l ZWQgdG8gYmUgZXh0ZW5kZWQgd2l0aCBzdXBwb3J0IG9mIGV4dGVuc2lvbnMgbGlrZSBFeHRlbmRl ZCBNYXN0ZXIgU2VjcmV0LCBTaWduYXR1cmUgQWxnb3JpdGhtcywgYW5kIENlcnRpZmljYXRlIFN0 YXR1cyBSZXF1ZXN0IHRvIGJlIGNvbnNpZGVyZWQgZmluZSBpbiAyMDE5Lg0KDQpDaGVlcnMsDQpK b2huDQoNCu+7vw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzYWFnIG1haWxpbmcgbGlzdA0Kc2FhZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo= From nobody Wed Oct 16 16:13:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5D512010F for ; Wed, 16 Oct 2019 16:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=pRPtLt+t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OYpZ9rmO Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fopCkoRcaUxR for ; Wed, 16 Oct 2019 16:13:29 -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 0540312092E for ; Wed, 16 Oct 2019 16:13:28 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 40BFE1437; Wed, 16 Oct 2019 19:13:28 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 16 Oct 2019 19:13: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=fm3; bh=en0s/q7cYsymziTGHGD0Pqpe9So0 AUrTFmb1uoz6Ujo=; b=pRPtLt+tD26+mySGXlo+oLXn0hM6mR4o94m4AI4fsq/H o8rJSiEHDmX293fuMAsFDjbrBkyn99EOlVjqK999mJbWtnpMu8B5eO5p6xQfWkVn 816BFpmAmpR75z9YENL0UnMXGRj4L13gmgz6pqGLU02nEkcm0E/JAEG4WaVJjfA+ jchZw2tMljvwpDqLeyZD9VIdEA2OMx6rraUXE0vqUFYmucDeeK6aNBdk9lLykcXs KeOz4HAbqSRv6H2uYpqhVIGCr6PwUXQKirU+4z54JS4jmj5SLM9WlKeXTkTwMDlZ usuzwdQHwkFLdRg2QxsjjHtM3tcqlDfAA4HPqNUzyg== 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=fm1; bh=en0s/q 7cYsymziTGHGD0Pqpe9So0AUrTFmb1uoz6Ujo=; b=OYpZ9rmOPFQ5nsbGsFoFp1 HT0eueFS/UTcLCCzpjzs4Ll6xFHCwzUV0tfh6gKdPLGfhq/PvI/y21lIEhA02p9a d/io6hRkRZES4bL9/+KLkH8ZIIK2sd/pjENSQufzCA/bUSWnCcj7/VV5D5ihI0+h ckFmd86NIPlIyR29+BmnKHHvpZbdtNj4YnpdwqtSx9kp4uWK80JWn81OzIKPZeZZ zekd19LtZJLnokOD/2J7aQBGX/Stwxb4C2fTseS2aXESTH6UwyMv2iW6Nh5n7v2U 0QyOijawYVSZazp7QU31CSR5/hLv347G3LKVYd94nki97uZW51GoJuY4ryG6nBpw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeeigddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4B703E00A5; Wed, 16 Oct 2019 19:13:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <7d15a1f1-c646-43b7-b5d6-c89ea4b4b615@www.fastmail.com> In-Reply-To: References: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> Date: Wed, 16 Oct 2019 16:13:08 -0700 From: "Martin Thomson" To: "Nick Sullivan" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 16 Oct 2019 23:13:33 -0000 On Tue, Oct 15, 2019, at 17:13, Nick Sullivan wrote: > One may note that no matter what the choice is with respect to RSA, > this particular wrinkle also applies more broadly. For example, if a > client advertises support for ed25519 in "signature_algorithms" in > order to support ed25519 delegated credentials, it should also be > prepared to receive an ed25519 certificate. Good point. But I'm not sure that I'm happy with that property. From nobody Wed Oct 16 20:32:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644C112011B for ; Wed, 16 Oct 2019 20:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 eSdgu38hajK7 for ; Wed, 16 Oct 2019 20:32:21 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF42120024 for ; Wed, 16 Oct 2019 20:32:20 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id n14so871295ljj.10 for ; Wed, 16 Oct 2019 20:32:20 -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=ksF2BMoGBSc7JkD1GviPX6MeTXiB7vkdr0osHmbdd20=; b=oxJhpKyiSwsZhk4SwSlwa/11wHA9cQ4jN1HwePCzMWgcen88zkJCp9wdQzcSCJTcej v81WgWqrglK8NkbZoOXA5kUP704/J3vFJ9i2RK36LDMLT5204jAo0z0vQyK/SYNS1VO1 hnWjDamkVqP6NHQXOECXSSjJsYlqpRQuJENvDJ1IqR72kWIfxUKK0GxT8RaDoKsUsfIk lyF8Jkg0blnHMSMPf6WHzStx5kVVKaVfbbmaa7FHWQ5MSzMp43tdS5lAKtWGT17FbVBW cJPirBDJkacmBKZxKEfyAlsYNg9JybieEh8QlG9cRPnFmYZkKpZ41OnDzrBgQAQ71suq AhjQ== 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=ksF2BMoGBSc7JkD1GviPX6MeTXiB7vkdr0osHmbdd20=; b=pjryfyUAtB54MxuAjpXT6KCdAdr+q+4cySPHPhonqyTFOzZ/Mz7DdagTYfaH7wyI1z 822H9auGuGkcdWO07+00PYQ1euNObClsMeTjlVGK9Gfh3AJ/OL3xOwVgZn6GLyUF/ydU Jvi3hQHhZITD++gQ6oJf6x53WSMI4oZkFpqdFPLCQ21+G5d5GiZZELcXdSonySqFwV7q jWUGw+6y0AVINy0oJDRz7G4YKrt0R8q2oVoU5QgxPxn9i4sBjj+GpR/8sozUOW0CoiAc xZsWwpc0Jp9QU9jgnoLPls6A0Hel9ppHIUOenICF98f4T3liZTnpv0M7XwU8vHaelwqB vg3Q== X-Gm-Message-State: APjAAAWBm9MRpzgKPtdhv13jDuTr64YvPdVDBsS6jZmCfM9hErhCBKiG S0BfwRYAfJ9HGq724Bz7V1nOQeO+MP1OTydEpyA= X-Google-Smtp-Source: APXvYqwQyIn87jdekXV4uvU6cT2vwPOLdiodY/qO7d5ElmLVec1imAcYJR/KwRZLejS5npXTml7g2y3pomGK29rjSWI= X-Received: by 2002:a2e:8654:: with SMTP id i20mr859416ljj.238.1571283138946; Wed, 16 Oct 2019 20:32:18 -0700 (PDT) MIME-Version: 1.0 References: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> <7d15a1f1-c646-43b7-b5d6-c89ea4b4b615@www.fastmail.com> In-Reply-To: <7d15a1f1-c646-43b7-b5d6-c89ea4b4b615@www.fastmail.com> From: Watson Ladd Date: Wed, 16 Oct 2019 20:32:07 -0700 Message-ID: To: Martin Thomson Cc: Nick Sullivan , TLS List Content-Type: multipart/alternative; boundary="00000000000056ad72059512dd58" Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 17 Oct 2019 03:32:23 -0000 --00000000000056ad72059512dd58 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 16, 2019, 4:13 PM Martin Thomson wrote: > On Tue, Oct 15, 2019, at 17:13, Nick Sullivan wrote: > > One may note that no matter what the choice is with respect to RSA, > > this particular wrinkle also applies more broadly. For example, if a > > client advertises support for ed25519 in "signature_algorithms" in > > order to support ed25519 delegated credentials, it should also be > > prepared to receive an ed25519 certificate. > > Good point. But I'm not sure that I'm happy with that property. In TLS 1.3 it seems to have been assumed this wouldn't happen and we could split signature algorithms from signature algorithms cert. If that's not actually the case it affects more than just DCs. DCs are a good way to restore extensibility if there is a problem here, provided we can come up with a solution. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000056ad72059512dd58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Oct 16, 2019, 4:13 PM Martin = Thomson <mt@lowen= tropy.net> wrote:
On Tue, = Oct 15, 2019, at 17:13, Nick Sullivan wrote:
> One may note that no matter what the choice is with respect to RSA, > this particular wrinkle also applies more broadly. For example, if a <= br> > client advertises support for ed25519 in "signature_algorithms&qu= ot; in
> order to support ed25519 delegated credentials, it should also be
> prepared to receive an ed25519 certificate.

Good point.=C2=A0 But I'm not sure that I'm happy with that propert= y.

In= TLS 1.3 it seems to have been assumed this wouldn't happen and we coul= d split signature algorithms from signature algorithms cert.

If that's not actually the case i= t affects more than just DCs. DCs are a good way to restore extensibility i= f there is a problem here, provided we can come up with a solution.

_______________________________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000056ad72059512dd58-- From nobody Fri Oct 18 11:44:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578A31208C0 for ; Fri, 18 Oct 2019 11:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=cPKKGSxH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SJex5GVN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zM_lUBZmB5T for ; Fri, 18 Oct 2019 11:44:25 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD17E120811 for ; Fri, 18 Oct 2019 11:44:25 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id EFA2046F for ; Fri, 18 Oct 2019 14:44:24 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Fri, 18 Oct 2019 14:44:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=sFOx3BqB7FwvvhQgrcNzpoVRuIVsrGXlcwInmgNy8VM=; b=cPKKGSxH MZgmNaIBWeqFAaHY4fQg9kBziXUI2f16bFJcC+VyL6q2KGONVslIg07GHts5SDc7 JHVz/+58opqoHjUito0tlyJ+/Hjk3bpj+PCSlhnb6wY4+8UZ2mn70uRlqVf+H/No WpwbNwBvkk+ZkiOL3WQxvt02aNBaIVoBGFLt8EVgUI/tIkoj979gd5NAL+SjqJeT O/8sKGAKH4iWdxMY5lPYwT4IQ7ONFn72zoXWYwdXLnubhjEyr5+uaM4ZQgXtO0E+ oj4iuAbeYKYxyxu04GIfLykapDBWBnD2xz3QcIPGUAQXcezFNEUk5a7gqLMNeuXv g6xWZYzc5tGy/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=fm1; bh=sFOx3BqB7FwvvhQgrcNzpoVRuIVsr GXlcwInmgNy8VM=; b=SJex5GVNWApuWd70o2UzA2FargFkMjDFVH63GkJQbclEX WX4sC0TKBcAfHpWUrWX9xF3NexzkaT5egOaPObHImVv6PfFIZEJ50IkHUFnuB/Dn e89eZScsAicTPmY+wSQwF/ZG0FKIXcYNvFTGsKGtX1I85t7t70A22xDhs6uIEcMI 7O85+aIoeSfR2VoU9UDpLEplOEt86XdzBOWXZ9/hOWB5miYVoRhOo9pPGCvfzast 8QASCxzphv5i4oNKj44troO+SHUs+Zz23pLkLy8dAb3wSF3RqQzLXeQ9Oca49/Hy EyEzJjJ6zQ/VOEcGykeqHj2FJsvB/7PS1Fsyhl/Cg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrjeelgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehh vggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F3C243C00A1; Fri, 18 Oct 2019 14:44:23 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-360-g7dda896-fmstable-20191004v2 Mime-Version: 1.0 Message-Id: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> Date: Fri, 18 Oct 2019 11:44:03 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2019 18:44:27 -0000 This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, which can be found here: https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 It will run until November 1, 2019. Please indicate whether or not you would like to see this draft adopted and whether you will review and provide feedback on it going forward. Thanks, Chris, Joe, and Sean From nobody Fri Oct 18 11:46:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7002C12013F for ; Fri, 18 Oct 2019 11:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=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 qPJMfIXu9IDB for ; Fri, 18 Oct 2019 11:46:31 -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 002C9120026 for ; Fri, 18 Oct 2019 11:46:30 -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 x9IIggck010819; Fri, 18 Oct 2019 19:46:27 +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=l33MPhOZohImcMS0hP22/rPHj7W1ofPFi7WuNrlkGLc=; b=VFPGkVWhZ9lvoAE+qu0UyyVL8n8zbfPd1QEpsq2hbF0BECQ6SeLWAZqn6vBdkwJ+4UfA zhqY9Z0F5m9G2AHxJeCzTYYXnDxORwNWhDtjSi3h/DY8mmqE06jcjPwaWD547Y+2h/O5 6X7ONvf9tWIzC1Jp74DUL6SifQRK45jr+MVF04K4oHH+LWu3ZA+YpqaJ7fc3lYu4ZvLr mn+TMqrtg8qW7K3OfEs5t0yWvoDFtM7k5HQvhBaesJ2tKiFYfGp3BTlx5bFVY6nRUo6E pvfouoN2p6TMkR9sd+iNY65f2u3V6G6dOVoeT9v66uysjgY3ilWPsxpkP7/rHJ6RLzPg dQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vnp4qfwur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 19:46:27 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9IIW9c0009822; Fri, 18 Oct 2019 14:46:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2vka5wvj42-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 14:46:25 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 18 Oct 2019 14:46:25 -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.1473.005; Fri, 18 Oct 2019 14:46:25 -0400 From: "Salz, Rich" To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] Adoption call for draft-davidben-tls13-pkcs1 Thread-Index: AQHVheQZQJYu09L7+kC9XCEs0dxs76dgvOYA Date: Fri, 18 Oct 2019 18:46:24 +0000 Message-ID: <10196741-9694-4290-8FAC-0E20246ABF4C@akamai.com> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> In-Reply-To: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.51] 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:, , definitions=2019-10-18_04:, , 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=713 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910180165 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-18_04:2019-10-18,2019-10-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=716 priorityscore=1501 spamscore=0 bulkscore=0 lowpriorityscore=0 phishscore=0 impostorscore=0 suspectscore=0 adultscore=0 clxscore=1015 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910180166 Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2019 18:46:33 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLCB3aWxsIGNvbnRyaWJ1dGUuDQoNCg== From nobody Fri Oct 18 13:15:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4D2120959 for ; Fri, 18 Oct 2019 13:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 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.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nDuZNiUs0cNG for ; Fri, 18 Oct 2019 13:15:53 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 31749120942 for ; Fri, 18 Oct 2019 13:15:53 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id q24so3350979plr.13 for ; Fri, 18 Oct 2019 13:15:53 -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=vDnwfcakzzuZavnC8LQm36ZqkzQgKVBXMC+6w37Wv+U=; b=CC7p2f3N8JVmG+Ir7DCI7Iaw3jYDU8HSPBJDpJPaIxiQuJ1ww9g/HmlkirJ1gv8+ap bASDBmnEVsa2O+wob3EiiLMYQythx1i8pKdJxS5bsrJ/VgVap+qbQeDnXR5tQbvkS4CJ oGn4NiHYXZarJgjhccFqDUsTvUlpOWsq7F9R0= 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=vDnwfcakzzuZavnC8LQm36ZqkzQgKVBXMC+6w37Wv+U=; b=plkB4QJ40g+ugv7f1vSJWdsJB+RiNNx6WLnGvWomwTKQ34BCfdtn1b9TW+MBslDHGQ ovL0wSrkWvsWAqVmR8dkDDWokyJvFdXAXfwjm/TEwx5AdSNPBoT8UrEpjFF+7Z/ahHHC F+PlteWeRWZ1U6F+rK/v77oGIOf0vAIP1iOKRxb96bkn88e4GMOGpvhcNnd7bHyUsu7Q HnEPdDe1LR1hDTIZ9A1hoUyTsxH2k5uOBJOiUnK4be46iux+GWvwRb0G3SiPXvOVG+YW CGHN7z07buQvPOwHzNp4Jpq2u0A/XME7eVK28BdAHLhG5DAUhixyLMF+VNhrkjYZfNLt EbSA== X-Gm-Message-State: APjAAAVyZJBGpbbyNdd++U+xwxMWuuYYeVBxO1jYBMJqVY9aE7Is74B5 Sax4AN0K8py367pwOa2b//V+lv/pz2CUaulLNkCy X-Google-Smtp-Source: APXvYqwAlyT9lzkJpRboaX2ngpkiQ5Oz5V0C/it7EUw5I5535Eyt54XsG5HAR1rspEGcoocQtK5R50ze3ize/tab/Jk= X-Received: by 2002:a17:902:8c98:: with SMTP id t24mr11715599plo.334.1571429752464; Fri, 18 Oct 2019 13:15:52 -0700 (PDT) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <10196741-9694-4290-8FAC-0E20246ABF4C@akamai.com> In-Reply-To: <10196741-9694-4290-8FAC-0E20246ABF4C@akamai.com> From: David Benjamin Date: Fri, 18 Oct 2019 16:15:36 -0400 Message-ID: To: "Salz, Rich" Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002fe0d20595350068" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2019 20:15:54 -0000 --0000000000002fe0d20595350068 Content-Type: text/plain; charset="UTF-8" I also support adoption and will contribute, unsurprisingly. :-) On Fri, Oct 18, 2019 at 2:46 PM Salz, Rich wrote: > I support adoption, will contribute. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002fe0d20595350068 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also support adoption and will contribute, unsurprisingl= y. :-)

On Fri, Oct 18, 2019 at 2:46 PM Salz, Rich <rsalz@akamai.com> wrote:
I support adoption, will contribute.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002fe0d20595350068-- From nobody Fri Oct 18 16:55:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66357120111 for ; Fri, 18 Oct 2019 16:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3WimqODuL9X3 for ; Fri, 18 Oct 2019 16:55:34 -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 4DE141200DE for ; Fri, 18 Oct 2019 16:55:34 -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 x9INtMYX010517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Oct 2019 19:55:25 -0400 Date: Fri, 18 Oct 2019 16:55:21 -0700 From: Benjamin Kaduk To: RFC Errata System Cc: ekr@rtfm.com, rdd@cert.org, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com, lperrin@bellaliant.net, tls@ietf.org Message-ID: <20191018235521.GO43312@kduck.mit.edu> References: <20191012042149.A9B79B801A8@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191012042149.A9B79B801A8@rfc-editor.org> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5874) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 18 Oct 2019 23:55:36 -0000 On Fri, Oct 11, 2019 at 09:21:49PM -0700, RFC Errata System wrote: > The following errata report has been submitted for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5874 > > -------------------------------------- > Type: Technical > Reported by: Mr Laurie Perrin > > Section: 5.1 > > Original Text > ------------- > ... > > Application Data messages contain data that is opaque to TLS. > Application Data messages are always protected. Zero-length > fragments of Application Data MAY be sent, as they are potentially > useful as a traffic analysis countermeasure. Application Data > fragments MAY be split across multiple records or coalesced into a > single record. > > Corrected Text > -------------- > ... > > Application Data messages contain data that is opaque to TLS. > Application Data messages are always protected. Zero-length > fragments of Application Data (i.e. those encapsulating an > TLSInnerPlaintext record having a content field of length zero) > MAY be sent, as they are potentially useful as a traffic analysis > countermeasure. Application Data fragments MAY be split across > multiple records or coalesced into a single record. I think at most this could be Editorial/Hold For Document Update, though the added phrasing can probably be wordsmithed a bit more, perhaps "(i.e., TLSInnerPlaintext records of type application_data with zero-length content)". > Notes > ----- > In the interest of clarity, it may be prudent to specify the type of record for > which a fragment of length zero is being considered - it cannot be that of the > TLSCiphertext itself, for "Application Data messages are always protected," > therefore I infer this relates to the TLSInnerPlaintext content field (of > length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment. As an implementor I think it's hard to be confused, but maybe others feel otherwise. -Ben > Note: This comment also applies to previous versions of the TLS specification, > in particular with the introduction of the respective text concerning zero-length > fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content > field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment. > > Note: The implications of zero-length records must be considered with respect to > potential vectors for denial of service. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG From nobody Fri Oct 18 18:38:04 2019 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 75A0B12012E; Fri, 18 Oct 2019 18:38:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157144908240.3924.7514701217675355586@ietfa.amsl.com> Date: Fri, 18 Oct 2019 18:38:02 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ticketrequests-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: Sat, 19 Oct 2019 01:38:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Ticket Requests Authors : Tommy Pauly David Schinazi Christopher A. Wood Filename : draft-ietf-tls-ticketrequests-03.txt Pages : 6 Date : 2019-10-18 Abstract: TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while simultaneously priming clients for future connection attempts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-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 Oct 20 14:40:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4CA12001E for ; Sun, 20 Oct 2019 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5jVWZiGBqeLU for ; Sun, 20 Oct 2019 14:40:52 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 9201912006A for ; Sun, 20 Oct 2019 14:40:52 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id c25so13503280iot.12 for ; Sun, 20 Oct 2019 14:40:52 -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=V5jjZ1r2VZvjFuuXYTvQzOccM4vgUHkLE7eXQKYZ2hw=; b=nk6iMObcN9XrWs66cfSjoLPi6YTlnvcljAA0ntj5wmjn0vONhHTDsc6UkQnQFpeNRg DqIbdQReQi01PCAs8l5FHp4Kr9N//tNSAsnHDLwbs+Q/EvXfjbkouVs22yv+oMtTI3eH AItojHJNSk87vH7hyYb8TN1xOKcg0HyTweyQLSNB3iqwTfZg5WSF5C+O2F2dAy9h9+bz KFATHBtImjpeqSLli0d3H/DyUVVC0LZGLD60PMIeHbFGQ7vMqp5JI7nnmHkvvacU+Co+ HXxBu0WjHtT30e4Gt+tVuzUUOnPtReAlhtZ8jxT4sQk6HkiFkyUD8UJ6caKL9Zs1J3I+ Xm6w== 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=V5jjZ1r2VZvjFuuXYTvQzOccM4vgUHkLE7eXQKYZ2hw=; b=CaWBUrhZv50nP0fYR4Zec3WnsdKPeZc2RyESlWMj2vw6q7baWiS8vfT4w7WuEoCZkm U2EXgITWbLtReLcPLe8Lg+xpV7gFK84W9omt1oxdKE1CilolCZXnFDN9ZD/3ZvVSTB2h gPnwF6iEbtE7tu5rbVOdyzoIcs/z9GMz94yqNhhAXzJzD3fdJ72Y2F/dDcZTCWVJnXbo F/6IYtXDYL4qcEpJucmYrzMyQiKOmQN7fhyx+LDbZMVlfGxfFN4jwenOiF0YUQOoEDDS u6vvNWMWXzFBoZO8nIXuUhO14Yc87v3QYyFnZtSocMpvA7JkfV3aZBx4/RAvSKqtDV+A EHeg== X-Gm-Message-State: APjAAAVH9D2D0jO5mWpJYAwX4aW179tj9aH2IKNyeDAI08toWdb8iqXF OxVBb+QMJuEEETdlbyGgveoSWaLrIjPc2L7BkvLtYNhF X-Google-Smtp-Source: APXvYqyHAbA4+T4AkK/fxdjj7JiGEBdR6IFQ0u2kfyCivvI2QD/oxsOJ03stdzKu93pj779R9BqB5fJRr8VCa27Aec0= X-Received: by 2002:a5d:9297:: with SMTP id s23mr12004518iom.49.1571607651285; Sun, 20 Oct 2019 14:40:51 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Sun, 20 Oct 2019 14:40:40 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c800dc05955e6bb9" Archived-At: Subject: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 20 Oct 2019 21:40:55 -0000 --000000000000c800dc05955e6bb9 Content-Type: text/plain; charset="UTF-8" Hi, I was implementing https://tools.ietf.org/html/draft-ietf-tls-esni-02 (since I believe that version is what Firefox and Cloudflare currently ship), and I had a difficult time parsing this part of the draft: struct { ServerNameList sni; opaque zeros[ESNIKeys.padded_length - length(sni)]; } PaddedServerNameList; struct { uint8 nonce[16]; PaddedServerNameList realSNI; } ClientESNIInner; I hadn't seen the fixed-but-variable length construction that the "zeros" field uses before (although I haven't written much TLS code). It does end up being easy to implement, because "realSNI" is placed at the end of ClientESNIInner. However, this detail was not obvious to me until I got through all of the serialization code I was writing, and it would also seem to limit the places PaddedServerNameList should appear in TLS structs. Judging by the mailing list archives, the design of the field is intentional. It's not clear to me why "zeros" wasn't specified as variable-length with a prose restriction, though. This part of the spec is also just generally difficult to follow, in my opinion. I had no trouble following the ESNIKeys section. Perhaps the problem is in the interaction of prose order, serialization order, and procedural code order. thanks, Rob --000000000000c800dc05955e6bb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I was implementing=C2=A0https://tools.ietf.org/= html/draft-ietf-tls-esni-02 (since I believe that version is what Firef= ox and Cloudflare currently ship), and I had a difficult time parsing this = part of the draft:

struct {
=C2=A0 ServerNameLi= st sni;
=C2=A0 opaque zeros[ESNIKeys.padded_length - length(sni)];
} = PaddedServerNameList;

struct {
=C2=A0 uint8 nonce[16];
=C2=A0 = PaddedServerNameList realSNI;
} ClientESNIInner;

I hadn't seen the fixed-but-variable length construction=C2=A0tha= t the "zeros" field uses before (although I haven't written m= uch TLS code). It does end up being easy to implement, because "realSN= I" is placed at the end of ClientESNIInner. However, this detail was n= ot obvious to me until I got through all of the serialization code I was wr= iting, and it would also seem to limit the places=C2=A0PaddedServerNameList= should appear in TLS structs.

Judging by the mail= ing list archives, the design of the field is intentional. It's not cle= ar to me why "zeros" wasn't specified as variable-length with= a prose restriction, though.

This part of the spe= c is also just generally difficult to follow, in my opinion. I had no troub= le following the=C2=A0ESNIKeys section. Perhaps the problem is in the inter= action of prose order, serialization order, and procedural code order.

thanks,
Rob
--000000000000c800dc05955e6bb9-- From nobody Sun Oct 20 22:05:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310DE1200E6 for ; Sun, 20 Oct 2019 22:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=B3lw6NfV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fF/Gq1Ra Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeosJkagPuHl for ; Sun, 20 Oct 2019 22:05:48 -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 7DFDC1200FA for ; Sun, 20 Oct 2019 22:05:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E42A720355 for ; Mon, 21 Oct 2019 01:05:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 21 Oct 2019 01:05:47 -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= fm1; bh=m9Hn7DeAkxxFZ3eZMprXRs4h4qbUKRUZmjIC4vPLV3s=; b=B3lw6NfV klhmaua4K8i4eLHFrJd67KVdvYxj/4mWadGwwDJ5EQSfotPsTFy81xP8iboZNGFP zq6NYSX6XP4ixvPeEJoCbmRMlRezKODXyooHUy1uXib7vOkBgCGbcIrMWTWjn0Bl al5NFKeEw8gU3Hrjo24lmWQPF6ajOZddyaGGGuvw8WVZD+RR2LetlM0gGFUKQ5rO DjVUlx8I12MAtnuKxJBtJBQI/LPalOIAG7eLxgZelN5LRyKJf3NcYUGYvonYlAg8 KxZ8+93RFppcAqPtzoZft1yA+1NNspzD1CnuWlwg5MSx6JRwSYXvGFHVsoGRoVgR 6kEM7QMgBXrhFw== 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=fm1; bh=m9Hn7DeAkxxFZ3eZMprXRs4h4qbUK RUZmjIC4vPLV3s=; b=fF/Gq1RacMLqy7pCBBYX5EGATZanpYJBWbhnKtXdglI5L qbdI/3bGdZN7W1xoKmoZnVz0mr/Lb54TXezXDeJ4byPEMJ0YlcUMlpJ8yXjqy9ms WESBs5SJLkVn3CGSIlmwd5ztQT4wbwQrJ0vd+gKlTdC69oZiYB0ZwYKxyV8Osv0n S1/SD9lsNFq0v4KhWp6Y488zpNZ+tEHjgJv1TSKSGvxvod+ctHMTzwncWIlZ+EYm 0RNOWV/4YGpwc5MP0PfEJhMmCaCoPFVIuRX5OLnER/CVz7Ihcc3e0i40lmb8B+rA mOADs9GeLIFHYVRZ6G35qhEELahz65TutsMjmdjCQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeggdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgsucfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc fkphepgeehrdejledruddufedrudeiheenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedv X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id A050CD6005F for ; Mon, 21 Oct 2019 01:05:47 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 0DA659E87C for ; Mon, 21 Oct 2019 05:05:47 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============2749065975368042305==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191021050547.0DA659E87C@cloud.mnot.net> Date: Mon, 21 Oct 2019 05:05:47 +0000 (UTC) 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: Mon, 21 Oct 2019 05:05:56 -0000 --===============2749065975368042305== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-ticketrequest (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #6 Discuss possible self-induced amplification for servers (1 by chris-= wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/issues/6=20 1 issues closed: - Discuss possible self-induced amplification for servers https://github.= com/tlswg/draft-ietf-tls-ticketrequest/issues/6=20 * tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC1) 1 issues created: - ASN.1 Module (by seanturner) https://github.com/tlswg/tls-subcerts/issues/37=20 1 issues received 1 new comments: - #28 PSS (1 by grittygrease) https://github.com/tlswg/tls-subcerts/issues/28=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Remove partial split mode (by bemasc) https://github.com/tlswg/draft-ietf-tls-esni/pull/185=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - More edits from the list. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/7=20 1 pull requests merged: - More edits from the list. https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/7=20 * tlswg/tls-subcerts (+2/-1/=F0=9F=92=AC1) 2 pull requests submitted: - Asn1 module (by seanturner) https://github.com/tlswg/tls-subcerts/pull/38=20 - nitty-nits (by seanturner) https://github.com/tlswg/tls-subcerts/pull/36=20 1 pull requests received 1 new comments: - #38 Asn1 module (1 by siyengar) https://github.com/tlswg/tls-subcerts/pull/38=20 1 pull requests merged: - nitty-nits https://github.com/tlswg/tls-subcerts/pull/36=20 * tlswg/tls-exported-authenticator (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #50 Address comments by Christer Holmberg. (1 by grittygrease) https://github.com/tlswg/tls-exported-authenticator/pull/50=20 Repositories tracked by this digest: ----------------------------------- * 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 --===============2749065975368042305== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Monday October 21, 2019

Issues

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

1 issues received 1 new comments:

1 issues closed:

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

1 issues created:

1 issues received 1 new comments:

Pull requests

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

1 pull requests submitted:

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

1 pull requests submitted:

1 pull requests merged:

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

2 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

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

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============2749065975368042305==-- From nobody Mon Oct 21 01:04:43 2019 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 B2EE5120143; Mon, 21 Oct 2019 01:04:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157164508164.31795.18313531664029121455@ietfa.amsl.com> Date: Mon, 21 Oct 2019 01:04:41 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-07.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: Mon, 21 Oct 2019 08:04:42 -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 : Connection Identifiers for DTLS 1.2 Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Filename : draft-ietf-tls-dtls-connection-id-07.txt Pages : 16 Date : 2019-10-21 Abstract: This document specifies the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol version 1.2. A CID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-07 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-07 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 Mon Oct 21 06:06:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52F91200C4 for ; Mon, 21 Oct 2019 06:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV1nGtzDGQ-m for ; Mon, 21 Oct 2019 06:06:40 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 CCCB7120099 for ; Mon, 21 Oct 2019 06:06:39 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id y3so13248961ljj.6 for ; Mon, 21 Oct 2019 06:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lizBzmZooz2GyL5rCjZVTkxXBRam4n0Fi1G5W/WgVBQ=; b=tbJvJwfAmbHLG1gtXcYXAaBPV0Cw7dd/e/Jl2f7e7sPz5AASeRslzwBSX9rJ/pzJ1y hE2KUxnNB3HnRorn3tQndi9nWq16+o+YWNhCUO7DnTgAvcwoX2XrX4Zu6xnXAnUwj3gt s3MT22bKS9STl8MaBu9vEqSMTmG9n5NkFgbP/DVf/Z6elwUXo7zNU6num+kaO290d8bc Sa+BR7zaBscpGr2dE+C3CChztK3wEQFFbjU06axmKJWS4gSEqbwQ2Hn1wGAy2UU41gDk FbBbjg5QR3VpiNHEzNx3uEseBG92R4oSRIDCB/ZsCQyTfNh5h7hQKd+kAKPdJwpx1Dst KoNQ== 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=lizBzmZooz2GyL5rCjZVTkxXBRam4n0Fi1G5W/WgVBQ=; b=YkHC8nbyfnfA5yoSG4XDYteYMD+0wisYhwKyUtFMa0NbWow5EOJRWyhl6RVvWwCjmo eOduas/YELxco2rN7sAMT5/dI34LY6ucnUAUs/Q/84g0EiRKT7IFmm/dg0YW5jK6bdPA nTIgAYETc1Wpo197rS0ztWJ+gG5kNrGW0r1QHkPAc5Wzz+8RPkZfdhVe+PliFJovHtd2 XUobFjXF5Dacf7BtgmP8jK08EaF4tW1X9dJcA9tmkeyurXCaXbx1R17ps4z468XaBQnN vHZYXy3QzoPcMSohN8RGIcJN+VcYUVuWvs9uPLn33KvGk83XOO1N+JLtRcHTRAbfp000 MUSA== X-Gm-Message-State: APjAAAUYGzqoDHpMmjgJP/VYTLAPm73E7SomiJbHfrOGNAfZ3qFI6Ire PXUG/aBpB10Pu9FvX3J1Y6q/xtvUPHrYSS96fCqh7Q== X-Google-Smtp-Source: APXvYqx9fTvLhNkwFg/cUkO9ubADPxGyZwYxgDCQAmjB/c1PvydeRB1dDRH6ROjSeLZp2EnYEf4stPjhh5116USkgsA= X-Received: by 2002:a2e:3a14:: with SMTP id h20mr14485547lja.29.1571663197950; Mon, 21 Oct 2019 06:06:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 06:06:01 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009efb9905956b5aee" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 13:06:42 -0000 --0000000000009efb9905956b5aee Content-Type: text/plain; charset="UTF-8" On Sun, Oct 20, 2019 at 2:41 PM Rob Sayre wrote: > Hi, > > I was implementing https://tools.ietf.org/html/draft-ietf-tls-esni-02 > (since I believe that version is what Firefox and Cloudflare currently > ship), and I had a difficult time parsing this part of the draft: > > struct { > ServerNameList sni; > opaque zeros[ESNIKeys.padded_length - length(sni)]; > } PaddedServerNameList; > > struct { > uint8 nonce[16]; > PaddedServerNameList realSNI; > } ClientESNIInner; > > I hadn't seen the fixed-but-variable length construction that the "zeros" > field uses before (although I haven't written much TLS code). > It is used in other places. See, for instance: https://tools.ietf.org/rfcmarkup?doc=8446#section-5.2 Judging by the mailing list archives, the design of the field is > intentional. It's not clear to me why "zeros" wasn't specified as > variable-length with a prose restriction, though. > Because then you have a spurious length field. This part of the spec is also just generally difficult to follow, in my > opinion. I had no trouble following the ESNIKeys section. Perhaps the > problem is in the interaction of prose order, serialization order, and > procedural code order. > Well, this structure is likely to change a fair bit, so probably not worth trying to update the text right at this moment. -Ekr > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009efb9905956b5aee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 20, 2019 at 2:41 PM Rob S= ayre <sayrer@gmail.com> wrote= :
Hi,

I was implementing=C2=A0https://tools.ietf.= org/html/draft-ietf-tls-esni-02 (since I believe that version is what F= irefox and Cloudflare currently ship), and I had a difficult time parsing t= his part of the draft:

struct {
=C2=A0 ServerNa= meList sni;
=C2=A0 opaque zeros[ESNIKeys.padded_length - length(sni)];} PaddedServerNameList;

struct {
=C2=A0 uint8 nonce[16];
=C2= =A0 PaddedServerNameList realSNI;
} ClientESNIInner;

<= /div>
I hadn't seen the fixed-but-variable length construction=C2= =A0that the "zeros" field uses before (although I haven't wri= tten much TLS code).

It is used= in other places. See, for instance: https://tools.ietf.org/rfcmarkup?doc=3D8446#s= ection-5.2


Judging by the mailing list archives, the design of the f= ield is intentional. It's not clear to me why "zeros" wasn= 9;t specified as variable-length with a prose restriction, though.

Because then you have a spurious length= field.


This part of the spec is also just= generally difficult to follow, in my opinion. I had no trouble following t= he=C2=A0ESNIKeys section. Perhaps the problem is in the interaction of pros= e order, serialization order, and procedural code order.

Well, this structure is likely to change a fair b= it, so probably not worth trying to update the text right at this moment.

-Ekr

thanks,
Rob
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009efb9905956b5aee-- From nobody Mon Oct 21 06:06:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E368B120033 for ; Mon, 21 Oct 2019 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 J4G9P7sUWJ0c for ; Mon, 21 Oct 2019 06:06:39 -0700 (PDT) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C5F12004D for ; Mon, 21 Oct 2019 06:06:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571663198; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Uq+bw4umtXiCBDhgXPPG/vK6i4iNuYkh/XVM7ZxhY+8=; b=UmodjuimGIeWKxze04IRR3Y8FZCSefJwwRh7W2P18Jd83ArthbnOxjFriFoAaxDpK+RLqi tkQ6voNVdp7Bmg82eVZ2I/kM447G1uXp5X3jv8Ens/eniLGKiezlGRKM55Uqk7HW/Ft6iK +dUdW/QBvW9Kh+4gmDHgyR77pSUiV18= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-326-MWV3xHaYO3-0GDDic96CqQ-1; Mon, 21 Oct 2019 09:06:35 -0400 X-MC-Unique: MWV3xHaYO3-0GDDic96CqQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E495A800D41 for ; Mon, 21 Oct 2019 13:06:34 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-53.brq.redhat.com [10.40.200.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6F987166BB for ; Mon, 21 Oct 2019 13:06:34 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 21 Oct 2019 15:06:16 +0200 Message-ID: <2526780.OaETcaIKEv@pintsize.usersys.redhat.com> In-Reply-To: <157144908240.3924.7514701217675355586@ietfa.amsl.com> References: <157144908240.3924.7514701217675355586@ietfa.amsl.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 Content-Type: multipart/signed; boundary="nextPart6498523.DgYpVqzdJR"; micalg="pgp-sha512"; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 13:06:43 -0000 --nextPart6498523.DgYpVqzdJR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 19 October 2019 03:38:02 CEST internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Layer Security WG > of the IETF. >=20 > Title : TLS Ticket Requests > Authors : Tommy Pauly > David Schinazi > Christopher A. Wood > =09Filename : draft-ietf-tls-ticketrequests-03.txt > =09Pages : 6 > =09Date : 2019-10-18 >=20 > Abstract: > TLS session tickets enable stateless connection resumption for > clients without server-side, per-client state. Servers vend an > arbitrary number of session tickets to clients, at their discretion, > upon connection establishment. Clients store and use tickets when > resuming future connections. This document describes a mechanism by > which clients can specify the desired number of tickets needed for > future connections. This extension aims to provide a means for > servers to determine the number of tickets to generate in order to > reduce ticket waste, while simultaneously priming clients for future > connection attempts. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-03 except for the "vend" and "vended" typos, looks good to me --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart6498523.DgYpVqzdJR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2trUgACgkQkqjRuAHS 9fW2Lg/+J4vH6zssAfSQ52p6XRZ+mzYkk58btTS61VnMpPUdfLliyZHYqmz+NhnG poZl9HhryoZiyqGhkQXrZMbMpN6O+Rrs8/uRyr5uBkYq6u13vm31hAhkdTddBheY IPP2tZyOgevazsMs9KCPDvFWoEN85Cus1q/EFx/jGBqVTz6A52SDSkxw0XDUNh46 pQVoEi/EGqI6k8A20lf3BSo9ex8QY+G9eLF5XPXz1qJRnXFgZLqi/6PXJXAZTQ5G 6sr+VaCrWD3FIXwPRXw+KxTeYHC4ZHIWXOB135yJukSo/RWfJ5FwhLlr/ovCFTWY An9+d7NXsLA098g6oVosvyBLqrp7p9hH7ah8E3XSXNwz6Mn3vUVO5+QltNXtMNbi uEWN4kUNejAJcyNzD5itKMoBB4mbkpaS9YGvj4lHpsQoHAv3IM0gJyNWznkDCVSD ihJ622y48WW3B+7wJwQYF2nrZY/ThCL/Hab+oEqOwTkY31RkX6Pbk2Ta2FdlRBwM J4B9AB2SxrqwRsi9jamCGhPKFr77R8TtSyPfRFGQ2gDZKxR/G4FlkmGyK4mkmCnO +63KwJl3ox0IJoAAgN4bKYoZYEz8ko41Jfm1Bnae7Vgpce9QDy384RnJeWuEZzqG 4Lg9br5h2QvkqK9OwpEMGYnalKsgx0ARElyWKW7qv/VXRD0B/cw= =z9WP -----END PGP SIGNATURE----- --nextPart6498523.DgYpVqzdJR-- From nobody Mon Oct 21 06:42:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AF3120099 for ; Mon, 21 Oct 2019 06:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 shldr9IBTfNc for ; Mon, 21 Oct 2019 06:42:48 -0700 (PDT) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0668612004D for ; Mon, 21 Oct 2019 06:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571665366; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4Sy0TBDJ8pfl6X0Of0tqI1PMT0ncr8c5qwNqheSqE+Q=; b=YEbyQOz9lKxLNblbHG6OszDgJ82OzqY1QYnsx91JhIHWzSm3iUpidMOm2PeF8LyJfcPRRn k4uLPOdUH36IFqHpTWLyTxFqXAGbIK0L1Ymm33x6Lqx6B7eSoE9ncjOOVTQ//rEmI/beTO +4biypdVP9v1UbdL4DE9vn6RlWr254w= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-22-vVhRZKJhMSeP1T-36QQI9w-1; Mon, 21 Oct 2019 09:42:43 -0400 X-MC-Unique: vVhRZKJhMSeP1T-36QQI9w-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E014B476; Mon, 21 Oct 2019 13:42:41 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-53.brq.redhat.com [10.40.200.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id DB72B7ED78; Mon, 21 Oct 2019 13:42:40 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Cc: Christopher Wood , "TLS@ietf.org" Date: Mon, 21 Oct 2019 15:42:39 +0200 Message-ID: <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> In-Reply-To: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 Content-Type: multipart/signed; boundary="nextPart1998546.HKHFz684Vl"; micalg="pgp-sha512"; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 13:42:50 -0000 --nextPart1998546.HKHFz684Vl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > which can be found here: >=20 > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 >=20 > It will run until November 1, 2019. Please indicate whether or not you wo= uld > like to see this draft adopted and whether you will review and provide > feedback on it going forward. Yes, requiring RSA-PSS causes interoperability issues with smartcards that= =20 don't implement this 16 year old algorithm. But being able to say "if you'r= e=20 using TLS 1.3 that means you are not using legacy crypto" has non=20 insignificant value too. This document erodes that. So I'm against adoption of this draft by the WG. If it is adopted, I will review and provide feedback on it. --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1998546.HKHFz684Vl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2ttc8ACgkQkqjRuAHS 9fWexw//ecf3kUWLzUJf0mUEFpgVtDuGznf0tVP7Sr6EBE5aAj8gteydgsWcUzKu HgOnHsVZdcEG76YjLSiqBfsEqqE5AZ4qB3Su+UGU/KAyrBSB8ht3bywSZTX87Na4 Jwrf/KyGLjeMQTDrDO7MZV+IuIsjowcu1RcoZ/xHWDEjB4ndvnvVQ65HYJ6BETsN tAsvqQT+n0g1I7VN+sC0ELbo+G4dn4bR4n+51U7hElChpGE24CsYmgs5mS4wP2jZ I3EC6vyXEnmDb14izhl2tsDVIwugU0ved53OQAxUbgwRthBToG/J466iqqZ5VJrF qbrW9CokMWLoqmZemOIv6jAENsLPLaZ4MPTwj8nVsWsHFftyWjR/p+vyikLqM6Qf SEiPiKzdqpUxj5zZXYcuoPkYpmMahYNPX+Hz0aWYxeQcELQZmRfq0GGhbM3vkBoJ ddJy8lVT5eXPDnJAlYuuRFtj4Asue14kTiH/3jscMlexpX/FkNp0ITFxdohctQA+ IG/ANiS4w4LbGU/DD/q36MtBRE83W5bABFT5ZUzpvVlSiL/Ep1+AgUd1mLRAc60S GfTivuqPuwRfmhsr67oyv8vclADK4IloGowkZXiUtA+gwE2bSAJ8hfRO/pgJwUEU dAKF81Elfkor/PRnD7v5PuFPtCM1OMX0VVcWbbInkCtscCp8jkI= =V7Fx -----END PGP SIGNATURE----- --nextPart1998546.HKHFz684Vl-- From nobody Mon Oct 21 07:32:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B04120834 for ; Mon, 21 Oct 2019 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7IQkrxNaxG0F for ; Mon, 21 Oct 2019 07:32:32 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F479120821 for ; Mon, 21 Oct 2019 07:32:23 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id c11so7070412iom.10 for ; Mon, 21 Oct 2019 07:32:23 -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=Eoz5dEAAC8lmu7yUidwZiGi4ckgsAmcoqBg4MhGz/MA=; b=D0uR1wGCh4vKmQ5ZTuS/82eX9YQ2l+eG3dQcIiyrtJ8q+uXwqcNJAsybbSMX5OGFat zTdsjgkh7syRBk1ZzJbIB3ErGTrjl0/YifXm/EWFvjcwKKdFQnemsNkrjh4Xwb0LLLNo UKkVxK4Z4IJAZyo1L956TRxqqro4X3Sun9VMwRVaHKlw13i5Ud/CM9FvpqWsjTDqwTDx AwC11K0gNiqsyzCLOUDohoCZgf3j9+BSD4vq9FlKYSU5ZXf8+ZQ2jQDYNcEUrV6fFZ3L z2RjWSnVI9Sn49FS0sKipMZfcIgKRqAHWzxK9Vz9s8cyJu/+HrgiqX2fXpn5HAxttrZE GGHQ== 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=Eoz5dEAAC8lmu7yUidwZiGi4ckgsAmcoqBg4MhGz/MA=; b=hQU6novTMh7yD4jF97RjsTfw0tihSKDpsELwLHhm5cYoQJSxsCNoyjYLH5sxQVpyrx 7EIFmYLZDN1tqFv+WqlCcRqa4VW9JGJqE5kka1USu5nuoNOwwjrUgiiMQWpwEWhmKiyX MgtzKuQLUyu+Nrf3ndpsm9AU6ogQRBPxG7i0oVgWnF6ryQCD5KO2njMnjr19HIa/caOy AaqU0i3Jv5snm45vOYL8oFpRNxo/pxzZN0Si0JihLegFAisuForwtLW7ey7inTNnSyRW gHf308+6xwKV76QSK27/SjJhIJhzS7J9g8O02ON/UDa6g7GJFA7xgEiTNP74ZIcF5Bio wOxA== X-Gm-Message-State: APjAAAV8IwlQX0zQWgTD1Wd2rFoso0M/LAUDuYwkY9tf7ggAswjsT9MF kyOOvFE3wMsnOXBF8tWhXsnvfR7tk7MgZM9taSqPtX6U X-Google-Smtp-Source: APXvYqwE4RjWT1SPfygQZSygKK09uEt5Te+AJo0ggf4qQbLzA7TKV8osCk50msgqs6RgHmz3JzoDHP5L9zNBKw+dwYQ= X-Received: by 2002:a02:9a15:: with SMTP id b21mr21348159jal.103.1571668342235; Mon, 21 Oct 2019 07:32:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 07:32:11 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003e715705956c8df0" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 14:32:36 -0000 --0000000000003e715705956c8df0 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 6:06 AM Eric Rescorla wrote: > >> >> I hadn't seen the fixed-but-variable length construction that the "zeros" >> field uses before (although I haven't written much TLS code). >> > > It is used in other places. See, for instance: > https://tools.ietf.org/rfcmarkup?doc=8446#section-5.2 > Ah. I have only worked on some handshake messages, and it was new to me. In the future, I think it might be worth calling out this kind of field as a distinct type. Maybe "dependent vector"? The TLS 1.3 RFC does say "The size of the vector may be specified at documentation time or left unspecified until runtime", but I thought the latter part of that sentence was referring to variable-length vectors. > Judging by the mailing list archives, the design of the field is >> intentional. It's not clear to me why "zeros" wasn't specified as >> variable-length with a prose restriction, though. >> > > Because then you have a spurious length field. > I don't understand why it would be spurious. In this case, the deserializing implementation needs to inspect every byte anyway. > This part of the spec is also just generally difficult to follow, in my >> opinion. I had no trouble following the ESNIKeys section. Perhaps the >> problem is in the interaction of prose order, serialization order, and >> procedural code order. >> > > Well, this structure is likely to change a fair bit, so probably not worth > trying to update the text right at this moment. > Fair enough. I would also suggest making sure that this section does not span a page boundary. That made things worse for me. thanks, Rob --0000000000003e715705956c8df0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 6:06 AM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div class=3D"gmail_quote">


I hadn't seen the = fixed-but-variable length construction=C2=A0that the "zeros" fiel= d uses before (although I haven't written much TLS code).

It is used in other places. See, for instanc= e: https://tools.ietf.org/rfcmarkup?doc=3D8446#section-5.2

Ah. I have only worked on = some handshake messages, and it was new to me. In the future, I think it mi= ght be worth calling out this kind of field as a distinct type. Maybe "= ;dependent vector"? The TLS 1.3 RFC does say "The size of the vec= tor may be specified at documentation time or left unspecified until runtim= e", but I thought the latter part of that sentence was referring=C2=A0= to variable-length vectors.

=C2=A0
Judging by the mailing list archives, the design of the field is inte= ntional. It's not clear to me why "zeros" wasn't specifie= d as variable-length with a prose restriction, though.

Because then you have a spurious length field.

I don't understand why it= would be spurious. In this case, the deserializing implementation needs to= inspect every byte anyway.

=C2=A0
This part of the spec is also just generally difficult to follow, in = my opinion. I had no trouble following the=C2=A0ESNIKeys section. Perhaps t= he problem is in the interaction of prose order, serialization order, and p= rocedural code order.

Well, thi= s structure is likely to change a fair bit, so probably not worth trying to= update the text right at this moment.
<= br>
Fair enough. I would also suggest making sure that this secti= on does not span a page boundary. That made things worse for me.
=
thanks,
Rob=C2=A0
--0000000000003e715705956c8df0-- From nobody Mon Oct 21 07:41:39 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32229120088 for ; Mon, 21 Oct 2019 07:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsbUUlfXIqIZ for ; Mon, 21 Oct 2019 07:41:36 -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 6AD9D12004A for ; Mon, 21 Oct 2019 07:41:36 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id n14so13603568ljj.10 for ; Mon, 21 Oct 2019 07:41:36 -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=1iAYzCJhEmATccxrF0T1LAYyFewtQgVlBC8+vpBkCdI=; b=CYDQRXhCjCRCmTE26e0P5/83erf8b3B2XxkesIXk3ZX1WRawtvFJzd1sBCmq1E/ZOi 7C+paf4vJ7kUk/k7+1sP5pSpwSihOHRyRQY3XLArGNF4V6RbZ6GLbGkwkc0wmaxwIOrQ yFeQBGX1DSiKudl2ICYau9OTIdm21vPwJbHs0agETL21txUfICaI4v7sDCjBZNXOLk3C KvhPg5Z9FSr5DfF9ELISgj7dYDJtNdLgd7VORFl/x/omQiCu0tpxlceSyuSlqKG9PdZ5 GOki9Gg7NhFWp/hedVOvWtNwCMIM3gRAYNK4JSSN0QJdkNfTOFY0e6ODcd13b2/+6J0q rbmw== 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=1iAYzCJhEmATccxrF0T1LAYyFewtQgVlBC8+vpBkCdI=; b=Lyx86d2avFoSw+DX95CD/W5q9RZl8BPUqYKPqJKaML5N2+mS3zBjryd6fWQ47ckDD/ k6MEfwfo18Ip2QNo8RbEorwXjYOQfLXHzdP9Ehnk2TcHagsEy9Q4OVOCP78yfGrUEwiZ BcdvnYxeHWB512ouwcWSzgmkpPq6HG+lgFn8pcRbO9efzQqFRYBKXRI1jzg8Z1rWxagV VY5k/25lHXE9kNhNs/LDChQRq2ccNxSTI+XOtV1ITZLo/R43hIHkSQb1Chy1NR0flwJx 18WYHx8KQQVyETkgdxaPBBTE/3vo1FqJ+U0vKrJaIjLXHoQDuYv9/5zhBmto9zyTIaNO 1P7A== X-Gm-Message-State: APjAAAVQJkbkdJEAJkU2ogCaSOWXQY6s4PpywI/knGHgYJ2s9rgT08kK BSLkpwhboY5sk/ajjuUTyYtMYAeXSK7msPjxXkJ8Zg== X-Google-Smtp-Source: APXvYqxkmrmvWU4KnJgqPWr1q/fIcuVxeaq1fVq8LR23J6SrrmnEBdEieBi9A0+2ZgdJn4wvttPF3okzYp5IArk87R4= X-Received: by 2002:a2e:3a14:: with SMTP id h20mr14768042lja.29.1571668894602; Mon, 21 Oct 2019 07:41:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 07:40:58 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ae7fc05956cae8c" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 14:41:38 -0000 --0000000000002ae7fc05956cae8c Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote: > Judging by the mailing list archives, the design of the field is >>> intentional. It's not clear to me why "zeros" wasn't specified as >>> variable-length with a prose restriction, though. >>> >> >> Because then you have a spurious length field. >> > > I don't understand why it would be spurious. In this case, the > deserializing implementation needs to inspect every byte anyway. > Because if you set padding to be the length of the maximum value, then a length byte makes every message one longer. > >> This part of the spec is also just generally difficult to follow, in my >>> opinion. I had no trouble following the ESNIKeys section. Perhaps the >>> problem is in the interaction of prose order, serialization order, and >>> procedural code order. >>> >> >> Well, this structure is likely to change a fair bit, so probably not >> worth trying to update the text right at this moment. >> > > Fair enough. I would also suggest making sure that this section does not > span a page boundary. That made things worse for me. > At this early stage, we usually don't worry over-much about page breaks. -Ekr > thanks, > Rob > --0000000000002ae7fc05956cae8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 7:32 AM Rob S= ayre <sayrer@gmail.com> wrote= :

=C2=A0
Judging = by the mailing list archives, the design of the field is intentional. It= 9;s not clear to me why "zeros" wasn't specified as variable-= length with a prose restriction, though.

<= /div>
Because then you have a spurious length field.
<= /blockquote>

I don't understand why it would be spur= ious. In this case, the deserializing implementation needs to inspect every= byte anyway.

Because if = you set padding to be the length of the maximum value, then a length byte m= akes every message one longer.


=C2=A0
This part of the spec is also ju= st generally difficult to follow, in my opinion. I had no trouble following= the=C2=A0ESNIKeys section. Perhaps the problem is in the interaction of pr= ose order, serialization order, and procedural code order.

Well, this structure is likely to change a fair= bit, so probably not worth trying to update the text right at this moment.=

Fair enough. I would als= o suggest making sure that this section does not span a page boundary. That= made things worse for me.

At this early stage, we usually don't worry over-much about page brea= ks.

-Ekr


thanks,
Rob=C2=A0
--0000000000002ae7fc05956cae8c-- From nobody Mon Oct 21 07:56:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0204F120043 for ; Mon, 21 Oct 2019 07:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 z8fYaTkyg8ut for ; Mon, 21 Oct 2019 07:56:01 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 A3974120096 for ; Mon, 21 Oct 2019 07:56:01 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id 1so4918640iou.4 for ; Mon, 21 Oct 2019 07:56:01 -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=qWO05rT49YCqytvz2oY2rde4EgJNWaw+APa+rjUEmow=; b=nhOkeOveTXA3J/oecyUFvdT2YSlH5CtQHP2HGVlhchCXaPMIWG0Za6zXqEalQQ6pqa mVkerSpYIQ08vRtgZrPPfNeDjrh+/payGQC1Ko8yWjoI5tfXrc/DiEvFPKdiZfhxrgao u5Sp+9do1eluk8XmWehJtxfjegjV90tnHWj1R1iZ59ZPzyiS0kGJXEEw7qRpYXRdqXv8 EyrslNE+avfArGQJyos7z05yJV9YJNS9XdxWt1rhc3poFIVTjsABVL8+GXvRkfZtx7OE D7ZTX/E3EIiAWiMO0P2hrmKokxzj0ZiFYlyBTyVshYZGXi/UsNYLQ8gdt8GSp6/adjve ThoA== 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=qWO05rT49YCqytvz2oY2rde4EgJNWaw+APa+rjUEmow=; b=DcRh4gbYVY2YVcbzMhRRCbVgbX/sI2ARPyVnDdTtX0Ve8AhmM7W3hFSVy8inTKpsrK XrfDr/F6t/Bxxt3U3ulJ8vyJnUKEiCqZoOOTejp3jYGfbY+ufNspdEhPctM8+gU+ypnM ipqlryWfJeLApAY2esTCcyWOfgaq8s6hxZZGDQy2BSlvDGh6vzadDCRuE8GrRqm4vypB Uo+hoJ0b3U+nWReOz70mVEEFVRTn8jH0KMkB0a+kQT8cifSIXFQ3kNsaBG+zlLPAKbSN 2/E5mu3wU+1H8QM+lqBYmB2b1PTS0xWZloLZPwlTHDSc4D98sCNkQ5KSxNR29Y5TSKAw PwhA== X-Gm-Message-State: APjAAAXI0oMttxNxbTu0kjFBgG02ieJ1J3xg7fQS0ItwZ5gN1Ip8Xebo lxvgUKja5zSUn6Oz4htLqwe26YeokACINx9wUnqNHMRl X-Google-Smtp-Source: APXvYqwN59URPknCZ/5ME0YjZ7SVCtIo6A72AlW5EDDIv3ot0HVBhP2IF11R2lf2zcKdheBnrv557BANjzTaqYvJq8E= X-Received: by 2002:a6b:400e:: with SMTP id k14mr9653375ioa.254.1571669760774; Mon, 21 Oct 2019 07:56:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 07:55:49 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cb952005956ce1af" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 14:56:04 -0000 --000000000000cb952005956ce1af Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote: > > > >> Judging by the mailing list archives, the design of the field is >>>> intentional. It's not clear to me why "zeros" wasn't specified as >>>> variable-length with a prose restriction, though. >>>> >>> >>> Because then you have a spurious length field. >>> >> >> I don't understand why it would be spurious. In this case, the >> deserializing implementation needs to inspect every byte anyway. >> > > Because if you set padding to be the length of the maximum value, then a > length byte makes every message one longer. > Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you just mean it would be superfluous. That could be true, but it is dependent on the value of a field in a DNS record. If it had a length, I could have used existing payload deserialization code. Having gone through every message in this draft, I don't understand the rationale behind the following section and the corresponding PaddedServerNameList: " ... CipherSuite cipher_suites<2..2^16-2>; uint16 padded_length; ... padded_length : The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the server expects to support rounded up the nearest multiple of 16. If the server supports wildcard names, it SHOULD set this value to 260." That's not to say the draft is wrong, but the rationale seems missing. The rationale may exist in a mailing list message or github issue. thanks, Rob --000000000000cb952005956ce1af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 7:41 AM Eric Resc= orla <ekr@rtfm.com> wrote:


On Mon, Oct 21, 2019 at 7:32 AM = Rob Sayre <sayrer@= gmail.com> wrote:

=C2=A0
<= 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">
Judging by the mailing list archives, the design of the fiel= d is intentional. It's not clear to me why "zeros" wasn't= specified as variable-length with a prose restriction, though.
=

Because then you have a spurious length fi= eld.

I don't understa= nd why it would be spurious. In this case, the deserializing implementation= needs to inspect every byte anyway.
Because if you set padding to be the length of the maximum valu= e, then a length byte makes every message one longer.

Sorry if I'm being dense here. Couldn'= t "zeros" have a length? Maybe you just mean it would be superflu= ous. That could be true, but it is dependent on the value of a field in a D= NS record. If it had a length, I could have used existing payload deseriali= zation code.

Having gone through every message in = this draft, I don't understand the rationale behind the following secti= on and the corresponding PaddedServerNameList:

&qu= ot;
...
CipherSuite cipher_suites<2..2^16-2>;
= uint16 padded_length;=C2=A0

...

padded_length : The length to pad the ServerNameList value to prior<= br>=C2=A0 =C2=A0to encryption.=C2=A0 This value SHOULD be set to the larges= t
=C2=A0 =C2=A0ServerNameList the server expects to support rounded up t= he nearest
=C2=A0 =C2=A0multiple of 16.=C2=A0 If the server supports wil= dcard names, it SHOULD set
=C2=A0 =C2=A0this value to 260."

That's not to say the draft is wrong, but the rat= ionale seems missing. The rationale may exist in a mailing list message or = github issue.

thanks,
Rob
--000000000000cb952005956ce1af-- From nobody Mon Oct 21 08:44:13 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D10712009E for ; Mon, 21 Oct 2019 08:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 VnEjwpbzQ6I2 for ; Mon, 21 Oct 2019 08:44:09 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 B3061120098 for ; Mon, 21 Oct 2019 08:44:09 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id d22so6808907pll.7 for ; Mon, 21 Oct 2019 08:44:09 -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=q9FBzYwm8I5OsfZWGzyq1h+sOK+FtqD8528yiQnCR+o=; b=m7dux5EvsLcwmL3vARboXwvX1AInxHt4bik7rpza4FBzNexnhBIy+SdNsjtqAq2EGJ QfahGOKdzQrT6zvl09NHt57h4nF7Nuv10Bt/ZdiKStcp9v9TE5tM6A/sTMkjB3509ZiK sEkO5oJnkSa7WlxxiZ2V/CajnI0mvNo2i7EqU= 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=q9FBzYwm8I5OsfZWGzyq1h+sOK+FtqD8528yiQnCR+o=; b=igDNGFqhAHY3MqXTDGpF58IE4dTqIBXzcvKc8eXSmvaI3pIigV44dRqedfBLiuFcjL Khn9b4y7IUb+JB3cTddWKy2tBqx9MCLFZ68tkbNG7lZqWr8ilemQSO7RXPIG6MdxV/iC L795VoGSAVyzeBzRQcT+n9crRJsT6ywyKJ/cjjXhTazNDjnKqPgd56F9J6a2NQfIS17Z VtCxdGfvJxuPcYgWV3ntuKXEUDJ6ViXNBsBkCJxzAe4SyHJnBhdCpCA3GbtidYOSSWa7 +W5Q9t3LIjcC0SURu/kZl1gR6TUKFeMhYdVlClMmdGTexJHv1Ap4W3h8JW9bfWJj7pfi cEYA== X-Gm-Message-State: APjAAAX2/Q2Dc503AgIeeu+sEXXw3nC0Ou3joVl+NLXR5VyA+/52EYe8 1yw6jv29GEvmI90rS7tWR6U6JUl92Gl55w8LGdYb X-Google-Smtp-Source: APXvYqxSEZBNjbj4HN7XtgsMctA/gu4ty71sQ7QisYVtaoKeTfL6VvHt7vsi/o00YXu7qFRy/ioXvbsvBBUJQSdfMnk= X-Received: by 2002:a17:902:9a41:: with SMTP id x1mr24910148plv.331.1571672648833; Mon, 21 Oct 2019 08:44:08 -0700 (PDT) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> In-Reply-To: <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> From: David Benjamin Date: Mon, 21 Oct 2019 11:43:52 -0400 Message-ID: To: Hubert Kario Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f0918805956d8dc2" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 15:44:12 -0000 --000000000000f0918805956d8dc2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > > which can be found here: > > > > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > > > > It will run until November 1, 2019. Please indicate whether or not you > would > > like to see this draft adopted and whether you will review and provide > > feedback on it going forward. > > Yes, requiring RSA-PSS causes interoperability issues with smartcards tha= t > don't implement this 16 year old algorithm. But being able to say "if > you're > using TLS 1.3 that means you are not using legacy crypto" has non > insignificant value too. > > This document erodes that. > The document goes into the rationale here under Security Considerations. I'm unhappy about this too, but our experience is that devices without PSS support are fairly common in client certificates. The negotiation order means that accounting for such devices effectively means servers hold back TLS 1.3 for *all* their clients, not just those that are affected. Additionally, even if one could get the negotiation order correct, TLS 1.3 fixes a serious privacy leak with client certificates. Keeping those clients on TLS 1.2 means they continue to leak their identity over the network. To mitigate the second-order effects, the document intentionally makes the code points client-only (the above motivations don't apply for server keys), as well as allocating separate code points from the existing PKCS#1 values. If a client or server wishes to not use[*] PKCS#1 signatures in TLS 1.3, it doesn't need to advertise/accept those code points. TLS libraries probably should also disable them by default. Given all that, I think adding code points for deployments that need them is the right tradeoff. [*] PKCS#1 signatures in certificates and the downgrade-sensitivity of the TLS 1.2 signature aside. > So I'm against adoption of this draft by the WG. > > If it is adopted, I will review and provide feedback on it. > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000f0918805956d8dc2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 9:42 AM Hubert Ka= rio <hkario@redha= t.com> wrote:
On Friday, 18 October 2019 20:44:03 CEST C= hristopher Wood wrote:
> This email starts a call for adoption of draft-davidben-tls13-pkcs1-00= ,
> which can be found here:
>
>=C2=A0 =C2=A0 https://tools.ietf.org/ht= ml/draft-davidben-tls13-pkcs1-00
>
> It will run until November 1, 2019. Please indicate whether or not you= would
> like to see this draft adopted and whether you will review and provide=
> feedback on it going forward.

Yes, requiring RSA-PSS causes interoperability issues with smartcards that =
don't implement this 16 year old algorithm. But being able to say "= ;if you're
using TLS 1.3 that means you are not using legacy crypto" has non
insignificant value too.

This document erodes that.

The document= goes into the rationale here under Security Considerations. I'm unhapp= y about this too, but our experience is that devices without PSS support ar= e fairly common in client certificates. The negotiation order means that ac= counting for such devices effectively means servers hold back TLS 1.3 for <= i>all=C2=A0their clients, not just those that are affected. Additionall= y, even if one could get the negotiation order correct, TLS 1.3 fixes a ser= ious privacy leak with client certificates. Keeping those clients on TLS 1.= 2 means they continue to leak their identity over the network.
To mitigate the second-order effects, the document intentional= ly makes the code points client-only (the above motivations don't apply= for server keys), as well as allocating separate code points from the exis= ting PKCS#1 values. If a client or server wishes to not use[*] PKCS#1 signa= tures in TLS 1.3, it=C2=A0doesn't need to advertise/accept those code p= oints. TLS libraries probably should also disable them by default.

Given all that, I think adding code points for deployments= that need them is the right tradeoff.

[*] PKCS#1 = signatures in certificates and the downgrade-sensitivity of the TLS 1.2 sig= nature aside.
=C2=A0
So I'm against adoption of this draft by the WG.

If it is adopted, I will review and provide feedback on it.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000f0918805956d8dc2-- From nobody Mon Oct 21 09:11:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C7120071 for ; Mon, 21 Oct 2019 09:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 5uOyquzW042m for ; Mon, 21 Oct 2019 09:11:37 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 82AD3120044 for ; Mon, 21 Oct 2019 09:11:37 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id k32so11497570otc.4 for ; Mon, 21 Oct 2019 09:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jnD+/urEZJ/XUTnTTNySltheEoDyLlfAH4WnkYE+adU=; b=lzq7BOsr01U85ac5U6DVmH5F5g0yIEoY82kLkYM9gZmtQF8/m0WpyOTuHB+nweyCnt edniLtQvKOzOr1U6mc6a8zxYzJOVD+feffR7sCpcEXmlhGnnlZDK30YG7TVCvgUFWDJ8 SRF/fV9YuLW3oa/U3pL567Sgp6RRbnTdIyCVOssSqRfoSfcxh1yYTfFwM4oyeRug0btW tAS+IWyEsCFyXfv7RRg0HLZ8ljcurfc2HTVB5dWJMgadna5qYOdVEDJJ7Z767A8xekg6 F9v1ovyzKzWj6pbJIzuC1KKqz7yg+HY2BCZZ3sKogpXN6/TVU63uHgNAv1TwSPi3LZU4 I1Dw== 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=jnD+/urEZJ/XUTnTTNySltheEoDyLlfAH4WnkYE+adU=; b=fIWSZjc6R2JRVsOpCUWvV8rYF+Z6kXVrRiRKl0fd1XqfGqJkJVtApFzJ0/ZrlNticg 1I/GSoMF4GAWpUIsueNcwR+hcTQc30ZrMjAo+Bh1klr47Yb9gYwQuVk2OD2YDQoQ5b0j mUvhGrHsdKcdNt+e9goHvDyRwTH1YS5X/3tqkHypE/NAyl/wZGUDjhT8H0nJik6chUKM DdfJr4kxtzyix/o+BRD7uV2FnSij/lHVBIMUz175TF4MgmHUivJkQkCCwgTIywzACfzl eeq+QoOz78b1V0j3OA4rPdyCA6H2dVPNyGfrKLgEBMR+d9R7jpzxlwKiAysrwk9tA+21 otkQ== X-Gm-Message-State: APjAAAXdOAslWSNTD3c9KWYVMMmO173phPC0UDsfR6j1t8agZ/QB17AE ph2FTXg7ZCqqGXQyv9EnMFEM1q6rF7g7olXTx4nRwA== X-Google-Smtp-Source: APXvYqyOCknum2L9ZWUJZfKir/W8+A1c4v2r862qhg1FNW0+OXYBH3NgnGudOG5N+PJhE3vkjeU5KC0GQonQIslB4MQ= X-Received: by 2002:a9d:4613:: with SMTP id y19mr7396075ote.159.1571674296614; Mon, 21 Oct 2019 09:11:36 -0700 (PDT) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> In-Reply-To: From: Richard Barnes Date: Mon, 21 Oct 2019 12:11:19 -0400 Message-ID: To: David Benjamin Cc: Hubert Kario , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000027117705956df015" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 16:11:40 -0000 --00000000000027117705956df015 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2019 at 11:44 AM David Benjamin wrote: > On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > >> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >> > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00= , >> > which can be found here: >> > >> > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 >> > >> > It will run until November 1, 2019. Please indicate whether or not you >> would >> > like to see this draft adopted and whether you will review and provide >> > feedback on it going forward. >> >> Yes, requiring RSA-PSS causes interoperability issues with smartcards >> that >> don't implement this 16 year old algorithm. But being able to say "if >> you're >> using TLS 1.3 that means you are not using legacy crypto" has non >> insignificant value too. >> >> This document erodes that. >> > > The document goes into the rationale here under Security Considerations. > I'm unhappy about this too, but our experience is that devices without PS= S > support are fairly common in client certificates. The negotiation order > means that accounting for such devices effectively means servers hold bac= k > TLS 1.3 for *all* their clients, not just those that are affected. > Additionally, even if one could get the negotiation order correct, TLS 1.= 3 > fixes a serious privacy leak with client certificates. Keeping those > clients on TLS 1.2 means they continue to leak their identity over the > network. > > To mitigate the second-order effects, the document intentionally makes th= e > code points client-only (the above motivations don't apply for server > keys), as well as allocating separate code points from the existing PKCS#= 1 > values. If a client or server wishes to not use[*] PKCS#1 signatures in T= LS > 1.3, it doesn't need to advertise/accept those code points. TLS libraries > probably should also disable them by default. > > Given all that, I think adding code points for deployments that need them > is the right tradeoff. > I think I agree with both of you here. Eroding the modernity of TLS 1.3 makes me sad, but the draft does a good job of scoping the change to be minimal. The latter points you make here could be stronger in the document. Where you talk about the signature_algorithms in the CertificateRequest, you could also note that if a PKCS#1 signature is received using an algorithm not in that list, then the server MUST reject it (even though this is probably duplicative of RFC 8446). You could probably also say that server implementations SHOULD disable these code points by default. --Richard > > [*] PKCS#1 signatures in certificates and the downgrade-sensitivity of th= e > TLS 1.2 signature aside. > > >> So I'm against adoption of this draft by the WG. >> >> If it is adopted, I will review and provide feedback on it. >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech >> Republic_______________________________________________ >> 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 > --00000000000027117705956df015 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 11:44 AM Davi= d Benjamin <davidben@chromium.o= rg> wrote:
On Mon, Oct 21, 2019 at 9:42 AM Hubert = Kario <hkario@red= hat.com> wrote:
On Friday, 18 October 2019 20:44:03 CEST = Christopher Wood wrote:
> This email starts a call for adoption of draft-davidben-tls13-pkcs1-00= ,
> which can be found here:
>
>=C2=A0 =C2=A0 https://tools.ietf.org/ht= ml/draft-davidben-tls13-pkcs1-00
>
> It will run until November 1, 2019. Please indicate whether or not you= would
> like to see this draft adopted and whether you will review and provide=
> feedback on it going forward.

Yes, requiring RSA-PSS causes interoperability issues with smartcards that =
don't implement this 16 year old algorithm. But being able to say "= ;if you're
using TLS 1.3 that means you are not using legacy crypto" has non
insignificant value too.

This document erodes that.

The document= goes into the rationale here under Security Considerations. I'm unhapp= y about this too, but our experience is that devices without PSS support ar= e fairly common in client certificates. The negotiation order means that ac= counting for such devices effectively means servers hold back TLS 1.3 for <= i>all=C2=A0their clients, not just those that are affected. Additionall= y, even if one could get the negotiation order correct, TLS 1.3 fixes a ser= ious privacy leak with client certificates. Keeping those clients on TLS 1.= 2 means they continue to leak their identity over the network.
To mitigate the second-order effects, the document intentional= ly makes the code points client-only (the above motivations don't apply= for server keys), as well as allocating separate code points from the exis= ting PKCS#1 values. If a client or server wishes to not use[*] PKCS#1 signa= tures in TLS 1.3, it=C2=A0doesn't need to advertise/accept those code p= oints. TLS libraries probably should also disable them by default.

Given all that, I think adding code points for deployments= that need them is the right tradeoff.
<= br>
I think I agree with both of you here.=C2=A0 Eroding the mode= rnity of TLS 1.3 makes me sad, but the draft does a good job of scoping the= change to be minimal.

The latter points you make = here could be stronger in the document.=C2=A0 Where you talk about the sign= ature_algorithms in the CertificateRequest, you could also note that if a P= KCS#1 signature is received using an algorithm not in that list, then the s= erver MUST reject it (even though this is probably duplicative of RFC 8446)= .=C2=A0 You could probably also say that server implementations SHOULD disa= ble these code points by default.

--Richard
=C2=A0
<= div dir=3D"ltr">

[*] PKCS#1 s= ignatures in certificates and the downgrade-sensitivity of the TLS 1.2 sign= ature aside.
=C2=A0
So I'm against adoption of this draft by the WG.

If it is adopted, I will review and provide feedback on it.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic= _______________________________________________
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
--00000000000027117705956df015-- From nobody Mon Oct 21 09:13:29 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BE1120089 for ; Mon, 21 Oct 2019 09:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.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 1HC3ShqoCymc for ; Mon, 21 Oct 2019 09:13:25 -0700 (PDT) Received: from us-smtp-delivery-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF310120071 for ; Mon, 21 Oct 2019 09:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1571674404; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=35hqzeWe1aLa6HYCPOVgYvmha60FAtpIkInDxk8ohd4=; b=h4QvzzZY/C0MVLUZ/QGuES30m1rnZPMTIpLW2iPxCcV9BdJEtKbq1OBfuLewNTaq8PdNzH yOxel4rIq7Eaj+vnPgoWCZi1YTuKQeBgWUX4mo9Y63867FBhETahOcAhYCGVvBYfcmx1B4 y48dpZmKG4k9djcSogvcdjIglVlZ4co= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-276-qnK0SeKrN6OZdMPEDKf3sA-1; Mon, 21 Oct 2019 12:13:18 -0400 X-MC-Unique: qnK0SeKrN6OZdMPEDKf3sA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D1DC61800D79; Mon, 21 Oct 2019 16:13:17 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-53.brq.redhat.com [10.40.200.53]) by smtp.corp.redhat.com (Postfix) with ESMTP id EE95E6012D; Mon, 21 Oct 2019 16:13:16 +0000 (UTC) From: Hubert Kario To: David Benjamin Cc: "TLS@ietf.org" Date: Mon, 21 Oct 2019 18:13:10 +0200 Message-ID: <2346333.Tok7fK9tdU@pintsize.usersys.redhat.com> In-Reply-To: References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 Content-Type: multipart/signed; boundary="nextPart3659103.3jaaIzUkP6"; micalg="pgp-sha512"; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 16:13:28 -0000 --nextPart3659103.3jaaIzUkP6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 21 October 2019 17:43:52 CEST David Benjamin wrote: > On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-0= 0, > > >=20 > > > which can be found here: > > > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > > >=20 > > > It will run until November 1, 2019. Please indicate whether or not yo= u > >=20 > > would > >=20 > > > like to see this draft adopted and whether you will review and provid= e > > > feedback on it going forward. > >=20 > > Yes, requiring RSA-PSS causes interoperability issues with smartcards t= hat > > don't implement this 16 year old algorithm. But being able to say "if > > you're > > using TLS 1.3 that means you are not using legacy crypto" has non > > insignificant value too. > >=20 > > This document erodes that. >=20 > The document goes into the rationale here under Security Considerations. > I'm unhappy about this too, but our experience is that devices without PS= S > support are fairly common in client certificates. The negotiation order > means that accounting for such devices effectively means servers hold bac= k > TLS 1.3 for *all* their clients, not just those that are affected. > Additionally, even if one could get the negotiation order correct, TLS 1.= 3 > fixes a serious privacy leak with client certificates. Keeping those > clients on TLS 1.2 means they continue to leak their identity over the > network. yes, I've read it. 1. I don't expect that heterogeneous deployments of clients (where some=20 smartcards can do RSA-PSS and some can't) will be a significant portion,= =20 let alone the majority, of deployments. 2. servers that do use client certificates for authentication are not=20 generally deployed for the public, on the internet. Those are closed=20 systems, so impact for publicly facing servers is minimal if they need t= o=20 downgrade to TLS 1.2. 3. while client certificate authentication /may/ leak client certificates i= n=20 plaintext in TLS 1.2, by sending them in initial handshake, is not the o= nly=20 configuration that provides certificate based authentication. Adding cli= ent=20 certificates through renegotiation does not leak them and is fairly comm= on=20 deployment model. =20 > To mitigate the second-order effects, the document intentionally makes th= e > code points client-only (the above motivations don't apply for server > keys), as well as allocating separate code points from the existing PKCS#= 1 > values. If a client or server wishes to not use[*] PKCS#1 signatures in T= LS > 1.3, it doesn't need to advertise/accept those code points. TLS libraries > probably should also disable them by default. yes, that's a very good part of this i-d (I will suggest making the languag= e=20 around it more strict than it is now, if the i-d is adopted), but the probl= em=20 I have is that they are allowed at all, as that means the legacy hardware i= s=20 given another decade if not two to get replaced Having configurations that need to downgrade to TLS 1.2 for interoperabilit= y=20 is a good thing because it raises obvious red flags during audits. Algorith= ms=20 advertised by server in CertificateVerify are not an obvious red flag. =20 > Given all that, I think adding code points for deployments that need them > is the right tradeoff. >=20 > [*] PKCS#1 signatures in certificates and the downgrade-sensitivity of th= e > TLS 1.2 signature aside. >=20 > > So I'm against adoption of this draft by the WG. > >=20 > > If it is adopted, I will review and provide feedback on it. > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech > > Republic_______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls --=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3659103.3jaaIzUkP6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAl2t2RYACgkQkqjRuAHS 9fUqvw/5AeCPD/H1VyuaT3BplTwsPghp49xakZkBZpDhKBJn42Ivd1d0kqBt6O0N p/n/hrwbIA8pH/RE86hwb+iObjGf3PHDlHnQdrGwBcv2yGQ+brLdpNkDU09NAmCW awRoxhcQe6vSRLoevQ+PnfbY6iqZMH2HlT48Xy6jKNRu05b6faFBhim2FS+HznSS ClcEme/w8MPuKSfshVrjhCD0EPmcs96FzRhuT7g6zl1iWz7/xYikmG5Me2Pdv+FJ CV1aYv/9LRzS/KrnO0Nw6PRnFJtYJzeiYMeU3lcMBJmCTb+lGtU3h8g09iWyGONz xmlHtynsi21ywhEBY0QFiiz8+kyGW6jnpfWElHAuwPh6wQyX9KWTtM6FBMLRx2IU fdsHryguX3j1hJSlj2XYYs8zx+fe2qE1KQFLor36XdXkgoRa85CsSRoZktM+I8Tv zXOqq7460Quuq6Te3DRpceBF7xZTYQQKPhsWZEby7STw+7yMp5hKizTr0ag/CJ7G W4rhkgpfAmFSI5fIko+wU48Jh8mSWe6iqSJcusfYXV9Drfvn9WVaIRu/WwVMUkFQ R4xt6SE8f85lm9rLagnolZbLQRkvJwvNjyC8ebNwXnFbMWJgwBGZDMC5yaBOIPS2 ZVfe1BUaAcbU5M/nPE8qBqi7kbgme2TdbC/8QXapJPFThWnw02U= =l1Gq -----END PGP SIGNATURE----- --nextPart3659103.3jaaIzUkP6-- From nobody Mon Oct 21 09:20:18 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CD51200B6 for ; Mon, 21 Oct 2019 09:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.251 X-Spam-Level: X-Spam-Status: No, score=-9.251 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 eLCB5stHa_8D for ; Mon, 21 Oct 2019 09:20:15 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 898BF120071 for ; Mon, 21 Oct 2019 09:20:15 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id r1so8085978pgj.12 for ; Mon, 21 Oct 2019 09:20:15 -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=SrH5Ju/5X+9bT/WeSXbfLe8JRuFzjIzZ9zg0//rPh4k=; b=Oat39a9j6LKIKfO8BjObG5tk8Q3Kj0l/PCcWDBVxCMJefw30ZIEKnTFzN58TjXnpY0 498p6Za8MMhLG7vf/rKL5xC1P/TERXa3oR3FmxconBsmZzAqQXIIuXxkh3TrLhMF9bp6 JBGVgtN0s8aJ6s2LWVafAlf2y5DmD9PiPLoUk= 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=SrH5Ju/5X+9bT/WeSXbfLe8JRuFzjIzZ9zg0//rPh4k=; b=dqOebuclXQE2JLaH6vApKHxGliHESJhZhdRI1VY/qGCjeGRrjep5ONaS4QiQn6GYFw DiyhIiBF4wggWjsVaACb7MMsRTpPnd52+ZvnsD/3iabRtcchi20EsMpj/Dlksr2qqa7z AZotezjRPS9Z1Du4kPpNwdEmj9XTDzN3DrPypVDFK1LFJScNRhRuVUm32GqDfNyVd6LV CcfHHWMNR8+KxgRlxO7MN7U4xchXx8HnR4tN9k9rUQdlI0KdbWiuotDRA08aovO0Kdc+ 6GmuKh7S/rmrh0RV2/EQgdp6VyIJgHFzt6Jx4cqhgFjTOGrdE0n+fG8QkIerPqXyOJq0 1LkA== X-Gm-Message-State: APjAAAVx6g0QFKx20WUMEZXyaac/xSrN8fCghZhKKYEkC5zl1HNZg58u 7P0dEUyY742zRljbKvDkswmjUMH0l5PW2RRxFFCyfU5W4g== X-Google-Smtp-Source: APXvYqyAf++QE2b5OLb8izEvH6cqO41eHJcsKf1/NYEWOLobPtpuof0baLAE0IoAKdlPsd6CQ+g1105TOZtUWvmoTRA= X-Received: by 2002:a65:6201:: with SMTP id d1mr26039171pgv.182.1571674813786; Mon, 21 Oct 2019 09:20:13 -0700 (PDT) MIME-Version: 1.0 References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> In-Reply-To: From: David Benjamin Date: Mon, 21 Oct 2019 12:19:57 -0400 Message-ID: To: Richard Barnes Cc: Hubert Kario , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fafa1105956e0e5c" Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 16:20:17 -0000 --000000000000fafa1105956e0e5c Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 12:11 PM Richard Barnes wrote: > On Mon, Oct 21, 2019 at 11:44 AM David Benjamin > wrote: > >> On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: >> >>> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >>> > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, >>> > which can be found here: >>> > >>> > https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 >>> > >>> > It will run until November 1, 2019. Please indicate whether or not you >>> would >>> > like to see this draft adopted and whether you will review and provide >>> > feedback on it going forward. >>> >>> Yes, requiring RSA-PSS causes interoperability issues with smartcards >>> that >>> don't implement this 16 year old algorithm. But being able to say "if >>> you're >>> using TLS 1.3 that means you are not using legacy crypto" has non >>> insignificant value too. >>> >>> This document erodes that. >>> >> >> The document goes into the rationale here under Security Considerations. >> I'm unhappy about this too, but our experience is that devices without PSS >> support are fairly common in client certificates. The negotiation order >> means that accounting for such devices effectively means servers hold back >> TLS 1.3 for *all* their clients, not just those that are affected. >> Additionally, even if one could get the negotiation order correct, TLS 1.3 >> fixes a serious privacy leak with client certificates. Keeping those >> clients on TLS 1.2 means they continue to leak their identity over the >> network. >> >> To mitigate the second-order effects, the document intentionally makes >> the code points client-only (the above motivations don't apply for server >> keys), as well as allocating separate code points from the existing PKCS#1 >> values. If a client or server wishes to not use[*] PKCS#1 signatures in TLS >> 1.3, it doesn't need to advertise/accept those code points. TLS libraries >> probably should also disable them by default. >> >> Given all that, I think adding code points for deployments that need them >> is the right tradeoff. >> > > I think I agree with both of you here. Eroding the modernity of TLS 1.3 > makes me sad, but the draft does a good job of scoping the change to be > minimal. > > The latter points you make here could be stronger in the document. Where > you talk about the signature_algorithms in the CertificateRequest, you > could also note that if a PKCS#1 signature is received using an algorithm > not in that list, then the server MUST reject it (even though this is > probably duplicative of RFC 8446). You could probably also say that server > implementations SHOULD disable these code points by default. > Sounds good to me. I'll include something to that effect in the next revision. (What's the usual order of operations here? It seems weird to change a document mid-adoption-call, and, if the document is adopted, it also seems weird to make the first TLSWG revision different from the document from the adoption call. That suggests tabling this for a little while.) --000000000000fafa1105956e0e5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 12:11 PM Richard = Barnes <rlb@ipv.sx> wrote:
On Mon, Oct 21, 2019 at 11:44 AM David Benjamin <davidben@chromium.org> wrote:=
On Mon, Oct 21, 2019 at 9:42 = AM Hubert Kario <= hkario@redhat.com> wrote:
On Friday, 18 October 2019 20:4= 4:03 CEST Christopher Wood wrote:
> This email starts a call for adoption of draft-davidben-tls13-pkcs1-00= ,
> which can be found here:
>
>=C2=A0 =C2=A0 https://tools.ietf.org/ht= ml/draft-davidben-tls13-pkcs1-00
>
> It will run until November 1, 2019. Please indicate whether or not you= would
> like to see this draft adopted and whether you will review and provide=
> feedback on it going forward.

Yes, requiring RSA-PSS causes interoperability issues with smartcards that =
don't implement this 16 year old algorithm. But being able to say "= ;if you're
using TLS 1.3 that means you are not using legacy crypto" has non
insignificant value too.

This document erodes that.

The document= goes into the rationale here under Security Considerations. I'm unhapp= y about this too, but our experience is that devices without PSS support ar= e fairly common in client certificates. The negotiation order means that ac= counting for such devices effectively means servers hold back TLS 1.3 for <= i>all=C2=A0their clients, not just those that are affected. Additionall= y, even if one could get the negotiation order correct, TLS 1.3 fixes a ser= ious privacy leak with client certificates. Keeping those clients on TLS 1.= 2 means they continue to leak their identity over the network.
To mitigate the second-order effects, the document intentional= ly makes the code points client-only (the above motivations don't apply= for server keys), as well as allocating separate code points from the exis= ting PKCS#1 values. If a client or server wishes to not use[*] PKCS#1 signa= tures in TLS 1.3, it=C2=A0doesn't need to advertise/accept those code p= oints. TLS libraries probably should also disable them by default.

Given all that, I think adding code points for deployments= that need them is the right tradeoff.
<= br>
I think I agree with both of you here.=C2=A0 Eroding the mode= rnity of TLS 1.3 makes me sad, but the draft does a good job of scoping the= change to be minimal.

The latter points you make = here could be stronger in the document.=C2=A0 Where you talk about the sign= ature_algorithms in the CertificateRequest, you could also note that if a P= KCS#1 signature is received using an algorithm not in that list, then the s= erver MUST reject it (even though this is probably duplicative of RFC 8446)= .=C2=A0 You could probably also say that server implementations SHOULD disa= ble these code points by default.

Sounds good to me.=C2=A0 I'll include something to that effect= in the next revision.

(What's the usual order= of operations here? It seems weird to change a document mid-adoption-call,= and, if the document is adopted, it also seems weird to make the first TLS= WG revision different from the document from the adoption call. That sugges= ts tabling this for a little while.)
--000000000000fafa1105956e0e5c-- From nobody Mon Oct 21 09:45:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8C912010D for ; Mon, 21 Oct 2019 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZrKKuTnowhV for ; Mon, 21 Oct 2019 09:45:02 -0700 (PDT) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 5415B1200F8 for ; Mon, 21 Oct 2019 09:45:02 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id t8so10648638lfc.13 for ; Mon, 21 Oct 2019 09:45:02 -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=5Jfo8jjkzOiqjNvuu5oKCk3RzKXvjAkhqe1cUiObFbc=; b=E0wzjuP/luQJv0X7QGibuTQGlvuQzyZCau2285/6tvHX4qUBgvfJcSLxH5VM2nWMUi rmTPMWw6m5uXReomsq3lmR7w8twi26Cy/LIRVdmI8yKJjRlhfD93I3EfKvcqV2lAi3xp n+cCVz1Cm6vvcSgb06ilmYsLXMZMurNDpmgHhCshR9w/htUlKFgWzbuQGMZ5HWr6pJwG QjGlbXQ/GmQZmjICx4oHlzqs+Q7/B5+2xIOsxpOZB5sR+D3pRTlUE3CFyQSyrz1oFMfA /wr4L25C2TlhoIZfdY98oESkZxKvh9JyJfLOHbf0eQUKpniUvgq5IgMOsJx7AbYDwTkn UaUA== 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=5Jfo8jjkzOiqjNvuu5oKCk3RzKXvjAkhqe1cUiObFbc=; b=VuOMO6DCVwBzKG8tAFi6OKF+viRKwefoF7E5UKHDcidqQsla9aqX+dg4GV2aB6BRkT GQViJWwesulv1FRYzgpjoQT0v/oRK2MycwEx+lUx5cZpZo/x3R6ip8xsEJv7Y6eeq8gh Fq+PZo34IL4NKr2SYIqb7vBQBid7ZZV6tNnRhEwbDPQaUnaxkeVmMC0bGU74XzRNt65D 7oT2G9DsTszJRc/z2XE3E5blBsu/M/8LVPjUJDudDi3TQ45e2TJiALk/iuzG3a1Sng+S RzvF3rXafEMdH/YiPmiMIKHWUu/W0spxBJUXJ567x9/QiUogQGJQHD9s9lToAywqQIWH aBVg== X-Gm-Message-State: APjAAAVguDEKeRRLJc1vAEBiWnnd2oIhBZJci4xhekichTaZoW7jrD4G SBtX3fhzMYLldfaWsGoSlp5I8OLS6WUbJusAkBHnzw== X-Google-Smtp-Source: APXvYqwS1VYWRaL0H6fwEGoctEJ9seDDydGoWskVX2IrOfL8uBYeiqsCad4LOTgLuZJX4FhKUqmJPBImypwFSsVGrFM= X-Received: by 2002:ac2:484e:: with SMTP id 14mr8874104lfy.184.1571676300514; Mon, 21 Oct 2019 09:45:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 09:44:24 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000982bfa05956e6725" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 16:45:04 -0000 --000000000000982bfa05956e6725 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: > On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla wrote: > >> >> >> On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote: >> >> >> >>> Judging by the mailing list archives, the design of the field is >>>>> intentional. It's not clear to me why "zeros" wasn't specified as >>>>> variable-length with a prose restriction, though. >>>>> >>>> >>>> Because then you have a spurious length field. >>>> >>> >>> I don't understand why it would be spurious. In this case, the >>> deserializing implementation needs to inspect every byte anyway. >>> >> >> Because if you set padding to be the length of the maximum value, then a >> length byte makes every message one longer. >> > > Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you > just mean it would be superfluous. > Yes, that is what I mean. -Ekr --000000000000982bfa05956e6725 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 7:56 AM Rob S= ayre <sayrer@gmail.com> wrote= :
On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Oct 21, 2019 at 7:= 32 AM Rob Sayre <s= ayrer@gmail.com> wrote:

=C2=A0
<= div dir=3D"ltr">
Judging by the mailing list archives, the design of th= e field is intentional. It's not clear to me why "zeros" wasn= 't specified as variable-length with a prose restriction, though.
=

Because then you have a spurious len= gth field.

I don't un= derstand why it would be spurious. In this case, the deserializing implemen= tation needs to inspect every byte anyway.

Because if you set padding to be the length of the maximu= m value, then a length byte makes every message one longer.

Sorry if I'm being dense here. Could= n't "zeros" have a length? Maybe you just mean it would be su= perfluous.

Yes, that is = what I mean.

-Ekr

--000000000000982bfa05956e6725-- From nobody Mon Oct 21 10:08:45 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F19B12010F for ; Mon, 21 Oct 2019 10:08:43 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 NX-8cg4RG83C for ; Mon, 21 Oct 2019 10:08:40 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 C4C831200F7 for ; Mon, 21 Oct 2019 10:08:39 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id 71so9468359qkl.0 for ; Mon, 21 Oct 2019 10:08:39 -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=M266/ywGwZoxMhCef+fHtm1DsaduvL5OoeZMsT/7LCg=; b=k+VmeyChfA8DqC3uWGP8odM3RSajDryUtMBNPvVuvV+4cX0yZmRLSjKYnk+Yn/6+Rr St1tX51rBUVvcZch6DBQwltC8kws+AqS5XjVZmOBqBJOpyifq28e1OqXahAWGvLa1nca 6M/F1b4opFknVBNFX4C3SuohhPV26gxhzjdLI= 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=M266/ywGwZoxMhCef+fHtm1DsaduvL5OoeZMsT/7LCg=; b=INWkhfCtrAUyoAcO7uc4gaxAaptPfoAVtQdnZ3q/wGFEOtdGHOzQOBI9ng5x8ahycI QwBvWaVOofyHmH1DQWmr1C0eD0pomx4OSoJYccKMlEseHHGAmQhMlHopcv8p2oeYyZco TaxyxRrcKz6PkJ2aMuFn386sXi66zwzDyJtM9W9Aj/0jO8bkoT+WVLKT8bgJAAbK4RiX ZYeJQnoMkNFlUZ6E5xL+9ZRcyo2UTEOKflcVHq4/QyqnfC8vW+dG5Ch8e1LHPSUUV9S+ fmb7YePRC3ZpBpW280hYlpIY6l1RQ8xNizw95Dsm4mVnKfD3Zrwjq10kbtH5qam6jZ3s IICg== X-Gm-Message-State: APjAAAVlPQsSiMPlEd0RA1QaZ5gT3dBSepLRknLK/OJ+6wifJbnFc8t8 /WMF9QEA8O7mHJStE/O7P6Y68Q== X-Google-Smtp-Source: APXvYqzvlViN21h/hHu2APgoHrAszYcE/U6J0fQdmUBbmOsX0t39qMCcuzvqT8dhsHDQFv5oia9o7w== X-Received: by 2002:a37:e10d:: with SMTP id c13mr22050509qkm.35.1571677718705; Mon, 21 Oct 2019 10:08:38 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id s5sm7961987qts.76.2019.10.21.10.08.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Oct 2019 10:08:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Sean Turner In-Reply-To: Date: Mon, 21 Oct 2019 13:08:37 -0400 Cc: Richard Barnes , "TLS@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <843cc437-4c6d-43ce-b634-527a287c4e27@www.fastmail.com> <2641069.fcJi2IyA6W@pintsize.usersys.redhat.com> To: David Benjamin X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 17:08:43 -0000 > On Oct 21, 2019, at 12:19, David Benjamin = wrote: >=20 > (What's the usual order of operations here? It seems weird to change a = document mid-adoption-call, and, if the document is adopted, it also = seems weird to make the first TLSWG revision different from the document = from the adoption call. That suggests tabling this for a little while.) Yep, I=E2=80=99d hold off on making any changes until we finish the = adoption call. The individual draft is really just a starting place. = Assuming nobody starts screaming =E2=80=9Cno=E2=80=9D, I would submit = the renamed version that matches the individual one to move it to the WG = and then submit a revised version including these changes. I.e., as you = said sit on it for bit. spt= From nobody Mon Oct 21 10:55:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7B120105 for ; Mon, 21 Oct 2019 10:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 y2sRZcjDNLG4 for ; Mon, 21 Oct 2019 10:55:11 -0700 (PDT) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 DD5BE1200E0 for ; Mon, 21 Oct 2019 10:55:10 -0700 (PDT) Received: by mail-io1-xd2a.google.com with SMTP id c6so16953731ioo.13 for ; Mon, 21 Oct 2019 10:55: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=X0OhClZWrSFSO7K2/El+I1YXsm+TAJf2zC7TGBmQVNs=; b=O1RabkKOlg30hOE0TgQEr4xThw0bMYzjnjCey1hhrdcaAgL1Boh/LE23U9ygXQ4OJt PmX5eSAg+1jn9xCpkiDZ/9QowKxP4rmeD41wN6rZLawytCVnulgzqiY9jVnh4jVsPFdu 5QB0qcY6mgmh8EJPxLSh7/8oiuOxmT+Jnpxpbg+zNIL32HYfCHNl5do8h02mLVwp+G1D bVN9Y+HsR5jZIk7iVIs+gVXH2KAOJsOxzcn5CtIdxLqQswxM/UQdhfyYHUwcZBMGJVZN JCp7A59CXXXKH/4Bd28U5sVmOhwQpNW1OdCcDWlf/XZLFuA1JGIYXq5DcLKvjswnflxR B/YA== 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=X0OhClZWrSFSO7K2/El+I1YXsm+TAJf2zC7TGBmQVNs=; b=HfVuId6Fa68IBljvSgvITY7ZwWCaEXkk2uZiqNQ1W1zM017r7ZQrRgz5Rbjqyciw38 5gtR/8mvHY++U0WI5ID8GzC3lmjBT/ivc9LZOfikn1JrQjrC6KZMIDu7gHc6SexLmFIF FOosJH1SJXNB1os4C1FKHnl8bKj5138lb0RHjZlqrQqCHmwHmPz7DRxcVdxOgllvIYmC EPi5BxIGxAowTKEROTQ6IEpBHYflCwe6FyJyqm1gFa4NQ09JWfar783QyViHTjqYP0mc bZuR8C8qPzQF54hWupCDjpO7FSd9rH8LR1keTb3W9vejTbJFEEdWgUkabk/yWHTZLjhw AheQ== X-Gm-Message-State: APjAAAUC+rvuxz1ZyUJbl4GD0TDQYE8LFtARwbsAChTECScU+WwEmmvB QaUT6d2Yi30uTzyY2ArjgsNOPgKdGxSvivC08x8= X-Google-Smtp-Source: APXvYqwCWW1WA81O66dkZK9zOyuG3NDIzo0cn48GxP9MfYQijnRPeGTU4smCNRg4juTiqSZsAs3fsT+A58RZPnL+H6c= X-Received: by 2002:a02:c646:: with SMTP id k6mr23813546jan.53.1571680510068; Mon, 21 Oct 2019 10:55:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 10:54:58 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000080cb1505956f62b7" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 17:55:13 -0000 --00000000000080cb1505956f62b7 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: > >> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you >> just mean it would be superfluous. >> > > Yes, that is what I mean. > OK. To be clear, I understand why there is padding in the spec. I don't understand three aspects: 1) Where did the number 260 come from? It also seems to conflict with the "multiples of 16" advice in the previous sentence. 2) Why does the server set the padding amount? If clients were allowed to vary it with different amounts of zeros, wouldn't that be more anonymous? 3) Why is the length of "zeros" implicit rather than explicit? Is it to save a few bytes, or is there a deeper reason? None of this stuff signals a flaw in the draft from an interoperability perspective--I was able to follow it as a non-expert in TLS and get things working. But I still have questions about why things are specified this way. thanks, Rob --00000000000080cb1505956f62b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 9:45 AM Eric Resc= orla <ekr@rtfm.com> wrote:


On Mon, Oct 21, 2019 at 7:56 AM = Rob Sayre <sayrer@= gmail.com> wrote:
Sorry if I'm bein= g dense here. Couldn't "zeros" have a length? Maybe you just = mean it would be superfluous.

Yes, that is what I mean.

OK. To be clear, I understand why there is padding in the spec. I do= n't understand three aspects:

1) Where did the= number 260 come from? It also seems to conflict with the "multiples o= f 16" advice in the previous sentence.
2) Why does the serve= r set the padding amount? If clients were allowed to vary it with different= amounts of zeros, wouldn't that be more anonymous?
3) Why is= the length of "zeros" implicit rather than explicit? Is it to sa= ve a few bytes, or is there a deeper reason?

None = of this stuff signals a flaw in the draft from an interoperability perspect= ive--I was able to follow it as a non-expert in TLS and get things working.= But I still have questions about why things are specified this way.
<= div>
thanks,
Rob
--00000000000080cb1505956f62b7-- From nobody Mon Oct 21 11:09:35 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080F8120105 for ; Mon, 21 Oct 2019 11:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqxmnKJrJwGi for ; Mon, 21 Oct 2019 11:09:32 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894401200E0 for ; Mon, 21 Oct 2019 11:09:31 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id m7so14380233lji.2 for ; Mon, 21 Oct 2019 11:09:31 -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=fQ9w71+zyg+5pcC9dMGh4vXAjEqHFO2oUaffgTbOqLQ=; b=z2iq7dKD3RutqmuHS7TngZozOy19f65/5X+XBWNLnqUaOWAhoOeMZytJTBHZXaESqG FuIINzlmLm1Olfa7SaD+Nd77p4WIQzQay38FokJoALK777HFmOzVGX2uaSuipR364EbW g3TD3HKhI5YdjBAZSCqHgZPSxF7MdEYMa6/tO3Bykmk9kUfmh4h7hZnSjAVdHuDCUgHr 9RWejpSbAxAdjuKgH6a7+xxSLy/1gg+pKUe1+ddXjr25hVH9RoEkSozlx3fPxbYzEhtR WS5R8o09Fm8JRsx48hq1tk5Z0XOwPgXluuyIWtEf46G/qF2+pk7NjUiv0Syw4/f83XNt ajHw== 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=fQ9w71+zyg+5pcC9dMGh4vXAjEqHFO2oUaffgTbOqLQ=; b=HhVEr3Jm16t9GpF2S2Im/yAQjegTkCuIcItUxqbmcStSCq26N1VxoTfbclDVAr4Er+ fWuPPkT7jiuaIPvctLuSREc8OchWJRef92dYEU71iwQrGR4UpeyemDNIeuk6f2IQbuno dNf6KVm/W91R3U9fePwTtLq1eUiOqyAFHE0M7AAoI2pc86Fw/EpN6V84S/jtzcNWRzn4 9mVW9htNwuqZfuDWesX3M44J0FwyHW1YFPXPunTJkuKcUJVap4r26jzcz9NQ/oqXxaQV OJFMkMSAo2/SSqBwAay/4qr5TtkWMMaCRGxmeQTTWACZoGGo++d1lES535wxOuXDkYSt jNfA== X-Gm-Message-State: APjAAAVjAEHJT3Oir2nGkwe0PTAwnbQR+LrjUALIT33GWufj10tRVTl6 Wh4lrFcHY2OTcwQn5gjLPjii+vOes8JQx8GKMjVF+A== X-Google-Smtp-Source: APXvYqzHCIkZMLDiQUXxIr3eEHvRThpsHPIg/Zgm1Gjl+mqVTsfp0oUEZXERiXiz4HJZdov6UestZo8p/3DPyGfuPDI= X-Received: by 2002:a05:651c:237:: with SMTP id z23mr16036803ljn.93.1571681369731; Mon, 21 Oct 2019 11:09:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 11:08:53 -0700 Message-ID: To: Rob Sayre Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be4eb005956f9538" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 18:09:34 -0000 --000000000000be4eb005956f9538 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre wrote: > On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote: > >> >> >> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: >> >>> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you >>> just mean it would be superfluous. >>> >> >> Yes, that is what I mean. >> > > OK. To be clear, I understand why there is padding in the spec. I don't > understand three aspects: > > 1) Where did the number 260 come from? It also seems to conflict with the > "multiples of 16" advice in the previous sentence. > I believe it was large enough to fit the maximum plausible label size, but I'd have to go look at the relevant issue. 2) Why does the server set the padding amount? If clients were allowed to > vary it with different amounts of zeros, wouldn't that be more anonymous? > No. You want padding to be set to be the longest size that you would send to any origin in the anonymity group, and the server knows this. Many client padding strategies leak information over time and it's hard to know how to construct one that doesn't unless you know the max. For instance, consider what happens if the anonymity group consists of "a.example" and " thisisaverylongname.example.com" and the client always pads to the next 16. 3) Why is the length of "zeros" implicit rather than explicit? Is it to > save a few bytes, or is there a deeper reason? > It saves bytes on the wire. It's also the way we've done other zero padding. None of this stuff signals a flaw in the draft from an interoperability > perspective--I was able to follow it as a non-expert in TLS and get things > working. But I still have questions about why things are specified this way. > Generally speaking, these issues were aired on the list or in Github issues, so the best way to answer them is to go look at the history -Ekr > thanks, > Rob > --000000000000be4eb005956f9538 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 10:55 AM Rob = Sayre <sayrer@gmail.com> wrot= e:
On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Oct 21, 2019 at 7:= 56 AM Rob Sayre <s= ayrer@gmail.com> wrote:
Sorry if I'= m being dense here. Couldn't "zeros" have a length? Maybe you= just mean it would be superfluous.
Yes, that is what I mean.
OK. To be clear, I understand why there is padding in the spec= . I don't understand three aspects:

1) Where d= id the number 260 come from? It also seems to conflict with the "multi= ples of 16" advice in the previous sentence.

I believe it was large enough to fit the maximum p= lausible label size, but I'd have to go look at the relevant issue.
=


2) Why does th= e server set the padding amount? If clients were allowed to vary it with di= fferent amounts of zeros, wouldn't that be more anonymous?
<= /div>

No. You want padding to be set to be = the longest size that you would send to any origin in the anonymity group, = and the server knows this. Many client padding strategies leak information = over time and it's hard to know how to construct one that doesn't u= nless you know the max. For instance, consider what happens if the anonymit= y group consists of "a.example" and "thisisaverylongname.example.com" and t= he client always pads to the next 16.


3) Why is the length of "zeros" implic= it rather than explicit? Is it to save a few bytes, or is there a deeper re= ason?

It saves bytes on t= he wire. It's also the way we've done other zero padding.
=


None of this stuff si= gnals a flaw in the draft from an interoperability perspective--I was able = to follow it as a non-expert in TLS and get things working. But I still hav= e questions about why things are specified this way.

Generally speaking, these issues were aired on = the list or in Github issues, so the best way to answer them is to go look = at the history

-Ekr


thanks,
Rob
--000000000000be4eb005956f9538-- From nobody Mon Oct 21 11:26:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0C2120111 for ; Mon, 21 Oct 2019 11:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CDjzsRwebJJw for ; Mon, 21 Oct 2019 11:26:04 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 496C012010F for ; Mon, 21 Oct 2019 11:26:04 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id b136so17136593iof.3 for ; Mon, 21 Oct 2019 11:26: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=CHTMO0EtmA4p37x7glUxybOUkx9suCGBUIhFKmBz0pg=; b=eSMxKYoHUxSqIpraavxhW7A964W1YRYchrHZN1DWJXCJy8dtaN8kaRcZ4brnmJ25fd 2EDKYSxqVh81hx80ZmHKia3OS8l1Slk/5BcJZZIu5pBJN/YXociyj2ZTA4OCtLlokr7F BNQCuCAj6J5Ne6ytLu4UAyZT0y1yGvlB6SF3BDEnLKdd6RVKEJ8WSPkrB47XqWGmf7/7 foPbO8UMndHfpo81WnluJpHzaEw4ntpynWnRj7uCymhZlujlb5coPN0cBa41eVS1DFbg z5guIOLNjdFyLvJDx/s2uZ3k5Mzj/Chy+eh10l40gNdswjDa6o5uMhrVv5Gl8f8bl/hv UNhg== 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=CHTMO0EtmA4p37x7glUxybOUkx9suCGBUIhFKmBz0pg=; b=QdtWVEvI2MkJ9AXE1sYRaoZHaMElWqRxqVMu8OiDC1vP+vYC69OtYGKoCshZsGeTUs QTOria1EJJEPv0O2cITO0Bkr0Rlrt0H38OIgpX/bLBlG4OWz3MD4rYbkbogHwbq5IWBJ 7KFa5T3+2OGKst8B5JXEuRhYP7NewUGE0ljUUnQ38xVq4VuLU9UcvkcQX34gILUwRoNh NLjHc2psUWm77WcXNoHEKUiDDvOmAXjuSA9VFRAcUa/Zi09kIJqBcuacKdOKgu14LNJu RyN4Z5zW5vTVo9mQducxsX4pEYn7F8prMtHYAvf1BenMoTOlAzJAKM4x68K/Z4XZ0MwG nLbw== X-Gm-Message-State: APjAAAXX1A+dYH6THiemzQBbGsUDOvQ2GJlUqK5lv13nT0NaefPcd1Xr Cry9QpEPvOrlKAzFqza7RhBHjRCdMEuem/fAH4s= X-Google-Smtp-Source: APXvYqzRImIg1bsqt0eZXwRm98nhTTN3knOOZKOJY+zqRzEPZpzAaq2TTE9K5tL8vuoqFh5IpNJ2uddu/XvSFxyL7oI= X-Received: by 2002:a05:6602:21c2:: with SMTP id c2mr12202298ioc.189.1571682363474; Mon, 21 Oct 2019 11:26:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 11:25:52 -0700 Message-ID: To: Eric Rescorla Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f986b505956fd0d7" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 18:26:06 -0000 --000000000000f986b505956fd0d7 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 11:09 AM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre wrote: > >> On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote: >> >>> >>> >>> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: >>> >>>> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe >>>> you just mean it would be superfluous. >>>> >>> >>> Yes, that is what I mean. >>> >> >> OK. To be clear, I understand why there is padding in the spec. I don't >> understand three aspects: >> >> 1) Where did the number 260 come from? It also seems to conflict with the >> "multiples of 16" advice in the previous sentence. >> > > I believe it was large enough to fit the maximum plausible label size, but > I'd have to go look at the relevant issue. > I have not tested this, but I wondered about IDNA-encoded domain names as I read. Is their encoded form always under 255? So, it might be worthwhile for the draft to explain where 260 came from. > > > 2) Why does the server set the padding amount? If clients were allowed to >> vary it with different amounts of zeros, wouldn't that be more anonymous? >> > > No. You want padding to be set to be the longest size that you would send > to any origin in the anonymity group, and the server knows this. Many > client padding strategies leak information over time and it's hard to know > how to construct one that doesn't unless you know the max. For instance, > consider what happens if the anonymity group consists of "a.example" and " > thisisaverylongname.example.com" and the client always pads to the next > 16. > I thought the "padded_length" field might be more useful as a minimum. I agree with you about narrowly-padded messages. None of this stuff signals a flaw in the draft from an interoperability >> perspective--I was able to follow it as a non-expert in TLS and get things >> working. But I still have questions about why things are specified this way. >> > > Generally speaking, these issues were aired on the list or in Github > issues, so the best way to answer them is to go look at the history > I don't agree with this. These questions all concern MUST or SHOULD requirements in the draft. There should be rationales for the requirements that aren't obvious. Especially the "SHOULD" ones. thanks, Rob --000000000000f986b505956fd0d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 11:09 AM Eric= Rescorla <ekr@rtfm.com> wrote:
=


On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre <sayrer@gmail.com> wro= te:
On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla <ekr@rtfm.com> wrote:<= br>


On Mon, Oct 21, 2019 at 7:= 56 AM Rob Sayre <s= ayrer@gmail.com> wrote:
Sorry if I'= m being dense here. Couldn't "zeros" have a length? Maybe you= just mean it would be superfluous.
Yes, that is what I mean.
OK. To be clear, I understand why there is padding in the spec= . I don't understand three aspects:

1) Where d= id the number 260 come from? It also seems to conflict with the "multi= ples of 16" advice in the previous sentence.

I believe it was large enough to fit the maximum p= lausible label size, but I'd have to go look at the relevant issue.
=

I have not tested this, = but I wondered about IDNA-encoded domain names as I read. Is their encoded = form always under 255? So, it might be worthwhile=C2=A0for the draft to exp= lain where 260 came from.

=C2=A0


2)= Why does the server set the padding amount? If clients were allowed to var= y it with different amounts of zeros, wouldn't that be more anonymous?<= /div>

No. You want padding to b= e set to be the longest size that you would send to any origin in the anony= mity group, and the server knows this. Many client padding strategies leak = information over time and it's hard to know how to construct one that d= oesn't unless you know the max. For instance, consider what happens if = the anonymity group consists of "a.example" and "thisisaverylongna= me.example.com" and the client always pads to the next 16.

I thought the "padded_l= ength" field might be more useful as a minimum. I agree with you about= narrowly-padded messages.
=C2=A0

=
None of this stuff signals a flaw in the dr= aft from an interoperability perspective--I was able to follow it as a non-= expert in TLS and get things working. But I still have questions about why = things are specified this way.

Generally speaking, these issues were aired on the list or in Github = issues, so the best way to answer them is to go look at the history

I don't agree with this. The= se questions all concern MUST or SHOULD requirements in the draft. There sh= ould be rationales for the requirements that aren't obvious. Especially= the "SHOULD" ones.

thanks,
Ro= b=C2=A0
--000000000000f986b505956fd0d7-- From nobody Mon Oct 21 11:41:58 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60A4120105 for ; Mon, 21 Oct 2019 11:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 J2MEF2EDf0cw for ; Mon, 21 Oct 2019 11:41:55 -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 AA392120025 for ; Mon, 21 Oct 2019 11:41:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2318BBE39; Mon, 21 Oct 2019 19:41:52 +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 zIrdWdY7wWq7; Mon, 21 Oct 2019 19:41:50 +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 96C55BE2E; Mon, 21 Oct 2019 19:41:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571683310; bh=kkTB2NYs5FOwjkr7eMnb/jV6Gz+g9uT9y4sJjTIOVtE=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=2VI9HjFMSvd5g58sJI9YjoEIizHfV1+f60LAW5FipoyKwSl4Kgmd4VIztEZ9PoHtc Em7frjchcPnKWpOfQrP5gtWrqLN2hsVAS/a8GpUSYj95mJp85H6/5812ULyTNrU2S2 YW17H82DxyaFWS5PFWKo920pg4IgX8LG+wATI1uI= To: Eric Rescorla , Rob Sayre Cc: "TLS@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> Date: Mon, 21 Oct 2019 19:41:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WX0TbLy6EkQ2YiVhy2oX3Y8NriahiXaMm" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 18:41:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WX0TbLy6EkQ2YiVhy2oX3Y8NriahiXaMm Content-Type: multipart/mixed; boundary="8O3Uccfwy85gXJT7ZKtBYBHVpvEbTWuRR"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , Rob Sayre Cc: "TLS@ietf.org" Message-ID: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: In-Reply-To: --8O3Uccfwy85gXJT7ZKtBYBHVpvEbTWuRR Content-Type: multipart/mixed; boundary="------------62B3B2C7E27D171A96806CC6" Content-Language: en-GB This is a multi-part message in MIME format. --------------62B3B2C7E27D171A96806CC6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/10/2019 19:08, Eric Rescorla wrote: > No. You want padding to be set to be the longest size that you would se= nd > to any origin in the anonymity group, and the server knows this. In the past, I've argued that this is not necessarily true and hence the current padding scheme is not a good plan. Two main reasons: - a server may not have visibility of all names that can be in certificate SANs - even if a server does have such visibility at time t, a CA re-issuing certs can change the situation during the lifetime of one ESNIKeys value I believe it is not unknown for servers to have a DB of TLS server certs/private keys that is queried based on the SNI (which could've arrived as ESNI). I don't know how common that is. My guess is that all of the above will lead to everyone always using 260 for this value, making it pointless and somewhat wasteful. I would argue for an algorithmic method of padding and to not require servers to include any value in ESNIKeys at all. I proposed one such algorithm on the list before. Cheers, S. PS: I think 260 is the right max, didn't look it up just now but I did some time ago and it seemed correct. --------------62B3B2C7E27D171A96806CC6 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----- --------------62B3B2C7E27D171A96806CC6-- --8O3Uccfwy85gXJT7ZKtBYBHVpvEbTWuRR-- --WX0TbLy6EkQ2YiVhy2oX3Y8NriahiXaMm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2t++QACgkQWrL68XsX K+pjuxAAv4SSNFo+pZnz8HasweSyiG4kmaH+DamaQKpPjXqx8Rx8xPzsqSOPqzOg ycbqUFY18ibEcJNdIhz0AKdR6D/uAP9ebrQ2/kRomNbHe1LrKjRl42sBA/6l+HbX YBPrZftXbuRdoQJqr0k4Fq52P3RPH9sbPyOQkyv74tZZNdrRZzS4LFy7aNqXGU8A B3biCcBS7moIkT+F9H97Aeoz1dJ5UqRz9e8QAmS0Mp8+ev6WPTCXWkzaCJSbvMhq pRdNgytgXBNEW++qA6AxKqt7Ca/a/wsTsm/kljWc+dqKw3OF1JxMXP4EzGMU1BNQ IlYXX5AxDKJVD8TPTzH68TcTeiXr9ReoN39CP97vPxjl0v3JNY7mh2/9oXb94V8H aKd1a06MdO1sBGgMk1F+yLgRXq8SDn+xhWaCnTYgRlU/HTkUJEk/CG+c/0ukCHNj /uc3BsYcDNxsaaGQfXca7eRTWWlTk4zecmdOlWhJoSFfNf+vA5KS7XL9tB4AtW+n bN3ojyip4XIqlsKO4q2YbMYe8ZbSWpyp7x1jK31z38u/gcHKJbWR+8TOW+nRTg0o LPv+Ze6h9KQznlxIv9XJa8tJ1o0A9Y1p9zB74Yc29112jJlYHXeNjB5euX5iXI94 +qctQykLIL54GTh6/VhafQX0D6JbEADgqVZ1Sfp1H9TKAJl44DY= =1VPv -----END PGP SIGNATURE----- --WX0TbLy6EkQ2YiVhy2oX3Y8NriahiXaMm-- From nobody Mon Oct 21 11:43:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22344120025 for ; Mon, 21 Oct 2019 11:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BLOoCc3I8zuy for ; Mon, 21 Oct 2019 11:43:02 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 17768120105 for ; Mon, 21 Oct 2019 11:43:02 -0700 (PDT) Received: from xse313.mail2web.com ([66.113.197.59] helo=xse.mail2web.com) by mx37.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iMcdu-0001Rm-DR for tls@ietf.org; Mon, 21 Oct 2019 20:42:59 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46xlrH3NWDz4N2K for ; Mon, 21 Oct 2019 11:42:55 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iMcdr-0007qc-BL for tls@ietf.org; Mon, 21 Oct 2019 11:42:55 -0700 Received: (qmail 26652 invoked from network); 21 Oct 2019 18:42:55 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.199]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Oct 2019 18:42:54 -0000 To: Eric Rescorla , Rob Sayre Cc: "TLS@ietf.org" References: From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Mon, 21 Oct 2019 11:42:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------07DED3083F696AE4F0847AA5" Content-Language: en-US X-Originating-IP: 66.113.197.59 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/gcnlw0QRKNbAP+Q7R/EWH3Kru/cipSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4aioNRigAEGGgKELfu9uCeXgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cBN5HyO9svXODFfKDo2spNmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdGd9U9Oojh2QY0MMPWjRsTVhMmX9VvKuj6psZloQqgYBwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPm2aZV8IQy+1t lZouzjYZdjp6t/bGQkUFXcjsI4cbvH6eNgufYE2F3hOb0LsrGGS6BBO8u0ag4+i9kLOW9cRnakdu 2lX9U0U/jnlrPw5p8im8gM5yDzctcfgaSyAJ9MhDntZcYflIMbaTJGx1xg/L1K1AUBBrtwxVM+r+ oqZYnUJBJwCelAgxI3HE4I5TUXrjZkhGpv3EPeYWzTNzqdCNxj0M4yXd56AXsGo1g3fUsu6jZuM7 jUXIESohoO51xWmU8ZNfCyuJJ0v8KnjP4iInSCUzn7yZwpmJB7GizNBQNhhk86LodOZj79xdSjzK bqR5XHk0qi1hkw/hDGKWkPVYlXF3BhZxGgZFOwvGprxNGaa6/2rAztFeklLxGNN3KHaPkMjB65Ki hPq1I9TXHnOlSkg/OIORZDl9o+TmclcfPTQwNGP0PwcsocAqk8Y/wQ+e4HndwcgUdq9CmjcVQOst ghA= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 18:43:04 -0000 This is a multi-part message in MIME format. --------------07DED3083F696AE4F0847AA5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/21/2019 11:08 AM, Eric Rescorla wrote: > > 3) Why is the length of "zeros" implicit rather than explicit? Is > it to save a few bytes, or is there a deeper reason? > > > It saves bytes on the wire. It's also the way we've done other zero > padding. There also off-by-one or off-by-two issues that arise when the natural length is equal to or very close to the padding target. Suppose that you need zero padding to achieve the limit. Then if you have to stick in one byte of length, you go over the limit. You might get around that by making the padding field optional, but then the syntax would allow to not have any padding and that opens a can of worms.. Or suppose that you need exactly one byte of padding, but the length field is two bytes -- you can't just add one byte, you end up always off by one. -- Christian Huitema --------------07DED3083F696AE4F0847AA5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 10/21/2019 11:08 AM, Eric Rescorla wrote:


3) Why is the length of "zeros" implicit rather than explicit? Is it to save a few bytes, or is there a deeper reason?

It saves bytes on the wire. It's also the way we've done other zero padding.

There also off-by-one or off-by-two issues that arise when the natural length is equal to or very close to the padding target. Suppose that you need zero padding to achieve the limit. Then if you have to stick in one byte of length, you go over the limit. You might get around that by making the padding field optional, but then the syntax would allow to not have any padding and that opens a can of worms.. Or suppose that you need exactly one byte of padding, but the length field is two bytes -- you can't just add one byte, you end up always off by one.

-- Christian Huitema

--------------07DED3083F696AE4F0847AA5-- From nobody Mon Oct 21 12:01:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966F71207FF for ; Mon, 21 Oct 2019 12:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5P0ffbkVrD4X for ; Mon, 21 Oct 2019 12:01:25 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0: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 974D6120241 for ; Mon, 21 Oct 2019 12:01:25 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id y5so13052029ilb.5 for ; Mon, 21 Oct 2019 12:01:25 -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=vS5mVp2oCGsN/H6VgN05lcAu+7d3Uc4Lf3W8QGbdXUg=; b=BTdtobI+Ulf0COlyfyhgh/Y/BIybNZ3jKXRrf8El1aV2HcJyC8WCvdwjx7XmKIFbzm WG8Nrp8/xMKMvITVGBvfpGET5WO9fBaW26aSuZC4wb37W7O0x61ndU9Ir9sHPE5iPy8T RxWg0t7sVyzVNap7nKQO/Q3rzLqhTEsJ3lyXzwv4bGH2D9H05+r2374CQbOqaDP7x0fm nH0V8WOOyXtxOR7T8shuW0eWN5IlmeZGheI013HiKZEUfGdyCBezk9MAiDLGbjaVWhjX YW9Cs/AcN4Txt3VT+VW3IZG/oHRF6gKuFetagp8BQAsCmpC67Zmd1S7vT2EgjOto/0N8 Cykg== 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=vS5mVp2oCGsN/H6VgN05lcAu+7d3Uc4Lf3W8QGbdXUg=; b=rTxes7A82xuEzO/OtkvbnsgTzYJ520qih7DedF1Th8Tt6W9ZoQacZwMQZMGRoWoAou umRpriQiOc4db2lAm+s7pavu0urJZ+HcgWcxiqTz1WEla+YQfM87SIAdBxxtbClXiOrJ dGSyD7eBhG4VFEr8ATBeXXeYwGnpV529saj6Ud9MHhE66SM/1BABPBMYyv3/LunBPm5/ wgBuDHHNqOu+ag55Vsjglm1OY67q3f55NidsGuw0WwfyZm8VNJb59K+ohkRsbF5oW9ng m7zL+wkx8gi+u+N/qrZBs2SeWjbwBruGJX0Z6Rdsve0zxTzBdoS8YsSfXAji1zvLa+kZ KA8g== X-Gm-Message-State: APjAAAXQUIk6CdNjkZJkqEme7QM+bXaEf0H3QqMGPX0apCyJrsJxaNcY OqGMQ9ybdxPdsb5eEnkYGZKdYBWDxMAav7qyRTo= X-Google-Smtp-Source: APXvYqw2ABl/19BpH838CHgzYCCnJ9Yzbvvv8wb80Kh5N8Ark4WiUXnZwadnsxQ6ls7cGsHhqtpyReIxV6MpR4/tmoM= X-Received: by 2002:a92:48cf:: with SMTP id j76mr7757453ilg.189.1571684484715; Mon, 21 Oct 2019 12:01:24 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> From: Rob Sayre Date: Mon, 21 Oct 2019 12:01:13 -0700 Message-ID: To: Stephen Farrell Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006918a40595704f34" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 19:01:40 -0000 --0000000000006918a40595704f34 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell wrote: > My guess is that all of the above will lead to everyone > always using 260 for this value, making it pointless > and somewhat wasteful. > Whether it's wasteful depends on how big typical ClientHello (without early data) messages are. If they'll easily fit in one packet, 260 doesn't matter. This seems like something TLS WG should track, tbh. thanks, Rob --0000000000006918a40595704f34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 11:41 AM Stephen = Farrell <stephen.farrell@cs= .tcd.ie> wrote:
My guess is that all of the above will lead to everyone
always using 260 for this value, making it pointless
and somewhat wasteful.

Whether it's= wasteful depends on how big typical ClientHello (without early data) messa= ges are. If they'll easily fit in one packet, 260 doesn't matter.

This seems like something TLS WG should track, tbh.=

thanks,
Rob
--0000000000006918a40595704f34-- From nobody Mon Oct 21 12:10:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062321201EA for ; Mon, 21 Oct 2019 12:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 BjPS0aH02K_T for ; Mon, 21 Oct 2019 12:10:19 -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 718D812013F for ; Mon, 21 Oct 2019 12:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 105DABE5B; Mon, 21 Oct 2019 20:10:17 +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 AbEUo6t0U_AE; Mon, 21 Oct 2019 20:10:15 +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 830F0BE53; Mon, 21 Oct 2019 20:10:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571685015; bh=X6lCyYvq2EXb4mN8457Zyt9xIpjEcpw3QELQmASByy0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YXi0agS53xUVs7O5yHBrVM0xqsv/RDQ03g5vvz5QEYiefGSeX9/WAIayHnMSJYGNz 533iAlZVCwc3iwYn/9xX1VpOij589V6oPq8pEpcoECJ2OVV72QdZaIXIkuD2q06ZO3 gVW1ibgcK9Fjn+ZF7gn2UKKXUe+r2o0/Hzzg13aM= To: Rob Sayre Cc: Eric Rescorla , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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, 21 Oct 2019 20:10:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PVbMX0PVQkrtVXHtDxBDEWthjndxQ6ZVM" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 19:10:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PVbMX0PVQkrtVXHtDxBDEWthjndxQ6ZVM Content-Type: multipart/mixed; boundary="rV5jJopATfpf1mxOsTUlCSZeNaC0wNtPo"; protected-headers="v1" From: Stephen Farrell To: Rob Sayre Cc: Eric Rescorla , "TLS@ietf.org" Message-ID: Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: --rV5jJopATfpf1mxOsTUlCSZeNaC0wNtPo Content-Type: multipart/mixed; boundary="------------E6FDA90FA68C881E5E3FCC77" Content-Language: en-GB This is a multi-part message in MIME format. --------------E6FDA90FA68C881E5E3FCC77 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/10/2019 20:01, Rob Sayre wrote: > On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell > wrote: >=20 >> My guess is that all of the above will lead to everyone >> always using 260 for this value, making it pointless >> and somewhat wasteful. >> >=20 > Whether it's wasteful depends on how big typical ClientHello (without e= arly > data) messages are. If they'll easily fit in one packet, 260 doesn't ma= tter. I don't think we ought be so confident of that. TLS is so broadly used that there may be other circumstances now or in future where this would be a problem that'd cause ESNI to not be used. It seems prudent to use fewer bytes when that's possible (so long as we don't expose the actual SNI length). Removing the padding_length field also removes a way in which server configurations can be broken (if some server admin sets a too-low value), which is also a more prudent design than we currently have. S. > This seems like something TLS WG should track, tbh. >=20 > thanks, > Rob >=20 --------------E6FDA90FA68C881E5E3FCC77 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----- --------------E6FDA90FA68C881E5E3FCC77-- --rV5jJopATfpf1mxOsTUlCSZeNaC0wNtPo-- --PVbMX0PVQkrtVXHtDxBDEWthjndxQ6ZVM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2uApYACgkQWrL68XsX K+rOUBAAwRK2XUk7R4I6xm6aFR2ZdYI9kifkeqrq88R9aDIqsN4SnJZfsmr1rdq9 PJmplQ1umd8kItfTR61s+agm7jP6bOvwAYifQ0w+Bzsj8vkWioCqIY2PqAYqY74I 1zrK+BkEGk99rjqXW0dBqgG+FHFKqTTYqoanj0fImj5Zg2ITAkoJmEUfQdIntdRo letsXNiy57m9njh+7WryjPxhooB0pNRA+Co84xVuFmdnuUudVhS56obHNilqeBUW BXhooWyvO9xTQ6IGI7xuHvNo+UxyTInHDwLFoW4qkLG+MOO29mW6W+OE3nrVkB8m g4ItvshVAoxGvrXA43OL/T+eswnPS/3p5dNOngD6GBDH0IHqOjErwrsyxUZR/DSK N4Pz1KHvmcTTRPLW3afifVUqLXGkcBa2o0YEYdrh0wdjudjC48FH/ZWN6cul677R R8brNdHHobUOH2gPFuznYGHVZU/ZQ8OULArR6StH5wjEZ75bFip0uPWe+YtimNW1 +x9nrt7RK4MpCu67X6HqGfA6vpzXIlP6jIHmgKtiOd2JCFKENaGlluu4dhhAyg6Q wH9URnID/z2Ls5SJm3t5ufrNt55XynHCLs0mSkjQxfczb8MknBAwbXkZ0TblxjA4 ljMMQVVM15Jx4UhqBt8JqQFAi4D2cK09qZTllKCH+DcdW0rNFlM= =8XT4 -----END PGP SIGNATURE----- --PVbMX0PVQkrtVXHtDxBDEWthjndxQ6ZVM-- From nobody Mon Oct 21 12:14:56 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F086712084F for ; Mon, 21 Oct 2019 12:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Ou2kqH-gPcUJ for ; Mon, 21 Oct 2019 12:14:52 -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 B5C2C1207FF for ; Mon, 21 Oct 2019 12:14:52 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id z10so13096792ilo.8 for ; Mon, 21 Oct 2019 12:14:52 -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=M+h2Ndf+tG3MqbLU/Ysn+E6Wg/EQa5Mleg27QkMIx6I=; b=PrLU8wikcqtQNGhcDNSzeVX2/3CtuVyomQ+XNt65XMiI9U+3wrmBK6Id9CHvzrW13A C7K7BVR4uD5v9y/0atFsEirebzBdDYssbVX5OWx4cOk15SCOUvTZumEdud/CL21xhmFd pw1HHQKZPNvIzFzimCvIrYfiFONkCUmyxLyqa85TSaJsdwGqyGDAsKzjhLyuv2SjdEcp Vb/voNXUPOm4ZFAIhHkLhu4BsZpkxIFKiKjwBz3zlUwm9m4VG9Fg2rPDmGTV/he02SKC i3ySWadKynks0YrKTRszabKduYoecK0ORkmHLt/1LgsPTPzd+l9NRW4bYTT597ZCM9N0 qPXQ== 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+h2Ndf+tG3MqbLU/Ysn+E6Wg/EQa5Mleg27QkMIx6I=; b=q86sVWDkynobn25P5NlPZgIUM4HVPnOji+UaHRw3+Od2ntJ4E/DZrQiQdzUGj1xsUT 9eatx5Ujx1B7xA8EEoD2pWK1qoPRGT4p0XXdd4JcmbZcPcYuWyE3qVyCNu286/hEpo7H tAoMOCJwMqnfXe1sCSuutGAw+nYSb6cqztPtm6pe1S7OcB68gqODhXRetCUu7Ocm7Wau JOPdHnAkC3rB1sO0KjrtSZYODVrDU2/Jg6XitsaMH3l04eLexW+n2qfivq6Bzi17+7qb V7b+6lHFUFisk/xNiM2LifRaZbVfYxO2CU/wtZryd4bs/pkfeKFIR1qXgSFE8ZvEhJ5d BFTQ== X-Gm-Message-State: APjAAAVggUvRPKNNWZN3VR19CzCqJUe6BBFSUN1vx7lDAaUXn9DHog4g ZqgkyfXDD+uXX3euOmZxY+fmx2np8hxGjUENkuw= X-Google-Smtp-Source: APXvYqy4Pkohbkl+xLGV7wfVpV0KcOUYjbQhYw4IWnCe2DVXL7j/Gd/Ws2vdXTSqySNYkrmVLI1VD80zTkeTmPhCwlw= X-Received: by 2002:a92:db0c:: with SMTP id b12mr4184596iln.49.1571685291841; Mon, 21 Oct 2019 12:14:51 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 12:14:40 -0700 Message-ID: To: Stephen Farrell Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000084dfe60595707fca" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 19:14:55 -0000 --00000000000084dfe60595707fca Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 12:10 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 20:01, Rob Sayre wrote: > > On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> My guess is that all of the above will lead to everyone > >> always using 260 for this value, making it pointless > >> and somewhat wasteful. > >> > > > > Whether it's wasteful depends on how big typical ClientHello (without > early > > data) messages are. If they'll easily fit in one packet, 260 doesn't > matter. > > I don't think we ought be so confident of that. TLS is > so broadly used that there may be other circumstances > now or in future where this would be a problem that'd > cause ESNI to not be used. It seems prudent to use fewer > bytes when that's possible (so long as we don't expose > the actual SNI length). > I have seen MTUs under 1500 many times, but nothing under 1200. Is there data on this? (I honestly haven't seen any) > > Removing the padding_length field also removes a way > in which server configurations can be broken (if some > server admin sets a too-low value), which is also a > more prudent design than we currently have. > I think padding_length makes sense as a minimum. As a maximum, it could actually be an attack as well. thanks, Rob --00000000000084dfe60595707fca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 12:10 PM Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:

Hiya,

On 21/10/2019 20:01, Rob Sayre wrote:
> On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell <stephen.farrell@cs.tcd.ie= >
> wrote:
>
>> My guess is that all of the above will lead to everyone
>> always using 260 for this value, making it pointless
>> and somewhat wasteful.
>>
>
> Whether it's wasteful depends on how big typical ClientHello (with= out early
> data) messages are. If they'll easily fit in one packet, 260 doesn= 't matter.

I don't think we ought be so confident of that. TLS is
so broadly used that there may be other circumstances
now or in future where this would be a problem that'd
cause ESNI to not be used. It seems prudent to use fewer
bytes when that's possible (so long as we don't expose
the actual SNI length).

I have seen MTU= s under 1500 many times, but nothing under 1200. Is there data on this? (I = honestly haven't seen any)
=C2=A0

Removing the padding_length field also removes a way
in which server configurations can be broken (if some
server admin sets a too-low value), which is also a
more prudent design than we currently have.

=
I think padding_length makes sense as a minimum. As a maximum, it coul= d actually be an attack as well.
=C2=A0
thanks,
Rob
--00000000000084dfe60595707fca-- From nobody Mon Oct 21 12:24:12 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3447B120108 for ; Mon, 21 Oct 2019 12:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 FwzAdJWWiIkO for ; Mon, 21 Oct 2019 12:24: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 BB45D120112 for ; Mon, 21 Oct 2019 12:24:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27E06BE5B; Mon, 21 Oct 2019 20:24:05 +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 m-roIxjOtwOv; Mon, 21 Oct 2019 20:24: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 8BA8ABE55; Mon, 21 Oct 2019 20:24:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571685843; bh=/iJ/Rmjsxyk/akqG+8TZ1qsbEWczMXq2ydi6/7SGu6g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XeEJFnTFXFtUF/2S5JxCcukBdDrCrnVgq55ZNF0jy+d99Qg33WaQgX7Jud4wVjf22 R8Gjh0eZBD9kk/A/X/z0HsKJxm1jE+sHFCs7JoAlH3QI8wXHWxFA5GMg97Q5sAlXC+ n6xgqrE30Bc4w52sIvGUN2zbqZkh5wsgF9k4E9G8= To: Rob Sayre Cc: Eric Rescorla , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> Date: Mon, 21 Oct 2019 20:23:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nT4OL2BZlMzSWjxn1xIN9pX4TeIpsOFtA" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 19:24:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nT4OL2BZlMzSWjxn1xIN9pX4TeIpsOFtA Content-Type: multipart/mixed; boundary="yfJ9XnVHNWZv2F6B0KG6NhTT7yzb8d48Y"; protected-headers="v1" From: Stephen Farrell To: Rob Sayre Cc: Eric Rescorla , "TLS@ietf.org" Message-ID: <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: --yfJ9XnVHNWZv2F6B0KG6NhTT7yzb8d48Y Content-Type: multipart/mixed; boundary="------------6BD4E143592BC98FF850393C" Content-Language: en-GB This is a multi-part message in MIME format. --------------6BD4E143592BC98FF850393C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 21/10/2019 20:14, Rob Sayre wrote: > I have seen MTUs under 1500 many times, but nothing under 1200. Is ther= e > data on this? (I honestly haven't seen any) My assumption is that maybe 90% of names are <60 octets. That means padding_length of 260 is wasting roughly 200 octets, almost all the time (hi there GREASE!). If that's 20% of what remains available in an MTU then it's still wasted as it'll no longer be available for whatever other things people wanna send with or add to a CH. Prediction: if we stick with the current design, in a few years, if ESNI gets widely deployed, we'll have to revisit that aspect and come up with some more efficient way to solve the problem, and that'll mean ignoring the value 260 in then-deployed ESNIKeys;-( S. --------------6BD4E143592BC98FF850393C 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----- --------------6BD4E143592BC98FF850393C-- --yfJ9XnVHNWZv2F6B0KG6NhTT7yzb8d48Y-- --nT4OL2BZlMzSWjxn1xIN9pX4TeIpsOFtA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2uBcQACgkQWrL68XsX K+rscw/+IPZKDgtz/jgfkgKu0dw6hKMUvwHsjJg3tOU2lbi/9P8nbKnrD/QR6WiJ vQKQHEt4rx0ZTab2G7+atyDANoFSKR8v0ZNFJW+wXC8/tz/7SjMZOk59PB8Dw9cb brh14kDsC+l0sJbBr2BnFqpymJysN+359SFDns4E1IlxPO+oAvUODWDdHSaq5ja+ CX7cYuU5v/wL6Zpvsctd/K8h2Cy4bBuwvEv4cBqjmPBeSb+tYBYS+k2DQXHhRbpf 1uIuQAjWvYru5L1ziRgcO81UDJbZcjuHt3cmGjIWp8XcHIRP4YKdnuPMz1lNcB20 FhkNE/RTDmO8XnX4EKlo/cPbV8Q2hnY2tqErsrUMGf2OoIKr8xkVYZsRqdqgR7i7 kiA6Jf9EXAoEJqxOyINIM1wM3rquFcx/owlQW0Kb68CByZk6A9NSYJu5PG6wla1Q 9DA6QhuRYfCpNcSbC/y2xIqo78/4PSfOdmon0Rg9lGsLIrLaYQ8+lTucWpfvo986 aaxGes9yipeuej2e0/LAimrQUOwnQfpgeLun4aZ3ZPa4qFcNkKarA0MeTqlzcO4b GeGyHETZ/C4bDv7F7U//UPDMRsANr7GJXInD1jxFxxFpTmGeYeWsyqyfTgOTFV7i j3oHnSKBmKGkfj+tozhqTSKDxNrDc5jzImhpqE2A5s6SgGi7n/U= =UQCX -----END PGP SIGNATURE----- --nT4OL2BZlMzSWjxn1xIN9pX4TeIpsOFtA-- From nobody Mon Oct 21 12:30:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67936120871 for ; Mon, 21 Oct 2019 12:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 303ylC0xIon3 for ; Mon, 21 Oct 2019 12:30:11 -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 D585B120879 for ; Mon, 21 Oct 2019 12:30:03 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id y3so14606708ljj.6 for ; Mon, 21 Oct 2019 12:30:03 -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=i35l3v54rKQP1s5+Kb8InGfU4nAXdzHSPS6IqEVG9tQ=; b=lJXiGvYpZ4KbTiT1lFE2RSvmABZQPlqVnb3Z2rQgZS+Zexb2BcThCGwm6lJ+huSwxS OsdAMGSbc64icTwWWVzrBs12Nbw4O1RivM1QkWVt29YUak2k7QsHzBAzdr/mPx7av4di Uo98jF4tMo4jpViHjyXWeYWV/QmX7MZizMVdnnhbLg7M2zP4L1BqYqvnquhNjImEc3Lu HVr2c/VYg9Qfl/zl2c4iViBzcauQsOqKMmFNKZQ5D9+QOct7HS3v+fsHALdwPnzHWV7S 7gRqHcirjRTd8tNERksNDUSb5i2KrWPUaSy74rzgQLCajVkxfgaLzeFE9YcwoMXCus6u NKBw== 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=i35l3v54rKQP1s5+Kb8InGfU4nAXdzHSPS6IqEVG9tQ=; b=Vjdz6Xw4MUCfLFVwUdKe+SqnDPfs4WzWfP9kcpIOtsHnG0GLBZceqDFNENR5muI/7s 44mU8aEsa24P8VqBLSKJ18ob9keeKf7lz9fXSCDpBGAqeBzQMorOlP7F2lPoGxTlPyM5 iOU3p5IspeI/4X/BSpMAW5W4HqaZR6X8Ciw+AHxFtlUMuULuc1swchQ/uN/p2FICWOx0 AUHjxWpSgNqndVKZNqpCGc6EP0ovsJk9IPRpPjxFaY9NEMX0wktbH8TABAlEqw2Jd/eX o/T6twkpgrlPPBW7H3MdIE5k8XGWmkYE9SQpv5fYMoYi38YMXRw7JFsXxJRcWFlJbNtc LJGQ== X-Gm-Message-State: APjAAAV7XH3yNNoqUEvG/MexjNx5rGTkx8God3hKNu9jC5fIbEBB5M5O 7I8TyEB1CEzIi2U2rCpfb2hInp4QViayN7YHuQwpmA== X-Google-Smtp-Source: APXvYqyvam21+t6AztShx282uf6wcWKXzp1Umo72alMTXD4+pHztz3XfY08UqTAOaXy3+i5hG46hB74olN6+Sx5SNWQ= X-Received: by 2002:a2e:3a14:: with SMTP id h20mr15505491lja.29.1571686202083; Mon, 21 Oct 2019 12:30:02 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> From: Eric Rescorla Date: Mon, 21 Oct 2019 12:29:25 -0700 Message-ID: To: Stephen Farrell Cc: Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c620d0059570b524" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 19:30:13 -0000 --000000000000c620d0059570b524 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 19:08, Eric Rescorla wrote: > > No. You want padding to be set to be the longest size that you would send > > to any origin in the anonymity group, and the server knows this. > > In the past, I've argued that this is not necessarily true > and hence the current padding scheme is not a good plan. > > Two main reasons: > > - a server may not have visibility of all names that can > be in certificate SANs > The question is not the server, but the operator. - even if a server does have such visibility at time t, a > CA re-issuing certs can change the situation during the > lifetime of one ESNIKeys value > > I believe it is not unknown for servers to have a DB > of TLS server certs/private keys that is queried based > on the SNI (which could've arrived as ESNI). I don't > know how common that is. > > My guess is that all of the above will lead to everyone > always using 260 for this value, making it pointless > and somewhat wasteful. > I don't agree that 260 is pointless, though perhaps wasteful. > I would argue for an algorithmic method of padding and > to not require servers to include any value in ESNIKeys at > all. I proposed one such algorithm on the list before. > Yes, but I do not believe that it obtained the consensus of the WG. Obviously, if the chairs call consensus on this point, we will change the draft. -Ekr > Cheers, > S. > > PS: I think 260 is the right max, didn't look it up just > now but I did some time ago and it seemed correct. > --000000000000c620d0059570b524 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 11:41 AM Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:

Hiya,

On 21/10/2019 19:08, Eric Rescorla wrote:
> No. You want padding to be set to be the longest size that you would s= end
> to any origin in the anonymity group, and the server knows this.

In the past, I've argued that this is not necessarily true
and hence the current padding scheme is not a good plan.

Two main reasons:

- a server may not have visibility of all names that can
be in certificate SANs

The question is = not the server, but the operator.


- even if a server does have such visibility at time t, a
CA re-issuing certs can change the situation during the
lifetime of one ESNIKeys value

I believe it is not unknown for servers to have a DB
of TLS server certs/private keys that is queried based
on the SNI (which could've arrived as ESNI). I don't
know how common that is.

My guess is that all of the above will lead to everyone
always using 260 for this value, making it pointless
and somewhat wasteful.

I don't agre= e that 260 is pointless, though perhaps wasteful.

=
=C2=A0

Cheers,
S.

PS: I think 260 is the right max, didn't look it up just
now but I did some time ago and it seemed correct.
--000000000000c620d0059570b524-- From nobody Mon Oct 21 12:48:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796C71208DA for ; Mon, 21 Oct 2019 12:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 TYyyFPyPoT8m for ; Mon, 21 Oct 2019 12:48:06 -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 3B9C21208C2 for ; Mon, 21 Oct 2019 12:48:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0930BBE4D; Mon, 21 Oct 2019 20:48:03 +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 wtCv97-2HuuU; Mon, 21 Oct 2019 20:48:01 +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 6D1B7BE4C; Mon, 21 Oct 2019 20:48:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571687281; bh=EFaXZBRHQ8lq187lJ77/Bdqz0wdVYXxM7WHB2KVAMdY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JCb2i13RKTzEvngF1niy6VxkIIm0JB53P/i5UVhWJwcmKH0hNOri3JR3Yj2GIlYOf oen6T9x48QfJz1mA780ZSg+qKyAz1GloyKCqUm+sDKrC1Cb+spLhVBcWvXalKJ8LIE 3ArZEu/o3lrs5ehZ6OxTJ/uiX3ssdfqe2Iu/BsK0= To: Eric Rescorla Cc: Rob Sayre , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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, 21 Oct 2019 20:48:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IPlAw7qYNGJV3i5YSLetvuhPmyEe7AWq0" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 19:48:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IPlAw7qYNGJV3i5YSLetvuhPmyEe7AWq0 Content-Type: multipart/mixed; boundary="3XtAiDSkkvOrkaLitaY00zEhnulyxcGIt"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: Rob Sayre , "TLS@ietf.org" Message-ID: Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: --3XtAiDSkkvOrkaLitaY00zEhnulyxcGIt Content-Type: multipart/mixed; boundary="------------7BC5A351CC515A56D17DF926" Content-Language: en-GB This is a multi-part message in MIME format. --------------7BC5A351CC515A56D17DF926 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/10/2019 20:29, Eric Rescorla wrote: > The question is not the server, but the operator. Sure, but the point holds though. If ESNIKeys are changed every N seconds, and any new certificate is loaded during that time, then the server operator can't tell the lengths that the CAs might produce in future. So with the current design 260-always is the only thing a server-operator (or really an ESNIKeys generator who may be a slightly different entity) can rely on in general. > Yes, but I do not believe that it obtained the consensus of the WG. Not yet, that's true. OTOH, the 260 value wasn't decided on the list either that I recall. However, I'm not objecting to the current design for process reasons at all, I'm only critical of it technically:-) > Obviously, if the chairs call consensus on this point, we will change t= he > draft. Sure. We'll see where it lands. I remain hopeful a better design will be the result. S. --------------7BC5A351CC515A56D17DF926 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----- --------------7BC5A351CC515A56D17DF926-- --3XtAiDSkkvOrkaLitaY00zEhnulyxcGIt-- --IPlAw7qYNGJV3i5YSLetvuhPmyEe7AWq0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2uC3AACgkQWrL68XsX K+oYEw//S/SYd6P1aSMxxlkFQjoH0O36+4isRKnxnGiye/w1fElBFrxCSnuRAKxQ xAyj+OnzjCo1gqsaF5NGwLKAebk3O/T+4cOhcAaYvnpssBlABe4iev+0Wv036qeV 5m9S/F9slEpsLt5JqFx/AdQlkKP3pFTM+dIcqCdaA9QuzHo0oorzal+kmyJvuADk TeLOpOH0RciGm06RHSm1jBZc9/RfZ5bkU1UpXnK/DIVjz6bRnNRvbfU8vMXyO2OF U1fAuzlOSE0fwU5544K+MTs/qhoWVHBav30c5aSG/hMLSwsweVDX05toG/mQlfZp /UkGLh4/ZSKvvU5W7Vj+9I0lO0Otjs53nH3ULtjApsyEfpuD7Ltsze5V8+QcP/Ft B/vCasgpDs1VwmWm3idk8Ljls7DQGo9m4wTw175guA5smZufW3BwWMPTPaVpfoKF 8SMxiz1mv2RxUc/gFNAD6uUPqm6XlgiwAYPoIv39Vge6j1S5uJVBroIWU0iv4Jjf pf+MVyt32mNPQWgdTIH8aQXthRuKO1xeRK1CxLwgteR1O/btTuq9vb/tWA66FeSy XQasMIN5gcTl5Z2tIa2zjfif9IoIQr4pFFAz3fjvDuD9q3nEnLGOOvff/blKLFal Pdr2AbTQepsHpuE0josp6tHppg/3ZuJStS4faJepG9h/lQzYdmI= =V3mV -----END PGP SIGNATURE----- --IPlAw7qYNGJV3i5YSLetvuhPmyEe7AWq0-- From nobody Mon Oct 21 13:03:09 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAC21208CF for ; Mon, 21 Oct 2019 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYrl4H4DcuJX for ; Mon, 21 Oct 2019 13:03:06 -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 93F741208C3 for ; Mon, 21 Oct 2019 13:03:05 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id z12so11120926lfj.9 for ; Mon, 21 Oct 2019 13:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wvgxx+ffIrgCnfYPNE5l430b4HBKpM/2Cx4I4jx6v6k=; b=I65QgtIvVak2BG5AwBuQ57ld7yh7IpKgK23COxkbQ1OkPmGNNYXQfVJdJJLj3oCXZw mPniUpi3loW9/9mxgzIyzz5LllzhzzYWYJO1l1JNhvAwqVBtnBUZd9AWBNqusYCNrmIN vQbSrJDWZYHvuXuvZE4PE6Z8IDGzcBdmT2C5OMIB2zfFYT9d42SDfYeQG49EFozeCnEX Vp0oJahtRAPQCNonCjeQNHV3zDhcuvrdlJebBmm3z3vxDhwNi4GQwAkOQ0hvOFs8B2pm DgMZUsUoCEwKnrxZUR1zcd1xAZchVD/0kGk1/M1B4Z6xiPpcCdlu5lr+rvHR2djfc6yI ifbQ== 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=Wvgxx+ffIrgCnfYPNE5l430b4HBKpM/2Cx4I4jx6v6k=; b=cir1O45+pFidvz+hdQrdmW/IepjnguAu6vVcm2O48GEcvLx+V01HJns/6KHILO95Gq bYLHIwcL9MvdObHbREdbuhNPlwOGLzg3tCFV2eJiwGdCkJ9EX3UgbCqr0djwQX1tkhMW EBrL7xT5Oot97rEqhhwTWZd33kRjf4PPu1L/0zazQE3x5jK6STsH3Y0VoxEpjlCP/pEv h7QXkRaKdoJeBBeW6xFmHo2lxon3LJUiO4z7B7Qm/HkCi5DMbF17IdAadBHhYjmLZ3Vt UA+moywVdRnC0zERBo+1OciqUCnhKu+SDIYmZzexDayKAK4QHA6pbK0to7wdfOPIpcjE AENw== X-Gm-Message-State: APjAAAV3yyes7wyC7xFUpX2/duyRlI1G94Uz8H/ZxZqKxEVU/n0VTUJT RemGWjZFwc+wYEwBmSgSTbXxpzK0xGvBNP5uD2Ww9g== X-Google-Smtp-Source: APXvYqzTEON7UWikBupiuR2dJ0CoBg5tC+pUL7AC8UKAcCWOr8OGfb0neovypL7LTolmiG2sUPZW5YGoih39u6D9DvQ= X-Received: by 2002:a19:c6d6:: with SMTP id w205mr14626626lff.17.1571688183764; Mon, 21 Oct 2019 13:03:03 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 13:02:27 -0700 Message-ID: To: Stephen Farrell Cc: Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e460f20595712ba5" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 20:03:08 -0000 --000000000000e460f20595712ba5 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 20:29, Eric Rescorla wrote: > > > The question is not the server, but the operator. > > Sure, but the point holds though. If ESNIKeys are changed every > N seconds, and any new certificate is loaded during that time, > then the server operator can't tell the lengths that the CAs > might produce in future. So with the current design 260-always is > the only thing a server-operator (or really an ESNIKeys generator > who may be a slightly different entity) can rely on in general. > I don't believe that this claim is correct in general. Remember that these records are stored in the DNS under the name that becomes the SNI, so, absent wildcards, ths eet of names is in fact known, regardless of what happens to be in the certificate. > Yes, but I do not believe that it obtained the consensus of the WG. > > Not yet, that's true. OTOH, the 260 value wasn't decided on > the list either that I recall. IIRC it was there at the time of adoption. -Ekr However, I'm not objecting to > the current design for process reasons at all, I'm only critical > of it technically:-) > > > Obviously, if the chairs call consensus on this point, we will change the > > draft. > > Sure. We'll see where it lands. I remain hopeful a better > design will be the result. > > S. > > --000000000000e460f20595712ba5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 12:48 PM Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:

Hiya,

On 21/10/2019 20:29, Eric Rescorla wrote:

> The question is not the server, but the operator.

Sure, but the point holds though. If ESNIKeys are changed every
N seconds, and any new certificate is loaded during that time,
then the server operator can't tell the lengths that the CAs
might produce in future. So with the current design 260-always is
the only thing a server-operator (or really an ESNIKeys generator
who may be a slightly different entity) can rely on in general.

I don't believe that this claim is correct in = general. Remember that these records are stored in the DNS under the name t= hat becomes the SNI, so, absent wildcards, ths eet of names is in fact know= n, regardless of what happens to be in the certificate.


> Yes, but I do not believe that it obtained the consensus of the WG.
Not yet, that's true. OTOH, the 260 value wasn't decided on
the list either that I recall.

IIRC it was= there at the time of adoption.

-Ekr
However, I'm n= ot objecting to
the current design for process reasons at all, I'm only critical
of it technically:-)

> Obviously, if the chairs call consensus on this point, we will change = the
> draft.

Sure. We'll see where it lands. I remain hopeful a better
design will be the result.

S.

--000000000000e460f20595712ba5-- From nobody Mon Oct 21 13:07:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9401120976 for ; Mon, 21 Oct 2019 13:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SGk55lt9HjRI for ; Mon, 21 Oct 2019 13:07:30 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4632D120971 for ; Mon, 21 Oct 2019 13:07:30 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z19so17575687ior.0 for ; Mon, 21 Oct 2019 13:07:30 -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=Qkc73E9VBzesk2i9RNKV6tywLzbZIKWQ5jivt13fclk=; b=TDocGASqqi2cCkqOTWkRzyzTu8Q6NE9q9gohN698sWMpOYNVbAEIjr9TZQ+uDUaVx9 kcVyf0XwIQaO3KUI1VZ0E4+wP6JcjdFp0f5OYWpbTe/6Zy/560A7+alLMtr4wuPSpLOS P65Z8pSm6wFIzu25ZvbR+dGmk487fvF6PN4W3/V3T8M4PYf7a1tR/blQotbebW+59Lhi eXyYN8NFPharY4Cz8ctKMrQpuLQ5w1AdWkXvQNPni4urmF8xqsbP0yNMoCT0ectRy9Ml xliUGOFKg/+Cpm+igG57MQEA5Ybu7G8XWgbiXEN4LVzSGKbPJiLsacmUvLASMCn25mXQ PLkA== 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=Qkc73E9VBzesk2i9RNKV6tywLzbZIKWQ5jivt13fclk=; b=ciPoekwjsTK0cNYA/h5lpujluyGx5qOW3Vb+j/I17G+EAiDS3hXYfusXItCDaCNIP6 9uBj0i4FQPdliwd3Xem/1Kej74HeVLEknBNFRm1orkXE+A0JcXodo25vSJU8m67XFM9j U51Ip4zJvD7ylj/TXy8nBVnaKn69NT6ICFa3TjgXvB+aV1IuzwSIWiP1NUzB9V1Se96u H1Cl1vZGVH9VNX7Q4RCYDlzVG6PikUOF3NDdpz7xd4vrjoffsPvmbyxJX7wmSQ3/+gcK hLQZ45NbSehG9NYSwHOMHwADGc5Y7v7w/QW6sWrVhrawwCnq13LK96dJvBOjuxUydLQq tQ2g== X-Gm-Message-State: APjAAAWeYyFdPhHyHNC0aS/pig8shhz43fCjNI8IRkXhu45567tSY8zH brlwvvwW+CRULOD//O7bmv2yNDDRQI0dalZxro94Dh+PWlo= X-Google-Smtp-Source: APXvYqxYQ1/pOiDIg4A6jeNnSqVlC3BkgoLOSTcEGxIQeKyealWLXWMWE26PJtmfsNcQtFtahmXLJZNC1vnA1wUuu6I= X-Received: by 2002:a02:9a15:: with SMTP id b21mr51403jal.103.1571688449293; Mon, 21 Oct 2019 13:07:29 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 13:07:18 -0700 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b7c3da0595713b27" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 20:07:32 -0000 --000000000000b7c3da0595713b27 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote: > On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> >> Not yet, that's true. OTOH, the 260 value wasn't decided on >> the list either that I recall. > > > IIRC it was there at the time of adoption. > Yes, it's there in https://tools.ietf.org/html/draft-rescorla-tls-esni-00. I think we should do better than "pretty sure it's right", though. thanks, Rob --000000000000b7c3da0595713b27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 1:03 PM Eric Resc= orla <ekr@rtfm.com> wrote:
On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell <stephen.farrell@cs.tcd= .ie> wrote:


Not yet, that's true. OTOH, the 260 value wasn't decided on
the list either that I recall.

IIRC it was= there at the time of adoption.


I think we should do better than "= ;pretty sure it's right", though.

thanks,=
Rob=C2=A0
--000000000000b7c3da0595713b27-- From nobody Mon Oct 21 13:09:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4D12099D for ; Mon, 21 Oct 2019 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qhc6X0tAv_G for ; Mon, 21 Oct 2019 13:09:17 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36B5120976 for ; Mon, 21 Oct 2019 13:09:16 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id l21so14728205lje.4 for ; Mon, 21 Oct 2019 13:09:16 -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=S5gpoAQOqBC+x5K+D6yzbWiassMd+7LC5H04YGdZ8Xg=; b=V00Uru0n5kqEs2IAyWqu24muRaKsPkIcFMJftSzL86yn6XCY1PVZhtNOqsJHZJdQxm PRoKabqhdr+/QNy6qo1TtN1RKJQCWv1PtTRe+0TKutIYWkX3RAqQtL/dgTAf6j1uCULc y4Xy0wTwKkXCwsZSlK8L4dUtlUrKuGPaYS7v8q6kGtgOt9KKPMglZ97DQDC5r9hyifi3 cehExfzVlUVvy5xFAFutv/lpvM8dADg83TtMsn5/eHiamCmjRgQeI/LDS+WMAbLiHddz 3OrX2vHLPBL89AF588B7FnC0lke3CazIqwprujkylBml5Q240YeOLjRXpD9ugXR+e03g CHMg== 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=S5gpoAQOqBC+x5K+D6yzbWiassMd+7LC5H04YGdZ8Xg=; b=jJqtSQL65s6x0YVg8cnYCmQL2nYuW5qLdKLg6biHV6qeQZ8xb4gRXWrX4YUJz1b+Bc 0Bbt10dH8jBAQfXRNkTehSiOI2c412vOjtpWcp9za1T5XdYByJghrq0iTEeWr064bc3e xkpQ0p3kCgcq48zyoKhjymIAuuQpeNBy+xh2xdTHUwCWkUS5IEtPk4otFafexyhXzQ0w Vh34bCRywXmdL4G/u+KmmCrx4lQUpVcANxDyvVYFC6hSWlQOSZVICDoS9mGXBR5CGdNB 5kd6mAFXdEvnyILCbAQzrk/kBZm5GqYfXYcj1YiFXOf/rVo70XuO78ARZHsTaK2bMJ1F QOrg== X-Gm-Message-State: APjAAAUF6en2jsb+fsJOuG/Y8KekyxyQsZxtWX2smQSEPWPOfEr+2Exp z+T9PfNOxSivAIK7kvno7Do6AEWj/yeDnYknKg8NKA== X-Google-Smtp-Source: APXvYqyz4PjWIeAWPrCufWuZHoIaBak02Cs+Ihe8IzT8gOfOSamFQnvnt/ShdD7uS4eKtLn7yTcno8NlkGtUh6sdFfg= X-Received: by 2002:a05:651c:237:: with SMTP id z23mr16310049ljn.93.1571688554957; Mon, 21 Oct 2019 13:09:14 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 13:08:38 -0700 Message-ID: To: Rob Sayre Cc: Stephen Farrell , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000425a305957142fe" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 20:09:19 -0000 --0000000000000425a305957142fe Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 1:07 PM Rob Sayre wrote: > On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote: > >> On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell < >> stephen.farrell@cs.tcd.ie> wrote: >> >>> >>> >>> Not yet, that's true. OTOH, the 260 value wasn't decided on >>> the list either that I recall. >> >> >> IIRC it was there at the time of adoption. >> > > Yes, it's there in https://tools.ietf.org/html/draft-rescorla-tls-esni-00. > > I think we should do better than "pretty sure it's right", though. > I don't believe that's what I said. -Ekr > thanks, > Rob > --0000000000000425a305957142fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 1:07 PM Rob S= ayre <sayrer@gmail.com> wrote= :
On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:


Not yet, that's true. OTOH, the 260 value wasn't decided on
the list either that I recall.

IIRC it was= there at the time of adoption.


I think we should do= better than "pretty sure it's right", though.

I don't believe that's what I s= aid.

-Ekr


thanks,
Rob=C2=A0
--0000000000000425a305957142fe-- From nobody Mon Oct 21 13:13:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE822120927 for ; Mon, 21 Oct 2019 13:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 c95Orrq4y58y for ; Mon, 21 Oct 2019 13:13:08 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 0406612090B for ; Mon, 21 Oct 2019 13:13:08 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id o16so5171437ilq.9 for ; Mon, 21 Oct 2019 13:13:07 -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=WDTjvn8TrvQvPFjMWxJXUEWyUMxjX74E9g3jWbfksEg=; b=f5Da1P2OaMjKDzX5Qyjn/8Ny9cjI3sS7cj+X0e+t+8OffBz1Fyc/DCJTYfQ8mFMkAB eMLcLZ+F0mTdXRIDBSsfkNMmcgUqrjL//f4+Olw1XH4Yx/j7sMkuTcbZEIlRnioWt33v RvAuqS3fX5MEtdtWqgDhlbG+ouegiuEcwZEOcZ5S+MqfuyUIo2STZdR9W6a5057fq9LB yk2l7QfX2i17UUsbLDSQlFeYr/CwaqVzYm/UrM9KfiPHtApO1bbr6HBOIQ108bTOKuBk AR6YDxUhu7BwZW2KTWXjBIFXiUSrK9rEsNgQQBvSz5o+opY+1QNurfr13/WMn2388QZI galg== 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=WDTjvn8TrvQvPFjMWxJXUEWyUMxjX74E9g3jWbfksEg=; b=FvDVF52AHHKRunP58yN8U0Com4tuvPXN/wma0YMOwZ5Kmrts/eZwdiEet8ha9YXRlo hTVIrby3fj3ZgSAez+5swpIm/OaT9Fss/TBbo6sNy1B2sPsU2n3qmCw8/cTIcGp/jd0n CCW8R7QXYfTXJMED/YAlJ4XlhhSo7EmYh3k9JB3v83NQd4i4sj6ufPsQW0fwjc6og9AL V+aA+fJQu8G6y8KiNd6101c0ygriR8ItY9zQ03S8JHV0TClSuJVPXDoaYq5/Y7tJq9qZ bo2CzfZ0eW0+h4Y1E83rOMzMvhk6UWQ6vz6RPXP7agkvKMp7QRd1n776wE8X+HKgW89E KjGA== X-Gm-Message-State: APjAAAVg31AEcUHnKlAs1Uv0k+QppeGnWvTmueK7OnSfj+By//qEmQMd NrHXYyVIjwoWS3guYruhLkxXzn4mQc3kIjTWdmtErTWUC4w= X-Google-Smtp-Source: APXvYqzUn29Mu6AGtoiGuZF+lAY8gCrL2ikCNK7hSLkwiI2qZS5WXwsnZsyizjUHSfLaEZ+gK2mBk7byMZKRrDS1aIU= X-Received: by 2002:a92:db0c:: with SMTP id b12mr4477506iln.49.1571688787091; Mon, 21 Oct 2019 13:13:07 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 13:12:55 -0700 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000da2ae20595714fa3" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 20:13:10 -0000 --000000000000da2ae20595714fa3 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 1:09 PM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 1:07 PM Rob Sayre wrote: > >> On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote: >> >>> On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell < >>> stephen.farrell@cs.tcd.ie> wrote: >>> >>>> >>>> >>>> Not yet, that's true. OTOH, the 260 value wasn't decided on >>>> the list either that I recall. >>> >>> >>> IIRC it was there at the time of adoption. >>> >> >> Yes, it's there in https://tools.ietf.org/html/draft-rescorla-tls-esni-00 >> . >> >> I think we should do better than "pretty sure it's right", though. >> > > I don't believe that's what I said. > It is not. You said to look up the reasons for the requirements in the draft in the mailing list archives and GH issues. Stephen wrote: "PS: I think 260 is the right max, didn't look it up just now but I did some time ago and it seemed correct." thanks, Rob --000000000000da2ae20595714fa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 1:09 PM Eric = Rescorla <ekr@rtfm.com> wrote:
<= div dir=3D"ltr">

On Mon, Oct 21, 2019 at 1:07 PM Rob Sayre <sayrer@gmail.com> wro= te:
On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla <ekr@rtfm.com> wrote:<= br>
On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell <stephen.farrell@= cs.tcd.ie> wrote:


Not yet, that's true. OTOH, the 260 value wasn't decided on
the list either that I recall.

IIRC it was= there at the time of adoption.


I think we should do= better than "pretty sure it's right", though.

I don't believe that's what I s= aid.

It is not. You said = to look up the reasons for the requirements in the draft in the mailing lis= t archives and GH issues.

Stephen wrote:

"PS: I think 260 is the right max, didn't look it = up just
now but I did some time ago and it seemed correct."
=

thanks,
Rob
--000000000000da2ae20595714fa3-- From nobody Mon Oct 21 13:46:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4317E120A65 for ; Mon, 21 Oct 2019 13:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 hnqH3w4qlzOu for ; Mon, 21 Oct 2019 13:46:20 -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 7A9081209C9 for ; Mon, 21 Oct 2019 13:46:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A1145BE4C; Mon, 21 Oct 2019 21:46:17 +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 DA42XfMf6Mon; Mon, 21 Oct 2019 21:46:16 +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 051EABE39; Mon, 21 Oct 2019 21:46:16 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571690776; bh=bm4S7QtdnjidcDk5kw/ncTZgtiX+bFxAOCSaO/tXu3M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qZ1SJBmI3GnYTSAoqWXa12iFrMf0tlkdA+R3U3QRcixefjHvukOwPFhPFkQ0VX9EN 4QtZroY9IZQ/nafkPkfIOkg7HHKS9w8diJ5gBiI+H93YBagwTDpecjPcTuSvgQM9Lh fOapkUxXhQI/lGKhAhCMryLivKzQGl1eBY2ckz1g= To: Eric Rescorla Cc: Rob Sayre , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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, 21 Oct 2019 21:46:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EQorT9tmOa6dYMubHT9uKdW7qfIP1bOup" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 20:46:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EQorT9tmOa6dYMubHT9uKdW7qfIP1bOup Content-Type: multipart/mixed; boundary="lvIPV6D0RsS7Jt8x90syTZEaoJXOugJeb"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: Rob Sayre , "TLS@ietf.org" Message-ID: Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: --lvIPV6D0RsS7Jt8x90syTZEaoJXOugJeb Content-Type: multipart/mixed; boundary="------------E75D36649729F268DDFEB2A7" Content-Language: en-GB This is a multi-part message in MIME format. --------------E75D36649729F268DDFEB2A7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/10/2019 21:02, Eric Rescorla wrote: >> Sure, but the point holds though. If ESNIKeys are changed every >> N seconds, and any new certificate is loaded during that time, >> then the server operator can't tell the lengths that the CAs >> might produce in future. So with the current design 260-always is >> the only thing a server-operator (or really an ESNIKeys generator >> who may be a slightly different entity) can rely on in general. >> > I don't believe that this claim is correct in general. Remember that th= ese > records are stored in the DNS under the name that becomes the SNI, so, > absent wildcards, ths eet of names is in fact known, regardless of what= > happens to be in the certificate. Depends which "in general" is more general I guess. Wildcards do exist in the DNS, though TBH I'm not really familiar with how they're implemented in authoritatives. But even ignoring those, deployment models where the ESNIKeys are generated by the TLS server operator, but DNS records are published by a different entity (say the owner of the name or registrar) ought not be precluded I think. Supporting such a model I think more or less requires setting padding_length to 260 or else risking a failure nobody will notice (if browsers fall back to cleartext SNI) or know how to diagnose if they do. And even in the case of a monolithic service that does it all for every name, I think it'd still likely pick 260 in order to avoid having to exercise/write the code to detect and react to a need to increase the padding_length. ("Holy crap - you mean I need to re-publish everyone's ESNIKeys just because this bozo has a really long name? Who made that up?") I really can't see what'd motivate anyone to publish ESNIKeys with a padding_length < 260 tbh (well, other than not having thought it through;-). Anything <260 just seems to be asking for later problems. S. --------------E75D36649729F268DDFEB2A7 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----- --------------E75D36649729F268DDFEB2A7-- --lvIPV6D0RsS7Jt8x90syTZEaoJXOugJeb-- --EQorT9tmOa6dYMubHT9uKdW7qfIP1bOup Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2uGRIACgkQWrL68XsX K+poGRAArxPDZs04SJ0otschz0GlKYCTvYNjgPAU5vqAMUJotxjkj6js+GXNi3xa rW3NoJwzBaNNeUphyuCdd15+K+e1uD0oJx1wn5VoD0M5AzCaC+n1y0+PgnZGnXwF 34W+BOdVN8IgCxjbPqqWJYY0xQpwtXCQort7zIhCN14KwltCeSha5kcoOzqPz/8G NHKGR+Ww1mqtAAoKSwO+IyBdNJs2oGIgRxj4qH/7L3+BMOMg4Ir79RM/b9ULchBc QY/4jVvRlfM0iBPOKvj6h9/R/PPRH3sZM/iyGdbbCilw8AE9TZuBbwqa7HMu37Zq 05+8I2XnVTl2lSTZ0KGJma2S/dlOCXZp+VkjzJsWOLDSDoHTexoPKpKmuK04UVeA Ql64cEhGtu06jhLDlav9geN67hQ5o52f06rUmdhuqeDllpYUR2/IFZYKomfBSJ9i RZ3sxckJ1C1DNxt9B5hwpwli7PS/zLaiHL8/tvcb/HFExAKBmnWc9SXzD6QgF6Bl wU0XOJ6zhgSsKAj7a0487a8WkP6fgc4ieK+MXvQKmH+6t9SIkWaYAy96PfH2LJ+I r8gEBBEAN7xOPFxSmpmmsOkFgmiJhECKQL2YzXeWS494uxzuj1jqBHYsn0/q+OeO mcedPIsHCxlpl6JCPpPnkK86F5Tfi/PJ+htRonCQGwDAyyM7pYs= =Z6z/ -----END PGP SIGNATURE----- --EQorT9tmOa6dYMubHT9uKdW7qfIP1bOup-- From nobody Mon Oct 21 13:56:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E68912090B for ; Mon, 21 Oct 2019 13:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWw-WiLGdetr for ; Mon, 21 Oct 2019 13:56:18 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8332512001A for ; Mon, 21 Oct 2019 13:56:18 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id 195so11235999lfj.6 for ; Mon, 21 Oct 2019 13:56: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=B4/cg+mfbnsuUYaj15Yvao2b/WYm8txvOTazZVprAXw=; b=B0CeqvPzSd4O0UjztxQhlcnG/5e5UMvMs/Fjcky8CnDyaHLd7roZszT4SpKZ5+mBeV 8eusoWFXESP6WXb3LTYs3APqHDVptqJ+ab5cCbLa5QVh4PyYGsqAU1wGbM4Y0yJpaOgq qBs57AEbiVnw1n/aKPg3hVz7WtMEFVWGGDr5UQ6CVTGaQx5WWrFthnSNIX5iJlMTSdhZ HErcsNqHbKgBSwIgRkv9TY3TBhWpspc1rmtXoexac1S2xR9Nn2ofaEUgfx7hcyO4dAaQ R/44kxY4+kI/ItUKUZC6TEVS25mMyJOIz+yYYhbguxOK7i2rPnOIYLPbEEcocpFMsMna Hoyw== 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=B4/cg+mfbnsuUYaj15Yvao2b/WYm8txvOTazZVprAXw=; b=M4YCGdR3DoZKA4rtrzhWRWEeWM04RFfDVP49Pcn28YnXUn5W8YH35PGwsYQPt3nLul EspErqnb0QfDbUbehJX4L1znfjUzILbM96LJ2BKnGFqvMbJOXbkyNItjmauD6fw0zv6s e7mIYRVqE6+BoXuYA4zPeIHw0OU6WwcGH+xfQNk32nEt0aK8MpLjqSyQN+3wz7OyU+y7 n/LdfeZMENLKEI3FVJPvYo/wR+Se20Rm6Xq6w/lsD8sC6KqDWYoOoCeXsqlZsmU2F6Go u0/C5a72I+FBlcf26ww99hoAQEZfmDno0Tos7w2e6R+hlIRZvG5MJp6qMqvcJzcvt9rf FLPQ== X-Gm-Message-State: APjAAAU86H89+vV5ps6X1atcs4w2Rf2El3iNdDwowUbsxJ1CFiIlMAyu xaI63vwA+Dy5NvulK1HiLe87+nHf5lMLEj5KupriHA== X-Google-Smtp-Source: APXvYqzeRbozvpVPryaYt28pz0oO4kSs0Vrq+gnOsi6nwQdQiM00gy8LAp59xe1XFiXA0gZ1QdY22qADXMdH+DEl5Hc= X-Received: by 2002:a19:8196:: with SMTP id c144mr5183114lfd.129.1571691376591; Mon, 21 Oct 2019 13:56:16 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Mon, 21 Oct 2019 13:55:40 -0700 Message-ID: To: Stephen Farrell Cc: Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000032d9a6059571ea00" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 20:56:21 -0000 --00000000000032d9a6059571ea00 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 21:02, Eric Rescorla wrote: > >> Sure, but the point holds though. If ESNIKeys are changed every > >> N seconds, and any new certificate is loaded during that time, > >> then the server operator can't tell the lengths that the CAs > >> might produce in future. So with the current design 260-always is > >> the only thing a server-operator (or really an ESNIKeys generator > >> who may be a slightly different entity) can rely on in general. > >> > > I don't believe that this claim is correct in general. Remember that > these > > records are stored in the DNS under the name that becomes the SNI, so, > > absent wildcards, ths eet of names is in fact known, regardless of what > > happens to be in the certificate. > > Depends which "in general" is more general I guess. > > Wildcards do exist in the DNS, though TBH I'm not really > familiar with how they're implemented in authoritatives. > > But even ignoring those, deployment models where the > ESNIKeys are generated by the TLS server operator, but > DNS records are published by a different entity (say the > owner of the name or registrar) ought not be precluded > I think. Supporting such a model I think more or less > requires setting padding_length to 260 or else risking > a failure nobody will notice (if browsers fall back to > cleartext SNI) or know how to diagnose if they do. > > And even in the case of a monolithic service that does it > all for every name, I think it'd still likely pick 260 > in order to avoid having to exercise/write the code to > detect and react to a need to increase the padding_length. > Fortunately, we have a number of such operators on this list. Alessandro? McManus? Nygren, What say you? -Ekr ("Holy crap - you mean I need to re-publish everyone's > ESNIKeys just because this bozo has a really long name? > Who made that up?") > > I really can't see what'd motivate anyone to publish > ESNIKeys with a padding_length < 260 tbh (well, other > than not having thought it through;-). Anything <260 > just seems to be asking for later problems. > > S. > > > --00000000000032d9a6059571ea00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 1:46 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 21/10/2019 21:02, Eric Rescorla wrote:
>> Sure, but the point holds though. If ESNIKeys are changed every >> N seconds, and any new certificate is loaded during that time,
>> then the server operator can't tell the lengths that the CAs >> might produce in future. So with the current design 260-always is<= br> >> the only thing a server-operator (or really an ESNIKeys generator<= br> >> who may be a slightly different entity) can rely on in general. >>
> I don't believe that this claim is correct in general. Remember th= at these
> records are stored in the DNS under the name that becomes the SNI, so,=
> absent wildcards, ths eet of names is in fact known, regardless of wha= t
> happens to be in the certificate.

Depends which "in general" is more general I guess.

Wildcards do exist in the DNS, though TBH I'm not really
familiar with how they're implemented in authoritatives.

But even ignoring those, deployment models where the
ESNIKeys are generated by the TLS server operator, but
DNS records are published by a different entity (say the
owner of the name or registrar) ought not be precluded
I think. Supporting such a model I think more or less
requires setting padding_length to 260 or else risking
a failure nobody will notice (if browsers fall back to
cleartext SNI) or know how to diagnose if they do.

And even in the case of a monolithic service that does it
all for every name, I think it'd still likely pick 260
in order to avoid having to exercise/write the code to
detect and react to a need to increase the padding_length.
=

Fortunately, we have a number of such operators on this= list. Alessandro? McManus? Nygren, What say you?

= -Ekr



("Holy crap - you mean I need to re-publish everyone's
ESNIKeys just because this bozo has a really long name?
Who made that up?")

I really can't see what'd motivate anyone to publish
ESNIKeys with a padding_length < 260 tbh (well, other
than not having thought it through;-). Anything <260
just seems to be asking for later problems.

S.


--00000000000032d9a6059571ea00-- From nobody Mon Oct 21 15:34:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED622120A68 for ; Mon, 21 Oct 2019 15:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=FwzaOIAT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=anaNnaMy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIb7dlIXUCql for ; Mon, 21 Oct 2019 15:34:18 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA7C120018 for ; Mon, 21 Oct 2019 15:34:18 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 48C2C6CA; Mon, 21 Oct 2019 18:34:17 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 21 Oct 2019 18:34:17 -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=fm3; bh=iSDpurON5HflBYsYQty6AfHvehMh rCR1OunSgqOKxF8=; b=FwzaOIATcyGgU3a3TM0kdO2iLKp/DDlOPCQau6T6BYE7 F96d/iKtz0da6BDK1tgXsC53kDZUCGOCDn3S8DG8c34avEh23eoXnM7Glf3LykWt htPvrK3mOlF2LMGcH/NVCAciPMPl6BzGnECk/Zf3zETQ7IDskD5qAqSEn9P7aTbG GM2X9rhNjfGJA0hNyHuYUyms4HnzOcBGaWd3LhU+RVOJVbdGrTgi0haV+niwRTcT GjT3KD+JxTHhGEJk4W66340pmbO7K/v+IYHYm2LVgwXyMG1q99T6Gfyx1r3taCaS XgZA6HZJ2HWl+PkppK8Oufw9aspprevH/JfcM1nc0Q== 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=fm1; bh=iSDpur ON5HflBYsYQty6AfHvehMhrCR1OunSgqOKxF8=; b=anaNnaMysfSnzkjdCIHY+v lhSFuRXdqoAPHmZ40kLoZ+88Zd80ql0+7/byQrzMSJ/6TI5oWLoMrc3vkYYSfTyF uFy58gPYN2GUCSJOaSAMZtBZWtV1rx7fKBSorEkUihTezFIQIR9BHRwM/PXACiJN axwC9m6NwkrNDrWW/Wf/6CMb1cnKnpSe/qBcqb/sbAyd28/TDk7I+PAq7D2E8f4U kN2GOC9g09pty2voIbu3BfgWcFCOMiHp5RfU21UtXDBCA9CmLoGnKdY33r+6X3He IqQuKSVSt76Qur110xcLzss3bq/ojuh8PD4zJgOC58Nd8XPmyyu/8l92/QJI7qnA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeeigdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucfrrg hrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhu shhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 67965E00A5; Mon, 21 Oct 2019 18:34:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: <975f9484-7206-469d-a57a-7b8dc67bd53e@www.fastmail.com> In-Reply-To: References: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> <7d15a1f1-c646-43b7-b5d6-c89ea4b4b615@www.fastmail.com> Date: Tue, 22 Oct 2019 09:33:56 +1100 From: "Martin Thomson" To: "Watson Ladd" Cc: "Nick Sullivan" , "TLS List" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 22:34:20 -0000 On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote: > In TLS 1.3 it seems to have been assumed this wouldn't happen and we > could split signature algorithms from signature algorithms cert. > > If that's not actually the case it affects more than just DCs. DCs are > a good way to restore extensibility if there is a problem here, > provided we can come up with a solution. Yeah, I think that this is the clincher. FWIW, in Firefox we have a separation between TLS and the certificate validation logic. The latter cares about the SPKI of all certificates in the certification path because it applies policy related to choice of keys. As a result, that code cares about DC also. So we don't really get to advertise an algorithm until it is supported in both places. For that reason signature_algorithms_cert, as much as it is intended to address this sort of split, doesn't really help us. Logically, there is a split between the certification path construction and the policy pieces, and the structure of the code recognizes this, but in practice they are somewhat coupled. From nobody Mon Oct 21 16:59:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5774120A7A for ; Mon, 21 Oct 2019 16:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=p1lNislE; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=o128HcHS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkTX0wwFRzTX for ; Mon, 21 Oct 2019 16:58:57 -0700 (PDT) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 A44AD120A79 for ; Mon, 21 Oct 2019 16:58:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1571702337; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=qlawPSB75ZySZkWhcG55KylXFhYCzPV4v2weuFhsY6B/UNYfcirWWWfZ0We7VzBqVm7XnjHDpZPE2 R0WJXEG1TaUt1HJWYrPAZSFAZxI1ot5dP6+0DT/1MstsGSKUrOjXXo2lpouAbcN/2CXpt0C6R2RrWV o/KgAp8JFTeU0YZIpiW0jR8jdxucG+Jp2H7O+GDk9UT3kAHIDdorvYaEQjMmfSoBtKmegr05JNl30W n08695Bz8TrnJZRMM1VsEz8iH3ZKuv3QOek7yervRV4OLM0lx+urYQJE3Wxohl6NsTAEOMRQQxHKTq LZMdvaxn2nmq7gecGl+52Vy7775UfOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=2Tyk91onQCGOcNcCeOO0v9M00wOYhRNlQZ8oosuwTWk=; b=gnDyATmcrXhja58vxor0tvUqWDc6S8CJQ5DzXFOTRdze+R+Ig7FfkTZcypONf+s3uEEdhxfthlQcL V/+QvPlsnQSD0UfzOydal3sbxvw+nRNOT2W8QLZuZ3llQG1Et+8h/J8a66GkHAkErxJEpFVp38sexx N6Ss7JGL6klWIef9EbgGsAJTdsttv5Lf2xhdMtBxvZwwHu0JjKR8o0y5R+v+DLyZWS469Fd3BVFYvJ UycE1jM+0kX+OJRzY+pLgwFOL5yK3HOVnKtRKzg87NUEgRQUTevpzAM53ll6cA6vXxREXlBFchYuM+ BoXH0JoADyOR6+XvvuMGBeCypc6ctAg== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.50; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=2Tyk91onQCGOcNcCeOO0v9M00wOYhRNlQZ8oosuwTWk=; b=p1lNislEyuUrvoOdvP8NoUPI4Q6S5F9sfRfaOGoe4oNi77ggIN+kFWPrQZk1QZNP+M5520r2UwgPl Xgb5QiQcdtPUP9FBi1JJo3/k/4O4OK4RouubDMFvVdlPhoVaRt+LDl0bAVX4YA99MWCuzXewBp1vSA nB8SaPTFSy9Ki6i0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=2Tyk91onQCGOcNcCeOO0v9M00wOYhRNlQZ8oosuwTWk=; b=o128HcHSfyrFtnCWDhUtARiCLokccge/ki9wTBWTLkA9zF3967HWTjsOB+uUhxH/Ry9S2QGPTMqCA r30WltSmnKyKWK6VFTpqW7DY+smK83W3OcjEWcK7OBPdoccuXJNpgfTwoYHkm3KeTHeHA0c3oovzUt eIJU7u3WfHEA47kHWXPaeNaF4wRvkruJcKsteUk+Uzs4GEPLB7DPyyGKeDEuApKeeKE+cfA8/kR1Jk Q9AEUiHgDzCntqgnS36kYVp7ANN3Ex+2oAT4l92Fr8Kzn2bHCWloqYbAKnJOE6QuTDNsMZ4HF9N6Fe 33LHDyTQcJiQhxP9x4CY4RJjqusYJ4w== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: bd103ce7-f45e-11e9-9560-dfabc1efb494 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.50 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f50.google.com (unknown [209.85.210.50]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id bd103ce7-f45e-11e9-9560-dfabc1efb494; Mon, 21 Oct 2019 23:58:55 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id c7so1843689otm.3 for ; Mon, 21 Oct 2019 16:58:55 -0700 (PDT) X-Gm-Message-State: APjAAAVd4hkAiZ7iJI+P2paoeXodk6Pet3Vg49Me6Xc85It1F9KRWqUQ SMQwFdME6km8pto5+wBXbjOc98KP1CSsnFIu+FQ= X-Google-Smtp-Source: APXvYqxGxI5tya9RYSzcigElBIjchx7tiRJRUF9OWy9Ok4cQYzcQscBtHZGx2RUO2KajkG81sZVcqJX/SBYnZ8WtFPI= X-Received: by 2002:a05:6830:1e03:: with SMTP id s3mr386087otr.289.1571702334519; Mon, 21 Oct 2019 16:58:54 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Patrick McManus Date: Mon, 21 Oct 2019 19:58:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Stephen Farrell , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000057826f05957477bf" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 21 Oct 2019 23:59:01 -0000 --00000000000057826f05957477bf Content-Type: text/plain; charset="UTF-8" wildcards are real in both dns and http services.. (also the dns entries might be invisible to the http provider thanks to cname indirections.. though obviously service names are not.) On Mon, Oct 21, 2019 at 4:56 PM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell > wrote: > >> >> Hiya, >> >> On 21/10/2019 21:02, Eric Rescorla wrote: >> >> Sure, but the point holds though. If ESNIKeys are changed every >> >> N seconds, and any new certificate is loaded during that time, >> >> then the server operator can't tell the lengths that the CAs >> >> might produce in future. So with the current design 260-always is >> >> the only thing a server-operator (or really an ESNIKeys generator >> >> who may be a slightly different entity) can rely on in general. >> >> >> > I don't believe that this claim is correct in general. Remember that >> these >> > records are stored in the DNS under the name that becomes the SNI, so, >> > absent wildcards, ths eet of names is in fact known, regardless of what >> > happens to be in the certificate. >> >> Depends which "in general" is more general I guess. >> >> Wildcards do exist in the DNS, though TBH I'm not really >> familiar with how they're implemented in authoritatives. >> >> But even ignoring those, deployment models where the >> ESNIKeys are generated by the TLS server operator, but >> DNS records are published by a different entity (say the >> owner of the name or registrar) ought not be precluded >> I think. Supporting such a model I think more or less >> requires setting padding_length to 260 or else risking >> a failure nobody will notice (if browsers fall back to >> cleartext SNI) or know how to diagnose if they do. >> >> And even in the case of a monolithic service that does it >> all for every name, I think it'd still likely pick 260 >> in order to avoid having to exercise/write the code to >> detect and react to a need to increase the padding_length. >> > > Fortunately, we have a number of such operators on this list. Alessandro? > McManus? Nygren, What say you? > > -Ekr > > > > ("Holy crap - you mean I need to re-publish everyone's >> ESNIKeys just because this bozo has a really long name? >> Who made that up?") >> >> I really can't see what'd motivate anyone to publish >> ESNIKeys with a padding_length < 260 tbh (well, other >> than not having thought it through;-). Anything <260 >> just seems to be asking for later problems. >> >> S. >> >> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000057826f05957477bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
wildcards are real in both dns and http services.. (also t= he dns entries might be invisible to the http provider thanks to cname indi= rections.. though obviously service names are not.)

On Mon, Oct 21, 2019 at = 4:56 PM Eric Rescorla <ekr@rtfm.com&= gt; wrote:


On Mon, Oct 21, 2019 at 1:46 PM Stephen Fa= rrell <st= ephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 21/10/2019 21:02, Eric Rescorla wrote:
>> Sure, but the point holds though. If ESNIKeys are changed every >> N seconds, and any new certificate is loaded during that time,
>> then the server operator can't tell the lengths that the CAs >> might produce in future. So with the current design 260-always is<= br> >> the only thing a server-operator (or really an ESNIKeys generator<= br> >> who may be a slightly different entity) can rely on in general. >>
> I don't believe that this claim is correct in general. Remember th= at these
> records are stored in the DNS under the name that becomes the SNI, so,=
> absent wildcards, ths eet of names is in fact known, regardless of wha= t
> happens to be in the certificate.

Depends which "in general" is more general I guess.

Wildcards do exist in the DNS, though TBH I'm not really
familiar with how they're implemented in authoritatives.

But even ignoring those, deployment models where the
ESNIKeys are generated by the TLS server operator, but
DNS records are published by a different entity (say the
owner of the name or registrar) ought not be precluded
I think. Supporting such a model I think more or less
requires setting padding_length to 260 or else risking
a failure nobody will notice (if browsers fall back to
cleartext SNI) or know how to diagnose if they do.

And even in the case of a monolithic service that does it
all for every name, I think it'd still likely pick 260
in order to avoid having to exercise/write the code to
detect and react to a need to increase the padding_length.
=

Fortunately, we have a number of such operators on this= list. Alessandro? McManus? Nygren, What say you?

= -Ekr



("Holy crap - you mean I need to re-publish everyone's
ESNIKeys just because this bozo has a really long name?
Who made that up?")

I really can't see what'd motivate anyone to publish
ESNIKeys with a padding_length < 260 tbh (well, other
than not having thought it through;-). Anything <260
just seems to be asking for later problems.

S.


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000057826f05957477bf-- From nobody Mon Oct 21 17:10:07 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F670120A83 for ; Mon, 21 Oct 2019 17:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 t2KAQustRVaU for ; Mon, 21 Oct 2019 17:10:04 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FDE120A7E for ; Mon, 21 Oct 2019 17:10:04 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id c6so18138312ioo.13 for ; Mon, 21 Oct 2019 17:10: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=9DJWz15D/KtngIex8rlqOCgXlxEirbS48+xrVmL93h8=; b=OCfttGFDZ1l3no5W/1UaZSzYQxgKoRZblH/LI2tLy+dBRxWfoBkxczP2Ocwb0mRUFI QQ44MSaAcGFN0PXlDPsO22yisWQAUVqhi+BTf0Aw322r/d/HXW+MFA09KEZ8Ajihp1K9 QVtvKjtmyfGfTBY1oF1+Y5/mlVazwkYh3GIElGuSJfQL8sxCJW/QNvZbHTTFtf+9Ohsq gSAGT/3xWzGaHDyZLVRSmvwXHHocQWtdoHjRHtASV4JZALgy2LbYF/rKTCvUZH7xImRV 8zDInR5ZbXRriKfMwMTF+esMCecLYj5fMMMujSRTPNg/07ruk9X/+4eJES/ZCgLwO7cs 8upg== 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=9DJWz15D/KtngIex8rlqOCgXlxEirbS48+xrVmL93h8=; b=EZY8/HPGmmT23qXSZhlj3Li7mdrPb1aMxNopIqkU0plc0rMLVhfZnjSnQ314YrezGg Bgc0FYwzsh+6HW1lSWbhm3XRntyoIrSCzGwbAHut6HVvjR4jcmeev0ZmP5HkXptrNnJS zPiwcshZo4mVExTS5Tj3ME2vF8pidNnUFBeTUIw+2d1L20LTXLvyzIbzI/0d+m6Y4a96 cuUo5K7DhPCcoRXV/G7bw6rF4bjOJscl7mxyU2XanyGCYUivahZnEky8mOi/ndWg/T6q n37Hut0MYcN5BNtzQTiJytgGn85GnniIDuE0j2LyJK2eoHHVX8DtWPXxF7tBcFCUHS2b eBqA== X-Gm-Message-State: APjAAAVO96RZQBULlDkavyY3MrF/qiq98hlAz3AZrWkZYNXkEVBzABJZ JHAZFj5l9hHWM6hS/MocCY3SYdeIlNiEdjitzmY+m+L8 X-Google-Smtp-Source: APXvYqw5wmhrvUE0jYO2LPB55czDbsprGmKE/465VvIgYsN1nVXd7RMSgUwrqoolaiu8qOTHEhLSVzS9ZmAerMAFeCc= X-Received: by 2002:a05:6602:21c2:: with SMTP id c2mr921298ioc.189.1571703004000; Mon, 21 Oct 2019 17:10:04 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Mon, 21 Oct 2019 17:09:52 -0700 Message-ID: To: Patrick McManus Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003ef7790595749f75" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 00:10:07 -0000 --0000000000003ef7790595749f75 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 4:59 PM Patrick McManus wrote: > wildcards are real in both dns and http services.. (also the dns entries > might be invisible to the http provider thanks to cname indirections.. > though obviously service names are not.) > That all seems right. I was wondering where the 260 number came from. It seems like relying on fixed numbers has burned in the past. Is 260 one of those "I was asked to put this in" numbers? It seems like that's probably not the case here, but I think the rationale should be written down in the draft. thanks, Rob --0000000000003ef7790595749f75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Oct 21, 2019 at 4:59 PM Patrick M= cManus <mcmanus@ducksong.com= > wrote:
wildcards are real in both dns and = http services.. (also the dns entries might be invisible to the http provid= er thanks to cname indirections.. though obviously service names are not.)<= /div>

That all seems right. I was wondering= where the 260 number came from.

It seems like rel= ying on fixed numbers has burned in the past. Is 260 one of those "I w= as asked to put this in" numbers?=C2=A0

It se= ems like that's probably not the case here, but I think the rationale s= hould be written down in the draft.

thanks,
<= div>Rob

--0000000000003ef7790595749f75-- From nobody Mon Oct 21 21:29:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5333B12007A for ; Mon, 21 Oct 2019 21:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 6J-H_Yx3vAON for ; Mon, 21 Oct 2019 21:29:23 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4819120058 for ; Mon, 21 Oct 2019 21:29:23 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id z19so18814084ior.0 for ; Mon, 21 Oct 2019 21:29:23 -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=c3ONm1YAdz/yOi1cz7uiFMteMwRWgu0PJ1xPSrzN8Ko=; b=I5ha4CApgRNs0KuGGr/rnBtzQW22v4PPt8FfxjBErkZ4NUrIoGKRynfaFXp9KboHun /S4fEvIFTCUlmOwkIY2TqEhjI+6VkOOJ0G/JITf1OFBKZc2/4MhM9FPQ+kELVjilvz/i rSs+Iat/tBHA71GI5d85HF9HLYKiKhMvGGiKaluMKi3P6HB5eMDW51fami5v1HOsYMCU wAZ40fyRVnn4gfQ7R9CiJEPKbj59aOvASZibv1eGrYRvxtoy2H2LqN7/h9s+477C5pl9 HxAumubOQ9CvytwYgCzsZCn1dSQNMkpwxTCZ0jzBYjafXD65cbTas9jeUO3XgkGXW8VH H26g== 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=c3ONm1YAdz/yOi1cz7uiFMteMwRWgu0PJ1xPSrzN8Ko=; b=JuO7SeOgikzUpKsREe+CSgeGca/drdAXrWCsiKDuo3svTS9o0KxHNvrpy3LtzKbKV0 +EjQTljL7bqBhn1XZbdIfsKZ0wk5paS1mSrxw38L8mL/ca5gHzaZImVMFQDHbo/5ytBN hDEAIBnYxnBFSom/P+GGchmr8l2rj+99cRmJbaa0FSxKmSLMO5o7G4hYjFhlSkznU9Kq 8gr5fKgMWVZzrhDi9pwR+C0FY32+Cy5ED+LjgkDz1QEIZiZz2UyHDklsjIVqTCTn8Vej AYQEi+7K74RZ50OEJviPR5p04L+vV07uXg6h0cyWVrwTl6EDLnVFxs+qP49F6bTJPm/A 4O5A== X-Gm-Message-State: APjAAAVNTqLPSwiyarOGIEA/CR/shBeZEeBntZhrqB3PNx9+KmxcaVcl 0ew0MV/v0RlCaJ5Phv0OZtuuWyNuwiJweuyxpo9hgeqKnBD1eg== X-Google-Smtp-Source: APXvYqw1FVq1GsYQCXgPxroe5DuHxi1oU4zffy+/Jus++3weA9+QqVDw1+dvunpbYZ6H5feyyV7v+pUnZyd38605PUI= X-Received: by 2002:a6b:7a4a:: with SMTP id k10mr1594847iop.193.1571714863337; Mon, 21 Oct 2019 20:27:43 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> In-Reply-To: <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> From: Ben Schwartz Date: Mon, 21 Oct 2019 23:27:30 -0400 Message-ID: To: Stephen Farrell Cc: Rob Sayre , "TLS@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000a69a610595783e8e" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 04:29:26 -0000 --000000000000a69a610595783e8e Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 3:24 PM Stephen Farrell wrote: > > > > On 21/10/2019 20:14, Rob Sayre wrote: > > I have seen MTUs under 1500 many times, but nothing under 1200. Is there > > data on this? (I honestly haven't seen any) > > My assumption is that maybe 90% of names are <60 octets. > That means padding_length of 260 is wasting roughly > 200 octets, almost all the time (hi there GREASE!). Note that the current text in the editors' draft says that when applying GREASE, "The padded_length value SHOULD be 260 or a multiple of 16 less than 260.". We don't need GREASE to send 260 all the time, and the draft doesn't recommend it. Personally, I expect that 260 will be rare for real deployments, because most systems serve a fixed, known set of domains, and those that serve a large, dynamic set probably already impose a tighter length limit. One intriguing alternative would be to define some ESNI ciphersuites that encrypt a strong hash of the name. Then a server with a large but finite name database can choose one of these ciphersuites, pre-compute hashes for names when entering them into the DB, and quickly invert incoming hashes with a DB lookup. I wouldn't want to make this the only option because it can't support true wildcard servers, but I think it would cover most potential users while limiting the length to 32 octets or similar. > If that's 20% of what remains available in an MTU then > it's still wasted as it'll no longer be available for > whatever other things people wanna send with or add > to a CH. > > Prediction: if we stick with the current design, in > a few years, if ESNI gets widely deployed, we'll have > to revisit that aspect and come up with some more > efficient way to solve the problem, and that'll mean > ignoring the value 260 in then-deployed ESNIKeys;-( > > S. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --000000000000a69a610595783e8e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAW33s9MvB1nzfDmK9+1exh YkSbwQTMekg6pWs03BqXvTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMjIwNDI5MjNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAELsPHOuGFB1Ihdkl+TTpHCyhwBic3398l5yqpPNm NZQO/BB0BVQmHTzOHsvHIM8GYbO+MUGhiyd3V6UKms3OqFvlE3HTY4WGaWizP0jyeySfFg8Ka6yJ xPcJWBxJ5Q6rAUiUxbkzPaoWNDHTdnhvShZCBGGXC4vbOFyuN4415Z4u85PBcofYf3UtoJPQneek 8dgUMx5wZXDU233BFGCpPT5WfTQTYtHe5nQZ1nIb9RzfqhtX3cjEghZ+Bj0kDocHd1nXqDtqKz7Y 9j+HXT3Wodozn4z90KlFKmv+fQVDuW6bPwxCLLFGcGB6UZCb3SXRGda9c/swmvqiRvdfGtg4Qg== --000000000000a69a610595783e8e-- From nobody Tue Oct 22 01:21:19 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D46120052 for ; Tue, 22 Oct 2019 01:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 7cW9B_q2G_9q for ; Tue, 22 Oct 2019 01:21: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 6554E120047 for ; Tue, 22 Oct 2019 01:21:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1ADE9BE39; Tue, 22 Oct 2019 09:21: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 avbgC40AuO13; Tue, 22 Oct 2019 09:21: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 5DF85BE2E; Tue, 22 Oct 2019 09:21:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571732470; bh=vPx+z9byaz8i7BQJG3z3ch/yR9VdQjBsW/hyEevboCQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Qx/SHTitoMybEaZ+gTH/EqsYlU4jyQ04MlRNiT5tw53x18xMD3qjNviUuX45pxT3R h1qT1Ej4fEjEY5BjQF+Ng945Gv+Q1z4nebyiOci5s/6+4DIqRkA6xakPn17OW23o5N RwSz2EQfYF8hsl1h9T8ylco5uuyJH/AzzBLK5R1o= To: Ben Schwartz Cc: Rob Sayre , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> Date: Tue, 22 Oct 2019 09:21:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uFSR4UigAmYphWxlso2atKcFVu4XF0CXg" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 08:21:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uFSR4UigAmYphWxlso2atKcFVu4XF0CXg Content-Type: multipart/mixed; boundary="dmVV5LXQYxlYJiUGBNUwM9Z8PVW2zsrLr"; protected-headers="v1" From: Stephen Farrell To: Ben Schwartz Cc: Rob Sayre , "TLS@ietf.org" Message-ID: <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> In-Reply-To: --dmVV5LXQYxlYJiUGBNUwM9Z8PVW2zsrLr Content-Type: multipart/mixed; boundary="------------60FF6B82071BE82379326C2F" Content-Language: en-GB This is a multi-part message in MIME format. --------------60FF6B82071BE82379326C2F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 22/10/2019 04:27, Ben Schwartz wrote: > Note that the current text in the editors' draft says that when > applying GREASE, "The padded_length value SHOULD be 260 or a multiple > of 16 less than 260.". We don't need GREASE to send 260 all the time, > and the draft doesn't recommend it. ISTM that GREASE needs to follow the kinds of lengths used in practice to be most useful, so if 260 does get widely used, then I guess that's what'd be most useful to GREASE. > Personally, I expect that 260 will be rare for real deployments, > because most systems serve a fixed, known set of domains, and those > that serve a large, dynamic set probably already impose a tighter > length limit. I don't know of any hoster or service with such a name length limit. Do you have any example where a DNS name that can be published and used as a TLS SNI would be declined by a service provider? >=20 > One intriguing alternative would be to define some ESNI ciphersuites > that encrypt a strong hash of the name. Then a server with a large > but finite name database can choose one of these ciphersuites, > pre-compute hashes for names when entering them into the DB, and > quickly invert incoming hashes with a DB lookup. I wouldn't want to > make this the only option because it can't support true wildcard > servers, but I think it would cover most potential users while > limiting the length to 32 octets or similar. Yeah, that'd be nice but as you say doesn't work well for wildcard certs, which I think is a showstopper. I do think there are other algorithmic options we could go with though, that would work. Cheers, S. --------------60FF6B82071BE82379326C2F 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----- --------------60FF6B82071BE82379326C2F-- --dmVV5LXQYxlYJiUGBNUwM9Z8PVW2zsrLr-- --uFSR4UigAmYphWxlso2atKcFVu4XF0CXg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2uu/QACgkQWrL68XsX K+qVkxAAteShSuD3MJauOAacNaZHpjn9fxwrNMSd/OvCzM5zl1sYm52WVJU712uM xWT6trZnjFb+GNCu2BCAUjoY9P1QB1MmW10ywe1kb2Tbf7u5iCu5UottCj/D0yce oJFCwExCc/AQuxzIaNnNG0Cyk2IFz8GugPSPliEcVxmXrLKzI+GfUvlL+xdURo7P yiA/tI8dhD1dPVY+7kM5l6WUMQzFnbdS24b1pm5HJx5oQetJOnCZnnNrGR417Id3 w4mjXvsiI7Mf+3zLaIJkiyHMVPRFpDIMXwLgap2joCx5ra4w+PrgvvP5zQz/k5sU cjHWwnfLuKHZRzEQEUlAXbzq+GslMHcXR7LIICSAUrfTObyou+4cwYVCUqxMk8yy K05rzpq6L44LMhDoN9/OOjotmpnRjxa2vcQbLLQA35BKyHq4YmziUN/hjvcs3Xu1 GBarhe3ZBQpgQTJr9rj9IfdlJ+TioOo5vxfD/HVv9UtX1HCJKUn8AlkiteNyflOX OkilB4v1yswYEDX9JjpEsHV5NFp7mx++b8B3MeMXUiEOw5k822k6eD/1eR0NbSjp EYaHn/gpkB4S6c/lVz2kfruTwTKC7+o7z44nEJjcMLQg0vpYN6iOY/5B43GKF7uO 2LzQUFxJZfo2wbk0cevsj1c992hIYorkJs303BGJXhgH6FM3BoY= =o1WD -----END PGP SIGNATURE----- --uFSR4UigAmYphWxlso2atKcFVu4XF0CXg-- From nobody Tue Oct 22 07:56:22 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3EE1200B3 for ; Tue, 22 Oct 2019 07:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 rGlbUtEQyezm for ; Tue, 22 Oct 2019 07:56:19 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 15BE61200E7 for ; Tue, 22 Oct 2019 07:56:19 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id q1so20816591ion.1 for ; Tue, 22 Oct 2019 07:56:19 -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=YsBylWTRq8ycAHoCVPX4WCP1MpaknC2PRi7JglLw3Uw=; b=gcU9Abu/PMljcPfdpewnRpvCgzPP5c9JTUP+jtUAggWpqbUIpREofeWQ7+f0zu1etP SMwdmhDPXm3rub0y3dJt4a7o5wm2pCE+rD/Hx+U77OWveD4z0ydfQQTHDCJc5mWmvPQL Y87KQhsYLsfDP9BQcqtJwLylOUNjj4Q9+scFfyEheVtA6XnEhn2Xf5b9QlPRB3ObVTwz rSoh2mT+EF/C8tMtVM8ta1wIVV6S/vtWP6z3D4MsKKE3IoDQ+AdKTABdgNy3nYZ/WSMJ Cncfc8Y5OmA8dsHg76a3Jy0zhlLYFrKQlD9+/5I4LlFRaQqVkrAt9EaMzVbKRL+jIVzB +CXw== 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=YsBylWTRq8ycAHoCVPX4WCP1MpaknC2PRi7JglLw3Uw=; b=qKaH/xi6FyFOImOBQkQN7LvghaYMFzKFT0U701qn5ZmT3as25mdRffnhIQ2ChpWZGr f/Ovw8evIHbMx6sdSP5BYxl5kVgIKU/cbgf5LBhFFToN9HvzvjJKh5/jyAlmIE4vYzZf SHyz/4cn1uEc1mnWo/ZiriRyjH9/RY6yurvItluPZrrxjOMMV/PMQ5QbG8V3bUfItin6 mzcCBiHz8jtBGYWtPOcLIdwCDYSFYsiur3IdYUBWOdghw6YRC1wSWAjyM4eyf4Vyz0Yn 7ZkqNS4Yf6gBDwSnUIAHrFpZjkuxkpJ7C+Tkd5A/8aMlTA1g60JHH7k7DkAO6OzK1F5n nCGg== X-Gm-Message-State: APjAAAVee6SX1IuIp+QGsG2aAn8g/EXC+6zFAeGUrL/jxkoIDdLvt+Wg kwW/oHPvM9ppz4XvtSs44CGud1w/01+ccNheMyi/IQ== X-Google-Smtp-Source: APXvYqy57voubQ9jeDDEPcfJr0AxP4llV0EShaI78oM3lLZt5rCG3itq3ASjGrMeCE/abVDEnkE1m7L8B5mj1iRuI8E= X-Received: by 2002:a05:6602:1c4:: with SMTP id w4mr3939981iot.153.1571756177900; Tue, 22 Oct 2019 07:56:17 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> In-Reply-To: <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> From: Ben Schwartz Date: Tue, 22 Oct 2019 10:56:05 -0400 Message-ID: To: Stephen Farrell Cc: Rob Sayre , "TLS@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000b16486059581007b" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 14:56:21 -0000 --000000000000b16486059581007b Content-Type: text/plain; charset="UTF-8" On Tue, Oct 22, 2019 at 4:21 AM Stephen Farrell wrote: > > > Hiya, > > On 22/10/2019 04:27, Ben Schwartz wrote: > > Note that the current text in the editors' draft says that when > > applying GREASE, "The padded_length value SHOULD be 260 or a multiple > > of 16 less than 260.". We don't need GREASE to send 260 all the time, > > and the draft doesn't recommend it. > > ISTM that GREASE needs to follow the kinds of lengths > used in practice to be most useful, so if 260 does get > widely used, then I guess that's what'd be most useful > to GREASE. Agreed. (Although the details of this are potentially tricky, like whether the random length can be sticky without accidentally labeling the user.) > > Personally, I expect that 260 will be rare for real deployments, > > because most systems serve a fixed, known set of domains, and those > > that serve a large, dynamic set probably already impose a tighter > > length limit. > > I don't know of any hoster or service with such a name > length limit. Do you have any example where a DNS name > that can be published and used as a TLS SNI would be > declined by a service provider? Sure. For example, tumblr limits usernames to 32 characters: https://unwrapping.tumblr.com/post/58535402323/tips-tumblr-username These usernames also form the subdomain part of the *.tumblr.com wildcard, so the longest allowed name is [32 chars].tumblr.com. I expect that most wildcard TLS hosts impose similar limits. > > One intriguing alternative would be to define some ESNI ciphersuites > > that encrypt a strong hash of the name. Then a server with a large > > but finite name database can choose one of these ciphersuites, > > pre-compute hashes for names when entering them into the DB, and > > quickly invert incoming hashes with a DB lookup. I wouldn't want to > > make this the only option because it can't support true wildcard > > servers, but I think it would cover most potential users while > > limiting the length to 32 octets or similar. > > Yeah, that'd be nice but as you say doesn't work well > for wildcard certs, which I think is a showstopper. I don't think it's quite that bad. For example, this approach would work fine for tumblr in principle. Any hash corresponding to a name that exists can be inverted from their database. Any hash corresponding to a name that doesn't exist will return the default cert, which still covers *.tumblr.com. The case where this doesn't work is when multiple wildcard domains share an IP but not a certificate. That seems most likely in a CDN context, where multiple wildcard customers could be sharing an IP and providing their own certificates. If the CDN's operational architecture allows pushing all wildcard customers into a single certificate, the limiting factor becomes the number of names allowed in one certificate. > I > do think there are other algorithmic options we could > go with though, that would work. I suppose a server could indicate that the first N labels be included verbatim, and the remainder should be hashed. Or maybe it should only be hashed if it's longer than the hash size ... there are all sorts of options here. > > Cheers, > S. > > --000000000000b16486059581007b Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD2IvIVvOwi7f/cL5saz975 iBj2OWozWb92RBZi3HtFDjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMjIxNDU2MThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAH96TO/Pu78UsKFxsj4is4JumCpnCuSfO8krFw/mL 322GDxYmBW1GnjwpA5XCxXXJGAIlRT9XZVRR4WnP8WTqz6Qlwyi69ArVRElv4i/7Sk5SLiVMLYYT sMiOk9Iye8WjoObBbNN0ia/3vbOAnYoJhof5oXdnfuAtofH4uGJNuZU//pdyvDTdUTKl/8gun6h8 s6nefm9LHO2YpKdhmNaZ88HtYyz0ty755PVsIcR26fY85C0SjM31tD5tEZqttC58RyE8eM/VRP+L YNlsGMXR0yDLcdLHkaEAnFg9FTXwvCnMc8ixzed7gDzpNg1SPBIcLDbrKUtlfiP84gQqf2CjUw== --000000000000b16486059581007b-- From nobody Tue Oct 22 08:06:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF66120088 for ; Tue, 22 Oct 2019 08:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 QaIBBQ9D2MDf for ; Tue, 22 Oct 2019 08:06:48 -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 27A4012009C for ; Tue, 22 Oct 2019 08:06:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 58463BE53; Tue, 22 Oct 2019 16:06:46 +0100 (IST) 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 tzQJVkqIJX4Z; Tue, 22 Oct 2019 16:06:46 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC130BE50; Tue, 22 Oct 2019 16:06:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571756806; bh=gCkHsgedoA2F8g1nG/7Ygl61Kqi9o6yikbi5gPJd3Fc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=KQbccDKDD/0hNlZGZim2fh4nxFkWyJHfEIkWU3cdW4ccOBRHOvsqC0CWIAVtc7nGr Vozy5qEbsIepAjB6xAval5cZVtMbvUO54v8A93O9QwSqkmNMWM8xBb89cIX/61S4qf tmKmHcaH34Op1t1W48XWlZBSDXEqEHt1lxVkrymQ= To: Ben Schwartz Cc: Rob Sayre , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> Date: Tue, 22 Oct 2019 16:06:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="WaAjWMMnjIPcoiPwgvii9ctQGpPAZqOd4" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 15:06:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WaAjWMMnjIPcoiPwgvii9ctQGpPAZqOd4 Content-Type: multipart/mixed; boundary="ElHd6FgI1JWOJfH9Kb5wSJSUk1CXWxpyl"; protected-headers="v1" From: Stephen Farrell To: Ben Schwartz Cc: Rob Sayre , "TLS@ietf.org" Message-ID: <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> In-Reply-To: --ElHd6FgI1JWOJfH9Kb5wSJSUk1CXWxpyl Content-Type: multipart/mixed; boundary="------------24765079B94520675490AB65" Content-Language: en-GB This is a multi-part message in MIME format. --------------24765079B94520675490AB65 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22/10/2019 15:56, Ben Schwartz wrote: > Sure. For example, tumblr limits usernames to 32 characters: > https://unwrapping.tumblr.com/post/58535402323/tips-tumblr-username >=20 > These usernames also form the subdomain part of the *.tumblr.com > wildcard, so the longest allowed name is [32 chars].tumblr.com. >=20 > I expect that most wildcard TLS hosts impose similar limits. >=20 Fair enough. Sub-domains (or whatever may be the right term) can have such limits. However, IIUC most services ilke hosters or CDNs will just allow anything that's a valid DNS name so I argue that our design target ought be to handle that well. (The current spec does handle it, but not, IMO, well;-) Cheers, S. --------------24765079B94520675490AB65 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----- --------------24765079B94520675490AB65-- --ElHd6FgI1JWOJfH9Kb5wSJSUk1CXWxpyl-- --WaAjWMMnjIPcoiPwgvii9ctQGpPAZqOd4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2vGv8ACgkQWrL68XsX K+oERhAAxXglczkg6MspGbyJ9eU5K8OweSu7rzb4MsscX2ugjsOBMPzzthu7Lgjh 9zoVjZgPDJdsg2NQhOfdsqHR8cUwjdbPJS/p1dak4yIOIUgYCzhD48xp7ynp+Jdf pzdT9vUjM1X6CuPjcFue6dRByiDFffFDNS7jLZ/okuiEgR5XxOz7ESawFUHSuMPZ yEmQBd0+A/JL8bzIcAEOa/QMiX/XvOt8t3rx46lCP4OV2p+Xfz5rNELwUis4al+Z MH7H/5cMtDw4dRXYWazX0pdXpdLpESO0KaWPn3xSrkab81UPHssg6TZVgUSgFJtS L8wZ8cQwPeycBgx9wgD7bvF+2p9IXkId5urZzp6n+viWvg0USVUT3eaDV3pVFjPd WAQze6PHnB9WgzPt5E4jj5zgN/YjQn6p6wvik3ZwhZdoj2cw08AYYtoh2tni9L2n Fej3LeaCZS+d2Lscj56rix8sQ9AAeB8YKWsdIv+ee9tc+lT7HelRUcumhJNdbH1n jWpy2KtiY92mBzrUpTuRkR8/TqW633YYjqE7nYyTtAcfxdlKlbCEW6bFhj1hx1qX 6WpdUHvX/+yAtThCWLNbfbLaFmvMCW5Gszq1Z+05zw4S5MA+EJnqTSuu+f6mwPwW rcy6K2Rs60Gyi++35ugtGUEtqi6NCYgavA91BpIC+dSymL/jgRQ= =A9BR -----END PGP SIGNATURE----- --WaAjWMMnjIPcoiPwgvii9ctQGpPAZqOd4-- From nobody Tue Oct 22 09:22:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35756120073 for ; Tue, 22 Oct 2019 09:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 W19EvIb1srn9 for ; Tue, 22 Oct 2019 09:22:04 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0: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 33CC712004A for ; Tue, 22 Oct 2019 09:22:04 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id f13so15981375ils.11 for ; Tue, 22 Oct 2019 09:22: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=Qec8JNvcXLf07ytcSK2T3n31D7Nt4nF20Y/uI8JJLlk=; b=G5vQndGotjh53veVK/PC/aYEaIQomY2A8SkHQpcvWoLycnSM95+Pk1eGAA4SDt3s9H mg/sr02Mt4LDlAvhVNb/pL626y0QOeOWyD2H16gh6sY0QKywdjYbu18DjLmh0as7F0kc 6X8vq9ti9hzRYXAUhG62F9Zstw12z1L1fNRAZXoG5yuYg/pUI9T1LXJN+7BpZpjwYgU+ JpafYKGveyGmkBAjJ7vvtX3qGJVh1okCRRnq4IOGYAVa6AjjQsYdMpmUQVJLK1P3krcF QgNXoLiyBWFGID3afkVOQPazIJJGaH+wPxGydJwY6VN14miXgk6mDpq0w5mcDtwFGIe6 tAdw== 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=Qec8JNvcXLf07ytcSK2T3n31D7Nt4nF20Y/uI8JJLlk=; b=YRMLKsKvUT6rE7E9E1kZ179ULqjxuaUCMbpMavlu9CTrwjXBmNt3n9rC9DDcT6cwbi prKglgB0sSEDMT0cooQAbPr+1FYbPGOduanx7bmLcthlxuoj7M6NN0UJ1Nv0Q/GLVsfL tsZ8y8taUL+08+xCl0vZsdGItzaUtuTRcT5+Ih1dcq+G5VcuWEwr98h0x5dufW8uITm4 OQdL+Ta4cWuvdd2RO79o3veocFVey2Uiq7VYTt73MGl+JVXleK9RND60FlAZ8ovDD3kN 3mmlPVbIGkhMjIC1LwSXp2apgP0vQV4p5/CLrzdjqAOXHATLNVXRtRsTB2ROgaJYCl93 b72Q== X-Gm-Message-State: APjAAAXEaGqcXTe9V0phJFdjvfxXKvSRpfu0x+ghXFMz9HP84vkPRDsF e0bPznVsrH/X4mK+itNr81B3Xsg31eJr0+3eCgcwjcqa X-Google-Smtp-Source: APXvYqyXdQ4OIq+ywhVPaWB48iXR73sF7oT2rcPsv43bL5aZ5PFjTmVFMZAL+qalsn6wIB68uAdixHa12x11FsBqG9k= X-Received: by 2002:a05:6e02:a:: with SMTP id h10mr9145516ilr.254.1571761323200; Tue, 22 Oct 2019 09:22:03 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Rob Sayre Date: Tue, 22 Oct 2019 09:21:51 -0700 Message-ID: To: Stephen Farrell Cc: Ben Schwartz , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000057561a05958233fc" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 16:22:06 -0000 --00000000000057561a05958233fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2019 at 8:06 AM Stephen Farrell wrote: > > > On 22/10/2019 15:56, Ben Schwartz wrote: > > Sure. For example, tumblr limits usernames to 32 characters: > > https://unwrapping.tumblr.com/post/58535402323/tips-tumblr-username > > > > These usernames also form the subdomain part of the *.tumblr.com > > wildcard, so the longest allowed name is [32 chars].tumblr.com. > > > > I expect that most wildcard TLS hosts impose similar limits. > > > > Fair enough. Sub-domains (or whatever may be the right > term) can have such limits. However, IIUC most services > ilke hosters or CDNs will just allow anything that's a > valid DNS name so I argue that our design target ought > be to handle that well. (The current spec does handle > it, but not, IMO, well;-) On reflection, I=E2=80=99m not really comfortable with the code I=E2=80=99v= e written on the client side. It does work, but I don=E2=80=99t think the DNS record should = dictate the padding so precisely. I=E2=80=99d like my client to send 260 (or whatev= er the right number is) whenever possible. As specified, short TTLs and varying padding could be a problem. thanks, Rob > --00000000000057561a05958233fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 22, 2019 at 8:06 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wro= te:


On 22/10/2019 15:56, Ben Schwartz wrote:
> Sure.=C2=A0 For example, tumblr limits usernames to 32 characters:
> https://unwrapping.tumblr.co= m/post/58535402323/tips-tumblr-username
>
> These usernames also form the subdomain part of the *.tumblr.com
> wildcard, so the longest allowed name is [32 chars].tumblr.com.
>
> I expect that most wildcard TLS hosts impose similar limits.
>

Fair enough. Sub-domains (or whatever may be the right
term) can have such limits. However, IIUC most services
ilke hosters or CDNs will just allow anything that's a
valid DNS name so I argue that our design target ought
be to handle that well. (The current spec does handle
it, but not, IMO, well;-)

On reflection, I=E2=80= =99m not really comfortable with the code I=E2=80=99ve written on the clien= t side. It does work, but I don=E2=80=99t think the DNS record should dicta= te the padding so precisely. I=E2=80=99d like my client to send 260 (or wha= tever the right number is) whenever possible. As specified, short TTLs and = varying padding could be a problem.


thanks,
Rob<= /div>
--00000000000057561a05958233fc-- From nobody Tue Oct 22 09:46:49 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E8D120073 for ; Tue, 22 Oct 2019 09:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 GidWWbqFcU18 for ; Tue, 22 Oct 2019 09:46:45 -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 B2E7C12004A for ; Tue, 22 Oct 2019 09:46:45 -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 x9MGRWkR026246; Tue, 22 Oct 2019 17:44:36 +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=iDE7qcZTqpcuCG5nSyhQsujOR6JiyiRKwSuTDKfQejQ=; b=fZCblB8C6p2/0NlOLbmsjbYv8jrq8lUHl3JDEWx3BSDJhIwJw7UsXNBIeZ2plg8iXgjt 83VljrLsWTtTwC/8YOt8sGjIH83mM2mzGx0J99S+Y9qdQxRrxfslPVhg5LSfDVwcvwGR kVIvuUhSYCfUdEJNshsJ6w/b+XL+HFbk2DkTTRnRbZyGxQIYsWaanSfLGWsszP7b6WJ1 x72pVCXTVohwuJLsuHvVoMG9lU0/bREs5SvDrpUD8huVpTeIE7H5OVpoax0YB2A7RlJ+ XON1XqP9A3ovSI5Pq7ezle22nius7vuRmMoOLHSaWSseCENEmy1HBKTXZ7Cahm4QJEjB sw== 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 2vqt4uxxeg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 17:44:36 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9MGX3o3003624; Tue, 22 Oct 2019 09:44:35 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2vr0f8cqfc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 09:44:35 -0700 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Oct 2019 12:44:34 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 22 Oct 2019 12:44:34 -0400 From: "Salz, Rich" To: Rob Sayre , Stephen Farrell CC: "TLS@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-esni feedback Thread-Index: AQHVh48Xcu8AFw12IkSiVjKLPouzoadlVIKAgAAYE4CAAAJ1AIAABCaAgAAeVgCAABO4AIAAA+OAgAAJKICAAAV3gIAAAoUAgAABPQCAAAKMgIAAhyYAgABSCwCAAG5ZgIAAAvSAgAAVAoD//8NLAA== Date: Tue, 22 Oct 2019 16:44:34 +0000 Message-ID: References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@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/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.15] Content-Type: multipart/alternative; boundary="_000_BE5E72836EF44113ADBA7790A5DFACD8akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-22_03:, , 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=843 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910220139 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-22_03:2019-10-22,2019-10-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=831 lowpriorityscore=0 phishscore=0 malwarescore=0 adultscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 spamscore=0 suspectscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910220139 Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 16:46:47 -0000 --_000_BE5E72836EF44113ADBA7790A5DFACD8akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkkgZG9u4oCZdCB0aGluayB0aGUgRE5TIHJlY29yZCBzaG91bGQgZGljdGF0ZSB0aGUgcGFkZGlu ZyBzbyBwcmVjaXNlbHkuIEnigJlkIGxpa2UgbXkgY2xpZW50IHRvIHNlbmQgMjYwIChvciB3aGF0 ZXZlciB0aGUgcmlnaHQgbnVtYmVyIGlzKSB3aGVuZXZlciBwb3NzaWJsZS4gQXMgc3BlY2lmaWVk LCBzaG9ydCBUVExzIGFuZCB2YXJ5aW5nIHBhZGRpbmcgY291bGQgYmUgYSBwcm9ibGVtLg0KDQpJ IHRoaW5rIHZhcnlpbmcgcGFkZGluZyB0byBzb21lIGZpeGVkIG11bHRpcGxlIGlzIGEgZ29vZCB0 cmFkZS1vZmYuICBBcHBhcmVudGx5IHRoZSBuZXh0IHB1Ymxpc2hlZCBkcmFmdCB3aWxsIHNheSB0 aGF0Lg0K --_000_BE5E72836EF44113ADBA7790A5DFACD8akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <02E2626A217B3047BA526CA3B3A2EBCC@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7PC9zcGFuPjwv Yj5JIGRvbuKAmXQgdGhpbmsgdGhlIEROUyByZWNvcmQgc2hvdWxkIGRpY3RhdGUgdGhlIHBhZGRp bmcgc28gcHJlY2lzZWx5LiBJ4oCZZCBsaWtlIG15IGNsaWVudCB0byBzZW5kIDI2MCAob3Igd2hh dGV2ZXIgdGhlIHJpZ2h0IG51bWJlciBpcykgd2hlbmV2ZXIgcG9zc2libGUuIEFzIHNwZWNpZmll ZCwgc2hvcnQgVFRMcyBhbmQgdmFyeWluZw0KIHBhZGRpbmcgY291bGQgYmUgYSBwcm9ibGVtLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB2YXJ5aW5nIHBhZGRpbmcgdG8g c29tZSBmaXhlZCBtdWx0aXBsZSBpcyBhIGdvb2QgdHJhZGUtb2ZmLiZuYnNwOyBBcHBhcmVudGx5 IHRoZSBuZXh0IHB1Ymxpc2hlZCBkcmFmdCB3aWxsIHNheSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BE5E72836EF44113ADBA7790A5DFACD8akamaicom_-- From nobody Tue Oct 22 10:49:48 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A28B1200D6 for ; Tue, 22 Oct 2019 10:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 xuexRdoedM-F for ; Tue, 22 Oct 2019 10:49:43 -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 D72221200CD for ; Tue, 22 Oct 2019 10:49:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2BDF4BE4C; Tue, 22 Oct 2019 18:49:40 +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 rEquQilbRF2u; Tue, 22 Oct 2019 18:49:38 +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 A7D3DBE47; Tue, 22 Oct 2019 18:49:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571766578; bh=ZSzHS/kWBtSQmjTJxkbNR9ZYW1YH0ihDiXabWtTJCOU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MhVQhQJP3QsaP/zMozWWwniNG14JIS/Ucj3AtJj3fDFj7JdQf10oJ2n6czyMJiGd1 Ila7FqXvyRm752n8xPnMSfG7f/9XpZ9q532n4o3i2hwtvL04Mg/M+jQQ0rVViXPcCy awG7UhYm3oEAioUSMm7axYPZW0qkOfLAZ1s9zyHs= To: "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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, 22 Oct 2019 18:49:23 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IFCzrDRERdFivL1cYoJJTWJsOCzqBfBbN" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 17:49:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IFCzrDRERdFivL1cYoJJTWJsOCzqBfBbN Content-Type: multipart/mixed; boundary="LoTRdvdVdxl7ZMQKs5zoGMnOLJX1wUNUG"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" Message-ID: Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: --LoTRdvdVdxl7ZMQKs5zoGMnOLJX1wUNUG Content-Type: multipart/mixed; boundary="------------6EBCE5B30CB213F12017469E" Content-Language: en-GB This is a multi-part message in MIME format. --------------6EBCE5B30CB213F12017469E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22/10/2019 17:44, Salz, Rich wrote: > I think varying padding to some fixed multiple is a good trade-off. Me too. I'd go for multiples of 32 octets, with a SHOULD to add an extra block or two randomly, but anything of that kind should work. > Apparently the next published draft will say that. Hmm. That *really* ought be communicated to the list by the draft authors, and before -05 is submitted. Cheers, S. --------------6EBCE5B30CB213F12017469E 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----- --------------6EBCE5B30CB213F12017469E-- --LoTRdvdVdxl7ZMQKs5zoGMnOLJX1wUNUG-- --IFCzrDRERdFivL1cYoJJTWJsOCzqBfBbN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2vQSMACgkQWrL68XsX K+quhBAAynIIK0Qe6GLULrwNUpHtgZ98sqWqOCOilq3XOdSmHjBq8Ou74br5UU66 Bz5GcQ8X9Fb8k4sFwS3iHugkcb007tDYu0v1dUJflAe3uSTWS0/Ln4hb9rPjhbj+ GazDxWWen73mysaGvS+UacL55rfj8+OO7sI90ZnTi89yp+YYJ/Qa0JeO0gBttcrj 3OmB0/nTvrntXD+j+exms2n6SfQKz0urY2G+SxMS/0rbLZ79Mv7B8YjDlWEXIkHC B/SQzB9esqK7rZxDkDjrF/15/p+1pX7E/xUkTaajOA9QqFsR0M7dMueVawMQrgFv 2hJbEYxd3fU8gr3vl9oRWzl69uNG1s4HvNYqw2HOpVOjv4F1kIBhR36iglZVMXui BwRz1R/p0de1tYoiy47EX9mU1bvBtqzgGfmypQjGv7ZxdF57mXLM8kAecXyv+Yvm RI/IaFVIyhTSNM7zqzwEm0ZrDW3JTK9GH9wHY2lD2tZcPKxKpkZgFPFuD3HG1SI2 dqMkR+lLNS4OnviTzVjpdX0lVeofrAGVR8hcSvo4UYZaqBk+xugQ9ObMyWYhkcR5 GjZLVTEE2APba7WDyqIGq3KhYQeDZY6UNju/XB6jNqyWuuyJldq4A0EqtgePgkEN HsM02bS8sScMLMCcIbyRnNyCy1wEKtO9a2Br/AeNhfpZoNG8kvw= =y/Ys -----END PGP SIGNATURE----- --IFCzrDRERdFivL1cYoJJTWJsOCzqBfBbN-- From nobody Tue Oct 22 11:11:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1C51208DE for ; Tue, 22 Oct 2019 11:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8XYkpJty91o for ; Tue, 22 Oct 2019 11:11:07 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 731931208A0 for ; Tue, 22 Oct 2019 11:11:07 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id t8so13849702lfc.13 for ; Tue, 22 Oct 2019 11:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NgM/O/Y6WRVBFwxnI6cUmA1yCymsGq6ytSiyMp38nSI=; b=o6h1y0NYLIJJfhzRBTMRfjbgO1d7lFXQVnSAe7RCOvm5AdWBXFbNQyJEMZGInajlBC y8NLFd+zKgEUIqy31fTtF8kIEuF4pMsZPQvp8e9wm2tbZSodbbyVJfs6eDCpbm4xaNau 4WhS4vXWGYAVeAAKNCVBoOdAqq8PnDO5zuSAMkex9p9cAxbjwB4X6UMIPIdS3D4TK9TQ BHL3QrozSm5kTXssxRGRx1/xYax/FEYj33+RB7itrp6QKCZXhFbrY0K8w3qKcJVj+5jQ T7/CNRmZOKCgRrxMHAEnI3Wd9ApNgrYWBDND6Ab+v+GbWj1GWhMEyNlNJ87On8DhI02z NxVw== 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=NgM/O/Y6WRVBFwxnI6cUmA1yCymsGq6ytSiyMp38nSI=; b=X+fFTOA7Ngwaa4VCghKlsALNP/uPsWphQLklF4f5o/A6xd9lOsXuNWym1vQRreuO4l 3L6M8cPkjl6RR/LP1FoAb5btfPdJrOzPkrpGMOYo/1ZHhhYMCrM3pCfHFftFwrrjZWIt gTPgcwgo8ogh8JqwjYbfUcNQIfxwHACIjaW6nVVbK8f+p8WZS7AIO/3ieCI5bo1i/pWc i+dBm+GQoanu7SREv6R7m2yETxzTf/GWCq1oXeauPkrhR3fy1M+rNJq+JhEuRCU+mNSy +031ZVh40WPbO2B5bo42um0NX6CzvFMuE9mcaWa5BY/LghTouNlb5Ixoe1zpUuLoshIq Dl0g== X-Gm-Message-State: APjAAAWuKt/MXnAgTvFO9SHzxn8hqUjdpf3jNLjXMF1kBoA8b6C1+fYa sM91lsNwDEBkExop4kX2+BJG62BXyW7oN624UuB6uA== X-Google-Smtp-Source: APXvYqzRjqAzhrCwkYtJeaniaVW2/0yxHwHnrRlo7H4htnTi8C6wr3E/q4oIJIMwPy5oze5f0SK8zneojw8Wl5F2PYQ= X-Received: by 2002:a19:f107:: with SMTP id p7mr17875344lfh.91.1571767865509; Tue, 22 Oct 2019 11:11:05 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Tue, 22 Oct 2019 11:10:28 -0700 Message-ID: To: Stephen Farrell Cc: "Salz, Rich" , Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000004b1fcc059583b92a" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:11:10 -0000 --0000000000004b1fcc059583b92a Content-Type: text/plain; charset="UTF-8" On Tue, Oct 22, 2019 at 10:49 AM Stephen Farrell wrote: > > > On 22/10/2019 17:44, Salz, Rich wrote: > > I think varying padding to some fixed multiple is a good trade-off. > > Me too. I'd go for multiples of 32 octets, with a SHOULD > to add an extra block or two randomly, but anything of > that kind should work. > > > Apparently the next published draft will say that. > Hmm. > > That *really* ought be communicated to the list by the draft > authors, and before -05 is submitted. > Uh,why? Authors generally have a fair amount of latitude at this stage of the process, with the understanding that the draft can be reverted. And I say that as someone who isn't quite sure what the draft in Github currently says :) -Ekr > Cheers, > S. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000004b1fcc059583b92a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 22, 2019 at 10:49 AM Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:


On 22/10/2019 17:44, Salz, Rich wrote:
> I think varying padding to some fixed multiple is a good trade-off.
Me too. I'd go for multiples of 32 octets, with a SHOULD
to add an extra block or two randomly, but anything of
that kind should work.

> Apparently the next published draft will say that.
Hmm.

That *really* ought be communicated to the list by the draft
authors, and before -05 is submitted.

U= h,why? Authors generally have a fair amount of latitude at this stage of th= e process, with the understanding that the draft can be reverted.

And I say that as someone who isn't quite sure what the= draft in Github currently says :)

-Ekr
<= div>

Cheers,
S.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000004b1fcc059583b92a-- From nobody Tue Oct 22 11:15:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C991207FE for ; Tue, 22 Oct 2019 11:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 A3i9ttwI36lf for ; Tue, 22 Oct 2019 11:15:38 -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 0CF9E1208A0 for ; Tue, 22 Oct 2019 11:15:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32F9DBE55; Tue, 22 Oct 2019 19:15:35 +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 LZksYWjJGhYj; Tue, 22 Oct 2019 19:15:33 +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 DF282BE47; Tue, 22 Oct 2019 19:15:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571768133; bh=NVek/3UoUsehuJcDtO0regZSOPdUXbqmX7KBzN8ZHJk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=shE9dTDtGA5fCFPe+mZqhfxD92tNwlohZdzvn+i+/E40K4H1zJjv1feocd+/T1GIC Zba1GOeUcF6ImXK7l98JRQMTJvh2qGwWj94m6hXXlG6Bzif3NS2q3yK7LdTrb1VKI7 u8k78k9CmS/xx/WzRw7Ucms7a67Kt0ec4HBCa6DU= To: Eric Rescorla Cc: "Salz, Rich" , Rob Sayre , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <3b45ebae-0c79-afb8-62aa-506392e8119b@cs.tcd.ie> Date: Tue, 22 Oct 2019 19:15:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ammVgH7mOuJfX3ON1q651MfHra6UYYdRg" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:15:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ammVgH7mOuJfX3ON1q651MfHra6UYYdRg Content-Type: multipart/mixed; boundary="46ILu84VfpbTJ28tiUzlyLWQv81zFym3J"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "Salz, Rich" , Rob Sayre , "TLS@ietf.org" Message-ID: <3b45ebae-0c79-afb8-62aa-506392e8119b@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: --46ILu84VfpbTJ28tiUzlyLWQv81zFym3J Content-Type: multipart/mixed; boundary="------------AF07720BC68E944F69893E1B" Content-Language: en-GB This is a multi-part message in MIME format. --------------AF07720BC68E944F69893E1B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22/10/2019 19:10, Eric Rescorla wrote: > Uh,why?=20 Openness, transparency, enabling the WG to make decisions on the list. I'd have thought all that was pretty obvious TBH. It also seems a minimal level of politeness given there's an active discussion on the list. S. --------------AF07720BC68E944F69893E1B 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----- --------------AF07720BC68E944F69893E1B-- --46ILu84VfpbTJ28tiUzlyLWQv81zFym3J-- --ammVgH7mOuJfX3ON1q651MfHra6UYYdRg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2vRzUACgkQWrL68XsX K+ooew/+JVphYFEfsPlH+Gwvd/CIwb50pvvFw7FScZl/9DSVqcxtqf34GIOodqBq h6IMNnhcOG+jTH3zX0de+S3PsnO6yEy3DIKNVIPE7oqQVqyATXyRq/d8TUejdqD6 Z5W8nos+S3sMq6hFmUncxeSDZWlnZBvGodqkplC6nfjnuYG172/GxOs7ZjEJUFPu /uUhxbgLGVfYU1ijCy6QQJ4zLPfmRd0BT9HCx+A234zB/qbjZVfm9jLsl/y242r6 XvaYmEFrrsiyDaepqtsCyPtIoHt2jYu5NUyyMCOXWmw59lLSokxPgXsBOnnL5zh/ ogjBtr7gggwMBpimZz0Sq01dSbp3YAPZsGdrcK7ikfh+q4qlZJ0RVCmhVqM3QoTW YWXjfuZWOkmixZWQ+cavaBjc5IWOinKpl6zCKCbSyZk77s0uRXFLYKcL/ZbqCTkR r85tuwB8M1vud8YeiFkKgbBYv8Ua14w0ZUBrqv8HbosSD9nu+Mccd7pa6vYxKoIz R7E19jRl/QYXnVuM1NtrOQIzjcR/vXTY0Xs4VCfdf2asCV6S7Wfxw7YM8h0OovQe ui44zu/kkTLqSGwfD+fTvGWGqpQNXWPFl/R/CuwVcrh8RzG0OrTMYv2MxqKHJli4 xUHYjEzb3K8CyIh5/lyAPhwpoos633hdFMXG+ss3lJ7fjFsgFek= =fhN6 -----END PGP SIGNATURE----- --ammVgH7mOuJfX3ON1q651MfHra6UYYdRg-- From nobody Tue Oct 22 11:15:52 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70BCE1207FE for ; Tue, 22 Oct 2019 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 TVykUp5ME1vq for ; Tue, 22 Oct 2019 11:15:38 -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 0CCD7120881 for ; Tue, 22 Oct 2019 11:15:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 22D40BE53; Tue, 22 Oct 2019 19:15:35 +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 zuvh4m9vtQXK; Tue, 22 Oct 2019 19:15:33 +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 E7353BE4C; Tue, 22 Oct 2019 19:15:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571768133; bh=+NZYeMNYJKqs5XdOCJkW9LNnSw5pyeENCyEkPxdfzeE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CDQu0fY2Bh0PV/Axb9o/6vRx1BNMTt01MCnoS0IY6YnsmLt8z+IeflWL+i6bQvxbX lvH/PkRPzrSSBhVR0dWCuvWfcav6uvnMSF21oeBcFSoMPVQqDwQkIKEOyEdeU3GnIp P3Fs0EnsEn/pvswFsU5Zh1cLLaCqE5hVqTZpE694= To: Eric Rescorla Cc: "Salz, Rich" , Rob Sayre , "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> Date: Tue, 22 Oct 2019 19:15:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="DbZ5szL4gX89NV9OubrdgmLUFX1G1HJdN" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:15:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DbZ5szL4gX89NV9OubrdgmLUFX1G1HJdN Content-Type: multipart/mixed; boundary="ZkM51HaoIEonLpIn7KG2l4rtvFOIwUdVZ"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "Salz, Rich" , Rob Sayre , "TLS@ietf.org" Message-ID: <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: --ZkM51HaoIEonLpIn7KG2l4rtvFOIwUdVZ Content-Type: multipart/mixed; boundary="------------2FCEDABE10AFD69B05F1599E" Content-Language: en-GB This is a multi-part message in MIME format. --------------2FCEDABE10AFD69B05F1599E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 22/10/2019 19:10, Eric Rescorla wrote: > Uh,why?=20 Openness, transparency, enabling the WG to make decisions on the list. I'd have thought all that was pretty obvious TBH. It also seems a minimal level of politeness given there's an active discussion on the list. S. --------------2FCEDABE10AFD69B05F1599E 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----- --------------2FCEDABE10AFD69B05F1599E 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----- --------------2FCEDABE10AFD69B05F1599E-- --ZkM51HaoIEonLpIn7KG2l4rtvFOIwUdVZ-- --DbZ5szL4gX89NV9OubrdgmLUFX1G1HJdN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2vRzUACgkQWrL68XsX K+qnWQ//YVWu0LFHbD7OAqvaHQhZ/gEzu1DUksOZ39vwCMprrvWf8Zh1P/TfHv9W 5QuOylfue6hK3vgnHp5fTaRjQU34bRgdiGeuFVAtYkEihZqH1oE5IrUtBd8vHzem 5d3vunKK4E8JWc+abht1Fvt5e3BJSQ02XEh1kYzhwU5PzIIWvjnUWAcErt7kdvPG mNu6nJ3wkuPhBjaPNMMWcjVWj4o1F0oZ2G7hL9LgpILodoiRnp9AN/LSEVSS356x S4QMOLQ0mzmYnx/Aw8WMBV1fLZcfVa/bw2ma4Rqp5lrBnqo5sg21si4YsoApqz7X o/8qZ5V+4px4EkHZ9Acl/SkSErxMJRIZqqsCuag7h5ahUDfHiJK7X3visU4LXFPu pKD3ekmVg6wVoMMfXPUydm+mUN3uPqhfLYuEwBy7ZvgZX0yFv1zIZlxEZP+XNwbL v2dMtuANZsfQZBRLX/JTjyvpN0xUek/hKQp9JANF8eSn3Yi8LhQsvtB23zgm9CuR sg97AXKQHexdmFEbCiqThloqoTwlNeRZt3+yVZZVGe1ubGgro5QGkKwbwa4qVY1+ dv8wZLGwfNPdFRRV2DsmTf3jfXXI9hPqLHv99EgQOEtgMNTvoDgJMCM9SfcPbCc9 tRLUA50GNhTBVaesdR/74mrTRD/rNpeV6szapgZEj+U8qRrokyc= =Ziwp -----END PGP SIGNATURE----- --DbZ5szL4gX89NV9OubrdgmLUFX1G1HJdN-- From nobody Tue Oct 22 11:24:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9688C120953 for ; Tue, 22 Oct 2019 11:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhZL1iZX0YLQ for ; Tue, 22 Oct 2019 11:24:53 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F073912094C for ; Tue, 22 Oct 2019 11:24:52 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id x4so7598022lfn.8 for ; Tue, 22 Oct 2019 11:24:52 -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=CCOEFKx//aNiGSnzX9P8OcRMsUEdKRyyaxT/yD2V5ZY=; b=NF08AXOv1JgWRbUshUSp5UQANRoD29G+hD5oCn0NwcZgn9a64z9IA7eqJ6Gl36iLJq zH/B8nZw97c3WGOj3cE44c8C67WpGGv9fS6eoG5cHF8RePmrsJI9gUCAGGjGJRJyZXKQ yxr4kujgZnMDuFlX1pbiXbC8VaFlkuQKNxK7SNEZaHTudX9MYz5MM4VVz72l8Lgw1Czn 04XtIf+7J8ktLhnMn5jfBQSc2PhTlPOxVkCJf65vaaFV+FblnlgvRJfJ2aGFm3adXY02 tb18r5bbmVxB2dEu3SDJG25IAHsAHWkTErfguBqZyeAOx+JR9elWmN/F7hVSh7dPQMjP sa+g== 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=CCOEFKx//aNiGSnzX9P8OcRMsUEdKRyyaxT/yD2V5ZY=; b=nAu2N6N2Ffpe40U3piXEmPxu1dprUTm54Zv8jWgARaIAjB5Jo5MOq+ynhb3KoEaGfU zPMTXTkQJc0vhkle93JToClnL9sCSUqLp1mVr4hpOjcv7ozbkyVKlHwXqFha3H2LPVRv m/IoUS+BqpAGfnotSja4PNOg/+ONkzgNSrTvoqnKpfzv8mWvsQYN0nIs3GlWQh+wFUXx U5N4sc9Bi+/FIzoQNPx4AF1elI5JmakanfUve0DX1C/VT+/XqxpJIEjdCwbQ4PkKn9z/ SJhVHO5Pn8SEc2Y42rJRAyaN94l4hz1G63qkmZuEqUiu0V08bCEc85CQY7B8q2l06DE3 VcFA== X-Gm-Message-State: APjAAAXgjTNFlRpyH4pohSnUZIOnYFFFxRwMgeMB7rZe2bEbh9DyROLx sSpmLKNMR+m8GjZwV3cp5XRS3j+v4CX1laMLeY7/TQ== X-Google-Smtp-Source: APXvYqxWemXwrkc1keY+GgEGMpeAyjQDGWmHBAr8tQSAx2FvDbFOmEi5KNmrInoeRuPnYBLEnlCiv95647o52CuUbK0= X-Received: by 2002:a19:c6d6:: with SMTP id w205mr17797668lff.17.1571768691225; Tue, 22 Oct 2019 11:24:51 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> In-Reply-To: <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> From: Eric Rescorla Date: Tue, 22 Oct 2019 11:24:14 -0700 Message-ID: To: Stephen Farrell Cc: "Salz, Rich" , Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000829026059583eae9" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:24:55 -0000 --000000000000829026059583eae9 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 22, 2019 at 11:15 AM Stephen Farrell wrote: > > > On 22/10/2019 19:10, Eric Rescorla wrote: > > Uh,why? > > Openness, transparency, enabling the WG to make decisions on > the list. The WG has the chance to make decisions on the list *in response to* proposals in the draft. At this stage of the draft development, I don't think it's problematic for authors to put proposals in a draft with the understanding that they are proposals. Eventually, we'll need to enter a "no changes without consensus" phase, but I don't think it's at all obvious that that's true yet. -Ekr --000000000000829026059583eae9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 22, 2019 at 11:15 AM Step= hen Farrell <stephen.farrel= l@cs.tcd.ie> wrote:


On 22/10/2019 19:10, Eric Rescorla wrote:
> Uh,why?

Openness, transparency, enabling the WG to make decisions on
the list.

The WG has the chance to make dec= isions on the list *in response to* proposals in the draft. At this stage o= f the draft development, I don't think it's problematic for authors= to put proposals in a draft with the understanding that they are proposals= . Eventually, we'll need to enter a "no changes without consensus&= quot; phase, but I don't think it's at all obvious that that's = true yet.

-Ekr

--000000000000829026059583eae9-- From nobody Tue Oct 22 11:29:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D91200FF for ; Tue, 22 Oct 2019 11:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 QRu6utkU74bo for ; Tue, 22 Oct 2019 11:29:02 -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 3468C1200B9 for ; Tue, 22 Oct 2019 11:29:02 -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 x9MIN9Jw000459; Tue, 22 Oct 2019 19:26:56 +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=jV3uY4JIDawQJoNIa4yInFcOTQD57C0ZMPX59kE/eKw=; b=EPfG7Bjm303nANYA4Ltgw5ZSmnWMehAC2xMSrG+rXNcm7lRl3vY6ubVbdRBkE+9Xc77E r8+9MVzOIUt1cg35YPZ8LcAtPJ4gaG389u+F59SFhPBEHEZvr0bDARs5vUOGpFno4pu2 CVgQ3cYjchSh1V+WvE9BcCFnGhWf+3lyzSILNTtZa+Zhy0+CP7lcixDp1ehuMV7n+qP7 S7AAPlm09IsALYXcTdYYAYcL4g1LVXfI8S8KOeBoqC02NdK/aPU+9rs/L3/KyXxGCLON OVu4cjUP4S/wHY1bp7JGlZkYJ3rKP6l1IeYc1QmgtYOWfmNPRFdk9q5WhMNRF9LaE1fS Wg== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vqt4uyaeq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 19:26:56 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9MII8ri016669; Tue, 22 Oct 2019 14:26:55 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint7.akamai.com with ESMTP id 2vqwu1x382-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 14:26:52 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Oct 2019 14:26:50 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 22 Oct 2019 14:26:50 -0400 From: "Salz, Rich" To: Eric Rescorla , Stephen Farrell CC: Rob Sayre , "TLS@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-esni feedback Thread-Index: AQHVh48Xcu8AFw12IkSiVjKLPouzoadlVIKAgAAYE4CAAAJ1AIAABCaAgAAeVgCAABO4AIAAA+OAgAAJKICAAAV3gIAAAoUAgAABPQCAAAKMgIAAhyYAgABSCwCAAG5ZgIAAAvSAgAAVAoD//8NLAIAAVSqAgAAF5ACAAAFZgIAAAoAA//+9rAA= Date: Tue, 22 Oct 2019 18:26:49 +0000 Message-ID: <850CD4D6-54EC-4363-B025-5D6A6A1BE857@akamai.com> References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@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/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.15] Content-Type: multipart/alternative; boundary="_000_850CD4D654EC4363B0255D6A6A1BE857akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-22_03:, , 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=920 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910220151 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-22_03:2019-10-22,2019-10-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=907 lowpriorityscore=0 phishscore=0 malwarescore=0 adultscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 spamscore=0 suspectscore=0 impostorscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910220152 Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:29:04 -0000 --_000_850CD4D654EC4363B0255D6A6A1BE857akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZSwgaXTigJlzIGFsbG93ZWQgdG8gd29yayB0aGlzIHdheS4NCg0KTm90IHN1cmUsIHNpbmNl IHRoZXJlIGlzIHZlcnkgYWN0aXZlIGRpc2N1c3Npb24gZ29pbmcgb24gaW4gdGhlIFdHIGVtYWls IHJpZ2h0IG5vdywgdGhhdCBpdCBpcyB0aGUgYmVzdCB3YXkuDQoNCk5vdCBldmVyeXRoaW5nIGlz IGFsd2F5cyBkb25lIHRoZSBiZXN0IHdheS4gIEJ1dCBtYXliZSB3ZSBjYW4gYWxsIHRyeSBoYXJk ZXI/DQoNCiAgICAgICAgICAgICAgICAvciQNCg0K --_000_850CD4D654EC4363B0255D6A6A1BE857akamaicom_ 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 IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlN1cmUsIGl04oCZcyBhbGxvd2VkIHRvIHdvcmsgdGhpcyB3YXkuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk5vdCBzdXJlLCBzaW5jZSB0aGVyZSBpcyB2ZXJ5IGFjdGl2ZSBkaXNj dXNzaW9uIGdvaW5nIG9uIGluIHRoZSBXRyBlbWFpbCByaWdodCBub3csIHRoYXQgaXQgaXMgdGhl IGJlc3Qgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgZXZlcnl0aGluZyBpcyBhbHdh eXMgZG9uZSB0aGUgYmVzdCB3YXkuJm5ic3A7IEJ1dCBtYXliZSB3ZSBjYW4gYWxsIHRyeSBoYXJk ZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAvciQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_850CD4D654EC4363B0255D6A6A1BE857akamaicom_-- From nobody Tue Oct 22 11:29:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604F61208FA for ; Tue, 22 Oct 2019 11:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 i6gVO_nT4gEu for ; Tue, 22 Oct 2019 11:29:07 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C22E012020A for ; Tue, 22 Oct 2019 11:29:07 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id w12so21632841iol.11 for ; Tue, 22 Oct 2019 11:29:07 -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=HnLnEYROZEayFt27p3Afaztkt+3E8wr3gnRi6rzSadQ=; b=hPQ4CBYLlwSSlxCj4fDMXu5HSvZLeVcVFoOr1HcZBEIveK/ytwqgTcIEMR+lSbdgxm qTXeSFNmDFzGVPI7Rc2/YfZK+wjB4cOa8Z4Dde8qrAZwm8qSdg7BVVbxq18Nu6tLX8M8 VjuIGzGX3x8kjR457uGLOOYmicH+RaV1i60DcpRA+6eyATgplFDQlzSZmOYaWNg/AYPw Yez1lK50w9KL3nkNVn7+zSK/yeixdAP0Wt62ytpb9w+n8QMvMtLbpeJw233f3o3gMBlo TMxzHyX/IRyFmtecQKb4wRoDc00xVSohjM0kPNnm4EoiFtV0mHigTIvvKV6tfsA4dJ3b hpBg== 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=HnLnEYROZEayFt27p3Afaztkt+3E8wr3gnRi6rzSadQ=; b=KKZ9C5et9WM7LPUnbiBYgcYI/WBohxAA/lIGtuiRYmBb1yhp0G33T3DpYAfXgxzVcX fWVsij/SUl3UOxc3yF+H57eTNbG6mfs3sZx+D4A186n1vUw8ogtOGE24JSWtjMLFowXy N45E8NR6LLQhyTUTu8tlrIulLT/6rMmd2iSXkxqCdiU0Vwq34FVNJpYFr0JMAk5Z/DLl 71O6uJWhXN2pGM+B0U1IMH+FZ1zCXj7lQEm7DNajYfeBlCidMFSZvEZd6MjxKVe9SCzQ 9J/5WBfkkB38+ChlaQ5SKYUkNughLxs8HjrhiAIwY5X60tWON4DjdUVfJrEvJTVUfw2L pLJw== X-Gm-Message-State: APjAAAWWO0oa/XtqVGDuMgcA8CWn6vDR2Xivyw70UzBIT+Esc5F0lv3D N17X6xF2e411wUPK6vhWsAnbeK2Ewbk2ygxl/qk= X-Google-Smtp-Source: APXvYqw3ENiafEYfab5tsMNSjg+TYFXihO5AQfpsxvz4LT/So8KyHfqWub5HgJ+o+W31T2Lo9GsYlJfjBWhXz+D/sAk= X-Received: by 2002:a02:c646:: with SMTP id k6mr5273760jan.53.1571768946854; Tue, 22 Oct 2019 11:29:06 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 22 Oct 2019 11:28:55 -0700 Message-ID: To: Eric Rescorla Cc: "Salz, Rich" , Stephen Farrell , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf10e3059583f920" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:29:14 -0000 --000000000000bf10e3059583f920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2019 at 11:24 AM Eric Rescorla wrote: > > > On Tue, Oct 22, 2019 at 11:15 AM Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> >> On 22/10/2019 19:10, Eric Rescorla wrote: >> > Uh,why? >> >> Openness, transparency, enabling the WG to make decisions on >> the list. > > > The WG has the chance to make decisions on the list *in response to* > proposals in the draft. At this stage of the draft development, I don't > think it's problematic for authors to put proposals in a draft with the > understanding that they are proposals. Eventually... > This seems fine to me, fwiw. It was a little weird to hear about the decision in this way, but that kind of thing is always happening behind the scenes. :) It seems to me that the client is in the best position to set the padding, so I=E2=80=99m not sure why there is anything in the DNS record. thanks, Rob --000000000000bf10e3059583f920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 22, 2019 at 11:24 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Oct 22, 201= 9 at 11:15 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 22/10/2019 19:10, Eric Rescorla wrote:
> Uh,why?

Openness, transparency, enabling the WG to make decisions on
the list.

The WG has the chance to make dec= isions on the list *in response to* proposals in the draft. At this stage o= f the draft development, I don't think it's problematic for authors= to put proposals in a draft with the understanding that they are proposals= . Eventually...

<= div dir=3D"auto">This seems fine to me, fwiw. It was a little weird to hear= about the decision in this way, but that kind of thing is always happening= behind the scenes. :)

I= t seems to me that the client is in the best position to set the padding, s= o I=E2=80=99m not sure why there is anything in the DNS record.=C2=A0
=

thanks,
Rob
--000000000000bf10e3059583f920-- From nobody Tue Oct 22 11:42:11 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E390120812 for ; Tue, 22 Oct 2019 11:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amBWE0uUG46Z for ; Tue, 22 Oct 2019 11:42:08 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7DD12090D for ; Tue, 22 Oct 2019 11:42:07 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q64so18279378ljb.12 for ; Tue, 22 Oct 2019 11:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Xd//4wFrSjpF7mBAP28Iv8zMAZlahJjAv09A3MKv4U=; b=T8yeHw4NjEzJwrMpjoGdUtnn9jAJ6oo5Adz7zvMcz0sFjp7E77CIhh+uhqUaiMkRXt Hc59CKkHp5SZEMBiHUAbQRZW6p+7KrZR4vVSElmt6W1AzN+z9CpsYEFCx/4gjvR/Rpgv 8qg+ocp1KdO0KOyKKIRtrZ3nZLeEFIvdkN1Zn+CD1r+RLw2lKMDojVPGdeaj+x71LGKl K0EClL8RcXXRpIfEPpzMasf6uNSC2rBoqmBDt/oCJ5J8R/+yfRQNXau/IcWr0skLWeWS UMfnmbt3sQsfSYrM/70O6droyUBgTow5sFD1udthZ/CTHwSc9Yu948ObmTBABQpKJ97D Ckdw== 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=0Xd//4wFrSjpF7mBAP28Iv8zMAZlahJjAv09A3MKv4U=; b=c1QBBvKljWSLO1Ao9XuIUY656gA9hvNHwK3rWREcS2kCMHcaewfj6L6tSiDuoo7eNI wFvRpS//787d1Do6rIj06vL+4aQQMxadoYkHRKUVW+fV9Y4MifjS6BEzDHF+okGU6gQT lES5q2ibs+rllX/dm9Aiqt/johIxtZMLPhEI2YugnlxV95sP1QBFfMKyqONn5Kqw0dgk 7W3EHKQfYgill6uBQQOpt3FoA9Thh4dBifxrjtlRx4fGf25HaUF0j1I8KUYevAOgNi2m q4XtR9edZdIveCxKjeDI/wxmtRy0uLBwMTMhmuYum/zFHa4Bp+XspLRteuDPXzMHs7wd v4Ug== X-Gm-Message-State: APjAAAXd8dQGSKEyRNwbVj5axyYJtahbdqX3lr8lwE6KjAByJnr1jleg U5+qolot3W20tJXOjWpu+0z1DzssbwRiePqWDEUDAQ== X-Google-Smtp-Source: APXvYqxB/crrohiF2ydHFCUTB0Kl86YAfMOt/AHaklyYr0h8UvD4yhTljIuTh1m3tS7ytCUBB84DMmIBpTs0kR2w+MQ= X-Received: by 2002:a2e:8310:: with SMTP id a16mr20117262ljh.48.1571769725716; Tue, 22 Oct 2019 11:42:05 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> <850CD4D6-54EC-4363-B025-5D6A6A1BE857@akamai.com> In-Reply-To: <850CD4D6-54EC-4363-B025-5D6A6A1BE857@akamai.com> From: Eric Rescorla Date: Tue, 22 Oct 2019 11:41:29 -0700 Message-ID: To: "Salz, Rich" Cc: Stephen Farrell , Rob Sayre , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b9f390595842849" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:42:09 -0000 --0000000000002b9f390595842849 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2019 at 11:30 AM Salz, Rich wrote: > Sure, it=E2=80=99s allowed to work this way. > > > > Not sure, since there is very active discussion going on in the WG email > right now, that it is the best way. > > > > Not everything is always done the best way. But maybe we can all try > harder? > Well, I don't think it *is* being done quite that way. The last commit to the draft was August 9, so I would expect the author team to take the discussion here into account. -Ekr > > /r$ > > > --0000000000002b9f390595842849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 22, 2019 at 11:30 AM Salz= , Rich <rsalz@akamai.com> wro= te:

Sure, it=E2=80=99s allowed to work this way.<= u>

=C2=A0

Not sure, since there is very active discussion goin= g on in the WG email right now, that it is the best way.

=C2=A0

Not everything is always done the best way.=C2=A0 Bu= t maybe we can all try harder?


<= div>Well, I don't think it *is* being done quite that way. The last com= mit to the draft was August 9, so I would expect the author team to take th= e discussion here into account.

-Ekr

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /r$

=C2=A0

--0000000000002b9f390595842849-- From nobody Tue Oct 22 11:45:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686E4120918 for ; Tue, 22 Oct 2019 11:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 KAPufTjGECID for ; Tue, 22 Oct 2019 11:45:04 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185E0120924 for ; Tue, 22 Oct 2019 11:45:03 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id d83so7957150ilk.7 for ; Tue, 22 Oct 2019 11:45:03 -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=qnGAX3Wq8Tt/4wgL29ze8s56S5o9CwsP5bwdSMlxVQ8=; b=lrYkXzSO+gQQByQDEPZYkGQf0fp6ZB6eRFk69ZIO/Ldj8ZAM2Al2iLMvjBCuOC7YSY LhiJMbOlKeFkBVrfe82Lu7KUdpZBssAHweqvZUy8l1jbkrniAMGpWdyqt0+aIUcjmHa3 s+0YH0M2R9yDZhGiMZWpQy+bF8Z8uQYEodZHSHjBbnZQLfrAMGbnaN6bnHnVDOEYo/9r MsprSM6P37r3gOz7LTCVS2Xz135ob7xSHZ+XbPGoPD7GQ5MmCQc9v3NWKyc3xCLnLVH6 Gq/dva+lK3D+jLrLKxXGJapHAbW8n1m8XOLHqPf7i8FDnEPVJQIWjhCsmft2xl77Abyh Yukw== 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=qnGAX3Wq8Tt/4wgL29ze8s56S5o9CwsP5bwdSMlxVQ8=; b=OMpV0UaTfKyTRMg4iTN5zc6Jz27D0WO8pofQxqPwvDEEG37xlBAE56uwzCwELc/UNz tsQTIi03WKe0ICIj6cOAyF40NuzA8ZqTc/W629i9/XJJkgjlGbSsgZ0/tmFGvbOhejSw tx8MbPM4N4Khwj1ZU7nW3kei26gPwVSaP8hoCBtuLb3UQTGQaBY/f04u6BnaKUKLUC2j JCKZMtW1vopqXMs0DKl6ZZ9kpA/Ia8vUoKDVT4iBC3rSDHou/IUDBxiw8ynbCnrHU5GE ajVP4SRuoi9nBUckX/9EwMAehMV+TGyWrYRKCIPl672v/wFAo5GTnZdM7ond7HB9bULj mebg== X-Gm-Message-State: APjAAAU1gEsH7f+MmFc5MvSVW476fw8qnKLnGOWBHDfjJ/NU31Oy1+Ix 1jwTSXIfvxPfe8LK0dTXOMsk97xVM6H+co9S9IL6pw== X-Google-Smtp-Source: APXvYqyekRYPiGhEZGlrdfpWZlYdhY4QsAWuU4Jp99KFa+1CtGXXLgi8G6dhmuYfDgYq5uLdGNomaHzoQ/MsedRU0GE= X-Received: by 2002:a92:ce0e:: with SMTP id b14mr1912616ilo.153.1571769902697; Tue, 22 Oct 2019 11:45:02 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> In-Reply-To: From: Ben Schwartz Date: Tue, 22 Oct 2019 14:44:50 -0400 Message-ID: To: Rob Sayre Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c3bfce059584327c" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:45:06 -0000 --000000000000c3bfce059584327c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2019 at 2:29 PM Rob Sayre wrote: > > > > On Tue, Oct 22, 2019 at 11:24 AM Eric Rescorla wrote: >> >> >> >> On Tue, Oct 22, 2019 at 11:15 AM Stephen Farrell wrote: >>> >>> >>> >>> On 22/10/2019 19:10, Eric Rescorla wrote: >>> > Uh,why? >>> >>> Openness, transparency, enabling the WG to make decisions on >>> the list. >> >> >> The WG has the chance to make decisions on the list *in response to* pro= posals in the draft. At this stage of the draft development, I don't think = it's problematic for authors to put proposals in a draft with the understan= ding that they are proposals.. Eventually... > > > This seems fine to me, fwiw. It was a little weird to hear about the deci= sion in this way, but that kind of thing is always happening behind the sce= nes. :) > > It seems to me that the client is in the best position to set the padding= , so I=E2=80=99m not sure why there is anything in the DNS record. Strongly disagree. If one IP address hosts two domains, short.example and longlonglonglonglonglonglonglong.example, a client of short.example has no SNI privacy unless they pad up to the length of the longer name. The client can't know to do this unless the DNS record says so. > > thanks, > Rob > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --000000000000c3bfce059584327c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBD7BnXfqckJZOzNJ/w0d/8 e5sWyA3VXT3qy1m5p3b7IjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMjIxODQ1MDNaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAUJWuDk9w091iLhfi29Bt3rtX/NA7oB/WxzIYM+H+ 3zo6te9+EZkXAgMDErEzeoQepmy31lkYRHsxysDDuCWOlhgA4f7O7GWdd1tfbfhmKDK/pUpSjepz m6MGRm+os8McydLjmOSMJf2/Z4HwSnCBGTncfUaVA3jcLrfTO7eIF1zTane5ftqcFTHitMMwGpLa hXXqW1XSoXMSyah8dmswKNn7uF+Sts4i/SEMPTdY9qdG11k80XGWgUDGPSRUGjHh2C+Yj4tZPRdA CJr5vRzE9ES+tvdp9DgpFNPRBIrgQrRITbAoOkoctXEN3Dtgpl4DOKkX42/m3kazSMiDwg11lA== --000000000000c3bfce059584327c-- From nobody Tue Oct 22 11:53:09 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4B81200EC for ; Tue, 22 Oct 2019 11:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Kuu4X5YFV8Vh for ; Tue, 22 Oct 2019 11:53:05 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8441200B1 for ; Tue, 22 Oct 2019 11:53:05 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id q1so21796909ion.1 for ; Tue, 22 Oct 2019 11:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HNeiwrfTELksTb6GLIQV+69a0cUFU4CHxtdLRZ+jmVg=; b=TDE2q8PB6WZfZpQd1wAwyjR/n+3ghvjyQ18nOAqy4wQ6Z9NJXSeBnoGqjwiOZTUYPt VXmeos4ScRWeKedFANak02yFiZDmnKJ8zt19C3ZGpc9rUYesSELjC7zdu7K8du1UAzY5 CMj67Q5DCChD2FL6zWyIX/OgXNmq4u+1EPPsUOdihcTKTj8nHYsScDys14rq5IDqO0cN +hN8I4aabLRFOh84pW5/EAD5dAKE7/u7Af6LGwpGGQ8ypt6d6u02WcEegl8uJ2S0usZL iZ5KxzchjN8Jcp36+5pRAd3NU0YzroqoL4bMLbN6gDKsFJ+0tIFW1uU9fgYE3561H10I H0Eg== 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=HNeiwrfTELksTb6GLIQV+69a0cUFU4CHxtdLRZ+jmVg=; b=PqVMaMD6jWRiS/A2o/V8P155+q0fkJAoByFwZP6/uDkDgaldOVfmiNkzLwxmB2i8Xp xsJCICBQS6YXEDlxVSQG8him7u7WMg2MGVZNwSkNGdR0+U0PlVV4uDirj1MAe9jrFo3Z FNZA6XCLcv8TlqnTVAEkNbpdyS+F+oLrcpjjQv5915VjecY/Ij86F2IxeCrRrPG8jtKs mSsXHI4r6qF4QDQibV7kLONfCM3MXxS4DRv16B6jUdSQBYcs8JQT6+WI+P2YZBdnErEt ka6LG4bUCNZ3M54L81KshDIbaepet04t1h0HVuuS2jw52u1BuvCkXclEwNouhftsIzvQ USGg== X-Gm-Message-State: APjAAAXLtqyyI9KLUv2Jr7CGJ1afHs/e3x8RpdOdrN3eKgiyLZDMf61N 0RF9SziDcKspZHmGnjxrYQGf/pwoqbsG3ZLZYgs= X-Google-Smtp-Source: APXvYqzExZ0afmJsNzUEULV7TnFOUhvmt0fE9EVQbaYnqynX5ESFPfELyna6nHTI90qnIyJZGvovGfwKYe/KxGr4pzg= X-Received: by 2002:a02:c646:: with SMTP id k6mr5371312jan.53.1571770384330; Tue, 22 Oct 2019 11:53:04 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 22 Oct 2019 11:52:53 -0700 Message-ID: To: Ben Schwartz Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006d31e20595844f11" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:53:07 -0000 --0000000000006d31e20595844f11 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2019 at 11:45 AM Ben Schwartz wrote: > On Tue, Oct 22, 2019 at 2:29 PM Rob Sayre wrote: > > > > > > > > On Tue, Oct 22, 2019 at 11:24 AM Eric Rescorla wrote: > >> > >> > >> > >> On Tue, Oct 22, 2019 at 11:15 AM Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >>> > >>> > >>> > >>> On 22/10/2019 19:10, Eric Rescorla wrote: > >>> > Uh,why? > >>> > >>> Openness, transparency, enabling the WG to make decisions on > >>> the list. > >> > >> > >> The WG has the chance to make decisions on the list *in response to* > proposals in the draft. At this stage of the draft development, I don't > think it's problematic for authors to put proposals in a draft with the > understanding that they are proposals.. Eventually... > > > > > > This seems fine to me, fwiw. It was a little weird to hear about the > decision in this way, but that kind of thing is always happening behind t= he > scenes. :) > > > > It seems to me that the client is in the best position to set the > padding, so I=E2=80=99m not sure why there is anything in the DNS record. > > Strongly disagree. If one IP address hosts two domains, short.example > and longlonglonglonglonglonglonglong.example, a client of > short.example has no SNI privacy unless they pad up to the length of > the longer name. The client can't know to do this unless the DNS > record says so. Well, I am not sure we are disagreeing so strongly. I want to pad everything up to 260 since the ClientHello will still fit in one packet. I think it would be ok to send a minimum length in the DNS record. thanks, Rob --0000000000006d31e20595844f11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Oct 22, 2019 at 11:45 AM Ben Schwartz <bemasc@google.com> wrote:
On Tue, Oct 22, 2019 at 2:29 PM Rob Sayre <<= a href=3D"mailto:sayrer@gmail.com" target=3D"_blank">sayrer@gmail.com&g= t; wrote:
>
>
>
> On Tue, Oct 22, 2019 at 11:24 AM Eric Rescorla <ekr@rtfm.com> wrote:
>>
>>
>>
>> On Tue, Oct 22, 2019 at 11:15 AM Stephen Farrell <stephen.farrell@cs.tcd.ie= > wrote:
>>>
>>>
>>>
>>> On 22/10/2019 19:10, Eric Rescorla wrote:
>>> > Uh,why?
>>>
>>> Openness, transparency, enabling the WG to make decisions on >>> the list.
>>
>>
>> The WG has the chance to make decisions on the list *in response t= o* proposals in the draft. At this stage of the draft development, I don= 9;t think it's problematic for authors to put proposals in a draft with= the understanding that they are proposals.. Eventually...
>
>
> This seems fine to me, fwiw. It was a little weird to hear about the d= ecision in this way, but that kind of thing is always happening behind the = scenes. :)
>
> It seems to me that the client is in the best position to set the padd= ing, so I=E2=80=99m not sure why there is anything in the DNS record.

Strongly disagree.=C2=A0 If one IP address hosts two domains, short.example=
and longlonglonglonglonglonglonglong.example, a client of
short.example has no SNI privacy unless they pad up to the length of
the longer name.=C2=A0 The client can't know to do this unless the DNS<= br> record says so.

W= ell, I am not sure we are disagreeing so strongly. I want to pad everything= up to 260 since the ClientHello will still fit in one packet. I think it w= ould be ok to send a minimum length in the DNS record.

thanks,
Rob

<= /div> --0000000000006d31e20595844f11-- From nobody Tue Oct 22 11:55:36 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA91208E3 for ; Tue, 22 Oct 2019 11:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IX9vBHqe4pqI for ; Tue, 22 Oct 2019 11:55:27 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 BE9C912020A for ; Tue, 22 Oct 2019 11:55:26 -0700 (PDT) Received: from xse497.mail2web.com ([66.113.197.243] helo=xse.mail2web.com) by mx148.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iMzJN-0008d2-Fn for tls@ietf.org; Tue, 22 Oct 2019 20:55:24 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 46yN426MMbz1y8c for ; Tue, 22 Oct 2019 11:55:14 -0700 (PDT) Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iMzJK-0003Is-OV for tls@ietf.org; Tue, 22 Oct 2019 11:55:14 -0700 Received: (qmail 1286 invoked from network); 22 Oct 2019 18:55:14 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.199]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Oct 2019 18:55:14 -0000 To: Stephen Farrell , "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 22 Oct 2019 11:55:02 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hiVrwPkw9YX8saSis37sCGgccx3lyEzWX" X-Originating-IP: 66.113.197.243 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: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0QRKNbAP+Q7R/EWH3Kru/cipSDasLI4SayDByyq9LIhV/nepSH6+EXuB iy03jAubAkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4YjjSclGZ1YxPwRfn9LaKqHgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+fyO3R7+MmLKUvLY+RGMRrtPM2DmctUkuqITdPZ8a3LuY6jSvfpO+1kZkomjtjB6X7/nuj3 koRhn2BlE7dXoT0pGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbuhdxf5Dwg9wMBX5ckCo48ayVGvgdM/14NhEhsQ0jllqEE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ileOfMnQTuxRu w7b3K/aRb5jEMDQiNsTxs76hah9Uw3RGlv5DlRrbnUN65t1TkEc2WEIbgxh442xxB+jk8FmuUvx8 g2fGU86cSswil+kDetUfttbLHdNhiUq2jBEvMVLlZ4GThCScvU0cCIiHSQbmcVIqhqtz6FB8nX1I B7lRlsAaN+qh3YF7t/lvtNmPz3Nh3rn58MR7IcF4VudkTz3DtjUMABrRFJiSr1elhs1Dwe10XPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdgjWXUH3Ex48jMGHWNtGfR91vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine9.antispamcloud.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 18:55:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hiVrwPkw9YX8saSis37sCGgccx3lyEzWX Content-Type: multipart/mixed; boundary="GWoA1uIu4ci9zPYseGYWsBJnNU9XBbb7k"; protected-headers="v1" From: Christian Huitema To: Stephen Farrell , "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" Message-ID: Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: --GWoA1uIu4ci9zPYseGYWsBJnNU9XBbb7k Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 10/22/2019 10:49 AM, Stephen Farrell wrote: > > On 22/10/2019 17:44, Salz, Rich wrote: >> I think varying padding to some fixed multiple is a good trade-off. > Me too. I'd go for multiples of 32 octets, with a SHOULD > to add an extra block or two randomly, but anything of > that kind should work. Stephen, do you have some statistical analysis to back your "should work" assertion? I say that because DKG performed that analysis for the padding of DNS messages (https://dns.cmrg.net/ndss2017-dprive-empirical-DNS-traffic-size.pdf). The results were non trivial. In particular, the analysis showed that random padding was not a good way to achieve privacy. If there is only little randomness, the attacker that observes multiple transactions transactions can see through the randomness. If there is a lot of randomness, then the padding policy causes a lot of overhead, which made that policy less efficient than padding to fixed size blocks. That study was the basis for the recommended encrypted DNS padding strategy in RFC 8467.=C2=A0 I do not claim that statistics on the DNS directly inform ESNI padding strategies, but I would say that in the absence of better analysis we should heed DKG's recommendations for now -- and the recommendation of padding to 260 does that. I would of course be happy to change my opinion once we have an ESNI specific study. -- Christian Huitema --GWoA1uIu4ci9zPYseGYWsBJnNU9XBbb7k-- --hiVrwPkw9YX8saSis37sCGgccx3lyEzWX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEzw9TMGad0+xb0f/tttrTkhQ4dVAFAl2vUJQACgkQttrTkhQ4 dVC8gAf7B07F+h+jwvdpdLHJiTwSWMoWatZrta5CgKnNYIbBuAZLXjOkct9Pkgwd s34shMGZ/lI/FdY6pJCLiKXAPa3Dx4KjA5XusMcsBkmznTpPF/dWmPdy8pNJjU7B iekqNvJTQqW3DvcyrDxRNCfnaULh1pfJJGQmRaKOxL3sUD7ZBJ6xMhtM1Iz9dGkj fRuVnKs45Z9r15xdT7Zn3/3aRKDiV5gc8VEM1U5mujWSU0Wg8UZwNr60rX2CKE82 uNeORWGFbV9o6CchPfzuepLQlnho1FbPtaga2g+wJl3VgyzJUqmVwNLorZD5oWA5 QvJ3NLxiltO/Lt9j0Db4346nHt+Fgw== =rN7n -----END PGP SIGNATURE----- --hiVrwPkw9YX8saSis37sCGgccx3lyEzWX-- From nobody Tue Oct 22 12:02:28 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD351208F1 for ; Tue, 22 Oct 2019 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 lQJZx38MWkZE for ; Tue, 22 Oct 2019 12:02:24 -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 7E42E12082F for ; Tue, 22 Oct 2019 12:02:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 489A2BE4C; Tue, 22 Oct 2019 20:02:21 +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 k6pUE_T2rpz3; Tue, 22 Oct 2019 20:02:19 +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 85C80BE47; Tue, 22 Oct 2019 20:02:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571770939; bh=GCmv5uldjREbvXzfHMUyGpl3Z+C4mE+XfIpFYcxyK7M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mUTbsctYz2LJhbT33JhOXsFHjROHb35czYrnSdQv40UF+Kdb71lsGA8hCZ2LFjBee e5idqiRPRVroRB9BZL6X2H7i0YFGliHGidEh02cOiAuAqiHsizsUSFb5OpuPr3hyVA FStzZnRjaFMPnwpzdqnV1TBDX20OnFINg3SN+pDo= To: Christian Huitema , "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <083895f3-ac72-dc3d-9511-1dd05300ffe1@cs.tcd.ie> Date: Tue, 22 Oct 2019 20:02:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oX3Pii6Awi8XPWWQl9we6Gb6BIMGz2Ocb" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 19:02:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oX3Pii6Awi8XPWWQl9we6Gb6BIMGz2Ocb Content-Type: multipart/mixed; boundary="cNrsJrSqNJtF2kO9zB0O3za3KdaMQxf5H"; protected-headers="v1" From: Stephen Farrell To: Christian Huitema , "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" Message-ID: <083895f3-ac72-dc3d-9511-1dd05300ffe1@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: --cNrsJrSqNJtF2kO9zB0O3za3KdaMQxf5H Content-Type: multipart/mixed; boundary="------------D5652B7274EA42CF0AF0428E" Content-Language: en-GB This is a multi-part message in MIME format. --------------D5652B7274EA42CF0AF0428E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 22/10/2019 19:55, Christian Huitema wrote: > In particular, the analysis showed that > random padding was not a good way to achieve privacy.=20 Sure. But I'm not suggesting the kind of random padding that was under discussion then. My suggestion was to pad to a multiple of 32 octets and with a random addition of 0,1,2... or more 32 octet blocks of zeros. Yes, some work would be needed to pick the right block size (32 might be a little small maybe) and to pick a (non-uniform) distribution from which to randomly select how many additional blocks to send. But like I said, I'm sure there're lots of different algorithms that could work for this, and whichever we picked would need some checking vs. reality of course. Cheers, S. --------------D5652B7274EA42CF0AF0428E 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----- --------------D5652B7274EA42CF0AF0428E-- --cNrsJrSqNJtF2kO9zB0O3za3KdaMQxf5H-- --oX3Pii6Awi8XPWWQl9we6Gb6BIMGz2Ocb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2vUikACgkQWrL68XsX K+qTaw//bwc2oYterUM6ss7ksA2FaBNWzJHqfvAKGYpELbbywFsZrrFrsWDR4gmL 5Ijd9tnzK8d5qGbL1LJGYXtbDfp9AgkzeanZukOQ3mSSj68PpjTbWmTeZjfk/l8E MwgbauWPVP1Q8ghpsd2GLBctgVUoPzthsij0UoP9UZgNSxwG2OnpAFyf0ksyhmMM 01XZnPWuXwkuGAqYN0syYJsYJm5fjjnsp2saYHgt01t81JTypYTVz+mb8mE+tWer RGuY7j9QKNaSUYmMDVKnlFCUJuv3UBZFamYndEae3QgdqLnln8Plt/SkOiemRLSa 4uqfQ4iqdJn71swPrWk6ZpaelWd2BYz6dp5JGZnZC6N1Is01dclyfwoa5+D5Yvhx NrinWY7gomuOBO0Xizi4ZMaoDK6BTb09pt+5ZDv0LNRvxsG+fZy0GAPJuthK79kq /K2b/bwg8C3vVv2QD2Y8puaO1VUaeIerOM3xo2MDeIbS3L1d709yq8kM0+zar8Wy WfFfQTcPKwYnA+nnnGPQuY4nJ07lt6lP7q9Izu6YCusw09qY4/6Mb5WtOmjdpgfy gvHJFASxfte2f/o+1u1AhPLDxPpA4WpCeFlKV8ldeiXyY0P2Q7eNcD2Hf1WFSsZi u+HpBJRwgjkAOaNj3vp6xHGCn/1ifQYTxgSvQDAPLY9DQHGZo5U= =dSFF -----END PGP SIGNATURE----- --oX3Pii6Awi8XPWWQl9we6Gb6BIMGz2Ocb-- From nobody Tue Oct 22 14:00:23 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4225D1200F3 for ; Tue, 22 Oct 2019 14:00:22 -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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 veYftao4WG2m for ; Tue, 22 Oct 2019 14:00:20 -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 84776120077 for ; Tue, 22 Oct 2019 14:00:20 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id p8so7093624ilp.2 for ; Tue, 22 Oct 2019 14:00:20 -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=pzA07LAMI4rwifYC7OZzBISEAKQBvKFybJNuSrtn3WM=; b=a4yqLDPLOQEPUtvkXNP6i77F7vjfe/7wVt7zcHDD2P195bJ/qKwPhkF3ebxN6M5y02 zKqga5/iSlc24p8QgZH54Bub1f9V9OHKE8ntvXChp2x3n/rKiOGJQqiukbZR/v3Mnvog Hb+HXKJuI8WQTCnv1ifsri+S+NuX+1SHtXk0PmEH2qRuKh5U0lgWxmw+xicQJcT67tHO 4kh+jW0ji055xS0xuDpIOCPC3L2IeB0t07s328Vzpbo+vGCkuR92fDuMcqu4blzCXrCO t0O1U+IhtdLXHw3VxONNcPJiheL1AFQKoULQUXogXu45FWHwIBGZqVNh2D/uNdNVNayp /pWQ== 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=pzA07LAMI4rwifYC7OZzBISEAKQBvKFybJNuSrtn3WM=; b=kFbdW4FCVC830ujY9GNcLFObeNbnGgRUwzKEBuKijG/lUoZQ8A7iNzXvjso0GBKM77 FxgL0eBbnOs2+0NS4i6Svmjogx3fNvGAjTh0vfPWBXuNKBvkoBr4nqBVFtDjja/iqWZY NCZ4YijTNNchzMwRhGm6ZBqDug3NKa+hysP6uU/pq/TnERGmsZqQfEqYnfipROYQU3u8 zRcdQuN9/ME5eA2aA1hjrMoEN0nY5xyqnCNKIMxKTmwEeEoTdDD5x6WJJCoTBfGPjN0A AxYlJI+6J0Qj9wbXbpr1UJcfi3HniyDCYelbEfCR347Odeltk5PLhg6xnG75J24Qyb7C 9+qQ== X-Gm-Message-State: APjAAAXQMgeCmF6fn9ancS2BtWWhjbHyb/upYGYZkYxFVW6wWcZn2jWH PYI4wszHFfGqTM1NuGwjgRml6+yL3+DfCaO6HGwOT61FIN3E/g== X-Google-Smtp-Source: APXvYqwoEbiJeCR9R1UsuELYCuB/gw1+yc/8iLhnVOIhELXmj78qj5Ku6H2aLP9yXHR7fc0KsTg9H0Ll4OGxwoA3zXk= X-Received: by 2002:a92:48cf:: with SMTP id j76mr14437991ilg.189.1571778019625; Tue, 22 Oct 2019 14:00:19 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <120231f6-698c-03c0-824e-0077b85b6439@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 22 Oct 2019 14:00:08 -0700 Message-ID: To: Ben Schwartz Cc: Eric Rescorla , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008691860595861652" Archived-At: Subject: [TLS] ESNI padding X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 22 Oct 2019 21:00:22 -0000 --0000000000008691860595861652 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I thought this discussion was important enough to surface with a new topic. I can see why the server might need to set a minimum in the DNS record, but I find it likely irrelevant, since I intend to effectively max out the padding allowed within a packet. thanks, Rob On Tue, Oct 22, 2019 at 11:52 AM Rob Sayre wrote: > On Tue, Oct 22, 2019 at 11:45 AM Ben Schwartz wrote: > >> On Tue, Oct 22, 2019 at 2:29 PM Rob Sayre wrote: >> > It seems to me that the client is in the best position to set the >> padding, so I=E2=80=99m not sure why there is anything in the DNS record= . >> >> Strongly disagree. If one IP address hosts two domains, short.example >> and longlonglonglonglonglonglonglong.example, a client of >> short.example has no SNI privacy unless they pad up to the length of >> the longer name. The client can't know to do this unless the DNS >> record says so. > > > Well, I am not sure we are disagreeing so strongly. I want to pad > everything up to 260 since the ClientHello will still fit in one packet. = I > think it would be ok to send a minimum length in the DNS record. > >> --0000000000008691860595861652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I thought this discussion was important enough to sur= face with a new topic.

I can see why the server mi= ght need to set a minimum in the DNS record, but I find it likely irrelevan= t, since I intend to effectively max out the padding allowed within a packe= t.

thanks,
Rob

On Tue, Oct 22, 2019 at 11= :52 AM Rob Sayre <sayrer@gmail.com> wrote:
<= div class=3D"gmail_quote">
On Tue, Oct= 22, 2019 at 11:45 AM Ben Schwartz <bemasc@google.com> wrote:
On Tue, Oct 22, 2019 at 2:29 PM Rob Say= re <sayrer@gmail.c= om> wrote:
> It seems to me that the client is in the best position to set the padd= ing, so I=E2=80=99m not sure why there is anything in the DNS record.

Strongly disagree.=C2=A0 If one IP address hosts two domains, short.example=
and longlonglonglonglonglonglonglong.example, a client of
short.example has no SNI privacy unless they pad up to the length of
the longer name.=C2=A0 The client can't know to do this unless the DNS<= br> record says so.

W= ell, I am not sure we are disagreeing so strongly. I want to pad everything= up to 260 since the ClientHello will still fit in one packet. I think it w= ould be ok to send a minimum length in the DNS record.
--0000000000008691860595861652-- From nobody Tue Oct 22 18:30:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B965C1200CD for ; Tue, 22 Oct 2019 18:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 I093-2FzcKB7 for ; Tue, 22 Oct 2019 18:30:27 -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 6E816120026 for ; Tue, 22 Oct 2019 18:30:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 43DE4BE47; Wed, 23 Oct 2019 02:30:23 +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 XqAycyPZyKHQ; Wed, 23 Oct 2019 02:30:21 +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 4C777BE39; Wed, 23 Oct 2019 02:30:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571794221; bh=LkxgwuqOU02CLj9Bwu92sw55D2tFYIwAPxonTDFPjvE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=WVh2wYsNjMH3ePH45Qm2xvw9C3hm6BDBJAfYHmOLWmwMrjbpm1Orl2HqpG52AvmJN FlX/Bo29vh1QkV9SlwHDQYMfhsY/fCRBcS53Qqgfoy8zYcH4Y9bRV0MfkdQNBvs6si dOG7J7TmFAfI0uZdSO0tySTX/iXu0Se/edO2NLuc= To: "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> Date: Wed, 23 Oct 2019 02:30:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="g6iO0Kj3rZzffb9LFdsVbBpeN9iw6VsK9" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 01:30:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --g6iO0Kj3rZzffb9LFdsVbBpeN9iw6VsK9 Content-Type: multipart/mixed; boundary="O3QWoJqPRBiyoDqNcPakLEqrwJWMHrm7w"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Rob Sayre Cc: "TLS@ietf.org" Message-ID: <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> In-Reply-To: --O3QWoJqPRBiyoDqNcPakLEqrwJWMHrm7w Content-Type: multipart/mixed; boundary="------------3387E864890AAF7728BAC4C0" Content-Language: en-GB This is a multi-part message in MIME format. --------------3387E864890AAF7728BAC4C0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Unstylishly quoting myself... On 22/10/2019 18:49, Stephen Farrell wrote: > Me too. I'd go for multiples of 32 octets, with a SHOULD > to add an extra block or two randomly, but anything of > that kind should work. Stylishly however, it seems I'm in the happy position to also admit I was wrong there (thanks to Christian Huitema for spelling this out to me offlist). In most cases, when using ESNI, DNS queries will need to be made for the A/AAAA and ESNIKeys (or HTTPSSSSSSSSSVC:-) and hopefully those DNS queries will also be padded. RFC8467 [1] defines a bunch of ways of doing that, and has one recommended way. While it is likely too early to say that the recommendation in RFC8467 is really a best practice, I think it is the case that padding of the DNS query and of the SNI within the ESNI extension to the CH ought be "commensurate" in the sense that observing both ought not provide more information to someone who only observes one of those. So, at minimum, that'd mean s/32/128/ in my quoted text above, and likely more. (Plus, of course, doing the kind of due-diligence that lead to [1].) Bottom line is that I think I'd modify my starting out position for what to suggest for draft-05 to be to copy (and modify as needed) what's recommended in [1] for padding the query. Cheers, S. [1] https://tools.ietf.org/html/rfc8467 --------------3387E864890AAF7728BAC4C0 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----- --------------3387E864890AAF7728BAC4C0-- --O3QWoJqPRBiyoDqNcPakLEqrwJWMHrm7w-- --g6iO0Kj3rZzffb9LFdsVbBpeN9iw6VsK9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2vrR0ACgkQWrL68XsX K+ongQ//bgo7gEckapIVss/YJWopVNZhzJIQAXoJ/abLtHpSvrT6nwQ6ePtJGa4z /f3LVqReXe854ICut4AXciQe6B48o3X2A9xdTYT6er7hi2zdzqXiukEvsUTorqZ2 fR49WiyzXnAEQiTZ1/qg+auOBMTgrEL1rURIeU194IodSvlEykutwndP2rt9OmfD u2mOkTFLXuDriVgBiAoViQg/6HXwQ77YAHS81wHjhKo1GErRyDE8HVgRtc6ujcjr xq+dpHQfa498+PpRZU0L8IvVfdCq4vVSiaonsZCpFnVJi0POvUoakZWi9+fHCuvj r62BdtSGTlLvS0LKtuzKoZ4nF0lnTKSlrGfL9pvv7g/p29aoqoUOcGg6oNIhmQRG e5/FbZS0qgjlh7ZLa5PnyMavFnRDeJnPlEPcEeFB/YsGAnmju/4CtEoxMjM1SqJh NjD2yxPg2yxRv9oQx4h2gHAyVI9/bIfLhM7vdiY3JhVqUka07TL2om5ZgyEiu3t7 nGA/VlJoIbLFl/9gg0iLhpr6VzAy9rTyjg3qlufVqiLTB8AR4vQCeDRMmGcApT26 Cw1RHUoXBElA+ilZ9daYtPzQLK9wDah240JDkx0cYf121NiALjNSTOLlnum0Ih7L B4HDNx6eeP/MdinnkDf8da6JA7/pg+c9ESlegPfE93xNkmFY8ws= =D6RK -----END PGP SIGNATURE----- --g6iO0Kj3rZzffb9LFdsVbBpeN9iw6VsK9-- From nobody Tue Oct 22 19:06:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67912024E for ; Tue, 22 Oct 2019 19:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hiSpq0AvGi6I for ; Tue, 22 Oct 2019 19:06:08 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 D466A120232 for ; Tue, 22 Oct 2019 19:06:07 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id u8so22961245iom.5 for ; Tue, 22 Oct 2019 19:06:07 -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=1+0kzFckYlLm3AR/Q8Muv4G12P0E3KUJDXP5JZfcYBI=; b=OpXnIMuNa4GrGXZv+eijhBnw5J58lImKJ1k2NscOQGQD1d04u/YIhaKC/qd1uQdcqO CyO6CTmRRGeaVPoUcvxatJW/EvDLkpJ5Sq+Vk01arPKDzyrCBSAR9crHp7A3fKrsZ+14 fN9qxR1OzefJE5riveGcvnIq7QSbD1ebrWA3yooGsNV+XwdVgY97V+fJgAe23vlQuNCL 7eTtcnaVVja7W0jDPdil/kW8gqTexfXysJBP9gKe2w9fFeKy2DaBbCBDH/H/yCu5kC+O KljGCIVPlkcls2ifHwxPXktNrIkCPL+ESHxvfsaMTAnHlXn8GysVvY9UwNzJniKZirOg xfqg== 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=1+0kzFckYlLm3AR/Q8Muv4G12P0E3KUJDXP5JZfcYBI=; b=DtqVZZhWCx1UsyitgTXF+D1S8VpJw7ZttAwH9+2xH5vhZcKD+5YoNGR5ZCf6flUIhJ pn7QZ6qqa8NUJrnYm74AMAESCwzZsesAkwv9IN4uhlWz2Ua8nkL7MYVKYeTqKocMbFTv nrmJe1ugN5Cvhr4I8Bae2jT8DyvP/BXsbnAkogdSBMW8iCuj9x8yVoR1l9QuvK/sIfwv 7ZInB4Qa7IyeB2okZjXiEyisRG9Tt1JWljGSC5FMqpGUYGVzZTCmMokxT1k0Qsp7HaHe AOjqQU6NOokMDFiOfW9fBvQvYfbJklA7afWWg16gdOKGDsJllex8LBDg71jFZCyRMN/P sdwA== X-Gm-Message-State: APjAAAWfUJoaIztmRFqYJJwcs+AQtZlh5la5LUBeP8OWPAn/cVtfdQyl CnDT34U8qlIhHOcnkCQdQ0ZYIgkWgSbp4lFQ2b7u8+4zL6A= X-Google-Smtp-Source: APXvYqyLutYncL6uEX1Qx773SanlooIVKdDtQ9u0gC8Zr0GYdmKDbspvlhlxUUdOvhvJk6X9aHBDjRS7sfe3krfKRs4= X-Received: by 2002:a05:6602:21c2:: with SMTP id c2mr871071ioc.189.1571796366934; Tue, 22 Oct 2019 19:06:06 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> In-Reply-To: <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> From: Rob Sayre Date: Tue, 22 Oct 2019 19:05:55 -0700 Message-ID: To: Stephen Farrell Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001c474605958a5ce2" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 02:06:09 -0000 --0000000000001c474605958a5ce2 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 22, 2019 at 6:30 PM Stephen Farrell wrote: > > So, at minimum, that'd mean s/32/128/ in my quoted text > above, and likely more. (Plus, of course, doing the kind > of due-diligence that lead to [1].) > Or, maybe, start at 256. :) Low numbers might encounter all sorts of well-known cryptographic problems, and varying the padding of the domain name with any granularity would tend to narrow the search space for an attacker. I'm not an expert in these matters, though. thanks, Rob --0000000000001c474605958a5ce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 22, 2019 at 6:30 PM Stephen F= arrell <stephen.farrell@cs.= tcd.ie> wrote:

So, at minimum, that'd mean s/32/128/ in my quoted text
above, and likely more. (Plus, of course, doing the kind
of due-diligence that lead to [1].)

Or,= maybe, start at 256. :)

Low numbers might encount= er all sorts of well-known cryptographic problems, and varying the padding = of the domain name with any granularity would tend to narrow the search spa= ce for an attacker.

I'm not an expert in these= matters, though.

thanks,
Rob=C2=A0
--0000000000001c474605958a5ce2-- From nobody Tue Oct 22 19:29:26 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2269E12022C for ; Tue, 22 Oct 2019 19:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=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 gQuGVrEJuvPg for ; Tue, 22 Oct 2019 19:29:22 -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 9D278120048 for ; Tue, 22 Oct 2019 19:29:22 -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 x9N2Rd0g017876; Wed, 23 Oct 2019 03:29:17 +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=MyWcU6A7g0EYMlOd1J/j14AN4csN7gPNNNBoMxrlceU=; b=P3lz6WFNmtZDGBqCZRJ/tOPBDuv5ztRW1vE7z0Qcz8zocqRObZv0WL1INWegRtx+rBR/ kaKu3Ud4ZltRGTtlUK5FhkhlEzwOeQiFHrCNFx3gA2cGPVlpeNfu6BGR26DFyJc/dNfr b87cT2TunnAFUKxFBpzFOhzl7J4xolaOtFXUmc9sfh2F0VKLAJb1FOfjQ80RLDnVnYqk SYikr3YZiaaaIaM0NpfyQk8YquAR168bnozW/CnQORB/GEDk2BZs7uCCAAF5EjuIxUlx U7YA/jYuHG3ae7goKLnxX1ZfwTvvy0pqv5OUwj081nGOE8ohEqLPjfHdeI2ry+ERp1lW Rg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2vqsr9tj2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 03:29:17 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9N2H1ni016713; Tue, 22 Oct 2019 22:29:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2vqwtwq373-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 22 Oct 2019 22:29:16 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 22 Oct 2019 22:29:15 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Tue, 22 Oct 2019 22:29:15 -0400 From: "Salz, Rich" To: Rob Sayre , Stephen Farrell CC: "TLS@ietf.org" Thread-Topic: [TLS] draft-ietf-tls-esni feedback Thread-Index: AQHVh48Xcu8AFw12IkSiVjKLPouzoadlVIKAgAAYE4CAAAJ1AIAABCaAgAAeVgCAABO4AIAAA+OAgAAJKICAAAV3gIAAAoUAgAABPQCAAAKMgIAAhyYAgABSCwCAAG5ZgIAAAvSAgAAVAoD//8NLAIAAVSqAgACAuICAAAoDgP//w3YA Date: Wed, 23 Oct 2019 02:29:14 +0000 Message-ID: References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <975963dc-f311-b806-6860-8768f4ec1a76@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/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.187] Content-Type: multipart/alternative; boundary="_000_CCF5D10776AD4311A931F0FB4D393147akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-23_01:, , 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=534 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230021 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-23_01:2019-10-22,2019-10-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 adultscore=0 phishscore=0 mlxlogscore=508 spamscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910230023 Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 02:29:24 -0000 --_000_CCF5D10776AD4311A931F0FB4D393147akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIExvdyBudW1iZXJzIG1pZ2h0IGVuY291bnRlciBhbGwgc29ydHMgb2Ygd2VsbC1r bm93biBjcnlwdG9ncmFwaGljIHByb2JsZW1zLCBhbmQgdmFyeWluZyB0aGUgcGFkZGluZyBvZiB0 aGUgZG9tYWluIG5hbWUgd2l0aCBhbnkgZ3JhbnVsYXJpdHkgd291bGQgdGVuZCB0byBuYXJyb3cg dGhlIHNlYXJjaCBzcGFjZSBmb3IgYW4gYXR0YWNrZXIuDQoNCldoYXQgd2VsbC1rbm93biBjcnlw dG9ncmFwaGljIHByb2JsZW1zPyAgVmFyeWluZyB0aGUgcGFkZGluZyBjYW4gYWxzbyAqYWRkKiBz ZWN1cml0eSBiZWNhdXNlIGZvby5zZWNyZXQuZXhhbXBsZS5jb20gY291bGQgc2hvdyB1cCB3aXRo IHR3byBkaWZmZXJlbnQgc2l6ZXMuDQo= --_000_CCF5D10776AD4311A931F0FB4D393147akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFs MCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NDExMDUzMDc7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjUxMTg5MTcwNCAxODkyODQxODIgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj5Mb3cgbnVtYmVycyBtaWdodCBlbmNvdW50ZXIgYWxsIHNvcnRzIG9mIHdlbGwta25v d24gY3J5cHRvZ3JhcGhpYyBwcm9ibGVtcywgYW5kIHZhcnlpbmcgdGhlIHBhZGRpbmcgb2YgdGhl IGRvbWFpbiBuYW1lIHdpdGggYW55IGdyYW51bGFyaXR5IHdvdWxkIHRlbmQgdG8gbmFycm93IHRo ZSBzZWFyY2ggc3BhY2UgZm9yDQogYW4gYXR0YWNrZXIuPG86cD48L286cD48L2xpPjwvdWw+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgd2VsbC1rbm93biBjcnlwdG9ncmFwaGljIHByb2Js ZW1zPyZuYnNwOyBWYXJ5aW5nIHRoZSBwYWRkaW5nIGNhbiBhbHNvICo8Yj5hZGQ8L2I+KiBzZWN1 cml0eSBiZWNhdXNlIGZvby5zZWNyZXQuZXhhbXBsZS5jb20gY291bGQgc2hvdyB1cCB3aXRoIHR3 byBkaWZmZXJlbnQgc2l6ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CCF5D10776AD4311A931F0FB4D393147akamaicom_-- From nobody Tue Oct 22 19:54:41 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767D312006D for ; Tue, 22 Oct 2019 19:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HasEl5XIUnvA for ; Tue, 22 Oct 2019 19:54:37 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0: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 9072E12004C for ; Tue, 22 Oct 2019 19:54:37 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id i12so6957110ils.6 for ; Tue, 22 Oct 2019 19:54:37 -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=SAaVNsljEuMV2o/Kj+vND8XrsD/3ijlHFN+G/NM3/JY=; b=ktAOZkYIGJoJFu5OR+6p7Ln4ZaaylYxyqQuGnb4dYK0RfnMx2a0xDfkVCeXvzV1Wv1 Gc2lQh94n4TcsRbH/I1axZMWnvZMbHvHq5UbFuhDCYIyfE1kbI8KPbtrwEUjJbxU/s/R Cuwpruf1lhGm+QX6uSTiot+rwI7uaLOXZBMpw+ZtNrKb3B3ONBKAEZoTEvP53654YAlm s6kU5WaEEM3ZKk6czfTObX4qlvlBDP2mUkb6KPvBBkYdXYwmIrAdwzRaH33hZ6eNYwE4 2QsU6TzTwf8mkPexC/tUQHSZSqqN8D6q99FVKwktvVukV+ZY/JSorsqabpEs/8sM0qol C4Tg== 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=SAaVNsljEuMV2o/Kj+vND8XrsD/3ijlHFN+G/NM3/JY=; b=pdKJydnlEFy+1y01V8/LO+1WMKw02kb5+qa59M3s4lX2F9zEoFwEGUNDiDpIIwXrNS bpQkrC3h+7RT7NPNdytPGnNz1uGUHHbUHHpWKc1+qeV9D17htoPr5VCbpKBNeFVFtcpA IkoAwoFSkAF4tFzkJ5ife77BK4vNTIN0m/GIT/v5CfcQMcA1CEMH7MO0pYpIgaH6//Di /z8pRz4P2PLcbZHOHNYjq0y+ZHTUqatxpjO07jqGA/kA0KE+e4pLD3oTPI4/gwP43ZDX /x4js8WXuptrlAy9zGhFmAcn4TaLoGu07WldSgd5fB34Yunz1/tvlhmlrAP1CGyx/ZtS 6LYQ== X-Gm-Message-State: APjAAAWqUsuUyBK3KoM/K6vw5Vp4qrpo/Ugi92tSbEOjFCv+wMQfnc7F KwD69Vlm2zbUoF7yKMbKOkX8v6LBoZdOVPea/2s= X-Google-Smtp-Source: APXvYqx873ue1kiViaDtzTiWDco9i9CSRKbtwIDQlHIBKXb54RJUMTxG3wBL8P7x/RgciL8UqCu/8R5G1J0apBP+qJ0= X-Received: by 2002:a92:db0c:: with SMTP id b12mr8053294iln.49.1571799276625; Tue, 22 Oct 2019 19:54:36 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Tue, 22 Oct 2019 19:54:25 -0700 Message-ID: To: "Salz, Rich" Cc: Stephen Farrell , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008aa3cb05958b09d9" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 02:54:39 -0000 --0000000000008aa3cb05958b09d9 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 22, 2019 at 7:29 PM Salz, Rich wrote: > > > - Low numbers might encounter all sorts of well-known cryptographic > problems, and varying the padding of the domain name with any granularity > would tend to narrow the search space for an attacker. > > > > What well-known cryptographic problems? Varying the padding can also * > *add** security because foo.secret.example.com could show up with two > different sizes. > Hi Rich, To be clear, I am in favor of varying padding. I want the "zeros" field to have a prefix and I want my client to do whatever it wants with that buffer, within the boundaries of an unsigned 16 bit integer. I was concerned about a couple of different issues. The first is that the search space for the plain text is actually quite restricted. For example, " foo.example.com" might only vary by three characters vs other "example.com" domains. So, 16-character padding boundaries might be an issue. The other is that I worried that an attacker could use brute force to replicate traffic, and thus determine what was requested. I couldn't come up with a way to do this easily, but I did worry that a small search space in the SNI text would make it easier. And, as I wrote, I am not an expert in these matters. From what I do know, I think padding the buffer to the maximum likely size seems like a good idea. thanks, Rob --0000000000008aa3cb05958b09d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 22, 2019 at 7:29 PM Salz,= Rich <rsalz@akamai.com> wrot= e:

=C2=A0

  • Low numbers might encounter all sorts of well-known cryptographic= problems, and varying the padding of the domain name with any granularity = would tend to narrow the search space for an attacker.

=C2=A0

What well-known cryptographic problems?=C2=A0 Varyin= g the padding can also *add* security because foo.secret.example.com could show= up with two different sizes.


Hi Rich,

To be clear, I am in favor of va= rying padding. I want the "zeros" field to have a prefix and I wa= nt my client to do whatever it wants with that buffer, within the boundarie= s of an unsigned 16 bit integer.

I was concerned a= bout a couple of different issues. The first is that the search space for t= he plain text is actually quite restricted. For example, "foo.example.com" might only vary by three c= haracters vs other "example.com&quo= t; domains. So, 16-character padding boundaries might be an issue.

The other is that I worried that an attacker could use bru= te force to replicate traffic, and thus determine what was requested. I cou= ldn't come up with a way to do this easily, but I did worry that a smal= l search space in the SNI text would make it easier.

And, as I wrote, I am not an expert in these matters. From what I do kno= w, I think padding the buffer to the maximum likely size seems like a good = idea.

thanks,
Rob

--0000000000008aa3cb05958b09d9-- From nobody Tue Oct 22 22:26:17 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28A12007A for ; Tue, 22 Oct 2019 22:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 hyWxXXh-LZo4 for ; Tue, 22 Oct 2019 22:26:14 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69CB120058 for ; Tue, 22 Oct 2019 22:26:14 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id l12so17719975ilq.4 for ; Tue, 22 Oct 2019 22:26:14 -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=9UU6cPPwFoPDBo2tzP/wCzIGK6SBya423nWIgVIL4Ok=; b=X849A5Nm4Il0/7KBsvZld6ncEpREFyPAT9UGjtTmBQhI8Rz38IPJ6UO6pXDzNDT8JM w3CwyR4z5g1ajE/CZphs2C0UrcoXJEayqNGFUQOFPoH9rs55DzSGcmBEH61mzXsp/qIv Hr1anbUONRaoFnHvGVHAv7zH2ygvbFqJMLhijukNBX/aObzTEp7tUp6iPuSHskN50lD3 W2odKwcYVDWB6+dICTKwelOF2+hE1nRWjnIAoTXWk0RgfOk1St+wLXpawb0zzgq9mNUY nFPmC5OM5oRjbOFXBjvw3rXrOmlHS44VShK47M6mz0uKlzP/LWVG3a/BME49zoFheTxj Ph6w== 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=9UU6cPPwFoPDBo2tzP/wCzIGK6SBya423nWIgVIL4Ok=; b=LS0ZXGw5FNkCr6ZNscWtZqac9Flru2MIc0mMGBaSQbxAtuPoFAVzLxI8t7yGfCYgq0 q6Px/0erZu/ziXiJTeiAMNXwnsUJznLDW6XpgAp/HMvevdRZbTugIqhgDfmBf5GcRAaa 8ddAigkfjQQ3acHNKCr59c4xeOFigKuNxgyptipr+jeUlxx49ZCglqvk1ScQlC7lr7Fo nv1yxmPFHBFCraEgnVwVwoQRzZ5h3LN5oAmjAYuucVzoDk5it7gz7BEKLL+5zDzXN8if 9Gaf8KcLCDVKbkxhnpJIN6D6kOanIfHbyM52z0L7gg9M6RXGgTR5ztrUfbn1WDGUIs+f vTHw== X-Gm-Message-State: APjAAAXD8HffrVIaYIZWEuffoSWJvtq8rymx1BRG7EnNIA4r5zYsW4Z8 ALPJrFV7M1Uz0fxLsfbeU2yDJ6oCUR26vkxxP3IHuRgEax4fLQ== X-Google-Smtp-Source: APXvYqxeeyry/nrYaa4JmeSpJC32tzE5SU/cahcIxH0Ym3oQ1rzPhSu/CDWenIJU8a9svq3O1+Se7b3TM7sZZ8lci7w= X-Received: by 2002:a92:db0c:: with SMTP id b12mr8566887iln.49.1571808373713; Tue, 22 Oct 2019 22:26:13 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Tue, 22 Oct 2019 22:26:02 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c531e905958d2726" Archived-At: Subject: [TLS] basic off-list bullying X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 05:26:16 -0000 --000000000000c531e905958d2726 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I thought I would help to characterize some basic "crypto" bullying. This kind of thing is not easy for every participant to deflect, so I thought I would share some email traffic in my inbox. thanks, Rob [me] > "And, as I wrote, I am not an expert in these matters. From what I do know, I think padding the buffer to the maximum likely size seems like a good idea." [respondent] > "Usually not a good idea to go with what =E2=80=9Cseems=E2=80=9D like a g= ood idea. Crypto is often not obvious" [me] > "I am totally ok with a brutal on-list takedown of my message. That would shake out truth, and that is good." [respondent] > "Shrug. Not from me, not this time :)" [me] > "It seems hard to argue against 256 characters for this use case. There isn't even an efficiency argument, since ClientHello messages are pretty small." thanks, Rob --000000000000c531e905958d2726 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, I thought I would help to characterize some basic= "crypto" bullying.

This kind of thing i= s not easy for every=C2=A0participant to deflect, so I thought I would shar= e some email traffic in my inbox.

thanks,
Rob

[me]
> "And, as I wrote, I am n= ot an expert in these matters. From what I do know, I think padding the buf= fer to the maximum likely size seems like a good idea."

[respondent]
> "Usually not a good idea to go wi= th what =E2=80=9Cseems=E2=80=9D like a good idea.=C2=A0 Crypto is often not= obvious"

[me]
> "I am totally ok = with a brutal on-list takedown of my message. That would shake out truth, a= nd that is good."

[respondent]
>= "Shrug.=C2=A0 Not from me, not this time :)"

[me]
> "It seems hard to argue against 256 characte= rs for this use case. There isn't even an efficiency argument, since Cl= ientHello messages are pretty small."

tha= nks,
Rob

--000000000000c531e905958d2726-- From nobody Tue Oct 22 22:39:42 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2959C120058 for ; Tue, 22 Oct 2019 22:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mAPL_j8csnDz for ; Tue, 22 Oct 2019 22:39:38 -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 51868120024 for ; Tue, 22 Oct 2019 22:39:38 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id y127so14987653lfc.0 for ; Tue, 22 Oct 2019 22:39:38 -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=HsaHsPE4HuxpzXRNqadzslzXFI44CBQHe0ZWKMFld1A=; b=ZwId5pzskfHPNcCrcCNjFqpb0dHZdp3raOIUeXSEn5COKUN4sn5ckE84zRMTYoVJbF IdUMgca/kqYgkX37Rd9QoPxhemBLDxqHuv3/vM1UGjQsKK/ZlYIeBJu1lRgS3SsZU2Pm ahAIrvU4vzf6hOrawyml0/Qt/JsEDNkJJAKj5k9ye6NhCQBTUfVGTuma++W4CNhoM0If q3mOCf1liru+I+b04rcliSNS2WyYhB3c21bOxO0lFu9Q5eRI4G+Fc2k2Dcew4Aol6upo if3YQKqre0fi7XYxP46ug985IZtknW2yRtiJIQULO90iJOb9Ig0it1LeTxG4DtPRjViR USfw== 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=HsaHsPE4HuxpzXRNqadzslzXFI44CBQHe0ZWKMFld1A=; b=nm735/UYOH2Nk9Uqn0+D2VtjQUpr58PfMEUeObvE2lRmZ0V/tWruTjcFQYbYDb1DG1 SrEJn0+P+QnUfbuIpPv5w8sTIcl7gKLUI0bJZHPaL5zpSodldXQuMuDA1ny/u+heoow9 wdeiQPPHBUMhixbK0DTooxNlRECDrbvG+BINMxrdFbHoqLwAzWolqWNv+yiFDIFP2UW7 vd2GM3D2pEGWjMgon6ryIGrUmw0apgEnClHuZdc14vDdsoI0VcqC3VoxbeEd0Z2C9+gr GpXbbfjZWc7iRXQiujXCX5jq9IeM09+I4/DcG1DyPnONrxo2gqXPeJijVQwcld6uz7+9 s8hw== X-Gm-Message-State: APjAAAXAEX0AsnIbGDuRByXEBDKJtXcoasrF+cyBb0JMkPTygtn4IGmb MZScc1wiW7ljkRrwE7fUG4h+9GrJ2EPvY3O71Wg= X-Google-Smtp-Source: APXvYqwyPzAgkXqJ07izzFiFrwV8CsjJ6MsiCor4lIFYaIHlxl98brukIFlqCM6jp00jDt3C1pOtfBK9R9/ZIqbPh1Q= X-Received: by 2002:a19:10:: with SMTP id 16mr13687048lfa.100.1571809176268; Tue, 22 Oct 2019 22:39:36 -0700 (PDT) MIME-Version: 1.0 References: <03e15760-dfce-cd7b-baea-56ac70d92192@cs.tcd.ie> <8063bb12-8462-53fa-fa62-1e5abb1a652e@cs.tcd.ie> <333fde42-76f9-1af3-0f0f-c70914b0222e@cs.tcd.ie> <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> In-Reply-To: From: Watson Ladd Date: Tue, 22 Oct 2019 22:39:24 -0700 Message-ID: To: Rob Sayre Cc: "Salz, Rich" , "TLS@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 05:39:41 -0000 On Tue, Oct 22, 2019 at 7:54 PM Rob Sayre wrote: > > > > On Tue, Oct 22, 2019 at 7:29 PM Salz, Rich wrote: >> >> >> >> Low numbers might encounter all sorts of well-known cryptographic proble= ms, and varying the padding of the domain name with any granularity would t= end to narrow the search space for an attacker. >> >> >> >> What well-known cryptographic problems? Varying the padding can also *a= dd* security because foo.secret.example.com could show up with two differen= t sizes. > > > Hi Rich, > > To be clear, I am in favor of varying padding. I want the "zeros" field t= o have a prefix and I want my client to do whatever it wants with that buff= er, within the boundaries of an unsigned 16 bit integer. > > I was concerned about a couple of different issues. The first is that the= search space for the plain text is actually quite restricted. For example,= "foo.example.com" might only vary by three characters vs other "example.co= m" domains. So, 16-character padding boundaries might be an issue. > > The other is that I worried that an attacker could use brute force to rep= licate traffic, and thus determine what was requested. I couldn't come up w= ith a way to do this easily, but I did worry that a small search space in t= he SNI text would make it easier. > > And, as I wrote, I am not an expert in these matters. From what I do know= , I think padding the buffer to the maximum likely size seems like a good i= dea. Padding to the max every time leaks no information. It also doesn't have some of the operational issues. There are possible setups on Cloudflare where Cloudflare will not know what domains are being proxied ahead of time (wildcard DNS+wildcard cert, https://support.cloudflare.com/hc/en-us/articles/360017421192-Cloudflare-DN= S-FAQ#CloudflareDNSFAQ-DoesCloudflaresupportwildcardDNSentries available to enterprise customer) What's not clear is what the other proposals leak. Some of them like randomized padding end up leaking much more the might be expected. At the same time Client Hello sizes aren't constrained to be tiny, but the next problem of 1280 bytes is not that far off either. So we should be judicious in spending those bytes. > > thanks, > Rob > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Oct 22 22:57:47 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E5B120058; Tue, 22 Oct 2019 22:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=lD2jpG1/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wzR+3ZfT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ihk7NVZebUA; Tue, 22 Oct 2019 22:57:41 -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 F0818120024; Tue, 22 Oct 2019 22:57:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 4B1752205E; Wed, 23 Oct 2019 01:57:40 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 23 Oct 2019 01:57:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=drhUQyhsmKlxiW6EMFQyDOS1+Xud snuYe99jsmN7ExE=; b=lD2jpG1/+3DXLdMIK5X+PVssOgvCjhqv6J+gnBcFqp5C Tr8u5YcgsW2OnJJ1AvNCdJIhd4Rhd6qdD5N6nsPuGQ8ml6ntbDV+J1/5qqVXRj2X iv9DHLgLC1dIdnXsq07lHohLDiI3uea1m5uka2BxZy93DDn8HUyhnmCYge9oWnjI s/C2LifYR/2J1vgyFRnyKOxnuWJqXQOW3tK+5cODDmRXzBZ1GZ0m3WZpLIDb5Y6s 3Tp9cc8Qiary53dQ7DSbE2BSgNxo7cvOlAQbvx9LxdQAgJN4ycojFDz+GMSEurgF 7xAUgjNQFYQ8gvr6JR35n1+atX+03Li24gb6c8pM1Q== 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=fm1; bh=drhUQy hsmKlxiW6EMFQyDOS1+XudsnuYe99jsmN7ExE=; b=wzR+3ZfT/7pPUg0xPzcap4 rR+GrDfbSIuGr/QeLT0uNjc211mFomT2bpmcHhzQP3SNNuEcxjhfYZdB/MEoFrFi HBDxDXPzOYq6oPg/tIRFyVT/2QRW+8v6kmClfHGHAtDGbsGAv6F+pr5yLb5dDvOm 4nL/5/ENnLJzlq2BBUJIGJrNkBoS8xIhlx87CGTZjic+rRLcpzH7z/w67RKbrunt yr1uGGZzRujxhDxleMdR0dsHzCZdYp9HX/cQ49cnhNLsDZXWcacdI0kXCc3C2oGX 8+9l+eqEWJKV+5YHD/vvIRos+GQQoY/AYB4CQdk1eWncPL0Cmq6QKJE21s9qCQdQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrkeekgdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D37023C00A1; Wed, 23 Oct 2019 01:57:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: In-Reply-To: <31e3f9ed-6b24-4526-af75-e2c190a3d707@www.fastmail.com> References: <31e3f9ed-6b24-4526-af75-e2c190a3d707@www.fastmail.com> Date: Wed, 23 Oct 2019 07:57:19 +0200 From: "Christopher Wood" To: "TLS@ietf.org" Cc: "TLS Chairs" Content-Type: text/plain Archived-At: Subject: Re: [TLS] IANA changes for draft-ietf-tls-exported-authenticator X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 05:57:45 -0000 Hearing no major objections, we're moving forward with this proposal. Best, Chris On Wed, Oct 2, 2019, at 10:58 PM, Christopher Wood wrote: > Hi folks, > > draft-ietf-tls-exported-authenticator requires some IANA changes that > were not discussed during WGLC. The proposed changes are below. Please > let the list know by next week (10/9) if you object to them, and if so, > please explain why. > > > Value: EXPORTER-server authenticator handshake context > > DTLS-OK: Y > > Recommended: Y > > Reference: [ RFC-to-be ] > > Note: > > > > Value: EXPORTER-client authenticator finished key > > DTLS-OK: Y > > Recommended: Y > > Reference: [ RFC-to-be ] > > Note: > > > > Value: EXPORTER-server authenticator finished key > > DTLS-OK: Y > > Recommended: Y > > Reference: [ RFC-to-be ] > > Note: > > Thanks! > Chris From nobody Wed Oct 23 07:35:01 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B31612081C for ; Wed, 23 Oct 2019 07:35:00 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 U50H85B0pHE2 for ; Wed, 23 Oct 2019 07:34:58 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (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 AA19C1200E6 for ; Wed, 23 Oct 2019 07:34:58 -0700 (PDT) Received: from [174.192.19.62] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1iNHiz-000AHf-AE for tls@ietf.org; Wed, 23 Oct 2019 10:34:57 -0400 Date: Wed, 23 Oct 2019 10:34:57 -0400 From: Bill Frantz To: 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79d624e5df46477f8e56db7733a77c628c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 174.192.19.62 Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 14:35:00 -0000 A perhaps radical suggestion: Make the server name field fixed length e.g. 256 bytes. Longer=20 server names are not supported and clients MUST NOT send them.=20 (Both client and server can't use them because they won't fit in=20 the fixed length field.) Putting a limitation like this one into a protocol certainly can=20 create problems, but we can look to the file system name=20 situation for some insight. In the dark ages, file names were=20 limited to a small number of characters -- 4, 5, or 6. I=20 remember when the file system I used increased the limit to 8=20 characters, seeming like infinity for a few days. Finally some=20 file systems raised the limit to 256 characters and I stopped=20 hearing complaints that the length limit was a problem. With the suggestion, DNS lookups are padded to allow all 255=20 byte names to be represented in what is, in effect, a fixed=20 length lookup string. Now people with more information about the problem can describe=20 the problems this suggestion would cause. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345=20 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos,=20 CA 95032 From nobody Wed Oct 23 07:52:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62433120143 for ; Wed, 23 Oct 2019 07:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LSGBHgLQI5k4 for ; Wed, 23 Oct 2019 07:52:47 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88A271200E6 for ; Wed, 23 Oct 2019 07:52:47 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q78so6321896lje.5 for ; Wed, 23 Oct 2019 07:52:47 -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=9gxaVhoB/b08SRcVN/mIRzkkF+IfMD8Hzb+f/pv3Zq0=; b=CWhk4Tr6wC3VKOO3d0f4hRi7FR4Cgz0TOAVE+nCGWghwrHG5z/LgC8I0fsFD20Xjp8 9ajQdqysNLr+LMlZCt5Y4gcZaJzNYSAV0SkXG+O9lH+HfmXvsRzh3vCUCDTrqMXrlI4F u/qIPQOjrL1A32ar5twSvKfT9lRYZE1SPrZoAJZfOfiz/9aj1efu1pTY0JmYtiRCv9JM UyYbP67BL+326bpQlvS0tfdG/DFq0B3efki3CODwoT73DF0YQjN9i5BLBj8NymDX172K n+zyTDuOfoIUyT52mi+GGfw9n46PeeKveG95DdEfJ98pUGirLS97+9ZD4keEHfOpgzcx 2Q2A== 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=9gxaVhoB/b08SRcVN/mIRzkkF+IfMD8Hzb+f/pv3Zq0=; b=qcmoDd6Qe5fdZ1j2RiwSi9YcgjZYqxp70L4kr3cWnuacQfJK0HTuqm4ORB8cHIQWhw bsnAxIa5g1Sb9/97OnLIk3TkG8kgapunuNXOIHQPeB/Z+PsMbhp86ZNjCXkNMkzM2jms ear8wSO/CfW5Jy0yl/q1LjeK9za6m4s59msPHFawNoJu1m2aDJZKuYPVPeETcINo9ZFS BVkSDS+fpmlKIquYV/E7+mpOSVU2B6ylv1Fqm5fgxPtoHLyUCFNX/xF/FUb2eJ60fmLU V8Qutg2w07P8miDpv/m5ctfftuG1XaEJr8hnAk9XZN3BHcMaFvWyQe9615FWzLeqpD96 lb1g== X-Gm-Message-State: APjAAAUuMP9fZxKK4hCf59RDxcJ51LG4SRWiXhKvzuBrk5rHBupr6VHi vGZd76g9n+BNHBCwi8C6yLBqBko0ph532YqOraF9NlQH X-Google-Smtp-Source: APXvYqymvD5dRmNSLK6Jy+ry1PKpJfNPuQrOoN6/ewJKvUKggUwgtfUIZA5cZr70Q785xFakv1nFvlCtYVnFLS5ro5M= X-Received: by 2002:a2e:908d:: with SMTP id l13mr21120398ljg.165.1571842364835; Wed, 23 Oct 2019 07:52:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Watson Ladd Date: Wed, 23 Oct 2019 07:52:33 -0700 Message-ID: To: Bill Frantz Cc: TLS List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 14:52:49 -0000 On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz wrote: > > A perhaps radical suggestion: > > Make the server name field fixed length e.g. 256 bytes. Longer > server names are not supported and clients MUST NOT send them. > (Both client and server can't use them because they won't fit in > the fixed length field.) The limit of server name in DNS is 260 bytes, so that limit already exists. No reason to shorten it elsewhere! -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Oct 23 08:41:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C0D120AD6 for ; Wed, 23 Oct 2019 08:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 aA-FvIi9YBZd for ; Wed, 23 Oct 2019 08:41:06 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B77120AD7 for ; Wed, 23 Oct 2019 08:41:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D2CFE45518; Wed, 23 Oct 2019 18:41:03 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 5GaovYxT8MBY; Wed, 23 Oct 2019 18:41:03 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id CE30B2315; Wed, 23 Oct 2019 18:40:59 +0300 (EEST) Date: Wed, 23 Oct 2019 18:40:59 +0300 From: Ilari Liusvaara To: Watson Ladd Cc: Bill Frantz , TLS List Message-ID: <20191023154059.GA471205@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 15:41:09 -0000 On Wed, Oct 23, 2019 at 07:52:33AM -0700, Watson Ladd wrote: > On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz wrote: > > > > A perhaps radical suggestion: > > > > Make the server name field fixed length e.g. 256 bytes. Longer > > server names are not supported and clients MUST NOT send them. > > (Both client and server can't use them because they won't fit in > > the fixed length field.) > > The limit of server name in DNS is 260 bytes, so that limit already > exists. No reason to shorten it elsewhere! Got a reference for the 260 byte limit? According to RFC 1035, the maximum DNS hostname length is 253 bytes: "To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less." This is for wire-form encoding, which has 2 bytes of overhead (initial and terminal lengths), so maximum 253 bytes for the hostname. However RFC2181 says: "A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as '.'." Which could be interpretted as that the final length is not part of the 255 byte limit, and thus DNS name being maximum of 256 octets, corresponding to maximum hostname length of 254 bytes. However, dig utility refuses to send such queries (can send 253 bytes just fine), so I presume that the 255 octet limit is intended to include the terminal length -> maximum hostname length is 253 octets. I can not find any justification for higher limit from any RFC updating 1035 or 2181. And I would expect any such limit to have been significantly above 253 bytes. -Ilari From nobody Wed Oct 23 09:14:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D521208E5 for ; Wed, 23 Oct 2019 09:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 LEfYv58eIrYn for ; Wed, 23 Oct 2019 09:14:01 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31844120A8F for ; Wed, 23 Oct 2019 09:13:52 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id z10so19434594ilo.8 for ; Wed, 23 Oct 2019 09:13:52 -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=06Tpjaet4zUNitDBXFB1CfRay//DrYioIeqjoaVS7Yc=; b=vKLMoyl3lODR2ubQI0fShtLDV8vHYKqc9RCFhAud200Mt0tRavlkvb40mUK/IyBnzI XEwZ9hTtUzFV9Hzhfgz3+964oQkYwxpzPqbNJxTmbOvkuFB0QFs4ToHf1UX18IXCn0iR ndQzlBvZiUWGCfZbodj294Grk5uXDWtup4j+W+kJmLQDfTmgYBE23Zgp/8ktizbtRwy5 YsOzqj0CZDX8yZ+9HA2HVBvguMxVweyR5g/eDHBa5C8wO5p66qkT9tFQbxQiqRJ35lKJ 5QsimuHKI3BlKLn2dO5GFGLosoKnxjWCsFIKderHXZAwV1/d/+mQ1DtGE86yPXZh65RT D6Gg== 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=06Tpjaet4zUNitDBXFB1CfRay//DrYioIeqjoaVS7Yc=; b=D3TXVIP9lC/z8DFB+nbe0v3/yD6UVstkk/4faoD3R2MBuGmoIseJYcx19sN7PGAZHC pJlQNLuzB1FWdZQrkh72CC10T0q0VI3n7c2QgMHPOItTuDQaybFSaNAHpjfsv9u9Cimp vAet9A5gBAyZmUywAm5L+TihQWBcrBC2uks8rfLniOWdqbsWE4l/WU3EC1dFRhu1lqDO BLPjgw7N5xHjYxSuvtGmZqH5plS4FVQGqy7mo43IWaAj9cmp3a4fad2dNqKrhVN4ZTIj ghpzNlH/0nMuujZHKki3hdYjA5sGu6ajkUHFo15Jhi2Z79f2JolQ/CoE0520fMyl2hph IyLQ== X-Gm-Message-State: APjAAAUgh5OZxwoz7hUs63/e9xVyN3EugFuynxH1XneL2nLJuZ26Ps9F RKoMXaDSRK8PqDK5JQ9CZWLN+952ezHUL1+/H+fqWg== X-Google-Smtp-Source: APXvYqwBlCDoqzy1CgyPm8MPvboo9iCjM8YmslIyTYn4bJdHQFrJxocGLeoOQX8WQGmMsfiFHirXAbePUqcehOLCrdI= X-Received: by 2002:a92:8dd9:: with SMTP id w86mr39864480ill.163.1571847231000; Wed, 23 Oct 2019 09:13:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Wed, 23 Oct 2019 12:13:39 -0400 Message-ID: To: Watson Ladd Cc: Bill Frantz , TLS List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000e2278505959633e5" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 16:14:08 -0000 --000000000000e2278505959633e5 Content-Type: text/plain; charset="UTF-8" On the topic of radical suggestions, here's another one: https://github.com/tlswg/draft-ietf-tls-esni/pull/186 In brief, this replaces the variable-length name with a fixed-length hash, plus some accommodations to allow *.example.com, *.*.example.com, etc. My hope is that this design would work in the architecture described by Watson, while saving ~220 bytes in each ClientHello. One interesting feature of this design is that it doesn't require each wildcard domain to publish any unique DNS record. Instead, all third-level wildcard customers can share a configuration, all fourth-level wildcard customers can share a configuration, etc. This distinction is not visible in the TLS handshake, so the anonymity set is not reduced. On Wed, Oct 23, 2019 at 10:53 AM Watson Ladd wrote: > > On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz wrote: > > > > A perhaps radical suggestion: > > > > Make the server name field fixed length e.g. 256 bytes. Longer > > server names are not supported and clients MUST NOT send them. > > (Both client and server can't use them because they won't fit in > > the fixed length field.) > > The limit of server name in DNS is 260 bytes, so that limit already > exists. No reason to shorten it elsewhere! > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --000000000000e2278505959633e5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCAy1DFnPnP+jdG6WOERqNR8 b8bknRKT7kSewxsINrx5pDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMjMxNjEzNTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAIeztytEpkW9pALa6U0XeWcfjRbXH2UKXFHn6+omu u3uVBmbIiUPxlT75bgSi0vAdvLgv0Yrbagcmsb9EGiFIbLWdjIizAORYuB00gaOIAcD7BldONpRM msXoP9TEZSyisFQR9THMdQkqatVB07z9SAuQkPDTS6zRfJ8e5X7BymjUF3khU3JaJUw5fNP8txBw jLEhhZ5aSiVa/ckxY8EaUQ1+JqyrGtr8B4PKrHrVQK2GsFOjeSSPzmtpVJfHXA1slF0A/Ski50Zn quHu/6Pr7Y23A4oySpdsS/75zpJR5cl7Up18sAD8nr5+Kkp/vaclv8hAylNxtxKwSjmFogg3fg== --000000000000e2278505959633e5-- From nobody Wed Oct 23 10:11:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473D9120B84 for ; Wed, 23 Oct 2019 10:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 ycYgdYcqCkAj for ; Wed, 23 Oct 2019 10:11:20 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881D7120B7C for ; Wed, 23 Oct 2019 10:11:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 8EDAECA2C; Wed, 23 Oct 2019 20:11:17 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id ToY4OQHZItQR; Wed, 23 Oct 2019 20:11:17 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9C33272; Wed, 23 Oct 2019 20:11:13 +0300 (EEST) Date: Wed, 23 Oct 2019 20:11:13 +0300 From: Ilari Liusvaara To: Ben Schwartz Cc: Watson Ladd , TLS List Message-ID: <20191023171113.GA472177@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 17:11:23 -0000 On Wed, Oct 23, 2019 at 12:13:39PM -0400, Ben Schwartz wrote: > On the topic of radical suggestions, here's another one: > https://github.com/tlswg/draft-ietf-tls-esni/pull/186 > > In brief, this replaces the variable-length name with a fixed-length > hash, plus some accommodations to allow *.example.com, > *.*.example.com, etc. > > My hope is that this design would work in the architecture described > by Watson, while saving ~220 bytes in each ClientHello. > > One interesting feature of this design is that it doesn't require each > wildcard domain to publish any unique DNS record. Instead, all > third-level wildcard customers can share a configuration, all > fourth-level wildcard customers can share a configuration, etc. This > distinction is not visible in the TLS handshake, so the anonymity set > is not reduced. AFAIK, PKIX in practice only allows single full-label wildcard in terminal position (the only place * can appear is as first character, followed by label separator). And the scheme in #186 does not seem to distinguish between "example.org" (the base name) and "*.example.org" (a wildcard). There also seems to be issue that seemingly nothing constrains the case of hashed encoding. And you do not want to deal with arbitrary casings, as the number of those quickly blows up. Perhaps a simpler way would be to have a flag that causes the first label to be overwritten with '*'. That would be set on nodes covered by a wildcard certificate. Alphabet would be hashed lowercased. Then the server could just hash every lowercased name from every known certificate and use the hashes as lookup table keys without worrying about encoding. And in the structure, the label_limit, num_labels and length field for name_digest seem to be superfluous. This would give that the encrypted_sni is 64 octets with AES-128 or Chacha20, and 80 octets with AES-256. On optimizing stuff, the length fields for record_digest and encrypted_sni in client structure are also superfluous, because the length of record_digest is impiled by suite (and unknown suites are unprocessable anyway) and encrypted_sni runs to end of explicit-length record. The length of key share probably can not be removed, as some algorithms may have variable-length ciphertexts. Using the above figures, this would mean that the part after the share would be 96 octets for AES-128 and Chacha20 and 128 octets for AES-256. -Ilari From nobody Wed Oct 23 10:38:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC5A120BD0 for ; Wed, 23 Oct 2019 10:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 29Cw-wUyL0cn for ; Wed, 23 Oct 2019 10:37:58 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE78A120C34 for ; Wed, 23 Oct 2019 10:37:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 83AC3350F; Wed, 23 Oct 2019 20:37:28 +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 38DsIUIJKRNU; Wed, 23 Oct 2019 20:37:28 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A865F7A; Wed, 23 Oct 2019 20:37:24 +0300 (EEST) Date: Wed, 23 Oct 2019 20:37:24 +0300 From: Ilari Liusvaara To: Watson Ladd Cc: Rob Sayre , "TLS@ietf.org" Message-ID: <20191023173724.GA472723@LK-Perkele-VII> References: <04a5a50a-3268-d9fb-de16-abb9224409ed@cs.tcd.ie> <975963dc-f311-b806-6860-8768f4ec1a76@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 17:38:06 -0000 On Tue, Oct 22, 2019 at 10:39:24PM -0700, Watson Ladd wrote: > > At the same time Client Hello sizes aren't constrained to be tiny, but > the next problem of 1280 bytes is not that far off either. So we > should be judicious in spending those bytes. I do not think 1280 bytes is a big issue. - If using QUIC, one expects fragmentation above 1200 bytes. I am not sure if fragmentation is presently allowed, but I am sure it is not pleasant to implement in robust way. - For classical TLS over TCP, in practice one can push something like 1400 octets or so in a single packet over virtually all paths. - Present handshake sizes are AFAIK bit north of 256 bytes (still mostly padded to 512 to avoid old TLS server bugs). So sticking even 350 bytes (256 for name plus 80 bytes crypto overhead plus few odd other bytes) extra would not blow any soft limits. - With post-quantum, you are going to bust single packet limits no matter what, since: - SIKE is slow, so server operators probably prefer lattices as those are like two orders of magnitude faster than SIKE (or SIDH). - Lattices are roughly 800 bytes at minimum at reasonable security levels. - You are going to need two keys, because all the post-quantum ways of sharing one key are both even slower and more exciting (not in a good way) than anything in NISTPQC. -Ilari From nobody Wed Oct 23 13:53:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCDC120103 for ; Wed, 23 Oct 2019 13:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 OHpC5H1mySgn for ; Wed, 23 Oct 2019 13:53:10 -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 BF10A1200EC for ; Wed, 23 Oct 2019 13:53:10 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id c6so26647986ioo.13 for ; Wed, 23 Oct 2019 13:53: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=/HYljioP/BKxBa0qgmnZnTfkYuT/Cyql1GQHIv9/wU0=; b=FiCZgEvSO6cvO8nDLLlR2pB4YDYbxU4M1QmyTEp10htWtkZ2A+lAj1naDSx/haT94a i+QUx9H4Xa7LgV46RLrnR121IiWeixgKrrhFGlPQBq2CP3ZAUcQONCZeG1S/hHWVubyZ /+CP8bQTalPse7sAIBQb7kFUx2/O8LvHXuG6HuHQC5Sf1hto5GZWIMd3QM0HNYdOGY/H 8SgWvJW8cPQTa/1wX6SsSFsLpk4j8DC/JEZcWZ2ccnxaQlKLByMxy8TZiJ2v+7p/SV8F 3NKhHHI3FYsLHrcNg0GYJulJ0bOJDtAGnWEKnW3Y71zRQj8pqOLfzSarb+dQdv/unfws C5Mw== 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=/HYljioP/BKxBa0qgmnZnTfkYuT/Cyql1GQHIv9/wU0=; b=UkYF7SPBvXUKFTN4jtsHBexSmEPezTLEd4YRDj4rp0p3jnTu8hgmaMegqIM+KqPapk fdipnQiElFWAcmZKaI7pBAFqRR5mVAKLWH3mtLiRk8ZIn2akeEP5kDzAZN2lJN9YY2hj HV4kSV14SkXjT2JgNBRlCYVXhKdUjPlXR7wbnTH7vP8j+hJixPBsy9usqAbC1ct8hjEJ ueFynSpSt/LiOvBkD8kgDnZpgDivULjnEljR30MbkE5smQx3erJG5tJk3++Aog/oC78o v5z/t+IEqhNC/9R3LIisaOJtzy8ShAywElg/1yprecKBlr28mi5e0MGDS3zY3DITwwVD aPIw== X-Gm-Message-State: APjAAAVLs+0xv6LCwgS7pnlxnzAN9i49oglyBZJ+7xd8fepeoVz3BdC2 pvNB495Xd85lCs7GlDw3VfJLMpwgiDolmnizDBq0rg== X-Google-Smtp-Source: APXvYqw0LPipT8xgE20S0qOuL1vmAT/f88LSn8IskP+KZ6mZlANDotXZ1eSwlOGsHPCs+SXgxYWzneVek5jB1ul+x6s= X-Received: by 2002:a6b:7a4a:: with SMTP id k10mr5437493iop.193.1571863989560; Wed, 23 Oct 2019 13:53:09 -0700 (PDT) MIME-Version: 1.0 References: <20191023171113.GA472177@LK-Perkele-VII> In-Reply-To: <20191023171113.GA472177@LK-Perkele-VII> From: Ben Schwartz Date: Wed, 23 Oct 2019 16:52:57 -0400 Message-ID: To: Ilari Liusvaara Cc: Watson Ladd , TLS List Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c62a7905959a1a10" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 20:53:13 -0000 --000000000000c62a7905959a1a10 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 23, 2019 at 1:11 PM Ilari Liusvaara wrote: > > On Wed, Oct 23, 2019 at 12:13:39PM -0400, Ben Schwartz wrote: > > On the topic of radical suggestions, here's another one: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/186 > > > > In brief, this replaces the variable-length name with a fixed-length > > hash, plus some accommodations to allow *.example.com, > > *.*.example.com, etc. > > > > My hope is that this design would work in the architecture described > > by Watson, while saving ~220 bytes in each ClientHello. > > > > One interesting feature of this design is that it doesn't require each > > wildcard domain to publish any unique DNS record. Instead, all > > third-level wildcard customers can share a configuration, all > > fourth-level wildcard customers can share a configuration, etc. This > > distinction is not visible in the TLS handshake, so the anonymity set > > is not reduced. > > AFAIK, PKIX in practice only allows single full-label wildcard in > terminal position (the only place * can appear is as first character, > followed by label separator). > > > And the scheme in #186 does not seem to distinguish between > "example.org" (the base name) and "*.example.org" (a wildcard). It does, with num_labels in the ClientESNIInner. > There also seems to be issue that seemingly nothing constrains the case > of hashed encoding. And you do not want to deal with arbitrary casings, > as the number of those quickly blows up. > > > Perhaps a simpler way would be to have a flag that causes the first > label to be overwritten with '*'. That would be set on nodes covered > by a wildcard certificate. This is a reasonable simplification. It would also work nicely without the hashing, for servers that only have reasonably-sized names but can't make promises about wildcards. However, it does still suffer from the configuration brittleness described by David Benjamin in #186. > Alphabet would be hashed lowercased. Then > the server could just hash every lowercased name from every known > certificate and use the hashes as lookup table keys without worrying > about encoding. And in the structure, the label_limit, num_labels and > length field for name_digest seem to be superfluous. > > This would give that the encrypted_sni is 64 octets with AES-128 or > Chacha20, and 80 octets with AES-256. > > On optimizing stuff, the length fields for record_digest and > encrypted_sni in client structure are also superfluous, because the > length of record_digest is impiled by suite (and unknown suites are > unprocessable anyway) and encrypted_sni runs to end of explicit-length > record. The length of key share probably can not be removed, as some > algorithms may have variable-length ciphertexts. > > Using the above figures, this would mean that the part after the > share would be 96 octets for AES-128 and Chacha20 and 128 octets for > AES-256. > > > -Ilari --000000000000c62a7905959a1a10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCkt8ePkynuGOp4QsG79/ON Wqyt3QR5HKdjKYelgUMYRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMjMyMDUzMTBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAZHGoekeguj9vj4hZbuWyHfnmo85gmVPR/BFV3Z2c 5G5M+NBOFWDkDrG16q1TBdfilLvHcerkLB9CI5xH7BcXW1akTfLXh+td0P8qAdBug8dUL3rsO9Xo PCaY8DzcsQM+UUzINgVYVCI0KPaV4gcXYdykWD7sCUhmgH6UJdHFrBGjTzOPezyStBfqkVpQXfPN 7H8GKtKa1cYOf9NWT+RYD82Ra6fDkeRcOHa2wZJEhPXe/B1q9gLZXX7yyyTWwn3S4PE+9YeA/usc ca+XWiz4cMI1E4TFBWV3mkw+xtLwHcp8SlMLL+kmWpsyDzGzRiq0Dw0/4Dj50ThTLD+cUXbzKg== --000000000000c62a7905959a1a10-- From nobody Wed Oct 23 14:10:38 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61356120100 for ; Wed, 23 Oct 2019 14:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HwxQYwEb4spI for ; Wed, 23 Oct 2019 14:10:35 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 8F56B1200A4 for ; Wed, 23 Oct 2019 14:10:35 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id p6so18545194iod.7 for ; Wed, 23 Oct 2019 14:10:35 -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=gNwud2zfF+qABdojmDp+ZtZJeoSrLRZv+F5LvbhIe0Q=; b=Xu81IcTflUk8dAS3KpAHYBg0a2Tg6Pl+gvIiV90bjgjOvZVFILLQL7Lf39xrS7kyny 6CjxrKbLH9c5G8vklIFTQYxYcZOVToN1OjqMc06J7QLZMcwHsSRfgtpFlYhuV9+OmDn9 JrAP/emX+02YKgBs6W7cj2iYeAbfDHM/gj4FPborQmcXp2tCYZv3IKkxqtOi09QZ4TRC uKKOPvdLUZvZt1cDhH2lO7cds09wiinDaRqHpDMeiIkwN5zQDdsVFjSgqeMCqlUC1ZDD 0hWi30mwB00oITZwzGgCvJp68UDlDEdDXGpT6M7rNqEsSIjIWGFpD4UvJguVZsAtc9rR IopA== 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=gNwud2zfF+qABdojmDp+ZtZJeoSrLRZv+F5LvbhIe0Q=; b=dg+OS5p9sdeyk5l4GCJueCGsooACi+mdpYWWMU957ulBuxn0RHxiMWB+G9f1p+PIMf j7zuCVWAM+6x2L96J6xKGfwAICIIGxmKLbPVK+f1oc1tXVILwXFrfONn5vhOI9ivDbmu a5YBVXLEfqwwLZ4m35Rol6eXGXEKexLjwR7dBAhjzvMdU9YuuD3We97iZD8dh+zHvKAS lLcRbXLkpvi4Umw7CAzt1aRl+tBLQveZFTneSWQ3hpRpHZg6u6BlejG7PZUhH8EN+xp+ w1v+k/lBRqDSc+FO9AbJ9udhsH2fRdv7GksShY3M13146TWHYttqDqhYdPYYpfJ2BOOo 8x0Q== X-Gm-Message-State: APjAAAVoZQKIkRTDH205qMYfXV/RkHDuyUe743j1zpvHPrCTPQyoiTiI P3nzuNM/+7Hox4ZTGcvt3xjbLTwby13LIkzq+4I= X-Google-Smtp-Source: APXvYqx0kR1QifuiUCq5I8aArWdxtOhFRGQaFRVs3k7c2kv8d4LqK37HsK6aOY5FKwT+uAPTPVILv3wqN9aP7bSrEoA= X-Received: by 2002:a05:6602:21c2:: with SMTP id c2mr5308042ioc.189.1571865034693; Wed, 23 Oct 2019 14:10:34 -0700 (PDT) MIME-Version: 1.0 References: <20191023154059.GA471205@LK-Perkele-VII> In-Reply-To: <20191023154059.GA471205@LK-Perkele-VII> From: Rob Sayre Date: Wed, 23 Oct 2019 14:10:23 -0700 Message-ID: To: Ilari Liusvaara Cc: Watson Ladd , TLS List Content-Type: multipart/alternative; boundary="0000000000000726d305959a59fd" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 21:10:37 -0000 --0000000000000726d305959a59fd Content-Type: text/plain; charset="UTF-8" On Wed, Oct 23, 2019 at 8:41 AM Ilari Liusvaara wrote: > On Wed, Oct 23, 2019 at 07:52:33AM -0700, Watson Ladd wrote: > > On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz > wrote: > > > > > > A perhaps radical suggestion: > > > > > > Make the server name field fixed length e.g. 256 bytes. Longer > > > server names are not supported and clients MUST NOT send them. > > > (Both client and server can't use them because they won't fit in > > > the fixed length field.) > > > > The limit of server name in DNS is 260 bytes, so that limit already > > exists. No reason to shorten it elsewhere! > > Got a reference for the 260 byte limit? > > ... > > I can not find any justification for higher limit from any RFC updating > 1035 or 2181. And I would expect any such limit to have been > significantly above 253 bytes. > I found the rationale here: https://github.com/tlswg/draft-ietf-tls-esni/pull/54 I think this explanation should be in the draft, too. thanks, Rob --0000000000000726d305959a59fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Oct 23, 2019 at 8:41 AM Ilari Liu= svaara <ilariliusvaara@welho= .com> wrote:
On Wed, Oct 23, 2019 at 07:52:33AM -0700, = Watson Ladd wrote:
> On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz <frantz@pwpconsult.com> wrote: > >
> > A perhaps radical suggestion:
> >
> > Make the server name field fixed length e.g. 256 bytes. Longer > > server names are not supported and clients MUST NOT send them. > > (Both client and server can't use them because they won't= fit in
> > the fixed length field.)
>
> The limit of server name in DNS is 260 bytes, so that limit already > exists. No reason to shorten it elsewhere!

Got a reference for the 260 byte limit?
=C2=A0
...

I can not find any justification for higher limit from any RFC updating
1035 or 2181. And I would expect any such limit to have been
significantly above 253 bytes.

I found = the rationale here:


I think this explanation should b= e in the draft, too.

thanks,
Rob=C2=A0
--0000000000000726d305959a59fd-- From nobody Wed Oct 23 14:12:31 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D115C1200EC for ; Wed, 23 Oct 2019 14:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 AGZ-PB5SYX7S for ; Wed, 23 Oct 2019 14:12:27 -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 1FBBD1200A4 for ; Wed, 23 Oct 2019 14:12:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45E1BBE2E; Wed, 23 Oct 2019 22:12:25 +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 HW9a2zo6_3H8; Wed, 23 Oct 2019 22:12:23 +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 3C9DDBE24; Wed, 23 Oct 2019 22:12:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571865143; bh=fLeNSfr9V1BHRbx9z+fnfrlKNToseYp/xu9wyLAeVqs=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=pkHWOPkEF/kZNUUc//ISluLpEsvHZQGRAVONes/6FGT5/+pvnqqLbYecF+kUZQZdZ dzOTZ+/YIx9E2EZ8dBMvP8qUYEsAlol3eauHoMJ/d1Eg9Yetg/XuYmrWwkvRmH7mKE ugH94HvOHF8+0yDJNRLN3v62Vg2u5SGQ6Cj02jLw= To: Ben Schwartz , Watson Ladd Cc: TLS List References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <0374dea8-f8bd-e0e6-d23e-f76051ec4f78@cs.tcd.ie> Date: Wed, 23 Oct 2019 22:12:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mwys8JQGDZupAMTIVtw7pZTKpI84iEg8R" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 21:12:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mwys8JQGDZupAMTIVtw7pZTKpI84iEg8R Content-Type: multipart/mixed; boundary="1g0EkFFxsZUE8ipjXD2TzyGluafSKkznB"; protected-headers="v1" From: Stephen Farrell To: Ben Schwartz , Watson Ladd Cc: TLS List Message-ID: <0374dea8-f8bd-e0e6-d23e-f76051ec4f78@cs.tcd.ie> Subject: Re: [TLS] draft-ietf-tls-esni feedback References: In-Reply-To: --1g0EkFFxsZUE8ipjXD2TzyGluafSKkznB Content-Type: multipart/mixed; boundary="------------95715CCA4993FCB55B482425" Content-Language: en-GB This is a multi-part message in MIME format. --------------95715CCA4993FCB55B482425 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/10/2019 17:13, Ben Schwartz wrote: > On the topic of radical suggestions, here's another one: > https://github.com/tlswg/draft-ietf-tls-esni/pull/186 How about a variant like this (which is maybe close to your most recent email, not quite sure): Names < N octets: pad those to N. Names >=3D N octets: hash those and pad to N. With N ~=3D64 I think that'd be ok, assuming we do some checking that N covers a sufficient percentage of names in real use. I think the WG could easily make the case that if some web site really does need/want to hide in the crowd, they just better not try do that with a gigantic DNS name. Cheers, S. >=20 > In brief, this replaces the variable-length name with a fixed-length > hash, plus some accommodations to allow *.example.com, > *.*.example.com, etc. >=20 > My hope is that this design would work in the architecture described > by Watson, while saving ~220 bytes in each ClientHello. >=20 > One interesting feature of this design is that it doesn't require each > wildcard domain to publish any unique DNS record. Instead, all > third-level wildcard customers can share a configuration, all > fourth-level wildcard customers can share a configuration, etc. This > distinction is not visible in the TLS handshake, so the anonymity set > is not reduced. >=20 > On Wed, Oct 23, 2019 at 10:53 AM Watson Ladd wr= ote: >> >> On Wed, Oct 23, 2019 at 7:35 AM Bill Frantz wr= ote: >>> >>> A perhaps radical suggestion: >>> >>> Make the server name field fixed length e.g. 256 bytes. Longer >>> server names are not supported and clients MUST NOT send them. >>> (Both client and server can't use them because they won't fit in >>> the fixed length field.) >> >> The limit of server name in DNS is 260 bytes, so that limit already >> exists. No reason to shorten it elsewhere! >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> >> _______________________________________________ >> 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 --------------95715CCA4993FCB55B482425 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----- --------------95715CCA4993FCB55B482425-- --1g0EkFFxsZUE8ipjXD2TzyGluafSKkznB-- --mwys8JQGDZupAMTIVtw7pZTKpI84iEg8R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2wwjEACgkQWrL68XsX K+oX6hAAroy3E3V+Qm+eCN2Re24vtwqVqjioDHmNUO5oUYcJfQ4YCZBXqLVbNsMd amae0bEP+roWBZevvpxmcskjZshFV2iM0Ak/u7OGcwGlmMeb0zq8YEVru7C6CjbR e58Qm6Zceza3OA0r3qHxasCybLzIzt7pIW86+nC91vAu6KZUu9KJ71tQ3xYsI32o 4EpK6Vhx9QlI5QjdfhD7Ca2fZ/iDxN6awQ+fWTESERNP10nfUnTu/eN0nkn2J002 jFL4Ibm2sWhyI9lJ6Vz/hcC0W/EYCiNmcTvV5Z5q5SEC/wNm0GxhhQsh+EICizGK sRc0OOLjJe3Bv0fVj+DS6+L/Ovl8D7fmL+XeLQMl+hIryb3xHDVlcufBEW55iRvF +j530+/oNvgPMZn601hvqLiL5C1YkugcOhiSuiYv4Koh3oN9UyfEhLfrZdxCfWIi 9PovV2Zqp82l8RrVf3SfQtmd8fPmQswOYzxNS+QyJphqzOJKSZG06bmey4zwnpO9 jKyJaWf6YC9cLelcv8RY81z5LjI+xpCkPPA8oh88vhFfzGGLTE3hjsH19DrLvjiP ZeBRdEG9iPP7RPw4wtAxYKMJwc5ODEhS+K3ktrem4avzjZm6yRm7qBnatodrP/ET 0WoURjSYlRKkPGkPh+PMEG6QXwH8ILSjVb5s6dg6VFMASguWKak= =LizY -----END PGP SIGNATURE----- --mwys8JQGDZupAMTIVtw7pZTKpI84iEg8R-- From nobody Wed Oct 23 14:46:16 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D647120106 for ; Wed, 23 Oct 2019 14:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=OvhR4MdA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iVbY+Amk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQAXk6217BbC for ; Wed, 23 Oct 2019 14:46:13 -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 AA253120100 for ; Wed, 23 Oct 2019 14:46:13 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id CC14421F2E for ; Wed, 23 Oct 2019 17:46:12 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Wed, 23 Oct 2019 17:46:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=VvQkektZMDMONZk7vIbXvg/Ibgy5ufx FZ/K5iwbWU10=; b=OvhR4MdAxT6otmftu4lI5Ws5Ey8aTR1Q3m20gefP0Cn6dVz 28Elxkc2c1rygQVvP3HwFhQQn46tWyYXt/x4Pd0ledhPKXzwRpC8HxVoKn4wEgdb PjdwfZ7BaWnhSsjEXvz8goNnNUBaXjoHUzmB/aog9vM7FaLImJKSqcFGsoKzr5Og 5dxt1shqAhskOHBI4qQVNWZmav2HNPeYIuXyc9igPIMuCf1UtlqT/TV5rzOq1bok d3rCy7UFCNZ7KIDL11CE8nskTRkRzN7ZcbskoRTmcepslhMzolBdi65qOB9KBsv6 naJzkMA4e8onWzekXTjGYtF8Roi4wMqdapB5Cmw== 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=fm1; bh=VvQkek tZMDMONZk7vIbXvg/Ibgy5ufxFZ/K5iwbWU10=; b=iVbY+AmkkbYAGYxsppnzM4 /eu10nxnF3PH2KdtcF8fx0v/oLlmm6DJLmJUz1stoqrx/HQZNfosEPJp6eIVugW+ Yo1KbGlhwp2q2MEdyUrCpDkHl7wtYKGadhbGh3L14X7Z0w1lYf/jIdxFjZ+e7WLF l4gbRV+LWiYf1SQrqW84MGMjjajfYK/ahyC/4AztzGOoX3K7IggUh/QMGB1rIAQC Yoe5fsZNunKXzTEkdk274QcR2RUSN4iMNdPNuho3KK1OkCxs6wbNvRpJPFhim9zM wKBCwrTQZl3Ec9243sXQvB1+Uhh0hUZ2Qh2Q1Mrmw1381yR1jWas1/OPUNZBIHUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledtucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttdertderre dtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggr phhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvghtnecu vehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8EEBD3C00A2; Wed, 23 Oct 2019 17:46:12 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: In-Reply-To: <0374dea8-f8bd-e0e6-d23e-f76051ec4f78@cs.tcd.ie> References: <0374dea8-f8bd-e0e6-d23e-f76051ec4f78@cs.tcd.ie> Date: Wed, 23 Oct 2019 14:45:52 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 21:46:16 -0000 On Wed, Oct 23, 2019, at 2:12 PM, Stephen Farrell wrote: > > > On 23/10/2019 17:13, Ben Schwartz wrote: > > On the topic of radical suggestions, here's another one: > > https://github.com/tlswg/draft-ietf-tls-esni/pull/186 > > How about a variant like this (which is maybe close to your > most recent email, not quite sure): > > Names < N octets: pad those to N. > > Names >= N octets: hash those and pad to N. > > With N ~=64 I think that'd be ok, assuming we do some checking > that N covers a sufficient percentage of names in real use. For this and other proposals, it seems there's different assumptions being made. I'd prefer to not make any change absent further analysis with clear guidance pointing towards a safe policy. Absent that, the safest approach (260B) seems prudent. > I think the WG could easily make the case that if some web > site really does need/want to hide in the crowd, they just > better not try do that with a gigantic DNS name. Why would such a site use ESNI at all? Best, Chris From nobody Wed Oct 23 14:57:51 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7757112008B for ; Wed, 23 Oct 2019 14:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 QECe5ZcwhG1a for ; Wed, 23 Oct 2019 14:57:46 -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 463BA120086 for ; Wed, 23 Oct 2019 14:57:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A7F39BE58; Wed, 23 Oct 2019 22:57:42 +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 zJdSlNVHvZoZ; Wed, 23 Oct 2019 22:57:40 +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 C2187BE2F; Wed, 23 Oct 2019 22:57:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571867860; bh=w/DnXOhQJ8nxKqJFRFN9kzodJ4pHMgGfrMkOO/9+Wlc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=4UoCQlpquexKFrwxYUpnRQUM5Guuz4jpGuJ62UrpYKUHuAdeNWTCB53TDfduzBdZ/ 5Sjxqet8dlRQsozU/oBWCdofMW2mtHf+J2eaNHzaIcU9Zjr3/T9DdVUQMtKKHMVyz+ Zwfl4H2NopXxxnmAdCclBsmWXysGfKKJcY25KBzc= To: Christopher Wood , "TLS@ietf.org" References: <0374dea8-f8bd-e0e6-d23e-f76051ec4f78@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: Wed, 23 Oct 2019 22:57:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rztXK4PBVTOtuXt7JKLedsopKNSbSAlmt" Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 23 Oct 2019 21:57:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --rztXK4PBVTOtuXt7JKLedsopKNSbSAlmt Content-Type: multipart/mixed; boundary="1VtqHrCo4O2LN7dOklyC8GD8hbA0OxK2p"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" Message-ID: Subject: Re: [TLS] draft-ietf-tls-esni feedback References: <0374dea8-f8bd-e0e6-d23e-f76051ec4f78@cs.tcd.ie> In-Reply-To: --1VtqHrCo4O2LN7dOklyC8GD8hbA0OxK2p Content-Type: multipart/mixed; boundary="------------8CABDD826D43592717E5DA56" Content-Language: en-GB This is a multi-part message in MIME format. --------------8CABDD826D43592717E5DA56 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 23/10/2019 22:45, Christopher Wood wrote: > On Wed, Oct 23, 2019, at 2:12 PM, Stephen Farrell wrote: >>=20 >>=20 >> On 23/10/2019 17:13, Ben Schwartz wrote: >>> On the topic of radical suggestions, here's another one:=20 >>> https://github.com/tlswg/draft-ietf-tls-esni/pull/186 >>=20 >> How about a variant like this (which is maybe close to your most >> recent email, not quite sure): >>=20 >> Names < N octets: pad those to N. >>=20 >> Names >=3D N octets: hash those and pad to N. >>=20 >> With N ~=3D64 I think that'd be ok, assuming we do some checking that >> N covers a sufficient percentage of names in real use. >=20 > For this and other proposals, it seems there's different assumptions > being made. I'd prefer to not make any change absent further analysis > with clear guidance pointing towards a safe policy. Absent that, the > safest approach (260B) seems prudent. Fixed at 260 octets is better that what we have and safest, yes. I think we could do better though, but agree that proposals for that need analysis. >> I think the WG could easily make the case that if some web site >> really does need/want to hide in the crowd, they just better not >> try do that with a gigantic DNS name. >=20 > Why would such a site use ESNI at all? My hope is browsers and sites might all just use ESNI eventually. But I think we are ok to consider that over-sized names may face some implementation obstacles. I suspect, but don't know, that hash based approaches are liable to break server-internal APIs in various ways. But that might be ok, if the numbers are small enough. Cheers, S. PS: Despite raising the above variant, I still think "behave the same as DNS query padding as far as possible" is still the right approach to try next. Given DNS query padding works, that is I think, as safe as a fixed use of 260 octets. >=20 > Best, Chris >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------8CABDD826D43592717E5DA56 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----- --------------8CABDD826D43592717E5DA56-- --1VtqHrCo4O2LN7dOklyC8GD8hbA0OxK2p-- --rztXK4PBVTOtuXt7JKLedsopKNSbSAlmt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2wzNEACgkQWrL68XsX K+p6VA//Q9KDudCtMCW36flaC2SbfYljp9hUFCD6zAlb4QRMwRWtP7xicWZabKen 8s+/EypmIgJZhxtWj9U/+nn9faQkpC+YeBF+DYSI1B83CLyuAZxA/p+hAKjbxt1b H6OrgplQz7g4qJxbQr1Sl+tMUeEWEGTzK+nooudMJIEvBUZNOHOA565QhDLYQMdA fUElWXrzwGf3KPgfAoOHY6W3NtBnldSqd+EXe0wy4DaG18MexV3dAigQLJsHhYWS /1y13mi3G9iLUCzzgh43E4lAyTlxt7F66dmE+hBDskkujMXUSPlXIqGepb61js/m +AI2B9BgtIPA6dRSERHqMyZmWgDnoVnmZpEpX7n5jpWIlt/YoAHDqnkkN1hVmE4f WKd0bZrBi9KtE0NPY5KopKLHdTd6FgC61mxCkdFSsrFQrqUKtL9+Oe1BlfBdeoug o4RjwIMu4W88UEq4vCmFTMMrR1oTtVRKcHd1JXnPOIP+q9UvXBx/c31lU9kJwYTS I1W50BLHiBkz1Ew40ZCfuogdFtD0WJkzYbiVbtR1jpKZ0utfJAHx/QpfCrAQ0s6A BQ8v/glxo2N9/X8KXgaj/K1rHKdcv4jYYBmF43H6S5ti6A87N05qKg7MBxf0fuID WtYX6klA0Lmq/csiY9sR52kmARmC1gJyWDqTAV9xj1oukNL+gMA= =HFhB -----END PGP SIGNATURE----- --rztXK4PBVTOtuXt7JKLedsopKNSbSAlmt-- From nobody Thu Oct 24 14:04:54 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27CA120108 for ; Thu, 24 Oct 2019 14:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 QwxKFJ51EZdy for ; Thu, 24 Oct 2019 14:04:43 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (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 01683120847 for ; Thu, 24 Oct 2019 14:04:43 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id d126so5638395vkb.1 for ; Thu, 24 Oct 2019 14:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pr+xND91aNmtTUgHO4XUbtJPSnItiUPhc0Qm0Z0JKvM=; b=woGG/8lWr0VR3qqZocsZycR+fYUCCi0CyW4r5gLG2thv1dBIqDBiPpSxoIluHECc+p KORDGPyGqi2xRzL+Zh8m/GKfPQLjdd2UuvYX/OikQBPesHxu4PgVvkL0qHnwU5nUqADx FP9unC2q/UB33Wr+Mtkx4VJ7CeSK9bdASG4MI= 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=Pr+xND91aNmtTUgHO4XUbtJPSnItiUPhc0Qm0Z0JKvM=; b=pVHyj3Fnv6omXAE54XH3Q95PXlczb9LwV1Ei6KYD+LASxTvnnkTluZAShKxjDejGwZ EiGiIWWPCo7Q6sJ3iqVtJbpg45Pv89rbL/1pfnWblSwAmy+yeH8v6/8zOcM2Zv3ZYPte pydywtmjKdc5eo+wPjaIUQVxjUsZqkhoWLgOzCQM/F7fYD2rdKHZDYfS6blTHK4QmGgi MVeSu6UKNClCNcR/PlH+xqTGBRnfEoP8yrnsUnN453bOEagkF86YYJI3CXUL8df79rFY M9y3bTrFo6KdBNCMaa0eYEWNeAdj1ZIjvQG8H+VpL48fcHpW0tYE6I3FpZfTQU/7hSvY aqtw== X-Gm-Message-State: APjAAAVzWtQiFdPJB6zJ+T7CHqmzgG8tsYuJ291l+GRjY5RsKoBs2bLp x7wuGpFdHc50cNXPX8XtEax4jmxl5yztNGhX/ROgRQ== X-Google-Smtp-Source: APXvYqzxx38u17VojxjQH0RPiEDMgt4oxT611jIMvjTiYXlNJUPYum3Zhj0LyTrT+Tmq/A7sndcb9Fe+c4Ub1ofGC+w= X-Received: by 2002:a1f:95ce:: with SMTP id x197mr248199vkd.19.1571951081635; Thu, 24 Oct 2019 14:04:41 -0700 (PDT) MIME-Version: 1.0 References: <29dbb36a-73d4-4e09-9906-d297e27a1f35@www.fastmail.com> <7d15a1f1-c646-43b7-b5d6-c89ea4b4b615@www.fastmail.com> <975f9484-7206-469d-a57a-7b8dc67bd53e@www.fastmail.com> In-Reply-To: <975f9484-7206-469d-a57a-7b8dc67bd53e@www.fastmail.com> From: Nick Sullivan Date: Thu, 24 Oct 2019 14:04:25 -0700 Message-ID: To: Martin Thomson Cc: Watson Ladd , TLS List , David Benjamin Content-Type: multipart/alternative; boundary="000000000000d383bf0595ae6159" Archived-At: Subject: Re: [TLS] Delegated Credentials Question about PSS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 24 Oct 2019 21:04:52 -0000 --000000000000d383bf0595ae6159 Content-Type: text/plain; charset="UTF-8" On Mon, Oct 21, 2019 at 3:34 PM Martin Thomson wrote: > On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote: > > In TLS 1.3 it seems to have been assumed this wouldn't happen and we > > could split signature algorithms from signature algorithms cert. > > > > If that's not actually the case it affects more than just DCs. DCs are > > a good way to restore extensibility if there is a problem here, > > provided we can come up with a solution. > > Yeah, I think that this is the clincher. > > FWIW, in Firefox we have a separation between TLS and the certificate > validation logic. The latter cares about the SPKI of all certificates in > the certification path because it applies policy related to choice of > keys. As a result, that code cares about DC also. So we don't really get > to advertise an algorithm until it is supported in both places. For that > reason signature_algorithms_cert, as much as it is intended to address this > sort of split, doesn't really help us. > > Logically, there is a split between the certification path construction > and the policy pieces, and the structure of the code recognizes this, but > in practice they are somewhat coupled. > This makes sense. In the current text, signature_algorithms_cert only applies to the cert chain, which is fine. It's slightly annoying that supporting new SPKIs in DCs makes implementations have to support the new SPKI in certificates, but it doesn't seem like too big of a deal. I'd be interested in hearing from other client implementations on this issue (cc: David Benjamin). --000000000000d383bf0595ae6159 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2019 at 3:34 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
On Thu,= Oct 17, 2019, at 14:32, Watson Ladd wrote:
> In TLS 1.3 it seems to have been assumed this wouldn't happen and = we
> could split signature algorithms from signature algorithms cert.
>
> If that's not actually the case it affects more than just DCs. DCs= are
> a good way to restore extensibility if there is a problem here,
> provided we can come up with a solution.

Yeah, I think that this is the clincher.

FWIW, in Firefox we have a separation between TLS and the certificate valid= ation logic.=C2=A0 The latter cares about the SPKI of all certificates in t= he certification path because it applies policy related to choice of keys.= =C2=A0 As a result, that code cares about DC also.=C2=A0 So we don't re= ally get to advertise an algorithm until it is supported in both places.=C2= =A0 For that reason signature_algorithms_cert, as much as it is intended to= address this sort of split, doesn't really help us.

Logically, there is a split between the certification path construction and= the policy pieces, and the structure of the code recognizes this, but in p= ractice they are somewhat coupled.

This= makes sense. In the current text,=C2=A0signature_algorithms_cert only appl= ies to the cert chain, which is fine. It's slightly annoying that suppo= rting new SPKIs in DCs makes implementations have to support the new SPKI i= n certificates, but it doesn't seem like too big of a deal.
<= br>
I'd be interested in hearing from other client implementa= tions on this issue (cc: David Benjamin).

=C2=A0
--000000000000d383bf0595ae6159-- From nobody Thu Oct 24 17:28:53 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A12A5120019 for ; Thu, 24 Oct 2019 17:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=R4D3tvFY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cZZDnqnc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB2POPYJ51qh for ; Thu, 24 Oct 2019 17:28:49 -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 26F5112008D for ; Thu, 24 Oct 2019 17:28:49 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7A00621AFB for ; Thu, 24 Oct 2019 20:28:48 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 24 Oct 2019 20:28:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=m4a86lDCtNs8kgULTrioqfkOk9qIi4JP6iDTk7s/02k=; b=R4D3tvFY W34faENs2z60A1Ldin64Qw8QVebpl/MmM+idyWYCOu+HYTBHLWQcq4CuNnJoXaek kJMP9U8R6mGLoMX379yi9QOq++KP/P/CPt2GgT3jylTx6Ox8wyxCZXhUfwwtnACE X+uvc9CbjUEZvlSvmPyTyQHJ5SxPX6qwXgD4JUunIfMrQJiimbhfN+/1Q3jADvHo 4wNxJSk2YZKnMJGCAt47S1fyq2DuOw+K+KFZ20c2nGmjd6SbLH5PFDPwFZVqsisw yF5VwyKJofUgMtuuQl9hpWiIUOHNlED1ATbVEMxOc3Vy1ZFucr67S4Rbndj26ooC sn9UbWUfcKUnHA== 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=fm1; bh=m4a86lDCtNs8kgULTrioqfkOk9qIi 4JP6iDTk7s/02k=; b=cZZDnqnc/cBlLts33/YuAn3CJGGZ9EAPA1Yqol/Hg0kqt yWvQOFr785+OOxhW6FXuwzAaPJU93aycPYVdHEoqWzOSTxQtwGDVK/2Yp6n1BZoD 2eT7BV42JLwIX/YLRZij6sEbgmIn9JwxY+Y/+lsIOwDYOYL3ipdf88piwNIiOyuT P5gRcuP155rK1euu9yFZxvfHzXX/YGn2iHElfpIFhWZqdkHLqPfYL/bW/IGK7waF Tp8rDOn4TTDjDjjHOnw1wetww6arrY8ZpiSgAIKL0L7KlrshA/JM5hJF/inCd/wt VULkg49c8YrmGtV29yumgtvTSdPXDEjYZ1fNDUtPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrledvgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhg sghithhsrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A19B3C00A1; Thu, 24 Oct 2019 20:28:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-470-gedfae93-fmstable-20191021v4 Mime-Version: 1.0 Message-Id: Date: Thu, 24 Oct 2019 17:28:26 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] Adopting HTTPSVC for 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: Fri, 25 Oct 2019 00:28:51 -0000 Hi folks, DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of doing the same thing, I've put together a PR that drops the custom ESNI RRType in favor of this more general (yet feature compatible) Resource Record: https://github.com/tlswg/draft-ietf-tls-esni/pull/187 Please have a look and comment before next Friday. We'd like to land this before Singapore. Best, Chris (no hat) [1] https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s From nobody Thu Oct 24 18:19:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4C5120096 for ; Thu, 24 Oct 2019 18:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=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 O88GRIA-ZB45 for ; Thu, 24 Oct 2019 18:19:05 -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 45475120018 for ; Thu, 24 Oct 2019 18:19:05 -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 x9P1Gj8F019712; Fri, 25 Oct 2019 02:19:00 +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=m7L/Xjy7VVJUwemu9J+wDuF3APyNv98UwOcc1x/8oOA=; b=osCg0c8do7xBXiyZtAU/KXwG4B4YqD6T+Go0X4vSNwzdZouRxEZe1iKH31KSLqSFvvVa sk8wt8VCJ9W50jFkvXrwIPgGAYEVXnn7+zZah6jbVQhSxtFri2k5XHiIDF2X/vebsoD0 Y27dYcYMsFDhYJO35N9jbjgdw9s5TajYtBqOU+Ixhjlgt+0BXkEgWLDhsSZ/WUnmYy6I W2ZfdXCHtVxL9tiIQMF+dymvqbELSVDMgGz5JttDZpEaz9OBc5ZqYUqt5WtnXVh47GVk EZvAZO94kNe8C902e1Cwrcjt3Y0aBxa2qiJ/Z8/Wk6D1rZuyIrl3iXvL1A7CUERXkQEJ Sw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2vsyugn4tn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 02:18:59 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9P1HosE009208; Thu, 24 Oct 2019 21:18:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 2vqwtwrh2y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 24 Oct 2019 21:18:58 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 24 Oct 2019 21:18:57 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Thu, 24 Oct 2019 21:18:57 -0400 From: "Salz, Rich" To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] Adopting HTTPSVC for ESNI Thread-Index: AQHViss9hnX3VwL9IUyuhU4A+mws4KdqjsKA Date: Fri, 25 Oct 2019 01:18:57 +0000 Message-ID: <01B37C96-FDA8-42C0-AC92-C7FC77C03EAD@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.127] 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:, , definitions=2019-10-24_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=648 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910250012 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-24_13:2019-10-23,2019-10-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 clxscore=1015 priorityscore=1501 malwarescore=0 mlxscore=0 bulkscore=0 mlxlogscore=639 adultscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250012 Archived-At: Subject: Re: [TLS] Adopting HTTPSVC for 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: Fri, 25 Oct 2019 01:19:07 -0000 U28gYSBnbG9iYWwgcmVwbGFjZSBvZiBFU05JS2V5cyB3aXRoIEVTTklDb25maWcgYW5kIGRlbGV0 aW5nIGEgbm93LXJlZHVuZGFudCBzZWN0aW9uLiAgTG9va3MgZ29vZCB0byBtZSENCg0KPiAgICAg ICBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvZHJhZnQtaWV0Zi10bHMtZXNuaS9wdWxsLzE4Nw0K DQpWZXJ5IGhhcHB5IHRvIHNlZSB0aGUgcmUtdXNlIQ0KDQoNCg== From nobody Fri Oct 25 03:29:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E3F12083C for ; Fri, 25 Oct 2019 03:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 t77cA3NTEOrY for ; Fri, 25 Oct 2019 03:28:59 -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 DC83812083A for ; Fri, 25 Oct 2019 03:28:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AF561BE2E; Fri, 25 Oct 2019 11:28:54 +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 JHHtoHcDAA3i; Fri, 25 Oct 2019 11:28:52 +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 CA047BE20; Fri, 25 Oct 2019 11:28:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1571999332; bh=Uxc2Sg5I/1xuZTr7/CddTSEFBGcT30xPV3el4IjS5Y4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=M5ikLHTxzzfArk18s5wDopxv8CUuRXos0t1HtMAbt0E/dpQoqoc1quxAK6ZLuJZA3 d5zvwaqcW8ixylg8EbPBQPrQxYMG2sCC6fSDdcn8/ybMDxvjYoPClRSYLfELyVEfHE 2+wocVw/nOlELlTMpT7TF3GD418yPa+LnHB5EWkY= To: Christopher Wood , "TLS@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <52c0ae70-4bcd-9135-294a-126bc7e13bf1@cs.tcd.ie> Date: Fri, 25 Oct 2019 11:28:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="N4F559HIW6tXeFbP3TA8SsGyGLJ0c1qxO" Archived-At: Subject: Re: [TLS] Adopting HTTPSVC for 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: Fri, 25 Oct 2019 10:29:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N4F559HIW6tXeFbP3TA8SsGyGLJ0c1qxO Content-Type: multipart/mixed; boundary="jTyOoiKSdENcrnFwkaW7wHaqKmEdUHHaA"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" Message-ID: <52c0ae70-4bcd-9135-294a-126bc7e13bf1@cs.tcd.ie> Subject: Re: [TLS] Adopting HTTPSVC for ESNI References: In-Reply-To: --jTyOoiKSdENcrnFwkaW7wHaqKmEdUHHaA Content-Type: multipart/mixed; boundary="------------C11F2F3DC5FF8510BA45A3D0" Content-Language: en-GB This is a multi-part message in MIME format. --------------C11F2F3DC5FF8510BA45A3D0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 25/10/2019 01:28, Christopher Wood wrote: > Hi folks, >=20 > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of > doing the same thing, I've put together a PR that drops the custom > ESNI RRType in favor of this more general (yet feature compatible) > Resource Record: >=20 > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 >=20 > Please have a look and comment before next Friday. We'd like to land > this before Singapore. I'm supportive of this change, on the assumption that browsers are really going to use HTTPSSVC. If that lands as-is, please bump the version to ff04 and I don't see much benefit in changing from ESNIKeys to ESNIConfig (seems more likely to confuse than help to me). Going further, I think we ought also take advantage of this to simplify the ESNIKeys/ESNIConfig structure. We don't need to do that right now but we could. There are two related simplifications that'd make sense to me: - remove the version field and encode that in the HTTPSSVC label (so it'd be something like esnikeys05=3D"/wElr6L2ACQAHQ...") - I think that'd lead to fewer cases where HTTPSSVC code needs to understand what's inside the ESNIConfig structure. - similarly, remove the extensions field from ESNIConfig, and require a new label in HTTPSSVC if something new is really needed Cheers, S. >=20 > Best, Chris (no hat) >=20 > [1] > https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s= > > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------C11F2F3DC5FF8510BA45A3D0 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----- --------------C11F2F3DC5FF8510BA45A3D0-- --jTyOoiKSdENcrnFwkaW7wHaqKmEdUHHaA-- --N4F559HIW6tXeFbP3TA8SsGyGLJ0c1qxO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2yzmMACgkQWrL68XsX K+otmg/6Am1tw2JPgSslh3LhmI/z9NU1ju0uSDiAUI6sonWf7OjvFbOFMVB06JU1 6VkI+PFkEmYcm6XLsEfaQuDZuBrYXQRgsx2m+82qdrAkg2ClNS49dcJoSiiDkr5F +ZFdQQvHXTGCFqsotIVG78DuV48iAZlu6S+bbp1z8S8AaN5L/MW3ah2jWNlX+Buu u1gsjWil7/dLaHIUTTYbN/Cp6GlGwHX3jy/rdYLrKxR5W//PZikr09JeXRKFqrle 5PCnQvMi/Atnr0Tkr28hOLc8w21jItm/qISDprGkOfbQyYD3ZIeZqOUoE9N1nxXk dfn1V0ysGC1kxcbLsQbhW2QBEQDc0OBKlWkAIKNS9SUPJomvy5PTwk+gxN+WkXfR ITfzpMPuelNd5k3SRTgIR+mzTOUkbzw3Zvf38I9npXZWXkLbdjnoJCyQg13hFsO1 2rvQdaroYalvR4LJnCtmD8IXr0lxM3zkUdv5UGZSsbtLN4mW6stNMwTIdXc8m+GU 8/qV2FOOEeZhEGoyNnYDjy04HovZC7p3NeWEXGkdhllelUQW1KG+EWXHs0w13b1e SyTQP0rpj7kO4tvCnkgsNM55zF65iafTzgZXPeWzKxGM7mjDPtxUf1CUjvG9Om1i ddEKoqyvQtlvyFoJMXdNqPD/lBYx6nLEhw9QmxZD2MLF/R70HXk= =xWds -----END PGP SIGNATURE----- --N4F559HIW6tXeFbP3TA8SsGyGLJ0c1qxO-- From nobody Fri Oct 25 03:55:14 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE882120851 for ; Fri, 25 Oct 2019 03:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 eJ24g88EMIzP for ; Fri, 25 Oct 2019 03:55:10 -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 0660412085F for ; Fri, 25 Oct 2019 03:55:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8E8FCBE24 for ; Fri, 25 Oct 2019 11: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 1KIG9URcK1Po for ; Fri, 25 Oct 2019 11:55:02 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A4CA3BE2E for ; Fri, 25 Oct 2019 11:55:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1572000902; bh=WqPUdzcxl2GUyMyzqSuEUHk4oiumAVRYIA+0QZLyQN8=; h=To:From:Subject:Date:From; b=tl7uvvpw4cdqmqt9R1DzsmPdW4ZsgiBlnIAFamTbN5qDLDh2FpYVWpjU6RyNKyPgc ulCRZ39LvB/vC8+1BucV7avLzcgJCMvLg2IW8Tfn0x6BWUVzYgp/t0oBMxwzDy2Czb b4XRHTnzgmXqfs4LY02cI0etZZrL1HdEykprz0dU= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 25 Oct 2019 11:55:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zZyzQxvUahdTei2FOCpImJHoEhG5l405x" Archived-At: Subject: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 10:55:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zZyzQxvUahdTei2FOCpImJHoEhG5l405x Content-Type: multipart/mixed; boundary="oEv96Ms7COBqCRpXFZd2jUFm3K7nP1Qvu"; protected-headers="v1" From: Stephen Farrell To: "tls@ietf.org" Message-ID: Subject: ESNI PEM files --oEv96Ms7COBqCRpXFZd2jUFm3K7nP1Qvu Content-Type: multipart/mixed; boundary="------------5BB203F880523A7D762E6B18" Content-Language: en-GB This is a multi-part message in MIME format. --------------5BB203F880523A7D762E6B18 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, To date, my ESNI code [1] has been dealing with files containing the binary encoding of ESNIKeys and a separate PEM file containing the related private key. As part of getting nginx to work with ESNI [2], it'd be easier for me to deal with a single file containing both private key and the ESNIKeys (or ESNIConfig) value. (One of the upstream maintainers didn't like how I handled configuring ESNI, so the change is really to make him happier, but I think it's likely a generally useful thing:-) Since mixing binary and PEM encoding in one file would be ickky, it'd be nice if we had a PEM file convention for the public keys used in ESNI. And of course, it'd be much nicer if everyone did the same thing here. What I'm coding up now would handle files like: " -----BEGIN ESNIKEY----- /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAX= O6j /gAAAABc995+AAA=3D -----END ENSIKEY----- " =2E..where the content is (unsurprisingly:-) a base64 encoded ESNIKeys. And if both the private and public components are in one file, it'd look like: " ----BEGIN PRIVATE KEY----- MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va -----END PRIVATE KEY----- -----BEGIN ESNIKEY----- /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAX= O6j /gAAAABc995+AAA=3D -----END ENSIKEY----- " I'd be happy to change that however increases the probability that other code bases do the same thing. If this is useful, I could do up a PR with a bit of text saying to use "ESNIKEY" (or whatever) as the label when storing these things in PEM files. Given RFC7468 documents other PEM file things, it seems reasonable to do the same for ESNI. Cheers, S. [1] https://github.com/sftcd/openssl/tree/master/esnistuff [2] https://github.com/sftcd/nginx --------------5BB203F880523A7D762E6B18 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----- --------------5BB203F880523A7D762E6B18-- --oEv96Ms7COBqCRpXFZd2jUFm3K7nP1Qvu-- --zZyzQxvUahdTei2FOCpImJHoEhG5l405x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2y1IUACgkQWrL68XsX K+pYlg/+LdMvMsgNWtKmPQUUjx8oAG+sChd6cBXQHw8N8M4H4PHTLAwCMkE1gd4e llmMAU5n75EDHVAkoSkokoR/psVQHVkNhkEzs6/D/fVlewwygOaAhoBmHwfCtNaB TseQOZvPi62Y4J3JAcWsqMxPTrNjlmewTyFlA2UDPm1VECh2VodfqktG73motxQO EpjoywVfQHrnLfeY8KMlNmbflxqADU6vXV8thrQ/CaJmjr0ZjyEurrcZ99JIWMWc 6Zsc7frz4y7sCP5FtQ+NDDX6WnuwGInazruKQDVeEKmZb38I+/gN7xnA17Ng2YR6 qtHX9zJHuCqMn6S4opXrsVKr+NZYM+kYvWJQE28NcxOjk3NxR0rqLZQSvgvEBTHA WzbUpBL/T44t9eVKfDSGzb5pANWWj5uhk3NmWfSkfHbNKc4b3w3kgUcOWPuIDPuF hb7F3dN1CKzLoQaFFgVuhT5oihITqDfqWD95rnuJFn8JysTGTMc+iurya0vlHODi 1BAEbYrcsnEBUFwhpjQdhRB4hDRQjZPkxBQXpu0bWWnS1gv3aLIHoppcIGu4dAvW 0md2a12MxVb2h9pJ3cg0qeYnG+mi0EsHFL6MeIGYXEpRA2tkGDpv1eSw2Zt7ywnP iWohr99hJhamxnqXBKTxbQBMauqzpXS8MceUXVaPQImyUuoo1lI= =UbtU -----END PGP SIGNATURE----- --zZyzQxvUahdTei2FOCpImJHoEhG5l405x-- From nobody Fri Oct 25 05:25:59 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7412086F for ; Fri, 25 Oct 2019 05:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=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 1nrh5KpkBH5o for ; Fri, 25 Oct 2019 05:25:55 -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 CB25912007C for ; Fri, 25 Oct 2019 05:25:55 -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 x9PCMBBL023302; Fri, 25 Oct 2019 13:25:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=n7xrvgOHmizzKy1hyuok8FiZdjA45n2VasSCyaF0WVc=; b=IPBLly6GR6RkZAGKfXvinuOOMcBJNEyDikMIl11/Rcrn8N2GS+Ez3Y6ml2mQFhRxJuoV oIwZQFxjCslhGk+zRUxuu8xnDP0ZqZTT7Lb1rcxs/LVV4b7ezxvpTNsFBdOxVsnku5DV oIpns88zwK0QRh4Egl+y97yGgqIsBC1JN0tCr8+K7Zccm2BD35E3tsVPt8ktMscEO9yJ N6MWvXxsLEjIRCCSjA9VkQ6K5Jyp9tczCcIeNzcwMdd5SYqtBh7qAcBpxe4pgQOBNFGS Sue20c1PPr8MSDo95MQIBzyjsWCWB8qzcBmP/TeHBHQdw4bqJibv2pen2E3iDcraWmVC eA== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2vqt14f0kb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 13:25:49 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9PCH8Ir018037; Fri, 25 Oct 2019 08:25:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2vqwu2kj28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 08:25:46 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 08:25:36 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Fri, 25 Oct 2019 08:25:36 -0400 From: "Salz, Rich" To: Stephen Farrell , "tls@ietf.org" Thread-Topic: [TLS] ESNI PEM files Thread-Index: AQHViyKz+fstIng8CkOfaQuz09MBJadrSFSA Date: Fri, 25 Oct 2019 12:25:35 +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.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.80.204] 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:, , definitions=2019-10-25_07:, , 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=760 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910250117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-25_07:2019-10-25,2019-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 mlxlogscore=766 spamscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 mlxscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250118 Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 12:25:57 -0000 SXMgdGhlIHByaXZhdGUga2V5IFBLQ1M4PyAgSWYgbm90LCB0aGVuIHBlcmhhcHMgIkVTTkkgUFJJ VkFURSBLRVkiIGlzIGJldHRlci4NCg0KT3ZlcmFsbCwgeWVzLCBwbHVzLW9uZS4NCiANCg0K From nobody Fri Oct 25 05:50:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C7712086F for ; Fri, 25 Oct 2019 05:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 qrMPmeAMaVxT for ; Fri, 25 Oct 2019 05:50:29 -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 0BD0F1200B5 for ; Fri, 25 Oct 2019 05:50:29 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id r5so3073623qtd.0 for ; Fri, 25 Oct 2019 05:50:28 -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=ymSaXUJUYTL7Z8kJQDZQO5IQgxrbS4PMLxr79eBptiw=; b=XbxrtXgyAAU36bxxGHV92Zlj4RHgfLS3UT3V6UhhZODZnwN3lu1Hy51yyFV5QXgrx+ rjEAxD5F3rwFkW153cEOwsXuPNFa4U0VqIjti3gNZkPlqv5v/G+pqewUNcKCmE3RfxLh GyeAtX0XAdpUNHZxN6FClM18zetL1A5LtaF3Q= 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=ymSaXUJUYTL7Z8kJQDZQO5IQgxrbS4PMLxr79eBptiw=; b=pnQaqUHFsNRMA4fkMKoy15SCvFaJCVEX8o90nvk86ufthNsj9HB5DCSAH3ckQXdV1l jES3ZPBRcs1239+l/kRgXoQ8KIvA7Vqci4dowPGmKvchwBIaG4DTnUUcPTWhz7+mQsxX NVS9ys/0CoBYHQgMpZV1/kBVi1k1lT4TCYgif5nKW+77Y5JEwDLLxhg1D0UytrxtlAaC no6rpduI7Y3zM3OJUPhBe6o5BZiKq/xo0dDmirjy1nno6nFV8CUe8GXVMLSKhWJjarSf AnFhDFrauwyybFMoaLtOrgtP8ffgVPJ6lwechbEashw+I5w8tWQhRNNY1DwTGqkdGWTP tI3A== X-Gm-Message-State: APjAAAXSFqXBt4+CD9BKKqSRawf6LaozKbuzctZgESlnmCqsTBPzgT2P URufCL0dU2Zd9ca3mBxdU+MNgUd8Nyo= X-Google-Smtp-Source: APXvYqxFag8m4ha+8vp+8BEtBqODqi8rdR5TU11gM6ht9MjK481fEfpZ4ZrB+sCNoXo6KGMaqatiig== X-Received: by 2002:ac8:70b:: with SMTP id g11mr2925463qth.66.1572007827815; Fri, 25 Oct 2019 05:50:27 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id 76sm1524175qke.111.2019.10.25.05.50.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Oct 2019 05:50:27 -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 12.4 \(3445.104.11\)) Message-Id: Date: Fri, 25 Oct 2019 08:50:26 -0400 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] TLS@IETF016: Agenda Topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 12:50:31 -0000 The preliminary IETF 106 agenda is out: = https://datatracker.ietf.org/meeting/agenda/. The final agenda will be published later today. The TLS WG will be meeting @ IETF 106 in Singapore. To help the chairs = get a better handle on how arrange our sessions, 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. Cheers, Chris, Joe, and Sean= From nobody Fri Oct 25 05:51:40 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 208FB120874 for ; Fri, 25 Oct 2019 05:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 7hyBpg8QHY1s for ; Fri, 25 Oct 2019 05:51:37 -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 5DD031200B5 for ; Fri, 25 Oct 2019 05:51:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8F93BBE24; Fri, 25 Oct 2019 13:51:35 +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 noIx8Bhnc93P; Fri, 25 Oct 2019 13:51:34 +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 2EF2DBE20; Fri, 25 Oct 2019 13:51:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1572007894; bh=F/SCrClFPPRuBax+5EHwRHtmnkz9HVhQsy2o+7hh4D4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Qfmpee6N1FJiEQ2CEawOka8WP6V+cUaxeK1Qw5mvDVJVH/Ez7GixuAFM9vzzLXSMp OA+QjLRPgiTDq7Gmx/PzqaVfAOoxzBawLB50U8UpOpmAHmjUo/fxpH4cIoug7pRP+/ rFjT+dfzdIjtCE+L6M9Z1wqBqlnJmrFy+3esPouU= To: "Salz, Rich" , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 25 Oct 2019 13:51:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LWjm8xvEkf7PHS409dHCyF6ufZMaEOMX4" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 12:51:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LWjm8xvEkf7PHS409dHCyF6ufZMaEOMX4 Content-Type: multipart/mixed; boundary="wRJOkgDDkp6v9rCJxltNKlHCqgFjembKv"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , "tls@ietf.org" Message-ID: Subject: Re: [TLS] ESNI PEM files References: In-Reply-To: --wRJOkgDDkp6v9rCJxltNKlHCqgFjembKv Content-Type: multipart/mixed; boundary="------------4901EC408D275E2F647DD0B7" Content-Language: en-GB This is a multi-part message in MIME format. --------------4901EC408D275E2F647DD0B7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 25/10/2019 13:25, Salz, Rich wrote: > Is the private key PKCS8? =20 Eh... not sure and didn't ever look:-) It's what I got from PEM_write_PrivateKey() But now that I do look, yep it's a PKCS8 PrivateKey. Cheers, S. > If not, then perhaps "ESNI PRIVATE KEY" is better. >=20 > Overall, yes, plus-one. > =20 >=20 --------------4901EC408D275E2F647DD0B7 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----- --------------4901EC408D275E2F647DD0B7-- --wRJOkgDDkp6v9rCJxltNKlHCqgFjembKv-- --LWjm8xvEkf7PHS409dHCyF6ufZMaEOMX4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2y79QACgkQWrL68XsX K+rCkA/+Io6pOeO4/7UoX1osFdDJmTS+Y/xRHdp0dyWSi/IAf5cQMkzNrGu6VEoQ jd0HPqunwSCRYPp0HBVKe5JVP94A9xHpNm3rhbFLD9bmcnSuymWs9y3svdq+m2t4 neyxcGMYmYbDlX1hfJkztiwxioVY+RtA19NElZLbccmWtycgemRQfK3lw1QWB4m1 O/Yxwe8GDjdzS5ncsnyfFjCzJhv3xWItnRGfyovcHwoUHHbZw5kVDMPJmUQU6qli Z1WPQgtOct39HRaznIxihNoS2oC9g9eOjO5WmFqzOyvMoRhQSY9NmlUCUERk4wlF D7iD1SguPnGZx76+ht5VGu2VhtB/JZbP7MXQAlspTy3D4SacPLw7J8WbzRJM7iZy hOvzyKwMQJlTQ7ORV5034Ukd5H4LPLEdOMm7WS2DxkySAF9DTPXYyjL1d692vtq8 Wdb890By5hc9JZA3BUAu8aJNeLuoixzrYG+O73KJVJoRAy6p827azZXYkZCnfVW5 oBgOGKQ/okwVyThDkgY20UzBWJeHisOZh4TAeDPgY9JYVvTKQLl0VcU16JxPCdRP mzjTK72rVJJxj6fLGX21iqFi2vbhflf3e+eHH/JYTV4wm1QGSZBFCe7brmWF4U7E xSGXEzthVAY3eMmnhFjdZwE4+d0QEne2EQ1SHey9kjOeOgZrWSw= =/puW -----END PGP SIGNATURE----- --LWjm8xvEkf7PHS409dHCyF6ufZMaEOMX4-- From nobody Fri Oct 25 06:04:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8761E120874 for ; Fri, 25 Oct 2019 06:04:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 NWHH93ItXE3N for ; Fri, 25 Oct 2019 06:04:24 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 0C67E12086F for ; Fri, 25 Oct 2019 06:04:24 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id a194so1629306qkg.10 for ; Fri, 25 Oct 2019 06:04:23 -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=X5pGyNEmEIhAAENcADJUpYsGrhn+8+1h2GAjl914SNo=; b=Xf76jzcqwk4kvR7IH8r3GTRNsbYpT9OZ9peO9ivXojEKborC5J40D2VnzOh88cxKXw gPeIKI/+lWQUwU+Z9rTuTvzcJ9PbG9LM5EzOQp9OgI55d2lc+HxlmVOB+xUrrqStklF9 p8NeS45ju2cDrNTfXnzL35DNA+IIuV3BxDnp4= 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=X5pGyNEmEIhAAENcADJUpYsGrhn+8+1h2GAjl914SNo=; b=i/Tdhx0jfIDwcB0kkfb7DsN9VPNcFDEMXq4Ha7u3RX8rnOZXyrRc8Zj8HfoSSfS7Wz HprdTVLPahHT0noeL0v3ZSfdipzJ7b9rrT5qX33jtgVg+9OEmK2oOrtJ/++BsQ2+Y6Df VAqhv8xm4NpgVwh+X0q1Js0JJc9ZrMQ/xXfgi5uT1cMKSkvFjoitMe8mljwdZtVR7ibI sEfSdIeDCgYVnXTRBWW9NsLevAWSp4jcPbXnGw8k3lyXTHLyqesoQS9madEnkR7RSZ4v //sEEGFlAX2YbT0ZNrC/OWo7j/E97ZnPLt3HXZFra9bjdyfZZ1PNrZMifEK9A/rmVHXG Mqzw== X-Gm-Message-State: APjAAAUWBTf6Y00NXiS2IB9bsotUwVkhVkALQ+E2jB2dDoHE2M4jKRtk 3+Q/mvKQgBbW400DU2YEWLkcTD4FFM8= X-Google-Smtp-Source: APXvYqwqOSZq7YTrrJ9mHVTHivEAMKLvEGlrzmpaEo7/mIGVbPzHrr9Jc46GkMUXxfAzpX1l8cdp6w== X-Received: by 2002:a37:82c1:: with SMTP id e184mr2717682qkd.424.1572008662935; Fri, 25 Oct 2019 06:04:22 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.36]) by smtp.gmail.com with ESMTPSA id l93sm1148475qtd.86.2019.10.25.06.04.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Oct 2019 06:04:22 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <586FB0E1-5C8C-474D-952D-A99449F1E54E@sn3rd.com> Date: Fri, 25 Oct 2019 09:04:21 -0400 To: TLS List X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [TLS] Standards Track for draft-ietf-tls-ticketrequests X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 13:04:26 -0000 During my Shepherd review of draft-ietf-tls-ticketrequests, I noticed = that the intended status of the draft is Informational, but the IANA = Considerations sections indicates that the Recommended column is = =E2=80=9CY=E2=80=9D. RFC 8447 requires Standards Action for an = extension to be marked as Recommended. I went back and looked and the = extension has been marked as Recommended since Chris' and David=E2=80=99s = initial individual draft back in April 2018. I think that this has been = an oversight and believe the intended status should be changed to = Proposed Standard. If you think this change is wrong, please let the = list know why by November 1st. Note that this is the final issue before I will issue WGLC. Cheers, spt= From nobody Fri Oct 25 06:46:10 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249E012080E for ; Fri, 25 Oct 2019 06:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFpljyGmzDwn for ; Fri, 25 Oct 2019 06:46:07 -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 9A8B3120882 for ; Fri, 25 Oct 2019 06:46:06 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id x4so1806386lfn.8 for ; Fri, 25 Oct 2019 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8S2ZeBYI58lQRdyjhuleYh9tMuVTH76TU8ROziRTqRY=; b=CrgJ/ux/icgHc/ZJh+XRDEUC/mzXJJzKHm0qjo+/dgCSVu5zhi99p5c9POWuZCfNR9 WGuFM3tnSL5Qz8XMvUjZtQGk6a8cuKaou4ifumA1/aDhH80pnanwt6IxbJRVAkIKOHWb iHcsQ80PkLJQaLJ5T0Xl1WG1QmZb7CEsWFOEd5Krw6Uxphjp3AXaNhZRIPMhZG7W/AVN g9RcSZG7bSgAJE5uOiMVqES24kMbBBioWW+CGh5s7IOxWG6wAmq/n9/mqIXRse+Lg3Ga V47CPAzsqgs7UyojgEKzKaDCu9YVxCML7AK13O7wVW6k9SqoLhHSNaYt+uPBZcX0Lv5Z AtIw== 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=8S2ZeBYI58lQRdyjhuleYh9tMuVTH76TU8ROziRTqRY=; b=OkzE6jEgybqojUD6RtfPHLXXnvK+4XiwrO46abX9/GhUiIWYB+UZyMHtoAsa+WwQa9 NPsfC8cNNWtMY7TMddCPMwBaj9YARQC+pIyMSf2Ap5D0qplzC4kGByZye6XfWDt3rN3v 6fqt4a7V109loqozj3rMsjOXDqzTYibE7npQxeNwDEmE6WQRVg0eLo84m2g90r5gUck9 lu7CBcLhAppm0H4/Q+skZl2Ll1oLQ9K8vufbRzNQoEMSvOTbcfDBfpYNGDzZlHhQLE+3 MJJqEydmBlcP1XJhmRAjRTV8B6D57SmCzeut4hrN5ArQfL9gw3yv275rQxd6SVClPsEE 1dYA== X-Gm-Message-State: APjAAAWSzMNZqfL/JEbbsAe0sGLWxCl+DAhujED5QhYAYiI3aqdZ/ayO xiJrbtv+yiDlelwgKLgx/nCOvmxJyXxcCOPJz2J7hg== X-Google-Smtp-Source: APXvYqxeCw/wF/BKe8MmOKlJltHEecKEmocaYv3MNQGtHSBnDU2LorRPGVMhClsvrc3SomNiwnGkX4Pj2+rkbcqD1U0= X-Received: by 2002:ac2:4847:: with SMTP id 7mr2816864lfy.180.1572011164732; Fri, 25 Oct 2019 06:46:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 25 Oct 2019 06:45:28 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000ea3d70595bc5fe8" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 13:46:09 -0000 --0000000000000ea3d70595bc5fe8 Content-Type: text/plain; charset="UTF-8" Are you suggesting that these strings appear on the wire in DNS? Or is this just an internal implementation covnenience? -Ekr On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell wrote: > > Hiya, > > To date, my ESNI code [1] has been dealing with files containing > the binary encoding of ESNIKeys and a separate PEM file containing > the related private key. > > As part of getting nginx to work with ESNI [2], it'd be easier > for me to deal with a single file containing both private key > and the ESNIKeys (or ESNIConfig) value. (One of the upstream > maintainers didn't like how I handled configuring ESNI, so the > change is really to make him happier, but I think it's likely > a generally useful thing:-) > > Since mixing binary and PEM encoding in one file would be ickky, > it'd be nice if we had a PEM file convention for the public keys > used in ESNI. And of course, it'd be much nicer if everyone did > the same thing here. > > What I'm coding up now would handle files like: > > " > -----BEGIN ESNIKEY----- > > /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j > /gAAAABc995+AAA= > -----END ENSIKEY----- > " > > ...where the content is (unsurprisingly:-) a base64 encoded ESNIKeys. > > And if both the private and public components are in one file, > it'd look like: > > " > ----BEGIN PRIVATE KEY----- > MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va > -----END PRIVATE KEY----- > -----BEGIN ESNIKEY----- > > /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j > /gAAAABc995+AAA= > -----END ENSIKEY----- > " > > I'd be happy to change that however increases the probability > that other code bases do the same thing. > > If this is useful, I could do up a PR with a bit of text saying > to use "ESNIKEY" (or whatever) as the label when storing these > things in PEM files. Given RFC7468 documents other PEM file > things, it seems reasonable to do the same for ESNI. > > Cheers, > S. > > [1] https://github.com/sftcd/openssl/tree/master/esnistuff > [2] https://github.com/sftcd/nginx > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000000ea3d70595bc5fe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Are you suggesting that these strings appear on the w= ire in DNS? Or is this just an internal implementation covnenience?

-Ekr


On Fri, Oct 25, 2019 at 3:55= AM Stephen Farrell <stephe= n.farrell@cs.tcd.ie> wrote:

Hiya,

To date, my ESNI code [1] has been dealing with files containing
the binary encoding of ESNIKeys and a separate PEM file containing
the related private key.

As part of getting nginx to work with ESNI [2], it'd be easier
for me to deal with a single file containing both private key
and the ESNIKeys (or ESNIConfig) value. (One of the upstream
maintainers didn't like how I handled configuring ESNI, so the
change is really to make him happier, but I think it's likely
a generally useful thing:-)

Since mixing binary and PEM encoding in one file would be ickky,
it'd be nice if we had a PEM file convention for the public keys
used in ESNI. And of course, it'd be much nicer if everyone did
the same thing here.

What I'm coding up now would handle files like:

"
-----BEGIN ESNIKEY-----
/wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6= j
/gAAAABc995+AAA=3D
-----END ENSIKEY-----
"

...where the content is (unsurprisingly:-) a base64 encoded ESNIKeys.

And if both the private and public components are in one file,
it'd look like:

"
----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va
-----END PRIVATE KEY-----
-----BEGIN ESNIKEY-----
/wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6= j
/gAAAABc995+AAA=3D
-----END ENSIKEY-----
"

I'd be happy to change that however increases the probability
that other code bases do the same thing.

If this is useful, I could do up a PR with a bit of text saying
to use "ESNIKEY" (or whatever) as the label when storing these things in PEM files. Given RFC7468 documents other PEM file
things, it seems reasonable to do the same for ESNI.

Cheers,
S.

[1] https://github.com/sftcd/openssl/tree/mas= ter/esnistuff
[2] https://github.com/sftcd/nginx
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000000ea3d70595bc5fe8-- From nobody Fri Oct 25 07:03:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 294A01208CB for ; Fri, 25 Oct 2019 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 A3TRvKy2edLM for ; Fri, 25 Oct 2019 07:03:17 -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 2372B120882 for ; Fri, 25 Oct 2019 07:03:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9F89DBE2E; Fri, 25 Oct 2019 15:03:13 +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 vI3etJIFpAc4; Fri, 25 Oct 2019 15:03:09 +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 8E4B0BE20; Fri, 25 Oct 2019 15:03:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1572012189; bh=4+KFgnKl1KVNYTweyukpDrphLLvF/Kst80c3i/CwHmc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=GYYsZx9CRFI+2sE7taM9xGz+hNYeDqnfm++oXwj7trdqL7G7xg/qlSBnfr0UHyAG/ C9qorBxwTsSyLTdPD0BA4BPaar6imXqR0nr/dBjbNFeCmCcCaVRGFPprA+ffo5FJvU S1u2/7El3Z0AV6M6tzPEIg5b2OQrBzsBV0EGMhHY= To: Eric Rescorla Cc: "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 25 Oct 2019 15:03:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aJ3PovEtk3pmAdTtIcQcUKSTXez8gADtd" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 14:03:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aJ3PovEtk3pmAdTtIcQcUKSTXez8gADtd Content-Type: multipart/mixed; boundary="FRXsTjMX0JiLmKsjTodBAVyiXIEkZCkFQ"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] ESNI PEM files References: In-Reply-To: --FRXsTjMX0JiLmKsjTodBAVyiXIEkZCkFQ Content-Type: multipart/mixed; boundary="------------475F742516652B2CFDC437F2" Content-Language: en-GB This is a multi-part message in MIME format. --------------475F742516652B2CFDC437F2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25/10/2019 14:45, Eric Rescorla wrote: > Are you suggesting that these strings appear on the wire in DNS?=20 Nope. > Or is this > just an internal implementation covnenience? A bit more than that, but yes. I have a (temporary) tool for generating these files and then need to import the output from that into e.g. nginx or lighttpd. Some applications support more than one TLS library, so having a well defined format seems like it'd help with ESNI deployment. Basically this is the same logic that lead to pkcs8 PrivateKey being worth documenting in an RFC. Cheers, S. >=20 > -Ekr >=20 >=20 > On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> To date, my ESNI code [1] has been dealing with files containing >> the binary encoding of ESNIKeys and a separate PEM file containing >> the related private key. >> >> As part of getting nginx to work with ESNI [2], it'd be easier >> for me to deal with a single file containing both private key >> and the ESNIKeys (or ESNIConfig) value. (One of the upstream >> maintainers didn't like how I handled configuring ESNI, so the >> change is really to make him happier, but I think it's likely >> a generally useful thing:-) >> >> Since mixing binary and PEM encoding in one file would be ickky, >> it'd be nice if we had a PEM file convention for the public keys >> used in ESNI. And of course, it'd be much nicer if everyone did >> the same thing here. >> >> What I'm coding up now would handle files like: >> >> " >> -----BEGIN ESNIKEY----- >> >> /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAA= AAXO6j >> /gAAAABc995+AAA=3D >> -----END ENSIKEY----- >> " >> >> ...where the content is (unsurprisingly:-) a base64 encoded ESNIKeys. >> >> And if both the private and public components are in one file, >> it'd look like: >> >> " >> ----BEGIN PRIVATE KEY----- >> MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va >> -----END PRIVATE KEY----- >> -----BEGIN ESNIKEY----- >> >> /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAA= AAXO6j >> /gAAAABc995+AAA=3D >> -----END ENSIKEY----- >> " >> >> I'd be happy to change that however increases the probability >> that other code bases do the same thing. >> >> If this is useful, I could do up a PR with a bit of text saying >> to use "ESNIKEY" (or whatever) as the label when storing these >> things in PEM files. Given RFC7468 documents other PEM file >> things, it seems reasonable to do the same for ESNI. >> >> Cheers, >> S. >> >> [1] https://github.com/sftcd/openssl/tree/master/esnistuff >> [2] https://github.com/sftcd/nginx >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 --------------475F742516652B2CFDC437F2 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----- --------------475F742516652B2CFDC437F2-- --FRXsTjMX0JiLmKsjTodBAVyiXIEkZCkFQ-- --aJ3PovEtk3pmAdTtIcQcUKSTXez8gADtd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2zAJwACgkQWrL68XsX K+rixQ//fw5nRJRq5Ogq5ZmW8qVDpQeC5ur9dnioPKQaEMmkhnaOMCu82VBHdhMz XJgBwXMgynDMp0f4+W/SwfFU6NkLE/q2ViCkcbTqlAZOud+z4HE3q4byMuzxI72n kSN9gWY4Vy3FHFbQ5Xk4QF9E+SscYmuoD+7wawHOQ4HJoZna3t7l023rR39DHvyl 2/6x0fOQ6iAX8kpqoBqkQXNgHSOYUdPNjTMfQXdVog0S2H41+eqymUAsW7DMCBYC oMU1TkFttNalrExRWpj0H/Ox9JRg/le62S5hdBxlvVQmAqJuWfqxzJuZNzt4e/i0 PCxzDwS4M2qS2dUn35H7IPy5fjhEC2A6pMWrq/KIR1cpVepefkR7SuzxSrdn6QoX zFfZwxc+jMp52j+Qqfy4B8ehmq0S+y9K1d9aA+pSNaC/NmeApz+e4vs9XYf7XcK6 SHFRHhmoBg4bE4w2N7zNZnW0HGr2lHNJRHJrpHRkQTyM/tmLQt9xXw5z+kGohSiS AIVDlubZZAnXBH9Con/XYYKRVJNG736EupQ+wafM2bah0gOlQXCkwLcJUFyYWDkm Snm1iH6TrMQUqBoCNDptTMnNQgwGDTdYWi4A+cYfeKC/DejsB8DwVUOthog05CQ0 S0cIK0dFU9MPeiIWpXyeFBaloAhJQse0u8eABEXa9v4PgDji/iE= =ti/+ -----END PGP SIGNATURE----- --aJ3PovEtk3pmAdTtIcQcUKSTXez8gADtd-- From nobody Fri Oct 25 07:06:43 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3946A12080E for ; Fri, 25 Oct 2019 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsKIkhSQ9GH8 for ; Fri, 25 Oct 2019 07:06:40 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 380CC120123 for ; Fri, 25 Oct 2019 07:06:40 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id q64so2838185ljb.12 for ; Fri, 25 Oct 2019 07:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f8pNMKDiGwPiQUufhPkpwavx5eiBM/TdT2lLhCGalMY=; b=0cbeD2inzKbT/MQeD2yFVdzqpxQQZfsRtm5+LxUAP6ARoaoPXVUt/ybhh9GUE5qCzN gS4d9oPycyVoiz4atKj0tZFnZ8tHOE7Q6eI1ZMaGibWVOE5wDGNmMIbtCEsLY24IdG2i sCtqrZ+t1xTXLUbFwo/Apbu7tjq24wFgvD/XZdJN9zTesfrALFQIU9OzNzM/pQIcJ4Gi P9RIi9hZqjluTEGCAyQmnXMb/093bnZZwICGWf5uRuhp+Hy1C9fyEyUy3htxNoKytO4O 8CFxrAFtKIRgExJ6B/YpfNPVD0r72C4ky+vL+pDWsjEP7BbK40/dWFEOz9ObULXA9r1W hewg== 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=f8pNMKDiGwPiQUufhPkpwavx5eiBM/TdT2lLhCGalMY=; b=km+DtSR8Jmxpim5Q8d0SIUm8ifuawPJIzOoWlg19Nys8AdMYl/owFFrs869kSo2TmU f1rSBRzMls0JhkovR1UC2FfBV2aOMdM2oDHNwu3FLsr13lVO9yTQQ6BuOYpUh81MegIk 0/vkQKEV2jhRvSYZ2PhX/C7glcX1RtIyggPbarQcpPyhrpu0S8U94xkiXAWwtGbuEQfI 2xNhZKe2TCtaKBP7Yhzfq86Twr3TmoSaBkcOwM2FIyW0R2UjlNbA33NUGShTmtE/QgNr +yPso7EexJSoWRzV1gRt/4bAaMgTMNiq0QcKRG7TiXkQVfLhYHSr8gc1aeSll3OaWxoP Vf2g== X-Gm-Message-State: APjAAAXxfrk2bretnAXQT0BIaA3NXfP19EiugoyUipwXclu7nkWizoxp YQ8IOF+nVUCDqPYNe7LaUTst+CEMThdUbGaVD+5nEA== X-Google-Smtp-Source: APXvYqxTY/ZUd2l1Yvqnxn/AqEKcznAOBDUBkpaDkkaundhQiTy1SqnouHxD5nKSOU2gBVgxSi7DnUECwYs1XskGm+4= X-Received: by 2002:a2e:9a09:: with SMTP id o9mr2699143lji.217.1572012398300; Fri, 25 Oct 2019 07:06:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 25 Oct 2019 07:06:02 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009565b00595bca8f5" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 14:06:42 -0000 --0000000000009565b00595bca8f5 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 25, 2019 at 7:03 AM Stephen Farrell wrote: > > > On 25/10/2019 14:45, Eric Rescorla wrote: > > Are you suggesting that these strings appear on the wire in DNS? > > Nope. > > > Or is this > > just an internal implementation covnenience? > > A bit more than that, but yes. I have a (temporary) tool for > generating these files and then need to import the output from > that into e.g. nginx or lighttpd. Some applications support > more than one TLS library, so having a well defined format > seems like it'd help with ESNI deployment. > > Basically this is the same logic that lead to pkcs8 PrivateKey > being worth documenting in an RFC. > OK. I don't think this needs to be documented in this draft, but if you wanted to write some other draft.... -Ekr > Cheers, > S. > > > > > -Ekr > > > > > > On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hiya, > >> > >> To date, my ESNI code [1] has been dealing with files containing > >> the binary encoding of ESNIKeys and a separate PEM file containing > >> the related private key. > >> > >> As part of getting nginx to work with ESNI [2], it'd be easier > >> for me to deal with a single file containing both private key > >> and the ESNIKeys (or ESNIConfig) value. (One of the upstream > >> maintainers didn't like how I handled configuring ESNI, so the > >> change is really to make him happier, but I think it's likely > >> a generally useful thing:-) > >> > >> Since mixing binary and PEM encoding in one file would be ickky, > >> it'd be nice if we had a PEM file convention for the public keys > >> used in ESNI. And of course, it'd be much nicer if everyone did > >> the same thing here. > >> > >> What I'm coding up now would handle files like: > >> > >> " > >> -----BEGIN ESNIKEY----- > >> > >> > /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j > >> /gAAAABc995+AAA= > >> -----END ENSIKEY----- > >> " > >> > >> ...where the content is (unsurprisingly:-) a base64 encoded ESNIKeys. > >> > >> And if both the private and public components are in one file, > >> it'd look like: > >> > >> " > >> ----BEGIN PRIVATE KEY----- > >> MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va > >> -----END PRIVATE KEY----- > >> -----BEGIN ESNIKEY----- > >> > >> > /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQQAAAAAXO6j > >> /gAAAABc995+AAA= > >> -----END ENSIKEY----- > >> " > >> > >> I'd be happy to change that however increases the probability > >> that other code bases do the same thing. > >> > >> If this is useful, I could do up a PR with a bit of text saying > >> to use "ESNIKEY" (or whatever) as the label when storing these > >> things in PEM files. Given RFC7468 documents other PEM file > >> things, it seems reasonable to do the same for ESNI. > >> > >> Cheers, > >> S. > >> > >> [1] https://github.com/sftcd/openssl/tree/master/esnistuff > >> [2] https://github.com/sftcd/nginx > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > > --0000000000009565b00595bca8f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 25, 2019 at 7:03 AM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:


On 25/10/2019 14:45, Eric Rescorla wrote:
> Are you suggesting that these strings appear on the wire in DNS?

Nope.

> Or is this
> just an internal implementation covnenience?

A bit more than that, but yes. I have a (temporary) tool for
generating these files and then need to import the output from
that into e.g. nginx or lighttpd. Some applications support
more than one TLS library, so having a well defined format
seems like it'd help with ESNI deployment.

Basically this is the same logic that lead to pkcs8 PrivateKey
being worth documenting in an RFC.

OK. = I don't think this needs to be documented in this draft, but if you wan= ted to write some other draft....

-Ekr


Cheers,
S.

>
> -Ekr
>
>
> On Fri, Oct 25, 2019 at 3:55 AM Stephen Farrell <stephen.farrell@cs.tcd.ie&= gt;
> wrote:
>
>>
>> Hiya,
>>
>> To date, my ESNI code [1] has been dealing with files containing >> the binary encoding of ESNIKeys and a separate PEM file containing=
>> the related private key.
>>
>> As part of getting nginx to work with ESNI [2], it'd be easier=
>> for me to deal with a single file containing both private key
>> and the ESNIKeys (or ESNIConfig) value. (One of the upstream
>> maintainers didn't like how I handled configuring ESNI, so the=
>> change is really to make him happier, but I think it's likely<= br> >> a generally useful thing:-)
>>
>> Since mixing binary and PEM encoding in one file would be ickky, >> it'd be nice if we had a PEM file convention for the public ke= ys
>> used in ESNI. And of course, it'd be much nicer if everyone di= d
>> the same thing here.
>>
>> What I'm coding up now would handle files like:
>>
>> "
>> -----BEGIN ESNIKEY-----
>>
>> /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQ= QAAAAAXO6j
>> /gAAAABc995+AAA=3D
>> -----END ENSIKEY-----
>> "
>>
>> ...where the content is (unsurprisingly:-) a base64 encoded ESNIKe= ys.
>>
>> And if both the private and public components are in one file,
>> it'd look like:
>>
>> "
>> ----BEGIN PRIVATE KEY-----
>> MC4CAQAwBQYDK2VuBCIEICAHxXknil9tI2qZ+USRouNwXp0LxlUB85l0/xbhZ4Va >> -----END PRIVATE KEY-----
>> -----BEGIN ESNIKEY-----
>>
>> /wGeNLTKACQAHQAg/JLBUtPE5wp4CU2bbTihSPeP3113kz1J80X/Iy1Y2EYAAhMBAQ= QAAAAAXO6j
>> /gAAAABc995+AAA=3D
>> -----END ENSIKEY-----
>> "
>>
>> I'd be happy to change that however increases the probability<= br> >> that other code bases do the same thing.
>>
>> If this is useful, I could do up a PR with a bit of text saying >> to use "ESNIKEY" (or whatever) as the label when storing= these
>> things in PEM files. Given RFC7468 documents other PEM file
>> things, it seems reasonable to do the same for ESNI.
>>
>> Cheers,
>> S.
>>
>> [1] https://github.com/sftcd/openssl/= tree/master/esnistuff
>> [2] https://github.com/sftcd/nginx
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
--0000000000009565b00595bca8f5-- From nobody Fri Oct 25 07:12:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416D2120120 for ; Fri, 25 Oct 2019 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 7DVEo3Tp1tm1 for ; Fri, 25 Oct 2019 07:12:00 -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 54CE2120105 for ; Fri, 25 Oct 2019 07:12:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7E7C7BDCF; Fri, 25 Oct 2019 15:11:57 +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 wxj1pPpwV3mU; Fri, 25 Oct 2019 15:11:56 +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 0B706BE24; Fri, 25 Oct 2019 15:11:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1572012716; bh=AmwER2L0Cv+e5/wx+R1Z2YNBmSsnfs1wZA50leyVvOI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RupaZrIkrzkK1/sNoEfKzRevbjFdN+CGVMeWEYEP/2y2i8G3/1T3ukycJBcKbn37d ps2zcOIgiLCQvi1YouK7LT1SyRiA1T9Rm+4IYS20/hU0H31EsK9j+j9qUji4d9/hmC eFmiNS6xVQZsB1NI/Lblkcbe7I/rG6z1Y+3qkZKA= To: Eric Rescorla Cc: "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 25 Oct 2019 15:11:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mvWucG4H8gxWBZMpFlFKSnMcMZUZOQsbc" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 14:12:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mvWucG4H8gxWBZMpFlFKSnMcMZUZOQsbc Content-Type: multipart/mixed; boundary="lJTOyijigrMGf2p5zwwJ1Mud8vqOCKwQI"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: Subject: Re: [TLS] ESNI PEM files References: In-Reply-To: --lJTOyijigrMGf2p5zwwJ1Mud8vqOCKwQI Content-Type: multipart/mixed; boundary="------------F11AF69CF73432E6548DD89B" Content-Language: en-GB This is a multi-part message in MIME format. --------------F11AF69CF73432E6548DD89B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25/10/2019 15:06, Eric Rescorla wrote: > OK. I don't think this needs to be documented in this draft, but if you= > wanted to write some other draft.... It doesn't *need* to be in draft-ietf-tls-esni, no, but I figure it'd be better there as implementers would be less likely to miss it in that case. But, I'm fine starting off with the small bit of text needed in a new draft if that's somehow better than a PR. Cheers, S. --------------F11AF69CF73432E6548DD89B 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----- --------------F11AF69CF73432E6548DD89B-- --lJTOyijigrMGf2p5zwwJ1Mud8vqOCKwQI-- --mvWucG4H8gxWBZMpFlFKSnMcMZUZOQsbc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl2zAqoACgkQWrL68XsX K+oWmw/+JMilNaxUhO2ZoYe7gbRHKQl3LD/Oaqaga4Ou4cN2b2yvZkXTzJxb8Hd3 anlRPGVfXcaBlyro4UUy46FXtMm3wPp89gDbTbLY80AvqdJQ8QhM3UnzRJRLfVPf BoVFC+zuxHjabDtp2vVqWs7yyg9cm1wKFJs3n1GKL7K6BcBblUy1VE17/9JjHsTn o3tyPsRO5JzzrMeQI6AdnYzUwx+Tafxyu/jkt6sMZXW/xzftHeYG3ua1c4Z9VGJF Y20nsrqJ30xfwpnLxEQqgiUsUjqZMQq59BYOT6AdWy56Tp3wxdEC4pWGdOawj1Wz CsEk8CwlCHNcLmhRR3anG4Gt+VK1HVXH3tQob4P62Itv+I3rcjdgQqk2bwdWlJyR k5Dsw6S0S73nBGbgCZ7XmN1ekmWj18/oZ35Yoe0rq6ok9ZV/0mWKm5GdDRHVXTU3 AVaJhw43QNAfFl/GZDzaqnHn5d8lGi8aUAH4seGxNBUmpRR1Yj/0YXZFkz1QKdjw gVTFqQ5hLb8D/NegoUkVogxhG+kDnPR7UnoFZ4e3suA2Z2U7H/+pVQjfjCnpZ9LH pD12ipdVifs+aaAcsiphmP6RdMXXBH5rIfKz+dF0A1rh1zhO4cIpfCV6jqtG8bk1 vqksw+tjo2MitnrIUqtPdKhJlJqNAM/Cus6MZ3tPbIvJTLMQhAI= =7noX -----END PGP SIGNATURE----- --mvWucG4H8gxWBZMpFlFKSnMcMZUZOQsbc-- From nobody Fri Oct 25 07:47:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B503120843 for ; Fri, 25 Oct 2019 07:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBZdGitDe8x3 for ; Fri, 25 Oct 2019 07:46:59 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A85120122 for ; Fri, 25 Oct 2019 07:46:59 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id u16so1992953lfq.3 for ; Fri, 25 Oct 2019 07:46:59 -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=dP5Ma9R9x5AKURJhn9/4fq+5JZZtLSZtyEoerUt5i28=; b=MmHTeUfN+X/K9fEmRd24mfGUOJr9XzWrfkeE4/Dds5mQgBBt1Zm/AieuFytmJk0hOm oFXnzpO2w2gMOt7e0RQNvP7IqIpiX2IcigB5+bbbXolx9CLFc2bHgqpmhDO2fOclslUN VMUT2tR4TVqIxByzJ6qIzqXYt219tpTVkvRLbLi0Js7cKaEp8UFJbCSonGiCGbEKw1mH RsoOWAokmXXUvygFBVMW+JLGIfsAuzQ+ncL4I9WMiG/TGhROTm0cYikz5+/ekGVNzPpz thZaOV10wbaIV9rdjwNVIMDoKgHy/GJqH49npTo9qQe7fYm2w6e0ZqPSFe+qwR4EJwdM qTNA== 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=dP5Ma9R9x5AKURJhn9/4fq+5JZZtLSZtyEoerUt5i28=; b=iAx+iuTqG/ohGDnjGIs+k6QAQjESVa6B4rkKi9JTGOL5IGPpHKnzYQ7oPiN+Vs2BOu 8GTctgWf8v9gU9ebwBKyJJfywEkxYlsLBhVQ4DUHg3qWvy/4J7kjj92fZkBz9HXXkmmb VZSgjCwZNFa7wiji4szYaboxdq8Qo8sFqOOYjv2vxYoVSBnrjlQc/W9G4+HPXKZB9XiG 8KwFgItJZbvkGu9Rg0jZ58dQFUcVFa3oMoxpr7NFPTrTXnePY6DiKG1TRZBt4FHLoU7g QyltSsqAnw5KeeJPd5g09WwxPoVRH4lqT26cnqDv8v7bjyH7htbJhDkRG/h5QYc0uYkj 5Osw== X-Gm-Message-State: APjAAAXSPLoAhOUctkyKdBp7cSYAukvtD2vlpVi3/iHoxrXXCJ29bhSu g9NlIMtODq3+McZumKABmHdA+Cpnvv1N3nf1f6FJr90k X-Google-Smtp-Source: APXvYqyHZiBUOrw5EZryj8wc4ophxlIR/CY9HTsKLY0oXqzCqdDIY3HxEybLacMN1CLjWnMj6akV3DePq2WDG2X2TQM= X-Received: by 2002:a19:6d19:: with SMTP id i25mr3021560lfc.178.1572014817776; Fri, 25 Oct 2019 07:46:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Fri, 25 Oct 2019 07:46:21 -0700 Message-ID: To: Stephen Farrell Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cbabb10595bd38fd" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 14:47:01 -0000 --000000000000cbabb10595bd38fd Content-Type: text/plain; charset="UTF-8" On Fri, Oct 25, 2019 at 7:11 AM Stephen Farrell wrote: > > > On 25/10/2019 15:06, Eric Rescorla wrote: > > OK. I don't think this needs to be documented in this draft, but if you > > wanted to write some other draft.... > > It doesn't *need* to be in draft-ietf-tls-esni, no, but I > figure it'd be better there as implementers would be less > likely to miss it in that case. But, I'm fine starting off > with the small bit of text needed in a new draft if that's > somehow better than a PR. > Sorry I wasn't clear: I don't think it belongs in this draft, but I don't object to you writing up some other draft. -Ekr > Cheers, > S. > --000000000000cbabb10595bd38fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 25, 2019 at 7:11 AM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:


On 25/10/2019 15:06, Eric Rescorla wrote:
> OK. I don't think this needs to be documented in this draft, but i= f you
> wanted to write some other draft....

It doesn't *need* to be in draft-ietf-tls-esni, no, but I
figure it'd be better there as implementers would be less
likely to miss it in that case. But, I'm fine starting off
with the small bit of text needed in a new draft if that's
somehow better than a PR.

Sorry I wasn&= #39;t clear: I don't think it belongs in this draft, but I don't ob= ject to you writing up some other draft.

-Ekr<= /div>


Cheers,
S.
--000000000000cbabb10595bd38fd-- From nobody Fri Oct 25 07:58:08 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D1512091F for ; Fri, 25 Oct 2019 07:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 HKUKjl0EDZPR for ; Fri, 25 Oct 2019 07:58:01 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 6C80E120921 for ; Fri, 25 Oct 2019 07:57:49 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id z6so2277218otb.2 for ; Fri, 25 Oct 2019 07:57: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=wmf1NUxToJcnhoXX1cZRBBbZ9UNEQeHhfV9bXJ5DfbE=; b=SQ6vY2U88YbQdKd1MbpdLQaWQJwO16vZtQX2IMF5BWoGS45Q5sq9Fr8ZrAC/prraFi ptcDEb0TORlEQAOBo+97IZn2aelYcKQ0oe7xGuDDqFK+zmH/x7YcIeb2ZSWt2NEMym6m rCweA1h+3QBTx5m0/LR4dcel5bMBP13E14kawWUPynHOEMreX/izPTU3closYfIGV2yX mqlaoO1WFNyt3BPFSIpm8NQnPbSspOJbVYl/hCH/TLcM39LkTbVbBaO/0L9YsIYCmg9D 1sGjN8olPb63hkgSnFxmFwAFXi65huTg3DXp0YG2dzVDOJw4a8N5+F4hl6HwwSFe/r0U Zicg== 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=wmf1NUxToJcnhoXX1cZRBBbZ9UNEQeHhfV9bXJ5DfbE=; b=RW/5MNltVFOrXrqe6/U0w6Vygx5xMNoWooW2X/7GRmi1t60DimUl90P4NvuCI7djYy inhy2+xJ+5QjfkcwvSfwH0VNppy1LmtP0oexhjcH56Z4ct83iF6jSLE04jc92i6oB1qZ kOuzgr2YApmPSkMqjx0EoVkGLeTbiUy74wB5kElYJhFjf9wvg/Q+7mtT6/ntwDZwjttt CnulqkkO3wkoJAswfdnyYsTMfknXUKXQEUBV1i1oKood7kYRfUel6fAlz/Hqlf9obJKZ Em9CKPabtn+cFkc9nTqEn2Ff7IyLqnrxok2FIwTflZQKRyhZl3yysXf6OgsLtzCMIWyh rCIw== X-Gm-Message-State: APjAAAULMRLoqsS7kHiir5HrCkgqx+xrLyOopzLkLQdsSKGtZcCi1EoW 4H/9EnaipYjB7B/vo3gIhxPsZH+tZOICxzWT1ANa/aYgecs= X-Google-Smtp-Source: APXvYqwRQHtohXA/+63eAlITg8EI8msjLM5LN6S2p9bqDfw5GbF0iBNL1mLrmkbgZG2xPztGYg5+R3FFuQw/WUVojrw= X-Received: by 2002:a9d:7cda:: with SMTP id r26mr3285732otn.290.1572015468318; Fri, 25 Oct 2019 07:57:48 -0700 (PDT) MIME-Version: 1.0 References: <52c0ae70-4bcd-9135-294a-126bc7e13bf1@cs.tcd.ie> In-Reply-To: <52c0ae70-4bcd-9135-294a-126bc7e13bf1@cs.tcd.ie> From: Steven Valdez Date: Fri, 25 Oct 2019 10:57:37 -0400 Message-ID: To: Stephen Farrell Cc: Christopher Wood , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009285220595bd5f46" Archived-At: Subject: Re: [TLS] Adopting HTTPSVC for 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: Fri, 25 Oct 2019 14:58:06 -0000 --0000000000009285220595bd5f46 Content-Type: text/plain; charset="UTF-8" Chrome is supportive of this change, and will likely work on implementing HTTPSSVC into our DNS stack once the draft progresses further. As for the ESNIKeys/ESNIConfig change, we were actually thinking of something that further abstracted HTTPSSVC having to understand anything about ESNI from the ESNI versioning: The ESNIKeys naming was always a bit confusing since you could have multiple ESNIKeys, and there wasn't a great way of referring to those. HTTPSSVC records include a single ESNIBundle which is length prefixed and contains one or more ESNIConfigs. (to allow an endpoint to publish multiple ESNIConfigs, potentially supporting multiple versions of the ESNI record). Each ESNIConfig is then just a version and then a version-specific structure. (to allow the entire structure of the ESNIConfigInner to arbitrarily change at different versions). Something roughly like the following: ESNIBundle { ESNIConfig<2..2^16-1>; }; ESNIConfig { version, select (version) { case 0: { opaque public_name<1..2^16-1>; KeyShareEntry keys<4..2^16-1>; CipherSuite cipher_suites<2..2^16-2>; uint16 padded_length; Extension extensions<0..2^16-1>; } } }; (alternatively maybe make an ESNIConfigInner and stuff an opaque in ESNIConfig that is version-specific, not sure what the right presentation looks like) On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell wrote: > > Hiya, > > On 25/10/2019 01:28, Christopher Wood wrote: > > Hi folks, > > > > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of > > doing the same thing, I've put together a PR that drops the custom > > ESNI RRType in favor of this more general (yet feature compatible) > > Resource Record: > > > > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 > > > > Please have a look and comment before next Friday. We'd like to land > > this before Singapore. > > I'm supportive of this change, on the assumption that browsers are > really going to use HTTPSSVC. > > If that lands as-is, please bump the version to ff04 and I don't > see much benefit in changing from ESNIKeys to ESNIConfig (seems > more likely to confuse than help to me). > > Going further, I think we ought also take advantage of this to > simplify the ESNIKeys/ESNIConfig structure. We don't need to do > that right now but we could. > > There are two related simplifications that'd make sense to me: > > - remove the version field and encode that in the HTTPSSVC label > (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I > think that'd lead to fewer cases where HTTPSSVC code needs to > understand what's inside the ESNIConfig structure. > > - similarly, remove the extensions field from ESNIConfig, and > require a new label in HTTPSSVC if something new is really needed > > Cheers, > S. > > > > > Best, Chris (no hat) > > > > [1] > > https://mailarchive.ietf.org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s > > > > _______________________________________________ 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 > -- Steven Valdez | Chrome Privacy Sandbox | svaldez@google.com | 210-692-4742 --0000000000009285220595bd5f46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Chrome is supportive of this change, and will likely work = on implementing HTTPSSVC into our DNS=C2=A0stack once the draft progresses = further.

As for=C2=A0the ESNIKeys/ESNIConfig change, we were actuall= y thinking of something that further abstracted HTTPSSVC=C2=A0having to und= erstand anything about ESNI from the ESNI versioning:

Th= e ESNIKeys naming was always a bit confusing since you could have multiple = ESNIKeys, and there wasn't a great way of referring to those.
=

HTTPSSVC=C2=A0records include a single ESNIBundle which= is length prefixed and contains one or more ESNIConfigs. (to allow an endp= oint to publish multiple ESNIConfigs, potentially supporting multiple versi= ons of the ESNI record).

Each ESNIConfig is then j= ust a version and then a version-specific structure. (to allow the entire s= tructure of the ESNIConfigInner to arbitrarily change at different versions= ).

Something roughly like the following:

ESNIBundle {
=C2=A0 ESNIConfig<2..2^16-1>;
};

ESNIC= onfig {
=C2=A0 version,
=C2=A0= select (version) {
=C2=A0 =C2=A0 case 0: {
=C2=A0 =C2=A0 =C2=A0 opaq= ue public_name<1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 KeyShareEntry keys= <4..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 CipherSuite cipher_suites<2..= 2^16-2>;
=C2=A0 =C2=A0 =C2=A0 uint16 padded_length;
=C2=A0 =C2=A0 = =C2=A0 Extension extensions<0..2^16-1>;
=C2=A0 =C2=A0 }
= =C2=A0 }
};

<= div>(alternatively maybe make an ESNIConfigInner a= nd stuff an opaque in ESNIConfig that is version-specific, not sure what th= e right presentation looks like)

On Fri, Oct 25, 2019 at 6:29 A= M Stephen Farrell <stephen.= farrell@cs.tcd.ie> wrote:

Hiya,

On 25/10/2019 01:28, Christopher Wood wrote:
> Hi folks,
>
> DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of
> doing the same thing, I've put together a PR that drops the custom=
> ESNI RRType in favor of this more general (yet feature compatible)
> Resource Record:
>
> https://github.com/tlswg/draft-ietf-tls-e= sni/pull/187
>
> Please have a look and comment before next Friday. We'd like to la= nd
> this before Singapore.

I'm supportive of this change, on the assumption that browsers are
really going to use HTTPSSVC.

If that lands as-is, please bump the version to ff04 and I don't
see much benefit in changing from ESNIKeys to ESNIConfig (seems
more likely to confuse than help to me).

Going further, I think we ought also take advantage of this to
simplify the ESNIKeys/ESNIConfig structure. We don't need to do
that right now but we could.

There are two related simplifications that'd make sense to me:

- remove the version field and encode that in the HTTPSSVC label
(so it'd be something like esnikeys05=3D"/wElr6L2ACQAHQ...") = - I
think that'd lead to fewer cases where HTTPSSVC code needs to
understand what's inside the ESNIConfig structure.

- similarly, remove the extensions field from ESNIConfig, and
require a new label in HTTPSSVC if something new is really needed

Cheers,
S.

>
> Best, Chris (no hat)
>
> [1]
> https://mailarchive.ietf= .org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s
>
>=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


--

Steven Valdez=C2=A0|=C2=A0Chrome Privacy Sandbox |=C2=A0svaldez@google.com=C2=A0|=C2=A0210-692-4742
--0000000000009285220595bd5f46-- From nobody Fri Oct 25 08:23:30 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5F9120168 for ; Fri, 25 Oct 2019 08:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, RCVD_IN_DNSWL_LOW=-0.7, 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=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 UnQwj-mzyopA for ; Fri, 25 Oct 2019 08:23:27 -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 B6AFB120123 for ; Fri, 25 Oct 2019 08:23:27 -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 x9PF7gCp020401; Fri, 25 Oct 2019 16:22:19 +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=OIlS68lGYEPTXmF8JXDQhVeskB0FR24I1Xnf/q4LOp0=; b=BqWU0ZuRiL++aG5qnDvo+D26A98SyV3KkNefzXBrjSfC/qVYilWoXVSaaMQqPvN+VH2V RqXfa1IwvlvBwH7YS7ijt9qvbzsfLpuWoT2XCvt2lUl/fO5CPb7WkuzkuRaZQKd3ExnN lFCX1C2hJaGWT5DVSgtu8NSvPKE+7fMmUmVHI44EWhqNU143RXGQM0fhg6L7AhoY8rT9 uY++4Xha1oTQ40NU5cef4BofKG96KYTSqPgDr6vBxVNxmKQsdVgGzKTZAHHYOYXyklVn pbgcCl4RzUuqU2YV6C7jJuvwLyB1c3Ta9ZK2lp/1bPbrYCRYj60FTct79ywr9Na4rhAK kQ== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vu5j8xdyf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 16:22:19 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9PFH8AC025281; Fri, 25 Oct 2019 11:22:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint6.akamai.com with ESMTP id 2vqwtwseb6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Oct 2019 11:22:18 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 11:22:17 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Fri, 25 Oct 2019 11:22:17 -0400 From: "Salz, Rich" To: Stephen Farrell , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] ESNI PEM files Thread-Index: AQHViyKz+fstIng8CkOfaQuz09MBJadrobQAgAAE8ACAAADPAIAAAaQA///QmwA= Date: Fri, 25 Oct 2019 15:22:17 +0000 Message-ID: <475194A6-17BA-43D1-B00E-BA63994A969F@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.81.209] Content-Type: text/plain; charset="utf-8" Content-ID: <0AF69B521B53C14792B2BD1AC2D09119@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-25_08:, , 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=948 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910250143 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-25_08:2019-10-25,2019-10-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 mlxscore=0 adultscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 mlxlogscore=934 spamscore=0 clxscore=1015 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910250143 Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 15:23:29 -0000 SSBwcmVmZXIgYW4gaW5mb3JtYXRpdmUgKG5vdC0gbm9ybWF0aXZlKSBhcHBlbmRpeCBvZiwgbGlr ZSwgMyBzZW50ZW5jZXMgb3Igc28uDQoNClRoaXMgd2lsbCBuZWVkIGFsbCB0aGUgaW1wbGVtZW50 YXRpb24gYW5kIG9wZXJhdGlvbmFsIGhlbHAgaXQgY2FuIGdldCwgYW5kIHNjYXR0ZXJpbmcgdGhp bmdzIGFjcm9zcyBtdWx0aXBsZSB0ZWVuc3kgZG9jcyBpcyBub3QgaGVscGZ1bC4NCiANCg0K From nobody Fri Oct 25 08:54:15 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9555F120219 for ; Fri, 25 Oct 2019 08:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 yqvHZHCY9Mjk for ; Fri, 25 Oct 2019 08:54:12 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDED120105 for ; Fri, 25 Oct 2019 08:54:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 88F3445BEF; Fri, 25 Oct 2019 18:54:10 +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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id JWeTGMPpa-6q; Fri, 25 Oct 2019 18:54:10 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A59107A; Fri, 25 Oct 2019 18:54:06 +0300 (EEST) Date: Fri, 25 Oct 2019 18:54:06 +0300 From: Ilari Liusvaara To: Ben Schwartz Cc: Watson Ladd , TLS List Message-ID: <20191025155406.GA526068@LK-Perkele-VII> References: <20191023171113.GA472177@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-esni feedback X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 15:54:15 -0000 On Wed, Oct 23, 2019 at 04:52:57PM -0400, Ben Schwartz wrote: > On Wed, Oct 23, 2019 at 1:11 PM Ilari Liusvaara > > > > Perhaps a simpler way would be to have a flag that causes the first > > label to be overwritten with '*'. That would be set on nodes covered > > by a wildcard certificate. > > This is a reasonable simplification. It would also work nicely > without the hashing, for servers that only have reasonably-sized names > but can't make promises about wildcards. However, it does still > suffer from the configuration brittleness described by David Benjamin > in #186. I think all mechanisms that transmit only a single hash need to know if some node is covered by exact name or a wildcard. And wildcard expansion is at worst 63 bytes, due to DNS limitations, so transmitting full first label and 32 octet hash of rest would take 96 octets (if one can assume host character set, that could be fit into 80 octets with some encoding). Then if one had two hashes, one could fit those to 64 bytes (or 48 if one truncated the hashes to 192 bits, as scope of uniqueness is just a single server). This would not depend on knowing if node is wildcard or not. -Ilari From nobody Fri Oct 25 09:01:24 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98373120972 for ; Fri, 25 Oct 2019 09:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=apple.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 BI8XTacLEt-I for ; Fri, 25 Oct 2019 09:01:22 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 37728120930 for ; Fri, 25 Oct 2019 09:01:22 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x9PFuqGX012788; Fri, 25 Oct 2019 09:01:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : content-type : mime-version : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=20PtdBq0BfqQb+KV5/XXgsCOxjrdNRrhlaCjIyYVNGk=; b=UFgzBybZpFQ6vE9vmddFCJsVNgFri1KTvA/zx7j7F0j84O3F+RXFG/3FZi1geLzkrcDD 1NUYXTx5qzvNq6RKvWGQhJW1QQpm9iyVsy4PdanfUGhbqWFerh4+opZIB7zUW4Z1WsJU 4vcar4C0T5fOVgwMmFvaynXw8/A/UqR1jwS2OVztMvAN8gTb8NHg9F0skhLmW9Yxy0uA VL8XlxSp4+5iYSHLT46LPg4OmRiL3h/xvZWJygyeoydKrliIl1/OLvEsn0V4Qb+bcAcA pZ+9p4eoEBXT9DtOD53Fzfm+qLj9jIhpQG2JzEW6v6ZmkKvQ4Sk4med8GM220TY/itF9 cg== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2vqy5ybv7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 25 Oct 2019 09:01:12 -0700 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PZX008VTTTYKF60@ma1-mtap-s02.corp.apple.com>; Fri, 25 Oct 2019 09:01:11 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PZX00C00TTXCW00@nwk-mmpp-sz12.apple.com>; Fri, 25 Oct 2019 09:01:10 -0700 (PDT) X-Va-A: X-Va-T-CD: 7713df823212217ef5a9d12f7f2438ff X-Va-E-CD: 5491b5cc3ae7abd2437712635d52f524 X-Va-R-CD: da429a9f70716868f716b0b8422aee7a X-Va-CD: 0 X-Va-ID: 726d4579-e90b-4b53-9653-3fd38877bd22 X-V-A: X-V-T-CD: 7713df823212217ef5a9d12f7f2438ff X-V-E-CD: 5491b5cc3ae7abd2437712635d52f524 X-V-R-CD: da429a9f70716868f716b0b8422aee7a X-V-CD: 0 X-V-ID: 5c88b3b0-da54-404b-9b93-f822495261c1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-25_08:,, signatures=0 Received: from [17.234.16.25] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PZX004IMTSPE540@nwk-mmpp-sz12.apple.com>; Fri, 25 Oct 2019 09:00:25 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_D57CADF3-4088-4205-B435-A0599CDB074A" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Fri, 25 Oct 2019 09:00:13 -0700 References: <52c0ae70-4bcd-9135-294a-126bc7e13bf1@cs.tcd.ie> To: Steven Valdez , "TLS@ietf.org" , Stephen Farrell In-reply-to: Message-id: <7C534382-715F-401E-911F-B788887528B0@apple.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-25_08:, , signatures=0 Archived-At: Subject: Re: [TLS] Adopting HTTPSVC for 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: Fri, 25 Oct 2019 16:01:23 -0000 --Apple-Mail=_D57CADF3-4088-4205-B435-A0599CDB074A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm also supportive of this change, and in general of using HTTPSSVC for = the transmission of ESNI keys, speaking as an implementer at Apple. With regards to the per-version structure, I agree with Steven that the = structure of the configuration should be able to change between = versions. I think that either specifying that the structure can change = with versions, or just moving the version into the label (Stephen's = suggestion) would work. I have a *slight* concern for the case of using = a different HTTPSSVC label for each version or set of extensions, since = the code that parses out the records may be distinct from the code that = uses the keys, and it may be easier to fetch the right information out = if it has a consistent label name. Not a huge issue either way, though. Thanks, Tommy > On Oct 25, 2019, at 7:57 AM, Steven Valdez = wrote: >=20 > Chrome is supportive of this change, and will likely work on = implementing HTTPSSVC into our DNS stack once the draft progresses = further. >=20 > As for the ESNIKeys/ESNIConfig change, we were actually thinking of = something that further abstracted HTTPSSVC having to understand anything = about ESNI from the ESNI versioning: >=20 > The ESNIKeys naming was always a bit confusing since you could have = multiple ESNIKeys, and there wasn't a great way of referring to those. >=20 > HTTPSSVC records include a single ESNIBundle which is length prefixed = and contains one or more ESNIConfigs. (to allow an endpoint to publish = multiple ESNIConfigs, potentially supporting multiple versions of the = ESNI record). >=20 > Each ESNIConfig is then just a version and then a version-specific = structure. (to allow the entire structure of the ESNIConfigInner to = arbitrarily change at different versions). >=20 > Something roughly like the following: >=20 > ESNIBundle { > ESNIConfig<2..2^16-1>; > }; >=20 > ESNIConfig { > version, > select (version) { > case 0: { > opaque public_name<1..2^16-1>; > KeyShareEntry keys<4..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > uint16 padded_length; > Extension extensions<0..2^16-1>; > } > } > }; >=20 > (alternatively maybe make an ESNIConfigInner and stuff an opaque in = ESNIConfig that is version-specific, not sure what the right = presentation looks like) >=20 > On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell = > wrote: >=20 > Hiya, >=20 > On 25/10/2019 01:28, Christopher Wood wrote: > > Hi folks, > >=20 > > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of > > doing the same thing, I've put together a PR that drops the custom > > ESNI RRType in favor of this more general (yet feature compatible) > > Resource Record: > >=20 > > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 = > >=20 > > Please have a look and comment before next Friday. We'd like to land > > this before Singapore. >=20 > I'm supportive of this change, on the assumption that browsers are > really going to use HTTPSSVC. >=20 > If that lands as-is, please bump the version to ff04 and I don't > see much benefit in changing from ESNIKeys to ESNIConfig (seems > more likely to confuse than help to me). >=20 > Going further, I think we ought also take advantage of this to > simplify the ESNIKeys/ESNIConfig structure. We don't need to do > that right now but we could. >=20 > There are two related simplifications that'd make sense to me: >=20 > - remove the version field and encode that in the HTTPSSVC label > (so it'd be something like esnikeys05=3D"/wElr6L2ACQAHQ...") - I > think that'd lead to fewer cases where HTTPSSVC code needs to > understand what's inside the ESNIConfig structure. >=20 > - similarly, remove the extensions field from ESNIConfig, and > require a new label in HTTPSSVC if something new is really needed >=20 > Cheers, > S. >=20 > >=20 > > Best, Chris (no hat) > >=20 > > [1] > > = https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s = > > > > _______________________________________________ TLS mailing list=20 > > TLS@ietf.org = https://www.ietf.org/mailman/listinfo/tls = > >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 > --=20 >=20 > Steven Valdez | Chrome Privacy Sandbox | = svaldez@google.com | 210-692-4742 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_D57CADF3-4088-4205-B435-A0599CDB074A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I'm = also supportive of this change, and in general of using HTTPSSVC for the = transmission of ESNI keys, speaking as an implementer at Apple.

With regards to the = per-version structure, I agree with Steven that the structure of the = configuration should be able to change between versions. I think that = either specifying that the structure can change with versions, or just = moving the version into the label (Stephen's suggestion) would work. I = have a *slight* concern for the case of using a different HTTPSSVC label = for each version or set of extensions, since the code that parses out = the records may be distinct from the code that uses the keys, and it may = be easier to fetch the right information out if it has a consistent = label name. Not a huge issue either way, though.

Thanks,
Tommy

On Oct 25, 2019, at 7:57 AM, = Steven Valdez <svaldez=3D40google.com@dmarc.ietf.org> = wrote:

Chrome is supportive of this change, and will = likely work on implementing HTTPSSVC into our DNS stack once the = draft progresses further.

As for the = ESNIKeys/ESNIConfig change, we were actually thinking of something that = further abstracted HTTPSSVC having to understand anything about = ESNI from the ESNI versioning:

The ESNIKeys naming was always a bit confusing since you = could have multiple ESNIKeys, and there wasn't a great way of referring = to those.

HTTPSSVC records include a single ESNIBundle which is = length prefixed and contains one or more ESNIConfigs. (to allow an = endpoint to publish multiple ESNIConfigs, potentially supporting = multiple versions of the ESNI record).

Each ESNIConfig is then just a version = and then a version-specific structure. (to allow the entire structure of = the ESNIConfigInner to arbitrarily change at different versions).

Something roughly like the following:

ESNIBundle = {
  ESNIConfig<2..2^16-1>;
};

ESNIConfig {
  = version,
  select (version) {
    case 0: = {
      opaque = public_name<1..2^16-1>;
      = KeyShareEntry keys<4..2^16-1>;
      = CipherSuite cipher_suites<2..2^16-2>;
    =   uint16 padded_length;
      = Extension extensions<0..2^16-1>;
    }
  }
};

(alternatively maybe make an = ESNIConfigInner and stuff an opaque in ESNIConfig that is = version-specific, not sure what the right presentation looks = like)

On Fri, Oct 25, 2019 at 6:29 AM Stephen = Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 25/10/2019 01:28, Christopher Wood wrote:
> Hi folks,
>
> DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways = of
> doing the same thing, I've put together a PR that drops the = custom
> ESNI RRType in favor of this more general (yet feature = compatible)
> Resource Record:
>
> https://github.com/tlswg/draft-ietf-tls-esni/pull/187
>
> Please have a look and comment before next Friday. We'd like to = land
> this before Singapore.

I'm supportive of this change, on the assumption that browsers are
really going to use HTTPSSVC.

If that lands as-is, please bump the version to ff04 and I don't
see much benefit in changing from ESNIKeys to ESNIConfig (seems
more likely to confuse than help to me).

Going further, I think we ought also take advantage of this to
simplify the ESNIKeys/ESNIConfig structure. We don't need to do
that right now but we could.

There are two related simplifications that'd make sense to me:

- remove the version field and encode that in the HTTPSSVC label
(so it'd be something like esnikeys05=3D"/wElr6L2ACQAHQ...") - I
think that'd lead to fewer cases where HTTPSSVC code needs to
understand what's inside the ESNIConfig structure.

- similarly, remove the extensions field from ESNIConfig, and
require a new label in HTTPSSVC if something new is really needed

Cheers,
S.

>
> Best, Chris (no hat)
>
> [1]
> https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2= k4NF_nj4s
>
>  _______________________________________________ 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


--

Steven Valdez | Chrome = Privacy Sandbox | svaldez@google.com | 210-692-4742
<= /div>
_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_D57CADF3-4088-4205-B435-A0599CDB074A-- From nobody Fri Oct 25 11:13:25 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7E1200DF for ; Fri, 25 Oct 2019 11:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 kjIDwUhkf8Rk for ; Fri, 25 Oct 2019 11:13:20 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740130.outbound.protection.outlook.com [40.107.74.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037CB120043 for ; Fri, 25 Oct 2019 11:13:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TZDq3sajkPvsy1gHpRkiUnOk8CVaHC/FY3AehiC6ANjEvU9FyWoumt4ribJUFAndjEZgm5s3VcO7+i4a1rbHzt1BOE6k84u1votE95vYWjhnlvqcfSIsYV0qa5OJz8zK0qU/twAhe2Ms9+ZVH1DoUkrT9PeOTZK1NaV0GLX1euD0FG6E2n57ijreEvPK2yN3EV8CfFmcvpwCOTVs/6LXvlYaBtWLX86RXcY/+GTyMTBW+epXoM5ZIF6uU1XYW28he6EVevrsGGspna7NzqU2Q0pzLHmXwssFrXInE6aCZIvOJCcqRmRkBPY5QyWQ77Te/1Vn3vtpgeVzDeVOstgHPg== 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=/KiHVAXi5Fe20W0kW+DmklPj/NC6+kZyYS89O0XE4wY=; b=abJWA+NYwr2TaezZPVeHuo3xK1lpLOcDjtOrR0jlnkpJ78IJKTntxI7rhYdw7tUJmfT9396iUnWU/S7kZu41o/bH49vfYoKznBhZXdCnTt/buykinou0qAizqd/6DV9UnOaQBxPeTmkUOCf2bex3BTlGGg7/T60H9tYsmRHMg9RL88gaNqn8xeF4ye7NKlFb0wm4cs9ycyW2kVf2/eI0vXKXeBxeGC4tSJGIJiromX/9aQabMpBz0NgzoO4sFGGhuVAMSKnB5oJGc1wzc41koIO3IuuZWeIedBm+FCDMU71PFquz/KZ54tyqGEjfTigXbvnvALqn9qMvMY0VFKBvJQ== 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=/KiHVAXi5Fe20W0kW+DmklPj/NC6+kZyYS89O0XE4wY=; b=drhxr+NBt2Ib7FY2y8kIZmuvFfvemNV9FTyxnuhnC7PtBQdLgnIl07VB0Lk4Hf0rdGefZ5+DNdAcuQgg5akgY6VxeizH81Q481xdaXW3W7EFyyuEOufDU7q3B9Tz3XFBYHZfEUDtnyh7TYrhvLHdDIUWn6KSk8XT2a/CxIEME5Q= Received: from DM5PR2101MB0997.namprd21.prod.outlook.com (52.132.133.31) by DM5PR2101MB1047.namprd21.prod.outlook.com (52.132.128.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2408.9; Fri, 25 Oct 2019 18:13:18 +0000 Received: from DM5PR2101MB0997.namprd21.prod.outlook.com ([fe80::602d:42fc:b602:ecd4]) by DM5PR2101MB0997.namprd21.prod.outlook.com ([fe80::602d:42fc:b602:ecd4%7]) with mapi id 15.20.2387.014; Fri, 25 Oct 2019 18:13:18 +0000 From: Andrei Popov To: RFC Errata System , "ekr@rtfm.com" , "rdd@cert.org" , "kaduk@mit.edu" , "caw@heapingbits.net" , "joe@salowey.net" , "sean+ietf@sn3rd.com" CC: "lperrin@bellaliant.net" , "tls@ietf.org" Thread-Topic: [TLS] [Technical Errata Reported] RFC8446 (5874) Thread-Index: AQHVgLSpd7FDKHjDJUC+OKeaNh4g+qdrvRNQ Date: Fri, 25 Oct 2019 18:13:18 +0000 Message-ID: References: <20191012042149.A9B79B801A8@rfc-editor.org> In-Reply-To: <20191012042149.A9B79B801A8@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:1:18b2:a023:971b:e42c] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: badebe31-751c-4792-079f-08d759770312 x-ms-traffictypediagnostic: DM5PR2101MB1047: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02015246A9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(376002)(346002)(39860400002)(366004)(199004)(13464003)(189003)(54906003)(256004)(99286004)(46003)(9686003)(478600001)(6306002)(966005)(55016002)(10090500001)(186003)(86362001)(10290500003)(7696005)(6506007)(11346002)(22452003)(2501003)(316002)(486006)(6436002)(446003)(74316002)(71190400001)(4326008)(33656002)(14454004)(110136005)(71200400001)(7736002)(2171002)(102836004)(8990500004)(14444005)(53546011)(76176011)(6246003)(8676002)(229853002)(2906002)(305945005)(81156014)(52536014)(6116002)(76116006)(2201001)(8936002)(5660300002)(64756008)(66446008)(66946007)(66476007)(66556008)(476003)(81166006)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB1047; H:DM5PR2101MB0997.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: METPu1vKkkIkYOph9527PCWIuakf7ptofya+p11rlNNjbZTlQVKf3f138vH/KRfRr3dMzFMqm5X4mE1mlKkMccrcETIqLgV3JX6P1y0F0cSVs1eFt/IbGv9ZcE7p9UGn00wlph8BQuvXriwmqy+45kMTXdkC7/dULkV25lRq1sFBTha0ATjP7LnB0HjtzRZMLvR+k9Adk49eG+beuQzcpIuWdskKOJQ4YRDHeB7zH8khFEvM28+22iVcC3eBMk54cWoz/HZOF2CtOdSmiJaGwMB/eWMyenBzYGwEV2pmZ++bg++LRkfC/6D5mO13iKkPWgQXfmA4ok331SiVts70JTVYHVECMPUqy3FzCe3mxDXi3kmL3k5uf5w1epEJdEzZsxdQI3gu+FFh63Gd1mVPNBcGnme45uTKyQ8proESLixaMtDv7HOaqtVUW97Xu1XbHCz0CIJhSyTBi3hPe7sOlV1QDKYYU1Tkfk+6ifuHv3I= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: badebe31-751c-4792-079f-08d759770312 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 18:13:18.2558 (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: TKZw0qlBiXCKSe/cjYyr+6R3+mjU7oV1GglN9ZUaMwHveJ3wmw1Bc2qqMrcR0APXyHgV+LDxvxm1RmxX8bn21Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB1047 Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5874) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 25 Oct 2019 18:13:23 -0000 My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data= records must still be encrypted and authenticated. Otherwise, MITM can inj= ect arbitrary numbers of these. However, the current language is vague enough that I've seen major SW vendo= rs send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is RFC-c= ompliant, because " Zero-length fragments of Application Data MAY be sent". Therefore, I support clarifications in this area. Cheers, Andrei -----Original Message----- From: TLS On Behalf Of RFC Errata System Sent: Friday, October 11, 2019 9:22 PM To: ekr@rtfm.com; rdd@cert.org; kaduk@mit.edu; caw@heapingbits.net; joe@sal= owey.net; sean+ietf@sn3rd.com Cc: lperrin@bellaliant.net; tls@ietf.org; rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC8446 (5874) The following errata report has been submitted for RFC8446, "The Transport = Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.rfc= -editor.org%2Ferrata%2Feid5874&data=3D02%7C01%7CAndrei.Popov%40microsof= t.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47= %7C1%7C0%7C637064509493396889&sdata=3D61wnX96xJGd6FSLbxEQAJNvwERSVAMGox= xvjgb7DuRo%3D&reserved=3D0 -------------------------------------- Type: Technical Reported by: Mr Laurie Perrin Section: 5.1 Original Text ------------- .... Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. Corrected Text -------------- .... Application Data messages contain data that is opaque to TLS. Application Data messages are always protected. Zero-length fragments of Application Data (i.e. those encapsulating an TLSInnerPlaintext record having a content field of length zero) MAY be sent, as they are potentially useful as a traffic analysis countermeasure. Application Data fragments MAY be split across multiple records or coalesced into a single record. Notes ----- In the interest of clarity, it may be prudent to specify the type of record= for which a fragment of length zero is being considered - it cannot be tha= t of the TLSCiphertext itself, for "Application Data messages are always pr= otected," therefore I infer this relates to the TLSInnerPlaintext content field (of l= ength "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment. Note: This comment also applies to previous versions of the TLS specificati= on, in particular with the introduction of the respective text concerning z= ero-length fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCi= pher content field of length "TLSCompressed.length" - i.e. to the TLSCompre= ssed fragment. Note: The implications of zero-length records must be considered with respe= ct to potential vectors for denial of service. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party can log in to change the status and ed= it the report, if necessary.=20 -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1= .3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ TLS mailing list TLS@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Ftls&data=3D02%7C01%7CAndrei.Popov%40micros= oft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db= 47%7C1%7C0%7C637064509493396889&sdata=3DkhYsCm5Wgkg98VESyOV8pNZCqEhA7EW= LQhGE6%2FtOgos%3D&reserved=3D0 From nobody Fri Oct 25 11:38:04 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5298A120043 for ; Fri, 25 Oct 2019 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=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 p8IpAWFEddgo for ; Fri, 25 Oct 2019 11:37:58 -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 D124F12004D for ; Fri, 25 Oct 2019 11:37:57 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id u16so2560852lfq.3 for ; Fri, 25 Oct 2019 11:37:57 -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=M7wGDwYPswWLFWFg5IM8YDvBocHnYyjmbJ6xGrdGbZc=; b=Rc01MYhWikMMNl3a6XyvVhnbihcn/Wa2ByEomMdr6/MEl1G+renU0WXNLfpqmi1MZp KT9H8el+aGmaAc/AKqRx6wpg56dzVxqYk2IETRVZe14p5+PajCmB/DQjdBJAGJ5YIsrX 7pchXCMyHob5Ca1fzqtLf78Iohj4lpT58OvLSj7ZA3Ky2E8xFSepxB+g7kNsZ7T4yrfG Faz7S3WfneB8fICiOs2Jnrj6aeUmYw4zLF0wVYKoRnj+tP8EaJ7L10WqeUgH1yjODw9k g74oO9pUs6dS++FHHgRBVcnnVaqSw5P5bzVfz04htzLISdMGTCRVsF3z1FgGvIYwyCmA KUXQ== 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=M7wGDwYPswWLFWFg5IM8YDvBocHnYyjmbJ6xGrdGbZc=; b=U8NhQzfldA+UR8JmutsqXJ/EJYBa7rcYeL7FbZfCYjHHwAmIMyXfnurOIr1AKNZXsC FFHtmkJrE4yeQu0KJCw2Pfb/w/7DUrHD2pbvHLyhjLDE/1Fp4j1K686CbsT5zzPILuQk 6V9Cs6rg15g0z8OeNOoc8Rkm5fEvD2RkMC/sbSlj4vrB93KGJ8Nacx8LjdyopFSVtzYB I0D0NYGckOF8/w6IEyz5e6gBnsuXWpZwHzDm4Z2CxYuADsm8GJ+SQxf6hjZ9685e29HU Pty/pvs/Cb66GmO8uEa7pXBgSISm9uW3i1EMST+5EPnTKzzUgCWS9yQ2MhUNJvR4L21p 2KWA== X-Gm-Message-State: APjAAAXwuMzScNeFjoxjQxtRDWrbednC2uVIm/xJBDgevE2IAoFjyH47 3Xcs8RgH1ZPPYZFnDtCosvWjPs8m7lfBvD0xA5qC2hlO X-Google-Smtp-Source: APXvYqwRWLd+h0JGQJKiCZ6/zSmfD4gp4mBtOwx6XlawyohB0w6rFlTxu97j7eKHSauPlsFhkrPWnhSca1ok3L/VuLQ= X-Received: by 2002:a19:6d19:: with SMTP id i25mr3660488lfc.178.1572028675927; Fri, 25 Oct 2019 11:37:55 -0700 (PDT) MIME-Version: 1.0 References: <52c0ae70-4bcd-9135-294a-126bc7e13bf1@cs.tcd.ie> <7C534382-715F-401E-911F-B788887528B0@apple.com> In-Reply-To: <7C534382-715F-401E-911F-B788887528B0@apple.com> From: Eric Rescorla Date: Fri, 25 Oct 2019 11:37:19 -0700 Message-ID: To: Tommy Pauly Cc: Steven Valdez , "TLS@ietf.org" , Stephen Farrell Content-Type: multipart/alternative; boundary="000000000000ce42950595c0724b" Archived-At: Subject: Re: [TLS] Adopting HTTPSVC for 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: Fri, 25 Oct 2019 18:38:01 -0000 --000000000000ce42950595c0724b Content-Type: text/plain; charset="UTF-8" I have some concerns here that I floated in the bug. At a high level, ipv[46]hints seems like a regression from the way things are in ESNI. -Ekr On Fri, Oct 25, 2019 at 9:01 AM Tommy Pauly wrote: > I'm also supportive of this change, and in general of using HTTPSSVC for > the transmission of ESNI keys, speaking as an implementer at Apple. > > With regards to the per-version structure, I agree with Steven that the > structure of the configuration should be able to change between versions. I > think that either specifying that the structure can change with versions, > or just moving the version into the label (Stephen's suggestion) would > work. I have a *slight* concern for the case of using a different HTTPSSVC > label for each version or set of extensions, since the code that parses out > the records may be distinct from the code that uses the keys, and it may be > easier to fetch the right information out if it has a consistent label > name. Not a huge issue either way, though. > > Thanks, > Tommy > > On Oct 25, 2019, at 7:57 AM, Steven Valdez < > svaldez=40google.com@dmarc.ietf.org> wrote: > > Chrome is supportive of this change, and will likely work on implementing > HTTPSSVC into our DNS stack once the draft progresses further. > > As for the ESNIKeys/ESNIConfig change, we were actually thinking of > something that further abstracted HTTPSSVC having to understand anything > about ESNI from the ESNI versioning: > > The ESNIKeys naming was always a bit confusing since you could have > multiple ESNIKeys, and there wasn't a great way of referring to those. > > HTTPSSVC records include a single ESNIBundle which is length prefixed and > contains one or more ESNIConfigs. (to allow an endpoint to publish multiple > ESNIConfigs, potentially supporting multiple versions of the ESNI record). > > Each ESNIConfig is then just a version and then a version-specific > structure. (to allow the entire structure of the ESNIConfigInner to > arbitrarily change at different versions). > > Something roughly like the following: > > ESNIBundle { > ESNIConfig<2..2^16-1>; > }; > > ESNIConfig { > version, > select (version) { > case 0: { > opaque public_name<1..2^16-1>; > KeyShareEntry keys<4..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > uint16 padded_length; > Extension extensions<0..2^16-1>; > } > } > }; > > (alternatively maybe make an ESNIConfigInner and stuff an opaque in > ESNIConfig that is version-specific, not sure what the right presentation > looks like) > > On Fri, Oct 25, 2019 at 6:29 AM Stephen Farrell > wrote: > >> >> Hiya, >> >> On 25/10/2019 01:28, Christopher Wood wrote: >> > Hi folks, >> > >> > DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of >> > doing the same thing, I've put together a PR that drops the custom >> > ESNI RRType in favor of this more general (yet feature compatible) >> > Resource Record: >> > >> > https://github.com/tlswg/draft-ietf-tls-esni/pull/187 >> > >> > Please have a look and comment before next Friday. We'd like to land >> > this before Singapore. >> >> I'm supportive of this change, on the assumption that browsers are >> really going to use HTTPSSVC. >> >> If that lands as-is, please bump the version to ff04 and I don't >> see much benefit in changing from ESNIKeys to ESNIConfig (seems >> more likely to confuse than help to me). >> >> Going further, I think we ought also take advantage of this to >> simplify the ESNIKeys/ESNIConfig structure. We don't need to do >> that right now but we could. >> >> There are two related simplifications that'd make sense to me: >> >> - remove the version field and encode that in the HTTPSSVC label >> (so it'd be something like esnikeys05="/wElr6L2ACQAHQ...") - I >> think that'd lead to fewer cases where HTTPSSVC code needs to >> understand what's inside the ESNIConfig structure. >> >> - similarly, remove the extensions field from ESNIConfig, and >> require a new label in HTTPSSVC if something new is really needed >> >> Cheers, >> S. >> >> > >> > Best, Chris (no hat) >> > >> > [1] >> > >> https://mailarchive.ietf..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s >> >> > >> > _______________________________________________ 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 >> > > > -- > > Steven Valdez | Chrome Privacy Sandbox | svaldez@google.com | > 210-692-4742 > _______________________________________________ > 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 > --000000000000ce42950595c0724b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have some concerns here that I floated in the bug.<= /div>

At a high level, ipv[46]hints seems like a regress= ion from the way things are in ESNI.

-Ekr


On Fri, Oct 25, 2019 at 9:01 AM Tommy Pauly <tpauly=3D40apple.com@dmarc.ietf.org&= gt; wrote:
I'm also supportive of this change= , and in general of using HTTPSSVC for the transmission of ESNI keys, speak= ing as an implementer at Apple.

With regards to the per-= version structure, I agree with Steven that the structure of the configurat= ion should be able to change between versions. I think that either specifyi= ng that the structure can change with versions, or just moving the version = into the label (Stephen's suggestion) would work. I have a *slight* con= cern for the case of using a different HTTPSSVC label for each version or s= et of extensions, since the code that parses out the records may be distinc= t from the code that uses the keys, and it may be easier to fetch the right= information out if it has a consistent label name. Not a huge issue either= way, though.

Thanks,
Tommy

On Oct 25, 2019, at 7:57 AM, Steven Valdez <= ;svaldez=3D40google.com@dmarc.ietf.org> wrote:

Chrome is supportive of this change, and will likely work on impl= ementing HTTPSSVC into our DNS=C2=A0stack once the draft progresses further= .

As for=C2=A0the ESNIKeys/ESNIConfig change, we were actually think= ing of something that further abstracted HTTPSSVC=C2=A0having to understand= anything about ESNI from the ESNI versioning:

The ESNIK= eys naming was always a bit confusing since you could have multiple ESNIKey= s, and there wasn't a great way of referring to those.
HTTPSSVC=C2=A0records include a single ESNIBundle which is len= gth prefixed and contains one or more ESNIConfigs. (to allow an endpoint to= publish multiple ESNIConfigs, potentially supporting multiple versions of = the ESNI record).

Each ESNIConfig is then just a v= ersion and then a version-specific structure. (to allow the entire structur= e of the ESNIConfigInner to arbitrarily change at different versions).
<= br>Something roughly like the following:

ES= NIBundle {
=C2=A0 ESNIConfig<2..2^16-1>;
};

ESNIConfig {=
=C2=A0 version,
=C2=A0 select= (version) {
=C2=A0 =C2=A0 case 0: {
=C2=A0 =C2=A0 =C2=A0 opaque publ= ic_name<1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 KeyShareEntry keys<4..= 2^16-1>;
=C2=A0 =C2=A0 =C2=A0 CipherSuite cipher_suites<2..2^16-2&= gt;;
=C2=A0 =C2=A0 =C2=A0 uint16 padded_length;
=C2=A0 =C2=A0 =C2=A0 = Extension extensions<0..2^16-1>;
=C2=A0 =C2=A0 }
=C2=A0 }};

(alternatively maybe make an ESNIConfigInner and stuff an= opaque in ESNIConfig that is version-specific, not sure what the right pre= sentation looks like)

On Fri, Oct 25, 2019 at 6:29 AM Stephen F= arrell <s= tephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 25/10/2019 01:28, Christopher Wood wrote:
> Hi folks,
>
> DNSOP recently adopted HTTPSSVC [1]. Rather than have two ways of
> doing the same thing, I've put together a PR that drops the custom=
> ESNI RRType in favor of this more general (yet feature compatible)
> Resource Record:
>
> https://github.com/tlswg/draft-ietf-tls-e= sni/pull/187
>
> Please have a look and comment before next Friday. We'd like to la= nd
> this before Singapore.

I'm supportive of this change, on the assumption that browsers are
really going to use HTTPSSVC.

If that lands as-is, please bump the version to ff04 and I don't
see much benefit in changing from ESNIKeys to ESNIConfig (seems
more likely to confuse than help to me).

Going further, I think we ought also take advantage of this to
simplify the ESNIKeys/ESNIConfig structure. We don't need to do
that right now but we could.

There are two related simplifications that'd make sense to me:

- remove the version field and encode that in the HTTPSSVC label
(so it'd be something like esnikeys05=3D"/wElr6L2ACQAHQ...") = - I
think that'd lead to fewer cases where HTTPSSVC code needs to
understand what's inside the ESNIConfig structure.

- similarly, remove the extensions field from ESNIConfig, and
require a new label in HTTPSSVC if something new is really needed

Cheers,
S.

>
> Best, Chris (no hat)
>
> [1]
> https://mailarchive.ietf= ..org/arch/msg/dnsop/9zCxhCfIhDzA3Cv3D2k4NF_nj4s
>
>=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


--

Stev= en Valdez=C2=A0|=C2=A0Chrome Privacy Sandbox |=C2=A0svaldez@google.com=C2=A0|=C2=A0210-692-4742
<= /div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

<= /div>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000ce42950595c0724b-- From nobody Fri Oct 25 14:17:55 2019 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 064611209E7; Fri, 25 Oct 2019 14:12:14 -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: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793401.2724.18384815539755179414.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:14 -0700 Archived-At: Subject: [TLS] tls - Requested sessions have been scheduled for IETF 106 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, 25 Oct 2019 21:13:09 -0000 Dear Christopher Wood, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:00 requested) Thursday, 21 November 2019, Morning Session I 1000-1200 Room Name: Padang size: 300 --------------------------------------------- tls Session 2 (1:00 requested) Thursday, 21 November 2019, Afternoon Session III 1740-1840 Room Name: Canning size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/tls.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Christopher Wood Number of Sessions: 2 Length of Session(s): 1 Hour, 2 Hours Number of Attendees: 120 Conflicts to Avoid: Chair Conflict: pearg git mls emu cacao 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 Fri Oct 25 18:19:27 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E231120807 for ; Fri, 25 Oct 2019 18:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 zHvMsUZlOgrM for ; Fri, 25 Oct 2019 18:19:20 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6601200E6 for ; Fri, 25 Oct 2019 18:19:20 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id 1so4464816iou.4 for ; Fri, 25 Oct 2019 18:19:20 -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=mcTMRHUrUYn5pMY0EZw/A/eJtOeYQ8fAX0WnjUiVxlo=; b=dmqhphrgIgsprvPjssYuArafyQ2zMMJy9PW1R5QrJtGY5d8Jqf1q7pP0gj34YxA9wi kVA3QRmoOZyX4yysZtVIDJHlzlQkofy8X0BcOalXGjTxYJXim6wIC8IZ08qnNR2sJ1D1 Jnj9wEOxSEMRxgZnH5426rqjyxDRUlrEwj0pmVjtucV5tSqh7zSb0KPxrS8Az2qpTljH QeXvTLIZCCNFVKe4Dxp3zRTlerYY7ZjoX1lobh8B8D1iWuU4nUKd6UZ3KNCMTFNtxvgD 7zL+TsQHOHPCo6UuynwraE57KA089qX5GS4FgrnPucxn+fZJ/inqrmp/r99irCeeppRw 2Tgg== 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=mcTMRHUrUYn5pMY0EZw/A/eJtOeYQ8fAX0WnjUiVxlo=; b=J2iWLkYdXVYaxTtD01DwVQkAfh1/MKjLIoPevYeuZNG90L6td5rNbrkhM6FyOxnbsD ogxUBWmsuf4YvE0Cu9RmjTNublMDyy6vUZGLgPtqkWRxY97OvMj7GWfxEofi8JQLiftH 0S9j9oHGFlRS2FSmQJK/jH5fvZatfevU9tEvbgAIv3vpIDLiMgcdW3J/ns0N1dwd4nxw sIj6kfkNhS2RTXz7e0Lhq1UJ9qCxSUX0ilTK7IFeP/bOdvHRFMD+58EwZbSKVn3bHjBx 1j0Uz2/jPA4ewhxwSdOibEpt+H1bhON24gYMjiwq0uuo+2bvk2orEu1aGice+E21XYUt zlVA== X-Gm-Message-State: APjAAAVeKjxYA9RWZnyWY67Dug4oJ5j7/LnTUKAKoDCe0AycFt3cxmat iV5SiPMs05AwoTkZzquxNuDl5rTxOxRwvkVvYR5D4si3AHM= X-Google-Smtp-Source: APXvYqxQ1Wuivbh0ceBaRrH2oB5T8LvhymVGgsm4+9VwCagnYjHem3AVdwC9Md6Htp+fLwqOFtPWSCbnH6INDs1RlgE= X-Received: by 2002:a5d:9297:: with SMTP id s23mr7138387iom.49.1572052759171; Fri, 25 Oct 2019 18:19:19 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Fri, 25 Oct 2019 18:19:08 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000047573d0595c60e86" Archived-At: Subject: [TLS] Suggestions regarding a few definitions in the ESNI draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 26 Oct 2019 01:19:25 -0000 --00000000000047573d0595c60e86 Content-Type: text/plain; charset="UTF-8" Hi, I filed a few issues on some definitions in the ESNI draft. "Zx = HKDF-Extract(0, Z)" https://github.com/tlswg/draft-ietf-tls-esni/issues/188 "AEAD-Encrypt" https://github.com/tlswg/draft-ietf-tls-esni/issues/189 Given that there are open source implementations to test against, I don't think these issues are critical right now, but they do seem imprecise at least. As the draft firms up, it might be nice to develop some test vectors for each step of each algorithm, so implementors can tell where things go wrong as they're developing. The ESNI process ended up being a lot more involved than I expected (but that is not a criticism). thanks, Rob --00000000000047573d0595c60e86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I filed a few issu= es on some definitions in the ESNI draft.

"Zx= =3D HKDF-Extract(0, Z)"

"AEAD-Encrypt"https= ://github.com/tlswg/draft-ietf-tls-esni/issues/189

Given that there are open source implementations to test against, I don&= #39;t think these issues are critical right now, but they do seem imprecise= at least. As the draft firms up, it might be nice to develop some test vec= tors for each step of each algorithm, so implementors can tell where things= go wrong as they're developing. The ESNI process ended up being a lot = more involved than I expected (but that is not a criticism).

=
thanks,
Rob
--00000000000047573d0595c60e86-- From nobody Fri Oct 25 22:53:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983F9120073 for ; Fri, 25 Oct 2019 22:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 JpHJ8KMXugdf for ; Fri, 25 Oct 2019 22:52:59 -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 51EF4120071 for ; Fri, 25 Oct 2019 22:52:59 -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 x9Q5qm9e018622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 26 Oct 2019 01:52:50 -0400 Date: Fri, 25 Oct 2019 22:52:47 -0700 From: Benjamin Kaduk To: Andrei Popov Cc: RFC Errata System , "ekr@rtfm.com" , "rdd@cert.org" , "caw@heapingbits.net" , "joe@salowey.net" , "sean+ietf@sn3rd.com" , "lperrin@bellaliant.net" , "tls@ietf.org" Message-ID: <20191026055247.GT69013@kduck.mit.edu> References: <20191012042149.A9B79B801A8@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (5874) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 26 Oct 2019 05:53:02 -0000 Thanks for letting us know, Andrei. That's rather depressing, but is fairly indicative that the errata report should be verified. (I think I will edit the "Notes" slightly when doing so, but am too tired to do a proper job tonight, so I'm holding off on actually marking the report as verified in the database for now.) -Ben On Fri, Oct 25, 2019 at 06:13:18PM +0000, Andrei Popov wrote: > My reading of the TLS 1.2 and 1.3 RFCs is that zero-length application_data records must still be encrypted and authenticated. Otherwise, MITM can inject arbitrary numbers of these. > > However, the current language is vague enough that I've seen major SW vendors send (and accept) 0x17 0x03 0x03 0x00 0x00 and insist that this is RFC-compliant, because " Zero-length fragments of Application Data MAY be sent". > > Therefore, I support clarifications in this area. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS On Behalf Of RFC Errata System > Sent: Friday, October 11, 2019 9:22 PM > To: ekr@rtfm.com; rdd@cert.org; kaduk@mit.edu; caw@heapingbits.net; joe@salowey.net; sean+ietf@sn3rd.com > Cc: lperrin@bellaliant.net; tls@ietf.org; rfc-editor@rfc-editor.org > Subject: [TLS] [Technical Errata Reported] RFC8446 (5874) > > The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". > > -------------------------------------- > You may review the report below and at: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5874&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&sdata=61wnX96xJGd6FSLbxEQAJNvwERSVAMGoxxvjgb7DuRo%3D&reserved=0 > > -------------------------------------- > Type: Technical > Reported by: Mr Laurie Perrin > > Section: 5.1 > > Original Text > ------------- > .... > > Application Data messages contain data that is opaque to TLS. > Application Data messages are always protected. Zero-length > fragments of Application Data MAY be sent, as they are potentially > useful as a traffic analysis countermeasure. Application Data > fragments MAY be split across multiple records or coalesced into a > single record. > > Corrected Text > -------------- > .... > > Application Data messages contain data that is opaque to TLS. > Application Data messages are always protected. Zero-length > fragments of Application Data (i.e. those encapsulating an > TLSInnerPlaintext record having a content field of length zero) > MAY be sent, as they are potentially useful as a traffic analysis > countermeasure. Application Data fragments MAY be split across > multiple records or coalesced into a single record. > > Notes > ----- > In the interest of clarity, it may be prudent to specify the type of record for which a fragment of length zero is being considered - it cannot be that of the TLSCiphertext itself, for "Application Data messages are always protected," > therefore I infer this relates to the TLSInnerPlaintext content field (of length "TLSPlaintext.length") - i.e. to the TLSPlaintext fragment. > > Note: This comment also applies to previous versions of the TLS specification, in particular with the introduction of the respective text concerning zero-length fragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content field of length "TLSCompressed.length" - i.e. to the TLSCompressed fragment. > > Note: The implications of zero-length records must be considered with respect to potential vectors for denial of service. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8446 (draft-ietf-tls-tls13-28) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date : August 2018 > Author(s) : E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7C079c32a628aa4a46749e08d74ecbc7c7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637064509493396889&sdata=khYsCm5Wgkg98VESyOV8pNZCqEhA7EWLQhGE6%2FtOgos%3D&reserved=0 From nobody Sat Oct 26 15:32:06 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F62120048 for ; Sat, 26 Oct 2019 15:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 tZTQUbiYNKKc for ; Sat, 26 Oct 2019 15:32:02 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 3FFC7120047 for ; Sat, 26 Oct 2019 15:32:02 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id i26so6409138iog.9 for ; Sat, 26 Oct 2019 15:32:02 -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=/Fhzewf4UdKKiOreuRjGOtgfYet/sootH7caasj4kMs=; b=RowD0Iv+tTrSVUmiDhv6GoxKtkGnrs4ovw+b6cb8pwI02PJcMgApcpyAWLFp0g+wOR dhqISzP8nqfxd/Qc1jAVILOhSWOaraNBI1AvXxQuUVG+ZApYXa5YQ/Yo9FI3xcyoJHyQ ePKhBIHUaaBL+uOWXdCMvdAWE+Y3GXkA+Iz9dged3mvb/4e4UA8rz2kPHSJ5cTDmhAGF /a4j8gopnqalQvmRjL23LjP6Qv2MPuz7n74WwZjx+noLl0iibZCvLwKjtcN/XoFxrZzk NL6tPItMUQ52s5zJjD/RDjynPIoYCLaAlEUwz6tX2k/WHI2XZ4DNbBwuVUFOEUuvU7QQ Kx2Q== 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=/Fhzewf4UdKKiOreuRjGOtgfYet/sootH7caasj4kMs=; b=jHJo0fVN+wnQHPVExsN1541nztOY73ZL0axz0Tcom49tRYCIYl8vnIA6TMkGlOQnej cPROyAQ6SOaXOb76zd0hS4FZ36eo41ud+++94KUzK8ifVL1hdeEliQYzXY/IGenwepkv L75uwcjt9zSwble1YMdW43evTU8KQc36jxJiERumHXje74o4lnZEsY0BkPhJfGgPTb+a GlBjLxsAt/5zpJNC4zQgzfU3SDJnooDPFiGh47lgGgaCZqPAbFvk1Sh1kuOWSACgyAQ2 J9THbMQfhtPgx5AgGpVS7fVbhGok82q0NxuWRHsqMRI/9zlIURYWvEfx+ojScYvJIlJn 14WQ== X-Gm-Message-State: APjAAAW576hRXs2/Fp85WlTjvGpPKMwvZfZVPiQ2zNgsBp6Lr6PIJtYb qxlxbB5472o8p7fI/d6DGnIzwavMdZgh7bNfMJohHUr2zPs= X-Google-Smtp-Source: APXvYqxAGDjzsl15P+pbF1hFR1LqrHlUOCYXDRVbwJ+ecmfiMjHUrcU+MjRnN+a4AVKBb36NFilbtz/pY9dD15gOYAc= X-Received: by 2002:a6b:f90f:: with SMTP id j15mr11309777iog.257.1572129120994; Sat, 26 Oct 2019 15:32:00 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Sat, 26 Oct 2019 15:31:49 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cc49d40595d7d5f3" Archived-At: Subject: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 26 Oct 2019 22:32:04 -0000 --000000000000cc49d40595d7d5f3 Content-Type: text/plain; charset="UTF-8" Hi, I think I have a working ESNI client, but I'm encountering a strange error testing with Cloudflare. I initially tested with "cloudflare.com", but found this was a bad idea, because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI triggered no errors. When my client sends an ESNI to a Cloudfront-fronted domain, I get a handshake_failure error (40). According to the -02 draft, this should only happen if the server fails to negotiate TLS 1.3. I've got my client configured for TLS 1.3 only, so this shouldn't be an issue. When I add an unencrypted SNI to an otherwise identical ClientHello, everything works over TLS 1.3. If there are problems with my ESNI encryption, I should see other errors. Things like "illegal_parameter" or "decrypt_error", right? In Wireshark, I can at least see that my encrypted_server_name extension matches Firefox's cipher and key share entries, and the lengths of record_digest and encrypted_sni are the same. Firefox does send some extensions I don't, like ALPN. Does the absence of unencrypted SNI imply the presence of other extensions? I also wondered about extension order. Since the ClientHello.key_share is part of the ESNI calculation, does it need to appear first in the extensions list? thanks, Rob --000000000000cc49d40595d7d5f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think I have a working ESNI c= lient, but I'm encountering a strange error testing with Cloudflare.

I initially tested with "cloudflare.com", but found this was a bad idea, becaus= e that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI tr= iggered no errors.

When my client sends an ESN= I to a Cloudfront-fronted domain, I get a handshake_failure error (40). Acc= ording to the -02 draft, this should only happen if the server fails to neg= otiate TLS 1.3. I've got my client configured for TLS 1.3 only, so this= shouldn't be an issue. When I add an unencrypted SNI to an otherwise i= dentical ClientHello, everything works over TLS 1.3. If there are problems = with my ESNI encryption, I should see other errors. Things like "illeg= al_parameter" or "decrypt_error", right?

In Wireshark, I can at least see that my encrypted_server_name extens= ion matches=C2=A0Firefox's cipher and key share entries, and the length= s of record_digest and encrypted_sni are the same. Firefox does send some e= xtensions I don't, like ALPN. Does the absence of unencrypted SNI imply= the presence of other extensions?

I also wondered= about extension order. Since the ClientHello.key_share is part of the ESNI= calculation, does it need to appear first in the extensions list?

thanks,
Rob
--000000000000cc49d40595d7d5f3-- From nobody Sat Oct 26 17:45:37 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3045120129 for ; Sat, 26 Oct 2019 17:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=nCmYaMoT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QCYthGuE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3URL9dt47GQv for ; Sat, 26 Oct 2019 17:45:27 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977D1120106 for ; Sat, 26 Oct 2019 17:45:27 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 348A23AF for ; Sat, 26 Oct 2019 20:45:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 26 Oct 2019 20:45: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= fm1; bh=+g+bkKsIVBmzwwdzUkhm4DacXLPQ0M5WSkAgGgDm2Lo=; b=nCmYaMoT cDBxuArdTXY/pyUqVzuLmZ6b+EJYxTynPO6F1QZGWq3+BgMtK8nW56VKXuS5YlBl hVjCrfqU5p3eGWWaMjnBwz397tb7BUkk1aXtN45Gwms3bMLuw24hs1Zp5qjCi0/q D/GqmYIGp1EWfFeIrzDitSZE2PDwKmrLH4oDdP6ry2i25hCBt0CigpMAeQQ22WSu 0saEXqWtgiSKZDEd0SICGNxw9tiVV73vX10x5mprNMNAP+PrBUaChuJxVOB+/m5N do2i6lp1UZ7Y9qlLj0MnU7m9uck5fqAHSoDhRsviuFo/mQOPzDfT+351priPFgJN u+6wGxXBkOa6cg== 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=fm1; bh=+g+bkKsIVBmzwwdzUkhm4DacXLPQ0 M5WSkAgGgDm2Lo=; b=QCYthGuE8l+9Kc9OUGotFIPxZnFAVFBnYyvjBEh0tObH0 QrzTiGlnvLe3i1Dmjz6r6+oHoYsQAr4sgGyB87aAWbj1l+NLzHSaaTh7NG2B2O8x W14kFsx6GGMfK3bxd3jxlDM7mjJR78S8VtXqKPm6nGqAUMEVm1uNehhi4nz84BZN 51b80UKC/l+CVjELD9RUd7dwUs8GE5wyIsU36FbvDz59oiVik69PWJ89/5OCTqhA 6jIXqLf94MZHgfPUIHEOJQY9VpDSI2uU27Nvy0g8nSlqZsrY80qsuci/ffPxl8Jy 9+ZglDiIRFEc7AtrNvpHbko/KeblQA991zIcNJb+g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrleeigdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomhepifhithhhuhgsucfpohhtihhfihgtrghtihhonhhsuceoughopghnohhtpghr vghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdphh htthhpshhvtgdrsgihnecukfhppeeghedrjeelrdduudefrdduieehnecurfgrrhgrmhep mhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtnecuvehluh hsthgvrhfuihiivgeptd X-ME-Proxy: Received: from cloud.mnot.net (cloud.mnot.net [45.79.113.165]) by mail.messagingengine.com (Postfix) with ESMTPA id 9003DD60057 for ; Sat, 26 Oct 2019 20:45:26 -0400 (EDT) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 0460F9E71C for ; Sun, 27 Oct 2019 00:45:26 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0083252495696084547==" MIME-Version: 1.0 From: Github Notifications To: tls@ietf.org Message-Id: <20191027004526.0460F9E71C@cloud.mnot.net> Date: Sun, 27 Oct 2019 00:45:26 +0000 (UTC) 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, 27 Oct 2019 00:45:35 -0000 --===============0083252495696084547== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92=AC8) 2 issues created: - AEAD-Encrypt definition (by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/189=20 - "HKDF-Extract(0, Z)" (by sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/188=20 1 issues received 8 new comments: - #189 AEAD-Encrypt definition (8 by ekr, sayrer) https://github.com/tlswg/draft-ietf-tls-esni/issues/189=20 * tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #20 Document security requirements and properties (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/20= =20 1 issues closed: - Document security requirements and properties https://github.com/tlswg/= draft-ietf-tls-external-psk-importer/issues/20=20 * tlswg/dtls-conn-id (+0/-2/=F0=9F=92=AC3) 2 issues received 3 new comments: - #69 Preconditions for accepting address update events (2 by boaks, thom= as-fossati) https://github.com/tlswg/dtls-conn-id/issues/69=20 - #64 Peer address validation (1 by thomas-fossati) https://github.com/tlswg/dtls-conn-id/issues/64=20 2 issues closed: - Preconditions for accepting address update events https://github.com/tl= swg/dtls-conn-id/issues/69=20 - Peer address validation https://github.com/tlswg/dtls-conn-id/issues/64= =20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC19) 2 pull requests submitted: - Replace ESNIKeys with ESNIConfig, and delegate the publishing container= to HTTPSVC. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/187=20 - Proposal: Use a hash instead of padding (by bemasc) https://github.com/tlswg/draft-ietf-tls-esni/pull/186=20 4 pull requests received 19 new comments: - #187 Replace ESNIKeys with ESNIConfig, and delegate the publishing cont= ainer to HTTPSVC. (15 by bemasc, chris-wood, davidben, ekr) https://github.com/tlswg/draft-ietf-tls-esni/pull/187=20 - #186 Proposal: Use a hash instead of padding (2 by bemasc, davidben) https://github.com/tlswg/draft-ietf-tls-esni/pull/186=20 - #176 Clarify that ESNIContents is not transmitted (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/176=20 - #71 Clarifications (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/pull/71=20 2 pull requests merged: - Remove partial split mode https://github.com/tlswg/draft-ietf-tls-esni/pull/185=20 - Clarify that ESNIContents is not transmitted https://github.com/tlswg/draft-ietf-tls-esni/pull/176=20 * tlswg/dtls-conn-id (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - Address validation take 2 https://github.com/tlswg/dtls-conn-id/pull/70=20 * tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC4) 1 pull requests submitted: - Asn1 module (by seanturner) https://github.com/tlswg/tls-subcerts/pull/38=20 1 pull requests received 4 new comments: - #38 Asn1 module (4 by russhousley, seanturner, siyengar) https://github.com/tlswg/tls-subcerts/pull/38=20 Repositories tracked by this digest: ----------------------------------- * 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 --===============0083252495696084547== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday October 27, 2019

Issues

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

2 issues created:

1 issues received 8 new comments:

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

1 issues received 1 new comments:

1 issues closed:

tlswg/dtls-conn-id (+0/-2/=F0=9F=92=AC3)

2 issues received 3 new comments:

2 issues closed:

Pull requests

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

2 pull requests submitted:

4 pull requests received 19 new comments:

2 pull requests merged:

tlswg/dtls-conn-id (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

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

1 pull requests submitted:

1 pull requests received 4 new comments:

Repositories tracked by this digest:

--===============0083252495696084547==-- From nobody Sat Oct 26 19:43:55 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AB0120043 for ; Sat, 26 Oct 2019 19:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 LF_mbsz4sBYy for ; Sat, 26 Oct 2019 19:43:51 -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 595B1120013 for ; Sat, 26 Oct 2019 19:43:51 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id z10so5077040ilo.8 for ; Sat, 26 Oct 2019 19:43: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; bh=HcSx/JeZsoXRixtz9PgSmv+iGyey/Ua7ohoU7DensVM=; b=M/T8bvwGWgyHW6Ny6PPjZVybYw6eQeS3omsWbfCTldOWVhPIbAfjbCqBj1x8Jzz5fj 2ZccPfa9QpK8hOKdUfkctEzy7/vKp6XpU8LcLVFp00QRglQutWdiVXM+HgRp63/LiQWf guPe/sQXFHimR4fb1rpHzw6hdBWFKMY82FIDBEzmlh8CznpthWE+UEgHZGqgMcY9qhoc GGWhHqX/9lz5WLQu4C//6yr+rHpiviQSPZvg+GOU3PTTsZaj+92XBVsUhcpT28XopDFM zB6S8FHxvUOSJPBnBf/t6B27NOsQsZ8vRBm3RIBIl9+nkbMMsQKPkI7jLVxBQDkgDAIR F8LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=HcSx/JeZsoXRixtz9PgSmv+iGyey/Ua7ohoU7DensVM=; b=IlZ3s+dkNTN8tOnvVZT1YmnFOlubT9MFK6m35IueuEfxQbhYvOItwL/LHXB9wl/E4s 4YEMU6/p+UDdYdRe3NwqeB96ghPcHvKpoJCIrJuOcgnJoM4kkfOtDBcKeJPZ5s1ZATPn DW/IqwexhfW1z+ybYN3JFohWWylzFg2UosxTfIlHo7WIX+nTuP0AclcLAQ1buVPxXtKX B1X23eRORtBp9NgJoWe3OOBYuu5fsdKEv2XYtPHxUJu/6NKifa6IEe5h0gpakwb6Keb2 lw8taT6JFj+why7dIgJPstNQtCeo8pw3i+0zXaSuhsUPxrWzhAbt6fOXiwAaqFF33yGR D0xA== X-Gm-Message-State: APjAAAW73Dd/RTXYPlTBr9B7HERt4CUXhtPVRys6BWkc8Zw2c4zB7OoQ +Ylpo+xBBP2crSjtvb6RX5QXfGyDd0UUQe94Z5y1FdMrUEcRsw== X-Google-Smtp-Source: APXvYqx3TJNw+v7TI/rv9aXR6PpTzv6W1JymDn7uoJLJoAXCACihLdooU2/CztqbFj/IMirtO6qG7Cw/65YDzZ8R2NE= X-Received: by 2002:a92:48cf:: with SMTP id j76mr12824677ilg.189.1572144229135; Sat, 26 Oct 2019 19:43:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sat, 26 Oct 2019 19:43:38 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000503b920595db5af5" Archived-At: Subject: Re: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 27 Oct 2019 02:43:54 -0000 --000000000000503b920595db5af5 Content-Type: text/plain; charset="UTF-8" As an update, I seem to be able to negotiate a handshake with "only.esni.defo.ie", but I must be making a mistake in my ClientHello. Wireshark sees Firefox's ClientHello as TLS 1.3, but mine only shows up as TLS 1.0, although the " only.esni.defo.ie" ServerHello does show up as TLS 1.3. You check out the details on that host at https://defo.ie/ . My client fails to read application data after that, although the server does seem to send it. You can check out my fork of Rustls here: https://github.com/grafica/rustls If you then do something like: $ cd rustls/rustls-mio/ $ cargo run --example esniclient you should see some ESNI traffic. Some of the code in the fork is a little messy so far, but it's still in the "make it work" phase. :) thanks, Rob On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre wrote: > Hi, > > I think I have a working ESNI client, but I'm encountering a strange error > testing with Cloudflare. > > I initially tested with "cloudflare.com", but found this was a bad idea, > because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI > triggered no errors. > > When my client sends an ESNI to a Cloudfront-fronted domain, I get a > handshake_failure error (40). According to the -02 draft, this should only > happen if the server fails to negotiate TLS 1.3. I've got my client > configured for TLS 1.3 only, so this shouldn't be an issue. When I add an > unencrypted SNI to an otherwise identical ClientHello, everything works > over TLS 1.3. If there are problems with my ESNI encryption, I should see > other errors. Things like "illegal_parameter" or "decrypt_error", right? > > In Wireshark, I can at least see that my encrypted_server_name extension > matches Firefox's cipher and key share entries, and the lengths of > record_digest and encrypted_sni are the same. Firefox does send some > extensions I don't, like ALPN. Does the absence of unencrypted SNI imply > the presence of other extensions? > > I also wondered about extension order. Since the ClientHello.key_share is > part of the ESNI calculation, does it need to appear first in the > extensions list? > > thanks, > Rob > --000000000000503b920595db5af5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As an update,

I seem to be able to nego= tiate a handshake with "only.esni= .defo.ie", but I must be making a mistake in my ClientHello. Wires= hark sees Firefox's ClientHello as TLS 1.3, but mine only shows up as T= LS 1.0, although the=C2=A0"only.e= sni.defo.ie" ServerHello does show up as TLS 1.3.=C2=A0You check o= ut the details on that host at=C2=A0https://de= fo.ie/ .

My client fails to read application d= ata after that, although=C2=A0the server does seem to send it.
You can check out my fork of Rustls here:
https://github.com/grafica/rustls

I= f you then do something like:
$ cd rustls/rustls-mio/
$ cargo run --e= xample esniclient

you should see some ESNI tra= ffic. Some of the code in the fork is a little messy so far, but it's s= till in the "make it work" phase. :)

tha= nks,
Rob
=C2=A0

On Sat, Oct 26, 2019 at 3:31 PM Ro= b Sayre <sayrer@gmail.com> wr= ote:
Hi,

I think I have a working ESNI client, but = I'm encountering a strange error testing with Cloudflare.
I initially tested with "cloudflare.com", but found this was a bad idea,= because that host doesn't seem to require an SNI or ESNI. So, a bogus = ESNI triggered no errors.

When my client sends= an ESNI to a Cloudfront-fronted domain, I get a handshake_failure error (4= 0). According to the -02 draft, this should only happen if the server fails= to negotiate TLS 1.3. I've got my client configured for TLS 1.3 only, = so this shouldn't be an issue. When I add an unencrypted SNI to an othe= rwise identical ClientHello, everything works over TLS 1.3. If there are pr= oblems with my ESNI encryption, I should see other errors. Things like &quo= t;illegal_parameter" or "decrypt_error", right?
In Wireshark, I can at least see that my encrypted_server_name= extension matches=C2=A0Firefox's cipher and key share entries, and the= lengths of record_digest and encrypted_sni are the same. Firefox does send= some extensions I don't, like ALPN. Does the absence of unencrypted SN= I imply the presence of other extensions?

I also w= ondered about extension order. Since the ClientHello.key_share is part of t= he ESNI calculation, does it need to appear first in the extensions list?

thanks,
Rob
--000000000000503b920595db5af5-- From nobody Sun Oct 27 14:34:05 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F2E12006B for ; Sun, 27 Oct 2019 14:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 K78VK6jtjt_R for ; Sun, 27 Oct 2019 14:34:00 -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 23064120052 for ; Sun, 27 Oct 2019 14:34:00 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id s6so2884802iln.0 for ; Sun, 27 Oct 2019 14:34: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; bh=xRV1dyrf08ac74Rszq/gN7xdvRDyoi+nPXoCA7N1KeY=; b=Jo8QW2/iRxdasgCLMbiDpMBC4ZrPKhuHfP4nnjIhY+wg+Xc7f62lKuvUCu2+cpF6MB w5qMO+3kUcnquW/8THvD69i0mPETgnNsu750xWeVsAUZtecAAOQGRNHkJ0508NCwhMxw Q1BSaYCIqjIZNkFEbawFuBGHpz0s99PLdtEiazbBl/L84x7oF5gAHZr1EC1CRcvmi7OH 0ItgPjb4Zc1ajAhnbnenWqMVYUx7wxaObrVt2oI/tGvMoJUE3X1960aFwWR4skKL5Wrz 2yUUJvv4+pGXY9BDzmXTYlZA8+fdeZa3QjblWwpJ8eIJHZUyecw3e2JuBPVk26i8Y0ep D1vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=xRV1dyrf08ac74Rszq/gN7xdvRDyoi+nPXoCA7N1KeY=; b=A5en5uqDubT9XSrnIB7rCQOQoinBMyiSVnBe2IOfASzkwGyxrbaGQTKlNkAOGwyHEG YaATIC8eDoFoDQyYchQcDwMidYm/4hKtZMJsAi924ZpU71CcwKDU2fX8xn89HWW7npze 88HOvcBmhjTLNyQcVEV97U/j7ZEJS2OTBXdJLNuf8/78y+eBwwr+ejBcCSnaJvmdYivv BVu3on8Ak7OYrnCfVuzdkPtIgP0C3cVyuDWSmt3Ww7AFtpHYfKWTeu6RP4O+udfmMYLa 2grj6ZhAM3AOSBkp7YUOB36TXqHg2iaXYOwYTaCtGiIP6UDNhmAvgv+i2GrlcETGtlGh mqsg== X-Gm-Message-State: APjAAAUfBhZp0VYGIisym3GGM8mbukbYMOEZnREIK8FgrUlArEMTnl4r 8DVAFX4iKQUY/pK1TwjfqhuaYh4ppC+Ahod6w6ybc0MrGXOs6Q== X-Google-Smtp-Source: APXvYqzimOPVPdejK9xYb5opkq1FP8iR7LlxOZAch8W4U0+qAl79E1/UjKPqdkSyYfan3aJfU2x+W7kK0jt2aC999tI= X-Received: by 2002:a92:8394:: with SMTP id p20mr17362486ilk.73.1572212038850; Sun, 27 Oct 2019 14:33:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sun, 27 Oct 2019 14:33:45 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000165f1d0595eb244f" Archived-At: Subject: Re: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 27 Oct 2019 21:34:03 -0000 --000000000000165f1d0595eb244f Content-Type: text/plain; charset="UTF-8" Hi, This code works with medium.com (hosted by Cloudflare). I was previously testing with a parked domain. Maybe there's some signaling needed when the handshake fails based on Split Mode / Shared Mode configuration. thanks, Rob On Sat, Oct 26, 2019 at 7:43 PM Rob Sayre wrote: > As an update, > > I seem to be able to negotiate a handshake with "only.esni.defo.ie", but > I must be making a mistake in my ClientHello. Wireshark sees Firefox's > ClientHello as TLS 1.3, but mine only shows up as TLS 1.0, although the " > only.esni.defo.ie" ServerHello does show up as TLS 1.3. You check out the > details on that host at https://defo.ie/ . > > My client fails to read application data after that, although the server > does seem to send it. > > You can check out my fork of Rustls here: > https://github.com/grafica/rustls > > If you then do something like: > $ cd rustls/rustls-mio/ > $ cargo run --example esniclient > > you should see some ESNI traffic. Some of the code in the fork is a little > messy so far, but it's still in the "make it work" phase. :) > > thanks, > Rob > > > On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre wrote: > >> Hi, >> >> I think I have a working ESNI client, but I'm encountering a strange >> error testing with Cloudflare. >> >> I initially tested with "cloudflare.com", but found this was a bad idea, >> because that host doesn't seem to require an SNI or ESNI. So, a bogus ESNI >> triggered no errors. >> >> When my client sends an ESNI to a Cloudfront-fronted domain, I get a >> handshake_failure error (40). According to the -02 draft, this should only >> happen if the server fails to negotiate TLS 1.3. I've got my client >> configured for TLS 1.3 only, so this shouldn't be an issue. When I add an >> unencrypted SNI to an otherwise identical ClientHello, everything works >> over TLS 1.3. If there are problems with my ESNI encryption, I should see >> other errors. Things like "illegal_parameter" or "decrypt_error", right? >> >> In Wireshark, I can at least see that my encrypted_server_name extension >> matches Firefox's cipher and key share entries, and the lengths of >> record_digest and encrypted_sni are the same. Firefox does send some >> extensions I don't, like ALPN. Does the absence of unencrypted SNI imply >> the presence of other extensions? >> >> I also wondered about extension order. Since the ClientHello.key_share is >> part of the ESNI calculation, does it need to appear first in the >> extensions list? >> >> thanks, >> Rob >> > --000000000000165f1d0595eb244f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This code works with medium.com (hosted by Cloudflare). I was previously= testing with a parked domain. Maybe there's some signaling needed when= the handshake fails based on=C2=A0Split Mode / Shared Mode configuration.<= /div>

thanks,
Rob

On Sat, = Oct 26, 2019 at 7:43 PM Rob Sayre <s= ayrer@gmail.com> wrote:
As an update,

I seem to = be able to negotiate a handshake with "only.esni.defo.ie", but I must be making a= mistake in my ClientHello. Wireshark sees Firefox's ClientHello as TLS= 1.3, but mine only shows up as TLS 1.0, although the=C2=A0"only.esni.defo.ie" Se= rverHello does show up as TLS 1.3.=C2=A0You check out the details on that h= ost at=C2=A0https://defo.ie/= .

My client fails to read application data af= ter that, although=C2=A0the server does seem to send it.



On Sat, Oct 26, 2019= at 3:31 PM Rob Sayre <sayrer@gmail.com> wrote:
Hi,

I think I = have a working ESNI client, but I'm encountering a strange error testin= g with Cloudflare.

I initially tested with "<= a href=3D"http://cloudflare.com" target=3D"_blank">cloudflare.com"= , but found this was a bad idea, because that host doesn't seem to requ= ire an SNI or ESNI. So, a bogus ESNI triggered no errors.
When my client sends an ESNI to a Cloudfront-fronted domain, I = get a handshake_failure error (40). According to the -02 draft, this should= only happen if the server fails to negotiate TLS 1.3. I've got my clie= nt configured for TLS 1.3 only, so this shouldn't be an issue. When I a= dd an unencrypted SNI to an otherwise identical ClientHello, everything wor= ks over TLS 1.3. If there are problems with my ESNI encryption, I should se= e other errors. Things like "illegal_parameter" or "decrypt_= error", right?

In Wireshark, I can at least s= ee that my encrypted_server_name extension matches=C2=A0Firefox's ciphe= r and key share entries, and the lengths of record_digest and encrypted_sni= are the same. Firefox does send some extensions I don't, like ALPN. Do= es the absence of unencrypted SNI imply the presence of other extensions?

I also wondered about extension order. Since the Cl= ientHello.key_share is part of the ESNI calculation, does it need to appear= first in the extensions list?

thanks,
R= ob
--000000000000165f1d0595eb244f-- From nobody Sun Oct 27 20:46:20 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBCE1200B6 for ; Sun, 27 Oct 2019 20:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 bJgqRnMsaR1S for ; Sun, 27 Oct 2019 20:46:15 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E68D120044 for ; Sun, 27 Oct 2019 20:46:15 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id s75so7000563ilc.3 for ; Sun, 27 Oct 2019 20:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=6j+VVaYsCVz7n5cAQTFFA4anNBmFkmdMBDWwTsy/WVg=; b=IsxTXHE3Wi3G8BV+2cl3IAmmt7oG2OR5n2ESM0HFBO+lHzGuIw9ajifTfk/a0w1a50 frQxM8jvYuthXR4dzb1shIgGmQdfJdhXRmtNaZSF/7th6zNP/TjYfGKTqeOduTr5W+rV S7PEYL5SQ2AI4Yq1UsWBEUpRfsAGRSCET41iitgwd3TVi1+XVz4gf9JkP9ljnrDN2dKM 9Q1yVml/brVQOL9axygChOmxBOkWh/KV4gf3HaQOesIZhuptY8UKt5RcsNfRAWw6HFLX hNZQfaVSE+UHeianlTWun2ysxeq7VP4cRrh6zGpyrIlfwrt6Zte0Bp69lBcEz/PjV+G/ O94g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=6j+VVaYsCVz7n5cAQTFFA4anNBmFkmdMBDWwTsy/WVg=; b=a0WLhidJKyHoPe0BVU3vtBKj6bTYBbxhb1+O4GSOaYsLw6aOXewhuCXG3i2hWWwwd9 eVrfxK1BYzc15WH6meRhM45qAc/Kq/9TwrF+UldBjFfAwrtmDQ7kCFxTQe7mzqR+TQ0T Xkt+ye9kwDSdYrJlrsAhBGQZawfRhcrY/U8C9Gm8x0qGZWzuGtnVqiDRhZVI1/LcnZky p/CGRa25q/yvhB0toUarv+UVJ7eH8pqZCWNjj7d+NPYKb7MCbxSj0s7hLUN2q8PAGGsn n1Q9ApcqBW/QV9/j8lQyUGMIBjvZ+bMfLWUu3NmGja/5dVQvRV/2T2BJoLj+RhGGUBT1 tl0g== X-Gm-Message-State: APjAAAWMCNm6qZIkN0TIdVJsTdNCi+G6aFwGTlcet7UEtA+bqB5bjGVb c28qJAqBcJlF9p8WP5OvNwj+XwtTJxnXQE8j/J4gqX4Ir20= X-Google-Smtp-Source: APXvYqwBXVe9OhKjDRkZmt/WKU6aKJmA+3fgExMu3B4YnQ07oEQaO7CLPhDuETdNfJSMUVphjsB//U5cxpXBR13uVzk= X-Received: by 2002:a92:5d49:: with SMTP id r70mr18253928ilb.257.1572234374399; Sun, 27 Oct 2019 20:46:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sun, 27 Oct 2019 20:46:01 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000063cd260595f05789" Archived-At: Subject: Re: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 28 Oct 2019 03:46:19 -0000 --00000000000063cd260595f05789 Content-Type: text/plain; charset="UTF-8" Hi, The joke is on me, because medium.com also does not check any SNI / ESNI field. :) However, I did notice that my record_digest value was off vs Firefox. And, now, I don't feel so bad. I noticed that esni-02 and esni-03 defined record_digest as: record_digest A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "checksum" to the end of the structure. This hash is computed using the hash function associated with "suite". but, esni-04 defines record_digest like so: record_digest A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from the first byte of "version" to the end of the structure. This hash is computed using the hash function associated with "suite". By following the record_digest algorithm from esni-04, I was able to match Firefox's record_digest fields for a given domain. This strikes me as very odd, since the ESNIKeys structure changed in esni-04, but I'm still using the older, esni-02 definition. So, it sure seems like people are running a strange mix of drafts at the moment. I think there's still something wrong with my calculation of the encrypted_sni field--perhaps I will have to read more NSS source code to figure out what that is. :) thanks, Rob On Sun, Oct 27, 2019 at 2:33 PM Rob Sayre wrote: > Hi, > > This code works with medium.com (hosted by Cloudflare). I was previously > testing with a parked domain. Maybe there's some signaling needed when the > handshake fails based on Split Mode / Shared Mode configuration. > > thanks, > Rob > > > On Sat, Oct 26, 2019 at 7:43 PM Rob Sayre wrote: > >> As an update, >> >> I seem to be able to negotiate a handshake with "only.esni.defo.ie", but >> I must be making a mistake in my ClientHello. Wireshark sees Firefox's >> ClientHello as TLS 1.3, but mine only shows up as TLS 1.0, although the " >> only.esni.defo.ie" ServerHello does show up as TLS 1.3. You check out >> the details on that host at https://defo.ie/ . >> >> My client fails to read application data after that, although the server >> does seem to send it. >> >> You can check out my fork of Rustls here: >> https://github.com/grafica/rustls >> >> If you then do something like: >> $ cd rustls/rustls-mio/ >> $ cargo run --example esniclient >> >> you should see some ESNI traffic. Some of the code in the fork is a >> little messy so far, but it's still in the "make it work" phase. :) >> >> thanks, >> Rob >> >> >> On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre wrote: >> >>> Hi, >>> >>> I think I have a working ESNI client, but I'm encountering a strange >>> error testing with Cloudflare. >>> >>> I initially tested with "cloudflare.com", but found this was a bad >>> idea, because that host doesn't seem to require an SNI or ESNI. So, a bogus >>> ESNI triggered no errors. >>> >>> When my client sends an ESNI to a Cloudfront-fronted domain, I get a >>> handshake_failure error (40). According to the -02 draft, this should only >>> happen if the server fails to negotiate TLS 1.3. I've got my client >>> configured for TLS 1.3 only, so this shouldn't be an issue. When I add an >>> unencrypted SNI to an otherwise identical ClientHello, everything works >>> over TLS 1.3. If there are problems with my ESNI encryption, I should see >>> other errors. Things like "illegal_parameter" or "decrypt_error", right? >>> >>> In Wireshark, I can at least see that my encrypted_server_name extension >>> matches Firefox's cipher and key share entries, and the lengths of >>> record_digest and encrypted_sni are the same. Firefox does send some >>> extensions I don't, like ALPN. Does the absence of unencrypted SNI imply >>> the presence of other extensions? >>> >>> I also wondered about extension order. Since the ClientHello.key_share >>> is part of the ESNI calculation, does it need to appear first in the >>> extensions list? >>> >>> thanks, >>> Rob >>> >> --00000000000063cd260595f05789 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The joke is on me, because medium.com also does not check any SNI / ESNI fi= eld. :)

However, I did notice that my record_diges= t value was off vs Firefox. And, now, I don't feel so bad.
I noticed that esni-02 and esni-03 defined record_digest as:

record_digest =C2=A0A cryptographic hash of the ESN= IKeys structure from
=C2=A0 =C2=A0 =C2=A0 which the ESNI key was obtai= ned, i.e., from the first byte of
=C2=A0 =C2=A0 =C2=A0 "checksum&qu= ot; to the end of the structure.=C2=A0 This hash is computed
=C2=A0 =C2= =A0 =C2=A0 using the hash function associated with "suite".
<= br>
but, esni-04 defines record_digest like so:

record_digest =C2=A0A cryptographic hash of the ESNIKeys structure = from
=C2=A0 =C2=A0 =C2=A0 which the ESNI key was obtained, i.e., from = the first byte of
=C2=A0 =C2=A0 =C2=A0 "version" to the end of= the structure.=C2=A0 This hash is computed
=C2=A0 =C2=A0 =C2=A0 using t= he hash function associated with "suite".

= By following the record_digest algorithm from esni-04, I was able to match = Firefox's record_digest fields for a given domain. This strikes me as v= ery odd, since the ESNIKeys structure changed in esni-04, but I'm still= using the older, esni-02 definition. So, it sure seems like people are run= ning a strange mix of drafts at the moment. I think there's still somet= hing wrong with my calculation of the encrypted_sni field--perhaps I will h= ave to read more NSS source code to figure out what that is. :)
<= br>
thanks,
Rob


On Sun, Oct 27, 201= 9 at 2:33 PM Rob Sayre <sayrer@gmail= .com> wrote:
Hi,

This code works with medium.com (hosted by Cloudfl= are). I was previously testing with a parked domain. Maybe there's some= signaling needed when the handshake fails based on=C2=A0Split Mode / Share= d Mode configuration.

thanks,
Rob
<= div>

On Sat, Oct 26, 2019 at 7:43 PM Rob Sayre <sayrer@gmail.com> wrote:
A= s an update,

I seem to be able to negotiate a handshake = with "only.esni= .defo.ie", but I must be making a mistake in my ClientHello. Wires= hark sees Firefox's ClientHello as TLS 1.3, but mine only shows up as T= LS 1.0, although the=C2=A0"only.esni.defo.ie" ServerHello does show up as TLS 1.3= .=C2=A0You check out the details on that host at=C2=A0https://defo.ie/ .

M= y client fails to read application data after that, although=C2=A0the serve= r does seem to send it.

You can check out my fork = of Rustls here:
https://github.com/grafica/rustls

If you then do somethi= ng like:
$ cd rustls/rustls-mio/
$ cargo run --example esniclient
=

you should see some ESNI traffic. Some of the cod= e in the fork is a little messy so far, but it's still in the "mak= e it work" phase. :)

thanks,
Rob
=C2=A0

On Sat, Oct 26, 2019 at 3:31 PM Rob Sayre <sayrer@gmail.com> wro= te:
Hi,

I think I have a working ESNI client, but I= 'm encountering a strange error testing with Cloudflare.

=
I initially tested with "cloudflare.com", but found this was a bad idea, = because that host doesn't seem to require an SNI or ESNI. So, a bogus E= SNI triggered no errors.

When my client sends = an ESNI to a Cloudfront-fronted domain, I get a handshake_failure error (40= ). According to the -02 draft, this should only happen if the server fails = to negotiate TLS 1.3. I've got my client configured for TLS 1.3 only, s= o this shouldn't be an issue. When I add an unencrypted SNI to an other= wise identical ClientHello, everything works over TLS 1.3. If there are pro= blems with my ESNI encryption, I should see other errors. Things like "= ;illegal_parameter" or "decrypt_error", right?
In Wireshark, I can at least see that my encrypted_server_name = extension matches=C2=A0Firefox's cipher and key share entries, and the = lengths of record_digest and encrypted_sni are the same. Firefox does send = some extensions I don't, like ALPN. Does the absence of unencrypted SNI= imply the presence of other extensions?

I also wo= ndered about extension order. Since the ClientHello.key_share is part of th= e ESNI calculation, does it need to appear first in the extensions list?

thanks,
Rob
--00000000000063cd260595f05789-- From nobody Sun Oct 27 21:51:33 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654601200DE for ; Sun, 27 Oct 2019 21:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 WQswisjJMtw6 for ; Sun, 27 Oct 2019 21:51:29 -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 A3638120013 for ; Sun, 27 Oct 2019 21:51:29 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id y5so7067143ilb.5 for ; Sun, 27 Oct 2019 21:51: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; bh=N/p/6js6wihd4gP6wE93cq4fQYPsiefJySPj6k9PCPg=; b=V8USGyoqxY8fh9vdvAnb1oGBrV3xvlLKhmp4cY7vCSNeyt1+og7WIF8gFS64g8xwV2 WzSph5Ju7ryLhhxay06NGwQmkS2JDcB28hGV9sJc8J54Y43f5e5kci+v+K4qtNAhbbj5 UfApDeFtklKNClOZkEIQIy772DLTiPe9rtpBm7t8phediIbcHwxaMtdwpTSyR3c2zA5U SSefCRK/nEGdondd5LmgcfWJTErEiv/IM4MRCKb4rgeTwl8NDeDrfTnpoQ9OKs0yQIvu cTJQWa4gjA9zr3Dezxw7Hf2opWgrZB6tpxZuiSSlQijhdRhJBA+5OLZcoA8CFuHlew6I +spw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N/p/6js6wihd4gP6wE93cq4fQYPsiefJySPj6k9PCPg=; b=FGt5D9W/j7VWyrwO/t1KDebLpBCoYf5bVxB/s62jUoLDHbpDxYmTAKOWhqhkloAehD opTpj7ngEAbRlitgzRT7xDkdgrbHPUve7k2xXc32JDdS3Wc828rCFdN6RVxwUdMkXQtS l0wkrNgnnqN50moAVHYHQytHZPLuOvQ6H8aHpDGToSMrtcfSr0KT5pySimwGzzJcCMSl WI9WZfKwf3B2jcNBiV4RCBbUXddyYd57sYE+T2WtNwqvsRYCMA4rHiEQ1rchBD+11xw3 Nzp348xyvCrSsTRnXrDl9JnlAY9nSckbsF6N8hzGLPrDDljBiG4XvM37H8q+EKWuGOEc y7UA== X-Gm-Message-State: APjAAAX6vVtRw5YrnxCtimwQahWbMq0F6EqtuE0UX9uo2IGCsgyhwnno 9ieaIAJqKIDe4oxXG0LMr+if0FnD6bDkpR7Bj28BdOzJ X-Google-Smtp-Source: APXvYqztKokwpLlUbv/c4skjSOC/WdpAZmgaWVxDQ0/cE53qDLNUX53HTLXxmRGn18t3IggqXhOf0GyL/4higZrkXSU= X-Received: by 2002:a92:8394:: with SMTP id p20mr18788825ilk.73.1572238288608; Sun, 27 Oct 2019 21:51:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sun, 27 Oct 2019 21:51:15 -0700 Message-ID: To: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b1e3080595f140cd" Archived-At: Subject: Re: [TLS] ESNI interoperability questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 28 Oct 2019 04:51:31 -0000 --000000000000b1e3080595f140cd Content-Type: text/plain; charset="UTF-8" On Sun, Oct 27, 2019 at 8:46 PM Rob Sayre wrote: > Hi, > > The joke is on me, because medium.com also does not check any SNI / ESNI > field. :) > > However, I did notice that my record_digest value was off vs Firefox. And, > now, I don't feel so bad. > > I noticed that esni-02 and esni-03 defined record_digest as: > > record_digest A cryptographic hash of the ESNIKeys structure from > which the ESNI key was obtained, i.e., from the first byte of > "checksum" to the end of the structure. This hash is computed > using the hash function associated with "suite". > > but, esni-04 defines record_digest like so: > > record_digest A cryptographic hash of the ESNIKeys structure from > which the ESNI key was obtained, i.e., from the first byte of > "version" to the end of the structure. This hash is computed > using the hash function associated with "suite". > > By following the record_digest algorithm from esni-04, I was able to match > Firefox's record_digest fields for a given domain. This strikes me as very > odd, since the ESNIKeys structure changed in esni-04, but I'm still using > the older, esni-02 definition. So, it sure seems like people are running a > strange mix of drafts at the moment. I think there's still something wrong > with my calculation of the encrypted_sni field--perhaps I will have to read > more NSS source code to figure out what that is. :) > Oh, and sorry for the postscript, but a common piece of cryptographic mythology is that using the same first bytes for every hash input can weaken it. I have never looked into that assertion, and I also haven't looked into whether using a checksum in the way -02 or -03 did could be problem. Why did the draft originally omit the version number, and why does it no longer do that? thanks, Rob --000000000000b1e3080595f140cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Oct 27, 2019 at 8:46 PM Rob Sayre= <sayrer@gmail.com> wrote:
Hi,

The joke is on me, becau= se medium.com also does= not check any SNI / ESNI field. :)

However, I did= notice that my record_digest value was off vs Firefox. And, now, I don'= ;t feel so bad.

I noticed that esni-02 and esni-03= defined record_digest as:

record_digest =C2=A0A c= ryptographic hash of the ESNIKeys structure from
=C2=A0 =C2=A0 =C2=A0 = which the ESNI key was obtained, i.e., from the first byte of
=C2=A0 =C2= =A0 =C2=A0 "checksum" to the end of the structure.=C2=A0 This has= h is computed
=C2=A0 =C2=A0 =C2=A0 using the hash function associated wi= th "suite".

but, esni-04 defines record_digest= like so:

record_digest =C2=A0A cryptographic hash= of the ESNIKeys structure from
=C2=A0 =C2=A0 =C2=A0 which the ESNI ke= y was obtained, i.e., from the first byte of
=C2=A0 =C2=A0 =C2=A0 "= version" to the end of the structure.=C2=A0 This hash is computed
= =C2=A0 =C2=A0 =C2=A0 using the hash function associated with "suite&qu= ot;.

By following the record_digest algorithm from e= sni-04, I was able to match Firefox's record_digest fields for a given = domain. This strikes me as very odd, since the ESNIKeys structure changed i= n esni-04, but I'm still using the older, esni-02 definition. So, it su= re seems like people are running a strange mix of drafts at the moment. I t= hink there's still something wrong with my calculation of the encrypted= _sni field--perhaps I will have to read more NSS source code to figure out = what that is. :)

Oh, and sorry = for the postscript, but a common piece of cryptographic mythology is that u= sing the same first bytes for every hash input can weaken it. I have never = looked into that assertion, and I also haven't looked into whether usin= g a checksum in the way -02 or -03 did could be problem. Why did the draft = originally omit the version number, and why does it no longer do that?

thanks,
Rob
--000000000000b1e3080595f140cd-- From nobody Mon Oct 28 08:40:34 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AF4120125 for ; Mon, 28 Oct 2019 08:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 MsdlWPPaJoH7 for ; Mon, 28 Oct 2019 08:40:30 -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 D8C481208C4 for ; Mon, 28 Oct 2019 08:40:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8B0DCBE50; Mon, 28 Oct 2019 15:40:26 +0000 (GMT) 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 BHZ4S46UYPuk; Mon, 28 Oct 2019 15:40:24 +0000 (GMT) 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 4F995BE4D; Mon, 28 Oct 2019 15:40:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1572277224; bh=w95hYU/le4AKCo5/l4Q0enQyjE0h1808tMcijGx/e/A=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FFSHbaaseF6JcOrzMVJWbMimvdXR9BOTgoj5YY1mlhUUkEjNcIbQ711TsTvjt0GzY rcJsmUjK/Hu6EBaerKZXjpHi2UpZK7qrUxLcN0JmXr5s6lMTWBImWH0z3M6wjiEcsJ 15DwWzgemZQOuoL/O+l88rIE23LQPpUVlOdJChZI= To: "Salz, Rich" , Eric Rescorla Cc: "tls@ietf.org" References: <475194A6-17BA-43D1-B00E-BA63994A969F@akamai.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= 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: <6d5f02e7-e15c-49db-e0b4-da3627390657@cs.tcd.ie> Date: Mon, 28 Oct 2019 15:40:22 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <475194A6-17BA-43D1-B00E-BA63994A969F@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GeudkEYES9MoeaT9xWNeaRvzocz0KTIDl" Archived-At: Subject: Re: [TLS] ESNI PEM files X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is the mailing list 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, 28 Oct 2019 15:40:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GeudkEYES9MoeaT9xWNeaRvzocz0KTIDl Content-Type: multipart/mixed; boundary="cNIBvAPpzSIlZb9G9EiKeNH2vUFQWUUh4"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Eric Rescorla Cc: "tls@ietf.org" Message-ID: <6d5f02e7-e15c-49db-e0b4-da3627390657@cs.tcd.ie> Subject: Re: [TLS] ESNI PEM files References: <475194A6-17BA-43D1-B00E-BA63994A969F@akamai.com> In-Reply-To: <475194A6-17BA-43D1-B00E-BA63994A969F@akamai.com> --cNIBvAPpzSIlZb9G9EiKeNH2vUFQWUUh4 Content-Type: multipart/mixed; boundary="------------20770A95F83C484DE051318B" Content-Language: en-GB This is a multi-part message in MIME format. --------------20770A95F83C484DE051318B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 25/10/2019 16:22, Salz, Rich wrote: > I prefer an informative (not- normative) appendix of, like, 3 > sentences or so. >=20 > This will need all the implementation and operational help it can > get, and scattering things across multiple teensy docs is not > helpful. >=20 I agree with Rich - if a bunch of TLS server code bases adopt this, it'd be better as an appendix to the ESNI spec. However, to help move things along, I submitted [1]. I'm happy to make sensible changes to that however suits other implementers, but that's what I've coded up for now. Cheers, S. [1] https://tools.ietf.org/html/draft-farrell-tls-pemesni-00 --------------20770A95F83C484DE051318B 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----- --------------20770A95F83C484DE051318B-- --cNIBvAPpzSIlZb9G9EiKeNH2vUFQWUUh4-- --GeudkEYES9MoeaT9xWNeaRvzocz0KTIDl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl23C+cACgkQWrL68XsX K+rXWA//bk0TpblJ2TXWu8y57Exl/WIOHP9TGLIdjIPHS/p5ZOWgqJj5yacUgjED 9xB1o4X0IZP469LJ1Y9ToIR3Xk4ff/dm6CjfeYGBYJo3dFV5DAGS078SLYtCL3nu AlSbZi4Cbl+k6+DH2dCCM+mXERyj+EGQ02or3Ukg46LeEmTocsu67Ktm63S5QCl3 guIICCD1IJced6OGjj/FYpbJ3aXJ+IPlo5db4nnbu3l4HbhLmoG4JyakwW26Yg0B a0pCxHT1w80tXKJkzrQHRjvT1kyn2JsVwN6qmkRsprUHOMreddAtjA6dIxHoc+c2 NY4kbjFWPNZX6hVQW/DzQVBuk5xCDBLUXQ5vr3R2VbZW15JI6/mhWV1qQDbLqxBO hNRb0gvwjH5QpUM9NQcdRueD09ZODZxsPJFGe0Lzq68Oc5lzz1907Njs+pb9rsN+ /6mV3BjKLC8Yav9CbW7C68CH0CVvLtuO8INGUvCQ+7GGKg1rTUjsitn8OjNeFJy5 ZTGI+0QAgkwzJPq+8ZfVs5qv+A3mwKqK4ito7HhesTQtdUnfj7YOLsgmu2uTOWvf PZqE3vGvIAIQWTHk6ZRFVJ5E3lia6MYsH1qlOtpaHUpMe0y3wgfF1S+eHbflv5fa PX8K97hkD8p/IQLFjfWHKp/Eq3a9XOgvgryMR3GJDclBZrpvXhU= =tXeR -----END PGP SIGNATURE----- --GeudkEYES9MoeaT9xWNeaRvzocz0KTIDl-- From nobody Mon Oct 28 14:50:55 2019 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 223D6120096; Mon, 28 Oct 2019 14:50:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <157229945305.16130.12384963205830531494@ietfa.amsl.com> Date: Mon, 28 Oct 2019 14:50:53 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-sni-encryption-09.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: Mon, 28 Oct 2019 21:50:53 -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 : Issues and Requirements for SNI Encryption in TLS Authors : Christian Huitema Eric Rescorla Filename : draft-ietf-tls-sni-encryption-09.txt Pages : 14 Date : 2019-10-28 Abstract: This draft 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. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-09 https://datatracker.ietf.org/doc/html/draft-ietf-tls-sni-encryption-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-sni-encryption-09 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 Mon Oct 28 16:12:06 2019 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 0F8C61200B2; Mon, 28 Oct 2019 16:11:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-tls-sni-encryption@ietf.org, The IESG , tls-chairs@ietf.org, Sean Turner , Joseph Salowey , kaduk@mit.edu, joe@salowey.net, rfc-editor@rfc-editor.org, tls@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <157230431305.16093.16984415443669763203.idtracker@ietfa.amsl.com> Date: Mon, 28 Oct 2019 16:11:53 -0700 Archived-At: Subject: [TLS] Document Action: 'Issues and Requirements for SNI Encryption in TLS' to Informational RFC (draft-ietf-tls-sni-encryption-09.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: Mon, 28 Oct 2019 23:11:53 -0000 The IESG has approved the following document: - 'Issues and Requirements for SNI Encryption in TLS' (draft-ietf-tls-sni-encryption-09.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ Technical Summary This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. Working Group Summary Some working group members are not in favor of encrypting the SNI. However, the working group has consensus for continued work on the general topic of SNI encryption. Document Quality This document describes the problem and does not define a protocol. The document has been reviewed by the TLS working group. Personnel Document Shepherd: Joseph Salowey Responsible AD: Ben Kaduk From nobody Thu Oct 31 15:04:02 2019 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD91F12086F for ; Thu, 31 Oct 2019 15:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 7ScqU7AcE8sI for ; Thu, 31 Oct 2019 15:03:58 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0: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 611CB120825 for ; Thu, 31 Oct 2019 15:03:58 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id m16so6814229iln.13 for ; Thu, 31 Oct 2019 15:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=eYprrGT0FZjN1Gq3wOmwJ+OjPTFYFAjFFVcm5le9Q7g=; b=ZyEvaIhdBFLBKgHKFtkR6Aj1eMEUb32D3dvm+BsWH71IR771AAsa7uNNQ1YAPxnpoF 7eiyxhZCLKpBdnAv2QhobDqVtN7wPbu3p4p6P8/keQCaZamwAHwAl1105VBJ5y/As34+ ixUMA4v4i8XhP+llL1xfRxOs6rGiJzXgpQcyesSyAINI38c0mSgPBjpxMiHpLcumQCUi s3C/BVtIWI6BVvFnrTu+vorv/0nJwIL3U3fClxWqPJQcRrcAJyXlTf+JD7Z3TAmL1FUp hWqfrZAWmi1B5q5BqNdxcZBOWERlTQGd0LHOcM8jhr4A/kJrJWLClbAXyRd/6VzJetcN PnmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=eYprrGT0FZjN1Gq3wOmwJ+OjPTFYFAjFFVcm5le9Q7g=; b=YHkNLmL9klMqOxgkkBfnZbbPDluxEogx3X83D+dWlQkBwwvBOGOEIE6K/6mrFDRSDA Ba6jFLiSQeHRZfe0Z8exLt2bGYm5UBUbSijed2LjRemotMycNaemMAvCAuibr7igNeLW vRo2AQD/ds9nxJ0q4Y4Lox4HW3q0GKqzZyGGfPZU7yMRy9zWa1hDRkQQ+aBGGSo3p1aD BwsTIHO9TUvDxdkzaRaWZcbxPbhbV2EjXK0Gmd9IAxvq8A9omsL1tRxbqg3pKzJ508Bg lbJUE7WrAUaLcagca6jnqFktAU4WR2uo2NqCJJE/39daobukIYINb/emVIx1iRDGsUDY B32A== X-Gm-Message-State: APjAAAX4r9KEMQjHyKYPc1C2cM5zoV7sEcI2P9QjRjdzFdyFIwRBnEak Lgg/bKHvjr7I+oHqsfWhbpb6ojZ8FCuA5M2yCcJdxN1U X-Google-Smtp-Source: APXvYqyvgZ4YBUQOKa4ED6HBrYu1h3TYMBTe8FSbVI8n0a6fKRK4Ig1FDbJwGT62bRyUC2DOCePB0XM0aM534j+HSzA= X-Received: by 2002:a92:9adb:: with SMTP id c88mr8713452ill.193.1572559437049; Thu, 31 Oct 2019 15:03:57 -0700 (PDT) MIME-Version: 1.0 References: <157255857403.30497.13130592146602300409.idtracker@ietfa.amsl.com> In-Reply-To: <157255857403.30497.13130592146602300409.idtracker@ietfa.amsl.com> From: Ben Schwartz Date: Thu, 31 Oct 2019 18:03:45 -0400 Message-ID: To: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ac1e9105963c063b" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-schwartz-tls-lb-02.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: Thu, 31 Oct 2019 22:04:01 -0000 --000000000000ac1e9105963c063b Content-Type: multipart/alternative; boundary="000000000000a2a36105963c0684" --000000000000a2a36105963c0684 Content-Type: text/plain; charset="UTF-8" Hi TLS, This is an updated version of the TLS-LB draft that I presented in Montreal. The draft is intended for load balancers (or "SNI reverse proxies") that sit between the client and the actual server, directing traffic without decrypting TLS. This is relevant to split mode ESNI. Some major changes since the previous version: * No more mention of QUIC. This draft is now TLS-only. (We can come back to QUIC in the future, perhaps in a separate draft.) * Communication is bidirectional, so that overloaded backend servers can tell the load balancer to shift traffic away. * Added a certificate padding procedure * Added a replay defense Please review. There were several requests in Montreal for a proper security analysis of the authentication procedure in this draft, so I would especially appreciate reviews or referrals on that front. Thanks, Ben Schwartz ---------- Forwarded message --------- From: Date: Thu, Oct 31, 2019 at 5:49 PM Subject: New Version Notification for draft-schwartz-tls-lb-02.txt To: Benjamin M. Schwartz A new version of I-D, draft-schwartz-tls-lb-02.txt has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository. Name: draft-schwartz-tls-lb Revision: 02 Title: TLS Metadata for Load Balancers Document date: 2019-10-31 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-schwartz-tls-lb-02.txt Status: https://datatracker.ietf.org/doc/draft-schwartz-tls-lb/ Htmlized: https://tools.ietf.org/html/draft-schwartz-tls-lb-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-schwartz-tls-lb Diff: https://www.ietf.org/rfcdiff?url2=draft-schwartz-tls-lb-02 Abstract: A load balancer that does not terminate TLS may wish to provide some information to the backend server, in addition to forwarding TLS data. This draft proposes a protocol between load balancers and backends that enables secure, efficient delivery of TLS with additional information. The need for such a protocol has recently become apparent in the context of split mode ESNI. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000a2a36105963c0684 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi TLS,

This is an updated version of t= he TLS-LB draft that I presented in Montreal.=C2=A0 The draft is intended f= or load balancers (or "SNI reverse proxies") that sit between the= client and the actual server, directing traffic without decrypting TLS.=C2= =A0 This is relevant to split mode ESNI.

Some majo= r changes since the previous version:
=C2=A0* No more mention of = QUIC.=C2=A0 This draft is now TLS-only.=C2=A0 (We can come back to QUIC in = the future, perhaps in a separate draft.)
=C2=A0* Communication i= s bidirectional, so that overloaded backend servers can tell the load balan= cer to shift traffic away.
=C2=A0* Added a certificate padding pr= ocedure
=C2=A0* Added a replay defense

Please review.

There were several requests in Montreal for a proper s= ecurity analysis of the authentication procedure in this draft, so I would = especially appreciate reviews or referrals on that front.

Thanks,
Ben Schwartz

---------- Forwarded message ---------<= br>From: <internet-drafts@ietf.org>
Date: Thu, Oct 31, 2019 at 5:49= PM
Subject: New Version Notification for draft-schwartz-tls-lb-02.txtTo: Benjamin M. Schwartz <bemasc@= google.com>



A new version of I-D, draft-schwartz-tls-lb-02.txt
has been successfully submitted by Benjamin M. Schwartz and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-tls-lb
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS Metadata for Load Balancers Document date:=C2=A0 2019-10-31
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-schwartz-tls-lb-02.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-schwartz-tls-lb/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-schwartz-tls-lb-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-schwartz-tls-lb
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-schwartz-tls-lb-02

Abstract:
=C2=A0 =C2=A0A load balancer that does not terminate TLS may wish to provid= e some
=C2=A0 =C2=A0information to the backend server, in addition to forwarding T= LS
=C2=A0 =C2=A0data.=C2=A0 This draft proposes a protocol between load balanc= ers and
=C2=A0 =C2=A0backends that enables secure, efficient delivery of TLS with =C2=A0 =C2=A0additional information.=C2=A0 The need for such a protocol has= recently
=C2=A0 =C2=A0become apparent in the context of split mode ESNI.




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

The IETF Secretariat

--000000000000a2a36105963c0684-- --000000000000ac1e9105963c063b Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDdIR7RnK6eIao4ICVG/HzN VH4uizRM/t/KIdmK5x03kDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTEwMzEyMjAzNTdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAmh3EWfDkgCGv/gNoJRFKrB7kJIr44Rd+vmTuZKLm hWdgN6z/X+WcTBRRbEcedpeezUFYNxSL1OdAXzn/VPVuoAIfJzp52qEn3nwh9nR9h1EE506q0SOE UVI6AysAZoKYMUzKuH880poWM/dgzxD3XYVZgwLdgdtimfyVorJMPB/8r4khqjuzHZDPsu6H875n /EN8RVp8mCR7QjeQc9zvTPM4F9e4tcp3K1N7tarGhPngeSM0LoLyZAnQOxf1L4mPoD4VhaR005Hr PKsqmXxn3PBkPz1wFZoM8Fx4UwbIJFy4hQV1X8od2wgw8p+cNJZjq8roAPnuBWzkoKE3ihLYpA== --000000000000ac1e9105963c063b--