From nobody Mon Dec 3 08:24:11 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2A9130ECF; Mon, 3 Dec 2018 08:24:05 -0800 (PST) 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, 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=isoc.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 oFmp38ImqeFT; Mon, 3 Dec 2018 08:24:02 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700077.outbound.protection.outlook.com [40.107.70.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11463130ECD; Mon, 3 Dec 2018 08:24:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iRhCHd6doLtvO/RAIb7PA5ZfsJGdvU/UtQnXpFaOoVo=; b=gU3A1sQHo26hlpqs9+BTvBWt6nsEFriBGppevd+nRnabClTFPvtROaaqjr4LxZgS0rl7Ded81XHB1tBxHPRvdqjGpjkQz3FpeOfekjhDAP7xzXUIFJ1wWS8t/m7dt8S+gqKrgy4pDPWPHRqnLXENvGVByn9p7VykZXDmJ8cTRc8= Received: from BL0PR06MB4803.namprd06.prod.outlook.com (10.167.182.157) by BL0PR06MB4756.namprd06.prod.outlook.com (52.132.15.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.22; Mon, 3 Dec 2018 16:23:59 +0000 Received: from BL0PR06MB4803.namprd06.prod.outlook.com ([fe80::256b:48e5:9fc0:a034]) by BL0PR06MB4803.namprd06.prod.outlook.com ([fe80::256b:48e5:9fc0:a034%3]) with mapi id 15.20.1382.020; Mon, 3 Dec 2018 16:23:59 +0000 From: Karen O'Donoghue To: "saag@ietf.org" CC: "ntp@ietf.org" Thread-Topic: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp Thread-Index: AQHUdhHBUXB3JXWl20iLjQfu3fh0dA== Date: Mon, 3 Dec 2018 16:23:59 +0000 Message-ID: References: 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=odonoghue@isoc.org; x-originating-ip: [24.153.48.220] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BL0PR06MB4756; 6:2svtTFyGSYG5/1INl6T8/C8JmlQ4CPzR7c7lEuQGYWEPS57AcOPUT3On6Y6Snpo9NXmlwqCrYvARQbm10zXdJ1++9OFO9953QBgCll9QSqzlXEPJVRdiSjQdlogKaUtxBWFR6QoYfoh4kAkLP/kf8Ng6K965iz3epymvPyPkRa9QcJj24hBru4lTVU1DakHVyoNEl0QEaqLinL37etgboMYN5ixG1Uza6q8YZVswwNX+UykK58GgPKaERtR603W72xogEjZ/u+zRWgdGTvM3g5GrkjNzdG05mQe/m+lvoqduF+S5qqcxF5X4v0ZlK9d8l+vTc7MGbU0FTtaWMMeomfUNXNeh6JShR6pfLSb/9d/lklYFldeCy6EYVFD5fKoMd+KsoB16P68aKvHRr6HVQMwL40oJmHOYiQPkJXazH8f2+SJfbd6YO1BspBpkOWRVebnukLAqDmbNDOgoScIwKg==; 5:hs/bsUQKGyKTSKvuxXs0uLw+oBvTHe4+mCGXwT9I9OlXn6HCrbLMUeMh3ifjLsB2tgDkpehfQaCfnTPVpxunWb0EeXIdxm46IwTHk4z4+gzlzzdoNhLFRIaoTka9D4PuTFjdsvo5AtuwSZBsOl95L5OQDWIL5UsyzYYihRwn/fg=; 7:a6lwe7NmatrnexCVQKEqmLYxccioKA+9X514Cb5L8FHNaA5eSYLO2w4738HCAm1+vZdt6YTfBPmCy68pNS8Gd/snKw+ph9cpa31jKeElmolBj0D+lGwwzWfpnOndU3/Svwhx87j1CtgTNLgnJBJ+ow== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7953690f-ba68-4fa2-0b91-08d6593bbb26 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BL0PR06MB4756; x-ms-traffictypediagnostic: BL0PR06MB4756: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231455)(999002)(944501493)(52105112)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:BL0PR06MB4756; BCL:0; PCL:0; RULEID:; SRVR:BL0PR06MB4756; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(396003)(376002)(136003)(346002)(189003)(199004)(5640700003)(6486002)(229853002)(76176011)(99286004)(6436002)(5660300001)(81166006)(7736002)(1730700003)(81156014)(102836004)(26005)(86362001)(8676002)(6506007)(14454004)(966005)(478600001)(2473003)(36756003)(105586002)(97736004)(316002)(6116002)(3846002)(66066001)(6916009)(606006)(4326008)(2351001)(25786009)(2501003)(106356001)(450100002)(6512007)(53936002)(236005)(71190400001)(71200400001)(83716004)(2616005)(476003)(486006)(256004)(14444005)(68736007)(6306002)(8936002)(54896002)(33656002)(446003)(2906002)(82746002)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR06MB4756; H:BL0PR06MB4803.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-microsoft-antispam-message-info: eWlVlLnGqUYPWjDUWg9Apd8ZdbH1+WVDLpxoYNTSreSCwb0qXdxFrmwIFPAs3LpHc+B9brX4KQc9Ezuif5KekiiN3N4PeNViYT50+WYQVKNeEqWUV6b6JgAYcgDS+JFSClgtF5eMyZexsJ5hndRJCPYg8KlebBw4yb4DGFPY4Lq06e5HqToRkjcLbEOIjmvFs+awW2pnBFljzzxIQTODDGnHeBA9Sd1BZ6KRReUyFQjv3QOLYZjWXtJqeSey/EfkusohepELarFUBbR0h3F7ukVen18uE3vuk/0HZDa0IB2q5/WIzsRYu08DXMWtwLGbi8DR6tN6GWOBzotZGKkY4QkqgxKO/FLKdXUZZiqGaz0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C73D7E8DBD4A47F3B5B666F08EFE7842isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 7953690f-ba68-4fa2-0b91-08d6593bbb26 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2018 16:23:59.4737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR06MB4756 Archived-At: Subject: [saag] Fwd: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 16:24:05 -0000 --_000_C73D7E8DBD4A47F3B5B666F08EFE7842isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCldl4oCZdmUgZXh0ZW5kZWQgdGhpcyBXR0xDIHRvIHRoaXMgRnJpZGF5LCA3IERl Y2VtYmVyIDIwMTguIFdl4oCZZCBzdGlsbCBsb3ZlIHNvbWUgYnJvYWRlciBzZWN1cml0eSByZXZp ZXcgaWYgcG9zc2libGUuIE5vdGUgdGhpcyBwcm90b2NvbCB1c2VzIFRMUyBzbyBmb2xrcyBtaWdo dCB0byBlbnN1cmUgd2UgaGF2ZW7igJl0IGNhdXNlZCBhbnkgcHJvYmxlbXMgdGhlcmUuDQoNCkth cmVuDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBLYXJlbiBPJ0Rvbm9naHVl IDxvZG9ub2dodWVAaXNvYy5vcmc8bWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZz4+DQpTdWJqZWN0 OiBbTnRwXSBXR0xDOiBkcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9yLW50cA0KRGF0ZTogTm92 ZW1iZXIgNiwgMjAxOCBhdCAzOjQ2OjEyIFBNIEVTVA0KVG86ICJudHBAaWV0Zi5vcmc8bWFpbHRv Om50cEBpZXRmLm9yZz4iIDxudHBAaWV0Zi5vcmc8bWFpbHRvOm50cEBpZXRmLm9yZz4+DQoNCkZv bGtzLA0KDQpUaGlzIG1lc3NhZ2UgaW5pdGlhdGVzIGEgdGhyZWUgcGx1cyB3ZWVrIHdvcmtpbmcg Z3JvdXAgbGFzdCBjYWxsIGZvcjoNCg0KTmV0d29yayBUaW1lIFNlY3VyaXR5IGZvciB0aGUgTmV0 d29yayBUaW1lIFByb3RvY29sDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLW50cC11c2luZy1udHMtZm9yLW50cC8NCg0KUGxlYXNlIHJldmlldyB0aGUgcmVmZXJl bmNlZCBkb2N1bWVudCBhbmQgc2VuZCBhbnkgY29tbWVudHMgdG8gdGhlIG1haWxpbmcgbGlzdCBp bmNsdWRpbmcgeW91ciBhc3Nlc3NtZW50IG9mIHdoZXRoZXIgdGhpcyBkb2N1bWVudCBpcyBtYXR1 cmUgZW5vdWdoIHRvIHByb2NlZWQgdG8gdGhlIElFU0cuIFBsZWFzZSBub3RlIHRoYXQgdGhlc2Ug bWVzc2FnZXMgb2Ygc3VwcG9ydCBmb3IgcHJvZ3Jlc3Npb24gdG8gdGhlIG1haWxpbmcgbGlzdCB3 aWxsIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIFdHIGNvbnNlbnN1cyB0byBwcm9jZWVkLg0KDQpQbGVh c2Ugc2VuZCBhbGwgY29tbWVudHMgaW4gYnkgQ09CIG9uIEZyaWRheSAzMCBOb3ZlbWJlci4gV2Ug cmVhbGl6ZSB0aGlzIGlzIGEgYml0IGxvbmdlciB0aGFuIG5vcm1hbCBidXQgd2UgYXJlIGNvbWlu ZyBvdXQgb2YgYW4gSUVURiB3ZWVrIGFuZCBoZWFkaW5nIGludG8gdGhlIFRoYW5rc2dpdmluZyBo b2xpZGF5IGluIHRoZSBVUy4NCg0KVGhhbmtzIQ0KS2FyZW4gYW5kIERpZXRlcg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm50cCBtYWlsaW5nIGxpc3QN Cm50cEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udHAN Cg0K --_000_C73D7E8DBD4A47F3B5B666F08EFE7842isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkZvbGtzLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2XigJl2ZSBleHRlbmRlZCB0aGlzIFdHTEMg dG8gdGhpcyBGcmlkYXksIDcgRGVjZW1iZXIgMjAxOC4gV2XigJlkIHN0aWxsIGxvdmUgc29tZSBi cm9hZGVyIHNlY3VyaXR5IHJldmlldyBpZiBwb3NzaWJsZS4gTm90ZSB0aGlzIHByb3RvY29sIHVz ZXMgVExTIHNvIGZvbGtzIG1pZ2h0IHRvIGVuc3VyZSB3ZSBoYXZlbuKAmXQgY2F1c2VkIGFueSBw cm9ibGVtcyB0aGVyZS4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkthcmVuPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+QmVn aW4gZm9yd2FyZGVkIG1lc3NhZ2U6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdl LW5ld2xpbmUiPg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVl LCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiIGNsYXNz PSIiPjxiIGNsYXNzPSIiPkZyb206DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPkthcmVuIE8nRG9ub2dodWUgJmx0OzxhIGhyZWY9Im1haWx0bzpvZG9u b2dodWVAaXNvYy5vcmciIGNsYXNzPSIiPm9kb25vZ2h1ZUBpc29jLm9yZzwvYT4mZ3Q7PGJyIGNs YXNzPSIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJn aW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhl bHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwg MS4wKTsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPlN1YmplY3Q6DQo8L2I+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zeXN0ZW0tZm9udCwgSGVsdmV0aWNhIE5ldWUsIEhl bHZldGljYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxiIGNsYXNzPSIiPltOdHBdIFdHTEM6IGRy YWZ0LWlldGYtbnRwLXVzaW5nLW50cy1mb3ItbnRwPC9iPjxiciBjbGFzcz0iIj4NCjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJpZ2h0OiAwcHg7IG1h cmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN5c3RlbS1mb250LCBIZWx2ZXRpY2EgTmV1ZSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBjb2xvcjpyZ2JhKDAsIDAsIDAsIDEuMCk7IiBjbGFzcz0iIj48 YiBjbGFzcz0iIj5EYXRlOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13 ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj5Ob3ZlbWJlciA2LCAyMDE4IGF0IDM6NDY6MTIgUE0gRVNUPGJyIGNsYXNzPSIi Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmln aHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGlj YSBOZXVlLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsi IGNsYXNzPSIiPjxiIGNsYXNzPSIiPlRvOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IC13ZWJraXQtc3lzdGVtLWZvbnQsIEhlbHZldGljYSBOZXVlLCBIZWx2ZXRpY2EsIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bnRwQGlldGYub3JnIiBj bGFzcz0iIj5udHBAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bnRwQGll dGYub3JnIiBjbGFzcz0iIj5udHBAaWV0Zi5vcmc8L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjwvc3Bh bj48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkZv bGtzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoaXMgbWVzc2FnZSBpbml0aWF0ZXMg YSB0aHJlZSBwbHVzIHdlZWsgd29ya2luZyBncm91cCBsYXN0IGNhbGwgZm9yOiA8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpOZXR3b3JrIFRpbWUgU2VjdXJpdHkgZm9yIHRoZSBOZXR3b3Jr IFRpbWUgUHJvdG9jb2w8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW50cC11c2luZy1udHMtZm9yLW50cC8iIGNsYXNzPSIi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbnRwLXVzaW5nLW50 cy1mb3ItbnRwLzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2UgcmV2aWV3 IHRoZSByZWZlcmVuY2VkIGRvY3VtZW50IGFuZCBzZW5kIGFueSBjb21tZW50cyB0byB0aGUgbWFp bGluZyBsaXN0IGluY2x1ZGluZyB5b3VyIGFzc2Vzc21lbnQgb2Ygd2hldGhlciB0aGlzIGRvY3Vt ZW50IGlzIG1hdHVyZSBlbm91Z2ggdG8gcHJvY2VlZCB0byB0aGUgSUVTRy4gUGxlYXNlIG5vdGUg dGhhdCB0aGVzZSBtZXNzYWdlcyBvZiBzdXBwb3J0IGZvciBwcm9ncmVzc2lvbiB0byB0aGUgbWFp bGluZyBsaXN0IHdpbGwgYmUNCiB1c2VkIHRvIGRldGVybWluZSBXRyBjb25zZW5zdXMgdG8gcHJv Y2VlZC4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIHNlbmQgYWxsIGNvbW1l bnRzIGluIGJ5IENPQiBvbiBGcmlkYXkgMzAgTm92ZW1iZXIuIFdlIHJlYWxpemUgdGhpcyBpcyBh IGJpdCBsb25nZXIgdGhhbiBub3JtYWwgYnV0IHdlIGFyZSBjb21pbmcgb3V0IG9mIGFuIElFVEYg d2VlayBhbmQgaGVhZGluZyBpbnRvIHRoZSBUaGFua3NnaXZpbmcgaG9saWRheSBpbiB0aGUgVVMu DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MhPGJyIGNsYXNzPSIiPg0KS2Fy ZW4gYW5kIERpZXRlcjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KbnRwIG1haWxpbmcgbGlzdDxiciBjbGFz cz0iIj4NCm50cEBpZXRmLm9yZzxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnRwPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C73D7E8DBD4A47F3B5B666F08EFE7842isocorg_-- From nobody Wed Dec 5 06:26:47 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD44128C65 for ; Wed, 5 Dec 2018 06:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 2QE9ShExdrYM for ; Wed, 5 Dec 2018 06:26:40 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (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 E8C2E126C01 for ; Wed, 5 Dec 2018 06:26:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 346BF602A2 for ; Wed, 5 Dec 2018 09:26:37 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M0SUyGAproqv for ; Wed, 5 Dec 2018 09:26:17 -0500 (EST) Received: from lx121e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id BE02E6029A for ; Wed, 5 Dec 2018 09:26:17 -0500 (EST) To: saag@ietf.org From: Robert Moskowitz Message-ID: <22a02bce-0c19-64d6-9b19-41f93f24883f@htt-consult.com> Date: Wed, 5 Dec 2018 09:25:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [saag] The U.S. National Academies Reports on the Prospects for Quantum Computing X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 14:26:45 -0000 reported about here: https://spectrum.ieee.org/tech-talk/computing/hardware/the-us-national-academies-reports-on-the-prospects-for-quantum-computing My read is don't hurry, make considered thought about what to do when and  if QC  is an issue. BTW, thank you all for the Get Well card, particularly Rich for getting it. I have started out-patient PT for my walking, I can get around the house now without a cane, for the most part, but still use it outdoors. Perhaps a couple more weeks to be walking reasonably well but perhaps a month to back to my power walking. 2 more weeks in a sling for the dislocated shoulder and only passive OT.  Hopefully my Ortho Surgeon will clear me then for PT, so no driving for a while (nor bicycling!) and we will see what he says about flying... take care all. Bob From nobody Tue Dec 11 07:26:08 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F041288EB for ; Tue, 11 Dec 2018 07:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUdy9lZ-Ok7r for ; Tue, 11 Dec 2018 07:26:03 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-cwlgbr01on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe14::70c]) (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 2B6EF127333 for ; Tue, 11 Dec 2018 07:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QPTtz6TZkideSnFtPY311DJA1ih0PT1sbQmHb4UkVoc=; b=n3qQAOaU9K/CMpqVGPcuxcNaKRx1h5FFMSPchTDQTEhWv0H2t23qYgXVCjOTXUmA8xJR6dIjJbLMx7x1lNMQE2FHdRhWhLIBVmGx9OEwY4xuomMJ/jquulFoC99JtHTYgQ42OvmZExy1ZDRNBDcbClCas9EVgU9sBEHofCbv2z4= Received: from MMXP123MB0847.GBRP123.PROD.OUTLOOK.COM (10.166.238.153) by MMXP123MB1359.GBRP123.PROD.OUTLOOK.COM (10.166.242.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.19; Tue, 11 Dec 2018 15:25:56 +0000 Received: from MMXP123MB0847.GBRP123.PROD.OUTLOOK.COM ([fe80::c022:568a:ecf5:a188]) by MMXP123MB0847.GBRP123.PROD.OUTLOOK.COM ([fe80::c022:568a:ecf5:a188%5]) with mapi id 15.20.1404.026; Tue, 11 Dec 2018 15:25:56 +0000 From: Kirsty P To: "saag@ietf.org" Thread-Topic: CARIS2 - 5 days until the submission deadline Thread-Index: AQHUkWV5Xq6+e5XjNkCU2Pm3WIj27A== Date: Tue, 11 Dec 2018 15:25:56 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Kirsty.p@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MMXP123MB1359; 6:pVyoAGdMuB54SECGbggkjEGfyapntwvpHvFJLLlAxv5zOVDQrEixeAT5jTwatEcU9ov0tE7mxjsIgf5BjwRJsoIeujRMv50JYd1G/C1TnozgPXIuwEUvCUCg33M0CnIVisV0KmvfYvXgIWzHesf8akm2+xxi0VqBetaC0iN+hmDjyYP8okgnnEJzATAWQ37SNJZZXE6TckAlcnaK0xeveKeSDqhRb5OKcfXcx8JihoiGYkidSzTiwGurYwFGR193PSzlWa28AysvJpgHb45gG7MeY2pdO1ZhwRWuLM4aLVBbOlc+JrRTaO9Wcr4nHjt6irZjpRa0ZG52IVIsBi/TKLj5jweBe2Yj0FOmTeOEw5ax9jCxEWH68+Shyyg5SpyCnY0TelVAreOMqrT2nQUnLZuNBcJVRCqeG6UhXodox05QsLsMHigJqktJTWD1TqRMqY+Vd6x/fctyGdWGX/WyIQ==; 5:vX6E5RHb5kJHtcZG5F0rAGGOQg4ha7rtqd0cZVUk/uTQajqS/eIJxpR/qsb/IAL6OlWLeP1MnuEXzxrSLoGC5Yy0w8cUCqwDVa4BpeieUxMiLWFbSseGNGwJ17VCVNgfEZMNXJNRJrg6x700etmgeIH2wfYNvNtzolpIkIeS1x8=; 7:GMlG/3mMpNoAKEH+EgAZ4+AQ21g54hZAuhgIGv4cSpbzu62SWQCQ5leOL4QBfdU0zCdlbhG04CAjfSZNlVPAFY0a1e9o77LWTojylhF49VRCw46GJ7nY1m91u1jMtGO0ymnbdQgwXTlxJqzK2wdZhQ== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 483311df-0c0e-4938-d18e-08d65f7cf220 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MMXP123MB1359; x-ms-traffictypediagnostic: MMXP123MB1359: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230017)(999002)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231472)(944501520)(52105112)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:MMXP123MB1359; BCL:0; PCL:0; RULEID:; SRVR:MMXP123MB1359; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(366004)(39850400004)(136003)(199004)(189003)(97736004)(478600001)(256004)(1730700003)(75922002)(81166006)(72206003)(33656002)(2351001)(14454004)(105586002)(8936002)(102836004)(19627405001)(106356001)(6606003)(71200400001)(6306002)(6916009)(6436002)(53936002)(55016002)(606006)(8676002)(236005)(68736007)(25786009)(81156014)(74482002)(66574011)(2906002)(99286004)(316002)(71190400001)(9686003)(26005)(54896002)(66066001)(476003)(186003)(486006)(5640700003)(3846002)(74316002)(6506007)(55236004)(7736002)(86362001)(14444005)(6116002)(2501003)(5660300001)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MMXP123MB1359; H:MMXP123MB0847.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ix1pmWBLL92+bQbNJLxp6OkYv7EescRlc2zWT6HJRTp7TRzHWdUv9Pumm4/bvcuVNw6bfNHbEHMy8Qk1l+1y2Zo5ETLi0klSHK9pQE58J7FKx/c1WRGm2X8pgsOkk5JaASVdCPd+1ho7ulID/Kan9whzRvuZrg5L1Z9eRNxZHbBCBRsSDd6MghTiGzaPFxCHgiQO/pLubK7o1niVKfm3xUSJnpWZwnvQJD1YcI3ZUOvrmnevIEmycup/4pkOkm2M+ohioekYkkbyoZvO81YsEcZKwggaRp8WzFwRcwPxUdIJIoWKumCRdrbhk39LgDZs spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MMXP123MB08475278E8DFB860FC5AB69CD7A60MMXP123MB0847GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 483311df-0c0e-4938-d18e-08d65f7cf220 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2018 15:25:56.0983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MMXP123MB1359 Archived-At: Subject: [saag] CARIS2 - 5 days until the submission deadline X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 15:26:06 -0000 --_000_MMXP123MB08475278E8DFB860FC5AB69CD7A60MMXP123MB0847GBRP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is a reminder that submissions to the CARIS2 workshop are closing on S= unday 16th December! And just in case you missed the previous post on this.= .. CARIS2 (Coordinating Attack Response at Internet Scale) is a 2-day workshop= about - well, exactly that - improving incident response to attacks on a l= arge scale... and as you're on the SAAG list, you (or someone you know) mig= ht be interested in participating/submitting a paper/attending. Full detail= s are on the website (https://www.internetsociety.org/events/caris2) but, i= n short, a wide range of expertise and experience in responding to attacks = would be invaluable at this workshop, so do consider contributing. Plus, th= e outcomes from CARIS2 will be used to feed into SMART (Stopping Malware an= d Researching Threats), a newly-proposed IRTF Research Group. If you have any questions, please ask on the list or directly - I'm happy t= o discuss it and negotiate around any blockers to your participation. Addit= ionally, if you have any contacts that might be interested; let them know..= . the deadline is approaching! This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_MMXP123MB08475278E8DFB860FC5AB69CD7A60MMXP123MB0847GBRP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

This is a reminder that submissions to = the CARIS2 workshop are closing on Sunday 16th December! And just in c= ase you missed the previous post on this...


CARIS2 (Coordinating Attack Response at= Internet Scale) is a 2-day workshop about - well, exactly that - = ;improving incident response to attacks on a large scale... and&n= bsp;as you're on the SAAG list, you (or someone you know) might be interested in participating/submitting a paper/attending. Full&nbs= p;details are on the website (https://www.internetsociety.org/events/cari= s2) but, in short, a wide range of expertise and experience in responding= to attacks would be invaluable at this workshop, so do cons= ider contributing. Plus, the = outcomes from CARIS2 will be used to feed into SMART (Stopping Malware and Researching Threats), a n= ewly-proposed IRTF Research Group.


If you have any questions, please ask on = the list or directly - I'm happy to discuss it and negotiate arou= nd any blockers to your participation. Additionally, if you = have any contacts that might be interested; let them know... the deadline is approaching!

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_MMXP123MB08475278E8DFB860FC5AB69CD7A60MMXP123MB0847GBRP_-- From nobody Tue Dec 18 11:37:36 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD399130F0F for ; Tue, 18 Dec 2018 11:37:34 -0800 (PST) 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, FREEMAIL_FROM=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 (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 veFg0_cn_L8U for ; Tue, 18 Dec 2018 11:37:32 -0800 (PST) Received: from mail-it1-x131.google.com (mail-it1-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 BD340130F06 for ; Tue, 18 Dec 2018 11:37:32 -0800 (PST) Received: by mail-it1-x131.google.com with SMTP id m8so9040613itk.0 for ; Tue, 18 Dec 2018 11:37:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:from:date:message-id:subject:to; bh=As9kSO368eqmNYNe9XKVzCRtk+PgF1vL+IwzWY/Iuzo=; b=t81jLcdVVaLqPHJjIoUDOZNwD53PA2JC6JucishpIw8xenT7kCA+WwV7Lv4zhCNCec zk7pPkz8FZ/YdeuSsGcja2uXig6rtXQykJ+c2oqIAmAeauqW/xNL2zESwEXRR8hgNzys 8hMTIKBNJBQ+dM4/PjtlTDJr9kCx5YHFkycPZ1b/7lj2fS44Nl7st9D1XRnHo59GatUu ut2/t6Sq8bhKVK62nqVAPqmE+PYE54d7bt6J81jX7mBxlwOGbMAzFW8YFGhY17I0vTL4 beJ4mfKxr4JJ7gRmcflSi+CSuKVG5W1NgycxGj9IF19ScdTKzuG8ZWNw2gfedrkAubs4 sksQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=As9kSO368eqmNYNe9XKVzCRtk+PgF1vL+IwzWY/Iuzo=; b=q1m/X34CVTDvfntuBzzSmfv7VeyNTLqfT/sNppmbmlkRAhCZ0cpmOywHbvUplTEqlD AIb73b2/XRold/U5vdU1oz76/YcBDugxIpEjRC+YV6QyT5MJxYVAVzYkypkwW1ePQJO3 5Mg9NCwKgT3YWJCh+uM1E1uB9uCehMuzl2btqMI7ggIRgvR9UoQiSpFXlXoVfBM/sXtP LvToeFUgFITG9WCA3sQkfzouymjG4OfrsrPMqER1ZJ8OFOPKkiZJ56sArx6w4ii3hPiE EOU4CMBS2bdsI4F9Mo3HndS/2k+m0fn0r2gRP6I987qxQwe2TzoaTI0Bc3NO/betG+Lw 6Qhw== X-Gm-Message-State: AA+aEWagNt+AoS3RBXXZzE1hAeq3nPS7OZCsW7fZjo8+zB9Rx8QgN8ct rori8Xe41iY27zgk1m3AeS0VhNUWWB/sh3Ww8/EGve++ X-Google-Smtp-Source: AFSGD/Vj+qWstgz5TjbboY6IO1mJeIVD0mVAoi6ydX12To8+h+xfpfDcs0loPSS9lpzu/qSCzzKXMrmWAaXg9aY/wNc= X-Received: by 2002:a02:ac8c:: with SMTP id x12mr15796233jan.72.1545161851845; Tue, 18 Dec 2018 11:37:31 -0800 (PST) MIME-Version: 1.0 Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 18 Dec 2018 14:37:18 -0500 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 19:37:35 -0000 Bernstein's papers detail the byte strings a little endian format. I.e., the LSB is at byte 0 instead of 31. Cf., https://cr.yp.to/ecdh/curve25519-20060209.pdf, Section 2, page 4. https://tools.ietf.org/html/rfc7748 also uses little endian format for the strings, but it does not provide details of encodings. https://tools.ietf.org/html/draft-ietf-curdle-pkix provides information on encodings but does not discuss endianess of the strings in the ASN.1 structure. I believe all other encodings I have seen use big endian formation for octet strings and bit strings. Would someone please confirm the strings are written in big endian format. I.e., an application that uses little endian format for calculations will have to "byte reverse" to/from ASN.1 encoding. Thanks in advance. From nobody Tue Dec 18 12:18:31 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77F4130F1D for ; Tue, 18 Dec 2018 12:18:29 -0800 (PST) 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_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 rtn6hnNaQ_wu for ; Tue, 18 Dec 2018 12:18:27 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77104130F62 for ; Tue, 18 Dec 2018 12:18:27 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 12:13:14 -0800 From: Jim Schaad To: , References: In-Reply-To: Date: Tue, 18 Dec 2018 12:18:13 -0800 Message-ID: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGrFkIRFAd5a6a1o+PTUBaWHtEUXaXX7/3w Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 20:18:30 -0000 >From the text: subjectPublicKey contains the byte stream of the public key It should probably be 'byte string' rather than 'byte stream', but it means that you take the bytes of the public key and put them there. There is no INTEGER ASN.1 type involved anywhere. Jiim > -----Original Message----- > From: saag On Behalf Of Jeffrey Walton > Sent: Tuesday, December 18, 2018 11:37 AM > To: saag@ietf.org > Subject: [saag] draft-ietf-curdle-pkix and endianess of strings > > Bernstein's papers detail the byte strings a little endian format. > I.e., the LSB is at byte 0 instead of 31. Cf., https://cr.yp.to/ecdh/curve25519- > 20060209.pdf, Section 2, page 4. > > https://tools.ietf.org/html/rfc7748 also uses little endian format for the strings, > but it does not provide details of encodings. > > https://tools.ietf.org/html/draft-ietf-curdle-pkix provides information on > encodings but does not discuss endianess of the strings in the ASN.1 structure. > > I believe all other encodings I have seen use big endian formation for octet > strings and bit strings. > > Would someone please confirm the strings are written in big endian format. > I.e., an application that uses little endian format for calculations will have to > "byte reverse" to/from ASN.1 encoding. > > Thanks in advance. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Dec 18 12:29:16 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246BF12D84D for ; Tue, 18 Dec 2018 12:29:15 -0800 (PST) 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, FREEMAIL_FROM=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 (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 q_7u5nIP2UAV for ; Tue, 18 Dec 2018 12:29:13 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-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 4DE96128D0C for ; Tue, 18 Dec 2018 12:29:13 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id w18so5894201ite.1 for ; Tue, 18 Dec 2018 12:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=B7Uxd9XLSGMN3Gr6TzbtW6kB7KJUarMS5ohGDjkRQDs=; b=l8Y7zMbKluHjBM0IZFyEiQ4UaWCoEaODnan+U0FdG0EqQgl0W9ZggSLqfC52744nzN WVAkIz+qtqIQrJDeUKs8OGwU5dTSPccrlAFeMNHaZlLJbISrWyrFdia54F6nJSLgPKi5 yBiy15fJ+7/Nb2TbFVkAj24Gbl1sRL/sj42KaFxjfDt2vJVyoOgm1D7ui7aklvfQgASV LFD2bABJU0n9YXZYwolyHAZlh5lE2lXT/rfN5ZUaBaHXGuEH9i5zCXZvmNVmpHbinWU9 zHBcPM5k53KIwEOCWk1xNDui02p7DvnTFnPQyBOfO0VH0GOMVttZAhQnXjFIQ4o02moz 6ZvA== 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:reply-to :from:date:message-id:subject:to:cc; bh=B7Uxd9XLSGMN3Gr6TzbtW6kB7KJUarMS5ohGDjkRQDs=; b=suWiltU5ZnYBQ5RNbEIGr1R7BvAeV2lp3ooMxQfm1GdUHGBYRO8D3ugTX0LgIyxQQp NwotErcNb7oPtcOVklcXDi9spTOB/5XmT50OTuXZileUwallxDVQY0vma79/bj5c2OM0 8CF+3UPzimv7vyeUfdKNrqMf0zOYI2BTyzMIOumrfbn+C5menRCP/81CyPVNYM3gfSGh BCbfvq9NaH7HdGEl2V9QpXZfs4XrLbJDaC234xW3GPtiYLUOttIo6FS5OouQY59n0QZ7 yJNpGXYhed1Eqge4ntoR7MPEl8dvdWT0vUIogNP3ZskTHWh0heqvkMEbrEpYuUS94r+h 8g3A== X-Gm-Message-State: AA+aEWao92izv2nVjs8NXuBrwLC5rhEn7ilqO9wKijUeF+q4RCKx7rjc IzBvcPsSgxZ3u7NqnzyRgl6MBlxDU2d7DfoRmtSAEw== X-Google-Smtp-Source: AFSGD/W+Xo3P3Vu7kZSOmKO053YvWVF6gX0wdpmAN8cvDEg7dpgl3iJykQTEIo1wj6adqjzw2nBQUfm7D29TLXHkfnY= X-Received: by 2002:a24:1d4a:: with SMTP id 71mr3906634itj.62.1545164952619; Tue, 18 Dec 2018 12:29:12 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> In-Reply-To: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 18 Dec 2018 15:28:59 -0500 Message-ID: To: Jim Schaad Cc: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 20:29:15 -0000 On Tue, Dec 18, 2018 at 3:18 PM Jim Schaad wrote: > > From the text: > > subjectPublicKey contains the byte stream of the public key > > It should probably be 'byte string' rather than 'byte stream', but it means > that you take the bytes of the public key and put them there. There is no > INTEGER ASN.1 type involved anywhere. Thanks. So this is a new ASN.1 type? a little endian octet string? Jeff From nobody Tue Dec 18 12:38:37 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCE0130E7F for ; Tue, 18 Dec 2018 12:38:36 -0800 (PST) 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, FREEMAIL_FROM=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 (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 1vCsihXXp_sY for ; Tue, 18 Dec 2018 12:38:34 -0800 (PST) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0: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 7E309128D0C for ; Tue, 18 Dec 2018 12:38:34 -0800 (PST) Received: by mail-it1-x136.google.com with SMTP id b5so6172508iti.2 for ; Tue, 18 Dec 2018 12:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=qXNUdqJCo0jj9pOso3YhVlzNaLah1l1p2yvupGn9H5Y=; b=rx7zvT0LRYl4EOH7c2Wz04BPerjEV02BeqLTuoYKKTNu8w+hIj/H41modo2LwDg+pq ueXKFEJji5J+tW5kQkf5awli0siM8OIPkYKsa8bQmoUktGLh7QsQoO7rymYbQQhmSGa/ gZe3oi+Yiel7Yl6m1oAlZT1BBsMNN1mdL5aDMeWxOPX/sjZhY9MIm2izhBMigcwNKqKU CKM0UHUr5HALdtmyJ/V+eiHJuxPCno9gA7BY35AHL9HcFyArvK1W6L9curTRdLaCvSOm dfbrJw/prYjpXrLoWCpvjgJlZ5MU29/8zqj6G4qxEgPyABlzFLl0Hj9+RKQY1G5TQXom 27UA== 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:reply-to :from:date:message-id:subject:to:cc; bh=qXNUdqJCo0jj9pOso3YhVlzNaLah1l1p2yvupGn9H5Y=; b=K/PCMmkJNtZY/vt2x74zgfNirRsIy1c1HTdg1EenbOTKV1jKL/vCsE6Iqomo7HH2WB 8VxgV99OfFnn0KnxQ0D695VqRWo0TkivUPVgv6u8qkVYO2WOdYsD9n2pHFy7HqM8ApqE +IGZv8f9kYECD+n5XumuXuoaGum3NvBcIKk7l6xvdRyvXzYjcFm0m4vyxVRuw6TgelGA 7oVso30uCwmd9kPU+DI0iz2FQcNvKlPFACP3dNs1756ntvZMSCWr1On7+whn8psQplgA fva9hpvjupTQytZEvnollrbDW+5r7DvSjmC4SzJDs3ZIJuVu7HuGwGIyW7rWtOr8MU8e G21g== X-Gm-Message-State: AA+aEWZ2t54+RugD859XDHYBgZTU1iKVGJdAW36qtYLheHGbvALGcBjF unV7Ncht0ihAY3jbwcBWFd7oEGnsqDQtn9Yqzuk= X-Google-Smtp-Source: AFSGD/WwiuCJj+4CgYBdKWeD48AmuSSVo/VJKO2jmLYVct317usIUH94zqLuo73v7CjBm5WrwelOoHZIL33D5CgcU40= X-Received: by 2002:a24:3282:: with SMTP id j124mr4197980ita.173.1545165513891; Tue, 18 Dec 2018 12:38:33 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 18 Dec 2018 15:38:20 -0500 Message-ID: To: Jim Schaad Cc: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 20:38:36 -0000 On Tue, Dec 18, 2018 at 3:28 PM Jeffrey Walton wrote: > > On Tue, Dec 18, 2018 at 3:18 PM Jim Schaad wrote: > > > > From the text: > > > > subjectPublicKey contains the byte stream of the public key > > > > It should probably be 'byte string' rather than 'byte stream', but it means > > that you take the bytes of the public key and put them there. There is no > > INTEGER ASN.1 type involved anywhere. > > Thanks. > > So this is a new ASN.1 type? a little endian octet string? Thanks again Jim. Let me rephrase this. Given a 32-byte private key x, we clamp byte 0 with x[0] &= 248. Where exactly does x[0] show up in the octet string? Is it the first octet or the last octet? My apologies for my confusion. Jeff From nobody Tue Dec 18 12:53:26 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E47130F0F for ; Tue, 18 Dec 2018 12:53:23 -0800 (PST) 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_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 dpGFmgg_Li6G for ; Tue, 18 Dec 2018 12:53:22 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0976E130E7F for ; Tue, 18 Dec 2018 12:53:21 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 12:47:48 -0800 From: Jim Schaad To: CC: References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> In-Reply-To: Date: Tue, 18 Dec 2018 12:52:47 -0800 Message-ID: <028e01d49713$a31a0030$e94e0090$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGrFkIRFAd5a6a1o+PTUBaWHtEUXQJV6zPDAneklFClsY4IQA== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 20:53:24 -0000 Octet string do not have an endian-ness. Integers do but octet strings = are just a sequence of bytes. Jim > -----Original Message----- > From: Jeffrey Walton > Sent: Tuesday, December 18, 2018 12:29 PM > To: Jim Schaad > Cc: saag@ietf.org > Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings >=20 > On Tue, Dec 18, 2018 at 3:18 PM Jim Schaad = wrote: > > > > From the text: > > > > subjectPublicKey contains the byte stream of the public key > > > > It should probably be 'byte string' rather than 'byte stream', but = it > > means that you take the bytes of the public key and put them there. > > There is no INTEGER ASN.1 type involved anywhere. >=20 > Thanks. >=20 > So this is a new ASN.1 type? a little endian octet string? >=20 > Jeff From nobody Tue Dec 18 12:55:35 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35539130F63 for ; Tue, 18 Dec 2018 12:55:32 -0800 (PST) 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_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 nf09RmyfVhzZ for ; Tue, 18 Dec 2018 12:55:30 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDE3130F3B for ; Tue, 18 Dec 2018 12:55:30 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 18 Dec 2018 12:50:19 -0800 From: Jim Schaad To: CC: References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> In-Reply-To: Date: Tue, 18 Dec 2018 12:55:18 -0800 Message-ID: <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGrFkIRFAd5a6a1o+PTUBaWHtEUXQJV6zPDAneklFABY4/USaWmcikg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 20:55:32 -0000 > -----Original Message----- > From: Jeffrey Walton > Sent: Tuesday, December 18, 2018 12:38 PM > To: Jim Schaad > Cc: saag@ietf.org > Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings >=20 > On Tue, Dec 18, 2018 at 3:28 PM Jeffrey Walton > wrote: > > > > On Tue, Dec 18, 2018 at 3:18 PM Jim Schaad > wrote: > > > > > > From the text: > > > > > > subjectPublicKey contains the byte stream of the public key > > > > > > It should probably be 'byte string' rather than 'byte stream', but > > > it means that you take the bytes of the public key and put them > > > there. There is no INTEGER ASN.1 type involved anywhere. > > > > Thanks. > > > > So this is a new ASN.1 type? a little endian octet string? >=20 > Thanks again Jim. >=20 > Let me rephrase this. Given a 32-byte private key x, we clamp byte 0 = with x[0] > &=3D 248. >=20 > Where exactly does x[0] show up in the octet string? Is it the first = octet or the > last octet? This is a 32-byte octet string (byte string). The value is encoded w/o = any changes byte strings do not have any endianness. x[0] is the first byte in the octet string. >=20 > My apologies for my confusion. >=20 > Jeff From nobody Tue Dec 18 13:33:04 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E01CA13116F for ; Tue, 18 Dec 2018 13:33:02 -0800 (PST) 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, FREEMAIL_FROM=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 (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 0XtlqOyLNqeT for ; Tue, 18 Dec 2018 13:33:01 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-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 ED0F1130FC2 for ; Tue, 18 Dec 2018 13:33:00 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id p197so6406380itp.0 for ; Tue, 18 Dec 2018 13:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=tz8voxXfnEFFSZcX8WH4AvH2vfYo2BCARpjedWyORfY=; b=jv9o1mb2axT1Q7YnnHRZjOAiCJZvyd69mQjih3GgKMpuJ0OEFnryMXwgX118xRsWwG cjF02x6YWvKNZgOc5lB9mXyIZFVCFQop1ruBb32cUwNp2qErRzQsY68h+DNE8y6E7lPd 1PtjieH47D2Q9nvk/G3t2xh41VurG+WtUfPJZeMvprfRxuCF+7TJQZOP5ukRQb3wWVIb 61ZzCDn0hoSEJYx42XlwAqoAn9gGncAftMUT/gY9nO20gjO74OEfAoV+Fhz+zou3CEAZ hF67/LdLlZ2g1bZ3wcm8bbj51sRJ3ieG736Je0XcU45CNRhJbp7nL9SmbagYVJbsn/kF cmSw== 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:reply-to :from:date:message-id:subject:to:cc; bh=tz8voxXfnEFFSZcX8WH4AvH2vfYo2BCARpjedWyORfY=; b=lae4PJhjWkBfAmAvxaBTw7umpH24NEJvwoBGpAgKEtZSBmHJyhTpPrBtqKz4D92d8W p9uhiDIQXhifdG6DIWmQWBQ1KTdK8hTR3AnAr/bq2BqYmEuHcG5nlUIZ3IprGytcuWN4 Us4kzhipuhQUcSIjldeNX9eev+WAgdYu5EPVXYlOQs5eljrPzxeZDlVu5RHfWFHBaYwc My+EcVylZQaGYapogTq+lDMbyfFWJYSEzvPpHNM/6IKlPp1GljdATeYS2KSHxirmMgAm 1KI7rb4DdGGgC3NraHHccixsj8zxvVp45EB1l624Dof23ETzUPjuwG/oV/CrWE1RYyJ6 0j/w== X-Gm-Message-State: AA+aEWY2RVr3tiXaB3pQVHat08rWQQignMYAd7jAHjDvl2GPRIh9231l OmFbGPMG1FmF/QkaOJyvAzmPVHhNY9MAVkpg+PQ= X-Google-Smtp-Source: AFSGD/UaNHgEqlEJRNt8/6gZr10D+qACu1VZnXUsJ826O6GpufuIWO+iby6SocU8iZFAZk2/s9GrXN7q3fBUuscHRe0= X-Received: by 2002:a24:c8d7:: with SMTP id w206mr4501478itf.56.1545168780298; Tue, 18 Dec 2018 13:33:00 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> In-Reply-To: <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Tue, 18 Dec 2018 16:32:46 -0500 Message-ID: To: Jim Schaad Cc: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 21:33:03 -0000 On Tue, Dec 18, 2018 at 3:55 PM Jim Schaad wrote: > ... > > > > Let me rephrase this. Given a 32-byte private key x, we clamp byte 0 with x[0] > > &= 248. > > > > Where exactly does x[0] show up in the octet string? Is it the first octet or the > > last octet? > > This is a 32-byte octet string (byte string). The value is encoded w/o any changes byte strings do not have any endianness. > > x[0] is the first byte in the octet string. Thanks for clearing that up. You might consider adding a note that the byte array is written to the octet string with the LSB in the first position, and the MSB in the last position. As far as I know this draft is the only one that reverses the byte ordering for presentation. It will avoid confusion for future readers who expect network byte ordering in ASN.1 presentations. Bernstein calls it little-endian when describing the algorithm. And to be clear, here is Bernstein's description of the sequence of bytes (section 2, page 4): The set of bytes is, by definition, {0,1, ..., 255}. The encoding of a byte as a sequence of bits is not relevant to this document. Write s |-> s-bar for the standard little-endian bijection {0,1, ..., 2^256-1} to the set {0,1, ..., 255}^32 of 32-byte strings: in other words, for each integer s in {0,1, ..., 2^256-1}, define s-bar = (s mod 256, floor(s/256) mod 256, ..., floor(s/256^31) mod 256). From nobody Tue Dec 18 18:54:48 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE21B130DC8 for ; Tue, 18 Dec 2018 18:54:47 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 Bf54I6m9bQly for ; Tue, 18 Dec 2018 18:54:45 -0800 (PST) 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 C6D3D1292F1 for ; Tue, 18 Dec 2018 18:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1545188085; x=1576724085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WJrvnzuD9N5nrpt0qaoUzkLDqJqD9ExusZ8KpBgOADw=; b=hTa2eFLPpXM6LWfhSLWNKJQqmqm16DoTVdZGYqv7mDXZHc6582Q1U2F6 XoMiVTg49iNzlpslcAU1SlikUEzkgXxXD0S6Yw0bYP8EXoDre2QRd91av UduX8fFg87u40P6J2B2xeGXL7+1Sms2cEIzrluf3yqqo+MdG59c9dYVQv K+SugznvnNy48+4InPTiF9FG1W3x34//PH7WNoj01zeyu2BFQ7qL4DUid cZ8qKgt2B5BgvK6CSswuyrLt0xtjHYefSFHyy38Gj2A3i0kc95exkS2lm X1pZO3eTtI3iTVzE0sALAzsNx28wpdTwPiv5S7oLeADjgLtKiKHtozFR+ A==; X-IronPort-AV: E=Sophos;i="5.56,370,1539601200"; d="scan'208";a="43759474" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Dec 2018 15:54:42 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 19 Dec 2018 15:54:41 +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, 19 Dec 2018 15:54:41 +1300 From: Peter Gutmann To: Jim Schaad , "noloader@gmail.com" CC: "saag@ietf.org" Thread-Topic: [saag] draft-ietf-curdle-pkix and endianess of strings Thread-Index: AQHUlwktejkwaOTqMEys7jzWK4AzKqWEFZqAgAADAoCAAAKdAIAABL0AgAAKeACAATPAlQ== Date: Wed, 19 Dec 2018 02:54:41 +0000 Message-ID: <1545188081299.7191@cs.auckland.ac.nz> References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com>, In-Reply-To: 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: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 02:54:48 -0000 Jeffrey Walton writes:=0A= =0A= >You might consider adding a note that the byte array is written to the =0A= >octet string with the LSB in the first position, and the MSB in the last = =0A= >position. As far as I know this draft is the only one that reverses the = =0A= >byte ordering for presentation. It will avoid confusion for future readers= =0A= >who expect network byte ordering in ASN.1 presentations.=0A= =0A= This was requested when the RFCs were written (alongside using the standard= =0A= X9.62 form that everything else uses), but nothing got done. Basically the= =0A= encoding used for the Bernstein curves is the reverse to the way everything= =0A= else does it. So you take the standard form used by all other curves, then= =0A= encode the values backwards. In my code I use a shim layer that reverses= =0A= the bytes, at which point they can be handled by code that expects them in= =0A= the standard form.=0A= =0A= Peter.=0A= From nobody Wed Dec 19 05:16:27 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF777130DFA for ; Wed, 19 Dec 2018 05:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWFKDeNbwrIo for ; Wed, 19 Dec 2018 05:16:21 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-lo2gbr01on0717.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe15::717]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3FC12D4ED for ; Wed, 19 Dec 2018 05:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ItajzUY1sAwVW4HGmnZYhbCmKFmkOdpc7EmEl33UQ9s=; b=lVjgnqMWBM2IQFFsfvAF5SwdMAlJuyDfriLxmzWAwtfeBjKn/giFSiouKfnX4F6elGmZ8dDXiBtcVVt28YD4rcEli+tsJqAGDpMxW6OlPvRDPUrRsMAZuhPaQ3gksqS2iWUldRFiTYnRtKbdFJGGeOohp8CFgsvWn9QvFM/7Q0Y= Received: from MMXP123MB1423.GBRP123.PROD.OUTLOOK.COM (10.166.242.147) by MMXP123MB0030.GBRP123.PROD.OUTLOOK.COM (10.166.237.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.19; Wed, 19 Dec 2018 13:16:12 +0000 Received: from MMXP123MB1423.GBRP123.PROD.OUTLOOK.COM ([fe80::5cfe:aae6:d800:c201]) by MMXP123MB1423.GBRP123.PROD.OUTLOOK.COM ([fe80::5cfe:aae6:d800:c201%2]) with mapi id 15.20.1425.024; Wed, 19 Dec 2018 13:16:12 +0000 From: Mark O To: "saag@ietf.org" Thread-Topic: Comments on draft-foudil-securitytxt-04 Thread-Index: AdSXmuqMkZbdVjQnQ92VKibJ8bVUvg== Date: Wed, 19 Dec 2018 13:16:12 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mark.O@ncsc.gov.uk; x-originating-ip: [51.140.114.144] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MMXP123MB0030; 6:6Q76mbrAcAxjHQe/ncuSYpLeWoXZqWEObamVB++/qHFZKQKkmdANr1/wC8EWoGrelCmOayLAhHeA4kUBZJLJuDG+lbPMVY2pIF3iNlSxXT/UBNeinIjfP3uQQ+gn0qLwsZPljbf9tEdzxNF+KcU2r4lVCzO/ybK54T9KYg7bglCmPSfPXUptUDxlMjAV+qmdfI8pN655r+Rgu6sD3y/RM8OEcsTJWGutGflqvgGAkgPqEiZtGAY4sktJLmw7QbWAkGahof3e6C+cOafZODyKcLvKFbn2la+4EjV8+BLS+SKEgT7aoSOyu41O64dTKx+O8K38GA+IZB4WqXb19JIn7uIdnBvW7k4VZ58mp3+VHg8AIET/DhMDlMzDlto3IV1mjY8iuvNV6A5A90ZgSfkCLwIRKN6E82quRhud0rZRwRd2L74jOkl3L2DLgYILX4R5YERExDgfe6ERxoOaPzO4+A==; 5:jfNTLAdv7EmjGfNergQZgSaT9KFuHNvhFc4hAKCFQMwyxJnDYOGXUAJVeusPnSVpzaalhMK/y+8hs+rUVJUKC2lOFXif5DQ/jbz/g7KslIAordzUTCh7RGZosKyGnsjSl4rV396MTQjZBi3C2fe35cjxi4MZ00wk7Yy1m2L8G1k=; 7:6AU4l4c7hk4fceRasYed0mJNMZGI/CRmQFiXPpiXC9Vjr1mxEpYT3xBHbA0KQSpyW9NZVm+YDwhUtkqjPkMAbb3Uzt6EuY8s2BrPUq7uoO1EdzOfRymv5zDcdI9fyIiJLzdQ/gIBLQdyIvcqudRnyA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 6fff3a95-ec90-41d0-ee29-08d665b425fb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:MMXP123MB0030; x-ms-traffictypediagnostic: MMXP123MB0030: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(4982022)(52105112)(93006095)(93001095)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:MMXP123MB0030; BCL:0; PCL:0; RULEID:; SRVR:MMXP123MB0030; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39850400004)(136003)(346002)(366004)(52314003)(199004)(189003)(256004)(8676002)(14444005)(2420400007)(72206003)(966005)(75922002)(1730700003)(81156014)(53546011)(97736004)(316002)(33656002)(25786009)(561944003)(66066001)(99286004)(14454004)(81166006)(6506007)(68736007)(236005)(10710500007)(7736002)(2351001)(55236004)(102836004)(53946003)(186003)(2906002)(74316002)(7696005)(53936002)(9686003)(2501003)(26005)(8936002)(7110500001)(74482002)(66574012)(3846002)(4744004)(55016002)(105586002)(476003)(6916009)(486006)(6116002)(15650500001)(71200400001)(86362001)(606006)(6436002)(54896002)(6306002)(5640700003)(71190400001)(790700001)(478600001)(5660300001)(106356001)(45080400002); DIR:OUT; SFP:1102; SCL:1; SRVR:MMXP123MB0030; H:MMXP123MB1423.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: asIQc1IfJij2iV7ieuKMV/sW8p5GwPOjjcdhWQCi4U5tJg1PQWPBV5M2QVitj9i6g6ZJVxwU+jAA2SE/y0NboM0jIsGzScdt1nYgF9hAfjALaII4Yep/dbsi7VTNfCjAmvVhsnkOOFkNAj3o1+sZXoupD8fAtFMUbnqysBWGp3MhKD6P8VKReFGg6Id4vtL4uwdi/BdishBCC9SNtddzK34XGHFLWziuGBB2f2SZYbgBA4JnS0fxPyNN5msn04yaP5iNMp9+f+lzgbjn+63vBjzCbCLIiKFYDlL1hzriaGTKP/tTJrOBA3Bu+C58MrIP spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MMXP123MB1423DD96BF73BBAE4AEAE121D3BE0MMXP123MB1423GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 6fff3a95-ec90-41d0-ee29-08d665b425fb X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Dec 2018 13:16:12.4189 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MMXP123MB0030 Archived-At: Subject: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 13:16:25 -0000 --_000_MMXP123MB1423DD96BF73BBAE4AEAE121D3BE0MMXP123MB1423GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to see draft-foudil-securitytxt progress and support its publi= cation in an amended format. On balance this draft will help to improve the reporting and correction of = vulnerabilities on servers and improve security for users and operators of = servers. I recognise that there are some valid concerns over authentication= of security.txt, particularly when the server has been compromised. In tha= t scenario, it will not be possible to trust the information provided in se= curity.txt. These concerns can be partially mitigated by using a secure tra= nsmission method such as TLS (v1.2 or v1.3). This improves the security aro= und provisioning security.txt and, although this is an imperfect solution, = I believe that overall the benefit to be gained from easier reporting of vu= lnerabilities outweighs the potential danger of incorrect information being= provided by a malicious security.txt on a compromised server. When securit= y.txt is used to find the reporting details for a vulnerability in a produc= t produced by a vendor, rather than in the server itself, we can assume tha= t the contents of the security.txt can be trusted and therefore there is no= danger in using security.txt. NCSC is keen to promote the usage of security.txt on UK public sector web s= ervers as a method of providing contact information for responsible disclos= ure of vulnerabilities. NCSC would incorporate usage of security.txt into i= ts "Web Check" service, a website configuration and vulnerability scanning = service available to all UK public sector organisations. I would like to see a change to the draft that mandates the use of a secure= transmission method for security.txt. In practice this will mean the use o= f HTTPS over TLS or in future HTTPS over QUIC (HTTP/3). So Section 3.1 ("Sc= ope") should state that security.txt MUST only be served over HTTPS (and th= e examples given using 'http://' should be removed from the text). Protecti= ng the whole website using TLS is good practice and provides a level of ass= urance that the contents of the file have not been tampered with, either at= rest on the server or in flight by a network adversary. There is a residua= l risk that the server has been compromised and therefore that the contents= of the file are malicious; this is recorded in the "Security Consideration= s" section. This residual risk can be reduced through the use of a digital = signature on security.txt (e.g. using PGP) or by recording contact details = in DNS records, but these solutions also bring complications (root of trust= for PGP key? can DNS data also be compromised?) therefore mandating a part= icular additional authentication appears to be counter-productive and would= hinder adoption of an otherwise simple RFC. I would additionally propose that, where the 'Contact:' directive is used t= o specify an email address using the 'mailto:' syntax, then it is necessary= to also specify an encryption public key (via the 'Encryption:' directive)= for protection of email messages sent to that contact address. So Section = 3.4.3 should specify that the Encryption: directive MUST be used when the c= ontent of the Contact: directive is an email address. The specification can= not mandate that security researchers use encryption on email sent to this = address - that would be out of scope - but an encryption key must at least = be available. In practice this will mean a PGP public key is published on t= he web server or a separate key server, but security.txt should not mandate= the format or the contents of the public key file. Some specific review comments on the -04 draft: * Replace "companies" by "organisations" throughout. * Section 3, replace "alway" by "always" * Section 3.4.2, replace "it MUST be begin" by "it MUST begin" * Section 3.4.3, replace "it MUST be begin" by "it MUST begin" * Section 3.4.4, replace "it SHOULD be begin" by "it SHOULD begin" Some further comments on Paul Wouters' outstanding concerns in-line below. On Thu, 23 Aug 2018 15:16:07, Paul Wouters wrote: > > On 07/16/2018 04:32 PM, Yakov Shafranovich wrote: > > > A new version of I-D, draft-foudil-securitytxt-04.txt > > has been successfully submitted by Edwin Foudil and posted to the > > IETF repository. > > URL: > > https://www.ietf.org/internet-drafts/draft-foudil-securitytxt-04.txt > > Status: https://datatracker.ietf.org/doc/draft-foudil-securityt= xt/ > > Htmlized: https://tools.ietf.org/html/draft-foudil-securitytxt-04 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-foudil-secu= ritytxt > > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-foudil-securi= tytxt-04 > > All my existing concerns still applies and it might even be worse now. > > Section 3.4.1 basically suggests building a list of fixed vulnerabilities= with the > acknowledgments section. So now hackers can scan for which servers haven'= t > been patched for something. Especially valuable if 9 out of 10 servers in= the > company have some acknowledgment but one of these does not. The amount of detail included on the security acknowledgments page is entir= ely at the discretion of the server's administrator; security.txt does not = mandate that specific vulnerabilities are disclosed. It is obviously undesi= rable to include information on the security acknowledgments page that woul= d lead an attacker to scan for a particular vulnerability or try a particul= ar attack. > > 3.4.3 is still terrible. If a server is compromised and security.txt is c= hanged to > the hackers PGP key, then ONLY the hackers are informed if someone is clo= se > to catching them. The real operators wont even be able to read the messag= e. Agreed that if the server is compromised to the extent that files can be ad= ded/modified/deleted then the contents of security.txt cannot be trusted. T= his can be partially mitigated by adopting good security practices includin= g the use of TLS and a signature on the file using an externally verifiable= public key. Ultimately there is a balance to be made between providing app= ropriate protection to the server and security.txt, and the usability and u= tility of security.txt for reporting security vulnerabilities, and this bal= ance may differ between use-cases. > > And this advise does not belong in an IETF document: > > If this directive indicates a web URL, then it MUST be begin with > "https://" > > with the entire world being https, this gives a false sense of security. = The > paragraphs also forms a nice Inception loop. What is the host that is hos= ting > the security key itself publishes a security.txt file. And why does it ev= en matter > in the first place if it is http or https, unless the person who found > the compromised website themselves are compromised? Would it be better to point to best current practice on the use of TLS for = securing servers, e.g. RFC 7525? HTTPS still brings benefits over HTTP beca= use an unauthenticated connection could be subject to a man-in-the-middle a= ttack to serve a fake version of security.txt, even without compromising th= e server. NCSC has published an article on why HTTPS matters: https://www.ncsc.gov.uk/blog-post/serve-websites-over-https-always Google also have a good article on the same topic: https://developers.google.com/web/fundamentals/security/encrypt-in-transit/= why-https > > When it comes to verifying the authenticity of the key, it is always > the security researcher's responsibility to make sure the key being > specified is indeed one they trust. > > So we pretend to offer a new "secure" method for finding a security conta= ct, > then say "dont ever trust this". So why specify this at all? HTTPS provides a baseline level of protection, but does not protect against= all threats (the server could have been compromised). It is good practice = to use an external method for verifying the authenticity of the contact, bu= t this is outside the scope of what can be specified within security.txt. > > 3.4.4 Hiring ? > > What are we now. a new Linked In protocol extension ? This is one way of building trust and a sense of community with vulnerabili= ty researchers to encourage responsible disclosure, but its presence in thi= s specification should be entirely optional. > > 3.4.7 signature file > > I have no idea why it has to be external and not inline, which is the typ= ical > PGP/GPG way This document should not mandate any particular format for a signature, inc= luding whether it is inline or external. > > 6 Security Considerations > > To me this reads like all the reasons why all of this is a bad idea. But = now > people like me who would never deploy this need to be aware of all of > this because my compromised server might add a security.txt file misleadi= ng > people so they will never contact me. It's a burden on those who don't > want to implement this unwise idea. > > > Anyway, the essence still remains. If I find a hacked server, I should no= t trust > that server for anything in provides. Instead, I should find another > resource that will hopefully still be trustworthy to find a contact. A nu= mber of > superiors ways: > > - Mail to the dns contact(s) of the domain based on SOA record email or > WHOIS/RDAP data > - Mail to the contact configured in the 40x errors on the http server (le= ts hope > hackers only got into /var/www and not /etc/httpd) > - google "security " > - go to linked in, find someone in IT in that company and ping them > - find a twitter account or facebook page of the company > - check any of the security groups/cabals ( eg ops-trust) > > All these methods are more trustworthy then a text file on a compromised > server. And even the draft says to not trust it so you end up having to d= o > one of these anyway. So I don't see it add any value at all. > > And if I was a hacker that compromised the server, I would surely delete = or > modify this file, or make it throw an error serving it. > > Another alternative approach is to add a field to the webservers certific= ate > that contains a contact email/phone field. An attacker won't be able > to modify this data without killing the certificate's CA signature. But t= hat might > be less useful now than in the past if the attacker can just ACME a new o= ne. > > I still think this document should not move forward, and believe it might= cause > more damage instead of making finding security contacts more reliable. > > Paul Any solutions proposed will be imperfect because of the possibility of fake= data being written to a compromised server (or DNS record, or TLS certific= ate). This proposal for security.txt is a pragmatic way forward that will b= e beneficial in the majority of cases and provides a basis for a more forma= l responsible vulnerability disclosure process. -- Mark This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_MMXP123MB1423DD96BF73BBAE4AEAE121D3BE0MMXP123MB1423GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


I would like to see draft-foudil-securitytxt progress and support its publi= cation in an amended format.

 

On balance this draft will help to improve the reporting and correction of = vulnerabilities on servers and improve security for users and operators of = servers. I recognise that there are some valid concerns over authentication= of security.txt, particularly when the server has been compromised. In that scenario, it will not be possible= to trust the information provided in security.txt. These concerns can be p= artially mitigated by using a secure transmission method such as TLS (v1.2 = or v1.3). This improves the security around provisioning security.txt and, although this is an imperfect soluti= on, I believe that overall the benefit to be gained from easier reporting o= f vulnerabilities outweighs the potential danger of incorrect information b= eing provided by a malicious security.txt on a compromised server. When security.txt is used to find the reporting d= etails for a vulnerability in a product produced by a vendor, rather than i= n the server itself, we can assume that the contents of the security.txt ca= n be trusted and therefore there is no danger in using security.txt.

 

NCSC is keen to promote the usage of security.txt on UK public sector web s= ervers as a method of providing contact information for responsible disclos= ure of vulnerabilities. NCSC would incorporate usage of security.txt into i= ts "Web Check" service, a website configuration and vulnerability scanning service available to all UK publi= c sector organisations.

 

I would like to see a change to the draft that mandates the use of a secure= transmission method for security.txt. In practice this will mean the use o= f HTTPS over TLS or in future HTTPS over QUIC (HTTP/3). So Section 3.1 (&qu= ot;Scope") should state that security.txt MUST only be served over HTTPS (and the examples given using 'http://' sho= uld be removed from the text). Protecting the whole website using TLS is go= od practice and provides a level of assurance that the contents of the file= have not been tampered with, either at rest on the server or in flight by a network adversary. There is a resi= dual risk that the server has been compromised and therefore that the conte= nts of the file are malicious; this is recorded in the "Security Consi= derations" section. This residual risk can be reduced through the use of a digital signature on security.txt (e.g= . using PGP) or by recording contact details in DNS records, but these solu= tions also bring complications (root of trust for PGP key? can DNS data als= o be compromised?) therefore mandating a particular additional authentication appears to be counter-productive an= d would hinder adoption of an otherwise simple RFC.

 

I would additionally propose that, where the 'Contact:' directive is used t= o specify an email address using the 'mailto:' syntax, then it is= necessary to also specify an encryption public key (via the 'Encryption:' directive) for protection of email messa= ges sent to that contact address. So Section 3.4.3 should specify that the = Encryption: directive MUST be used when the content of the Contact: directi= ve is an email address. The specification cannot mandate that security researchers use encryption on email sent to t= his address - that would be out of scope - but an encryption key must at le= ast be available. In practice this will mean a PGP public key is published = on the web server or a separate key server, but security.txt should not mandate the format or the contents= of the public key file.

 

Some specific review comments on the -04 draft:

* Replace "companies" by "organisations" throughout. * Section 3, replace "alway" by "always"

* Section 3.4.2, replace "it MUST be begin" by “it MUST beg= in”

* Section 3.4.3, replace "it MUST be begin" by “it MUST beg= in”

* Section 3.4.4, replace "it SHOULD be begin" by “it SHOULD= begin”

 

 

Some further comments on Paul Wouters' outstanding concerns in-line below.<= o:p>

 

 

On Thu, 23 Aug 2018 15:16:07, Paul Wouters wrote:

>

> On 07/16/2018 04:32 PM, Yakov Shafranovich wrote:

>

> > A new version of I-D, draft-foudil-securitytxt-04.txt<= /p>

> > has been successfully submitted by Edwin Foudil and posted to the=

> > IETF repository.

> > URL:

> > https://www.ietf.org/= internet-drafts/draft-foudil-securitytxt-04.txt

> > Status:         https://datatracker.i= etf.org/doc/draft-foudil-securitytxt/

> > Htmlized:       https://tools.ietf.or= g/html/draft-foudil-securitytxt-04

> > Htmlized:       https://datatracker.i= etf.org/doc/html/draft-foudil-securitytxt

> > Diff:          = https://www.ietf.org/= rfcdiff?url2=3Ddraft-foudil-securitytxt-04

>

> All my existing concerns still  applies and it might even be wors= e now.

>

> Section 3.4.1 basically suggests building a list of fixed vulnerabilit= ies with the

> acknowledgments section. So now hackers can scan for which servers hav= en't

> been patched for something. Especially valuable if 9 out of 10 servers= in the

> company have some acknowledgment but one of these does not.=

 

The amount of detail included on the security acknowledgments page is entir= ely at the discretion of the server's administrator; security.txt does not = mandate that specific vulnerabilities are disclosed. It is obviously undesi= rable to include information on the security acknowledgments page that would lead an attacker to scan for = a particular vulnerability or try a particular attack.

 

>

> 3.4.3 is still terrible. If a server is compromised and security.txt i= s changed to

> the hackers PGP key, then ONLY the hackers are informed if someone is = close

> to catching them. The real operators wont even be able to read the mes= sage.

 

Agreed that if the server is compromised to the extent that files can be ad= ded/modified/deleted then the contents of security.txt cannot be trusted. T= his can be partially mitigated by adopting good security practices includin= g the use of TLS and a signature on the file using an externally verifiable public key. Ultimately there is= a balance to be made between providing appropriate protection to the serve= r and security.txt, and the usability and utility of security.txt for repor= ting security vulnerabilities, and this balance may differ between use-cases.

 

>

> And this advise does not belong in an IETF document:

>

>         If this directive indicates= a web URL, then it MUST be begin with

> "https://”

>

> with the entire world being https, this gives a false sense of securit= y. The

> paragraphs also forms a nice Inception loop. What is the host that is = hosting

> the security key itself publishes a security.txt file. And why does it= even matter

> in the first place if it is http or https, unless the person who found=

> the compromised website themselves are compromised?

 

Would it be better to point to best current practice on the use of TLS for = securing servers, e.g. RFC 7525? HTTPS still brings benefits over HTTP beca= use an unauthenticated connection could be subject to a man-in-the-middle a= ttack to serve a fake version of security.txt, even without compromising the server.

 

NCSC has published an article on why HTTPS matters:

<= span style=3D"color:windowtext;text-decoration:none">https://www.ncsc.gov.u= k/blog-post/serve-websites-over-https-always

Googl= e also have a good article on the same topic:
https://developers.google.com/web/fundamentals/security/encrypt-in-transit= /why-https

 

>

>    When it comes to verifying the authenticity of the key, i= t is always

>    the security researcher's responsibility to make sure the= key being

>    specified is indeed one they trust.

>

> So we pretend to offer a new "secure" method for finding a s= ecurity contact,

> then say "dont ever trust this". So why specify this at all?=

 

HTTPS provides a baseline level of protection, but does not protect against= all threats (the server could have been compromised). It is good practice = to use an external method for verifying the authenticity of the contact, bu= t this is outside the scope of what can be specified within security.txt.

 

>

> 3.4.4 Hiring ?

>

> What are we now. a new Linked In protocol extension ?

 

This is one way of building trust and a sense of community with vulnerabili= ty researchers to encourage responsible disclosure, but its presence in thi= s specification should be entirely optional.

 

>

> 3.4.7 signature file

>

> I have no idea why it has to be external and not inline, which is the = typical

> PGP/GPG way

 

This document should not mandate any particular format for a signature, inc= luding whether it is inline or external.

 

>

> 6 Security Considerations

>

> To me this reads like all the reasons why all of this is a bad idea. B= ut now

> people like me who would never deploy this need to be aware of all of<= o:p>

> this because my compromised server might add a security.txt file misle= ading

> people so they will never contact me. It's a burden on those who don't=

> want to implement this unwise idea.

>

>

> Anyway, the essence still remains. If I find a hacked server, I should= not trust

> that server for anything in provides. Instead, I should find another

> resource that will hopefully still be trustworthy to find a contact. A= number of

> superiors ways:

>

> - Mail to the dns contact(s) of the domain based on SOA record email o= r

> WHOIS/RDAP data

> - Mail to the contact configured in the 40x errors on the http server = (lets hope

> hackers only got into /var/www and not /etc/httpd)

> - google "security <domain name>"

> - go to linked in, find someone in IT in that company and ping them

> - find a twitter account or facebook page of the company

> - check any of the security groups/cabals ( eg ops-trust)

>

> All these methods are more trustworthy then a text file on a compromis= ed

> server. And even the draft says to not trust it so you end up having t= o do

> one of these anyway. So I don't see it add any value at all.

>

> And if I was a hacker that compromised the server, I would surely dele= te or

> modify this file, or make it throw an error serving it.

>

> Another alternative approach is to add a field to the webservers certi= ficate

> that contains a contact email/phone field. An attacker won't be able

> to modify this data without killing the certificate's CA signature. Bu= t that might

> be less useful now than in the past if the attacker can just ACME a ne= w one.

>

> I still think this document should not move forward, and believe it mi= ght cause

> more damage instead of making finding security contacts more reliable.=

>

> Paul

 

Any solutions proposed will be imperfect because of the possibility of fake= data being written to a compromised server (or DNS record, or TLS certific= ate). This proposal for security.txt is a pragmatic way forward that will b= e beneficial in the majority of cases and provides a basis for a more formal responsible vulnerability dis= closure process.

 

-- Mark

 

 

&nbs= p;

This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_MMXP123MB1423DD96BF73BBAE4AEAE121D3BE0MMXP123MB1423GBRP_-- From nobody Wed Dec 19 13:13:47 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCB1130ED8 for ; Wed, 19 Dec 2018 13:13:45 -0800 (PST) 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, FREEMAIL_FROM=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 (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 mN6JrRQr59IL for ; Wed, 19 Dec 2018 13:13:44 -0800 (PST) Received: from mail-it1-x12c.google.com (mail-it1-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 D59E3130E86 for ; Wed, 19 Dec 2018 13:13:43 -0800 (PST) Received: by mail-it1-x12c.google.com with SMTP id g76so11879319itg.2 for ; Wed, 19 Dec 2018 13:13:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=H9t2BDi31rXLWXigGwpmbkkUIM9LEo4/h0u4jgVwZSE=; b=l58y+b2MgtuX1CF6VWB7pmfPh8JTguTbrGUqxP7h9XsOqBGijAqEn9AKkfp5/ehugK cqb8oi4faQor/l1vSpwgPMN7uSspWMRucpILxxz+mGTLoOLt/O3nLsAIsLUeT3OdbkgV pQtX2r3JTaZTGzc6ZDf8HVql5Tptoflxiq6ZLO5xLOP3GBL0hK1zXMcPDsb94Mg5PdXy JJUmrtnT3Y72jPT8LpJ0r7eWlm/eX1xIDXFoZiyYEUpklF678F5fJbRZeA8RE70va8HT 1y5ph0Hm6QcrTzwnd72TkkP6dk/NePvxWsMPxnQn0sh2Fz0+iSm3vkDN/fXzfOwvZlbm CQNQ== 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:reply-to :from:date:message-id:subject:to:cc; bh=H9t2BDi31rXLWXigGwpmbkkUIM9LEo4/h0u4jgVwZSE=; b=Hw/Gey879zRdseY+fM2PULpYo+WwI7w/E8y5MBahyAM4tltaDm+NJQPBoe3RwhnRco JK4416VsiOn/f2KGwfBkegNnYPHqgutO8GFO9b8dGynhN+lNfq7IMws3B9SwACHDpGnn gD9utD0SECXcG6j7+GlYIG+cmiLVY9buXLmPkfIb4eXNJQAwIYzSRrlpQTR3OrHzW8t1 EOWK2QCmuIuy2wFpf2rYM3jhnmt/KvitU/MEmxtqx/I0wENCBoyXH/ACkzxXF/G3GLP8 x8BrKAUPN8hrSsntClFMaRz7u+LKqCe9e13Fm096CRzzObWaJeWVuh8/EyZecVvfNSzb Fd/A== X-Gm-Message-State: AA+aEWZc2i7bhVMxnB3FLGqy/6x/jVugr4cq4tPh3coky/yz2xqUMdaD s6K4KoQqw4oQHA3s5mVsYqUeGy3sX+O6SoIrZKyUsw7K X-Google-Smtp-Source: AFSGD/WNLZggmFu903CWW7XzHuuor6dbyozwRkcV3kloesA2iBHuxZf9fH6LDA2OuTo7djFgHndH0KxLLILzI52R+sQ= X-Received: by 2002:a24:1d4a:: with SMTP id 71mr7433016itj.62.1545254023127; Wed, 19 Dec 2018 13:13:43 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> In-Reply-To: <1545188081299.7191@cs.auckland.ac.nz> Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Wed, 19 Dec 2018 16:13:29 -0500 Message-ID: To: Peter Gutmann Cc: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 21:13:46 -0000 On Tue, Dec 18, 2018 at 9:54 PM Peter Gutmann wrote: > > Jeffrey Walton writes: > > >You might consider adding a note that the byte array is written to the > >octet string with the LSB in the first position, and the MSB in the last > >position. As far as I know this draft is the only one that reverses the > >byte ordering for presentation. It will avoid confusion for future readers > >who expect network byte ordering in ASN.1 presentations. > > This was requested when the RFCs were written (alongside using the standard > X9.62 form that everything else uses), but nothing got done. Basically the > encoding used for the Bernstein curves is the reverse to the way everything > else does it. So you take the standard form used by all other curves, then > encode the values backwards. In my code I use a shim layer that reverses > the bytes, at which point they can be handled by code that expects them in > the standard form. Yeah, using the little endian presentation brings up some weird use cases. Suppose a named curve is not used (i, e., curve25519 parameters are specified). The other domain parameters like prime and subgroup order are big endian but the keys are little endian. I'm fairly certain the best course of action is to make this use case work as expected: $ dumpasn1 ed25519.bin 0 52: SEQUENCE { 2 1: INTEGER 0 ... 33 32: OCTET STRING : 6D C5 9D 3F 09 7F B2 3D 44 BA 90 79 12 81 B4 53 : 25 8D 69 1A 55 AF 5C E4 F1 EE 71 2F DF 91 AE 98 : } And then something like this with Botan (or pick your favorite library): uint8_t sb[32] = {0x6D, 0xC5, ... 0xAE, 0x98}; BigInt sk(sb, 32); The extra "byte reverse" needed to make things work as expected is non-intuitive and not documented. But maybe I am missing something or I don't understand the motivation. Jeff From nobody Wed Dec 19 14:03:38 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06368130EE5 for ; Wed, 19 Dec 2018 14:03:36 -0800 (PST) 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] 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 5YK46Iu9ERRP for ; Wed, 19 Dec 2018 14:03:33 -0800 (PST) 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 8DCF7130EAE for ; Wed, 19 Dec 2018 14:03:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 37AA23005AB for ; Wed, 19 Dec 2018 17:03:31 -0500 (EST) 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 kBhPyoxWwQ7t for ; Wed, 19 Dec 2018 17:03:29 -0500 (EST) Received: from [192.168.1.161] (pool-108-45-137-105.washdc.fios.verizon.net [108.45.137.105]) by mail.smeinc.net (Postfix) with ESMTPSA id EA428300054; Wed, 19 Dec 2018 17:03:28 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Russ Housley In-Reply-To: Date: Wed, 19 Dec 2018 17:03:30 -0500 Cc: IETF SAAG , curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> To: noloader@gmail.com X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 22:03:36 -0000 This discussion probably belongs on the CURDLE WG mail list ... Note that draft-ietf-curdle-pkix has been published as RFC 8410. When this object identifier is used: id-Ed25519 OBJECT IDENTIFIER ::=3D { 1 3 101 112 } the algorithm parameters are absent, so there is no opportunity to = define the curve through parameters. The RFC warns: Both [RFC7748] and [RFC8032] define the public key value as being a byte string. It should be noted that the public key is computed differently for each of these documents; thus, the same private key will not produce the same public key. The RFC could have also warned about the big-endian vs. little-endian = encoding used in different RFCs related to elliptic curve. Russ > On Dec 19, 2018, at 4:13 PM, Jeffrey Walton = wrote: >=20 > On Tue, Dec 18, 2018 at 9:54 PM Peter Gutmann = wrote: >>=20 >> Jeffrey Walton writes: >>=20 >>> You might consider adding a note that the byte array is written to = the >>> octet string with the LSB in the first position, and the MSB in the = last >>> position. As far as I know this draft is the only one that reverses = the >>> byte ordering for presentation. It will avoid confusion for future = readers >>> who expect network byte ordering in ASN.1 presentations. >>=20 >> This was requested when the RFCs were written (alongside using the = standard >> X9.62 form that everything else uses), but nothing got done. = Basically the >> encoding used for the Bernstein curves is the reverse to the way = everything >> else does it. So you take the standard form used by all other = curves, then >> encode the values backwards. In my code I use a shim layer that = reverses >> the bytes, at which point they can be handled by code that expects = them in >> the standard form. >=20 > Yeah, using the little endian presentation brings up some weird use > cases. Suppose a named curve is not used (i, e., curve25519 parameters > are specified). The other domain parameters like prime and subgroup > order are big endian but the keys are little endian. >=20 > I'm fairly certain the best course of action is to make this use case > work as expected: >=20 > $ dumpasn1 ed25519.bin > 0 52: SEQUENCE { > 2 1: INTEGER 0 > ... > 33 32: OCTET STRING > : 6D C5 9D 3F 09 7F B2 3D 44 BA 90 79 12 81 B4 53 > : 25 8D 69 1A 55 AF 5C E4 F1 EE 71 2F DF 91 AE 98 > : } >=20 > And then something like this with Botan (or pick your favorite = library): >=20 > uint8_t sb[32] =3D {0x6D, 0xC5, ... 0xAE, 0x98}; > BigInt sk(sb, 32); >=20 > The extra "byte reverse" needed to make things work as expected is > non-intuitive and not documented. But maybe I am missing something or > I don't understand the motivation. >=20 > Jeff >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Dec 19 15:03:37 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E1130E7F for ; Wed, 19 Dec 2018 15:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.564 X-Spam-Level: X-Spam-Status: No, score=-9.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4lCg_QtxEUU for ; Wed, 19 Dec 2018 15:03:32 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90798130EF1 for ; Wed, 19 Dec 2018 15:03:32 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id t13so24214893qtn.3 for ; Wed, 19 Dec 2018 15:03:32 -0800 (PST) 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=8eZINLqrf73JFXvMeUfcKd/iPHXdLO1QMySwRst9Bio=; b=QOKKe6qR7umXmQSeu3wFUpmNWI6UfQcPnVmKNUWgEsljTGJbWiqgKL4DTlUNuTx/sC kviVlh9gVdue57rIrf0LOZ2UgYJDOZNCPron3UyCohTfmzjMIcsbB/99WjmbYwPj5l+M ANgV06fJAG8gSgT41q1uw9CQYm6/rkwIV8IaM= 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=8eZINLqrf73JFXvMeUfcKd/iPHXdLO1QMySwRst9Bio=; b=c7TIwivrX+Ja0kpLsQPbG8npVz4hxk183/kIt6fc2/if8zYW98fvUsBK7OLphKpYFA pUILeoPDjb/oEOALhgQzjcmwypHbqscMRuN6oBvYqUE3PMZFTZ7y3GX582ByoHIhs9Ct Yng5mOjkY7vi7vX+NNqCiFXmihD8F04K0fHiCvA9z6ESr5V67s5xkliMzppwfEddZR5g /9XcCgysFIeeBITX6uUtQoL+9YMR+S/SrofYvTNX8dbk6gZbkrKvn/kPOo/xKf84lRzz bCjIHqpopczKpILJ9i+QyFFZeU6BuGUF5II2vQVrOoTNNaT15WgmljdvavAenu4Aclk4 NSfQ== X-Gm-Message-State: AA+aEWZxDByrK8qQ+4brRtbX8Kpak7OZOp3Tf6YBY3ldBPKlkDFypHiv wepqMoRsO0Ra1qoesjiXav/wdqv982zwkCgZ7iLrZn5VvQ== X-Google-Smtp-Source: AFSGD/U51zX9/6gBmOQTDuZkwH6c6lgvuHBMG+ZDM+Yw25QXthtjfweYeTkmHo9E2VvmZfJ6VmXLd3UtnhPIEXdtHIo= X-Received: by 2002:ac8:1873:: with SMTP id n48mr23500695qtk.10.1545260611378; Wed, 19 Dec 2018 15:03:31 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> In-Reply-To: From: David Benjamin Date: Wed, 19 Dec 2018 17:03:19 -0600 Message-ID: To: Russ Housley Cc: noloader@gmail.com, curdle , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000d4370a057d680567" Archived-At: Subject: Re: [saag] [Curdle] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 23:03:36 -0000 --000000000000d4370a057d680567 Content-Type: text/plain; charset="UTF-8" (Is the concern that RFC 7748 and RFC 8032 differ in endianness or that the pair of them differ in endianness from X9.42-style EC? I'm assuming it's the latter, because the former is not the case. RFC 7748 and RFC 8032 both specify little-endian. They're different for other reasons.) No objections to clarifying, but RFC 8032 (correctly) specifies Ed25519 and X25519 algorithms as functions on byte strings and RFC 8410 (correctly) defers to that. So probably a better question is whether RFC 8032 is clear enough on the internal serialization. I think the best architecture here is for byte string serialization to be handled by your Ed25519 and X25519 implementations internally, so the ASN.1 layer doesn't need to care. (Endianness is far from the biggest distinction between X9.42-style EC and X25519/Ed25519. They use different curve equation shapes altogether.) As an analogy, if you look at SHA-256's internals, a SHA-256 hash isn't 32 bytes, but eight 32-bit integers. But this is not a useful public interface, so SHA-256 comes with a particular byte encoding of those eight integers. It could have been big-endian, little-endian, or middle-endian and nothing outside of low-level SHA-256 implementations would have known. It is unfortunate that ECDSA got this wrong and saddled us with a mess of different serializations, wasting time and complexity. RFCs 8032 and 8410 happily did not repeat this mistake, and we should keep this up. To that end, the quoted text talks about using curve parameters explicitly rather than a non-named curve. RFC 8410 doesn't specify such a thing. I would have made a lot of noise if it had. :-) Which encoding is this referring to? David On Wed, Dec 19, 2018 at 4:03 PM Russ Housley wrote: > This discussion probably belongs on the CURDLE WG mail list ... > > Note that draft-ietf-curdle-pkix has been published as RFC 8410. > > When this object identifier is used: > > id-Ed25519 OBJECT IDENTIFIER ::= { 1 3 101 112 } > > the algorithm parameters are absent, so there is no opportunity to define > the curve through parameters. > > The RFC warns: > > Both [RFC7748] and [RFC8032] define the public key value as being a > byte string. It should be noted that the public key is computed > differently for each of these documents; thus, the same private key > will not produce the same public key. > > The RFC could have also warned about the big-endian vs. little-endian > encoding used in different RFCs related to elliptic curve. > > Russ > > > > On Dec 19, 2018, at 4:13 PM, Jeffrey Walton wrote: > > > > On Tue, Dec 18, 2018 at 9:54 PM Peter Gutmann > wrote: > >> > >> Jeffrey Walton writes: > >> > >>> You might consider adding a note that the byte array is written to the > >>> octet string with the LSB in the first position, and the MSB in the > last > >>> position. As far as I know this draft is the only one that reverses the > >>> byte ordering for presentation. It will avoid confusion for future > readers > >>> who expect network byte ordering in ASN.1 presentations. > >> > >> This was requested when the RFCs were written (alongside using the > standard > >> X9.62 form that everything else uses), but nothing got done. Basically > the > >> encoding used for the Bernstein curves is the reverse to the way > everything > >> else does it. So you take the standard form used by all other curves, > then > >> encode the values backwards. In my code I use a shim layer that > reverses > >> the bytes, at which point they can be handled by code that expects them > in > >> the standard form. > > > > Yeah, using the little endian presentation brings up some weird use > > cases. Suppose a named curve is not used (i, e., curve25519 parameters > > are specified). The other domain parameters like prime and subgroup > > order are big endian but the keys are little endian. > > > > I'm fairly certain the best course of action is to make this use case > > work as expected: > > > > $ dumpasn1 ed25519.bin > > 0 52: SEQUENCE { > > 2 1: INTEGER 0 > > ... > > 33 32: OCTET STRING > > : 6D C5 9D 3F 09 7F B2 3D 44 BA 90 79 12 81 B4 53 > > : 25 8D 69 1A 55 AF 5C E4 F1 EE 71 2F DF 91 AE 98 > > : } > > > > And then something like this with Botan (or pick your favorite library): > > > > uint8_t sb[32] = {0x6D, 0xC5, ... 0xAE, 0x98}; > > BigInt sk(sb, 32); > > > > The extra "byte reverse" needed to make things work as expected is > > non-intuitive and not documented. But maybe I am missing something or > > I don't understand the motivation. > > > > Jeff > > > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --000000000000d4370a057d680567 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Is the concern that RFC 7748 and RFC 8032 differ in = endianness or that the pair of them differ in endianness from X9.42-style E= C? I'm assuming it's the latter, because the former is not the case= . RFC 7748 and RFC 8032 both specify little-endian. They're different f= or other reasons.)

No objections to clarifying, but RFC= 8032 (correctly) specifies Ed25519 and X25519 algorithms as functions on b= yte strings and RFC 8410 (correctly) defers to that. So probably a better q= uestion is whether RFC 8032 is clear enough on the internal serialization.<= div>
I think the best architecture here is for byte string se= rialization to be handled by your Ed25519 and X25519 implementations intern= ally, so the ASN.1 layer doesn't need to care. (Endianness is far from = the biggest distinction between X9.42-style EC and X25519/Ed25519. They use= different curve equation shapes altogether.)

As an= analogy, if you look at SHA-256's internals, a SHA-256 hash isn't = 32 bytes, but eight 32-bit integers. But this is not a useful public interf= ace, so SHA-256 comes with a particular byte encoding of those eight intege= rs. It could have been big-endian, little-endian, or middle-endian and noth= ing outside of low-level SHA-256 implementations would have known.

It is unfortunate that ECDSA got this wrong and saddled us= with a mess of different serializations, wasting time and complexity. RFCs= 8032 and 8410 happily did not repeat this mistake, and we should keep this= up.

To that end, the quoted text talks about usin= g curve parameters explicitly rather than a non-named curve. RFC 8410 doesn= 't specify such a thing. I would have made a lot of noise if it had. :-= ) Which encoding is this referring to?

David
=

On Wed,= Dec 19, 2018 at 4:03 PM Russ Housley <housley@vigilsec.com> wrote:
This discussion probably belongs on the CURDLE WG mail list ...

Note that draft-ietf-curdle-pkix has been published as RFC 8410.

When this object identifier is used:

=C2=A0 =C2=A0id-Ed25519=C2=A0 =C2=A0OBJECT IDENTIFIER ::=3D { 1 3 101 112 }=

the algorithm parameters are absent, so there is no opportunity to define t= he curve through parameters.

The RFC warns:

=C2=A0 =C2=A0Both [RFC7748] and [RFC8032] define the public key value as be= ing a
=C2=A0 =C2=A0byte string.=C2=A0 It should be noted that the public key is c= omputed
=C2=A0 =C2=A0differently for each of these documents; thus, the same privat= e key
=C2=A0 =C2=A0will not produce the same public key.

The RFC could have also warned about the big-endian vs. little-endian encod= ing used in different RFCs related to elliptic curve.

Russ


> On Dec 19, 2018, at 4:13 PM, Jeffrey Walton <noloader@gmail.com> wrote:
>
> On Tue, Dec 18, 2018 at 9:54 PM Peter Gutmann <pgut001@cs.auckland.ac.nz>= ; wrote:
>>
>> Jeffrey Walton <noloader@gmail.com> writes:
>>
>>> You might consider adding a note that the byte array is writte= n to the
>>> octet string with the LSB in the first position, and the MSB i= n the last
>>> position. As far as I know this draft is the only one that rev= erses the
>>> byte ordering for presentation. It will avoid confusion for fu= ture readers
>>> who expect network byte ordering in ASN.1 presentations.
>>
>> This was requested when the RFCs were written (alongside using the= standard
>> X9.62 form that everything else uses), but nothing got done.=C2=A0= Basically the
>> encoding used for the Bernstein curves is the reverse to the way e= verything
>> else does it.=C2=A0 So you take the standard form used by all othe= r curves, then
>> encode the values backwards.=C2=A0 In my code I use a shim layer t= hat reverses
>> the bytes, at which point they can be handled by code that expects= them in
>> the standard form.
>
> Yeah, using the little endian presentation brings up some weird use > cases. Suppose a named curve is not used (i, e., curve25519 parameters=
> are specified). The other domain parameters like prime and subgroup > order are big endian but the keys are little endian.
>
> I'm fairly certain the best course of action is to make this use c= ase
> work as expected:
>
> $ dumpasn1 ed25519.bin
>=C2=A0 0=C2=A0 52: SEQUENCE {
>=C2=A0 2=C2=A0 =C2=A01:=C2=A0 =C2=A0INTEGER 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
> 33=C2=A0 32:=C2=A0 =C2=A0OCTET STRING
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A06D C5 9D 3F 09 7F B2 3D= 44 BA 90 79 12 81 B4 53
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0 =C2=A025 8D 69 1A 55 AF 5C E4= F1 EE 71 2F DF 91 AE 98
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:=C2=A0 =C2=A0}
>
> And then something like this with Botan (or pick your favorite library= ):
>
>=C2=A0 =C2=A0uint8_t sb[32] =3D {0x6D, 0xC5, ... 0xAE, 0x98};
>=C2=A0 =C2=A0BigInt sk(sb, 32);
>
> The extra "byte reverse" needed to make things work as expec= ted is
> non-intuitive and not documented. But maybe I am missing something or<= br> > I don't understand the motivation.
>
> Jeff
>
> _______________________________________________
> saag mailing list
> saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag

_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle

--000000000000d4370a057d680567-- From nobody Wed Dec 19 15:34:48 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04D3130EF1; Wed, 19 Dec 2018 15:34:39 -0800 (PST) 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, FREEMAIL_FROM=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 (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 2jymtqLgZbm9; Wed, 19 Dec 2018 15:34:37 -0800 (PST) Received: from mail-it1-x132.google.com (mail-it1-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 34895130E86; Wed, 19 Dec 2018 15:34:37 -0800 (PST) Received: by mail-it1-x132.google.com with SMTP id b5so311641iti.2; Wed, 19 Dec 2018 15:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=gvJLfHyHRumzjm3K8qrb0q9RWVrNOwmpSPzDV7BH4a4=; b=hHD622lqF8qcm/LwSVoz7CuOjrakB4BB+B3RRYM7JNERzfZNIrzyiK8zxs3fg+EwsE wOWCgwPa3TiPpkoiPNhiBdd4NNo/2vOxTNYFzcDsubELhgzMESjHW0RmBf7R4i+Qzk1v mGb2/XOhbtNqOwMjCRD+OBZ9HWjYhy4S+2URtn/wHfTBjBwB4PPl1l7MVKZEhoPwvKMO lrl4OW3gbBrg5L/NsgIaWhxYF3WF0qblcZ+6yQeGTWYZi5B+AhuL/cL/Jl3lk3T8fPd0 YtJ7vdNq4hM03Vb6pndapBQyQCSF1LrFZ+thFG/htPZe1NCXNQGW0tNrr+mtlwxqF/oh dagg== 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:reply-to :from:date:message-id:subject:to:cc; bh=gvJLfHyHRumzjm3K8qrb0q9RWVrNOwmpSPzDV7BH4a4=; b=BfqbyFlZU9r+r3zn2CP3x54/P5nuRl+z5RMkkU5Dfva5JEUgUC7p/TE0m6GbJdzsIc tJVQrPA53LSI+hOkhbxA8W4oyCkFA9VV+x+Y0ZSg1Y26l6WE9Ub/yXqhCrQ08XMt0lor mfK82Gtw3VEyIjvjup+UjDoW7grR5u0OR6et/mJwjpR45vYaQgEuuNVhWTUl+zFFqtHr ElNrmodblKtnuR+F9SDIHPq9KnuWLx9X2cnFdctgGyrGpVKSkF5+Lf36++b64B4lKLbF YPS51dyevWgn8rwccC6+mWRG0aJ9H+lrVOJOsqbJphF2Qx9vxETEOwpYzaUHrkyGtsrR Bqlg== X-Gm-Message-State: AA+aEWYgsT3xxUkpOLwbZY0Jo2ILcTulVe/8m0eJJqrCkwnH0/IQMrnM NVEbUBRW+tF7hpzCZaVe2ziIhaJGlHuoY2U4laGaTj63 X-Google-Smtp-Source: AFSGD/WxLli3WfsniIn/uUkuuv84M3uAFYyKxnE2mQJj/hE+V50udCghll3M/k7MckR8+Zfmn0BC71lEBQgTr95uNrg= X-Received: by 2002:a24:1d4a:: with SMTP id 71mr7758186itj.62.1545262476566; Wed, 19 Dec 2018 15:34:36 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Wed, 19 Dec 2018 18:34:23 -0500 Message-ID: To: Russ Housley Cc: IETF SAAG , curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 23:34:40 -0000 On Wed, Dec 19, 2018 at 5:03 PM Russ Housley wrote: > ... > Note that draft-ietf-curdle-pkix has been published as RFC 8410. Thanks Russ. Off-topic, my Google search for curve OIDs and encodings lead me to draft-ietf-curdle-pkix . I plugged in https://tools.ietf.org/id/draft-ietf-curdle-pkix.txt and got version 10 of the document. The document does not state there is an RFC available. Here's the relevant preamble: Network Working Group S. Josefsson Internet-Draft SJD AB Intended status: Standards Track J. Schaad Expires: November 9, 2018 August Cellars May 8, 2018 >From an outsider's view, all we know is the IETF is working on it. The doc has expired but it is the latest available. When NIST supersedes a document they serve pages like... FIPS 186-3 search: * https://csrc.nist.gov/publications/detail/fips/186/3/archive/2009-06-25 SP800-53A Rev 1 search: * https://csrc.nist.gov/publications/detail/sp/800-53a/rev-1/archive/2010-06-29 NIST makes it harder to use the wrong document for the typical use case. Jeff From nobody Wed Dec 19 16:37:53 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0F6130DD3; Wed, 19 Dec 2018 16:37:45 -0800 (PST) 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, FREEMAIL_FROM=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 (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 kLVG8r-dWEw6; Wed, 19 Dec 2018 16:37:43 -0800 (PST) Received: from mail-it1-x12f.google.com (mail-it1-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 29B3412D7EA; Wed, 19 Dec 2018 16:37:43 -0800 (PST) Received: by mail-it1-x12f.google.com with SMTP id z7so518773iti.0; Wed, 19 Dec 2018 16:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=nt/QwKrZhLh2M5njZxY2JSGKpcgLMlEnEgBitamDj1I=; b=kw5vaHslb1vBdLrIuq4pl98tOEGOYc9PkuqqS4pZehCHXiPLtpBtSpGSqDEZLUJ7Zd 4lxisHIo7A/QmjEmZ+ukaFq/jZOnjh+FoC4NQZ8BozT/kX53RcLLNne5/EnekvUDYR1S 0xFoJDvpSiYUb63eYB0OzTI+lZ6u2zeUxNcsYqOs4JZEIv9BGcmHJcrfrIVArziVzvGK eDogbQcRAsU56a0NmDF9N4/13iGMbz+VpwSjwcXyFurg5AAURMdDDCL0/40k9Wq4Y8UT jDe4yOmGvqHG2ri2jLIbE/L8iKZI7EjQysrbk/EvCCqTrxtf+bHzI1QLmmQIb2J2fyjX BZCA== 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:reply-to :from:date:message-id:subject:to:cc; bh=nt/QwKrZhLh2M5njZxY2JSGKpcgLMlEnEgBitamDj1I=; b=cNPQdJv87PQFaFN1cHvzP4YCLSptC/augu/RdOT0aRFAkTl/XOXKTkuqt+Sbng14tM IH+Fsp+GAH76FBis8xXNlHqp1AjgT4/c1u8sjAOdZVko2JrnIupKkVwJH+NLv9CROGwj MiqNsYR+Hgv6qBYnZ7XG/beHSC0a+0NH3aPDWZ5w1w5QIjF850vKZH8t1z97yX63+1RV VjQetk1wsHWuqDTYLlriPXG4fyWHUejszxsuy+FAjfjYANItPDrHSOuDff1GhfSGUK9V rltujLhzaBgDJBB8sROYcxRkz2yMjH1VxT4wlLuhSz70uA2mfJfyWbBbRzyfpKdgCAzM aprg== X-Gm-Message-State: AA+aEWay0Z0a6CLny1J1kAWz9l1w+k6f41PtRtXvgeoTWnMOww84VfJu 5AhhtgXKyF+p24GDe7W9GwVmkQDAcvygwMPRdJg= X-Google-Smtp-Source: AFSGD/UNcFUmsotCiQr8NZnY2lyJXG7fQNwTATSKYRoEHzHBhdiXORcmt88LBf9ygio6gWa1m+/kORXUkv0XWaCg2SM= X-Received: by 2002:a24:c8d7:: with SMTP id w206mr8725951itf.56.1545266262390; Wed, 19 Dec 2018 16:37:42 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> In-Reply-To: Reply-To: noloader@gmail.com From: Jeffrey Walton Date: Wed, 19 Dec 2018 19:37:28 -0500 Message-ID: To: David Benjamin Cc: curdle , IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] [Curdle] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 00:37:45 -0000 On Wed, Dec 19, 2018 at 6:03 PM David Benjamin wrote: > ... > To that end, the quoted text talks about using curve parameters explicitly rather than a non-named curve. RFC 8410 doesn't specify such a thing. I would have made a lot of noise if it had. :-) Which encoding is this referring to? Thanks David. I have this test program handy for interop testing. I believe it is using the EC key format from RFC 5480. This is what everyone has been using in the void before the latest IETF deliverables. In the program below the OID is new, but previous to getting Thawte's OID we used GNU's old OID for curve25519. In between new (Thawte) and old (GNU) we could use the OID's draft-josefsson-pkix-newcurves. Many folks have to support 8 or 10 OIDs for the curves. EC domain parameters (instead of a named curve) was going to be my next test case to ensure we interop or work as expected. I guess the point is, just because the latest RFC does not specify it, it does not mean it is not going to happen. In fact, it has been happening for years now because of the information void. RFC 5480 (with a mashup of OIDs) was enough to keep us going. Jeff $ cat x25519.c #include #include int main (int argc, char* argv) { EVP_PKEY *pkey = NULL; EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new_id(EVP_PKEY_X25519, NULL); EVP_PKEY_keygen_init(pctx); EVP_PKEY_keygen(pctx, &pkey); EVP_PKEY_CTX_free(pctx); PEM_write_PrivateKey(stdout, pkey, NULL, NULL, 0, NULL, NULL); return 0; } And then compile it. In the example below, OpenSSL was configured with --prefix=/opt/openssl-1.1.1. $ gcc -I /opt/openssl-1.1.1/include/ -L /opt/openssl-1.1.1/lib x25519.c -o x25519.exe -l:libcrypto.a -lpthread -ldl$ And finally: $ ./x25519.exe -----BEGIN PRIVATE KEY----- MC4CAQAwBQYDK2VuBCIEIMBio4/nGHPiJzCUDifuMl7zg6Me2XlI5jAKCyPRlW5R -----END PRIVATE KEY----- $ echo MC4CAQAwBQYDK2VuBCIEIMBio4/nGHPiJzCUDifuMl7zg6Me2XlI5jAKCyPRlW5R | base64 -d > x25519.bin $ dumpasn1 x25519.bin 0 46: SEQUENCE { 2 1: INTEGER 0 5 5: SEQUENCE { 7 3: OBJECT IDENTIFIER curveX25519 (1 3 101 110) : } 12 34: OCTET STRING, encapsulates { 14 32: OCTET STRING : C0 62 A3 8F E7 18 73 E2 27 30 94 0E 27 EE 32 5E : F3 83 A3 1E D9 79 48 E6 30 0A 0B 23 D1 95 6E 51 : } : } 0 warnings, 0 errors. From nobody Thu Dec 20 03:59:48 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4EF3131054 for ; Thu, 20 Dec 2018 03:59:46 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 Jtk0V7xnTREh for ; Thu, 20 Dec 2018 03:59:44 -0800 (PST) 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 B16CE130E09 for ; Thu, 20 Dec 2018 03:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1545307183; x=1576843183; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TG6wrt5MdyeisksrBRV+T/aFMDHur+JRwrlD2J/pV44=; b=sN3pNwLNjv6aPmkM3WkC5G1+ZRzCaSOiUj3JgG7Wg4vlolfktRduDVzX BXhMHinOUaVGvbXER6i/lAOTU5DiblD4bJTU8dCARMVbt7tjNfr3FXM6x PEUv7EO6tKR55iDv25Hfi1piypC+9nBChxYfO9Zg66ww0shGu5vn7/Vy8 qzphKkQIHjC7/fSTCHYm3K5+VX7wpAW5+3In3htV9NOKYe3J/w6kRVrCw ZEqBX3OBPl9JXd7vKBN6PdT/gP81iWGMHHUgPJowiYH4SKmpf/h55JI6F V7odYJCGjMb0QQQ5Fcgkd+3GNm6nRwLOP2RPwBJf3hv45YTCgesgRGnC9 A==; X-IronPort-AV: E=Sophos;i="5.56,376,1539601200"; d="scan'208";a="43889103" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Dec 2018 00:59:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 21 Dec 2018 00:59:38 +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; Fri, 21 Dec 2018 00:59:38 +1300 From: Peter Gutmann To: "noloader@gmail.com" CC: "saag@ietf.org" Thread-Topic: [saag] draft-ietf-curdle-pkix and endianess of strings Thread-Index: AQHUlwktejkwaOTqMEys7jzWK4AzKqWEFZqAgAADAoCAAAKdAIAABL0AgAAKeACAATPAlYAAWTKAgAHRJ4I= Date: Thu, 20 Dec 2018 11:59:37 +0000 Message-ID: <1545307175261.28601@cs.auckland.ac.nz> References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz>, In-Reply-To: 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: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2018 11:59:47 -0000 Jeffrey Walton writes:=0A= =0A= >The extra "byte reverse" needed to make things work as expected is non-=0A= >intuitive and not documented. But maybe I am missing something or I don't= =0A= >understand the motivation.=0A= =0A= One fix, adopted by a significant user overseas, is to retry a failed=0A= signature verification with the bytes reversed. They'd apparently used som= e=0A= Ed25519 implementation with a Java library that emitted the standard (big-= =0A= endian) representation for the signature, and it wasn't until other=0A= implementations tried to interop that they found the two sides couldn't ver= ify=0A= each other's signatures. So the adopted solution was to verify with whatev= er=0A= they read, and if they got a failed verification, reverse the bytes and try= =0A= again.=0A= =0A= Perhaps someone should do an RFC warning implementers about the booby-trap= =0A= built into the IETF specs that use 25519, and how to work around it, e.g. b= y=0A= retrying failed signature verifications with the bytes reversed.=0A= =0A= Peter.=0A= From nobody Fri Dec 21 08:38:15 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BA1130E34 for ; Fri, 21 Dec 2018 08:37:58 -0800 (PST) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 7SzIx-LxkpS8 for ; Fri, 21 Dec 2018 08:37:57 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B60130E3C for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id k19-v6so5256099lji.11 for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) 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=tZy/9Oq8k/TSv1RPM3J+Un5oTm74yxuDKDMKPLX9l1Y=; b=kgL2+TY94loVQYIn6H/4W2h3rQIMmCcZs8BK+zgnSs7DCie3wuXfsLM1HeWDf77IEh SKnqNGkdY8gqUZF+aCtznfGY6cBLqocvttcrPT+QyRYIsSZs9E0YmCvBId4Eig11dyBO MO2TpQLWMQXo8RaMocgF2O7yntSHXqeTR/c0vQLjv0zKK2wYA3nQlmW4p+Npw8BkssQZ 97c4NTgxhe2DgbvPu0H+/4MA3BazYwXx8V1iEwucwWvL51YgpJoCmeIkvAYi2b1hCCoh +rBjhbIbyskLaZjFJisirwdKY/TJdGwdEGimncpDvHwVSdaN/+fME/GZTYxxMkukCjYl Xx3A== 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=tZy/9Oq8k/TSv1RPM3J+Un5oTm74yxuDKDMKPLX9l1Y=; b=V3g0KDYmsYqxDBO5FLorrf3eGE6Z2/hji02JYyXZZYkQ0QK59DllaQIVDWeZgucIqq H7qF8yzTsRndmIeC/OoFkR4u+KEfkIwC7JVOpYg8CuEHbyxFL7rXdEEl2SlRelf9oybW /OTWtDp1mh2yonZK84ZYQwOVj4j+l/YS6e1nNprQt5UZyKn0l7i4xKvM2K21XubMgNm8 iFd7LXuXoX2ZhglQZhF0LTs/Wp0WUGNBjX5iBUV/9+fD6E7sj8HPM6cf8QN7K7isiNQ0 OXG9meb1Ng582B+RlH2C6mJ0uiExLNDwAEthJlDzrF92HWiySir808Pn/DKljVyH6Q0p f/tw== X-Gm-Message-State: AJcUukcmyhvJO0h5pPiDQKseSbkEQEJGQX25ZnbdZqLRU66dW6DchLr8 sOoe5kBXivo6BRuEgQ7AYtfeDnqkmTw0O+h/y273kw== X-Google-Smtp-Source: ALg8bN5eXUKMLbcyIjMgSzHkzGjl/9S8XJEcmz959qlj8WNEMefMbO3/Ci3cSCGa64+Yse7JFlkPPqFPlYs9QvSxS4c= X-Received: by 2002:a2e:3218:: with SMTP id y24-v6mr2241008ljy.157.1545410274683; Fri, 21 Dec 2018 08:37:54 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Fri, 21 Dec 2018 08:37:18 -0800 Message-ID: To: "" , saag@ietf.org, IPsecME WG , SPASM Content-Type: multipart/alternative; boundary="000000000000747e33057d8ade10" Archived-At: Subject: [saag] Proposed conflict review response for draft--irtf-cfrg-gcmsiv X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 16:37:59 -0000 --000000000000747e33057d8ade10 Content-Type: text/plain; charset="UTF-8" I am shepherding the conflict review for this document. I propose to say: The IESG has concluded that this work is related to IETF work done in LAMPS, TLS, and IPSECME, but this relationship does not prevent publishing. -Ekr --000000000000747e33057d8ade10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am shepherding the conflict review for = this document. I propose to say:

The IESG has concluded that this work is related to IETF work done= in LAMPS, TLS, and IPSECME, but this relationship does not prevent publish= ing.

-Ekr

--000000000000747e33057d8ade10-- From nobody Sat Dec 22 18:03:11 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB661130DC9 for ; Sat, 22 Dec 2018 18:03:09 -0800 (PST) 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, FREEMAIL_FROM=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 (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 q3JKhlCBomfZ for ; Sat, 22 Dec 2018 18:03:07 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AF08129AB8 for ; Sat, 22 Dec 2018 18:03:07 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id v15-v6so7929578ljh.13 for ; Sat, 22 Dec 2018 18:03:07 -0800 (PST) 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=LQ2nIl5A1G2iMsupxRIwd0Qqw03xPgyj+NHHeARLGDU=; b=d2+Wzm5FxF/qBNj7XmDEe5nd3MWIl8N0Qn9f5USscrXAzq2FXE11Q53JeT8P6ZETPp 31zYydia21Fg2MKFrBaSjCkZAPupJ/RiWcHCzcOFPs4HL7flucgWbaDn0sUqjwGfAO8t 6e5lZuxQ1SKGNwfzdOe7L5nd1lD2z1hylNgsNso9Y8l2phau9kEZOIDrAO4KxYPZJwgO HhWNiJ8ngnkdKxgzpX7Ekg0YN46uw627oXWPQHpVwi2bqqxK++kbo0G+zB/NsAnLci1S PLomG1rNQsviB/GkRaBy6aFfFc7PYTpb06xs3JA2tRoHk6fQ25PUR0ov0o/mAjCjc8On dlTg== 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=LQ2nIl5A1G2iMsupxRIwd0Qqw03xPgyj+NHHeARLGDU=; b=qYK9BEMkdMBYLnze0du2+VmaLiXRGrXPNbrJB+V6RcELanAbFEgY9WOMY9INGsZXtC rNDRTyfsgfx01I+8OsLdttU0wD/yzesOlRTanHVOaof173VoIsKZGEhbqbqRH91pSjNP hltvBuFC/c7OfGHjQM9YM+/Y5RjysQtUBb0y9H8OfR7FzDiwSCrcjScoIq2Fo7/U394q UkbzddB+QuAvjKZtEBUMjfXgak5C5lpgrDu8NTQKbEzLPx2fy+dYW8c2uxIDybXU/vJs W+eUi+JssHJ+UISt9NOH1PGoCgtw4oGfRGAeS4I34mKtNYOq9Cq5TdIEm5N596wiugjG RZbg== X-Gm-Message-State: AJcUukcPB9WORg02cWjVPTZ77lLO+R30Q5rdGKI2Ue2ttw7Gxcy7M+lO Sq5ezm4g4HZrKoPadUBcf8cTqLIOGqzxSeEkd5RLpw== X-Google-Smtp-Source: ALg8bN5WyoiOY8GpiyNOs9i1yamyLOHTugRwk5WviDVSaQ+o5yrla7tIaynTPhQv5PFvJPkOLIW7KDBz3bpzBrjG4IU= X-Received: by 2002:a2e:88cf:: with SMTP id a15-v6mr4649516ljk.76.1545530585437; Sat, 22 Dec 2018 18:03:05 -0800 (PST) MIME-Version: 1.0 References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> In-Reply-To: <1545188081299.7191@cs.auckland.ac.nz> From: Watson Ladd Date: Sat, 22 Dec 2018 21:02:54 -0500 Message-ID: To: Peter Gutmann Cc: Jim Schaad , "noloader@gmail.com" , "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2018 02:03:10 -0000 On Tue, Dec 18, 2018 at 6:55 PM Peter Gutmann wrote: > > Jeffrey Walton writes: > > >You might consider adding a note that the byte array is written to the > >octet string with the LSB in the first position, and the MSB in the last > >position. As far as I know this draft is the only one that reverses the > >byte ordering for presentation. It will avoid confusion for future readers > >who expect network byte ordering in ASN.1 presentations. > > This was requested when the RFCs were written (alongside using the standard > X9.62 form that everything else uses), but nothing got done. Basically the > encoding used for the Bernstein curves is the reverse to the way everything > else does it. So you take the standard form used by all other curves, then > encode the values backwards. In my code I use a shim layer that reverses > the bytes, at which point they can be handled by code that expects them in > the standard form. Can we drop this nonsense? The point is that Bernstein specified a function from a sequence of 32 bytes cross a sequence of 32 bytes to 32 bytes. And we apply this function to the bytes, which are what goes in the format defined in the draft. Why is this so hard to understand or apparently to implement? There are even test vectors! What is the endianness of bytes that contain the bits emerging from a Huffman encoder? > > Peter. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Dec 22 18:29:00 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D237130DF4 for ; Sat, 22 Dec 2018 18:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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=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 Eg0q72_VlDja for ; Sat, 22 Dec 2018 18:28:57 -0800 (PST) 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 10AC7130DC9 for ; Sat, 22 Dec 2018 18:28:56 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id wBN2RQ0v025587; Sun, 23 Dec 2018 02:28:49 GMT 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=kMBaUVK3kufgJ5nCo1pKi43/+fAGCvvOtW+sg1VIow8=; b=ZsNQ5DZR1Df8W7/Mh2Ihfz9qejXH1Xt1zY4zJQNpLnXKOePqICPrtQQLNWKDHIBVMrCh b/MuNolkjllNO3SRQDfH3Y7GOwE8K9q0uqeP0qqeyVG5KCQxFoQmcWr6MEWmpjj1jnPJ Mz3epbTDkzsEmWejXcQh11jsEYuSIwIj8HpywNIGE+i7wpTSkntft6nuUuWRRqcP/wIy uSDsr1QBaH2yd7Dub3ngmUkGiAPnM78mw69l8JVhj5cVI9QOh85qrtsY9wArOZNBNO6z 1x0vftFJeGbznxSYuzYEO4V/uKi/n8h+98B2VsWhz32SYd0jVBkFddVedHmKVPMQdeGp Ag== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2phb7humy0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 23 Dec 2018 02:28:49 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wBN2HqZl010667; Sat, 22 Dec 2018 21:28:48 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.21]) by prod-mail-ppoint3.akamai.com with ESMTP id 2phhgg3163-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 22 Dec 2018 21:28:48 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Sat, 22 Dec 2018 20:28:47 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Sat, 22 Dec 2018 20:28:47 -0600 From: "Salz, Rich" To: Watson Ladd , Peter Gutmann CC: "saag@ietf.org" Thread-Topic: [saag] draft-ietf-curdle-pkix and endianess of strings Thread-Index: AQHUlwkm2iNqHAeIH0GYbcPdnFjsfKWFVB2AgAADAoCAAAKdAIAABL0AgAAKeACAAFnxgIAGOtwA//+zaAA= Date: Sun, 23 Dec 2018 02:28:47 +0000 Message-ID: References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.211] Content-Type: text/plain; charset="utf-8" Content-ID: <3FEEA12485769A4FB0FF859B472B3D2A@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-23_02:, , 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=955 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812230017 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-23_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=950 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812230018 Archived-At: Subject: Re: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2018 02:28:59 -0000 ICAgID4gVGhpcyB3YXMgcmVxdWVzdGVkIHdoZW4gdGhlIFJGQ3Mgd2VyZSB3cml0dGVuIChhbG9u Z3NpZGUgdXNpbmcgdGhlIHN0YW5kYXJkDQogICAgPiBYOS42MiBmb3JtIHRoYXQgZXZlcnl0aGlu ZyBlbHNlIHVzZXMpLCBidXQgbm90aGluZyBnb3QgZG9uZS4NCg0KVGhhdCdzIG5vdCBxdWl0ZSBh Y2N1cmF0ZS4gVGhlIGlzc3VlIHdhcyBicm91Z2h0IHVwIGFuZCBkaXNjdXNzZWQsIGFuZCB0aGUg Q0ZSRyBkZWNpZGVkIHRvIG5vdCBkbyB0aGlzLg0KIA0KDQo= From nobody Tue Dec 25 19:59:05 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1385A12D4F2 for ; Tue, 25 Dec 2018 19:59:04 -0800 (PST) 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_MED=-0.001, 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 (2048-bit key) header.d=nightwatchcybersecurity-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 HdcjbpCx5NVP for ; Tue, 25 Dec 2018 19:58:59 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C577129BBF for ; Tue, 25 Dec 2018 19:58:59 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id a14so7049601plm.12 for ; Tue, 25 Dec 2018 19:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rWtAb7b/zb5SAEdJKP2e6vR3/daGkIWrCcvuLouZoAw=; b=T9AW38mgyPaJtSCeaHDsOHDDfF877mDh+139KWPFGrVDWOlfsbsHYnsciaFd68fqfq bHz7Cox/RVff/WC9PCmufTKqwh4k6Y1hnVNbO8gD9JISy3wyRq3DTZUc2JBkNGatbgJB TfOeCiqgPa+63O/f6dYOslbx/A4fiWV5veGHka2LHUObTrJgOYEeD5yD6wctL+wt925A WMI53XlrCY+/iSrBM4e29SzoYDgu2ewe5XEslJwhTu4EosFtp44OVmD2cHDk/ClnJFka 4d7Ho1MgQh3pPF2i1YaRFo+Z53rNbq9DHcUOfSZwqOuI+tWx8aZcbI63zEHPde6TPHmQ 7VGQ== 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=rWtAb7b/zb5SAEdJKP2e6vR3/daGkIWrCcvuLouZoAw=; b=kpg4g2IGsWOWPqLLAZqxOLWyzY9fggxWVI5iKfKW1UqNj07u39YnYnO+xW7N+UmqSB 1V1McPSLUx6EUquxzkWMep7menkEN6ErsLid1E273oFKpykmXGH9gerNYJCOmmd09HJX EsHdetaMD62Ohs/i9D4ynrYwGxPhfRzKcGaanlkzItvubx6olIP0PS0uEp/nqcB9QAXo Y9RRMC5CMKsN73bqUeztUuzfiVkPeaEpDWTvtzORoy7DXprlSSvmTDo+/3b+YliAklgq q6UTpzJV9T+n8gz94u4BlhT42fSjeWbNbNQIq3qGXT2BatRK7rFAM8gcRcsswo4LiqlI +IdA== X-Gm-Message-State: AJcUukelWNYtbwkOuGVlciydAyrrhUsRGJvjE1aULAfHmt3drOaHn7SP FYe7oF6AGWgGBZ/rF0iQdYg7woNBbJoTnVONX2A+MFzVcUROXQ== X-Google-Smtp-Source: ALg8bN4sVuYI2Jn7L+4gBSzQNIQ1FBoO1rPmklL+H3ppqWB5bYpgdZA4Jbd2iebh6dJnhRztdA/BndMhjdRV9XQKqAQ= X-Received: by 2002:a17:902:20c8:: with SMTP id v8mr18628204plg.319.1545796738593; Tue, 25 Dec 2018 19:58:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yakov Shafranovich Date: Tue, 25 Dec 2018 22:58:22 -0500 Message-ID: To: Mark O Cc: "saag@ietf.org" , Ed Overflow Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 03:59:04 -0000 (Apologies on my delayed reply) > I would like to see draft-foudil-securitytxt progress and support its pub= lication in an amended format. > > On balance this draft will help to improve the reporting and correction o= f vulnerabilities on servers and improve security for users and operators o= f servers. I recognise that there are some valid concerns over authenticati= on of security.txt, particularly when the server has been compromised. In t= hat scenario, it will not be possible to trust the information provided in = security.txt. These concerns can be partially mitigated by using a secure t= ransmission method such as TLS (v1.2 or v1.3). This improves the security a= round provisioning security.txt and, although this is an imperfect solution= , I believe that overall the benefit to be gained from easier reporting of = vulnerabilities outweighs the potential danger of incorrect information bei= ng provided by a malicious security.txt on a compromised server. When secur= ity.txt is used to find the reporting details for a vulnerability in a prod= uct produced by a vendor, rather than in the server itself, we can assume t= hat the contents of the security.txt can be trusted and therefore there is = no danger in using security.txt. > > NCSC is keen to promote the usage of security.txt on UK public sector web= servers as a method of providing contact information for responsible discl= osure of vulnerabilities. NCSC would incorporate usage of security.txt into= its "Web Check" service, a website configuration and vulnerability scannin= g service available to all UK public sector organisations. > Your support is appreciated > > I would like to see a change to the draft that mandates the use of a secu= re transmission method for security.txt. In practice this will mean the use= of HTTPS over TLS or in future HTTPS over QUIC (HTTP/3). So Section 3.1 ("= Scope") should state that security.txt MUST only be served over HTTPS (and = the examples given using 'http://' should be removed from the text). Protec= ting the whole website using TLS is good practice and provides a level of a= ssurance that the contents of the file have not been tampered with, either = at rest on the server or in flight by a network adversary. There is a resid= ual risk that the server has been compromised and therefore that the conten= ts of the file are malicious; this is recorded in the "Security Considerati= ons" section. This residual risk can be reduced through the use of a digita= l signature on security.txt (e.g.. using PGP) or by recording contact detai= ls in DNS records, but these solutions also bring complications (root of tr= ust for PGP key? can DNS data also be compromised?) therefore mandating a p= articular additional authentication appears to be counter-productive and wo= uld hinder adoption of an otherwise simple RFC. > A similar point has been raised by our document shepherd (Kathleen Moriarty) and as per her suggestion we changed all of the "http://" examples in the draft to "https://" as well as changed the language to read "RECOMMENDED" in regards to HTTPS. Based on our discussion it felt that using MUST may be unrealistic in the real world. These changes have been made in the GitHub version but not yet published - they will go into the -05 version: https://github.com/securitytxt/security-txt/blob/master/draft-foudil-securi= tytxt.txt > > I would additionally propose that, where the 'Contact:' directive is used= to specify an email address using the 'mailto:' syntax, then it is necessa= ry to also specify an encryption public key (via the 'Encryption:' directiv= e) for protection of email messages sent to that contact address. So Sectio= n 3.4.3 should specify that the Encryption: directive MUST be used when the= content of the Contact: directive is an email address. The specification c= annot mandate that security researchers use encryption on email sent to thi= s address - that would be out of scope - but an encryption key must at leas= t be available. In practice this will mean a PGP public key is published on= the web server or a separate key server, but security.txt should not manda= te the format or the contents of the public key file. > I am opening an issue on GitHub to track this: https://github.com/securitytxt/security-txt/issues/134 Similar to the point above regarding TLS support, I am not sure if MUST would work. Do you think RECOMMENDED or a SHOULD would be sufficient here? Regarding the key format, several implementers have reached out and asked for clarification. The context is that people want to build automation around the parsing of these files and feel like knowing the format of the key is useful. We have been considering a possibility of explicitly spelling out PGP as the default key format and adding an optional field to indicate a non-PGP format, or perhaps leaving this field for the future to be added to the IANA registry if it becomes needed. > > Some specific review comments on the -04 draft: > > * Replace "companies" by "organisations" throughout. > * Section 3, replace "alway" by "always" > > * Section 3.4.2, replace "it MUST be begin" by =E2=80=9Cit MUST begin=E2= =80=9D > > * Section 3.4.3, replace "it MUST be begin" by =E2=80=9Cit MUST begin=E2= =80=9D > > * Section 3.4.4, replace "it SHOULD be begin" by =E2=80=9Cit SHOULD begin= =E2=80=9D > I am filing an issue to track this and will review: https://github.com/securitytxt/security-txt/issues/135 > > Some further comments on Paul Wouters' outstanding concerns in-line below= . > > On Thu, 23 Aug 2018 15:16:07, Paul Wouters wrote: > > On 07/16/2018 04:32 PM, Yakov Shafranovich wrote: [snip] > > > > > All my existing concerns still applies and it might even be worse now. > > Section 3.4.1 basically suggests building a list of fixed vulnerabiliti= es with the > > acknowledgments section. So now hackers can scan for which servers have= n't > > been patched for something. Especially valuable if 9 out of 10 servers = in the > > company have some acknowledgment but one of these does not. > > The amount of detail included on the security acknowledgments page is ent= irely at the discretion of the server's administrator; security.txt does no= t mandate that specific vulnerabilities are disclosed. It is obviously unde= sirable to include information on the security acknowledgments page that wo= uld lead an attacker to scan for a particular vulnerability or try a partic= ular attack. > Perhaps adding language explicitly spelling this out would help as well? > > > And this advise does not belong in an IETF document: > > > If this directive indicates a web URL, then it MUST be begin wi= th > > "https://=E2=80=9D > > > with the entire world being https, this gives a false sense of security= . The > > paragraphs also forms a nice Inception loop. What is the host that is h= osting > > the security key itself publishes a security.txt file. And why does it = even matter > > in the first place if it is http or https, unless the person who found > > the compromised website themselves are compromised? > > Would it be better to point to best current practice on the use of TLS fo= r securing servers, e.g. RFC 7525? HTTPS still brings benefits over HTTP be= cause an unauthenticated connection could be subject to a man-in-the-middle= attack to serve a fake version of security.txt, even without compromising = the server. > > NCSC has published an article on why HTTPS matters: > https://www.ncsc.gov.uk/blog-post/serve-websites-over-https-always > > Google also have a good article on the same topic: > https://developers.google.com/web/fundamentals/security/encrypt-in-transi= t/why-https > As per my comment above, the language in the upcoming -05 draft has been changed to "RECOMMENDED". I think we can also add some of these concerns to the security concerns section in the draft. > > > 3.4.4 Hiring ? > > > What are we now. a new Linked In protocol extension ? > > This is one way of building trust and a sense of community with vulnerabi= lity researchers to encourage responsible disclosure, but its presence in t= his specification should be entirely optional. > The only required field in the file is "Contact", all other files including this one are optional. Additionally, as per the IANA registry being defined with this draft, if this particular directive proves harmful or ends up not being used, it can demoted to "deprecated" or "historic" status. As per my original comments, this field is being used by those implementing "security.txt" and we are documenting existing usage. > > > 3.4.7 signature file > > > I have no idea why it has to be external and not inline, which is the t= ypical > > PGP/GPG way > > This document should not mandate any particular format for a signature, i= ncluding whether it is inline or external. > There has been ongoing discussion around this piece, especially since several parties want guidance on parsing. Additionally, the way the ABNF grammar is defined now it doesn't account for inline signatures. At this point, the feedback we got seems to indicate that support for both inline and detached signatures is useful, plus mandating the presence of the detached signature file to be always in the same location. From nobody Thu Dec 27 18:58:59 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496DD130F43 for ; Thu, 27 Dec 2018 18:58:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] 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 YvGNhkqNjpqv for ; Thu, 27 Dec 2018 18:58:54 -0800 (PST) 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 4EBDC130F40 for ; Thu, 27 Dec 2018 18:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1545965934; x=1577501934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RJ8MwkCg7fR4S8QeozWHGLgVkBYXjMDfF4XVC3weACE=; b=TUApJNR4ghhrqZOj09fl4KHF6z4HPrdp+TCgRrYJUbqM/W8EV91Jtm7s tTH391QjM9dC0NCZa0ZMpe6nVW84ETfFBmqP1osLJ0nvQDQjcA5XxWqI3 w2edUIVIZiOwSBcEki4Wssh6hSBX4FOgTYsJ7WQmuQKyOhOhyWT5FQusH +m1jM1mTmuJSWAP+KbO4Ga0Ealzof27av0OOSnDgWbxUJiW7o0Vh14Oim 6/RWWDyUmx+BVwFfLBcC57S2LOil1ScQxDIitPLdFtWsp+s8rkKAXCP80 uDL/1lTdyLaykYtbqbLe75JK+XDybdhsjpgA5oqTe+pjApi2HpRCpDZrU g==; X-IronPort-AV: E=Sophos;i="5.56,407,1539601200"; d="scan'208";a="44355096" 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; 28 Dec 2018 15:58:46 +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; Fri, 28 Dec 2018 15:58:46 +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; Fri, 28 Dec 2018 15:58:46 +1300 From: Peter Gutmann To: Watson Ladd CC: "saag@ietf.org" Thread-Topic: [saag] draft-ietf-curdle-pkix and endianess of strings Thread-Index: AQHUlwktejkwaOTqMEys7jzWK4AzKqWEFZqAgAADAoCAAAKdAIAABL0AgAAKeACAATPAlYAFYQ0AgAjErnE= Date: Fri, 28 Dec 2018 02:58:45 +0000 Message-ID: <1545965918077.61224@cs.auckland.ac.nz> References: <027c01d4970e$cefd4c70$6cf7e550$@augustcellars.com> <028f01d49713$fd6a4540$f83ecfc0$@augustcellars.com> <1545188081299.7191@cs.auckland.ac.nz>, In-Reply-To: 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: [saag] draft-ietf-curdle-pkix and endianess of strings X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Dec 2018 02:58:57 -0000 Watson Ladd writes:=0A= =0A= >The point is that Bernstein specified a function from a sequence of 32 byt= es=0A= >cross a sequence of 32 bytes to 32 bytes. And we apply this function to th= e=0A= >bytes, which are what goes in the format defined in the draft. =0A= =0A= So does ECDSA, and presumably every other ECC. The difference is that all = of=0A= them except the Bernstein ones use a standardised encoding that's been arou= nd=0A= for 20-odd years. The Bernstein ones encode the same values backwards to w= hat=0A= the near-universal usage has been.=0A= =0A= >Why is this so hard to understand or apparently to implement? =0A= =0A= It's not hard to understand, the problem is that you now need to implement = a=0A= special-snowflake version of every function and mechanism that uses the=0A= Bernstein curves with their backwards encoding of the parameters. So=0A= everywhere where you formerly had:=0A= =0A= read ECC parameters;=0A= use ECC parameters;=0A= =0A= you now need to have:=0A= =0A= if( special-snowflake-curve )=0A= reverse data in parameters;=0A= read ECC parameters;=0A= use ECC parameters;=0A= =0A= And, as a previous poster pointed out, you need even more special-snowflake= =0A= handling when some parts of the ECC values are in standard form and other= =0A= parts are backwards (big- vs. little-endian).=0A= =0A= Peter.=0A= From nobody Mon Dec 31 08:55:33 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71831130E7D for ; Mon, 31 Dec 2018 08:55:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyi47OSdLPEl for ; Mon, 31 Dec 2018 08:55:29 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100107.outbound.protection.outlook.com [40.107.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26012130E7B for ; Mon, 31 Dec 2018 08:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sV1dcUeL4ZWu50XSMG06SP5EC1IkdUrR7neOpDIgqJA=; b=LODZ4NvDof8dTHYVLUB53DfX5y4dZq8yEbF6Q7egXnY28p47LYSE3IlC6+HjikB25oXsuO2bLJM5iElgUA1GINOPp/ws79ek26VnKZwF2Rcsb+nOEVtrV64KMx0aDK7RxKq6jsIKra6AuzGA7W7dlCi/+uuoLI6l443bgK07Mio= Received: from LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM (10.166.255.18) by LOXP123MB0888.GBRP123.PROD.OUTLOOK.COM (10.166.250.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.20; Mon, 31 Dec 2018 16:55:25 +0000 Received: from LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM ([fe80::b92d:c4f0:12e1:189d]) by LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM ([fe80::b92d:c4f0:12e1:189d%2]) with mapi id 15.20.1471.019; Mon, 31 Dec 2018 16:55:25 +0000 From: Mark O To: "saag@ietf.org" Thread-Topic: [saag] Comments on draft-foudil-securitytxt-04 Thread-Index: AdSXmuqMkZbdVjQnQ92VKibJ8bVUvgFNFPcAARWKmxA= Date: Mon, 31 Dec 2018 16:55:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mark.O@ncsc.gov.uk; x-originating-ip: [51.141.26.231] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LOXP123MB0888; 6:1qwvmEa5yZXLfi2/4NnyrFULThlmdMTZpRMHY5sDh9nFJl0tyz+iU+lw4zNuvW/7K7aiPCD8riR802pDU78I4kKSRv8UQT+/Ws620mVFdWEyoX/X2f7nf+tFxNo2rfg9e84vMk6AFvZseJbI+mpdieJYUIkVvO7Q+nly3PzSpvUSmCHBTyshF4P0bdavStLHjm5aHk01qi6qdyn6BikzGGbgL1ArrxL/wh4fbocwxbRnwzQtBmMSXBmnDMWOKFOGa1IWMet3Kt9hpVCV+MyMltY+Doj5/rFv4lipsKoRbLey7IpIz7f6NNT5glDLKZ/prPuquKnPa6/evmofP6xq9K2a3LnFqCqpF45wNs7a/nVTvkPUG2CHI/wjNdzXPA844TACFgaRlwDNcv85c8ctN99CTwBRRor1EHnxvNqkGk5jd4SaaYGKlWH4/aN1Ig/DK17aUhmsasTWJoTkKXLqsg==; 5:su5ISwOpv9iuYcg5FgbHbEyPEUsBKHldAsgFLFDKrzh88tyM929q0y9lc9uk+1N1dPW92w+xaY1KcccnYfBQ9yPNYvBeUwUsPyShhGeKillu+Idc4rViqh2WBuUOFz71j3dL3DOx7po8+1wMa4tOKaMcn+Lf9NiTg/SjNTaW0t0=; 7:oGcNpYk5gZYQoZIR1kHE3H7ZEb8csbcSLSy954EbJVgTLFUYWvNd8jOD30j+yrBMgPZ9DfKaFe9vYBGyRWlA7uU6UHsIIti0lDn6s7MwOcmAn74XUsYR/qX7UHs76a12h0NSoTva6dKdJhMRUNbMvw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5fafc32e-397b-4a8a-d84d-08d66f40c2a4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7153060)(7193020); SRVR:LOXP123MB0888; x-ms-traffictypediagnostic: LOXP123MB0888: x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(908002)(999002)(5005026)(6040522)(8220055)(2401047)(8121501046)(3002001)(10201501046)(3231475)(944501520)(4982022)(52105112)(93006095)(93001095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:LOXP123MB0888; BCL:0; PCL:0; RULEID:; SRVR:LOXP123MB0888; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(376002)(396003)(346002)(39840400004)(189003)(199004)(14444005)(305945005)(256004)(229853002)(33656002)(74482002)(68736007)(102836004)(25786009)(15650500001)(6246003)(55236004)(74316002)(6916009)(105586002)(10710500007)(72206003)(75922002)(99286004)(5660300001)(6506007)(53936002)(71190400001)(2420400007)(7736002)(26005)(71200400001)(2351001)(14454004)(186003)(97736004)(478600001)(86362001)(7110500001)(76176011)(9686003)(3846002)(81166006)(1730700003)(476003)(6436002)(446003)(55016002)(11346002)(316002)(8936002)(8676002)(6306002)(7696005)(106356001)(6116002)(486006)(66066001)(81156014)(2906002)(66574012)(2501003)(5640700003); DIR:OUT; SFP:1102; SCL:1; SRVR:LOXP123MB0888; H:LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ols4MP/ECzt2HFAtOINihErBk2Oyob+b36yZsxzhNqkKUA/65I2GthvsvPCh3DvJeH61rir9LwCOQW6rANFQaLunGozRJ9pQpXVWIdszhLCjCmHgcaOVPkSU11SBGQGKr9imR9D3iuf4R8owYT8dpiyMvvu6N0k4kPl4Itza5SqLmSm9g2sJTY4oqjivj0XFk8tcwm3fKfPkLdgpNxjLZZIJaD46DjkcQlmspmoaHiR15Ju1G7ZYPscbZFTf4SWJrDOdPWcSWmdgI+qjCEioOhDJu2Xl0L/ODzMESTvlCVSHzk5G53s7G8/0w78uKhwE spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 5fafc32e-397b-4a8a-d84d-08d66f40c2a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2018 16:55:25.1958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP123MB0888 Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 16:55:32 -0000 DQo+IEEgc2ltaWxhciBwb2ludCBoYXMgYmVlbiByYWlzZWQgYnkgb3VyIGRvY3VtZW50IHNoZXBo ZXJkIChLYXRobGVlbiBNb3JpYXJ0eSkgYW5kIGFzIHBlciBoZXIgc3VnZ2VzdGlvbiB3ZSBjaGFu Z2VkIGFsbCBvZiB0aGUgImh0dHA6Ly8iIGV4YW1wbGVzIGluIHRoZSBkcmFmdCB0byAiaHR0cHM6 Ly8iIGFzIHdlbGwgYXMgY2hhbmdlZCB0aGUgbGFuZ3VhZ2UgdG8gcmVhZCAiUkVDT01NRU5ERUQi IGluIHJlZ2FyZHMgdG8gSFRUUFMuIEJhc2VkIG9uIG91ciBkaXNjdXNzaW9uIGl0IGZlbHQgdGhh dCB1c2luZyBNVVNUIG1heSBiZSB1bnJlYWxpc3RpYyBpbiB0aGUgcmVhbCB3b3JsZC4gVGhlc2Ug Y2hhbmdlcyBoYXZlIGJlZW4gbWFkZSBpbiB0aGUgR2l0SHViIHZlcnNpb24gYnV0IG5vdCB5ZXQg cHVibGlzaGVkIC0gdGhleSB3aWxsIGdvIGludG8gdGhlIC0wNSB2ZXJzaW9uDQoNClRoYW5rcyBm b3IgcG9pbnRpbmcgbWUgdG8gdGhlIC0wNSBkcmFmdC4gV2Ugd291bGQgc3Ryb25nbHkgcHJlZmVy IHRoYXQgSFRUUFMgJ01VU1QnIGJlIHVzZWQgYXMgdGhpcyB0aWVzIGluIHdpdGggdGhlIGFkdmlj ZSB3ZSBvZmZlciB0byBhZG1pbmlzdHJhdG9ycyBvZiBwdWJsaWMgc2VjdG9yIHdlYnNpdGVzLCBo b3dldmVyLCAnUkVDT01NRU5ERUQnIHdvdWxkIG5vdCBwcmV2ZW50IHVzIHVzaW5nIHNlY3VyaXR5 LnR4dC4NCg0KPiA+IEkgd291bGQgYWRkaXRpb25hbGx5IHByb3Bvc2UgdGhhdCwgd2hlcmUgdGhl ICdDb250YWN0OicgZGlyZWN0aXZlIGlzIHVzZWQgdG8gc3BlY2lmeSBhbiBlbWFpbCBhZGRyZXNz IHVzaW5nIHRoZSAnbWFpbHRvOicgc3ludGF4LCB0aGVuIGl0IGlzIG5lY2Vzc2FyeSB0byBhbHNv IHNwZWNpZnkgYW4gZW5jcnlwdGlvbiBwdWJsaWMga2V5ICh2aWEgdGhlICdFbmNyeXB0aW9uOicg ZGlyZWN0aXZlKSBmb3IgcHJvdGVjdGlvbiBvZiBlbWFpbCBtZXNzYWdlcyBzZW50IHRvIHRoYXQg Y29udGFjdCBhZGRyZXNzLiBTbyBTZWN0aW9uIDMuNC4zIHNob3VsZCBzcGVjaWZ5IHRoYXQgdGhl IEVuY3J5cHRpb246IGRpcmVjdGl2ZSBNVVNUIGJlIHVzZWQgd2hlbiB0aGUgY29udGVudCBvZiB0 aGUgQ29udGFjdDogZGlyZWN0aXZlIGlzIGFuIGVtYWlsIGFkZHJlc3MuIFRoZSBzcGVjaWZpY2F0 aW9uIGNhbm5vdCBtYW5kYXRlIHRoYXQgc2VjdXJpdHkgcmVzZWFyY2hlcnMgdXNlIGVuY3J5cHRp b24gb24gZW1haWwgc2VudCB0byB0aGlzIGFkZHJlc3MgLSB0aGF0IHdvdWxkIGJlIG91dCBvZiBz Y29wZSAtIGJ1dCBhbiBlbmNyeXB0aW9uIGtleSBtdXN0IGF0IGxlYXN0IGJlIGF2YWlsYWJsZS4g SW4gcHJhY3RpY2UgdGhpcyB3aWxsIG1lYW4gYSBQR1AgcHVibGljIGtleSBpcyBwdWJsaXNoZWQg b24gdGhlIHdlYiBzZXJ2ZXIgb3IgYSBzZXBhcmF0ZSBrZXkgc2VydmVyLCBidXQgc2VjdXJpdHku dHh0IHNob3VsZCBub3QgbWFuZGF0ZSB0aGUgZm9ybWF0IG9yIHRoZSBjb250ZW50cyBvZiB0aGUg cHVibGljIGtleSBmaWxlLg0KPiBTaW1pbGFyIHRvIHRoZSBwb2ludCBhYm92ZSByZWdhcmRpbmcg VExTIHN1cHBvcnQsIEkgYW0gbm90IHN1cmUgaWYgTVVTVCB3b3VsZCB3b3JrLiBEbyB5b3UgdGhp bmsgUkVDT01NRU5ERUQgb3IgYSBTSE9VTEQgd291bGQgYmUgc3VmZmljaWVudCBoZXJlPw0KDQpW dWxuZXJhYmlsaXR5IHJlc2VhcmNoZXJzIG5lZWQgdG8gaGF2ZSBhIHNlY3VyZSBtZXRob2Qgb2Yg Y29tbXVuaWNhdGluZyB3aXRoIHRoZSBjb250YWN0IHNwZWNpZmllZCBpbiBzZWN1cml0eS50eHQs IGFuZCB1bmVuY3J5cHRlZCBlLW1haWwgY2Fubm90IGJlIHJlZ2FyZGVkIGFzIHNlY3VyZS4gQSBj b250YWN0IHRlbGVwaG9uZSBudW1iZXIgd291bGQgYmUgYmV0dGVyIHRoYW4gdW5lbmNyeXB0ZWQg ZS1tYWlsLiBJZiBhIHB1YmxpYyBrZXkgaXMgbm90IG1hbmRhdGVkIGhlcmUsIHRoZW4gSSBleHBl Y3QgaW4gcHJhY3RpY2UgaXQgd2lsbCBub3QgYmUgc3VwcGxpZWQgYW5kIG9ubHkgYW4gaW5zZWN1 cmUgZS1tYWlsIGFkZHJlc3Mgd2lsbCBiZSBnaXZlbi4gVGhpcyBsZWF2ZXMgdGhlIHZ1bG5lcmFi aWxpdHkgcmVzZWFyY2hlciBubyBvcHRpb24gYnV0IHRvIHNlbmQgdW5lbmNyeXB0ZWQsIGluc2Vj dXJlIGUtbWFpbC4NCkhvdyBhYm91dCwgc3BlY2lmeWluZyB0aGF0IGF0IGxlYXN0IG9uZSAqc2Vj dXJlKiBDb250YWN0IGFkZHJlc3MgTVVTVCBiZSBwcm92aWRlZCwgd2hpY2ggY291bGQgYmUgYW4g ZS1tYWlsIGFkZHJlc3Mgd2l0aCBjb3JyZXNwb25kaW5nIHB1YmxpYyBrZXksIGEgVVJMIGZvciBh IHdlYiBmb3JtIHNlcnZlZCBvdmVyIEhUVFBTLCBhIHRlbGVwaG9uZSBudW1iZXIsIGEgcG9zdGFs IGFkZHJlc3MsIGFuIGluc3RhbnQgbWVzc2VuZ2VyIGFjY291bnQuLi4gYnV0IGFsc28gYmVpbmcg ZXhwbGljaXQgdGhhdCB1bmVuY3J5cHRlZCBlLW1haWwgaXMgbm90IGNvbnNpZGVyZWQgc2VjdXJl IGFuZCB0aGVyZWZvcmUgbXVzdCBub3QgYmUgdGhlIG9ubHkgY29udGFjdCBtZXRob2QgbGlzdGVk Lg0KDQo+IFJlZ2FyZGluZyB0aGUga2V5IGZvcm1hdCwgc2V2ZXJhbCBpbXBsZW1lbnRlcnMgaGF2 ZSByZWFjaGVkIG91dCBhbmQgYXNrZWQgZm9yIGNsYXJpZmljYXRpb24uIFRoZSBjb250ZXh0IGlz IHRoYXQgcGVvcGxlIHdhbnQgdG8gYnVpbGQgYXV0b21hdGlvbiBhcm91bmQgdGhlIHBhcnNpbmcg b2YgdGhlc2UgZmlsZXMgYW5kIGZlZWwgbGlrZSBrbm93aW5nIHRoZSBmb3JtYXQgb2YgdGhlIGtl eSBpcyB1c2VmdWwuDQoNCkkgZmVlbCB0aGF0IGJlaW5nIHByZXNjcmlwdGl2ZSBhYm91dCBhIGtl eSBmb3JtYXQgKGFsc28gYSBzaWduYXR1cmUgZm9ybWF0KSBjb3VsZCBiZWNvbWUgYSBiYXJyaWVy IHRvIGFkb3B0aW9uLiBGdXJ0aGVybW9yZSBJIHdvdWxkIGhhdmUgdGhvdWdodCB0aGF0IHRoZSB1 c2UtY2FzZSBmb3IgYXV0b21hdGVkIHBhcnNpbmcgb2Ygc2VjdXJpdHkudHh0IHdvdWxkIGJlIHZl cnkgbGltaXRlZCAtIGluIG1vc3QgY2FzZXMsIEkgZXhwZWN0IHRoZSB3YXkgdGhhdCB0aGlzIGZp bGUgd2lsbCBiZSB1c2VkIGlzIHRoYXQgYSByZXNlYXJjaGVyIHdpbGwgZmluZCBhIHZ1bG5lcmFi aWxpdHkgYW5kIHRoZW4gY2hlY2sgZm9yIHRoZSBleGlzdGVuY2Ugb2YgYSBzZWN1cml0eS50eHQg ZmlsZSB0byBmaW5kIHRoZSBjb250YWN0IGRldGFpbHMgb2Ygd2hvIHRvIHJlcG9ydCBpdCB0byAt IGkuZS4gYSB2ZXJ5IG1hbnVhbCwgbm9uLWF1dG9tYXRlZCBwcm9jZXNzLiBXZSB3YW50IHRvIG1h a2UgaXQgYXMgZWFzeSBhcyBwb3NzaWJsZSB0byBwdWJsaXNoIGEgc2VjdXJpdHkudHh0IGZpbGUs IG5vdCB0byBzY3JhcGUgdGhlbSBmb3IgZGV0YWlscy4NCg0KPiA+IFRoZSBhbW91bnQgb2YgZGV0 YWlsIGluY2x1ZGVkIG9uIHRoZSBzZWN1cml0eSBhY2tub3dsZWRnbWVudHMgcGFnZSBpcyBlbnRp cmVseSBhdCB0aGUgZGlzY3JldGlvbiBvZiB0aGUgc2VydmVyJ3MgYWRtaW5pc3RyYXRvcjsgc2Vj dXJpdHkudHh0IGRvZXMgbm90IG1hbmRhdGUgdGhhdCBzcGVjaWZpYyB2dWxuZXJhYmlsaXRpZXMg YXJlIGRpc2Nsb3NlZC4gSXQgaXMgb2J2aW91c2x5IHVuZGVzaXJhYmxlIHRvIGluY2x1ZGUgaW5m b3JtYXRpb24gb24gdGhlIHNlY3VyaXR5IGFja25vd2xlZGdtZW50cyBwYWdlIHRoYXQgd291bGQg bGVhZCBhbiBhdHRhY2tlciB0byBzY2FuIGZvciBhIHBhcnRpY3VsYXIgdnVsbmVyYWJpbGl0eSBv ciB0cnkgYSBwYXJ0aWN1bGFyIGF0dGFjay4NCj4gUGVyaGFwcyBhZGRpbmcgbGFuZ3VhZ2UgZXhw bGljaXRseSBzcGVsbGluZyB0aGlzIG91dCB3b3VsZCBoZWxwIGFzIHdlbGw/DQpZZXMsIGl0J3Mg cHJvYmFibHkgbmVjZXNzYXJ5IHRvIGV4cGxpY2l0bHkgcG9pbnQgdGhpcyBvdXQuDQoNCg0KLS0g TWFyaw0KDQoNCg0KVGhpcyBpbmZvcm1hdGlvbiBpcyBleGVtcHQgdW5kZXIgdGhlIEZyZWVkb20g b2YgSW5mb3JtYXRpb24gQWN0IDIwMDAgKEZPSUEpIGFuZCBtYXkgYmUgZXhlbXB0IHVuZGVyIG90 aGVyIFVLIGluZm9ybWF0aW9uIGxlZ2lzbGF0aW9uLiBSZWZlciBhbnkgRk9JQSBxdWVyaWVzIHRv IG5jc2NpbmZvbGVnQG5jc2MuZ292LnVrDQo= From nobody Mon Dec 31 12:05:13 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304F9128D09 for ; Mon, 31 Dec 2018 12:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAEpZYmHfkjy for ; Mon, 31 Dec 2018 12:05:11 -0800 (PST) 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 75178126C7E for ; Mon, 31 Dec 2018 12:05:11 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBVJuiAD010790; Mon, 31 Dec 2018 20:05:08 GMT 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=/HDO4gyJIgcly/VFNwdz+jb8mS+TS83R3OclMJ0LKNc=; b=e+rKW18tPeFE96c9c3OuSQJ7Htv3gZAdBas62SmHd2dAwF59yvvnWmMRdZdnDFGoSkFz oVymcpDTyabm8F+m0e2s9EvycW41BeuhJ4SBnJ3yBQSONnWuczfQr5w+5W6/oGgFvnS2 SGfJqTHB2cOT1Q2nRmwyJbtoHu0JqcppXP599shl7K+b4WHg04S0dnksnyvt8dyPTxUW UTcocINx6YqjlkfIgK3X5CpkQbL53VBiZdWwC3Rzd0Cv0seEpOj3xAugtaxx7TcanYhg VmGUdcvIabIqrrrfoUyR1H6w0SoYWfvzB7EwZmwlBDxiD0Pcjv46KHWsr9nkPIz5Uk3D FQ== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2pp1exyft0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Dec 2018 20:05:08 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id wBVK2Rh5020727; Mon, 31 Dec 2018 15:05:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint4.akamai.com with ESMTP id 2pp551r64a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Dec 2018 15:05:07 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 31 Dec 2018 12:05:06 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Mon, 31 Dec 2018 14:05:06 -0600 From: "Salz, Rich" To: Mark O , "saag@ietf.org" Thread-Topic: [saag] Comments on draft-foudil-securitytxt-04 Thread-Index: AdSXmuqMkZbdVjQnQ92VKibJ8bVUvgFZp54AARaYY4D//+EsgA== Date: Mon, 31 Dec 2018 20:05:06 +0000 Message-ID: <48E913F3-59C7-4ED3-B742-CDE033453FBB@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.14.0.181208 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.88] Content-Type: text/plain; charset="utf-8" Content-ID: <65E2EFE80CD0E047BDF544388C9C9D61@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-31_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=888 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812310173 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-31_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=896 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812310173 Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 20:05:12 -0000 SSB0aGluayBpdCBpcyBzaWxseSB0byBoYXZlIGFuIGF1dG9tYXRlZCBzZWN1cml0eS50eHQgdGhh dCBkb2Vzbid0IGhhdmUgVExTLg0KDQoNCg== From nobody Mon Dec 31 12:23:10 2018 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDF1126C7E for ; Mon, 31 Dec 2018 12:23:08 -0800 (PST) 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 35Fm0Mtxnw19 for ; Mon, 31 Dec 2018 12:23:07 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E3F128CF3 for ; Mon, 31 Dec 2018 12:23:07 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1ge45X-0008Kr-HU; Mon, 31 Dec 2018 20:23:03 +0000 Date: Mon, 31 Dec 2018 12:23:03 -0800 Message-ID: From: Randy Bush To: "Salz, Rich" Cc: Mark O , "saag@ietf.org" In-Reply-To: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> References: <48E913F3-59C7-4ED3-B742-CDE033453FBB@akamai.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] Comments on draft-foudil-securitytxt-04 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2018 20:23:08 -0000 > I think it is silly to have an automated security.txt that doesn't > have TLS. agree, but i lost that discussion a year ago. i decided to just not take this docco seriously.