From nobody Mon Aug 1 08:31:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC53212DC7A for ; Mon, 1 Aug 2016 08:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S25pyrrJbMgu for ; Mon, 1 Aug 2016 08:31:23 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0100.outbound.protection.outlook.com [23.103.200.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303DA12DC82 for ; Mon, 1 Aug 2016 08:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=smhbp/VnDL1neSoGfdBZcVuOT5TUe9HQigpQpqQBa10=; b=PLk3zaUcCWKG+iAhHralFd/+ivtSZQae+2vS3fOYY+KPl4LcKe/mCqakabOwbPBs1Js/syKj40ft6cHis2CXS19FfCkDKhpkL9/LEnRhLS0draQOQ9oRSWVnHtBhehbUb5czg99uIeB3nkw5gYZUYlOn+UxdJ9GucqI8ONbdgn0= Received: from CY4PR09MB1672.namprd09.prod.outlook.com (10.173.109.142) by CY4PR09MB1669.namprd09.prod.outlook.com (10.173.109.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 1 Aug 2016 15:31:16 +0000 Received: from CY4PR09MB1672.namprd09.prod.outlook.com ([10.173.109.142]) by CY4PR09MB1672.namprd09.prod.outlook.com ([10.173.109.142]) with mapi id 15.01.0549.022; Mon, 1 Aug 2016 15:31:16 +0000 From: "Dang, Quynh (Fed)" To: Ilari Liusvaara , "curdle@ietf.org" Thread-Topic: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates Thread-Index: AQHR7Am+HMQ2sWzT8k+tVnTY1t7MwQ== Date: Mon, 1 Aug 2016 15:31:16 +0000 Message-ID: References: <19075EB00EA7FE49AFF87E5818D673D4138D60C7@PRODEXMB01W.eagle.usaa.com> <20160722160216.GA26177@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160722160216.GA26177@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: 3d8a55c0-aad4-4663-2eda-08d3ba20e11b x-microsoft-exchange-diagnostics: 1; CY4PR09MB1669; 6:uBEJUqriGyU8SeGwtA7kMmU0cdy8uJVpSNdhlzATBY5EwSNA/deAvaueGL6YMIjkqvrbDacJytSnWNZNPjupAcw6xXTG/lVRPe96NBzoLa3hN0eAwl7Q0t4jrByv+SxzmP4ORl6+z0iS4JJBMAR4g5S1ZM4Lkxp/vXxD62kl8/UM2kQMrQceIPpZe0RZh+35MxAKmUgjQ/enOh/D7rUKVWDF2nX6m9OXSEr1ojMCMrQffA5+CBCrPzryzBp07fS4zJc8nmD42JTi6M1jLzMi6AAsBGRmVvk/3k0aMK0O886hMzLLOamXfWFT3Ak0UVGA3KXP1JDvIXQzjmjE70qMHQ==; 5:JexEbZmKVgAbvvj0rzy5/2IBTmkc+mD/tlzFA4fFHZUwbieaUJ1ip3HCc98fychx1T1HxK+//j3ZHGoGIvdI8vsVqxmE3Xo1N6R/WZXJ8BiyuOTwGEjZfzkMZQfL1qLuRYKNQR/QlNwG3ekLadJobg==; 24:7FtcwNt0JG/ShUWJ4vRyDYWgi+of0HI76RjzOFYh30toTPYlB+IhpNTdvA+n2ghX86dMFQI1c8ETLRm6wcV1N3fiUNZvBwLJmEmRwtdPLxU=; 7:EuQPBTubZEXJd7It8P1TXg/tea87nInS/TjnlNHS9RS0wDrWJtXE+f2DvQbtSIQW2SBBP6HUh+1/ej3bfkt6EZsPfu2+utgNbjegfnTIRGBK99RtvTT/HfMVOnF77YfhpVCn60r1ZpiKJRasdDEGKKormmzoBq5gs6JIhywZV1DVW78g31yqxPO/u9vk6zlqXNS+AkF3spfhDg4lTnXeWfykGqz/hjOrXgIDtegKLOPCOhBg/CpwuEfU4Ez2XYUt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR09MB1669; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY4PR09MB1669; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1669; x-forefront-prvs: 0021920B5A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(53754006)(24454002)(199003)(51444003)(377454003)(101416001)(66066001)(7736002)(81166006)(2501003)(86362001)(7846002)(81156014)(83506001)(2950100001)(2900100001)(8676002)(102836003)(2906002)(3660700001)(68736007)(3280700002)(10400500002)(99286002)(8936002)(105586002)(50986999)(76176999)(54356999)(106116001)(189998001)(586003)(92566002)(3846002)(77096005)(11100500001)(4001350100001)(87936001)(106356001)(122556002)(107886002)(19580405001)(305945005)(19580395003)(6116002)(36756003)(97736004)(5002640100001)(5001770100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1669; H:CY4PR09MB1672.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2016 15:31:16.6235 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1669 Archived-At: Subject: Re: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 15:31:26 -0000 SGkgSWxhcmksDQoNCg0KT24gNy8yMi8xNiwgMTI6MDIgUE0sICJDdXJkbGUgb24gYmVoYWxmIG9m IElsYXJpIExpdXN2YWFyYSINCjxjdXJkbGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPiB3cm90ZToNCg0KPk9uIE1vbiwgSnVuIDEzLCAyMDE2 IGF0IDEwOjEyOjU1QU0gKzAwMDAsIERhbmcsIFF1eW5oIChGZWQpIHdyb3RlOg0KPj4gSGkgYWxs LA0KPj4gDQo+PiBQcmVoYXNoIG9yIG5vbi1wcmVoYXNoLCBjaG9vc2luZyB0aGUgb25lIHdoaWNo IHdvcmtzIHdlbGwgZm9yIGFsbCB1c2VzDQo+PiAobm90IGp1c3Qgc2lnbmluZyBjZXJ0cykgaXMg dGhlIHJpZ2h0IHRoaW5nIHRvIGRvLiBJIGRvbqn2dCBrbm93IGhvdyBtdWNoDQo+PiB0aGUgbm9u LXByZWhhc2ggdmVyc2lvbiBpcyBhY3R1YWxseSB1c2VkIHJpZ2h0IG5vdyAoZGlmZmVyZW50IGZy b20gaG93DQo+PiBtdWNoIGl0IGlzIHN1cHBvcnRlZCBpbiBsaWJyYXJpZXMpLg0KPg0KPldlbGws IEkgdGhpbmsgdGhhdCBhbnl0aGluZyB0aGF0Og0KPi0gdGVjaG5pY2FsbHkgX2NvdWxkXyBzaWdu ICJub3QgdGVjaG5pY2FsbHkgY29uc3RyYWluZWQiIENBIGNlcnRpZmljYXRlDQo+ICAocmVnYXJk bGVzcyBvZiBpZiB0aGUga2V5IHdhcyBldmVyIGludGVuZGVkIHRvIGRvIHRoYXQpLCBhbmQNCj4t IF9jb3VsZF8gZXZlciBzaWduIGFueXRoaW5nIHRoYXQgZXZlbiBwYXJ0aWFsbHkgY29tZXMgZnJv bSBleHRlcm5hbA0KPiAgc291cmNlcyAodGhpcyBpbmNsdWRlcyBjcm9zcy1jZXJ0cykuDQo+DQo+ U2hvdWxkIHVzZSBub24tcHJlaGFzaC4NCj4NCj4NCj5UaGUgcmVhc29uIGZvciB0aGlzIGlzIHRo YXQgbm9uLXByZWhhc2ggdmVyc2lvbnMgbG9vayB0byBiZQ0KPl9zdWJzdGFudGlhbGx5XyB3ZWFr ZXIgYWdhaW5zdCBhdHRhY2tzIHRvIHRoZSBoYXNoIGZ1bmN0aW9uIChnb2luZyBieQ0KPmhpc3Rv cmljYWwgcGVyY2VkZW50KSwgYW5kIHRoZSB1bHRpbWF0ZSBuaWdodG1hcmUgc2NlbmFyaW8gaXMg YXR0YWNrZXINCj5tYW5hZ2luZyB0byBjb2xsaWRlIGlzc3VlZCBkYXRhIHdpdGggdW5jb25zdHJh aW5lZCBDQSBjZXJ0ZmljYXRlLg0KDQpJIGJlbGlldmUgdGhhdCBFZDI1NTE5LCBFZDQ0OCwgU0hB LTUxMiBhbmQgU0hBS0UyNTYgKGFzIGEgaGFzaCBmdW5jdGlvbikNCmFyZSBhbGwgc2VjdXJlLiBJ IGRvbqGvdCBrbm93IHdoaWNoIG9uZSB3aWxsIGZhbGwgZmlyc3QsIGJ1dCBJIGtub3cgdGhhdCBh DQpwcmFjdGljYWwgcXVhbnR1bSBjb21wdXRlciB3aWxsIGJyZWFrIEVkMjU1MTkgYW5kIEVkNDQ4 LCBCVVQgbm90IHRoZSBoYXNoDQpmdW5jdGlvbnMsIGFuZCB0aGlzIGNvdWxkIGhhcHBlbiB3aXRo aW4gNSwgMTAsIDE1IG9yIDIwIHllYXJzLiBUaGVyZWZvcmUsDQppbiB0aGF0IHJlc3BlY3QsIHRo ZSBhZGRpdGlvbmFsIHJpc2sgd2l0aCB0aGUgcHJlaGFzaCBpcyBwcmFjdGljYWxseSBub25lLg0K DQpUaGUgbW9yZSBpbXBvcnRhbnQgdGhpbmcgaXMgdGhhdCBhcmUgeW91IHdvcnJpZWQgYWJvdXQg c2VjdXJpdHkgb2YgU0hBLTUxMg0KYW5kL29yIFNIQUtFMjU2PyBXZXJlIHRoaXMgd29ycnkgd29y dGggYnVmZmVyaW5nIGxvbmcgbWVzc2FnZXMgYWxsIHRoZQ0KdGltZXMgZXZlcnl3aGVyZSBpbiBh bnkgc2l0dWF0aW9ucyBpbmNsdWRpbmcgYWxsIGtpbmRzIG9mIGNvbnN0cmFpbmVkDQplbnZpcm9u bWVudHM/DQoNCg0KDQoNCj4NCj4NCj5BbHNvLCBpZiBvbmUgbG9va3MgYXQgdGhlIGJhc2ljIHNp Z25lZCBkYXRhIGl0ZW1zIHRoYXQgZmxvYXQgYXJvdW5kIGluDQo+dmFyaW91cyBQS0lzLCB0aG9z ZSBpbmNsdWRlOg0KPg0KPi0gQ2VydGlmaWNhdGVzDQo+LSBPQ1NQIHJlc3BvbnNlcw0KPi0gQ1JM cw0KPg0KPk5vdywgY2VydGlmaWNhdGVzIGFuZCBzaG91bGQgYmUgZmFpcmx5IHNtYWxsLiBGZXcg a2lsb2J5dGVzIChvciBhdA0KPm1vc3QgZmV3IHRlbnMgb2Yga2lsb2J5dGVzIGZvciBjZXJ0cyB3 aXRoIFBRIGtleSBpbiB0aGVtKSBvciBzby4NCj4NCj5PQ1NQIHJlc3BvbnNlcyBzaG91bGQgYmUg ZXZlbiBzbWFsbGVyLiBPbiBvcmRlciBvZiAxMDAgYnl0ZXMgZm9yDQo+c2lnbmVkIHNpemU/DQo+ DQo+VGhpcyBsZWF2ZXMgQ1JMcywgd2hpY2ggY291bGQgcG90ZW50aWFsbHkgYmUgbGFyZ2lzaC4g QnV0IGFyZQ0KPnRob3NlIGFjdHVhbGx5IHVzZWQgdGhhdCBtdWNoPyBJIGRpZCBzZWFyY2ggZm9y IENSTCBmb3Igb25lDQo+cHJhY3RpY3VsYXIgdmVyeSBoaWdoLWFjdGl2aXR5IFdlYlBLSSBjZXJ0 LCBhbmQgY291bGRuJ3QNCj5maW5kIGl0IChpdCBtaWdodCBub3QgZXZlbiBleGlzdCkuDQo+DQo+ DQo+U28gcHJlc3VtYWJseSB1c2luZyBub24tcHJlaGFzaCBmb3IgZXZlcnl0aGluZyB3b3VsZCBi ZSBmZWFzaWJsZS4NCj4NCj4NCj4tSWxhcmkNCj4NCg0KT25lIGFsZ29yaXRobSB3aGljaCB3b3Jr cyB3ZWxsIGZvciBhbGwgc2l0dWF0aW9ucyB3b3VsZCBiZSBiZXR0ZXIuIEluIFRMUywNCklQU0VD LCBTL01JTUUgZXRjoaYuLCBhbiBhZGRpdGlvbmFsIGhhc2ggaXMgbm90IGEgY29uY2VybiBmb3Ig dGhlDQpwcm90b2NvbHMuIFdoZW4gc2lnbmluZyBsYXJnZSBtZXNzYWdlcywgdGhlIHByZWhhc2gg dmVyc2lvbiBpcyB0aGUgYmVzdA0Kb3B0aW9uIGFuZCB0aGUgcmlnaHQgb3B0aW9uIHRvIGdvLiBJ IGRvbqGvdCBrbm93IGFsbCBvZiB0aGUgcGxhY2VzIHdoZXJlDQp0aGUgc2lnbmF0dXJlIGFsZ29y aXRobSBpcyBnb2luZyB0byBiZSB1c2VkLCBidXQgSSBhbSBzdXJlIHRoZXJlIHdpbGwgYmUNCnNp dHVhdGlvbnMgd2hlcmUgbGFyZ2UgbWVzc2FnZXMgZ2V0IHNpZ25lZC4gQ3VycmVudGx5LCBJIHRo aW5rIFMvTUlNRQ0Kc2hvdWxkIHVzZSB0aGUgcHJlaGFzaCB2ZXJzaW9uIChJIGhhdmUgbm8gaWRl YXMgd2hpY2ggb25lIHRoZSBTL01JTUUNCndvcmtpbmcgZ3JvdXAgaXMgIGdvaW5nIHRvIHVzZS9h ZG9wdCkuDQoNCg0KUXV5bmguIA0KDQo+DQoNCg== From nobody Mon Aug 1 16:07:30 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E51612D7D0; Mon, 1 Aug 2016 16:07:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160801230725.3015.91086.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 16:07:25 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 23:07:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-01.txt Pages : 6 Date : 2016-08-01 Abstract: This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 1 17:03:57 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C6A12D0A5 for ; Mon, 1 Aug 2016 17:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287, 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 Dqfb8DMiYS9d for ; Mon, 1 Aug 2016 17:03:52 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6472F12D61B for ; Mon, 1 Aug 2016 17:03:46 -0700 (PDT) X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 2 Aug 2016 01:03:39 +0100 Message-ID: <62D23120DAF147D99D337AE57BB18373@Khan> From: "denis bider \(Bitvise\)" To: "Curdle" References: <20160801230725.3015.91086.idtracker@ietfa.amsl.com> In-Reply-To: <20160801230725.3015.91086.idtracker@ietfa.amsl.com> Date: Mon, 1 Aug 2016 18:03:08 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0066_01D1EC1E.F589AE30" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: djm@mindrot.org, Simon Tatham , ietf-ssh@netbsd.org, Peter Gutmann Subject: [Curdle] SSH: New version of RSA SHA-2 draft; prune extensions from EXT_INFO draft? X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 00:03:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0066_01D1EC1E.F589AE30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone - the two related drafts to support RSA signatures with SHA-2 in SSH: Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01 Extension Negotiation in Secure Shell (SSH) https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-00 ... are currently deployed in at least two widely available = implementations that I'm aware of: OpenSSH 7.2 Bitvise SSH Server and Client 7.xx I am aware also of implementations by Peter Gutmann (Cryptlib) and at = least one another smaller one. For these other implementations, I'm not = sure of their status, but it could be that some of them are also = deployed. Issues: 1. New version of RSA SHA-2 draft: After some deployment experience, I am finding that the draft has been = too easy to misread with respect to the correct encoding of an = SSH_MSG_USERAUTH_REQUEST containing an RSA SHA-2 signature. I have = updated the draft to lay out a full example of an authentication = request, in the way it's supposed to be encoded.=20 Besides this additional example, the new version does not change the = protocol in any way. 2. Pruning superfluous extensions from EXT_INFO draft? The EXT_INFO document currently describes the following extensions: server-sig-algs no-flow-control accept-channels elevation delay-compression Currently, I am aware of "server-sig-algs" being widely implemented. = This extension goes hand-in-hand with support for RSA signatures with = SHA-2, so it is implemented in the same products as enumerated above: = OpenSSH, Bitvise SSH Client and Server, and I am aware of at least one = other. I am currently not aware of current implementations of the other = proposed extensions. The respective reasons I proposed them were as = follows: no-flow-control: Peter Gutmann once expressed a passionate argument in favor of something = like this, which did not fit into SSH at that time. I therefore proposed = it because, with a mechanism like EXT_INFO, an extension like this is = possible. However, I am not actually passionate about implementing this = - for our needs, SSH flow control is fine - so the viability of this = extension depends on other people's interest. It should be kept if there = are implementations working on this. It should be cut if there are not. accept-channels: This would be a way to advertise product features that may otherwise = remain unknown to other implementors. Without an extension like this, = feature discovery involves looking at the counterparty's source code (if = available) or analyzing disassembly. If software implements an extension = like this, you can see at a glance what might be a good idea to = implement that your product is missing. elevation: This allows the user to decide whether they want elevation when logging = into a Windows server. Signaling via an extension is pretty much the = only good way to implement this feature - after user authentication, it = is already too late. Bitvise has this feature on a to-do list as a = "would like to have", but it's not high priority. We can also do it with = a proprietary, @bitvise.com extension. This can be cut if no one else is = interested. delay-compression: In my opinion, this is THE solution to delayed compression that should = have been implemented to begin with. The original OpenSSH implementation = of delayed compression is prone to a somewhat bad race condition, and = the PuTTY workaround to this race condition (also adopted by Bitvise) is = to enable compression after user authentication via a second early key = exchange. This workaround costs an additional, mostly unnecessary = handshake, which cost could be removed while also resolving the race = condition using this extension. I think this is a superior solution to an ongoing problem. However, our = software does not have a dependency on the zlib library (we use = Crypto++), so I am currently under a (I hope not mistaken!) impression = that reducing the attack surface through delayed compression is a = "like-to-have" more than a "must-have". For this reason, I would like = this extension to be adopted by authors who are the biggest fans of = delayed compression, e.g. OpenSSH and/or PuTTY - in which case, we would = definitely implement it as well. Overall, my feelings about the current extensions are: server-sig-algs - widely implemented, definitely keep --- delay-compression - promising; would like people to implement; keep? --- elevation - somewhat optional, can keep or cut accept-channels - would be nice, but can keep or cut --- no-flow-control - are there implementations? if not, cut? Best regards, denis bider ---- Original Message ---- From: internet-drafts@ietf.org=20 Sent: Monday, August 1, 2016 17:07 To: i-d-announce@ietf.org=20 Cc: curdle@ietf.org=20 Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-01.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in = Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-01.txt Pages : 6 Date : 2016-08-01 Abstract: This memo defines an algorithm name, public key format, and signature format for use of RSA keys with SHA-2 512 for server and client authentication in SSH connections. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-rsa-sha2-01 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0066_01D1EC1E.F589AE30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everyone -
 
the two related drafts to support RSA signatures with SHA-2 in=20 SSH:
Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)
https:= //tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01
 
Extension Negotiation in Secure Shell (SSH)
ht= tps://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-00
 
... are currently deployed in at least two widely available = implementations=20 that I'm aware of:
 
OpenSSH 7.2
Bitvise SSH Server and Client 7.xx
 
I am aware also of implementations by Peter Gutmann (Cryptlib) and = at least=20 one another smaller one. For these other implementations, I'm not sure = of their=20 status, but it could be that some of them are also deployed.
 
Issues:
 
 
1. New version of RSA SHA-2 draft:
 
After some deployment experience, I am finding that the draft has = been too=20 easy to misread with respect to the correct encoding of an=20 SSH_MSG_USERAUTH_REQUEST containing an RSA SHA-2 signature. I have = updated the=20 draft to lay out a full example of an authentication request, in the way = it's=20 supposed to be encoded.
 
Besides this additional example, the new version does not change = the=20 protocol in any way.
 
 
2. Pruning superfluous extensions from EXT_INFO=20 draft?
 
The EXT_INFO document currently describes the following = extensions:
 
  server-sig-algs
  no-flow-control
  accept-channels
  elevation
  delay-compression
 
Currently, I am aware of "server-sig-algs" being widely = implemented. This=20 extension goes hand-in-hand with support for RSA signatures with SHA-2, = so it is=20 implemented in the same products as enumerated above: OpenSSH, Bitvise = SSH=20 Client and Server, and I am aware of at least one other.
 
I am currently not aware of current implementations of the other = proposed=20 extensions. The respective reasons I proposed them were as = follows:
 
no-flow-control:
 
Peter Gutmann once expressed a passionate argument in favor of = something=20 like this, which did not fit into SSH at that time. I therefore proposed = it=20 because, with a mechanism like EXT_INFO, an extension like this is = possible.=20 However, I am not actually passionate about implementing this - for our = needs,=20 SSH flow control is fine - so the viability of this extension depends on = other=20 people's interest. It should be kept if there are implementations = working on=20 this. It should be cut if there are not.
 
accept-channels:
 
This would be a way to advertise product features that may = otherwise remain=20 unknown to other implementors. Without an extension like this, feature = discovery=20 involves looking at the counterparty's source code (if available) or = analyzing=20 disassembly. If software implements an extension like this, you can see = at a=20 glance what might be a good idea to implement that your product is=20 missing.
 
elevation:
 
This allows the user to decide whether they want elevation when = logging=20 into a Windows server. Signaling via an extension is pretty much the = only good=20 way to implement this feature - after user authentication, it is already = too=20 late. Bitvise has this feature on a to-do list as a "would like to = have", but=20 it's not high priority. We can also do it with a proprietary, = @bitvise.com=20 extension. This can be cut if no one else is interested.
 
delay-compression:
 
In my opinion, this is THE solution to delayed compression that = should have=20 been implemented to begin with. The original OpenSSH implementation of = delayed=20 compression is prone to a somewhat bad race condition, and the PuTTY = workaround=20 to this race condition (also adopted by Bitvise) is to enable = compression after=20 user authentication via a second early key exchange. This workaround = costs an=20 additional, mostly unnecessary handshake, which cost could be removed = while also=20 resolving the race condition using this extension.
 
I think this is a superior solution to an ongoing problem. However, = our=20 software does not have a dependency on the zlib library (we use = Crypto++), so I=20 am currently under a (I hope not mistaken!) impression that reducing the = attack=20 surface through delayed compression is a "like-to-have" more than a = "must-have".=20 For this reason, I would like this extension to be adopted by authors = who are=20 the biggest fans of delayed compression, e.g. OpenSSH and/or PuTTY - in = which=20 case, we would definitely implement it as well.
 
Overall, my feelings about the current extensions are:
 
 
server-sig-algs   - widely = implemented,=20 definitely keep
---
delay-compression - promising; would = like people=20 to implement; keep?
---
elevation         -=20 somewhat optional, can keep or cut
accept-channels   - would be = nice, but=20 can keep or cut
---
no-flow-control   - are there=20 implementations? if not, cut?
 
 
Best regards,
 
denis bider
 
 
---- Original Message ----
From: internet-drafts@ietf.org
Sent: Monday, August 1, 2016 17:07
To: i-d-announce@ietf.org
Cc: curdle@ietf.org
Subject: [Curdle] I-D Action: = draft-ietf-curdle-rsa-sha2-01.txt
 
 
A New Internet-Draft is available from the on-line Internet-Drafts=20 directories.
This draft is a work item of the CURves, Deprecating and a Little = more=20 Encryption of the IETF.
 
       =20 Title           : Use = of RSA=20 Keys with SHA-2 256 and 512 in Secure Shell (SSH)
       =20 Author          : Denis = Bider
Filename        :=20 draft-ietf-curdle-rsa-sha2-01.txt
Pages           : = 6
Date          &nbs= p; :=20 2016-08-01
 
Abstract:
  This memo defines an algorithm name, public key format, and=20 signature
  format for use of RSA keys with SHA-2 512 for server and=20 client
  authentication in SSH connections.
 
 
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/
 
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-01
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-rsa-sha2-01
 
 
Please note that it may take a couple of minutes from the time of=20 submission
until the htmlized version and diff are available at = tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_0066_01D1EC1E.F589AE30-- From nobody Fri Aug 12 17:28:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8037912D81F for ; Fri, 12 Aug 2016 17:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 OSUcOGLbDmor for ; Fri, 12 Aug 2016 17:28:03 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC7A12D662 for ; Fri, 12 Aug 2016 17:28:03 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 12 Aug 2016 17:39:54 -0700 From: Jim Schaad To: Date: Fri, 12 Aug 2016 17:27:37 -0700 Message-ID: <020801d1f4f9$7fd562e0$7f8028a0$@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: AdH09qBhGkg5yA+GSmGf7UgBG4lHhQ== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 00:28:04 -0000 For the document draft-ietf-curdle-pkix, I have done something that is different and I wanted to see what people's reactions to it are going to be. When encoding a SubjectPublicKey, you end up with 0 30 42: SEQUENCE { 2 30 5: SEQUENCE { 4 06 3: OBJECT IDENTIFIER '1 3 101 112' : } 9 03 33: BIT STRING 0 unused bits : 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B 96 : C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66 61 : } Note that I have not done an ASN.1 wrapping on the key itself before putting it into the BIT STRING. Pro: This ends up being two bytes shorter than if we did a wrapping of an OCTET STRING around the key and then placed the result of that in the BIT STRING Con: This is not what any other algorithm has ever done, as far as I know, so there is a good chance that people are going to screw this up in their implementations. Comments on the approach are solicited. Jim From nobody Fri Aug 12 19:06:55 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113012D79E for ; Fri, 12 Aug 2016 19:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] 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 IReAcOcJkCR0 for ; Fri, 12 Aug 2016 19:06:52 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CF412D675 for ; Fri, 12 Aug 2016 19:06:51 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id u186so2473123ita.0 for ; Fri, 12 Aug 2016 19:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=4IDr+RSinTExQkfdRUdUq1U653N1FfOkEhZ9Ih+HXhU=; b=cs2ofEjOJin45PBAo6SRIlZjsOpk4aCxKogPJgnFRkL1DYICIZqMAmsp8v/KGOict3 pY9HK4P+9HpfU7AReUSAnStMUr27OSPz74qtM+vJaRGFgeoh7Emuu/ykAD94XpyolH/l QQX/i7j7o6gZ5ReD9swYvK9jmWwNTMegKuL2I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=4IDr+RSinTExQkfdRUdUq1U653N1FfOkEhZ9Ih+HXhU=; b=G6dgoPS0kmaJ0wpB/8Yp0D6Av7e3ucmYUSQ4oG9MPvlvBbrVjtATWTw/jafJLlDg9V kpPlVKBVuo9yXBUp3U7wX7wGsz/Egaw+lwYy/Br5S5JIIPabfOblmOP0E/joFjwwiU2o dAsCRKreKVmiV7iIAYscIaNS5n8RcyWLlr90wGM3LvrvyVUi9nmtPWSWs6z+ueaW7M8F GGulNrYjIv/IcJC1vLYieU7Z6w/WKpmqsMHZ7m3/tkBZL7xGqEfaAQCg+g55rFrap7Cz qe4LsXIls19+CS147S2Tu3UxU/po+fGDhy2DiMCDrc0Tmt/QmPkfjfwmxiMGMXym3L+B Bz/A== X-Gm-Message-State: AEkoouuRz9owJ0D67OSK6N37JROZW0xrm+hWwya0AmvLJKpx8HNNf1rrdQdpnsAft36nXWYZsGoK2n8rYndhJUj0 X-Received: by 10.36.147.68 with SMTP id y65mr2203392itd.76.1471054011117; Fri, 12 Aug 2016 19:06:51 -0700 (PDT) MIME-Version: 1.0 References: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> In-Reply-To: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> From: David Benjamin Date: Sat, 13 Aug 2016 02:06:39 +0000 Message-ID: To: Jim Schaad , curdle@ietf.org Content-Type: multipart/alternative; boundary=94eb2c08917cc7958a0539ea730c Archived-At: Subject: Re: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 02:06:54 -0000 --94eb2c08917cc7958a0539ea730c Content-Type: text/plain; charset=UTF-8 +1 I believe this is what id-ecPublicKey does too, except that it's the X9.62 serialization rather than the EdDSA one, so there's precedent for this too. David On Fri, Aug 12, 2016 at 8:28 PM Jim Schaad wrote: > For the document draft-ietf-curdle-pkix, I have done something that is > different and I wanted to see what people's reactions to it are going to > be. > > When encoding a SubjectPublicKey, you end up with > > 0 30 42: SEQUENCE { > 2 30 5: SEQUENCE { > 4 06 3: OBJECT IDENTIFIER '1 3 101 112' > : } > 9 03 33: BIT STRING 0 unused bits > : 19 BF 44 09 69 84 CD FE 85 41 BA C1 67 DC 3B 96 > : C8 50 86 AA 30 B6 B6 CB 0C 5C 38 AD 70 31 66 61 > : } > > Note that I have not done an ASN.1 wrapping on the key itself before > putting > it into the BIT STRING. > > Pro: This ends up being two bytes shorter than if we did a wrapping of an > OCTET STRING around the key and then placed the result of that in the BIT > STRING > > Con: This is not what any other algorithm has ever done, as far as I know, > so there is a good chance that people are going to screw this up in their > implementations. > > > Comments on the approach are solicited. > > Jim > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c08917cc7958a0539ea730c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

I believe this is what id-ecPublicKey does too, = except that it's the X9.62 serialization rather than the EdDSA one, so = there's precedent for this too.

David

On Fri, Aug 12, 2016 at 8:28 PM Jim Sc= haad <ietf@augustcellars.com> wrote:
For the document draf= t-ietf-curdle-pkix, I have done something that is
different and I wanted to see what people's reactions to it are going t= o be.

When encoding a SubjectPublicKey, you end up with

=C2=A0 =C2=A00 30=C2=A0 =C2=A042: SEQUENCE {
=C2=A0 =C2=A02 30=C2=A0 =C2=A0 5:=C2=A0 =C2=A0SEQUENCE {
=C2=A0 =C2=A04 06=C2=A0 =C2=A0 3:=C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER '= ;1 3 101 112'
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A09 03=C2=A0 =C2=A033:=C2=A0 =C2=A0BIT STRING 0 unused bits
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0 =C2=A019 BF 44 09 = 69 84 CD FE 85 41 BA C1 67 DC 3B 96
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0 =C2=A0C8 50 86 AA = 30 B6 B6 CB 0C 5C 38 AD 70 31 66 61
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=C2=A0 =C2=A0}

Note that I have not done an ASN.1 wrapping on the key itself before puttin= g
it into the BIT STRING.

Pro:=C2=A0 This ends up being two bytes shorter than if we did a wrapping o= f an
OCTET STRING around the key and then placed the result of that in the BIT STRING

Con:=C2=A0 This is not what any other algorithm has ever done, as far as I = know,
so there is a good chance that people are going to screw this up in their implementations.


Comments on the approach are solicited.

Jim


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--94eb2c08917cc7958a0539ea730c-- From nobody Sat Aug 13 01:31:46 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB9412D093 for ; Sat, 13 Aug 2016 01:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 BVcjq0Sm8raY for ; Sat, 13 Aug 2016 01:31:42 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id B727812B037 for ; Sat, 13 Aug 2016 01:31:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id AEF07FAA0; Sat, 13 Aug 2016 11:31:40 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id iEXybPW2m_Qm; Sat, 13 Aug 2016 11:31:40 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7BA7D27B; Sat, 13 Aug 2016 11:31:40 +0300 (EEST) Date: Sat, 13 Aug 2016 11:31:32 +0300 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160813083132.647hzdqfsx6jh4dy@LK-Perkele-V2.elisa-laajakaista.fi> References: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: Jim Schaad , curdle@ietf.org Subject: Re: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 08:31:45 -0000 On Sat, Aug 13, 2016 at 02:06:39AM +0000, David Benjamin wrote: > +1 > > I believe this is what id-ecPublicKey does too, except that it's the X9.62 > serialization rather than the EdDSA one, so there's precedent for this too. Yes, id-ecPublicKey has non-ASN.1 stuff inside that BIT STRING. -Ilari From nobody Sat Aug 13 12:34:58 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6802512D1A4 for ; Sat, 13 Aug 2016 12:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 pE6FaPZ7V8MR for ; Sat, 13 Aug 2016 12:34:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC49412D097 for ; Sat, 13 Aug 2016 12:34:54 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 13 Aug 2016 12:46:39 -0700 From: Jim Schaad To: , 'David Benjamin' References: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> <20160813083132.647hzdqfsx6jh4dy@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160813083132.647hzdqfsx6jh4dy@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sat, 13 Aug 2016 12:34:22 -0700 Message-ID: <029301d1f599$b32fc9f0$198f5dd0$@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: AQI9ko05HtipWTPM4kkMI/yWCI10pQGhJWV7AZzB3w2fVgk2oA== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 19:34:56 -0000 Sigh .... I have now seen it written to be done both ways in two different = documents. RFC 5480 - Says that the OCTET STRING ASN.1 wrapper is not used. I find = the text that says this to be obscure and could have been clearer. RFC 5753 - This is a slightly different context (CMS), but the structure = in ASN.1 is identical and is intended to be the same thing that is used = in a certificate. In this case the ASN.1 OCTET STRING wrapper is used. Jim > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Saturday, August 13, 2016 1:32 AM > To: David Benjamin > Cc: Jim Schaad ; curdle@ietf.org > Subject: Re: [Curdle] Encoding Public Keys >=20 > On Sat, Aug 13, 2016 at 02:06:39AM +0000, David Benjamin wrote: > > +1 > > > > I believe this is what id-ecPublicKey does too, except that it's the > > X9.62 serialization rather than the EdDSA one, so there's precedent = for this > too. >=20 > Yes, id-ecPublicKey has non-ASN.1 stuff inside that BIT STRING. >=20 >=20 >=20 > -Ilari From nobody Sat Aug 13 13:19:10 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F0812D519 for ; Sat, 13 Aug 2016 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.946 X-Spam-Level: X-Spam-Status: No, score=-3.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] 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 XJ9HL-maJW4H for ; Sat, 13 Aug 2016 13:19:07 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C0812D097 for ; Sat, 13 Aug 2016 13:19:06 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id f6so15273251ith.0 for ; Sat, 13 Aug 2016 13:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rGU2ApVp2LzBJwhWv3s2iXQFczWID+MUSoeIfTSIY6U=; b=WOGzS2kKmMmnn9IlkSjs4p8IpKQ/iiN6DpIAnanObEtMFXvkdBwMgdMJ4mXassp7fD bxSyVf5QUNIM3O/3iYPLTpYYMaZprZgYUPJz2C7iwEsPxJKtkRphQLtzn655niBgeS8B 5BqM2LTkdk3NVIUYRUyoRGh9WzWRUqP9EI7vw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rGU2ApVp2LzBJwhWv3s2iXQFczWID+MUSoeIfTSIY6U=; b=SHLN6nowZAZbm3e0NAQ2kZnMs0/+hFleJSGPjv0boQPJLByP88CvR6SgOP2fzmCXdj dtu6E0DgoAq0QG6Zd2gZSlxnPoFjR4L5XUnGOCGuL/Q5KUvq2hVz6pTz/MMyqJCqdDoy 0ex/qAraAly2w/Qkl8vr3Kn6hb/XM2f5qG0fkLeeUUre/o4KewwJs7l4jxHjNMR1TfKQ By+ryqyACVYSLMkP9TWX+FVu8uJmpKoTn7paqZWUDzmAJLuiT4x0+rOLprswXL3KnsTW E16XTubOiutI7RayAuvxRp/HbzV6A2ljBZs5yQzMLu1wKgV1uoyJfuvlfOoP5bJwz9uf jI2w== X-Gm-Message-State: AEkoous2x3sRkfBPR01D3hg1eQ45wSpGtWmSGxnvsoh9zLGcBffYyZ6V0A5D5ppu7VXKGeCwtAccbOH95cPEEgbk X-Received: by 10.36.61.201 with SMTP id n192mr6013894itn.92.1471119545930; Sat, 13 Aug 2016 13:19:05 -0700 (PDT) MIME-Version: 1.0 References: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> <20160813083132.647hzdqfsx6jh4dy@LK-Perkele-V2.elisa-laajakaista.fi> <029301d1f599$b32fc9f0$198f5dd0$@augustcellars.com> In-Reply-To: <029301d1f599$b32fc9f0$198f5dd0$@augustcellars.com> From: David Benjamin Date: Sat, 13 Aug 2016 20:18:54 +0000 Message-ID: To: Jim Schaad , ilariliusvaara@welho.com Content-Type: multipart/alternative; boundary=001a11444e94f55e5b0539f9b5f1 Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 20:19:09 -0000 --001a11444e94f55e5b0539f9b5f1 Content-Type: text/plain; charset=UTF-8 Oh lovely. At least for X.509 on the web, I believe everyone intereprets it as RFC 5480, though I agree it is phrased kind of confusingly. Do you know what existing CMS implementations do? Perhaps we want to errata RFC 5753. (Part of the problem I think is that SubjectPublicKeyInfo should have been an OCTET STRING instead of a BIT STRING, but we're stuck with that. As a BIT STRING everyone needs to spell out the same mapping from lowercase octet string to upper case BIT STRING. Though it seems RFC 3279 doesn't even spell it out and you've just got to know the mapping is the natural one given BIT STRING's DER representation.) David On Sat, Aug 13, 2016 at 3:34 PM Jim Schaad wrote: > Sigh .... > > I have now seen it written to be done both ways in two different documents. > > RFC 5480 - Says that the OCTET STRING ASN.1 wrapper is not used. I find > the text that says this to be obscure and could have been clearer. > RFC 5753 - This is a slightly different context (CMS), but the structure > in ASN.1 is identical and is intended to be the same thing that is used in > a certificate. In this case the ASN.1 OCTET STRING wrapper is used. > > Jim > > > > -----Original Message----- > > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > > Sent: Saturday, August 13, 2016 1:32 AM > > To: David Benjamin > > Cc: Jim Schaad ; curdle@ietf.org > > Subject: Re: [Curdle] Encoding Public Keys > > > > On Sat, Aug 13, 2016 at 02:06:39AM +0000, David Benjamin wrote: > > > +1 > > > > > > I believe this is what id-ecPublicKey does too, except that it's the > > > X9.62 serialization rather than the EdDSA one, so there's precedent > for this > > too. > > > > Yes, id-ecPublicKey has non-ASN.1 stuff inside that BIT STRING. > > > > > > > > -Ilari > > --001a11444e94f55e5b0539f9b5f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh lovely.=C2=A0At least f= or X.509 on the web, I believe everyone intereprets it as RFC 5480, though = I agree it is phrased kind of confusingly.

Do you kno= w what existing CMS implementations do? Perhaps we want to errata RFC 5753.=

(Part of the problem I think is that Subje= ctPublicKeyInfo should have been an OCTET STRING instead of a BIT STRING, b= ut we're stuck with that. As a BIT STRING everyone needs to spell out t= he same mapping from lowercase octet string to upper case BIT STRING. Thoug= h it seems RFC 3279 doesn't even spell it out and you've just got t= o know the mapping is the natural one given BIT STRING's DER representa= tion.)

David

On Sat, Aug 13, 2016 at 3:34 PM Jim Schaad <ietf@augustcellars.com> wrote:=
Sigh ....

I have now seen it written to be done both ways in two different documents.=

RFC 5480 - Says that the OCTET STRING ASN.1 wrapper is not used.=C2=A0 I fi= nd the text that says this to be obscure and could have been clearer.
RFC 5753 - This is a slightly different context (CMS), but the structure in= ASN.1 is identical and is intended to be the same thing that is used in a = certificate.=C2=A0 In this case the ASN.1 OCTET STRING wrapper is used.

Jim


> -----Original Message-----
> From: il= ariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
> Sent: Saturday, August 13, 2016 1:32 AM
> To: David Benjamin <davidben@chromium.org>
> Cc: Jim Schaad <ietf@augustcellars.com>; curdle@ietf.org
> Subject: Re: [Curdle] Encoding Public Keys
>
> On Sat, Aug 13, 2016 at 02:06:39AM +0000, David Benjamin wrote:
> > +1
> >
> > I believe this is what id-ecPublicKey does too, except that it= 9;s the
> > X9.62 serialization rather than the EdDSA one, so there's pre= cedent for this
> too.
>
> Yes, id-ecPublicKey has non-ASN.1 stuff inside that BIT STRING.
>
>
>
> -Ilari

--001a11444e94f55e5b0539f9b5f1-- From nobody Sat Aug 13 14:37:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8412D0A4 for ; Sat, 13 Aug 2016 14:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.247, 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 naI2MVunpBcs for ; Sat, 13 Aug 2016 14:37:24 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B3612B059 for ; Sat, 13 Aug 2016 14:37:23 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 13 Aug 2016 14:49:08 -0700 From: Jim Schaad To: 'David Benjamin' References: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> <20160813083132.647hzdqfsx6jh4dy@LK-Perkele-V2.elisa-laajakaista.fi> <029301d1f599$b32fc9f0$198f5dd0$@augustcellars.com> In-Reply-To: Date: Sat, 13 Aug 2016 14:36:51 -0700 Message-ID: <02a101d1f5aa$cf860f90$6e922eb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A2_01D1F570.232ABA00" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI9ko05HtipWTPM4kkMI/yWCI10pQGhJWV7AZzB3w0BguPTnQGsdWQ1nzzGJSA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2016 21:37:26 -0000 ------=_NextPart_000_02A2_01D1F570.232ABA00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I have just filed the errata on RFC 5753 based on what I understand the = implementations of OpenSSL and BouncyCastle do. Both of these = implementations apparently do not include the OCTET STRING wrapper. But = at least I now know why it is that I thought there was a wrapper on = this. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin Sent: Saturday, August 13, 2016 1:19 PM To: Jim Schaad ; ilariliusvaara@welho.com Cc: curdle@ietf.org Subject: Re: [Curdle] Encoding Public Keys =20 Oh lovely. At least for X.509 on the web, I believe everyone intereprets = it as RFC 5480, though I agree it is phrased kind of confusingly. =20 Do you know what existing CMS implementations do? Perhaps we want to = errata RFC 5753. =20 (Part of the problem I think is that SubjectPublicKeyInfo should have = been an OCTET STRING instead of a BIT STRING, but we're stuck with that. = As a BIT STRING everyone needs to spell out the same mapping from = lowercase octet string to upper case BIT STRING. Though it seems RFC = 3279 doesn't even spell it out and you've just got to know the mapping = is the natural one given BIT STRING's DER representation.) =20 David =20 On Sat, Aug 13, 2016 at 3:34 PM Jim Schaad > wrote: Sigh .... I have now seen it written to be done both ways in two different = documents. RFC 5480 - Says that the OCTET STRING ASN.1 wrapper is not used. I find = the text that says this to be obscure and could have been clearer. RFC 5753 - This is a slightly different context (CMS), but the structure = in ASN.1 is identical and is intended to be the same thing that is used = in a certificate. In this case the ASN.1 OCTET STRING wrapper is used. Jim > -----Original Message----- > From: ilariliusvaara@welho.com = [mailto:ilariliusvaara@welho.com ] > Sent: Saturday, August 13, 2016 1:32 AM > To: David Benjamin > > Cc: Jim Schaad = >; curdle@ietf.org =20 > Subject: Re: [Curdle] Encoding Public Keys > > On Sat, Aug 13, 2016 at 02:06:39AM +0000, David Benjamin wrote: > > +1 > > > > I believe this is what id-ecPublicKey does too, except that it's the > > X9.62 serialization rather than the EdDSA one, so there's precedent = for this > too. > > Yes, id-ecPublicKey has non-ASN.1 stuff inside that BIT STRING. > > > > -Ilari ------=_NextPart_000_02A2_01D1F570.232ABA00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I have just = filed the errata on RFC 5753 based on what I understand the = implementations of OpenSSL and BouncyCastle do.=C2=A0 Both of these = implementations apparently do not include the OCTET STRING = wrapper.=C2=A0 But at least I now know why it is that I thought there = was a wrapper on this.

 

Jim

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of David = Benjamin
Sent: Saturday, August 13, 2016 1:19 PM
To: = Jim Schaad <ietf@augustcellars.com>; = ilariliusvaara@welho.com
Cc: = curdle@ietf.org
Subject: Re: [Curdle] Encoding Public = Keys

 

Oh = lovely. At least for X.509 on the web, I believe everyone = intereprets it as RFC 5480, though I agree it is phrased kind of = confusingly.

 

Do you know what existing CMS implementations do? = Perhaps we want to errata RFC 5753.

 

(Part of the problem I think is that = SubjectPublicKeyInfo should have been an OCTET STRING instead of a BIT = STRING, but we're stuck with that. As a BIT STRING everyone needs to = spell out the same mapping from lowercase octet string to upper case BIT = STRING. Though it seems RFC 3279 doesn't even spell it out and you've = just got to know the mapping is the natural one given BIT STRING's DER = representation.)

 

David

 

On = Sat, Aug 13, 2016 at 3:34 PM Jim Schaad <ietf@augustcellars.com> = wrote:

Sigh ....

I have now seen it = written to be done both ways in two different documents.

RFC 5480 = - Says that the OCTET STRING ASN.1 wrapper is not used.  I find the = text that says this to be obscure and could have been clearer.
RFC = 5753 - This is a slightly different context (CMS), but the structure in = ASN.1 is identical and is intended to be the same thing that is used in = a certificate.  In this case the ASN.1 OCTET STRING wrapper is = used.

Jim


> -----Original Message-----
> = From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]
> Sent: Saturday, = August 13, 2016 1:32 AM
> To: David Benjamin <davidben@chromium.org>
> Cc: Jim Schaad = <ietf@augustcellars.com>; curdle@ietf.org
> Subject: Re: [Curdle] = Encoding Public Keys
>
> On Sat, Aug 13, 2016 at 02:06:39AM = +0000, David Benjamin wrote:
> > +1
> >
> > I = believe this is what id-ecPublicKey does too, except that it's = the
> > X9.62 serialization rather than the EdDSA one, so = there's precedent for this
> too.
>
> Yes, = id-ecPublicKey has non-ASN.1 stuff inside that BIT = STRING.
>
>
>
> = -Ilari

------=_NextPart_000_02A2_01D1F570.232ABA00-- From nobody Sun Aug 14 02:41:09 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0342612D6A1 for ; Sun, 14 Aug 2016 02:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 F58yIZ_g7Xya for ; Sun, 14 Aug 2016 02:41:06 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BF712D698 for ; Sun, 14 Aug 2016 02:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471167666; x=1502703666; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n9bgbwxtoGE4s1JScdNtzI4vYJMgwFldhqZRbeAEw0A=; b=PWu6n8YsOAymBSHM3+Bn6Cwk9YYzJ1EFvpYgDPvOElb9Jrvp+yb8kwty TwJp9o1GIntnnGaA5cCAwkmhxSr9AeoPxgpGiQwAH3wARMLZBScy7gtqR +RpEsO95Cc8IYY48QRbEIr2UK9N6ggF9bq8tnZXW2SC1OZ9lzTCg+6cNP 5lj8ETH36VNwykZiTpiKfblKvDFdkEL412aEWiUaiMIXWATjSqX7FoPFj eHR2ZuELes33FmhZQ7xcMvXgaHPZg351/IvsNGvlyNlmUSDlMWD2NKeqI BPCr55yRieuyxTUpS0tWmwIkHWP1yiIR4qGTYtedODEdpN1SkUVYnG5/K Q==; X-IronPort-AV: E=Sophos;i="5.28,519,1464609600"; d="scan'208";a="102101464" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 14 Aug 2016 21:41:00 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sun, 14 Aug 2016 21:41:00 +1200 From: Peter Gutmann To: David Benjamin , Jim Schaad , "ilariliusvaara@welho.com" Thread-Topic: [Curdle] Encoding Public Keys Thread-Index: AdH09qBhGkg5yA+GSmGf7UgBG4lHhf//WDyAgABriQCAALkxAIAADHIAgAGpJ5s= Date: Sun, 14 Aug 2016 09:40:59 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CEDC10@uxcn10-5.UoA.auckland.ac.nz> References: <020801d1f4f9$7fd562e0$7f8028a0$@augustcellars.com> <20160813083132.647hzdqfsx6jh4dy@LK-Perkele-V2.elisa-laajakaista.fi> <029301d1f599$b32fc9f0$198f5dd0$@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-originating-ip: [10.6.2.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] Encoding Public Keys X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Aug 2016 09:41:08 -0000 David Benjamin writes:=0A= =0A= >Do you know what existing CMS implementations do? Perhaps we want to errat= a=0A= >RFC 5753.=0A= =0A= That's a six-year-old document, if this is the first time someone has notic= ed=0A= a problem then I'm guessing it's not exactly widely deployed, so a change= =0A= wouldn't really cause breakage.=0A= =0A= Peter.= From nobody Tue Aug 16 13:18:58 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EFB12B049 for ; Tue, 16 Aug 2016 13:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oKnjbtulDF7 for ; Tue, 16 Aug 2016 13:18:53 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA39F128E19 for ; Tue, 16 Aug 2016 13:18:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=i8mDDcBoLzoRwJDM1RskTvV0hKnjdL+3udSmhPyfgd8=; b=MZTiGIqIuw1KvmuCS3F+Tr7K0PAk6do7YrDMYk4eJPcpdwXyMhHfGDmWDrhrCt/iKbQPIu7zzz+wF 3oo0MLLYtfX8ZdtppJ5CoH9AwQIE3MHT8tv61oKW6YnzGK+HQK5/kYoGqmt7Pj1/shfTsh1mOGiO6z PKWgasy3gyj6mDnD3CWWO3M4NKeXHxPUAvEbN6l4xpYNQHcUsMT+pp2RxO2SYJv/A+0Iw0Y7OodR53 jVOPQtECggsu/EhmAjS1ewaOTSSIdV5fm9/oRpbPS8RSKnzFm0G/WEGK4yeJEPvLHVUyrOps+XApLY FdempdxrsMTzPDbJ/1onimMY2JHxEKQ== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 16 Aug 2016 21:18:38 +0100 Message-ID: <11B894DDA9DC48DDB9ABA4B509946B4D@Khan> From: "denis bider \(Bitvise\)" To: "Peter Gutmann" , References: <9A043F3CF02CD34C8E74AC1594475C73F4CF007D@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF007D@uxcn10-5.UoA.auckland.ac.nz> Date: Tue, 16 Aug 2016 14:18:09 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0215_01D1F7C9.03F1F210" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: Curdle Subject: Re: [Curdle] Questions about draft-ietf-curdle-ssh-ext-info-00.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 20:18:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0215_01D1F7C9.03F1F210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Peter, > Section 2.3, "can send the the following message": > MAY? MUST? SHOULD? thanks. I changed this in the working version of the draft to MAY. > Section 2.3, "This message is sent without delay,=20 > and immediately after SSH_MSG_NEWKEYS": > > Uhh, shouldn't it wait for the NEWKEYS to succeed? > Otherwise if something goes wrong the sender has > leaked the info that it's withheld until now because > it's apparently sensitive. In the direction from client to server, the client's sending of NEWKEYS = indicates the server's authenticity has already been verified, so there = is no issue. In the direction from server to client, any information that's actually = sensitive would be postponed until the second EXT_INFO message sent when = user authentication is successful. There seems to be little value in = mounting an attack to discover the contents of EXT_INFO sent before user = authentication, when you can just connect to the SSH server without = intent to authenticate, and get the information that way after a normal = completed key exchange. > Section 2.4, "the server MAY send, but is not obligated > to send, an SSH_MSG_EXT_INFO message immediately before > SSH_MSG_USERAUTH_SUCCESS": > > Before, not after? Yes, before. Otherwise you get a race condition because the client may = want to take different actions after authentication success depending on = whether it receives certain information in this second EXT_INFO, or not. If the message could be sent after USERAUTH_SUCCESS, but might not be = sent by the server, then the client has no idea whether it should wait = for the server to send this message or not, or how long to wait. Given that the message is optional - which I think is a good choice, and = cannot be changed now anyway because the protocol extension is already = deployed to a significant extent - any second EXT_INFO sent by the = server must be sent *before* SSH_MSG_USERAUTH_SUCCESS. > That's going to lead to a pretty strange message flow, the > client sends a SSH_MSG_USERAUTH_REQUEST and instead of the > expected SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE > it gets some random message about extensions. The EXT_INFO message is not random when received in this context. The = client has signaled it is willing to receive it, which includes the = requirement and ability to receive it in this context, also. Note that the specification requires the server to send no more than one = or two EXT_INFO messages at the times specified, but the client = implementation for handling the second EXT_INFO does not have to enforce = that it is followed by USERAUTH_SUCCESS. If it is simpler for the client = to simply accept and normally handle any additional EXT_INFO messages = received before USERAUTH_SUCCESS, the client can do so without = necessarily needing to enforce the number of these additional messages, = or that a USERAUTH_SUCCESS message immediately follows. This can be done = easily at the same layer that handles the initial EXT_INFO message. = Since the server is already authenticated by the client, I don't see = risks from allowing this leeway. > Section 2.4, "If a server sends a subsequent > SSH_MSG_EXT_INFO, this replaces any initial one, and both > the client and the server re-evaluate extensions in effect": > > This is just asking for trouble, you're requiring both sides > to be able to sort out and disambiguate conflicting > extensions in a compatible manner. If a server implements one or more extensions that require the sending = of a second EXT_INFO, it may check the EXT_INFO received from the client = to see if the client indicates support for any of those extensions. If = it does not, the server does not need to send the second EXT_INFO, and = there are no conflicts. But if the client indicates support for such = extensions, implementations of such extensions will be able to agree on = proper behavior at that time. The current widely used extension, server-sig-algs, does not have much = continued relevance after user authentication is successful, and so does = not suffer from extensions being re-evaluated due to a second EXT_INFO. If you have a suggestion for wording to be inserted that would reduce = the chances of compatibility issues due to the second EXT_INFO, please = let me know. From my perspective, the current spec seems clear ("a = subsequent SSH_MSG_EXT_INFO [...] replaces any initial one", "the client = and the server re-evaluate extensions in effect"). But if there's a way = we can further clarify this, I'm open to suggestions. > Section 3.4, "elevation": > > What does this extension do? I was expecting an option of > which floor you want to get off on, with a negative value > for the parking garage. Point taken. I have modified the working version of the draft to insert = the words "(as used by Windows)" in the description of this extension. denis From: Peter Gutmann=20 Sent: Tuesday, August 16, 2016 04:36 To: ietf-ssh3@denisbider.com ; ietf-ssh@netbsd.org=20 Subject: Questions about draft-ietf-curdle-ssh-ext-info-00.txt I've been looking at this draft and have a few questions... Section 2.3, "can send the the following message": MAY? MUST? SHOULD? Section 2.3, "This message is sent without delay, and immediately after SSH_MSG_NEWKEYS": Uhh, shouldn't it wait for the NEWKEYS to succeed? Otherwise if = something goes wrong the sender has leaked the info that it's withheld until now = because it's apparently sensitive. Section 2.4, "the server MAY send, but is not obligated to send, an SSH_MSG_EXT_INFO message immediately before SSH_MSG_USERAUTH_SUCCESS": Before, not after? That's going to lead to a pretty strange message = flow, the client sends a SSH_MSG_USERAUTH_REQUEST and instead of the expected SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE it gets some random = message about extensions. Why not require that the extensions be sent after failure/success has been indicated? Section 2.4, "If a server sends a subsequent SSH_MSG_EXT_INFO, this = replaces any initial one, and both the client and the server re-evaluate = extensions in effect": This is just asking for trouble, you're requiring both sides to be able = to sort out and disambiguate conflicting extensions in a compatible manner. Section 3.4, "elevation": What does this extension do? I was expecting an option of which floor = you want to get off on, with a negative value for the parking garage. Peter. ------=_NextPart_000_0215_01D1F7C9.03F1F210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Peter,
 
> Section 2.3, "can send the the following message":
> MAY?  MUST?  SHOULD?
 
thanks. I changed this in the working version of the draft to = MAY.
 
 
> Section 2.3, "This message is sent without delay,
> and immediately after SSH_MSG_NEWKEYS":
>
> Uhh, shouldn't it wait for the NEWKEYS to succeed?
> Otherwise if something goes wrong the sender has
> leaked the info that it's withheld until now because
> it's apparently sensitive.
 
In the direction from client to server, the client's sending of = NEWKEYS=20 indicates the server's authenticity has already been verified, so there = is no=20 issue.
 
In the direction from server to client, any information that's = actually=20 sensitive would be postponed until the second EXT_INFO message sent when = user=20 authentication is successful. There seems to be little value in mounting = an=20 attack to discover the contents of EXT_INFO sent before user = authentication,=20 when you can just connect to the SSH server without intent to = authenticate, and=20 get the information that way after a normal completed key = exchange.
 
 
> Section 2.4, "the server MAY send, but is not obligated
> to send, an SSH_MSG_EXT_INFO message immediately before
> SSH_MSG_USERAUTH_SUCCESS":
>
> Before, not after?
 
Yes, before. Otherwise you get a race condition because the client = may want=20 to take different actions after authentication success depending on = whether it=20 receives certain information in this second EXT_INFO, or not.
 
If the message could be sent after USERAUTH_SUCCESS, but might not = be sent=20 by the server, then the client has no idea whether it should wait for = the server=20 to send this message or not, or how long to wait.
 
Given that the message is optional - which I think is a good = choice, and=20 cannot be changed now anyway because the protocol extension is already = deployed=20 to a significant extent - any second EXT_INFO sent by the server must be = sent=20 *before* SSH_MSG_USERAUTH_SUCCESS.
 
 
> That's going to lead to a pretty strange message flow, = the
> client sends a SSH_MSG_USERAUTH_REQUEST and instead of = the
> expected = SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE
> it gets some random message about extensions.
 
The EXT_INFO message is not random when received in this context. = The=20 client has signaled it is willing to receive it, which includes the = requirement=20 and ability to receive it in this context, also.
 
Note that the specification requires the server to send no more = than one or=20 two EXT_INFO messages at the times specified, but the client = implementation for=20 handling the second EXT_INFO does not have to enforce that it is = followed by=20 USERAUTH_SUCCESS. If it is simpler for the client to simply accept and = normally=20 handle any additional EXT_INFO messages received before = USERAUTH_SUCCESS, the=20 client can do so without necessarily needing to enforce the number of = these=20 additional messages, or that a USERAUTH_SUCCESS message immediately = follows.=20 This can be done easily at the same layer that handles the initial = EXT_INFO=20 message. Since the server is already authenticated by the client, I = don't see=20 risks from allowing this leeway.
 
 
> Section 2.4, "If a server sends a subsequent
> SSH_MSG_EXT_INFO, this replaces any initial one, and = both
> the client and the server re-evaluate extensions in = effect":
>
> This is just asking for trouble, you're requiring both = sides
> to be able to sort out and disambiguate conflicting
> extensions in a compatible manner.
 
If a server implements one or more extensions that require the = sending of a=20 second EXT_INFO, it may check the EXT_INFO received from the client to = see if=20 the client indicates support for any of those extensions. If it does = not, the=20 server does not need to send the second EXT_INFO, and there are no = conflicts.=20 But if the client indicates support for such extensions, implementations = of such=20 extensions will be able to agree on proper behavior at that time.
 
The current widely used extension, server-sig-algs, does not have = much=20 continued relevance after user authentication is successful, and so does = not=20 suffer from extensions being re-evaluated due to a second = EXT_INFO.
 
If you have a suggestion for wording to be inserted that would = reduce the=20 chances of compatibility issues due to the second EXT_INFO, please let = me know.=20 >From my perspective, the current spec seems clear ("a subsequent=20 SSH_MSG_EXT_INFO [...] replaces any initial one", "the client and the = server=20 re-evaluate extensions in effect"). But if there's a way we can further = clarify=20 this, I'm open to suggestions.
 
 
> Section 3.4, "elevation":
>
> What does this extension do?  I was expecting an option = of
> which floor you want to get off on, with a negative = value
> for the parking garage.
 
Point taken. I have modified the working version of the draft to = insert the=20 words "(as used by Windows)" in the description of this extension.
 
denis
 
 
Sent: Tuesday, August 16, 2016 04:36
To: ietf-ssh3@denisbider.com ; = ietf-ssh@netbsd.org
Subject: Questions about=20 draft-ietf-curdle-ssh-ext-info-00.txt
 
I've=20 been looking at this draft and have a few questions...

Section = 2.3, "can=20 send the the following message":

MAY?  MUST? =20 SHOULD?

Section 2.3, "This message is sent without delay, and = immediately=20 after
SSH_MSG_NEWKEYS":

Uhh, shouldn't it wait for the NEWKEYS = to=20 succeed?  Otherwise if something goes
wrong the sender has = leaked the=20 info that it's withheld until now because it's
apparently=20 sensitive.

Section 2.4, "the server MAY send, but is not = obligated to=20 send, an
SSH_MSG_EXT_INFO message immediately before=20 SSH_MSG_USERAUTH_SUCCESS":

Before, not after?  That's going = to lead=20 to a pretty strange message flow, the
client sends a = SSH_MSG_USERAUTH_REQUEST=20 and instead of the = expected
SSH_MSG_USERAUTH_SUCCESS/SSH_MSG_USERAUTH_FAILURE=20 it gets some random message
about extensions.  Why not require = that the=20 extensions be sent after
failure/success has been = indicated?

Section=20 2.4, "If a server sends a subsequent SSH_MSG_EXT_INFO, this = replaces
any=20 initial one, and both the client and the server re-evaluate extensions=20 in
effect":

This is just asking for trouble, you're requiring = both=20 sides to be able to
sort out and disambiguate conflicting extensions = in a=20 compatible manner.

Section 3.4, "elevation":

What does = this=20 extension do?  I was expecting an option of which floor you
want = to get=20 off on, with a negative value for the parking=20 garage.

Peter.
------=_NextPart_000_0215_01D1F7C9.03F1F210-- From nobody Tue Aug 16 14:19:54 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2D312D0AB for ; Tue, 16 Aug 2016 14:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2T4f5J0E1QKd for ; Tue, 16 Aug 2016 14:19:51 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1968212B024 for ; Tue, 16 Aug 2016 14:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type; bh=PG1UIUr0E1Uowr31xQobsOnWeIpMmudx8lfEO+Rdlq4=; b=fq5MlRStCFAlcu4L82ZvzpqMhT9QIoCIlmZ6YEiT1KOTNT/E1z193xDkXBWZO+LM5riL4UUvKLu7y +UZbhzR70OozRgE0X8EuOXd/CUMjTZ/dK3YZLlQBlr0c/XjiNmaTH7D3UoxkVL7s30DHrNQTAh4Iak 5K1yTVwYgugBFHcj1UMzl7wloZMdwwkZmY15WzXczV67osqyu1tb41mmYu5UwNIElAXnTxxW2Cfufu i7cMxVPkQrds+zM5ssbqbInW0ly0zb2GrPnCJyaLlGvl1cUvXcRzyuoJoyMgMd36Gd+bGfPhsAboC9 xo1SHr/3/gCnYU7xTXVtLmIPov6rY8A== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Tue, 16 Aug 2016 22:19:40 +0100 Message-ID: <71963A21726946C3B16A0B77F0CFF3F6@Khan> From: "denis bider \(Bitvise\)" To: "Curdle" Date: Tue, 16 Aug 2016 15:19:14 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027B_01D1F7D1.8C95D430" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: djm@mindrot.org, ietf-ssh@netbsd.org, "Mark D. Baushke" Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:19:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_027B_01D1F7D1.8C95D430 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everyone, this comment is with respect to the following draft specifying new = Diffie-Hellman groups for SSH key exchange: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 The current version of the draft specifies the following: diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group18-sha512 MAY/OPTIONAL =20 A previous version of this draft specified the following methods: https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03 diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group17-sha512 MAY/OPTIONAL diffie-hellman-group18-sha512 MAY/OPTIONAL =20 Note the presence of additional groups 15 and 17 which were removed in = version 4 of the original Baushke draft. Groups 15 and 17 were removed based on feedback from one implementer. = Basically, this feedback was one line: > +1 to dropping the odd-numbered groups and onlist listing = group14/16/18 I would like to counter this, and move to restore the previous table = including groups 15 and 17 - or failing that, at least group 15 - with = the same parameters as above, in version 3 of the original Baushke = draft. My reasons for proposing this are as follows: - According to NSA recommendations, the 3072-bit strength would be the = current sweet spot between performance and acceptable security. Group 15 = is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit. - The additional security of group 16 in comparison to group 15 is = estimated to be small. Symmetric security estimates I've seen are 80 = bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 = bits for group 15 (3072-bit). Based on this, I expect the security of = group 16 (4096-bit) to be between 136 - 144 symmetric bits. - Based on practical measurements, it appears that group 16 is about a = factor of 2 slower than group 15. With group 15, I'm getting about 20 = full DH key exchanges per second; with group 16, I am getting around 10. = I think this difference is significant, and can affect real world usage = scenarios on heavily loaded servers. At this time, I do not have a particular need for group 17 (or 18), but = I find it peculiar that this draft would not specify a group that = matches the exact recommended DH group size suggested by the NSA. It is = weird that we have to choose either between group 14, which does not = meet the requirements; or group 16, which is significantly slower. For our next Bitvise SSH Server and Client versions, I have implemented = support for groups 15 as well as 16, where group 15 is implemented with = SHA-512, as specified above. When using DH key exchange, our SSH Server = will favor group 15, whereas group 16 will be disabled by default for = performance (but it will be enabled and preferred in the SSH Client). denis ------=_NextPart_000_027B_01D1F7D1.8C95D430 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello everyone,
 
this comment is with respect to the following draft specifying new=20 Diffie-Hellman groups for SSH key exchange:
 
ht= tps://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03
 
The current version of the draft specifies the following:
 
  diffie-hellman-group14-sha256    =20 MAY/OPTIONAL
  diffie-hellman-group16-sha512    =20 SHOULD/RECOMMENDED
  diffie-hellman-group18-sha512    =20 MAY/OPTIONAL
A previous version of this draft specified the following = methods:
 
h= ttps://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03
 
  diffie-hellman-group14-sha256    =20 MAY/OPTIONAL
  diffie-hellman-group15-sha512    =20 MUST/REQUIRED/SHALL
  diffie-hellman-group16-sha512    =20 SHOULD/RECOMMENDED
  diffie-hellman-group17-sha512    =20 MAY/OPTIONAL
  diffie-hellman-group18-sha512    =20 MAY/OPTIONAL
Note the presence of additional groups 15 and 17 which were removed = in=20 version 4 of the original Baushke draft.
 
Groups 15 and 17 were removed based on feedback from one = implementer.=20 Basically, this feedback was one line:
 
> +1 to dropping the odd-numbered groups and onlist listing=20 group14/16/18
 
I would like to counter this, and move to restore the previous = table=20 including groups 15 and 17 - or failing that, at least group 15 - with = the same=20 parameters as above, in version 3 of the original Baushke draft.
 
My reasons for proposing this are as follows:
 
- According to NSA recommendations, the 3072-bit strength would be = the=20 current sweet spot between performance and acceptable security. Group 15 = is=20 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.
 
- The additional security of group 16 in comparison to group 15 is=20 estimated to be small. Symmetric security estimates I've seen are 80 = bits for=20 group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for = group 15=20 (3072-bit). Based on this, I expect the security of group 16 (4096-bit) = to be=20 between 136 - 144 symmetric bits.
 
- Based on practical measurements, it appears that group 16 is = about a=20 factor of 2 slower than group 15. With group 15, I'm getting about 20 = full DH=20 key exchanges per second; with group 16, I am getting around 10. I think = this=20 difference is significant, and can affect real world usage scenarios on = heavily=20 loaded servers.
 
At this time, I do not have a particular need for group 17 (or 18), = but I=20 find it peculiar that this draft would not specify a group that matches = the=20 exact recommended DH group size suggested by the NSA. It is weird that = we have=20 to choose either between group 14, which does not meet the requirements; = or=20 group 16, which is significantly slower.
 
For our next Bitvise SSH Server and Client versions, I have = implemented=20 support for groups 15 as well as 16, where group 15 is implemented with = SHA-512,=20 as specified above. When using DH key exchange, our SSH Server will = favor group=20 15, whereas group 16 will be disabled by default for performance (but it = will be=20 enabled and preferred in the SSH Client).
 
denis
 
------=_NextPart_000_027B_01D1F7D1.8C95D430-- From nobody Tue Aug 16 14:36:56 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7C012B024 for ; Tue, 16 Aug 2016 14:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 RAk6tjW2xpZZ for ; Tue, 16 Aug 2016 14:36:47 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F1112D74B for ; Tue, 16 Aug 2016 14:36:47 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 14:48:58 -0700 From: Jim Schaad To: Date: Tue, 16 Aug 2016 14:36:40 -0700 Message-ID: <05fa01d1f806$485b99f0$d912cdd0$@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: AdH4BZXvVXZANHxcSi2k0s4BKTQrjQ== Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Subject: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Aug 2016 21:36:54 -0000 Ilari has done edits on a local draft to respond to my comments and it appears he is planning on introducing a new mode to the EdDSA drafts for 25519. Specifically one would have: EdDSA25519 - the traditional signature algorithm EdDSA25519ctx - a new mode for 25519 which has a context structure available to it. EdDSA25519pre - a pre-hash mode that uses the same structure as EdDSSA25519ctx This means that we would no longer have the huge problem between ctx and pre hash modes conflicting quite as much as one could require the use of ctx and pre instead. One still has the problems between pure and the other modes. The questions I have are: Should we issue an OID for the new ctx mode? Should we require the use of the ctx mode for signing of certificates? Should we have any advisory language which says that new usages SHOULD use the ctx mode over the pure mode? Jim From nobody Tue Aug 16 20:37:27 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8555312B005 for ; Tue, 16 Aug 2016 20:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 UbCy3JoueJJj for ; Tue, 16 Aug 2016 20:37:23 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DA0A812B00B for ; Tue, 16 Aug 2016 20:37:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 9FD4AF3D8; Wed, 17 Aug 2016 06:37:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id jTEsoBFp1lPv; Wed, 17 Aug 2016 06:37:20 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3DB0027B; Wed, 17 Aug 2016 06:37:20 +0300 (EEST) Date: Wed, 17 Aug 2016 06:37:12 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> User-Agent: Mutt/1.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 03:37:25 -0000 On Tue, Aug 16, 2016 at 02:36:40PM -0700, Jim Schaad wrote: > Ilari has done edits on a local draft to respond to my comments and it > appears he is planning on introducing a new mode to the EdDSA drafts for > 25519. Specifically one would have: > > EdDSA25519 - the traditional signature algorithm > EdDSA25519ctx - a new mode for 25519 which has a context structure available > to it. > EdDSA25519pre - a pre-hash mode that uses the same structure as > EdDSSA25519ctx The names aren't right (the right ones are 'Ed25519ctx' and 'Ed25519ph'), but otherewise quite so (assuming contexts will be part of the document!) > This means that we would no longer have the huge problem between ctx and pre > hash modes conflicting quite as much as one could require the use of ctx and > pre instead. One still has the problems between pure and the other modes. That change also solves the problem of using the same key for Ed25519 and Ed25519ph. However, Ed25519ctx and Ed25519ph can't be computed using standard Ed25519 software. There is no way to do so while remaining safe to key- share. Fortunately, the places that are modified are likely not to be too inaccessable (i.e. written in high-level-language) in practical implementations, if you can modify one. > The questions I have are: > > Should we issue an OID for the new ctx mode? > > Should we require the use of the ctx mode for signing of certificates? > > Should we have any advisory language which says that new usages SHOULD use > the ctx mode over the pure mode? It occurs to me that one could avoid use of prehashed EdDSA variants by adding OID that is defined to sign a hash object[1] instead of the actual data. If then one could avoid contexts, one could just use standard-issue Ed25519 code (which is dime dozen). That could be also be used to avoid the potentially annoying SHAK256 hashing if one wants long-input Ed448. While contexts could help against things like that TLS 1.2 LURK SKI attack EKR came up with, there are plenty of RSA or ECDSA keys that are unprotected against such abuse. And then there is the issue that contexts are a new input, and many signature APIs just doesn't have it. And with regards to new stuff using contexts, I think it is a bad idea, unless the stuff used only contextualized signatures. And PKIX fails that criteria. [1] One rough sketch (excuse me for not using the correct notation): SEQUENCE { OID OCTET_STRING zeroes_64octets AlgorithmIdentifier hash_algorithm OCTET_STRING hash_value } DER-encode that (easily templateable if you know the hash, which would come from the signature algorithm OID) and use that as message for algorithm. The OID in the beginning is to distinguish it from other ASN.1 structures. I threw that zeroes_64octets in there to make it more difficult to abuse with TLS. Specifically, valid TLS 1.3 signatures can't look like that because those start with 0x20, not 0x30 like that one does. Nor can valid TLS 1.2 signatures, because that one presumably has a zero in 65th and 66th position, which would code curve type 0 (undefined) for ECDHE and p=0 (division by zero) for DHE. One minor problem being that it breaks a SHA-512 block (which is like 2% speed penalty for signing, less for verfication). -Ilari From nobody Tue Aug 16 21:14:15 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3C512D752 for ; Tue, 16 Aug 2016 21:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 p4lO0ghTv0FS for ; Tue, 16 Aug 2016 21:14:11 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531B112D626 for ; Tue, 16 Aug 2016 21:14:11 -0700 (PDT) Received: from hebrews (50.39.87.30) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 16 Aug 2016 21:26:03 -0700 From: Jim Schaad To: References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 16 Aug 2016 21:13:44 -0700 Message-ID: <064901d1f83d$c0b891f0$4229b5d0$@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: AQHmq3PHmJZ1Zt4yMknvAsjdQB0DPgHHRDYKoBTpzjA= Content-Language: en-us X-Originating-IP: [50.39.87.30] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 04:14:13 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Tuesday, August 16, 2016 8:37 PM > To: Jim Schaad > Cc: curdle@ietf.org > Subject: Re: [Curdle] Ed25591ctx >=20 > On Tue, Aug 16, 2016 at 02:36:40PM -0700, Jim Schaad wrote: > > Ilari has done edits on a local draft to respond to my comments and = it > > appears he is planning on introducing a new mode to the EdDSA drafts > > for 25519. Specifically one would have: > > > > EdDSA25519 - the traditional signature algorithm EdDSA25519ctx - a = new > > mode for 25519 which has a context structure available to it. > > EdDSA25519pre - a pre-hash mode that uses the same structure as > > EdDSSA25519ctx >=20 > The names aren't right (the right ones are 'Ed25519ctx' and = 'Ed25519ph'), but > otherewise quite so (assuming contexts will be part of the document!) >=20 > > This means that we would no longer have the huge problem between ctx > > and pre hash modes conflicting quite as much as one could require = the > > use of ctx and pre instead. One still has the problems between pure = and the > other modes. >=20 > That change also solves the problem of using the same key for Ed25519 = and > Ed25519ph. I had forgotten about the use of the invalid point to make sure that = this was clean. >=20 > However, Ed25519ctx and Ed25519ph can't be computed using standard > Ed25519 software. There is no way to do so while remaining safe to = key- share. > Fortunately, the places that are modified are likely not to be too = inaccessable > (i.e. written in high-level-language) in practical implementations, if = you can > modify one. >=20 > > The questions I have are: > > > > Should we issue an OID for the new ctx mode? > > > > Should we require the use of the ctx mode for signing of = certificates? > > > > Should we have any advisory language which says that new usages = SHOULD > > use the ctx mode over the pure mode? >=20 > It occurs to me that one could avoid use of prehashed EdDSA variants = by adding > OID that is defined to sign a hash object[1] instead of the actual = data. If then > one could avoid contexts, one could just use standard-issue > Ed25519 code (which is dime dozen). >=20 > That could be also be used to avoid the potentially annoying SHAK256 = hashing if > one wants long-input Ed448. >=20 >=20 > While contexts could help against things like that TLS 1.2 LURK SKI = attack EKR > came up with, there are plenty of RSA or ECDSA keys that are = unprotected > against such abuse. >=20 > And then there is the issue that contexts are a new input, and many = signature > APIs just doesn't have it. My intent was not clear. I was indicating that we should use the = context version, but specify an empty context as would be done with the = Ed448 signature algorithm. This is not the point in time that I would = want to introduce a new parameter to signature and verification APIs. Jim >=20 > And with regards to new stuff using contexts, I think it is a bad = idea, unless the > stuff used only contextualized signatures. And PKIX fails that = criteria. >=20 >=20 >=20 > [1] One rough sketch (excuse me for not using the correct notation): >=20 > SEQUENCE { > OID > OCTET_STRING zeroes_64octets > AlgorithmIdentifier hash_algorithm > OCTET_STRING hash_value > } >=20 > DER-encode that (easily templateable if you know the hash, which would = come > from the signature algorithm OID) and use that as message for = algorithm. >=20 > The OID in the beginning is to distinguish it from other ASN.1 = structures. >=20 > I threw that zeroes_64octets in there to make it more difficult to = abuse with > TLS. >=20 > Specifically, valid TLS 1.3 signatures can't look like that because = those start with > 0x20, not 0x30 like that one does. >=20 > Nor can valid TLS 1.2 signatures, because that one presumably has a = zero in 65th > and 66th position, which would code curve type 0 > (undefined) for ECDHE and p=3D0 (division by zero) for DHE. >=20 > One minor problem being that it breaks a SHA-512 block (which is like = 2% speed > penalty for signing, less for verfication). >=20 >=20 >=20 >=20 > -Ilari From nobody Tue Aug 16 22:12:06 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BF812B030 for ; Tue, 16 Aug 2016 22:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 XKfeBUvztdc0 for ; Tue, 16 Aug 2016 22:12:05 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0B212D754 for ; Tue, 16 Aug 2016 22:06:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 75000100DB; Wed, 17 Aug 2016 08:06:10 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id AwXRgrMoPdbJ; Wed, 17 Aug 2016 08:06:10 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 48DE121C; Wed, 17 Aug 2016 08:06:10 +0300 (EEST) Date: Wed, 17 Aug 2016 08:06:02 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160817050602.xn4rxxb5qrwgymdx@LK-Perkele-V2.elisa-laajakaista.fi> References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> <064901d1f83d$c0b891f0$4229b5d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <064901d1f83d$c0b891f0$4229b5d0$@augustcellars.com> User-Agent: Mutt/1.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 05:12:05 -0000 On Tue, Aug 16, 2016 at 09:13:44PM -0700, Jim Schaad wrote: > > My intent was not clear. I was indicating that we should use the > context version, but specify an empty context as would be done with > the Ed448 signature algorithm. This is not the point in time that > I would want to introduce a new parameter to signature and > verification APIs. The context is empty by default (except for Ed25519ctx). If that is not clear from the document, it should be fixed. -Ilari From nobody Wed Aug 17 04:41:00 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83012D699 for ; Wed, 17 Aug 2016 04:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 TSGKdJdaiIMI for ; Wed, 17 Aug 2016 04:40:54 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FC312D97D for ; Wed, 17 Aug 2016 04:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471433194; x=1502969194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3T56dL9Ot5Q51lMsS6jfOarnPDPuBPS7nAX+ma/J8m8=; b=M2d2HinL0J1jPDCkdQsmoQuVcdEkN32q6xh8PgwPhwB/WEikRWx/ZOUP slAu64Vjblpr3m/cf4aMp537FlgZ/myY60qScs7R9B2EM6EVhvfxegTA2 7iO6YeL4CmEWjla6ZHvsJ2DV0MF79Zut+0PxmJSMuYNqDbVlN4fySOHIn UjEbMmqyQkxrTD7qtouxm9EEAfG2a24goM45Vz8GKnv6pSdpwjECzQuyU HS4I/mhL1kocTfaogRmX/L5A9ic75NkJsW71DM2AA6jFxa/ejS6Xp1nKe KY6Quv80a2SD+OtFb3sw/FBpmlfsEr4QcFCdUDB24Og+rir6kd/GyYzGp w==; X-IronPort-AV: E=Sophos;i="5.28,529,1464609600"; d="scan'208";a="102529826" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Aug 2016 23:26:29 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Wed, 17 Aug 2016 23:26:29 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , Curdle Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APyc5WGhg2eHE6rWz5EA7SZMqBNBCC2 Date: Wed, 17 Aug 2016 11:26:28 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> In-Reply-To: <71963A21726946C3B16A0B77F0CFF3F6@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:40:58 -0000 denis bider (Bitvise) writes:=0A= =0A= >this comment is with respect to the following draft specifying new Diffie-= =0A= >Hellman groups for SSH key exchange:=0A= =0A= A further comment on the draft:=0A= =0A= The United States Information Assurance Directorate (IAD) at the=0A= National Security Agency (NSA) has published a FAQ=0A= [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve=0A= Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes=0A= less than SHA2-384 are no longer sufficient for transport of Top=0A= Secret information. It is for this reason that this draft moves=0A= ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange=0A= method. =0A= =0A= So you've got an arbitrary ruling by some random US govt. agency that's=0A= dictating how the entire world's SSH implementations have to function (sigh= ).=0A= We know from global TLS scans that pretty much the entire planet uses SHA-2= 56,=0A= with SHA-384 and SHA-512 essentially lost in the noise. However, this spec= is=0A= making the universal worldwide standard a MAY and the least-used form of th= e=0A= entire SHA-2 family a MUST. If the NSA's IAD wants to use whatever weird= =0A= config they decide on they can create their own spec (Suite B, anyone?), bu= t a=0A= global standard should go with whatever the world as a whole has decided on= ,=0A= and that's overwhelmingly SHA-256.=0A= =0A= Peter.= From nobody Wed Aug 17 04:46:52 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EE212D688 for ; Wed, 17 Aug 2016 04:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.968 X-Spam-Level: X-Spam-Status: No, score=-3.968 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 ENjPBRWWIVlR for ; Wed, 17 Aug 2016 04:46:50 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8BC12D685 for ; Wed, 17 Aug 2016 04:45:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B83A04EF32; Wed, 17 Aug 2016 11:45:15 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9B8194D23A; Wed, 17 Aug 2016 11:45:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471434315; bh=IxWCKgItFrzp302hnvledKK0WD2Nj6GdKdJR+UPOkdA=; l=212; h=From:To:CC:Date:References:In-Reply-To:From; b=ocEFh5k+w49jq/E65yTxewPHRWcHoGk/h2Q4SJ+Xh8EE/6jL6hGodnqOn4vR/MuEl yQvgR/yQ7M4rP/Bg1Jz7gkJfu0ifpG+7uv0ZhYqYNoYzlBIEGErbloTw/ugNP7grSD 8UuWfCo2XLGQwg7IojOGJmfx4CtKP1WZj3fJIUcw= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 90F241FC88; Wed, 17 Aug 2016 11:45:15 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 Aug 2016 07:45:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 17 Aug 2016 07:45:15 -0400 From: "Salz, Rich" To: Peter Gutmann , "denis bider (Bitvise)" , Curdle Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwaEfWkeGPWkyjpB63havJEqBNR2oA///BzAA= Date: Wed, 17 Aug 2016 11:45:14 +0000 Message-ID: References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.58] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 11:46:51 -0000 Speaking as an individual, I strongly agree with Peter; SHA256 should be MU= ST and any other variant should be a MAY. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Aug 17 07:20:48 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DBC12DCD1 for ; Wed, 17 Aug 2016 07:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcbVfK6XXrt5 for ; Wed, 17 Aug 2016 07:20:42 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AA912DCC6 for ; Wed, 17 Aug 2016 07:20:40 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-8d-57b4739fb51e Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 39.3F.02568.F9374B75; Wed, 17 Aug 2016 16:24:31 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 10:15:28 -0400 From: Daniel Migault To: "denis bider (Bitvise)" , Curdle Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwxyfnHXpgoEakB10teLEFZ6BNHKVg Date: Wed, 17 Aug 2016 14:15:27 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> In-Reply-To: <71963A21726946C3B16A0B77F0CFF3F6@Khan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXRPiO784i3hBhM3qVpsXTiL2eLKt2dM FvdeTmG0+HDvMZtF153rbA6sHvenz2P3WLLkJ5PH9aar7B7fPrWzeSx82MMYwBrFZZOSmpNZ llqkb5fAlfFnhXlB8wbGil/n1jA3MHbPZuxi5OCQEDCRuLkit4uRi0NIYAOjxL7bJ9khnOWM Evf2vWTrYuTkYBMwkmg71M8OYosIBEms+toHZjMLVEs8X/8arEZYwEPi4MyPTBA1nhIXt9+G qjeS+HvpDSuIzSKgKvH+ziVmEJtXwFfi8K3FYPVCAsYSRw7fZgM5iBPooPWdliBhRgExie+n 1jBBrBKXuPVkPpgtISAgsWTPeWYIW1Ti5eN/rBC2ksSkpedYIerzJVoudEGtEpQ4OfMJywRG kVlIRs1CUjYLSRlEXEdiwe5PbBC2tsSyha+ZYewzBx4zIYsvYGRfxchRWlyQk5tuZLCJERh5 xyTYdHcw3p/ueYhRgINRiYd3QcjmcCHWxLLiytxDjBIczEoivGsLt4QL8aYkVlalFuXHF5Xm pBYfYpTmYFES5xV7pBguJJCeWJKanZpakFoEk2Xi4JRqYGw68EEx3Ddr3smzJ55M81664JnQ htbjijekbfYwageofDr44KjSjetntF93qlfVW+j1SIRUJ8312LLrR9iRE49TGrevWLX31+/d fwvburSWzF0z9d+JNR6in+MWTfQ/4Nq7oCfwdP4hizIPIetLjml8z7tC9ib/NpvoUFs99+SH lNbUiZq6x1mUWIozEg21mIuKEwEPnR2RuAIAAA== Archived-At: Cc: "djm@mindrot.org" , "ietf-ssh@netbsd.org" , "Mark D. Baushke" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:20:45 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Going briefly through the draft, it seems redundant to have MAY/OPTIONAL, S= HOULD/RECOMMENDED, MAY/OPTIONAL. I am not sure this does not result in a c= ombination of recommendation for the users as well as a recommendation on a= lgorithms to implement. I would recommend we only focus on requirements for= algorithm implementation. We should also specify that all non specified al= gorithms in this document are "MAY". I have not found any recommendations for these algorithms at the IANA web p= age [1], nor in another document. If that is the case, maybe this document = should clarify this so a status can be assigned for each kex. The IANA page= also does not mention all algorithm and I have not found documentation for= all suites found in the manual. Updating the different algorithm should consider two aspects: security and = interoperability, which means a SHOULD NOT status is expected to be done fo= r a cipher suite with a SHOULD status. In other words going from MUST to SH= OULD NOT should be avoided unless there are strong reasons to do so. So may= be we should do a little bit more cleanup. I do not know the current status for SSH but it would be good to end up in = group1 and SHA1 set to MUST NOT - eventually SHOULD NOT later being updated= to MUST NOT. SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it ready= when SHA256 will be replaced. Maybe we should also consider the current use of the various group, and tho= se not widely used may be set to MAY. BR, Daniel [1] http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh= -parameters-16 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of denis bider (Bit= vise) Sent: Tuesday, August 16, 2016 5:19 PM To: Curdle Cc: djm@mindrot.org; ietf-ssh@netbsd.org; Mark D. Baushke Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Hello everyone, this comment is with respect to the following draft specifying new Diffie-H= ellman groups for SSH key exchange: https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 The current version of the draft specifies the following: diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group18-sha512 MAY/OPTIONAL A previous version of this draft specified the following methods: https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03 diffie-hellman-group14-sha256 MAY/OPTIONAL diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL diffie-hellman-group16-sha512 SHOULD/RECOMMENDED diffie-hellman-group17-sha512 MAY/OPTIONAL diffie-hellman-group18-sha512 MAY/OPTIONAL Note the presence of additional groups 15 and 17 which were removed in vers= ion 4 of the original Baushke draft. Groups 15 and 17 were removed based on feedback from one implementer. Basic= ally, this feedback was one line: > +1 to dropping the odd-numbered groups and onlist listing group14/16/18 I would like to counter this, and move to restore the previous table includ= ing groups 15 and 17 - or failing that, at least group 15 - with the same p= arameters as above, in version 3 of the original Baushke draft. My reasons for proposing this are as follows: - According to NSA recommendations, the 3072-bit strength would be the curr= ent sweet spot between performance and acceptable security. Group 15 is 307= 2-bit, whereas groups 14 and 16 are 2048- and 4096-bit. - The additional security of group 16 in comparison to group 15 is estimate= d to be small. Symmetric security estimates I've seen are 80 bits for group= 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 = (3072-bit). Based on this, I expect the security of group 16 (4096-bit) to = be between 136 - 144 symmetric bits. - Based on practical measurements, it appears that group 16 is about a fact= or of 2 slower than group 15. With group 15, I'm getting about 20 full DH k= ey exchanges per second; with group 16, I am getting around 10. I think thi= s difference is significant, and can affect real world usage scenarios on h= eavily loaded servers. At this time, I do not have a particular need for group 17 (or 18), but I f= ind it peculiar that this draft would not specify a group that matches the = exact recommended DH group size suggested by the NSA. It is weird that we h= ave to choose either between group 14, which does not meet the requirements= ; or group 16, which is significantly slower. For our next Bitvise SSH Server and Client versions, I have implemented sup= port for groups 15 as well as 16, where group 15 is implemented with SHA-51= 2, as specified above. When using DH key exchange, our SSH Server will favo= r group 15, whereas group 16 will be disabled by default for performance (b= ut it will be enabled and preferred in the SSH Client). denis --_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

Going briefly through the draft, it seems redundant= to have MAY/OPTIONAL, SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sur= e this does not result in a combination of recommendation for the users as well as a recommendation on algorithms to implement. I wo= uld recommend we only focus on requirements for algorithm implementation. W= e should also specify that all non specified algorithms in this document ar= e “MAY”.

 

I have not found any recommendations for these algo= rithms at the IANA web page [1], nor in another document. If that is the ca= se, maybe this document should clarify this so a status can be assigned for each kex. The IANA page also does not mention= all algorithm and I have not found documentation for all suites found in t= he manual.

 

Updating the different algorithm should consider tw= o aspects: security and interoperability, which means a SHOULD NOT status i= s expected to be done for a cipher suite with a SHOULD status. In other words going from MUST to SHOULD NOT should be av= oided unless there are strong reasons to do so. So maybe we should do a lit= tle bit more cleanup.

 

I do not know the current status for SSH but it wou= ld be good to end up in group1 and SHA1 set to MUST NOT – eventually = SHOULD NOT later being updated to MUST NOT.

 

SHA256 set to MUST, SHA386 to MAY and SHA512 set to= SHOULD to have it ready when SHA256 will be replaced.

 

Maybe we should also consider the current use of th= e various group, and those not widely used may be set to MAY.

 

BR,

Daniel

 

[1] http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-par= ameters-16

 

 

From: Curdle [mailto:curdle-bounces@= ietf.org] On Behalf Of denis bider (Bitvise)
Sent: Tuesday, August 16, 2016 5:19 PM
To: Curdle <curdle@ietf.org>
Cc: djm@mindrot.org; ietf-ssh@netbsd.org; Mark D. Baushke <mdb@ju= niper.net>
Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2=

 

Hello everyone,

 

this comment is with respect to the follo= wing draft specifying new Diffie-Hellman groups for SSH key exchange:<= /o:p>

 

 

The current version of the draft specifie= s the following:

 

  diffie-hellman-group14-sha256 = ;    MAY/OPTIONAL

  diffie-hellman-group16-sha512 = ;    SHOULD/RECOMMENDED

  diffie-hellman-group18-sha512 = ;    MAY/OPTIONAL

A previous version of this draft specifie= d the following methods:

 

 

  diffie-hellman-group14-sha256 = ;    MAY/OPTIONAL

  diffie-hellman-group15-sha512 = ;    MUST/REQUIRED/SHALL

  diffie-hellman-group16-sha512 = ;    SHOULD/RECOMMENDED

  diffie-hellman-group17-sha512 = ;    MAY/OPTIONAL

  diffie-hellman-group18-sha512 = ;    MAY/OPTIONAL

Note the presence of additional groups 15= and 17 which were removed in version 4 of the original Baushke draft.=

 

Groups 15 and 17 were removed based on fe= edback from one implementer. Basically, this feedback was one line:

 

> +1 to dropping the odd-numbered = groups and onlist listing group14/16/18

 

I would like to counter this, and move to= restore the previous table including groups 15 and 17 - or failing that, a= t least group 15 - with the same parameters as above, in version 3 of the original Baushke draft.

 

My reasons for proposing this are as foll= ows:

 

- According to NSA recommendations, the 3= 072-bit strength would be the current sweet spot between performance and ac= ceptable security. Group 15 is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.

 

- The additional security of group 16 in = comparison to group 15 is estimated to be small. Symmetric security estimat= es I've seen are 80 bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 (3072-bit). Ba= sed on this, I expect the security of group 16 (4096-bit) to be between 136= - 144 symmetric bits.

 

- Based on practical measurements, it app= ears that group 16 is about a factor of 2 slower than group 15. With group = 15, I'm getting about 20 full DH key exchanges per second; with group 16, I am getting around 10. I think this difference= is significant, and can affect real world usage scenarios on heavily loade= d servers.

 

At this time, I do not have a particular = need for group 17 (or 18), but I find it peculiar that this draft would not= specify a group that matches the exact recommended DH group size suggested by the NSA. It is weird that we have to choose eit= her between group 14, which does not meet the requirements; or group 16, wh= ich is significantly slower.

 

For our next Bitvise SSH Server and Clien= t versions, I have implemented support for groups 15 as well as 16, where g= roup 15 is implemented with SHA-512, as specified above. When using DH key exchange, our SSH Server will favor group 15, whe= reas group 16 will be disabled by default for performance (but it will be e= nabled and preferred in the SSH Client).

 

denis

 

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECAeusaamb107erics_-- From nobody Wed Aug 17 07:29:02 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B4912DD9F for ; Wed, 17 Aug 2016 07:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 w88GB6tx7sN7 for ; Wed, 17 Aug 2016 07:28:58 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCAD12D995 for ; Wed, 17 Aug 2016 07:28:57 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id k90so174196848uak.1 for ; Wed, 17 Aug 2016 07:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=T9kKa6BqPFLcVAuE7JY3GN4ib8aGOGMULj4ESzxfFBc=; b=m1FdgWoL5DBhQQlOI5TaX1TQPbuUvwYt8VDXwgqFP5WH7DTId5llQlhcErsEFXFtC5 Xup0pjmrwG6rX9jDO1hGPb4TtYX6b4m72cFsZfvmGYXnUucBlcPIXMzwwnCBSOjwZRaO 1Ax/JVtlqWm4Lap5W+XuP+KOX21z7cebAitkvRAkblDegbyX0VklqPCGAtVoHzoUcjHS J1uq5NmjZiZ/DmfySXgnGsTMz7zN6x+lkOWMhpvZ6zvWuI2AWNksN5TqTfo0fbfTIvy7 92S2QYPcsMQ1/KneI3/G2Zbffju13q50tvhNMLqYtBFCRM5NokiWKayO3wRHzCYrEVwz 2/7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=T9kKa6BqPFLcVAuE7JY3GN4ib8aGOGMULj4ESzxfFBc=; b=f7/iC4Jb3BxyGgRq+okuovYUSxxj3OqPAnhIjNc+tfBnWU7IWAaB5v3LrQ3h8SIjnr 0L0h1ga4QRNVzjRX/lZZguXdOOuTUMpoyeL3Q65o/2c0Bei6/rcqxiPmIJZ3lHoyDCw1 arOnUGFtTY7TxB2hYZjXFcbZUlGOw0gvcfyFZ4DyU/6jTj+F2RnfnIzO0q+Frds09+ZC IXW2S7DndQtUyyvFu7VtNUrBdfOnUUtjNKfn56Eh5SOSggxzPOfXivsIIKCdQjIF73EI ygXdi28UTQjnlJC+EwBlRidIflpPRxwHcIfctFqp2w4e1xZXfuWoC669j3TzkUv/7lvm gKkQ== X-Gm-Message-State: AEkoouv0PvyFTYQUrXsgQtJIGKuyE3pIPCwCPsfjK5NTkAnPomAemoFH/Xw/qQu3dmnWybRvuXiQOxeYzi2ywg== X-Received: by 10.176.4.85 with SMTP id 79mr5924193uav.56.1471444136650; Wed, 17 Aug 2016 07:28:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Wed, 17 Aug 2016 07:28:56 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> From: Watson Ladd Date: Wed, 17 Aug 2016 07:28:56 -0700 Message-ID: To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "denis bider \(Bitvise\)" , "djm@mindrot.org" , "ietf-ssh@netbsd.org" , Curdle , "Mark D. Baushke" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:29:01 -0000 On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault wrote: > Hi, > > > > > > Going briefly through the draft, it seems redundant to have MAY/OPTIONAL, > SHOULD/RECOMMENDED, MAY/OPTIONAL. I am not sure this does not result in = a > combination of recommendation for the users as well as a recommendation o= n > algorithms to implement. I would recommend we only focus on requirements = for > algorithm implementation. We should also specify that all non specified > algorithms in this document are =E2=80=9CMAY=E2=80=9D. There must be a single algorithm that everyone is required to implement. Make it P256 SHA2. Do not make it P384. There are no efficient constant time implementations. (I have written a constant time P384 this summer at Mozilla: it is not that fast). By contrast OpenSSL has a constant time P256 implementation (possibly not used by default: the rumors are unclear. Can you guys go ahead and ensure that it is used by default?) That's on top of everyone uses P256+SHA256. > > > > I have not found any recommendations for these algorithms at the IANA web > page [1], nor in another document. If that is the case, maybe this docume= nt > should clarify this so a status can be assigned for each kex. The IANA pa= ge > also does not mention all algorithm and I have not found documentation fo= r > all suites found in the manual. > > > > Updating the different algorithm should consider two aspects: security an= d > interoperability, which means a SHOULD NOT status is expected to be done = for > a cipher suite with a SHOULD status. In other words going from MUST to > SHOULD NOT should be avoided unless there are strong reasons to do so. So > maybe we should do a little bit more cleanup. > > > > I do not know the current status for SSH but it would be good to end up i= n > group1 and SHA1 set to MUST NOT =E2=80=93 eventually SHOULD NOT later bei= ng updated > to MUST NOT. > > > > SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it rea= dy > when SHA256 will be replaced. > > > > Maybe we should also consider the current use of the various group, and > those not widely used may be set to MAY. > > > > BR, > > Daniel > > > > [1] > http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-p= arameters-16 > > > > > > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of denis bider > (Bitvise) > Sent: Tuesday, August 16, 2016 5:19 PM > To: Curdle > Cc: djm@mindrot.org; ietf-ssh@netbsd.org; Mark D. Baushke > Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 > > > > Hello everyone, > > > > this comment is with respect to the following draft specifying new > Diffie-Hellman groups for SSH key exchange: > > > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03 > > > > The current version of the draft specifies the following: > > > > diffie-hellman-group14-sha256 MAY/OPTIONAL > > diffie-hellman-group16-sha512 SHOULD/RECOMMENDED > > diffie-hellman-group18-sha512 MAY/OPTIONAL > > A previous version of this draft specified the following methods: > > > > https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03 > > > > diffie-hellman-group14-sha256 MAY/OPTIONAL > > diffie-hellman-group15-sha512 MUST/REQUIRED/SHALL > > diffie-hellman-group16-sha512 SHOULD/RECOMMENDED > > diffie-hellman-group17-sha512 MAY/OPTIONAL > > diffie-hellman-group18-sha512 MAY/OPTIONAL > > Note the presence of additional groups 15 and 17 which were removed in > version 4 of the original Baushke draft. > > > > Groups 15 and 17 were removed based on feedback from one implementer. > Basically, this feedback was one line: > > > >> +1 to dropping the odd-numbered groups and onlist listing group14/16/18 > > > > I would like to counter this, and move to restore the previous table > including groups 15 and 17 - or failing that, at least group 15 - with th= e > same parameters as above, in version 3 of the original Baushke draft. > > > > My reasons for proposing this are as follows: > > > > - According to NSA recommendations, the 3072-bit strength would be the > current sweet spot between performance and acceptable security. Group 15 = is > 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit. > > > > - The additional security of group 16 in comparison to group 15 is estima= ted > to be small. Symmetric security estimates I've seen are 80 bits for group= 1 > (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 > (3072-bit). Based on this, I expect the security of group 16 (4096-bit) t= o > be between 136 - 144 symmetric bits. > > > > - Based on practical measurements, it appears that group 16 is about a > factor of 2 slower than group 15. With group 15, I'm getting about 20 ful= l > DH key exchanges per second; with group 16, I am getting around 10. I thi= nk > this difference is significant, and can affect real world usage scenarios= on > heavily loaded servers. > > > > At this time, I do not have a particular need for group 17 (or 18), but I > find it peculiar that this draft would not specify a group that matches t= he > exact recommended DH group size suggested by the NSA. It is weird that we > have to choose either between group 14, which does not meet the > requirements; or group 16, which is significantly slower. > > > > For our next Bitvise SSH Server and Client versions, I have implemented > support for groups 15 as well as 16, where group 15 is implemented with > SHA-512, as specified above. When using DH key exchange, our SSH Server w= ill > favor group 15, whereas group 16 will be disabled by default for performa= nce > (but it will be enabled and preferred in the SSH Client). > > > > denis > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Aug 17 07:30:38 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060D512DDBA for ; Wed, 17 Aug 2016 07:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 O6xc53aQOAR8 for ; Wed, 17 Aug 2016 07:30:36 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E07F412DDB6 for ; Wed, 17 Aug 2016 07:30:35 -0700 (PDT) Received: from [10.32.60.107] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7HEUQt0048962 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2016 07:30:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.107] From: "Paul Hoffman" To: "Peter Gutmann" Date: Wed, 17 Aug 2016 07:30:26 -0700 Message-ID: In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Curdle Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:30:37 -0000 On 17 Aug 2016, at 4:26, Peter Gutmann wrote: > A further comment on the draft: > > The United States Information Assurance Directorate (IAD) at the > National Security Agency (NSA) has published a FAQ > [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve > Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based > hashes > less than SHA2-384 are no longer sufficient for transport of Top > Secret information. It is for this reason that this draft moves > ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange > method. > > So you've got an arbitrary ruling by some random US govt. agency > that's > dictating how the entire world's SSH implementations have to function > (sigh). > We know from global TLS scans that pretty much the entire planet uses > SHA-256, > with SHA-384 and SHA-512 essentially lost in the noise. However, this > spec is > making the universal worldwide standard a MAY and the least-used form > of the > entire SHA-2 family a MUST. If the NSA's IAD wants to use whatever > weird > config they decide on they can create their own spec (Suite B, > anyone?), but a > global standard should go with whatever the world as a whole has > decided on, > and that's overwhelmingly SHA-256. +1 to Peter's comment. The fact that the NSA has two levels of "must never be exposed to anyone" that are poorly understood even within their own government doesn't mean that the IETF should follow suit. --Paul Hoffman From nobody Wed Aug 17 07:40:51 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AED512DE7B for ; Wed, 17 Aug 2016 07:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmGigmdo8fFQ for ; Wed, 17 Aug 2016 07:40:47 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6950F12D992 for ; Wed, 17 Aug 2016 07:40:47 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-be-57b478567b4c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by (Symantec Mail Security) with SMTP id 98.B2.02568.65874B75; Wed, 17 Aug 2016 16:44:38 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0301.000; Wed, 17 Aug 2016 10:35:41 -0400 From: Daniel Migault To: Watson Ladd Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwxyfnHXpgoEakB10teLEFZ6BNHKVggABdwAD//75NEA== Date: Wed, 17 Aug 2016 14:35:40 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BEFD@eusaamb107.ericsson.se> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <2DD56D786E600F45AC6BDE7DA4E8A8C117F5BECA@eusaamb107.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPrG5YxZZwg1NP9Sy2LpzFbHHl2zMm i3svpzBafLj3mM2i6851NouezpNsDmwe96fPY/fYOesuu8eSJT+ZPK43XWX3+Papnc1j4cMe xgC2KC6blNSczLLUIn27BK6Mszd7GQs+uFe0PLzE3sDY4tbFyMkhIWAiMedABzOILSSwgVHi 1pMKCHs5o8T826UgNpuAkUTboX52EFtEQF1iwvJNLF2MXBzMAqcZJfb1b2IESQgLeEgcnPmR CaLIU+Li9ttADRxAtpPEtzVRIGEWAVWJtpMbWEFsXgFfiVPv7rGDzBES2McocfPOcbBeToFA iRlvv4IVMQqISXw/tQYsziwgDnTbfCaIowUkluw5zwxhi0q8fPyPFcJWkpi09BwryF5mAU2J 9bv0IVoVJaZ0P2SH2CsocXLmE5YJjKKzkEydhdAxC0nHLCQdCxhZVjFylBYX5OSmGxlsYgRG 1jEJNt0djPenex5iFOBgVOLhXRCyOVyINbGsuDL3EKMEB7OSCO/awi3hQrwpiZVVqUX58UWl OanFhxilOViUxHnFHimGCwmkJ5akZqemFqQWwWSZODilGhitdPdaJl946lvHV/moLu7JnZ8h +8W/3uRn/FCudVz+0c6M11kf2bKLyvbxiBfJV9fPdf2/9/GSCoXyJ4+NGCaWV/zmicpZFXzB UGFa82quB4ey29jWh4tEuqY3r30YtHyDbl7BjOffv8QdZVpS0F14tiLkwbRAiUnPsz4tPlR9 34i31S7+h7ASS3FGoqEWc1FxIgAY6z/+qAIAAA== Archived-At: Cc: "denis bider \(Bitvise\)" , "djm@mindrot.org" , "ietf-ssh@netbsd.org" , Curdle , "Mark D. Baushke" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:40:50 -0000 SWYgdGhhdCBpcyB0aGUgZGVmYXVsdCwgaXQgd291bGQgZWFzZSB0byBkZXByZWNhdGUgd2hhdCB3 ZSB3YW50IHRvIGRlcHJlY2F0ZS4gQW5kIEkgYWdyZWUgaXRzIHN0YXR1cyBzaG91bGQgYmUgaW5k aWNhdGVkIGluIHRoZSBkcmFmdC4NCg0KQlIsIA0KRGFuaWVsDQoNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFdhdHNvbiBMYWRkIFttYWlsdG86d2F0c29uYmxhZGRAZ21haWwu Y29tXSANClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE3LCAyMDE2IDEwOjI5IEFNDQpUbzogRGFu aWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4NCkNjOiBkZW5pcyBiaWRl ciAoQml0dmlzZSkgPGlldGYtc3NoM0BkZW5pc2JpZGVyLmNvbT47IEN1cmRsZSA8Y3VyZGxlQGll dGYub3JnPjsgZGptQG1pbmRyb3Qub3JnOyBpZXRmLXNzaEBuZXRic2Qub3JnOyBNYXJrIEQuIEJh dXNoa2UgPG1kYkBqdW5pcGVyLm5ldD4NClN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBHcm91cCAxNSBu ZWVkZWQgaW4gZHJhZnQtYmF1c2hrZS1zc2gtZGgtZ3JvdXAtc2hhMg0KDQpPbiBXZWQsIEF1ZyAx NywgMjAxNiBhdCA3OjE1IEFNLCBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nz b24uY29tPiB3cm90ZToNCj4gSGksDQo+DQo+DQo+DQo+DQo+DQo+IEdvaW5nIGJyaWVmbHkgdGhy b3VnaCB0aGUgZHJhZnQsIGl0IHNlZW1zIHJlZHVuZGFudCB0byBoYXZlIA0KPiBNQVkvT1BUSU9O QUwsIFNIT1VMRC9SRUNPTU1FTkRFRCwgTUFZL09QVElPTkFMLiAgSSBhbSBub3Qgc3VyZSB0aGlz IA0KPiBkb2VzIG5vdCByZXN1bHQgaW4gYSBjb21iaW5hdGlvbiBvZiByZWNvbW1lbmRhdGlvbiBm b3IgdGhlIHVzZXJzIGFzIA0KPiB3ZWxsIGFzIGEgcmVjb21tZW5kYXRpb24gb24gYWxnb3JpdGht cyB0byBpbXBsZW1lbnQuIEkgd291bGQgcmVjb21tZW5kIA0KPiB3ZSBvbmx5IGZvY3VzIG9uIHJl cXVpcmVtZW50cyBmb3IgYWxnb3JpdGhtIGltcGxlbWVudGF0aW9uLiBXZSBzaG91bGQgDQo+IGFs c28gc3BlY2lmeSB0aGF0IGFsbCBub24gc3BlY2lmaWVkIGFsZ29yaXRobXMgaW4gdGhpcyBkb2N1 bWVudCBhcmUg4oCcTUFZ4oCdLg0KDQpUaGVyZSBtdXN0IGJlIGEgc2luZ2xlIGFsZ29yaXRobSB0 aGF0IGV2ZXJ5b25lIGlzIHJlcXVpcmVkIHRvIGltcGxlbWVudC4gTWFrZSBpdCBQMjU2IFNIQTIu IERvIG5vdCBtYWtlIGl0IFAzODQuIFRoZXJlIGFyZSBubyBlZmZpY2llbnQgY29uc3RhbnQgdGlt ZSBpbXBsZW1lbnRhdGlvbnMuIChJIGhhdmUgd3JpdHRlbiBhIGNvbnN0YW50IHRpbWUgUDM4NCB0 aGlzIHN1bW1lciBhdCBNb3ppbGxhOiBpdCBpcyBub3QgdGhhdCBmYXN0KS4gQnkgY29udHJhc3Qg T3BlblNTTCBoYXMgYSBjb25zdGFudCB0aW1lIFAyNTYgaW1wbGVtZW50YXRpb24gKHBvc3NpYmx5 IG5vdCB1c2VkIGJ5DQpkZWZhdWx0OiB0aGUgcnVtb3JzIGFyZSB1bmNsZWFyLiBDYW4geW91IGd1 eXMgZ28gYWhlYWQgYW5kIGVuc3VyZSB0aGF0IGl0IGlzIHVzZWQgYnkgZGVmYXVsdD8pDQoNClRo YXQncyBvbiB0b3Agb2YgZXZlcnlvbmUgdXNlcyBQMjU2K1NIQTI1Ni4NCg0KPg0KPg0KPg0KPiBJ IGhhdmUgbm90IGZvdW5kIGFueSByZWNvbW1lbmRhdGlvbnMgZm9yIHRoZXNlIGFsZ29yaXRobXMg YXQgdGhlIElBTkEgDQo+IHdlYiBwYWdlIFsxXSwgbm9yIGluIGFub3RoZXIgZG9jdW1lbnQuIElm IHRoYXQgaXMgdGhlIGNhc2UsIG1heWJlIHRoaXMgDQo+IGRvY3VtZW50IHNob3VsZCBjbGFyaWZ5 IHRoaXMgc28gYSBzdGF0dXMgY2FuIGJlIGFzc2lnbmVkIGZvciBlYWNoIGtleC4gDQo+IFRoZSBJ QU5BIHBhZ2UgYWxzbyBkb2VzIG5vdCBtZW50aW9uIGFsbCBhbGdvcml0aG0gYW5kIEkgaGF2ZSBu b3QgZm91bmQgDQo+IGRvY3VtZW50YXRpb24gZm9yIGFsbCBzdWl0ZXMgZm91bmQgaW4gdGhlIG1h bnVhbC4NCj4NCj4NCj4NCj4gVXBkYXRpbmcgdGhlIGRpZmZlcmVudCBhbGdvcml0aG0gc2hvdWxk IGNvbnNpZGVyIHR3byBhc3BlY3RzOiBzZWN1cml0eSANCj4gYW5kIGludGVyb3BlcmFiaWxpdHks IHdoaWNoIG1lYW5zIGEgU0hPVUxEIE5PVCBzdGF0dXMgaXMgZXhwZWN0ZWQgdG8gDQo+IGJlIGRv bmUgZm9yIGEgY2lwaGVyIHN1aXRlIHdpdGggYSBTSE9VTEQgc3RhdHVzLiBJbiBvdGhlciB3b3Jk cyBnb2luZyANCj4gZnJvbSBNVVNUIHRvIFNIT1VMRCBOT1Qgc2hvdWxkIGJlIGF2b2lkZWQgdW5s ZXNzIHRoZXJlIGFyZSBzdHJvbmcgDQo+IHJlYXNvbnMgdG8gZG8gc28uIFNvIG1heWJlIHdlIHNo b3VsZCBkbyBhIGxpdHRsZSBiaXQgbW9yZSBjbGVhbnVwLg0KPg0KPg0KPg0KPiBJIGRvIG5vdCBr bm93IHRoZSBjdXJyZW50IHN0YXR1cyBmb3IgU1NIIGJ1dCBpdCB3b3VsZCBiZSBnb29kIHRvIGVu ZCANCj4gdXAgaW4NCj4gZ3JvdXAxIGFuZCBTSEExIHNldCB0byBNVVNUIE5PVCDigJMgZXZlbnR1 YWxseSBTSE9VTEQgTk9UIGxhdGVyIGJlaW5nIA0KPiB1cGRhdGVkIHRvIE1VU1QgTk9ULg0KPg0K Pg0KPg0KPiBTSEEyNTYgc2V0IHRvIE1VU1QsIFNIQTM4NiB0byBNQVkgYW5kIFNIQTUxMiBzZXQg dG8gU0hPVUxEIHRvIGhhdmUgaXQgDQo+IHJlYWR5IHdoZW4gU0hBMjU2IHdpbGwgYmUgcmVwbGFj ZWQuDQo+DQo+DQo+DQo+IE1heWJlIHdlIHNob3VsZCBhbHNvIGNvbnNpZGVyIHRoZSBjdXJyZW50 IHVzZSBvZiB0aGUgdmFyaW91cyBncm91cCwgDQo+IGFuZCB0aG9zZSBub3Qgd2lkZWx5IHVzZWQg bWF5IGJlIHNldCB0byBNQVkuDQo+DQo+DQo+DQo+IEJSLA0KPg0KPiBEYW5pZWwNCj4NCj4NCj4N Cj4gWzFdDQo+IGh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvc3NoLXBhcmFtZXRlcnMv c3NoLXBhcmFtZXRlcnMueGh0bWwjc3MNCj4gaC1wYXJhbWV0ZXJzLTE2DQo+DQo+DQo+DQo+DQo+ DQo+IEZyb206IEN1cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgZGVuaXMgYmlkZXINCj4gKEJpdHZpc2UpDQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAx NiwgMjAxNiA1OjE5IFBNDQo+IFRvOiBDdXJkbGUgPGN1cmRsZUBpZXRmLm9yZz4NCj4gQ2M6IGRq bUBtaW5kcm90Lm9yZzsgaWV0Zi1zc2hAbmV0YnNkLm9yZzsgTWFyayBELiBCYXVzaGtlIA0KPiA8 bWRiQGp1bmlwZXIubmV0Pg0KPiBTdWJqZWN0OiBbQ3VyZGxlXSBHcm91cCAxNSBuZWVkZWQgaW4g ZHJhZnQtYmF1c2hrZS1zc2gtZGgtZ3JvdXAtc2hhMg0KPg0KPg0KPg0KPiBIZWxsbyBldmVyeW9u ZSwNCj4NCj4NCj4NCj4gdGhpcyBjb21tZW50IGlzIHdpdGggcmVzcGVjdCB0byB0aGUgZm9sbG93 aW5nIGRyYWZ0IHNwZWNpZnlpbmcgbmV3IA0KPiBEaWZmaWUtSGVsbG1hbiBncm91cHMgZm9yIFNT SCBrZXkgZXhjaGFuZ2U6DQo+DQo+DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWN1cmRsZS1zc2gta2V4LXNoYTItMDMNCj4NCj4NCj4NCj4gVGhlIGN1cnJlbnQg dmVyc2lvbiBvZiB0aGUgZHJhZnQgc3BlY2lmaWVzIHRoZSBmb2xsb3dpbmc6DQo+DQo+DQo+DQo+ ICAgZGlmZmllLWhlbGxtYW4tZ3JvdXAxNC1zaGEyNTYgICAgIE1BWS9PUFRJT05BTA0KPg0KPiAg IGRpZmZpZS1oZWxsbWFuLWdyb3VwMTYtc2hhNTEyICAgICBTSE9VTEQvUkVDT01NRU5ERUQNCj4N Cj4gICBkaWZmaWUtaGVsbG1hbi1ncm91cDE4LXNoYTUxMiAgICAgTUFZL09QVElPTkFMDQo+DQo+ IEEgcHJldmlvdXMgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0IHNwZWNpZmllZCB0aGUgZm9sbG93aW5n IG1ldGhvZHM6DQo+DQo+DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i YXVzaGtlLXNzaC1kaC1ncm91cC1zaGEyLTAzDQo+DQo+DQo+DQo+ICAgZGlmZmllLWhlbGxtYW4t Z3JvdXAxNC1zaGEyNTYgICAgIE1BWS9PUFRJT05BTA0KPg0KPiAgIGRpZmZpZS1oZWxsbWFuLWdy b3VwMTUtc2hhNTEyICAgICBNVVNUL1JFUVVJUkVEL1NIQUxMDQo+DQo+ICAgZGlmZmllLWhlbGxt YW4tZ3JvdXAxNi1zaGE1MTIgICAgIFNIT1VMRC9SRUNPTU1FTkRFRA0KPg0KPiAgIGRpZmZpZS1o ZWxsbWFuLWdyb3VwMTctc2hhNTEyICAgICBNQVkvT1BUSU9OQUwNCj4NCj4gICBkaWZmaWUtaGVs bG1hbi1ncm91cDE4LXNoYTUxMiAgICAgTUFZL09QVElPTkFMDQo+DQo+IE5vdGUgdGhlIHByZXNl bmNlIG9mIGFkZGl0aW9uYWwgZ3JvdXBzIDE1IGFuZCAxNyB3aGljaCB3ZXJlIHJlbW92ZWQgaW4g DQo+IHZlcnNpb24gNCBvZiB0aGUgb3JpZ2luYWwgQmF1c2hrZSBkcmFmdC4NCj4NCj4NCj4NCj4g R3JvdXBzIDE1IGFuZCAxNyB3ZXJlIHJlbW92ZWQgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSBvbmUg aW1wbGVtZW50ZXIuDQo+IEJhc2ljYWxseSwgdGhpcyBmZWVkYmFjayB3YXMgb25lIGxpbmU6DQo+ DQo+DQo+DQo+PiArMSB0byBkcm9wcGluZyB0aGUgb2RkLW51bWJlcmVkIGdyb3VwcyBhbmQgb25s aXN0IGxpc3RpbmcgDQo+PiArZ3JvdXAxNC8xNi8xOA0KPg0KPg0KPg0KPiBJIHdvdWxkIGxpa2Ug dG8gY291bnRlciB0aGlzLCBhbmQgbW92ZSB0byByZXN0b3JlIHRoZSBwcmV2aW91cyB0YWJsZSAN Cj4gaW5jbHVkaW5nIGdyb3VwcyAxNSBhbmQgMTcgLSBvciBmYWlsaW5nIHRoYXQsIGF0IGxlYXN0 IGdyb3VwIDE1IC0gd2l0aCANCj4gdGhlIHNhbWUgcGFyYW1ldGVycyBhcyBhYm92ZSwgaW4gdmVy c2lvbiAzIG9mIHRoZSBvcmlnaW5hbCBCYXVzaGtlIGRyYWZ0Lg0KPg0KPg0KPg0KPiBNeSByZWFz b25zIGZvciBwcm9wb3NpbmcgdGhpcyBhcmUgYXMgZm9sbG93czoNCj4NCj4NCj4NCj4gLSBBY2Nv cmRpbmcgdG8gTlNBIHJlY29tbWVuZGF0aW9ucywgdGhlIDMwNzItYml0IHN0cmVuZ3RoIHdvdWxk IGJlIHRoZSANCj4gY3VycmVudCBzd2VldCBzcG90IGJldHdlZW4gcGVyZm9ybWFuY2UgYW5kIGFj Y2VwdGFibGUgc2VjdXJpdHkuIEdyb3VwIA0KPiAxNSBpcyAzMDcyLWJpdCwgd2hlcmVhcyBncm91 cHMgMTQgYW5kIDE2IGFyZSAyMDQ4LSBhbmQgNDA5Ni1iaXQuDQo+DQo+DQo+DQo+IC0gVGhlIGFk ZGl0aW9uYWwgc2VjdXJpdHkgb2YgZ3JvdXAgMTYgaW4gY29tcGFyaXNvbiB0byBncm91cCAxNSBp cyANCj4gZXN0aW1hdGVkIHRvIGJlIHNtYWxsLiBTeW1tZXRyaWMgc2VjdXJpdHkgZXN0aW1hdGVz IEkndmUgc2VlbiBhcmUgODAgDQo+IGJpdHMgZm9yIGdyb3VwIDEgKDEwMjQtYml0KSwgMTEyIGJp dHMgZm9yIGdyb3VwIDE0ICgyMDQ4LWJpdCksIGFuZCAxMjggDQo+IGJpdHMgZm9yIGdyb3VwIDE1 ICgzMDcyLWJpdCkuIEJhc2VkIG9uIHRoaXMsIEkgZXhwZWN0IHRoZSBzZWN1cml0eSBvZiANCj4g Z3JvdXAgMTYgKDQwOTYtYml0KSB0byBiZSBiZXR3ZWVuIDEzNiAtIDE0NCBzeW1tZXRyaWMgYml0 cy4NCj4NCj4NCj4NCj4gLSBCYXNlZCBvbiBwcmFjdGljYWwgbWVhc3VyZW1lbnRzLCBpdCBhcHBl YXJzIHRoYXQgZ3JvdXAgMTYgaXMgYWJvdXQgYSANCj4gZmFjdG9yIG9mIDIgc2xvd2VyIHRoYW4g Z3JvdXAgMTUuIFdpdGggZ3JvdXAgMTUsIEknbSBnZXR0aW5nIGFib3V0IDIwIA0KPiBmdWxsIERI IGtleSBleGNoYW5nZXMgcGVyIHNlY29uZDsgd2l0aCBncm91cCAxNiwgSSBhbSBnZXR0aW5nIGFy b3VuZCANCj4gMTAuIEkgdGhpbmsgdGhpcyBkaWZmZXJlbmNlIGlzIHNpZ25pZmljYW50LCBhbmQg Y2FuIGFmZmVjdCByZWFsIHdvcmxkIA0KPiB1c2FnZSBzY2VuYXJpb3Mgb24gaGVhdmlseSBsb2Fk ZWQgc2VydmVycy4NCj4NCj4NCj4NCj4gQXQgdGhpcyB0aW1lLCBJIGRvIG5vdCBoYXZlIGEgcGFy dGljdWxhciBuZWVkIGZvciBncm91cCAxNyAob3IgMTgpLCANCj4gYnV0IEkgZmluZCBpdCBwZWN1 bGlhciB0aGF0IHRoaXMgZHJhZnQgd291bGQgbm90IHNwZWNpZnkgYSBncm91cCB0aGF0IA0KPiBt YXRjaGVzIHRoZSBleGFjdCByZWNvbW1lbmRlZCBESCBncm91cCBzaXplIHN1Z2dlc3RlZCBieSB0 aGUgTlNBLiBJdCANCj4gaXMgd2VpcmQgdGhhdCB3ZSBoYXZlIHRvIGNob29zZSBlaXRoZXIgYmV0 d2VlbiBncm91cCAxNCwgd2hpY2ggZG9lcyANCj4gbm90IG1lZXQgdGhlIHJlcXVpcmVtZW50czsg b3IgZ3JvdXAgMTYsIHdoaWNoIGlzIHNpZ25pZmljYW50bHkgc2xvd2VyLg0KPg0KPg0KPg0KPiBG b3Igb3VyIG5leHQgQml0dmlzZSBTU0ggU2VydmVyIGFuZCBDbGllbnQgdmVyc2lvbnMsIEkgaGF2 ZSANCj4gaW1wbGVtZW50ZWQgc3VwcG9ydCBmb3IgZ3JvdXBzIDE1IGFzIHdlbGwgYXMgMTYsIHdo ZXJlIGdyb3VwIDE1IGlzIA0KPiBpbXBsZW1lbnRlZCB3aXRoIFNIQS01MTIsIGFzIHNwZWNpZmll ZCBhYm92ZS4gV2hlbiB1c2luZyBESCBrZXkgDQo+IGV4Y2hhbmdlLCBvdXIgU1NIIFNlcnZlciB3 aWxsIGZhdm9yIGdyb3VwIDE1LCB3aGVyZWFzIGdyb3VwIDE2IHdpbGwgYmUgDQo+IGRpc2FibGVk IGJ5IGRlZmF1bHQgZm9yIHBlcmZvcm1hbmNlIChidXQgaXQgd2lsbCBiZSBlbmFibGVkIGFuZCBw cmVmZXJyZWQgaW4gdGhlIFNTSCBDbGllbnQpLg0KPg0KPg0KPg0KPiBkZW5pcw0KPg0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBD dXJkbGUgbWFpbGluZyBsaXN0DQo+IEN1cmRsZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1cmRsZQ0KPg0KDQoNCg0KLS0NCiJNYW4gaXMgYm9ybiBm cmVlLCBidXQgZXZlcnl3aGVyZSBoZSBpcyBpbiBjaGFpbnMiLg0KLS1Sb3Vzc2VhdS4NCg== From nobody Wed Aug 17 07:55:30 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E2E12DF5E for ; Wed, 17 Aug 2016 07:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8sGo8zenwZ_w for ; Wed, 17 Aug 2016 07:55:26 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C161512D74D for ; Wed, 17 Aug 2016 07:55:22 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id d10so34244500ybi.1 for ; Wed, 17 Aug 2016 07:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9EEHu6v1XhIoEgX1GB6d6PQUlEu0TZoQQCild5pGOwE=; b=XOfZzv49dT744Xe+ETvYtcTPZbIepfaWWLutdRaaktUsFIVs9Dbh8+yvJgYT363w1j xGmTyh/d2/ZhsrHYX7r6RAXX1bOeBp1l2ID9K8q0967ho1H3gstEgK+qJil/K45q7jih ShrRTMBLoURT/OUoZtwh3LPpbQbrurgLoksGovRWUUdhX+iWf2+iJfRac57bpp1EVjQa yCVAyWmzgAVFdTjhDx8xoqK/Fi9DkdmJx1kUzVlGRO5UlNJidjI2KZQYUaYFgChWhKDV 9mwd/Zj68/QxUNqwsJdbvkAudVwaNGRM6yJJnQ1f6nt1IS69ynjCmoCscNG2h+oymNLe oiLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9EEHu6v1XhIoEgX1GB6d6PQUlEu0TZoQQCild5pGOwE=; b=NpER22i+dxBHleJxslPomJJjV/PFmjwW1U5nTm/4NLVSI2235xxwVSfFXw6aPQhlOI qEPgYTHnhOGHNhRhw6jgbPT/FAzflm0YmkoNw01C5O8Ejd6gAn50MFTB5Qu7341I6JQ1 dPU8SEjMQxJ1OGZW5jtj/vFVN09p+5lijgIMkGzDgxwOcIAuz+/EMMnhF8FWLXcqW/4J G8EYfeOMCiElplribqHgJhlaO2x9TUlkAP4Fswle4m220/a2FaPJBc8NaDQN4QAS9ahw 8B0kPnh6Vi3oGmhRaXO/Aa+1AoyV2XTjHN3AzRyDitmkznu/20NBbTC/O/EIperoIj0Z PQHQ== X-Gm-Message-State: AEkoousb88BwnZ+nOmLLo3axHRKEz2hVR5eEjDRxfXvjzvvsNbgjMNQsndzqc/mtRGe5Cw== X-Received: by 10.37.217.129 with SMTP id q123mr27498895ybg.27.1471445721848; Wed, 17 Aug 2016 07:55:21 -0700 (PDT) Received: from galifrey.hallambaker.com (pool-173-48-179-147.bstnma.fios.verizon.net. [173.48.179.147]) by smtp.gmail.com with ESMTPSA id p21sm15493728ywg.10.2016.08.17.07.55.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Aug 2016 07:55:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phill In-Reply-To: Date: Wed, 17 Aug 2016 10:55:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> To: Paul Hoffman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Curdle , Peter Gutmann Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:55:28 -0000 I think we are getting into the weeds here. The point of standards is to = ensure interoperability. The only reason NIST/NSA has any particular = significance is that they have a lot of users of crypto and they have a = huge amount of purchasing power. =46rom an IETF perspective, I want exactly two algorithm choices, one = that is very secure and one that is ridiculously secure. I see no value = in IETF endorsing anything else. By =E2=80=98very secure=E2=80=99 I mean = a work factor of 2^128 (WF128) and by ridiculously secure I mean a work = factor of 2^256. In the age when Quantum Computing is starting to look = as if it may be feasible, a 2^256 () conventional work factor isn=E2=80=99= t insane. So I see 6 classes of crypto 1a) MUST NOT: Stuff we know is bad and there is no reason to use (MD4 = etc.) 1b) SHOULD NOT: Stuff we know is bad but is still needed for some legacy = systems (SHA-1) 2) MUST: The algorithm we think everything should support (SHA-2-256) 3) SHOULD: The backup algorithm (SHA-2-512) 4) MAY: Anything else that a client might need for interop in specific = environments. 5) - : That of which we remain silent (most algorithms) Rather than reading NIST docs and trying to interpret them, why not ask = NIST to write a draft specifying the set of suites to use and publish it = themselves or as a FIPS.=20 The thing is that we don=E2=80=99t have change control for that = particular use area and don=E2=80=99t want it. One set of choices I think we can dispense with is work factor WF192 = crypto. I can=E2=80=99t see any point to it. Either performance matters = a lot or it does not. If performance matters then you are going to be = sticking to WF128 algorithms. If not there is really no reason not to go = to WF256. Which is what I do anyway.= From nobody Wed Aug 17 08:35:26 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E950612D860 for ; Wed, 17 Aug 2016 08:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 1wYpXWSfJ79c for ; Wed, 17 Aug 2016 08:35:23 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0F212D800 for ; Wed, 17 Aug 2016 08:35:22 -0700 (PDT) Received: from hebrews (170.173.0.21) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 Aug 2016 08:47:10 -0700 From: Jim Schaad To: References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 17 Aug 2016 08:34:50 -0700 Message-ID: <064c01d1f89c$e61a3980$b24eac80$@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: AQHmq3PHmJZ1Zt4yMknvAsjdQB0DPgHHRDYKoBTpzjA= Content-Language: en-us X-Originating-IP: [170.173.0.21] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 15:35:25 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Tuesday, August 16, 2016 8:37 PM > To: Jim Schaad > Cc: curdle@ietf.org > Subject: Re: [Curdle] Ed25591ctx >=20 > On Tue, Aug 16, 2016 at 02:36:40PM -0700, Jim Schaad wrote: > > Ilari has done edits on a local draft to respond to my comments and = it > > appears he is planning on introducing a new mode to the EdDSA drafts > > for 25519. Specifically one would have: > > > > EdDSA25519 - the traditional signature algorithm EdDSA25519ctx - a = new > > mode for 25519 which has a context structure available to it. > > EdDSA25519pre - a pre-hash mode that uses the same structure as > > EdDSSA25519ctx >=20 > The names aren't right (the right ones are 'Ed25519ctx' and = 'Ed25519ph'), but > otherewise quite so (assuming contexts will be part of the document!) >=20 > > This means that we would no longer have the huge problem between ctx > > and pre hash modes conflicting quite as much as one could require = the > > use of ctx and pre instead. One still has the problems between pure = and the > other modes. >=20 > That change also solves the problem of using the same key for Ed25519 = and > Ed25519ph. I had forgotten about the use of the invalid point to make sure that = this was clean. >=20 > However, Ed25519ctx and Ed25519ph can't be computed using standard > Ed25519 software. There is no way to do so while remaining safe to = key- share. > Fortunately, the places that are modified are likely not to be too = inaccessable > (i.e. written in high-level-language) in practical implementations, if = you can > modify one. >=20 > > The questions I have are: > > > > Should we issue an OID for the new ctx mode? > > > > Should we require the use of the ctx mode for signing of = certificates? > > > > Should we have any advisory language which says that new usages = SHOULD > > use the ctx mode over the pure mode? >=20 > It occurs to me that one could avoid use of prehashed EdDSA variants = by adding > OID that is defined to sign a hash object[1] instead of the actual = data. If then > one could avoid contexts, one could just use standard-issue > Ed25519 code (which is dime dozen). >=20 > That could be also be used to avoid the potentially annoying SHAK256 = hashing if > one wants long-input Ed448. >=20 >=20 > While contexts could help against things like that TLS 1.2 LURK SKI = attack EKR > came up with, there are plenty of RSA or ECDSA keys that are = unprotected > against such abuse. >=20 > And then there is the issue that contexts are a new input, and many = signature > APIs just doesn't have it. My intent was not clear. I was indicating that we should use the = context version, but specify an empty context as would be done with the = Ed448 signature algorithm. This is not the point in time that I would = want to introduce a new parameter to signature and verification APIs. Jim >=20 > And with regards to new stuff using contexts, I think it is a bad = idea, unless the > stuff used only contextualized signatures. And PKIX fails that = criteria. >=20 >=20 >=20 > [1] One rough sketch (excuse me for not using the correct notation): >=20 > SEQUENCE { > OID > OCTET_STRING zeroes_64octets > AlgorithmIdentifier hash_algorithm > OCTET_STRING hash_value > } >=20 > DER-encode that (easily templateable if you know the hash, which would = come > from the signature algorithm OID) and use that as message for = algorithm. >=20 > The OID in the beginning is to distinguish it from other ASN.1 = structures. >=20 > I threw that zeroes_64octets in there to make it more difficult to = abuse with > TLS. >=20 > Specifically, valid TLS 1.3 signatures can't look like that because = those start with > 0x20, not 0x30 like that one does. >=20 > Nor can valid TLS 1.2 signatures, because that one presumably has a = zero in 65th > and 66th position, which would code curve type 0 > (undefined) for ECDHE and p=3D0 (division by zero) for DHE. >=20 > One minor problem being that it breaks a SHA-512 block (which is like = 2% speed > penalty for signing, less for verfication). >=20 >=20 >=20 >=20 > -Ilari From nobody Wed Aug 17 15:19:14 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E402D12D19F for ; Wed, 17 Aug 2016 15:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbD6E1MCWdQR for ; Wed, 17 Aug 2016 15:19:11 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D25C812D0FB for ; Wed, 17 Aug 2016 15:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=bhb9Ir3s3fFUi/AfAb2r1CN/D4135EwL8wYa78kjOd4=; b=L6hjEjlpT2n0pKRnV5JQWqeaZpaaBskaKAWPZ/rSpB+Ge2oQeHn78NkPKwL4SgoNXRoP/lC+tVH1G M4r+M0MHh9InU83fNDgOZl/7hepq0otwzadBPPptjNDhMqgwOlGiAz6GKUFBvOn/aLyaZ5MoExK7gt 7/8OQO6pExwZ+x2zGsfCrwanXmzCQBsxglJtQf19ekyBSX41yYAhgQ3fLZ7SW8HS76ytQxn5TtKt2H RwSTfE+wYucLMem+cOfGOloM5fIsHKRIwZWS0osyssE5k4v628JRbwzPOIimDUzjxdmwJ0/V2qtz5Y sNEf3Ihb2s0qI/buHmK33caMuAI05qA== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 17 Aug 2016 23:18:56 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Curdle" References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Date: Wed, 17 Aug 2016 16:18:09 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0174_01D1F8A2.F1B73080" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: Daniel Migault , Rich Salz , djm@mindrot.org, Paul Hoffman , "Mark D. Baushke" , Watson Ladd , Phill Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:19:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0174_01D1F8A2.F1B73080 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I perceive a substantial problem in the current tendency of IETF to try = to serve as a recommender, or even an authority on best practice, = instead of serving as a documenter and a dispassionate record of = existing work. When I implement a program or a solution, I do not ask = the IETF for suggestions on what to implement. I decide what to = implement based on real-world considerations that apply in my usage = case, and then consult IETF for documentation =E2=80=93 if any! = =E2=80=93 relating to the thing I=E2=80=99ve decided. I find there=E2=80=99s a disproportionate attitude, in this group and = elsewhere, presuming that the protocols that IETF documents are IETF = protocols. This is not the case. The IETF is not the final authority on = its protocols, the users are; and before the users, the implementers. To = the extent that the IETF wishes to not be obsolete, it must submit to = these final authorities, and document the protocols in the way they are = actually used, rather than in a way that seems to elevate the judgments = of people involved in the IETF process. The refusal of IETF to serve this role results in useful specifications = not ever making it to RFC, so that the role that used to be served by = documents in the RFC status (note that this stands for =E2=80=9CRequest = for comments=E2=80=9D!) is now increasingly being served by = hypothetically expiring Internet-Drafts, which really serve as actual = specifications for widely used internet protocols, such as SFTP, because = all we really want from a standards organization is the ability to = coordinate, and we are not so much interested in its efforts to = pontificate, opinionate, and mandate what=E2=80=99s to be done in = practice. The reason I say this is because the US federal government represents a = big chunk of end users who actually pay for software development, and = from the best of my impressions, their current recommendations appear = very reasonable. Based on articles that are now coming out with respect = to progress in the development of quantum computing, real quantum = computers are just around the corner, and when they arrive, 256-bit = elliptic curves that we are now recommending as =E2=80=9CMUST=E2=80=9D = everywhere will be the first to go. Guess which national intelligence = organization will be the first to have their own quantum computers, and = apply them generously to all of the Curve25519 traffic that they will = have recorded in preceding years, ready for cracking in their ample = storage? The desire to completely ignore the NSA just because they are not = entirely our ally is highly questionable, and counter-productive. = Chances are that they have more information about crypto cracking and = the future of quantum computing than any of us, and not only have a good = idea of the timeline, but also what they are going to do with it. They = are better informed about their own abilities than we are, so if they = say folks should use 3072-bit RSA and DH, and at least 384-bit hash = functions, I reckon we=E2=80=99re taking chances when we don=E2=80=99t = listen. A big chunk of users are going to heed these recommendations, and are = going to need a standards body that accommodates them. NIST is not going = to publish a spec on how to use 3072-bit DH with SHA-512 in SSH. But as = an implementer, I need to do this, and if IETF will not address this = case, then =E2=80=93 why would I need IETF, or respect any of its = specifications? From: Phill=20 Sent: Wednesday, August 17, 2016 08:55 To: Paul Hoffman=20 Cc: Curdle ; Peter Gutmann=20 Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 I think we are getting into the weeds here. The point of standards is to = ensure interoperability. The only reason NIST/NSA has any particular = significance is that they have a lot of users of crypto and they have a = huge amount of purchasing power. >From an IETF perspective, I want exactly two algorithm choices, one that = is very secure and one that is ridiculously secure. I see no value in = IETF endorsing anything else. By =E2=80=98very secure=E2=80=99 I mean a = work factor of 2^128 (WF128) and by ridiculously secure I mean a work = factor of 2^256. In the age when Quantum Computing is starting to look = as if it may be feasible, a 2^256 () conventional work factor = isn=E2=80=99t insane. So I see 6 classes of crypto 1a) MUST NOT: Stuff we know is bad and there is no reason to use (MD4 = etc.) 1b) SHOULD NOT: Stuff we know is bad but is still needed for some legacy = systems (SHA-1) 2) MUST: The algorithm we think everything should support (SHA-2-256) 3) SHOULD: The backup algorithm (SHA-2-512) 4) MAY: Anything else that a client might need for interop in specific = environments. 5) - : That of which we remain silent (most algorithms) Rather than reading NIST docs and trying to interpret them, why not ask = NIST to write a draft specifying the set of suites to use and publish it = themselves or as a FIPS.=20 The thing is that we don=E2=80=99t have change control for that = particular use area and don=E2=80=99t want it. One set of choices I think we can dispense with is work factor WF192 = crypto. I can=E2=80=99t see any point to it. Either performance matters = a lot or it does not. If performance matters then you are going to be = sticking to WF128 algorithms. If not there is really no reason not to go = to WF256. Which is what I do anyway. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle ------=_NextPart_000_0174_01D1F8A2.F1B73080 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I perceive a substantial problem in the current tendency of IETF to = try to=20 serve as a recommender, or even an authority on best practice, instead = of=20 serving as a documenter and a dispassionate record of existing work. = When I=20 implement a program or a solution, I do not ask the IETF for suggestions = on what=20 to implement. I decide what to implement based on real-world = considerations that=20 apply in my usage case, and then consult IETF for documentation = =E2=80=93 if any! =E2=80=93=20 relating to the thing I=E2=80=99ve decided.
 
I find there=E2=80=99s a disproportionate attitude, in this group = and elsewhere,=20 presuming that the protocols that IETF documents are IETF protocols. = This is not=20 the case. The IETF is not the final authority on its protocols, the = users are;=20 and before the users, the implementers. To the extent that the IETF = wishes to=20 not be obsolete, it must submit to these final authorities, and document = the=20 protocols in the way they are actually used, rather than in a way that = seems to=20 elevate the judgments of people involved in the IETF process.
 
The refusal of IETF to serve this role results in useful = specifications not=20 ever making it to RFC, so that the role that used to be served by = documents in=20 the RFC status (note that this stands for =E2=80=9CRequest for = comments=E2=80=9D!) is now=20 increasingly being served by hypothetically expiring Internet-Drafts, = which=20 really serve as actual specifications for widely used internet = protocols, such=20 as SFTP, because all we really want from a standards organization is the = ability=20 to coordinate, and we are not so much interested in its efforts to = pontificate,=20 opinionate, and mandate what=E2=80=99s to be done in practice.
 
The reason I say this is because the US federal government = represents a big=20 chunk of end users who actually pay for software development, and from = the best=20 of my impressions, their current recommendations appear very reasonable. = Based=20 on articles that are now coming out with respect to progress in the = development=20 of quantum computing, real quantum computers are just around the corner, = and=20 when they arrive, 256-bit elliptic curves that we are now recommending = as =E2=80=9CMUST=E2=80=9D=20 everywhere will be the first to go. Guess which national intelligence=20 organization will be the first to have their own quantum computers, and = apply=20 them generously to all of the Curve25519 traffic that they will have = recorded in=20 preceding years, ready for cracking in their ample storage?
 
The desire to completely ignore the NSA just because they are not = entirely=20 our ally is highly questionable, and counter-productive. Chances are = that they=20 have more information about crypto cracking and the future of quantum = computing=20 than any of us, and not only have a good idea of the timeline, but also = what=20 they are going to do with it. They are better informed about their own = abilities=20 than we are, so if they say folks should use 3072-bit RSA and DH, and at = least=20 384-bit hash functions, I reckon we=E2=80=99re taking chances when we = don=E2=80=99t=20 listen.
 
A big chunk of users are going to heed these recommendations, and = are going=20 to need a standards body that accommodates them. NIST is not going to = publish a=20 spec on how to use 3072-bit DH with SHA-512 in SSH. But as an = implementer, I=20 need to do this, and if IETF will not address this case, then =E2=80=93 = why would I need=20 IETF, or respect any of its specifications?
 
 
 
From: Phill
Sent: Wednesday, August 17, 2016 08:55
Subject: Re: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 
I=20 think we are getting into the weeds here. The point of standards is to = ensure=20 interoperability. The only reason NIST/NSA has any particular = significance is=20 that they have a lot of users of crypto and they have a huge amount of=20 purchasing power.

From an IETF perspective, I want exactly two = algorithm=20 choices, one that is very secure and one that is ridiculously secure. I = see no=20 value in IETF endorsing anything else. By =E2=80=98very secure=E2=80=99 = I mean a work factor of=20 2^128 (WF128) and by ridiculously secure I mean a work factor of 2^256. = In the=20 age when Quantum Computing is starting to look as if it may be feasible, = a 2^256=20 () conventional work factor isn=E2=80=99t insane.

So I see 6 = classes of=20 crypto

1a) MUST NOT: Stuff we know is bad and there is no reason = to use=20 (MD4 etc.)
1b) SHOULD NOT: Stuff we know is bad but is still needed = for some=20 legacy systems (SHA-1)
2) MUST: The algorithm we think everything = should=20 support (SHA-2-256)
3) SHOULD: The backup algorithm (SHA-2-512)
4) = MAY:=20 Anything else that a client might need for interop in specific=20 environments.
5) - : That of which we remain silent (most=20 algorithms)

Rather than reading NIST docs and trying to interpret = them,=20 why not ask NIST to write a draft specifying the set of suites to use = and=20 publish it themselves or as a FIPS.

The thing is that we = don=E2=80=99t have=20 change control for that particular use area and don=E2=80=99t want = it.


One=20 set of choices I think we can dispense with is work factor WF192 crypto. = I can=E2=80=99t=20 see any point to it. Either performance matters a lot or it does not. If = performance matters then you are going to be sticking to WF128 = algorithms. If=20 not there is really no reason not to go to WF256. Which is what I do=20 anyway.
_______________________________________________
Curdle = mailing=20 list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
------=_NextPart_000_0174_01D1F8A2.F1B73080-- From nobody Wed Aug 17 15:34:03 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F77D12D0CF for ; Wed, 17 Aug 2016 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 F7cVG8vPtdS7 for ; Wed, 17 Aug 2016 15:34:01 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6213F12B025 for ; Wed, 17 Aug 2016 15:34:01 -0700 (PDT) Received: from [10.32.60.107] (50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u7HMXwFA000201 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Aug 2016 15:33:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-193.dsl.dynamic.fusionbroadband.com [50.1.98.193] claimed to be [10.32.60.107] From: "Paul Hoffman" To: "denis bider" Date: Wed, 17 Aug 2016 15:33:58 -0700 Message-ID: In-Reply-To: References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Curdle Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:34:02 -0000 On 17 Aug 2016, at 15:18, denis bider (Bitvise) wrote: > A big chunk of users are going to heed these recommendations, It is developers that need the standards, not the users. The users will demand that certain standards they have heard of or are required to use in the software they purchase or download. > and are going to need a standards body that accommodates them. s/a standards body/standards/ If the IETF does not encode a standard that Some Government demands, someone else (hopefully That Government) will fill the gap. > NIST is not going to publish a spec on how to use 3072-bit DH with > SHA-512 in SSH. That seems like a harsh statement. NIST had multiple publishing arms; they could do it easily. Also, NIST has more than a handful of people who know how to write Internet-Drafts that could become Informational RFCs specifying how to implement what they want. > But as an implementer, I need to do this, and if IETF will not address > this case, then – why would I need IETF, or respect any of its > specifications? You don't "need" the IETF unless you want to follow the IETF's standards. If you have a better way to publish standards that are accepted by other developers who want to interoperate with you, you should do so. I say that in all seriousness: if you do a good job, the IETF can learn about our failings. (FWIW, I say this as a happy paying customer for your software.) --Paul Hoffman From nobody Wed Aug 17 15:47:52 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651912B074 for ; Wed, 17 Aug 2016 15:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYP9iBOuX8LM for ; Wed, 17 Aug 2016 15:47:39 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02B912D195 for ; Wed, 17 Aug 2016 15:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type:in-reply-to: references; bh=Pz983Gs7iJFMxJFDxYl0oqal3Ys7fWJ0O2w9dd//KRk=; b=OqVztG7pV7tftLyLPq1MZIPxjkFrAUJvwzqHehnJpuMsc06AAPUgni0fTf61lCIGvLDbuyS3cCf7E hIRe8HfVZbWw9tN3uPiJYE8vb3ZNqEp3ck+azbqHtcsw0ZTiKGMlJSuApJw5QjbZh4OrEWyu5CuUas brF7BzBXIKRnxVkvXdIyXdpdKPRiEFJLaNhFNXmHhi6NfnywTtZjdb7LftPgGLpuLJx9KHfpPkGGTA +YtWHuJjJ9rD/jZ9zdQO4It1TDT0v+piFYO3MgGukkNdOfQuZWL7b0ELwKDYMpKRgW3QCJAf61xui3 LFiWVKhFE6V8BN+CMCB5fY1y7Xoubsg== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Wed, 17 Aug 2016 23:47:25 +0100 Message-ID: <139AE5DDD8534EAABF2416122C7B0B83@Khan> From: "denis bider \(Bitvise\)" To: "Paul Hoffman" References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Date: Wed, 17 Aug 2016 16:47:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_027E_01D1F8A6.FC909B50" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: Curdle Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:47:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_027E_01D1F8A6.FC909B50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Paul: > You don't "need" the IETF unless you want to follow the IETF's=20 > standards. If you have a better way to publish standards that are=20 > accepted by other developers who want to interoperate with you, you=20 > should do so. I say that in all seriousness: if you do a good job, the = > IETF can learn about our failings.=20 Indeed, the thought has crossed my mind several times, but I=E2=80=99d = rather not have to. It would be much more efficient if the existing = standards body were to accept a more generous understanding of its role, = especially given that its flaws are incidental more so than fundamental. = Trying to improve existing systems is often frustrating, but if = successful, it=E2=80=99s more effective than creating a new one. > (FWIW, I say this as a happy paying customer for your software.) Much appreciated. :-) From: Paul Hoffman=20 Sent: Wednesday, August 17, 2016 16:33 To: denis bider=20 Cc: Curdle=20 Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 On 17 Aug 2016, at 15:18, denis bider (Bitvise) wrote: > A big chunk of users are going to heed these recommendations, It is developers that need the standards, not the users. The users will=20 demand that certain standards they have heard of or are required to use=20 in the software they purchase or download. > and are going to need a standards body that accommodates them. s/a standards body/standards/ If the IETF does not encode a standard=20 that Some Government demands, someone else (hopefully That Government)=20 will fill the gap. > NIST is not going to publish a spec on how to use 3072-bit DH with=20 > SHA-512 in SSH. That seems like a harsh statement. NIST had multiple publishing arms;=20 they could do it easily. Also, NIST has more than a handful of people=20 who know how to write Internet-Drafts that could become Informational=20 RFCs specifying how to implement what they want. > But as an implementer, I need to do this, and if IETF will not address = > this case, then =E2=80=93 why would I need IETF, or respect any of its = > specifications? You don't "need" the IETF unless you want to follow the IETF's=20 standards. If you have a better way to publish standards that are=20 accepted by other developers who want to interoperate with you, you=20 should do so. I say that in all seriousness: if you do a good job, the=20 IETF can learn about our failings. (FWIW, I say this as a happy paying=20 customer for your software.) --Paul Hoffman ------=_NextPart_000_027E_01D1F8A6.FC909B50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Paul:
 
> You don't = "need" the=20 IETF unless you want to follow the IETF's
> standards. If you = have a=20 better way to publish standards that are
> accepted by other = developers=20 who want to interoperate with you, you
> should do so. I say that = in all=20 seriousness: if you do a good job, the
> IETF can learn about our = failings.
 
Indeed, the = thought has=20 crossed my mind several times, but I=E2=80=99d rather not have to. It = would be much more=20 efficient if the existing standards body were to accept a more generous=20 understanding of its role, especially given that its flaws are = incidental more=20 so than fundamental. Trying to improve existing systems is often = frustrating,=20 but if successful, it=E2=80=99s more effective than creating a new=20 one.
 
> (FWIW, I = say this as=20 a happy paying customer for your software.)
Much appreciated. :-)
 
 
Sent: Wednesday, August 17, 2016 16:33
Cc: Curdle
Subject: Re: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 
On=20 17 Aug 2016, at 15:18, denis bider (Bitvise) wrote:

> A big = chunk of=20 users are going to heed these recommendations,

It is developers = that need=20 the standards, not the users. The users will
demand that certain = standards=20 they have heard of or are required to use
in the software they = purchase or=20 download.

> and are going to need a standards body that = accommodates=20 them.

s/a standards body/standards/  If the IETF does not = encode a=20 standard
that Some Government demands, someone else (hopefully That=20 Government)
will fill the gap.

> NIST is not going to = publish a=20 spec on how to use 3072-bit DH with
> SHA-512 in SSH.

That = seems=20 like a harsh statement. NIST had multiple publishing arms;
they = could do it=20 easily. Also, NIST has more than a handful of people
who know how to = write=20 Internet-Drafts that could become Informational
RFCs specifying how = to=20 implement what they want.

> But as an implementer, I need to = do this,=20 and if IETF will not address
> this case, then =E2=80=93 why = would I need IETF,=20 or respect any of its
> specifications?

You don't "need" = the IETF=20 unless you want to follow the IETF's
standards. If you have a better = way to=20 publish standards that are
accepted by other developers who want to=20 interoperate with you, you
should do so. I say that in all = seriousness: if=20 you do a good job, the
IETF can learn about our failings. (FWIW, I = say this=20 as a happy paying
customer for your software.)

--Paul=20 Hoffman

------=_NextPart_000_027E_01D1F8A6.FC909B50-- From nobody Wed Aug 17 16:40:56 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5229912D81D for ; Wed, 17 Aug 2016 16:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 GzLJK_edgjQr for ; Wed, 17 Aug 2016 16:40:54 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D912D669 for ; Wed, 17 Aug 2016 16:40:53 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DE3CC20002A; Wed, 17 Aug 2016 23:40:52 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id C8832200021; Wed, 17 Aug 2016 23:40:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471477252; bh=0Z3v3OyW7UDkullNmOi74P1tgo7Bl8knEWkXzo1T9co=; l=6252; h=From:To:Date:References:In-Reply-To:From; b=nQGJj2hGgd5lKI39WBzwExQirmjDXbSrzQ6c2aFxgYNcRtukxzv3G3B5RRa8SuSDh 6Q1XRaS86gBWJHI6KIVqCbOy9aT4s4Qqq2shYjwuO0d8xVoutmehrWM6MnVQQqowbX 1/xVIYLNHCJkRcrJpowwUoYapfiR1LhcqxvSOwCE= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A5DBF1E07C; Wed, 17 Aug 2016 23:40:52 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 17 Aug 2016 19:40:52 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 17 Aug 2016 19:40:52 -0400 From: "Salz, Rich" To: "denis bider (Bitvise)" , Curdle Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APwaEfWkeGPWkyjpB63havJEqBNR2oAgAAzZgCAAAbzAIAAe7uA///S9TA= Date: Wed, 17 Aug 2016 23:40:51 +0000 Message-ID: <2021212fab6446b9af083a94e6b2a619@usma1ex-dag1mb1.msg.corp.akamai.com> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.64] Content-Type: multipart/alternative; boundary="_000_2021212fab6446b9af083a94e6b2a619usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 23:40:55 -0000 --_000_2021212fab6446b9af083a94e6b2a619usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVuaXMsDQoNCkFyZSB0aGUgb3RoZXJzIHdobyBzaGFyZSB5b3VyIHZpZXdzPyAgVGhpcyBpc27i gJl0IHRoZSBmaXJzdCB0aW1lIHlvdeKAmXZlIGV4cHJlc3NlZCBpdCwgYnV0IGZyb20gbXkgbGlt aXRlZCB2aWV3cG9pbnQsIGl0IHNlZW1zIHRvIG5vdCBiZSBzaGFyZWQuDQoNCkkgYWxzbyBmaW5k IHNvbWUgaW5jb25zaXN0ZW5jeSBpbiB5b3VyIG1lc3NhZ2U7IGhvdyBjYW4gdGhlIElFVEYgbWFu ZGF0ZSBJbnRlcm5ldCBpbnRlcm9wZXJhYmlsaXR5IHdpdGhvdXQgZG9pbmcgdGhpbmdzIGxpa2Ug TVVTVCwgYW5kIHRoZXJlYnkgaXQsIHdlbGwsIE1VU1Qgc2VydmUgYXMgYSByZWNvbW1lbmRlciwg bm8/DQoNCi0tDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpJTTogcmlj aHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== --_000_2021212fab6446b9af083a94e6b2a619usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZW5pcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkFyZSB0aGUgb3RoZXJzIHdobyBzaGFyZSB5b3VyIHZpZXdzPyZuYnNwOyBUaGlzIGlzbuKA mXQgdGhlIGZpcnN0IHRpbWUgeW914oCZdmUgZXhwcmVzc2VkIGl0LCBidXQgZnJvbSBteSBsaW1p dGVkIHZpZXdwb2ludCwgaXQgc2VlbXMgdG8gbm90IGJlIHNoYXJlZC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bHNvIGZpbmQgc29tZSBpbmNvbnNpc3RlbmN5IGluIHlvdXIgbWVzc2FnZTsgaG93IGNhbiB0aGUg SUVURiBtYW5kYXRlIEludGVybmV0IGludGVyb3BlcmFiaWxpdHkgd2l0aG91dCBkb2luZyB0aGlu Z3MgbGlrZSBNVVNULCBhbmQgdGhlcmVieSBpdCwgd2VsbCwgTVVTVA0KIHNlcnZlIGFzIGEgcmVj b21tZW5kZXIsIG5vPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0tJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6 IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2021212fab6446b9af083a94e6b2a619usma1exdag1mb1msgcorpak_-- From nobody Wed Aug 17 18:51:03 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C39312D838 for ; Wed, 17 Aug 2016 18:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZXEwh3ucOIx for ; Wed, 17 Aug 2016 18:51:01 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154C212D834 for ; Wed, 17 Aug 2016 18:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:mime-version:content-type:in-reply-to: references; bh=N5tQDI05UpXvv8FIFHaEMn6/5SmoJ5uG0FIE4P6JyPQ=; b=aGjpc8fDwo9Lo9R+3V2W03VYWn7Sat1hZuol+z+amJq4JKRIMZmTiyZIcv06TkeTy6KNnpjeTgYXO 7bRjKFIJnBF1qTz50wjiiYq7bdDbUR4CI6PDfyt377qSon9Xrs+XSeHqx+FhJK9eZZKBVOutik9KUG w2JM3j2g/dMRn+82UjPmFa+Lzl8if1t31XrO4N1Y2WlrVzMmDPpAitob4/fZ60uJLrl+Ty/V0xMmAa ZKHPyfujm4OApLiCEBrQbA5Zx8M5iZwmO81fpwULCS0k5Fcu1OFXhazpq779c1kCc2WPq2WqDesUBK q9OtTeNa+RcwjNgnaTO+uU1g09H54ew== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 18 Aug 2016 02:50:44 +0100 Message-ID: <671AFE52E1174E648F460BFFCC1FCAFE@Khan> From: "denis bider \(Bitvise\)" To: "Salz, Rich" , "Curdle" References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.auckland.ac.nz> <2021212fab6446b9af083a94e6b2a619@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <2021212fab6446b9af083a94e6b2a619@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 17 Aug 2016 19:50:05 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C3_01D1F8C0.8CCF9A40" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 01:51:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C3_01D1F8C0.8CCF9A40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Rich, I don=E2=80=99t know; I guess I=E2=80=99m here to find out. Quite possibly, I=E2=80=99m not going to find out, because people who = share my views might not be here in the first place. There=E2=80=99s a = selection bias in any volunteer group, and this may make the group look = very different from a random population sample. It also makes for an echo chamber. Groups will normally attract people = who are in sync with the dominant group values, and repel people who are = not quite. The dominance of the group=E2=80=99s values does not mean the values are = preferrable, or good, or justified. It does not mean these values are = even helpful to the group=E2=80=99s ostensible purpose. Often, groups are ostensibly about one thing, but really about another. = I don=E2=80=99t agree with Robin Hanson about the extent to which all = human motivation revolves around seeking status. However, there is a = kernel of truth in that a lot of activity that is ostensibly about lofty = things, is in fact about seeking status. Academia. Volunteerism. = Participation in standards bodies. The work we=E2=80=99re doing here should not be interesting, or = flattering. We should not be here to put our names on things. We are = here to serve the community by documenting things, not to exercise power = by judging and mandating. That is a role for a different, more ephemeral = authority, that does not at the same time try to assume the role of the = internet=E2=80=99s main documenter of how things work. Specifications are forever; judgments last about 3 weeks. denis From: Salz, Rich=20 Sent: Wednesday, August 17, 2016 17:40 To: denis bider (Bitvise) ; Curdle=20 Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Denis, =20 Are the others who share your views? This isn=E2=80=99t the first time = you=E2=80=99ve expressed it, but from my limited viewpoint, it seems to = not be shared.=20 =20 I also find some inconsistency in your message; how can the IETF mandate = Internet interoperability without doing things like MUST, and thereby = it, well, MUST serve as a recommender, no? =20 -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz =20 ------=_NextPart_000_00C3_01D1F8C0.8CCF9A40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Rich,
 
I don=E2=80=99t know; I guess I=E2=80=99m here to find out.
 
Quite possibly, I=E2=80=99m not going to find out, because people = who share my=20 views might not be here in the first place. There=E2=80=99s a selection = bias in any=20 volunteer group, and this may make the group look very different from a = random=20 population sample.
 
It also makes for an echo chamber. Groups will normally attract = people who=20 are in sync with the dominant group values, and repel people who are not = quite.
 
The dominance of the group=E2=80=99s values does not mean the = values are=20 preferrable, or good, or justified. It does not mean these values are = even=20 helpful to the group=E2=80=99s ostensible purpose.
 
Often, groups are ostensibly about one thing, but really about = another. I=20 don=E2=80=99t agree with Robin Hanson about the extent to which all = human motivation=20 revolves around seeking status. However, there is a kernel of truth in = that a=20 lot of activity that is ostensibly about lofty things, is in fact about = seeking=20 status. Academia. Volunteerism. Participation in standards bodies.
 
The work we=E2=80=99re doing here should not be interesting, or = flattering. We=20 should not be here to put our names on things. We are here to serve the=20 community by documenting things, not to exercise power by judging and = mandating.=20 That is a role for a different, more ephemeral authority, that does not = at the=20 same time try to assume the role of the internet=E2=80=99s main = documenter of how things=20 work.
 
Specifications are forever; judgments last about 3 weeks.
 
denis
 
 
 
From: Salz, Rich
Sent: Wednesday, August 17, 2016 17:40
To: denis bider (Bitvise) ; Curdle =
Subject: RE: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 

Denis,

 

Are=20 the others who share your views?  This isn=E2=80=99t the first time = you=E2=80=99ve=20 expressed it, but from my limited viewpoint, it seems to not be shared.=20

 

I=20 also find some inconsistency in your message; how can the IETF mandate = Internet=20 interoperability without doing things like MUST, and thereby it, well, = MUST=20 serve as a recommender, no?

 

-- =20

Senior=20 Architect, Akamai Technologies

IM:=20 richsalz@jabber.at Twitter: RichSalz

 

------=_NextPart_000_00C3_01D1F8C0.8CCF9A40-- From nobody Wed Aug 17 19:21:44 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D5B12D847 for ; Wed, 17 Aug 2016 19:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=denisbider.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-xApost9QtX for ; Wed, 17 Aug 2016 19:21:33 -0700 (PDT) Received: from skroderider.denisbider.com (skroderider.denisbider.com [50.18.172.175]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE15C12D834 for ; Wed, 17 Aug 2016 19:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=denisbider.com; s=mail; h=from:subject:date:message-id:to:cc:mime-version:content-type; bh=epIQmrFd68XfSwXoRMqR4dcfVV1kNAEvcCgBTzEShMI=; b=Ng05nu9bd3jR7gwa5puioyykcTE0X/xDn1vtSQPnvM+Cyen/rjlBDkdwT7C4Inq3b8KR3fGdHcQ7R krSotpoiSWWxtkIeQV/LVD332XkfRTva6FKv4c5VwR4FlkEV0wx60sdk1eN5j/bgZPaFg6dcm3leaY sZE165JqTvYT12DIwFYGdfnv4PFMBR3u/wj04R+OUnYFFoajuRq4VwrFGqjegBnou0ZflmNZpaAN/t CjGnNDPgmm5mrZeQx6SnkEXFx3Wk4pke1L6eRvdDLp8QzcnH3CBZ66k4tfXXDHJspVnhvVCcyAWLqZ rvXrhTmyBKj9KgNMW1ZAeUkiJCaYT0A== X-Footer: ZGVuaXNiaWRlci5jb20= Received: from localhost ([127.0.0.1]) by skroderider.denisbider.com (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)); Thu, 18 Aug 2016 03:21:14 +0100 Message-ID: From: "denis bider \(Bitvise\)" To: "Curdle" Date: Wed, 17 Aug 2016 20:19:59 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01D1F8C4.BA313300" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: Rich Salz , "Mark D. Baushke" Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:21:37 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002F_01D1F8C4.BA313300 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It strikes me, also, that because this group caters to many protocols, = most people here might not have experience with implementing SSH. In this light, it may be relevant to point out that the seemingly many = DH key exchange methods defined by this draft are all a single key = exchange method. This is all the same original DH key exchange that was = present in the first SSHv2 version, and the method names are just a way = to negotiate a different DH group. The burden of implementing support = for an additional group literally consists of copy and pasting the group = parameters, and maybe plugging in a different hash. There are no changes = elsewhere. I appreciate that, in the interest of interoperability, folks want a = single key exchange method to be a MUST. I would second guess the idea = of the MUST being a curve and hash that fail to meet security = requirements of a substantial proportion of users, and that may likely = to fall to quantum cracking in the first few years quantum computing is = out. But as long as the choice remains currently reasonable, = I=E2=80=99ll support what you guys think should be a MUST. The problem is when you guys want to prevent the documentation of other = options, so that they might not interfere with the MUST. In this case, = you are betting a whole lot on your current insight being right, and the = NSA being wrong, over the period of the next 15 years. From: denis bider (Bitvise)=20 Sent: Wednesday, August 17, 2016 19:50 To: Salz, Rich ; Curdle=20 Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Hello Rich, I don=E2=80=99t know; I guess I=E2=80=99m here to find out. Quite possibly, I=E2=80=99m not going to find out, because people who = share my views might not be here in the first place. There=E2=80=99s a = selection bias in any volunteer group, and this may make the group look = very different from a random population sample. It also makes for an echo chamber. Groups will normally attract people = who are in sync with the dominant group values, and repel people who are = not quite. The dominance of the group=E2=80=99s values does not mean the values are = preferrable, or good, or justified. It does not mean these values are = even helpful to the group=E2=80=99s ostensible purpose. Often, groups are ostensibly about one thing, but really about another. = I don=E2=80=99t agree with Robin Hanson about the extent to which all = human motivation revolves around seeking status. However, there is a = kernel of truth in that a lot of activity that is ostensibly about lofty = things, is in fact about seeking status. Academia. Volunteerism. = Participation in standards bodies. The work we=E2=80=99re doing here should not be interesting, or = flattering. We should not be here to put our names on things. We are = here to serve the community by documenting things, not to exercise power = by judging and mandating. That is a role for a different, more ephemeral = authority, that does not at the same time try to assume the role of the = internet=E2=80=99s main documenter of how things work. Specifications are forever; judgments last about 3 weeks. denis From: Salz, Rich=20 Sent: Wednesday, August 17, 2016 17:40 To: denis bider (Bitvise) ; Curdle=20 Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Denis, =20 Are the others who share your views? This isn=E2=80=99t the first time = you=E2=80=99ve expressed it, but from my limited viewpoint, it seems to = not be shared.=20 =20 I also find some inconsistency in your message; how can the IETF mandate = Internet interoperability without doing things like MUST, and thereby = it, well, MUST serve as a recommender, no? =20 -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz =20 ------=_NextPart_000_002F_01D1F8C4.BA313300 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It strikes me, also, that because this group caters to many = protocols, most=20 people here might not have experience with implementing SSH.
 
In this light, it may be relevant to point out that the seemingly = many DH=20 key exchange methods defined by this draft are all a single key exchange = method.=20 This is all the same original DH key exchange that was present in the = first=20 SSHv2 version, and the method names are just a way to negotiate a = different DH=20 group. The burden of implementing support for an additional group = literally=20 consists of copy and pasting the group parameters, and maybe plugging in = a=20 different hash. There are no changes elsewhere.
 
I appreciate that, in the interest of interoperability, folks want = a single=20 key exchange method to be a MUST. I would second guess the idea of the = MUST=20 being a curve and hash that fail to meet security requirements of a = substantial=20 proportion of users, and that may likely to fall to quantum cracking in = the=20 first few years quantum computing is out. But as long as the choice = remains=20 currently reasonable, I=E2=80=99ll support what you guys think should be = a MUST.
 
The problem is when you guys want to prevent the documentation of = other=20 options, so that they might not interfere with the MUST. In this case, = you are=20 betting a whole lot on your current insight being right, and the NSA = being=20 wrong, over the period of the next 15 years.
 
 
Sent: Wednesday, August 17, 2016 19:50
Subject: Re: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 
Hello Rich,
 
I don=E2=80=99t know; I guess I=E2=80=99m here to find out.
 
Quite possibly, I=E2=80=99m not going to find out, because people = who share my=20 views might not be here in the first place. There=E2=80=99s a selection = bias in any=20 volunteer group, and this may make the group look very different from a = random=20 population sample.
 
It also makes for an echo chamber. Groups will normally attract = people who=20 are in sync with the dominant group values, and repel people who are not = quite.
 
The dominance of the group=E2=80=99s values does not mean the = values are=20 preferrable, or good, or justified. It does not mean these values are = even=20 helpful to the group=E2=80=99s ostensible purpose.
 
Often, groups are ostensibly about one thing, but really about = another. I=20 don=E2=80=99t agree with Robin Hanson about the extent to which all = human motivation=20 revolves around seeking status. However, there is a kernel of truth in = that a=20 lot of activity that is ostensibly about lofty things, is in fact about = seeking=20 status. Academia. Volunteerism. Participation in standards bodies.
 
The work we=E2=80=99re doing here should not be interesting, or = flattering. We=20 should not be here to put our names on things. We are here to serve the=20 community by documenting things, not to exercise power by judging and = mandating.=20 That is a role for a different, more ephemeral authority, that does not = at the=20 same time try to assume the role of the internet=E2=80=99s main = documenter of how things=20 work.
 
Specifications are forever; judgments last about 3 weeks.
 
denis
 
 
 
From: Salz, Rich
Sent: Wednesday, August 17, 2016 17:40
To: denis bider (Bitvise) ; Curdle =
Subject: RE: [Curdle] Group 15 needed in=20 draft-baushke-ssh-dh-group-sha2
 

Denis,

 

Are=20 the others who share your views?  This isn=E2=80=99t the first time = you=E2=80=99ve=20 expressed it, but from my limited viewpoint, it seems to not be shared.=20

 

I=20 also find some inconsistency in your message; how can the IETF mandate = Internet=20 interoperability without doing things like MUST, and thereby it, well, = MUST=20 serve as a recommender, no?

 

-- =20

Senior=20 Architect, Akamai Technologies

IM:=20 richsalz@jabber.at Twitter: RichSalz

 

= ------=_NextPart_000_002F_01D1F8C4.BA313300-- From nobody Thu Aug 18 06:28:35 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9F12D759 for ; Thu, 18 Aug 2016 06:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 VMmPYxPhFoYR for ; Thu, 18 Aug 2016 06:28:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE8612DE5D for ; Thu, 18 Aug 2016 06:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1471526909; x=1503062909; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6T7bogXMWMozvIIi/dFDUnIm0aTb1vFCSAREoxgssgQ=; b=InnGfdUH7DQfKX6AkpEVa8RJc+IfzXdkbFo0Avn7BeBCpTrp4Vs2F7iw 5jljmx5wh6orZFT+KfHG57go44wqmJ9/5lrZ/K+6Tklb1powpGElBVTWO vYTGhtxHolW8mfdLM5PKngpWNGqPIvhz7C1Q5GAVJgXqQh1kW8Gycsahi m3I6iYK1MLgFz435r/qUF+bltEmyMXb3oTjf1E3O0kFzp2g8sVExpz/Xf uYmAx5YTET44Dk5xAObLicNCdyBX6MPqtfYAd7WZL5XMEzUpecSZMK3n0 BC5u6b7oUZRSb00SBrUgUaZGO952zOA/VmhuxM+VlRel29R53BnkaAl26 g==; X-IronPort-AV: E=Sophos;i="5.28,539,1464609600"; d="scan'208";a="102692988" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Aug 2016 01:28:27 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 19 Aug 2016 01:28:27 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , Curdle Thread-Topic: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 Thread-Index: AQHR+APyc5WGhg2eHE6rWz5EA7SZMqBNBCC2//9qeACAAAbyAIAAe7uAgAHHEYY= Date: Thu, 18 Aug 2016 13:28:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4CF2F2F@uxcn10-5.UoA.auckland.ac.nz> References: <71963A21726946C3B16A0B77F0CFF3F6@Khan> <9A043F3CF02CD34C8E74AC1594475C73F4CF1A96@uxcn10-5.UoA.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-originating-ip: [10.6.3.3] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Daniel Migault , Rich Salz , "djm@mindrot.org" , Paul Hoffman , "Mark D. Baushke" , Watson Ladd , Phill Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:28:33 -0000 denis bider (Bitvise) writes:=0A= =0A= >The refusal of IETF to serve this role results in useful specifications no= t=0A= >ever making it to RFC, so that the role that used to be served by document= s=0A= >in the RFC status (note that this stands for =93Request for comments=94!) = is now=0A= >increasingly being served by hypothetically expiring Internet-Drafts, whic= h=0A= >really serve as actual specifications for widely used internet protocols,= =0A= >such as SFTP, because all we really want from a standards organization is = the=0A= >ability to coordinate, and we are not so much interested in its efforts to= =0A= >pontificate, opinionate, and mandate what=92s to be done in practice.=0A= =0A= Too true, sigh. The sixteen-year fiasco that is SCEP and my attempt to get= =0A= TLS-LTS adopted are other examples of this.=0A= =0A= >The desire to completely ignore the NSA just because they are not entirely= =0A= >our ally is highly questionable, and counter-productive. =0A= =0A= It has nothing to do with their motives. The NSA are one single organisati= on=0A= that deals with crypto among an ocean of organisations that deal with crypt= o,=0A= and in particular one that doesn't exactly have a good track record of back= ing=0A= workable crypto standards (CCEP, Clipper, Fortezza, Suite B, is there anyth= ing=0A= that they - not NIST - have pushed that's actually gone anywhere?). If we'= re=0A= going to jump whenever the NSA says so, why shouldn't we do the same for th= e=0A= FSB, DSD, CESG, BSI, ANSSI, FRA, NSM, MSS, NICRD, and an entire other alpha= bet=0A= soup of government agencies, not to mention the 13 pages of industry bodies= =0A= who'd all like their pet algorithms included in anything that gets=0A= standardised? Why build the NSAs wish list into SSH but not the IAGR (that= 's=0A= "International Association of Gaming Regulators", who are actually involved= in=0A= crypto standardisation work)?=0A= =0A= If someone really wants their pet algorithm baked into SSH, they can write = the=0A= profile themselves. The IETF is here to serve the needs of the people that= =0A= contribute to it and, in turn, their users/customers, not to rule that=0A= everyone has to use whatever someone's guess as to the wishes of one specif= ic=0A= US government agency is. It's not even as if we've had anyone from the NSA= =0A= ask for this, it's just your guess at what the NSA might in theory want if= =0A= someone asked them.=0A= =0A= Peter.= From nobody Thu Aug 18 13:50:10 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7858512D5E8; Thu, 18 Aug 2016 13:50:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147155340946.27920.8584261633888524485.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 13:50:09 -0700 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, mglt.ietf@gmail.com, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - New Meeting Session Request for IETF 97 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 20:50:09 -0000 A new meeting session request has just been submitted by Daniel Migault, a Chair of the curdle working group. --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: tls i2nsf ipsecme saag tcpinc sacm trans acme lamps Second Priority: dots Special Requests: --------------------------------------------------------- From nobody Thu Aug 18 18:20:40 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9843212D135; Thu, 18 Aug 2016 18:20:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147156963857.27807.1943427689461180067.idtracker@ietfa.amsl.com> Date: Thu, 18 Aug 2016 18:20:38 -0700 Archived-At: Cc: curdle@ietf.org, curdle-chairs@ietf.org, mglt.ietf@gmail.com, stephen.farrell@cs.tcd.ie Subject: [Curdle] curdle - Update to a Meeting Session Request for IETF 97 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 01:20:38 -0000 An update to a meeting session request has just been submitted by Daniel Migault, a Chair of the curdle working group. --------------------------------------------------------- Working Group Name: CURves, Deprecating and a Little more Encryption Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: First Priority: tls i2nsf ipsecme saag tcpinc sacm trans acme lamps radext Second Priority: dots Special Requests: --------------------------------------------------------- From nobody Thu Aug 18 22:51:51 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EA612D819 for ; Thu, 18 Aug 2016 22:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 qIhXvTHx4nqw for ; Thu, 18 Aug 2016 22:51:48 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 13B2B12D5D5 for ; Thu, 18 Aug 2016 22:51:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6FC3A13E49; Fri, 19 Aug 2016 08:51:46 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id yBYoUaKn015s; Fri, 19 Aug 2016 08:51:46 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 086DA21C; Fri, 19 Aug 2016 08:51:46 +0300 (EEST) Date: Fri, 19 Aug 2016 08:51:37 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160819055137.qi2ihrguilnqdqjs@LK-Perkele-V2.elisa-laajakaista.fi> References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 05:51:51 -0000 On Wed, Aug 17, 2016 at 06:37:12AM +0300, Ilari Liusvaara wrote: > > It occurs to me that one could avoid use of prehashed EdDSA variants by > adding OID that is defined to sign a hash object[1] instead of the actual > data. If then one could avoid contexts, one could just use standard-issue > Ed25519 code (which is dime dozen). > > That could be also be used to avoid the potentially annoying SHAK256 > hashing if one wants long-input Ed448. Did a PoC implementation: (The OID I picked is the first "free" OID I found from PKIX registry) Code: ----------------------------------------------------------------------- #!/bin/bash hash=`echo "$1" | cut -b 1-128` prefix="hex:30819A06072B060105050718300B06096086480165030402030440"; zeroes="0000000000000000000000000000000000000000000000000000000000000000" prefix2="0440" echo ${prefix}${zeroes}${zeroes}${prefix2}${hash} ----------------------------------------------------------------------- Session: ----------------------------------------------------------------------- # Generate a new key $ python3 eddsa2-prototool.py keygen Ed25519 base64url base64url privkey: f2cLOhNwOiWxIdYilrx8j_jfW_eiYU7TTRM4WAAjlTo pubkey: b0xsyPvk9X6EBuA7Us765Yt_V_6Jfd6CIIUXahTIJ04 # Sign SHA-512("abc") $ python3 eddsa2-prototool.py sign Ed25519 base64url:f2cLOhNwOiWxIdYilrx8j_jfW_eiYU7TTRM4WAAjlTo $(./sha512ph $(echo -n "abc" | sha512sum)) base64url signature: 4YXV2bze-vbAjfn0bZFynRhjI9BMf34NX-gh8r4aLEFxEEvTsRjEhCcMQezR3YkzlaCYuG9kIyGQqLp-sL2UBQ # Verify the signature just generated. $ python3 eddsa2-prototool.py verify Ed25519 base64url:b0xsyPvk9X6EBuA7Us765Yt_V_6Jfd6CIIUXahTIJ04 $(./sha512ph $(echo -n "abc" | sha512sum)) base64url:4YXV2bze-vbAjfn0bZFynRhjI9BMf34NX-gh8r4aLEFxEEvTsRjEhCcMQezR3YkzlaCYuG9kIyGQqLp-sL2UBQ # Exit status 0 => success. $ echo $? 0 # What that program does? $ ./sha512ph $(echo -n "abc" | sha512sum) hex:30819A06072B060105050718300B06096086480165030402030440000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000440ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f # The hash itself (this is one of SHA-2 test vectors). $ echo -n "abc" | sha512sum ddaf35a193617abacc417349ae20413112e6fa4e89a97ea20a9eeee64b55d39a2192992a274fc1a836ba3c23a3feebbd454d4423643ce80e2a9ac94fa54ca49f - $ ----------------------------------------------------------------------- The signature algorithm is standard-issue Ed25519. The same trick would also work for Ed448. I ensured that 64th, 65th and 66th bytes are all zero, which avoids collision with either TLS 1.2 or 1.3 (it is either invalid padding, invalid curve type or divide by zero). And the OID I put in there avoids collisions with other ASN.1 stuff. -Ilari From nobody Fri Aug 19 05:30:28 2016 Return-Path: X-Original-To: curdle@ietf.org Delivered-To: curdle@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EE712D0DD; Fri, 19 Aug 2016 05:30:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 05:30:23 -0700 Archived-At: Cc: curdle@ietf.org Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:30:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure Authors : Simon Josefsson Jim Schaad Filename : draft-ietf-curdle-pkix-01.txt Pages : 15 Date : 2016-08-15 Abstract: This document specify algorithm identifiers and ASN.1 encoding formats for Elliptical Curve constructs using the Curve25519 and Curve448 curves. The signature algorithms covered are Ed25519, Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered are X25519 and X448. The Encoding for Public Key, Private Key and EdDSA digital signature structures is provided. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-curdle-pkix-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 19 06:40:48 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDC512D9F8 for ; Fri, 19 Aug 2016 06:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 jnoOvuRlgKP8 for ; Fri, 19 Aug 2016 06:40:43 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C1E9F12DA73 for ; Fri, 19 Aug 2016 06:38:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id F232E109F1 for ; Fri, 19 Aug 2016 16:38:36 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id VQ_178AmOgiU for ; Fri, 19 Aug 2016 16:38:36 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 9E87127F for ; Fri, 19 Aug 2016 16:38:36 +0300 (EEST) Date: Fri, 19 Aug 2016 16:38:28 +0300 From: Ilari Liusvaara To: curdle@ietf.org Message-ID: <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:40:47 -0000 On Fri, Aug 19, 2016 at 05:30:23AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. > > Title : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure > Authors : Simon Josefsson > Jim Schaad > Filename : draft-ietf-curdle-pkix-01.txt > Pages : 15 > Date : 2016-08-15 Did a brief look: - The draft bans use of prehash variants for signing certificates and CRLs. What about OCSP responses? IMO, basic cases: High value? Large? Certificates Yes No OCSP No No CRL No Maybe So, prehashing probably shouldn't be allowed for certs, but might be necressary for CRLs. - Using intermediate objects (like I showed) would avoid having to support Ed25519ph/Ed448ph (where Ed25519ph can be especially problematic). -Ilari From nobody Fri Aug 19 09:59:59 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDD812D568 for ; Fri, 19 Aug 2016 09:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 t52-JgW6mICy for ; Fri, 19 Aug 2016 09:59:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0926912D103 for ; Fri, 19 Aug 2016 09:59:54 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 19 Aug 2016 10:11:36 -0700 From: Jim Schaad To: 'Ilari Liusvaara' , References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 19 Aug 2016 09:59:16 -0700 Message-ID: <097a01d1fa3b$06c6ee90$1454cbb0$@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: AQK2d0TroNuVIE0A27Dc80J1726oxAI+ZRKjnnWSGTA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:59:58 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari Liusvaara > Sent: Friday, August 19, 2016 6:38 AM > To: curdle@ietf.org > Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt > > On Fri, Aug 19, 2016 at 05:30:23AM -0700, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the CURves, Deprecating and a Little more > Encryption of the IETF. > > > > Title : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, > Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure > > Authors : Simon Josefsson > > Jim Schaad > > Filename : draft-ietf-curdle-pkix-01.txt > > Pages : 15 > > Date : 2016-08-15 > > Did a brief look: > > - The draft bans use of prehash variants for signing certificates and > CRLs. What about OCSP responses? Same paragraph in section 5 - although I said SHOULD NOT rather than MUST NOT. I am more than willing to increase this level. > > IMO, basic cases: > > High value? Large? > Certificates Yes No > OCSP No No > CRL No Maybe > > So, prehashing probably shouldn't be allowed for certs, but might be necressary > for CRLs. In many cases, the same key is being used to sign both certificates and CRLs so it is probably easier to have the same level of badness for both structures. CRLs are never going to be streamed in and out which is where I find the idea of doing hash then sign most attractive. If people believe that CRLs are going to be a problem, then the language would need to be something along the lines of -- a different signing key is needed for CRLs if you do the pre-hash case and client code needs to deal with large CRLs if that is not what is being done. I don't know how much current software is setup for delegated CRLs. Jim > > > - Using intermediate objects (like I showed) would avoid having to > support Ed25519ph/Ed448ph (where Ed25519ph can be especially > problematic). > > > > -Ilari > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Aug 19 10:08:02 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5683C12D5FB for ; Fri, 19 Aug 2016 10:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 mwND-8iUUlcu for ; Fri, 19 Aug 2016 10:07:59 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2238C12D5F0 for ; Fri, 19 Aug 2016 10:07:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 41BA9113C6; Fri, 19 Aug 2016 20:07:58 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id XFz-ZloBfITu; Fri, 19 Aug 2016 20:07:58 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id F30282316; Fri, 19 Aug 2016 20:07:57 +0300 (EEST) Date: Fri, 19 Aug 2016 20:07:49 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160819170749.qwcytwnw57ax22f7@LK-Perkele-V2.elisa-laajakaista.fi> References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 17:08:01 -0000 On Fri, Aug 19, 2016 at 09:59:16AM -0700, Jim Schaad wrote: > > > So, prehashing probably shouldn't be allowed for certs, but might be > necressary > > for CRLs. > > In many cases, the same key is being used to sign both certificates and CRLs > so it is probably easier to have the same level of badness for both > structures. > > CRLs are never going to be streamed in and out which is where I find the > idea of doing hash then sign most attractive. If people believe that CRLs > are going to be a problem, then the language would need to be something > along the lines of -- a different signing key is needed for CRLs if you do > the pre-hash case and client code needs to deal with large CRLs if that is > not what is being done. Oh, the signed CRL structure is ASN.1 DER, which means it has length field in the front, making streaming nasty? (BTW: Added Ed448 support (Ed25519 was already in, albeit I needed to adjust the OID) to one PKIX certificate verification code I am working on). -Ilari From nobody Fri Aug 19 10:14:07 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256BE12D5E8 for ; Fri, 19 Aug 2016 10:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 LQbg7gze6oDb for ; Fri, 19 Aug 2016 10:14:04 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9CD812D0B7 for ; Fri, 19 Aug 2016 10:14:03 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 19 Aug 2016 10:25:58 -0700 From: Jim Schaad To: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> In-Reply-To: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 10:13:37 -0700 Message-ID: <097d01d1fa3d$086f8390$194e8ab0$@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: AQK2d0TroNuVIE0A27Dc80J1726oxJ6Hh4yw Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Curdle] FW: I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 17:14:06 -0000 A new draft has been released which maps to the presentation that I gave in Berlin. Please review it to make sure that I got language correct, that I did not miss anything really stupid. There are a couple of things that I want to point out that were not in my presentation: 1. I make statements in section 5 on Certificates, CRLs, OCSP and AA constructions. We had talked about the implications for certificates but not as much for the other constructs. Are there other PKIX items that should be included here. Also, should this text be here in the key usage bits section or in the next section? 2. On a suggestion from Russ I changed the title of the document. It is long, but complete. Should we edit this down back to something smaller? 3. I have changed the presentation so that each section talks about a single structure. I think this makes things easier to follow, however the order could be changed if people thing it should be. 4. I think that all of the examples are correct, however they all need to be verified by a second person. Volunteers are gladly accepted. 5. I come from the world of S/MIME so people are going to find my ASN.1 module to be overly large in some respects. I need to go back and verify that I think the kaa-* items are correct based on the corresponding document from Russ, but I think that I got them correct. However people may object to this and want to go back to the minimal ASN.1 module. 6. The example certificate uses two different algorithms in it. This means it is not a self-signed certificate. Do people want to move back to having a different set of examples here? We can easily expand this to add things people thing are going to be useful. Jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, August 19, 2016 5:30 AM > To: i-d-announce@ietf.org > Cc: curdle@ietf.org > Subject: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CURves, Deprecating and a Little more > Encryption of the IETF. > > Title : Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, > X25519 and X448 for use in the Internet X.509 Public Key Infrastructure > Authors : Simon Josefsson > Jim Schaad > Filename : draft-ietf-curdle-pkix-01.txt > Pages : 15 > Date : 2016-08-15 > > Abstract: > This document specify algorithm identifiers and ASN.1 encoding > formats for Elliptical Curve constructs using the Curve25519 and > Curve448 curves. The signature algorithms covered are Ed25519, > Ed25519ph, Ed448 and Ed448ph. The key agreement algorithm covered > are X25519 and X448. The Encoding for Public Key, Private Key and > EdDSA digital signature structures is provided. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-curdle-pkix-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Aug 21 11:34:56 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A6B12D0C8 for ; Sun, 21 Aug 2016 11:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.548, 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 45o-oiaj52qN for ; Sun, 21 Aug 2016 11:34:53 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 473F412D0C6 for ; Sun, 21 Aug 2016 11:34:53 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 21 Aug 2016 11:46:39 -0700 From: Jim Schaad To: References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> In-Reply-To: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> Date: Sun, 21 Aug 2016 11:34:20 -0700 Message-ID: <006b01d1fbda$a33d7050$e9b850f0$@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: AQHmq3PHmJZ1Zt4yMknvAsjdQB0DPqAqXfyQ Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 18:34:55 -0000 A follow up to this message. The CFRG draft has been published and based on the text it really only leaves the question of do we want to assign an OID for EdDSA25519cxt at this time. jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, August 16, 2016 2:37 PM > To: curdle@ietf.org > Subject: [Curdle] Ed25591ctx > > Ilari has done edits on a local draft to respond to my comments and it appears > he is planning on introducing a new mode to the EdDSA drafts for 25519. > Specifically one would have: > > EdDSA25519 - the traditional signature algorithm EdDSA25519ctx - a new mode > for 25519 which has a context structure available to it. > EdDSA25519pre - a pre-hash mode that uses the same structure as > EdDSSA25519ctx > > This means that we would no longer have the huge problem between ctx and > pre hash modes conflicting quite as much as one could require the use of ctx and > pre instead. One still has the problems between pure and the other modes. > > The questions I have are: > > Should we issue an OID for the new ctx mode? > > Should we require the use of the ctx mode for signing of certificates? > > Should we have any advisory language which says that new usages SHOULD use > the ctx mode over the pure mode? > > Jim > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Aug 21 12:28:07 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDCA12D7DA for ; Sun, 21 Aug 2016 12:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 whybkeNoJejj for ; Sun, 21 Aug 2016 12:28:05 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912B212D7A1 for ; Sun, 21 Aug 2016 12:28:04 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 21 Aug 2016 12:39:50 -0700 From: Jim Schaad To: References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 21 Aug 2016 12:27:31 -0700 Message-ID: <007901d1fbe2$112d30d0$33879270$@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: AQHmq3PHmJZ1Zt4yMknvAsjdQB0DPgHHRDYKoBwxAxA= Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 19:28:06 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Tuesday, August 16, 2016 8:37 PM > To: Jim Schaad > Cc: curdle@ietf.org > Subject: Re: [Curdle] Ed25591ctx >=20 > On Tue, Aug 16, 2016 at 02:36:40PM -0700, Jim Schaad wrote: > > Ilari has done edits on a local draft to respond to my comments and = it > > appears he is planning on introducing a new mode to the EdDSA drafts > > for 25519. Specifically one would have: > > > > EdDSA25519 - the traditional signature algorithm EdDSA25519ctx - a = new > > mode for 25519 which has a context structure available to it. > > EdDSA25519pre - a pre-hash mode that uses the same structure as > > EdDSSA25519ctx >=20 > The names aren't right (the right ones are 'Ed25519ctx' and = 'Ed25519ph'), but > otherewise quite so (assuming contexts will be part of the document!) >=20 > > This means that we would no longer have the huge problem between ctx > > and pre hash modes conflicting quite as much as one could require = the > > use of ctx and pre instead. One still has the problems between pure = and the > other modes. >=20 > That change also solves the problem of using the same key for Ed25519 = and > Ed25519ph. >=20 > However, Ed25519ctx and Ed25519ph can't be computed using standard > Ed25519 software. There is no way to do so while remaining safe to = key- share. > Fortunately, the places that are modified are likely not to be too = inaccessable > (i.e. written in high-level-language) in practical implementations, if = you can > modify one. >=20 > > The questions I have are: > > > > Should we issue an OID for the new ctx mode? > > > > Should we require the use of the ctx mode for signing of = certificates? > > > > Should we have any advisory language which says that new usages = SHOULD > > use the ctx mode over the pure mode? >=20 > It occurs to me that one could avoid use of prehashed EdDSA variants = by adding > OID that is defined to sign a hash object[1] instead of the actual = data. If then > one could avoid contexts, one could just use standard-issue > Ed25519 code (which is dime dozen). >=20 > That could be also be used to avoid the potentially annoying SHAK256 = hashing if > one wants long-input Ed448. >=20 >=20 > While contexts could help against things like that TLS 1.2 LURK SKI = attack EKR > came up with, there are plenty of RSA or ECDSA keys that are = unprotected > against such abuse. >=20 > And then there is the issue that contexts are a new input, and many = signature > APIs just doesn't have it. >=20 > And with regards to new stuff using contexts, I think it is a bad = idea, unless the > stuff used only contextualized signatures. And PKIX fails that = criteria. >=20 >=20 >=20 > [1] One rough sketch (excuse me for not using the correct notation): >=20 > SEQUENCE { > OID > OCTET_STRING zeroes_64octets > AlgorithmIdentifier hash_algorithm > OCTET_STRING hash_value > } >=20 > DER-encode that (easily templateable if you know the hash, which would = come > from the signature algorithm OID) and use that as message for = algorithm. >=20 > The OID in the beginning is to distinguish it from other ASN.1 = structures. >=20 > I threw that zeroes_64octets in there to make it more difficult to = abuse with > TLS. >=20 > Specifically, valid TLS 1.3 signatures can't look like that because = those start with > 0x20, not 0x30 like that one does. >=20 > Nor can valid TLS 1.2 signatures, because that one presumably has a = zero in 65th > and 66th position, which would code curve type 0 > (undefined) for ECDHE and p=3D0 (division by zero) for DHE. >=20 > One minor problem being that it breaks a SHA-512 block (which is like = 2% speed > penalty for signing, less for verfication). This worries me from the following perspective: Ok - this would work if we had just TLS and ASN.1, but I start worrying = about this when you also decide to do the same thing for CBOR, XML, JSON = and who knows what other formats. YAML anybody? It is easy to = potentially avoid the collisions with two, but harder as new people = without the same experience as we have decide to do the same type of = thing. I would rather tell people to design a content structure that does the = prehash thing and sign that content than have fancy structure as part of = the signature processing. This is the basic approach I have suggested = for signing of large detached files for CBOR and JOSE. It is also = similar to how CMS is designed where the content is hashed and that = result is part of what is signed. Jim >=20 >=20 >=20 >=20 > -Ilari From nobody Mon Aug 22 04:02:51 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8054112D0E7 for ; Mon, 22 Aug 2016 04:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] 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 qZb6mpIyg4Bl for ; Mon, 22 Aug 2016 04:02:48 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 845E812B008 for ; Mon, 22 Aug 2016 04:02:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 9E6E3148CF; Mon, 22 Aug 2016 14:02:46 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id rNGSuFP3rwIM; Mon, 22 Aug 2016 14:02:46 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7440EC4; Mon, 22 Aug 2016 14:02:46 +0300 (EEST) Date: Mon, 22 Aug 2016 14:02:37 +0300 From: Ilari Liusvaara To: Jim Schaad Message-ID: <20160822110236.7vlpu67wjcizfonv@LK-Perkele-V2.elisa-laajakaista.fi> References: <05fa01d1f806$485b99f0$d912cdd0$@augustcellars.com> <20160817033711.32r5wvmueniqvkk5@LK-Perkele-V2.elisa-laajakaista.fi> <007901d1fbe2$112d30d0$33879270$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <007901d1fbe2$112d30d0$33879270$@augustcellars.com> User-Agent: Mutt/1.6.2-neo (2016-08-08) Sender: ilariliusvaara@welho.com Archived-At: Cc: curdle@ietf.org Subject: Re: [Curdle] Ed25591ctx X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 11:02:50 -0000 On Sun, Aug 21, 2016 at 12:27:31PM -0700, Jim Schaad wrote: > > This worries me from the following perspective: > > Ok - this would work if we had just TLS and ASN.1, but I start > worrying about this when you also decide to do the same thing for > CBOR, XML, JSON and who knows what other formats. YAML anybody? > It is easy to potentially avoid the collisions with two, but harder > as new people without the same experience as we have decide to do > the same type of thing. If you use the same key for those and interactions haven't been considered in the design, you are far into what I originally intended contexts to be used for. OTOH, I think that by far the most common other format ASN.1 keys need to share with is TLS (note: CSRs cause this sharing to happen a lot). Out of what ASN.1 could collide with in that list, CBOR looks to be the worst. I checked how the construct would fare with CBOR: SHA-384 variant could encode into valid concatenation of CBOR structures (it won't encode into single one, because the first byte is already a value). -Ilari From nobody Mon Aug 22 09:20:36 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FFF12D124 for ; Mon, 22 Aug 2016 09:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-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=docusign2com.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn2TjATCYhBb for ; Mon, 22 Aug 2016 09:20:32 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0121.outbound.protection.outlook.com [104.47.41.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740FE12D66A for ; Mon, 22 Aug 2016 09:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5XiuYOSB6/MNa2bHbgphXwUpoJIPUKTifisCDcV917w=; b=e/ImrnDwImeqEaugz/BfH7ixzAKnh4e/QHW7wrgLYMy+Q4Y0k9UDHxwbLdcA7MHFodUt2WBAfrT4ZpCCGgzVW7EHO8bs7AriJYxkimi47cTe5jOgfkWT2MJSWpHQI4r1oSaKJ/V51GhrG2wqRjak12pOomEjUm5KX26EJVaJ8X4= Received: from BN3PR0401MB1395.namprd04.prod.outlook.com (10.161.209.154) by BN3PR0401MB1393.namprd04.prod.outlook.com (10.161.209.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Mon, 22 Aug 2016 16:20:29 +0000 Received: from BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) by BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) with mapi id 15.01.0557.027; Mon, 22 Aug 2016 16:20:29 +0000 From: Erwann Abalea To: Jim Schaad Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR/JEZW8r+SxTmI0mQPZvWUm8bZQ== Date: Mon, 22 Aug 2016 16:20:29 +0000 Message-ID: <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> In-Reply-To: <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erwann.Abalea@docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-ms-office365-filtering-correlation-id: 918ad359-28ad-439c-1da8-08d3caa83bf8 x-microsoft-exchange-diagnostics: 1; BN3PR0401MB1393; 6:ACxlHwi3A8HwCKPfDQmxHpI/7RluaQZ7dJZF/k9vhl+s2/7Clw3AIhh/YIs7dLRwiTiDSIhdnvlgyav8sYH1+XPwa17lY7AOIMQ4s9nGG884lVt+S/I397mL7rqniMuVlByjdy3r0kCnnoAGIDjHqcU+b//3QlEUxCETqB/TxE1iuvskp1nuVYh6U9lD4BcjDoD6AfDm8Pm0fp4nM8sCEPEm+JJSG0Iaajs1ZAXOsm1GfovZBB/StdatndWAtN9sCQmgfC5shZ2Jg9Li2cibPPr54SJyoXyJ3O3myH+4HgA=; 5:1cq0e+UYUDsJdw0jBBWp0CF0k/iOXYET4h4fX+ocLFDNMHjIo4k4AJv8/9F/JENKJbGlVBD/SJi2MoXk6s0FANMzIUdxP1vtzkIzqHzxLZcZI9rNez8zZqYXqks7jJScY51N+rJC/p5F8DTtuSGtUg==; 24:kyoiNYV9dBybW642GnxEaD2y1k0pzztlA/NcKLwJzJZ8x2lG+1Xy6aahYmDqYFjTBdjH1MXm6cV/OvZ2XykyMhWlsI3Mj/f6bo3tAgBALmg=; 7:NUGWo8BXlTtsnfo0XBvv40nqtUDYUk++Rs6ReyOZiPXKLu51n9xY8xPi0QuGihG/Xr90R97SoA8d4hjD9+hFXL9LOKPRUcb2/kYWWYqckXv6FtHGi2N45I3c751lxdq1OvUu0aK3Ns+3ViZ8HEUBD2p3UAiUkVed8Z5K+uCKFmKBNVwwDpIXcyoIWuVVyHsUXotnMzTfgo0dChcuxbgbeJg4BU9GzJNN0+DUH95Hcwr4YQ9jOe2DXSoPHo/mFcaS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0401MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0401MB1393; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0401MB1393; x-forefront-prvs: 00429279BA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377424004)(189002)(377454003)(24454002)(13464003)(199003)(3280700002)(4326007)(81156014)(3660700001)(81166006)(8936002)(2950100001)(11100500001)(2906002)(7846002)(7736002)(305945005)(66066001)(8676002)(5660300001)(99286002)(105586002)(122556002)(106356001)(2900100001)(77096005)(106116001)(10400500002)(5002640100001)(230783001)(54356999)(50986999)(83716003)(86362001)(19580405001)(19580395003)(33656002)(76176999)(586003)(6116002)(102836003)(68736007)(5890100001)(92566002)(97736004)(3846002)(110136002)(189998001)(87936001)(36756003)(82746002)(101416001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0401MB1393; H:BN3PR0401MB1395.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: docusign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2016 16:20:29.7433 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0401MB1393 Archived-At: Cc: "curdle@ietf.org" , Ilari Liusvaara Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 16:20:35 -0000 Qm9uam91ciwNCg0KPiBMZSAxOSBhb8O7dCAyMDE2IMOgIDE4OjU5LCBKaW0gU2NoYWFkIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPiBhIMOpY3JpdCA6DQo+IA0KPiANCj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogQ3VyZGxlIFttYWlsdG86Y3VyZGxlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJbGFyaSBMaXVzdmFhcmENCj4+IFNlbnQ6IEZyaWRheSwg QXVndXN0IDE5LCAyMDE2IDY6MzggQU0NCj4+IFRvOiBjdXJkbGVAaWV0Zi5vcmcNCj4+IFN1Ympl Y3Q6IFJlOiBbQ3VyZGxlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAxLnR4 dA0KPj4gDQo+PiBPbiBGcmksIEF1ZyAxOSwgMjAxNiBhdCAwNTozMDoyM0FNIC0wNzAwLCBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+Pj4gDQo+Pj4gQSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVj dG9yaWVzLg0KPj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENVUnZlcywgRGVw cmVjYXRpbmcgYW5kIGEgTGl0dGxlIG1vcmUNCj4+IEVuY3J5cHRpb24gb2YgdGhlIElFVEYuDQo+ Pj4gDQo+Pj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IEFsZ29yaXRobSBJZGVudGlmaWVycyBm b3IgRWQyNTUxOSwgRWQyNTUxOXBoLA0KPiBFZDQ0OCwNCj4+IEVkNDQ4cGgsIFgyNTUxOSBhbmQg WDQ0OCBmb3IgdXNlIGluIHRoZSBJbnRlcm5ldCBYLjUwOSBQdWJsaWMgS2V5DQo+IEluZnJhc3Ry dWN0dXJlDQo+Pj4gICAgICAgIEF1dGhvcnMgICAgICAgICA6IFNpbW9uIEpvc2Vmc3Nvbg0KPj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICBKaW0gU2NoYWFkDQo+Pj4gCUZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWlldGYtY3VyZGxlLXBraXgtMDEudHh0DQo+Pj4gCVBhZ2VzICAgICAgICAgICA6 IDE1DQo+Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTYtMDgtMTUNCj4+IA0KPj4gRGlkIGEgYnJp ZWYgbG9vazoNCj4+IA0KPj4gLSBUaGUgZHJhZnQgYmFucyB1c2Ugb2YgcHJlaGFzaCB2YXJpYW50 cyBmb3Igc2lnbmluZyBjZXJ0aWZpY2F0ZXMgYW5kDQo+PiAgQ1JMcy4gV2hhdCBhYm91dCBPQ1NQ IHJlc3BvbnNlcz8NCj4gDQo+IFNhbWUgcGFyYWdyYXBoIGluIHNlY3Rpb24gNSAtIGFsdGhvdWdo IEkgc2FpZCBTSE9VTEQgTk9UIHJhdGhlciB0aGFuIE1VU1QNCj4gTk9ULg0KPiBJIGFtIG1vcmUg dGhhbiB3aWxsaW5nIHRvIGluY3JlYXNlIHRoaXMgbGV2ZWwuDQo+IA0KPj4gDQo+PiBJTU8sIGJh c2ljIGNhc2VzOg0KPj4gDQo+PiAgICAgICAgICAgICAgICBIaWdoIHZhbHVlPyAgIExhcmdlPw0K Pj4gQ2VydGlmaWNhdGVzICAgIFllcyAgICAgICAgICAgTm8NCj4+IE9DU1AgICAgICAgICAgICBO byAgICAgICAgICAgIE5vDQo+PiBDUkwgICAgICAgICAgICAgTm8gICAgICAgICAgICBNYXliZQ0K Pj4gDQo+PiBTbywgcHJlaGFzaGluZyBwcm9iYWJseSBzaG91bGRuJ3QgYmUgYWxsb3dlZCBmb3Ig Y2VydHMsIGJ1dCBtaWdodCBiZQ0KPiBuZWNyZXNzYXJ5DQo+PiBmb3IgQ1JMcy4NCj4gDQo+IElu IG1hbnkgY2FzZXMsIHRoZSBzYW1lIGtleSBpcyBiZWluZyB1c2VkIHRvIHNpZ24gYm90aCBjZXJ0 aWZpY2F0ZXMgYW5kIENSTHMNCj4gc28gaXQgaXMgcHJvYmFibHkgZWFzaWVyIHRvIGhhdmUgdGhl IHNhbWUgbGV2ZWwgb2YgYmFkbmVzcyBmb3IgYm90aA0KPiBzdHJ1Y3R1cmVzLg0KDQpJbiBzb21l IGNhc2VzLCBhbmQgcGFydGljdWxhcmx5IGluIHRoZSBXZWJQS0ksIHRoZSBzYW1lIGtleSBpcyB1 c2VkIHRvIHNpZ24gY2VydGlmaWNhdGVzLCBDUkxzLCBhbmQgT0NTUCByZXNwb25zZXMuIFRoZSBz aXplIHByb2JsZW0gZG9lc27igJl0IHJlYWxseSBleGlzdCBmb3IgT0NTUCByZXNwb25zZXMuDQpB Z2FpbiwgaXTigJlzIG5vdCBtYW5kYXRvcnkuDQoNCj4gQ1JMcyBhcmUgbmV2ZXIgZ29pbmcgdG8g YmUgc3RyZWFtZWQgaW4gYW5kIG91dCB3aGljaCBpcyB3aGVyZSBJIGZpbmQgdGhlDQo+IGlkZWEg b2YgZG9pbmcgaGFzaCB0aGVuIHNpZ24gbW9zdCBhdHRyYWN0aXZlLiAgSWYgcGVvcGxlIGJlbGll dmUgdGhhdCBDUkxzDQo+IGFyZSBnb2luZyB0byBiZSBhIHByb2JsZW0sIHRoZW4gdGhlIGxhbmd1 YWdlIHdvdWxkIG5lZWQgdG8gYmUgc29tZXRoaW5nDQo+IGFsb25nIHRoZSBsaW5lcyBvZiAtLSBh IGRpZmZlcmVudCBzaWduaW5nIGtleSBpcyBuZWVkZWQgZm9yIENSTHMgaWYgeW91IGRvDQo+IHRo ZSBwcmUtaGFzaCBjYXNlIGFuZCBjbGllbnQgY29kZSBuZWVkcyB0byBkZWFsIHdpdGggbGFyZ2Ug Q1JMcyBpZiB0aGF0IGlzDQo+IG5vdCB3aGF0IGlzIGJlaW5nIGRvbmUuDQoNCkl04oCZcyBub3Qg YSBxdWVzdGlvbiBvZiBzdHJlYW1pbmcsIGJ1dCBhIHF1ZXN0aW9uIG9mIEhTTSB1c2FnZS4gSSBh bHJlYWR5IGZvdW5kIHNvbWUgSFNNcyBjcmFzaGluZyB3aGVuIHNlbmRpbmcgYSA+MzJNQiBtZXNz YWdlIGZvciBzaWduYXR1cmUuIE5vdCB0aGF0IG5pY2UsIGJ1dCBwbGF1c2libGUuDQoNCj4gSSBk b24ndCBrbm93IGhvdyBtdWNoIGN1cnJlbnQgc29mdHdhcmUgaXMgc2V0dXAgZm9yIGRlbGVnYXRl ZCBDUkxzLg0KDQpUZWNobmljYWxseSBzcGVha2luZywgQ1JMIGRlbGVnYXRpb24gaXMgYSBkaWZm ZXJlbnQgYmVhc3QuDQoNCkhlcmUsIHdlIGNvdWxkIGhhdmUgZWl0aGVyICgxKSBhIHNlbGYtaXNz dWVkIGNlcnRpZmljYXRlIGRlZGljYXRlZCBmb3IgQ1JMIHNpZ25pbmcsIG9yICgyKSBhbm90aGVy IENBIGNlcnRpZmljYXRlIChhdHRhY2hlZCB0byB0aGUgc2FtZSBpc3N1ZXIgYXMgdGhlIGV4aXN0 ZW50IG9uZSkgZGVkaWNhdGVkIGZvciBDUkwgc2lnbmluZy4gUmFyZWx5IHNlZW4gaW4gcHJhY3Rp Y2UuDQoNCkV4YW1wbGUgb2YgYSAoMSktdHlwZSBoaWVyYXJjaHk6DQpSb290IChDPVVULCBPPUdv diBvZiBVdG9waWEsIENOPVJvb3QgQ0EpDQogIC0+IENBIDEgKCJDPVVULCBPPU1pbmlzdHJ5IG9m IFBLSSwgQ049TGFiIENBIiwga2V5VXNhZ2U9a2V5Q2VydFNpZ24sIGlzc3VlZCBieSBSb290KQ0K ICAgIC0+IENBIDEgKCJDPVVULCBPPU1pbmlzdHJ5IG9mIFBLSSwgQ049TGFiIENBIiwga2V5VXNh Z2U9Y3JsU2lnbiwgc2lnbmVkIGJ5IHRoZSBvdGhlciBrZXkgb2YgQ0ExLCB3aGVuY2Ugc2VsZi1p c3N1ZWQpDQoNCg0KRXhhbXBsZSBvZiBhICgyKS10eXBlIGhpZXJhcmNoeToNClJvb3QgKEM9VVQs IE89R292IG9mIFV0b3BpYSwgQ049Um9vdCBDQSkNCiAgLT4gQ0EgMSAoIkM9VVQsIE89TWluaXN0 cnkgb2YgUEtJLCBDTj1MYWIgQ0EiLCBrZXlVc2FnZT1rZXlDZXJ0U2lnbiwgaXNzdWVkIGJ5IFJv b3QpDQogIC0+IENBIDEgKCJDPVVULCBPPU1pbmlzdHJ5IG9mIFBLSSwgQ049TGFiIENBIiwga2V5 VXNhZ2U9Y3JsU2lnbiwgaXNzdWVkIGJ5IFJvb3QpDQoNCg0KQm90aCBhcmUgcGVyZmVjdGx5IGNv bXBsaWFudCB3aXRoIFguNTA5IGFuZCBSRkM1MjgwLCBidXQgSSBkb27igJl0IGV4cGVjdCB0aGVt IHRvIHdvcmsgb3V0IG9mIHRoZSBib3guIFJhcmVseSB1c2VkLCBjb3JuZXIgY2FzZSwgZXRjLiBB cyBhIGd1ZXNzIGV4ZXJjaXNlLCBJ4oCZZCBzYXkgdGhhdCBPcGVuU1NMICgxLjAuMSspIHNob3Vs ZCBiZSBPSywgTWljcm9zb2Z0IGFsc28sIE5TUyBtYXkgYWNjZXB0IGl0IGRlcGVuZGluZyBvbiB0 aGUgdmFsaWRhdGluZyBsaWIgKHRoZSBvbGQgb25lIHNob3VsZCBiZSBPSywgbm90IHRoZSBuZXcg b25lKSwgYW5kIEkgd291bGRu4oCZdCBiZXQgb24gQXBwbGUuIEFuZCBmcm9tIGEgQ0HigJlzIHBl cnNwZWN0aXZlLCB0aGF04oCZcyBhIHdlaXJkIGd1biBwb2ludGVkIG9uIHRoZWlyIGZlZXQuDQoN Cg0KQ29yZGlhbGVtZW50LA0KRXJ3YW5uIEFiYWxlYQ0KDQo= From nobody Mon Aug 22 11:50:39 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD912D603 for ; Mon, 22 Aug 2016 11:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 5g9CMh8IVG5s for ; Mon, 22 Aug 2016 11:50:25 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C35412D745 for ; Mon, 22 Aug 2016 11:50:23 -0700 (PDT) Received: from hebrews (192.168.1.152) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 22 Aug 2016 12:02:34 -0700 From: Jim Schaad To: 'Erwann Abalea' References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> In-Reply-To: <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> Date: Mon, 22 Aug 2016 11:50:16 -0700 Message-ID: <015d01d1fca6$07ae7720$170b6560$@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: AQK2d0TroNuVIE0A27Dc80J1726oxAI+ZRKjAYmJKD0DDZXZBp5Vpz0Q Content-Language: en-us X-Originating-IP: [192.168.1.152] Archived-At: Cc: curdle@ietf.org, 'Ilari Liusvaara' Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 18:50:32 -0000 > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Erwann = Abalea > Sent: Monday, August 22, 2016 9:20 AM > To: Jim Schaad > Cc: curdle@ietf.org; Ilari Liusvaara > Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt >=20 > Bonjour, >=20 > > Le 19 ao=C3=BBt 2016 =C3=A0 18:59, Jim Schaad = a =C3=A9crit : > > > > > > > >> -----Original Message----- > >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari > >> Liusvaara > >> Sent: Friday, August 19, 2016 6:38 AM > >> To: curdle@ietf.org > >> Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt > >> > >> On Fri, Aug 19, 2016 at 05:30:23AM -0700, internet-drafts@ietf.org = wrote: > >>> > >>> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >>> This draft is a work item of the CURves, Deprecating and a Little > >>> more > >> Encryption of the IETF. > >>> > >>> Title : Algorithm Identifiers for Ed25519, = Ed25519ph, > > Ed448, > >> Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key > > Infrastructure > >>> Authors : Simon Josefsson > >>> Jim Schaad > >>> Filename : draft-ietf-curdle-pkix-01.txt > >>> Pages : 15 > >>> Date : 2016-08-15 > >> > >> Did a brief look: > >> > >> - The draft bans use of prehash variants for signing certificates = and > >> CRLs. What about OCSP responses? > > > > Same paragraph in section 5 - although I said SHOULD NOT rather than > > MUST NOT. > > I am more than willing to increase this level. > > > >> > >> IMO, basic cases: > >> > >> High value? Large? > >> Certificates Yes No > >> OCSP No No > >> CRL No Maybe > >> > >> So, prehashing probably shouldn't be allowed for certs, but might = be > > necressary > >> for CRLs. > > > > In many cases, the same key is being used to sign both certificates > > and CRLs so it is probably easier to have the same level of badness > > for both structures. >=20 > In some cases, and particularly in the WebPKI, the same key is used to = sign > certificates, CRLs, and OCSP responses. The size problem = doesn=E2=80=99t really exist for > OCSP responses. > Again, it=E2=80=99s not mandatory. >=20 > > CRLs are never going to be streamed in and out which is where I find > > the idea of doing hash then sign most attractive. If people believe > > that CRLs are going to be a problem, then the language would need to > > be something along the lines of -- a different signing key is needed > > for CRLs if you do the pre-hash case and client code needs to deal > > with large CRLs if that is not what is being done. >=20 > It=E2=80=99s not a question of streaming, but a question of HSM usage. = I already found > some HSMs crashing when sending a >32MB message for signature. Not = that > nice, but plausible. If I was worried about size, then I would encourage people to segment = CRLs by the use of the CRLDistribution point rather than using a = pre-hash version. It seems that is already a problem for you since I = doubt that the HSM you are looking at is doing EdDSA anyway. >=20 > > I don't know how much current software is setup for delegated CRLs. >=20 > Technically speaking, CRL delegation is a different beast. I don't see it as a different beast. It is a way to say that I am using = two different keys. One for certs and one for CRLs. Since the general = advice is don't use two different algorithms for the same private key = this is needed if you want to prevent the pre-hash signature for certs = and allow it for CRLs. >=20 > Here, we could have either (1) a self-issued certificate dedicated for = CRL signing, > or (2) another CA certificate (attached to the same issuer as the = existent one) > dedicated for CRL signing. Rarely seen in practice. >=20 > Example of a (1)-type hierarchy: > Root (C=3DUT, O=3DGov of Utopia, CN=3DRoot CA) > -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DkeyCertSign, issued > by Root) > -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DcrlSign, signed by > the other key of CA1, whence self-issued) >=20 >=20 > Example of a (2)-type hierarchy: > Root (C=3DUT, O=3DGov of Utopia, CN=3DRoot CA) > -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DkeyCertSign, issued > by Root) > -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DcrlSign, issued by > Root) >=20 >=20 > Both are perfectly compliant with X.509 and RFC5280, but I = don=E2=80=99t expect them > to work out of the box. Rarely used, corner case, etc. As a guess = exercise, I=E2=80=99d say > that OpenSSL (1.0.1+) should be OK, Microsoft also, NSS may accept it > depending on the validating lib (the old one should be OK, not the new = one), and > I wouldn=E2=80=99t bet on Apple. And from a CA=E2=80=99s perspective, = that=E2=80=99s a weird gun pointed > on their feet. I don't understand which weird gun you are referring to is. The use of = delegated CRLs? Jim >=20 >=20 > Cordialement, > Erwann Abalea >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Aug 23 02:10:36 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E31D712D8D2 for ; Tue, 23 Aug 2016 02:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=docusign2com.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fgj9QjnPbwO for ; Tue, 23 Aug 2016 02:10:31 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0132.outbound.protection.outlook.com [104.47.32.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C3912B00B for ; Tue, 23 Aug 2016 02:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ju1l/LDSosW03bRLrR1AoalyJqfRtQsXCL0W0uQSlyk=; b=r4MTR6dI+3HNLI1FKxUuW1aYqh61uiLNHaMQ/P7iS96pmE4Osoqw0y42W1xRyCzoRDtjmUFD3pLm4JQr9jJ3lmHH7kWF66hBZZodnu+F7Y6RQJ2jAV5jtNgjZvfYFFDnU5mDJJc2Dqx1LLCB5W08Y65SiBYaExIwvf2Jz6TdbI0= Received: from BN3PR0401MB1395.namprd04.prod.outlook.com (10.161.209.154) by BN3PR0401MB1396.namprd04.prod.outlook.com (10.161.209.155) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 23 Aug 2016 09:05:04 +0000 Received: from BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) by BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 09:05:04 +0000 From: Erwann Abalea To: Jim Schaad Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR/JEZVaOc0mVdR0S33g5msrFEiA== Date: Tue, 23 Aug 2016 09:05:04 +0000 Message-ID: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> In-Reply-To: <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erwann.Abalea@docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-ms-office365-filtering-correlation-id: 19cb204c-b921-4832-b1f1-08d3cb349265 x-microsoft-exchange-diagnostics: 1; BN3PR0401MB1396; 6:03IqBxpkKmSKA4GJk3o+hVeJKhbhuTX0pfv6diknWOS4t1OtnhXHV9qZhoBszFyOzUcqbKYOgh1XHQfxsiYH50wHKqmyDIrRZscBt0ytfWcUK2d9CqN2+10WpRn8vL5gTRs03AF4bIVIUH3DQRu+bCH6iSqF+QTwYqDX9OHl/G+XTTbJG4g8QaKRIEbQDtkksA2RWKvnGgxr4Y/u8HeoQNaEybTzCzFZIQk7om46Npe0rJO9+lI88Q59j+M1k/ElAFaAsm7U+2PS9yA8ipRoHNkIJ6J8In5qxUBW6HdT0lQ=; 5:OYDrU9rlU8kaQzBOaD5m9O12WqbzDPFp8Z2R5fz9LdzR9A1trlue3Factuj8bXTaCksVTQwSmkYeu8xmLBaDS/70J+Kne00wVNmbLzxpZqKr2wj0QBFpj2TNKuXvbyPdngVhQ1mbYrkAvJfzUwezgg==; 24:K9Z27wWgpW6E3EkHhCvQEQyb92gSPhVnwVgxvSKLOh2HdlcNXtU9l2sIkBmbo6C3lvDeksoyi8VyqGgU01X3h2AL07CP6Clcu6HzlhZmmdY=; 7:2avnjf6ajhAIkbBciohafRWiu+pYmxrRdF+KEbP/57ngl/SurLZ0SRlB2t4mrcZoKGzNe2hLyEQtis/ogFszbm/riFtQsJopzJUWB13ZS3VEPEaUEnYUJXyGx4rPkV5qKuwl4kNG+rGpBagYkK68q+VnuWLggnnoSb1pdM8K8rWGE8rvfB0uAm4n/QoaD1a+9kYDfeDk5sd3qw2lRdpwFEmpbCQ/IQjzG/742/lJ227Q1R3/05RDqocX5CCTfD5m x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0401MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0401MB1396; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0401MB1396; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(13464003)(24454002)(105586002)(3660700001)(81166006)(77096005)(81156014)(86362001)(230783001)(33656002)(2950100001)(102836003)(3846002)(92566002)(2900100001)(586003)(99286002)(110136002)(106116001)(189998001)(106356001)(5660300001)(5002640100001)(8676002)(82746002)(5890100001)(97736004)(8936002)(4326007)(66066001)(83716003)(19580395003)(19580405001)(10400500002)(87936001)(6116002)(68736007)(36756003)(11100500001)(54356999)(7736002)(122556002)(3280700002)(50986999)(101416001)(93886004)(76176999)(2906002)(7846002)(16236675004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0401MB1396; H:BN3PR0401MB1395.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: docusign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_F65E63F2A35C4383A4450A86E2DA0EC5docusigncom_" MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 09:05:04.2586 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0401MB1396 Archived-At: Cc: "curdle@ietf.org" , Ilari Liusvaara Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 09:10:34 -0000 --_000_F65E63F2A35C4383A4450A86E2DA0EC5docusigncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Qm9uam91ciwNCg0KTGUgMjIgYW/Du3QgMjAxNiDDoCAyMDo1MCwgSmltIFNjaGFhZCA8aWV0ZkBh dWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+IGEgw6ljcml0 IDoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEN1cmRsZSBbbWFpbHRvOmN1 cmRsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJ3YW5uIEFiYWxlYQ0KU2VudDog TW9uZGF5LCBBdWd1c3QgMjIsIDIwMTYgOToyMCBBTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVn dXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+Pg0KQ2M6IGN1cmRs ZUBpZXRmLm9yZzxtYWlsdG86Y3VyZGxlQGlldGYub3JnPjsgSWxhcmkgTGl1c3ZhYXJhIDxpbGFy aWxpdXN2YWFyYUB3ZWxoby5jb208bWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbT4+DQpT dWJqZWN0OiBSZTogW0N1cmRsZV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeC0w MS50eHQNCg0KQm9uam91ciwNCg0KTGUgMTkgYW/Du3QgMjAxNiDDoCAxODo1OSwgSmltIFNjaGFh ZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+ IGEgw6ljcml0IDoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDdXJk bGUgW21haWx0bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElsYXJpDQpM aXVzdmFhcmENClNlbnQ6IEZyaWRheSwgQXVndXN0IDE5LCAyMDE2IDY6MzggQU0NClRvOiBjdXJk bGVAaWV0Zi5vcmc8bWFpbHRvOmN1cmRsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ3VyZGxl XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTAxLnR4dA0KDQpPbiBGcmksIEF1 ZyAxOSwgMjAxNiBhdCAwNTozMDoyM0FNIC0wNzAwLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8 bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoNCg0KW+KApl0NCg0KDQpD UkxzIGFyZSBuZXZlciBnb2luZyB0byBiZSBzdHJlYW1lZCBpbiBhbmQgb3V0IHdoaWNoIGlzIHdo ZXJlIEkgZmluZA0KdGhlIGlkZWEgb2YgZG9pbmcgaGFzaCB0aGVuIHNpZ24gbW9zdCBhdHRyYWN0 aXZlLiAgSWYgcGVvcGxlIGJlbGlldmUNCnRoYXQgQ1JMcyBhcmUgZ29pbmcgdG8gYmUgYSBwcm9i bGVtLCB0aGVuIHRoZSBsYW5ndWFnZSB3b3VsZCBuZWVkIHRvDQpiZSBzb21ldGhpbmcgYWxvbmcg dGhlIGxpbmVzIG9mIC0tIGEgZGlmZmVyZW50IHNpZ25pbmcga2V5IGlzIG5lZWRlZA0KZm9yIENS THMgaWYgeW91IGRvIHRoZSBwcmUtaGFzaCBjYXNlIGFuZCBjbGllbnQgY29kZSBuZWVkcyB0byBk ZWFsDQp3aXRoIGxhcmdlIENSTHMgaWYgdGhhdCBpcyBub3Qgd2hhdCBpcyBiZWluZyBkb25lLg0K DQpJdOKAmXMgbm90IGEgcXVlc3Rpb24gb2Ygc3RyZWFtaW5nLCBidXQgYSBxdWVzdGlvbiBvZiBI U00gdXNhZ2UuIEkgYWxyZWFkeSBmb3VuZA0Kc29tZSBIU01zIGNyYXNoaW5nIHdoZW4gc2VuZGlu ZyBhID4zMk1CIG1lc3NhZ2UgZm9yIHNpZ25hdHVyZS4gTm90IHRoYXQNCm5pY2UsIGJ1dCBwbGF1 c2libGUuDQoNCklmIEkgd2FzIHdvcnJpZWQgYWJvdXQgc2l6ZSwgdGhlbiBJIHdvdWxkIGVuY291 cmFnZSBwZW9wbGUgdG8gc2VnbWVudCBDUkxzIGJ5IHRoZSB1c2Ugb2YgdGhlIENSTERpc3RyaWJ1 dGlvbiBwb2ludCByYXRoZXIgdGhhbiB1c2luZyBhIHByZS1oYXNoIHZlcnNpb24uICBJdCBzZWVt cyB0aGF0IGlzIGFscmVhZHkgYSBwcm9ibGVtIGZvciB5b3Ugc2luY2UgSSBkb3VidCB0aGF0IHRo ZSBIU00geW91IGFyZSBsb29raW5nIGF0IGlzIGRvaW5nIEVkRFNBIGFueXdheS4NCg0KVGhlIHBy b2JsZW0gd2FzIHNvbHZlZCBieSBkb2luZyB0aGUgaGFzaCBvdXRzaWRlIG9mIHRoZSBIU00sIGFu ZCByZXF1ZXN0aW5nIGl0IHRvIG9ubHkgcGVyZm9ybSB0aGUgYmFyZSBzaWduYXR1cmUgb3BlcmF0 aW9uLg0KDQoNCg0KSSBkb24ndCBrbm93IGhvdyBtdWNoIGN1cnJlbnQgc29mdHdhcmUgaXMgc2V0 dXAgZm9yIGRlbGVnYXRlZCBDUkxzLg0KDQpUZWNobmljYWxseSBzcGVha2luZywgQ1JMIGRlbGVn YXRpb24gaXMgYSBkaWZmZXJlbnQgYmVhc3QuDQoNCkkgZG9uJ3Qgc2VlIGl0IGFzIGEgZGlmZmVy ZW50IGJlYXN0LiBJdCBpcyBhIHdheSB0byBzYXkgdGhhdCBJIGFtIHVzaW5nIHR3byBkaWZmZXJl bnQga2V5cy4gIE9uZSBmb3IgY2VydHMgYW5kIG9uZSBmb3IgQ1JMcy4gIFNpbmNlIHRoZSBnZW5l cmFsIGFkdmljZSBpcyBkb24ndCB1c2UgdHdvIGRpZmZlcmVudCBhbGdvcml0aG1zIGZvciB0aGUg c2FtZSBwcml2YXRlIGtleSB0aGlzIGlzIG5lZWRlZCBpZiB5b3Ugd2FudCB0byBwcmV2ZW50IHRo ZSBwcmUtaGFzaCBzaWduYXR1cmUgZm9yIGNlcnRzIGFuZCBhbGxvdyBpdCBmb3IgQ1JMcy4NCg0K Q1JMIGRlbGVnYXRpb24gaXMgbW9yZSBjbG9zZSB0byDCqyBpbmRpcmVjdCBDUkwgwrsgdGhhbiBo YXZpbmcgdGhlIHNhbWUgQ0EgdXNlIGRpZmZlcmVudCBrZXlzLg0KDQoNCg0KSGVyZSwgd2UgY291 bGQgaGF2ZSBlaXRoZXIgKDEpIGEgc2VsZi1pc3N1ZWQgY2VydGlmaWNhdGUgZGVkaWNhdGVkIGZv ciBDUkwgc2lnbmluZywNCm9yICgyKSBhbm90aGVyIENBIGNlcnRpZmljYXRlIChhdHRhY2hlZCB0 byB0aGUgc2FtZSBpc3N1ZXIgYXMgdGhlIGV4aXN0ZW50IG9uZSkNCmRlZGljYXRlZCBmb3IgQ1JM IHNpZ25pbmcuIFJhcmVseSBzZWVuIGluIHByYWN0aWNlLg0KDQpFeGFtcGxlIG9mIGEgKDEpLXR5 cGUgaGllcmFyY2h5Og0KUm9vdCAoQz1VVCwgTz1Hb3Ygb2YgVXRvcGlhLCBDTj1Sb290IENBKQ0K IC0+IENBIDEgKCJDPVVULCBPPU1pbmlzdHJ5IG9mIFBLSSwgQ049TGFiIENBIiwga2V5VXNhZ2U9 a2V5Q2VydFNpZ24sIGlzc3VlZA0KYnkgUm9vdCkNCiAgIC0+IENBIDEgKCJDPVVULCBPPU1pbmlz dHJ5IG9mIFBLSSwgQ049TGFiIENBIiwga2V5VXNhZ2U9Y3JsU2lnbiwgc2lnbmVkIGJ5DQp0aGUg b3RoZXIga2V5IG9mIENBMSwgd2hlbmNlIHNlbGYtaXNzdWVkKQ0KDQoNCkV4YW1wbGUgb2YgYSAo MiktdHlwZSBoaWVyYXJjaHk6DQpSb290IChDPVVULCBPPUdvdiBvZiBVdG9waWEsIENOPVJvb3Qg Q0EpDQogLT4gQ0EgMSAoIkM9VVQsIE89TWluaXN0cnkgb2YgUEtJLCBDTj1MYWIgQ0EiLCBrZXlV c2FnZT1rZXlDZXJ0U2lnbiwgaXNzdWVkDQpieSBSb290KQ0KIC0+IENBIDEgKCJDPVVULCBPPU1p bmlzdHJ5IG9mIFBLSSwgQ049TGFiIENBIiwga2V5VXNhZ2U9Y3JsU2lnbiwgaXNzdWVkIGJ5DQpS b290KQ0KDQoNCkJvdGggYXJlIHBlcmZlY3RseSBjb21wbGlhbnQgd2l0aCBYLjUwOSBhbmQgUkZD NTI4MCwgYnV0IEkgZG9u4oCZdCBleHBlY3QgdGhlbQ0KdG8gd29yayBvdXQgb2YgdGhlIGJveC4g UmFyZWx5IHVzZWQsIGNvcm5lciBjYXNlLCBldGMuIEFzIGEgZ3Vlc3MgZXhlcmNpc2UsIEnigJlk IHNheQ0KdGhhdCBPcGVuU1NMICgxLjAuMSspIHNob3VsZCBiZSBPSywgTWljcm9zb2Z0IGFsc28s IE5TUyBtYXkgYWNjZXB0IGl0DQpkZXBlbmRpbmcgb24gdGhlIHZhbGlkYXRpbmcgbGliICh0aGUg b2xkIG9uZSBzaG91bGQgYmUgT0ssIG5vdCB0aGUgbmV3IG9uZSksIGFuZA0KSSB3b3VsZG7igJl0 IGJldCBvbiBBcHBsZS4gQW5kIGZyb20gYSBDQeKAmXMgcGVyc3BlY3RpdmUsIHRoYXTigJlzIGEg d2VpcmQgZ3VuIHBvaW50ZWQNCm9uIHRoZWlyIGZlZXQuDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB3 aGljaCAgd2VpcmQgZ3VuIHlvdSBhcmUgcmVmZXJyaW5nIHRvIGlzLiAgVGhlIHVzZSBvZiBkZWxl Z2F0ZWQgQ1JMcz8NCg0KSeKAmXZlIHNlZW4gQ0FzIChhcyBvcmdhbml6YXRpb25zKSBmYWlsaW5n IHRvIGNvcnJlY3RseSByZW5ldytyZWtleSBhIENBIGFuZCBwcm9kdWNlIGdvb2QgQ1JMcyBzaWdu ZWQgYnkgdGhlIG5ldyBrZXkgKGl04oCZcyBzaW1pbGFyIHRvIHRoZSAoMiktdHlwZSBoaWVyYXJj aHkgZGVzY3JpYmVkKS4gUmVuZXcgYSBDQSBpcyBzZWVuIGFzIGEgc3RhbmRhcmQgb3BlcmF0aW9u LCB5ZXQgc29tZSBmYWlsIHRvIGRvIHNvLiBBc2tpbmcgQ0Etb3JncyB0byBzZXR1cCBtb3JlIGNv bXBsaWNhdGVkIHN0dWZmIHN1Y2ggYXMgc2VsZi1pc3N1ZWQgY2VydHMgb3IgbXVsdGkta2V5IENB cyB0byBkbyB0aGVpciBqb2IgaXMgdW5mcmllbmRseS4NCg0KDQpDb3JkaWFsZW1lbnQsDQpFcndh bm4gQWJhbGVhDQoNCg== --_000_F65E63F2A35C4383A4450A86E2DA0EC5docusigncom_ Content-Type: text/html; charset="utf-8" Content-ID: <808239119E32EE4D84DBDD0618B63986@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQm9uam91ciw8YnIgY2xhc3M9IiI+ DQo8ZGl2IGFwcGxlLWNvbnRlbnQtZWRpdGVkPSJ0cnVlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TGUgMjIgYW/Du3QgMjAxNiDDoCAyMDo1 MCwgSmltIFNjaGFhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20i IGNsYXNzPSIiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNsYXNzPSIiPg0K RnJvbTogQ3VyZGxlIFs8YSBocmVmPSJtYWlsdG86Y3VyZGxlLWJvdW5jZXNAaWV0Zi5vcmciIGNs YXNzPSIiPm1haWx0bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBF cndhbm4gQWJhbGVhPGJyIGNsYXNzPSIiPg0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTYg OToyMCBBTTxiciBjbGFzcz0iIj4NClRvOiBKaW0gU2NoYWFkICZsdDs8YSBocmVmPSJtYWlsdG86 aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgY2xhc3M9IiI+aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbTwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpjdXJkbGVAaWV0Zi5vcmci IGNsYXNzPSIiPmN1cmRsZUBpZXRmLm9yZzwvYT47IElsYXJpIExpdXN2YWFyYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbSIgY2xhc3M9IiI+aWxhcmlsaXVzdmFh cmFAd2VsaG8uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQpTdWJqZWN0OiBSZTogW0N1cmRsZV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jdXJkbGUtcGtpeC0wMS50eHQ8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpCb25qb3VyLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkxlIDE5IGFvw7t0IDIwMTYgw6AgMTg6NTksIEpp bSBTY2hhYWQgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIiBjbGFz cz0iIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDsgYSDDqWNyaXQgOjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNs YXNzPSIiPg0KRnJvbTogQ3VyZGxlIFs8YSBocmVmPSJtYWlsdG86Y3VyZGxlLWJvdW5jZXNAaWV0 Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpjdXJkbGUtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZiBJbGFyaTxiciBjbGFzcz0iIj4NCkxpdXN2YWFyYTxiciBjbGFzcz0iIj4NClNlbnQ6 IEZyaWRheSwgQXVndXN0IDE5LCAyMDE2IDY6MzggQU08YnIgY2xhc3M9IiI+DQpUbzogPGEgaHJl Zj0ibWFpbHRvOmN1cmRsZUBpZXRmLm9yZyIgY2xhc3M9IiI+Y3VyZGxlQGlldGYub3JnPC9hPjxi ciBjbGFzcz0iIj4NClN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LWN1cmRsZS1wa2l4LTAxLnR4dDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIEZyaSwg QXVnIDE5LCAyMDE2IGF0IDA1OjMwOjIzQU0gLTA3MDAsIDxhIGhyZWY9Im1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9h PiB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQpb4oCmXTwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBh dXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+Q1JMcyBhcmUgbmV2ZXIgZ29p bmcgdG8gYmUgc3RyZWFtZWQgaW4gYW5kIG91dCB3aGljaCBpcyB3aGVyZSBJIGZpbmQ8YnIgY2xh c3M9IiI+DQp0aGUgaWRlYSBvZiBkb2luZyBoYXNoIHRoZW4gc2lnbiBtb3N0IGF0dHJhY3RpdmUu ICZuYnNwO0lmIHBlb3BsZSBiZWxpZXZlPGJyIGNsYXNzPSIiPg0KdGhhdCBDUkxzIGFyZSBnb2lu ZyB0byBiZSBhIHByb2JsZW0sIHRoZW4gdGhlIGxhbmd1YWdlIHdvdWxkIG5lZWQgdG88YnIgY2xh c3M9IiI+DQpiZSBzb21ldGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIC0tIGEgZGlmZmVyZW50IHNp Z25pbmcga2V5IGlzIG5lZWRlZDxiciBjbGFzcz0iIj4NCmZvciBDUkxzIGlmIHlvdSBkbyB0aGUg cHJlLWhhc2ggY2FzZSBhbmQgY2xpZW50IGNvZGUgbmVlZHMgdG8gZGVhbDxiciBjbGFzcz0iIj4N CndpdGggbGFyZ2UgQ1JMcyBpZiB0aGF0IGlzIG5vdCB3aGF0IGlzIGJlaW5nIGRvbmUuPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KSXTigJlzIG5vdCBhIHF1ZXN0 aW9uIG9mIHN0cmVhbWluZywgYnV0IGEgcXVlc3Rpb24gb2YgSFNNIHVzYWdlLiBJIGFscmVhZHkg Zm91bmQ8YnIgY2xhc3M9IiI+DQpzb21lIEhTTXMgY3Jhc2hpbmcgd2hlbiBzZW5kaW5nIGEgJmd0 OzMyTUIgbWVzc2FnZSBmb3Igc2lnbmF0dXJlLiBOb3QgdGhhdDxiciBjbGFzcz0iIj4NCm5pY2Us IGJ1dCBwbGF1c2libGUuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIHN0eWxlPSJm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+SWYNCiBJIHdhcyB3b3JyaWVkIGFib3V0IHNpemUsIHRoZW4gSSB3b3VsZCBlbmNv dXJhZ2UgcGVvcGxlIHRvIHNlZ21lbnQgQ1JMcyBieSB0aGUgdXNlIG9mIHRoZSBDUkxEaXN0cmli dXRpb24gcG9pbnQgcmF0aGVyIHRoYW4gdXNpbmcgYSBwcmUtaGFzaCB2ZXJzaW9uLiAmbmJzcDtJ dCBzZWVtcyB0aGF0IGlzIGFscmVhZHkgYSBwcm9ibGVtIGZvciB5b3Ugc2luY2UgSSBkb3VidCB0 aGF0IHRoZSBIU00geW91IGFyZSBsb29raW5nIGF0IGlzIGRvaW5nIEVkRFNBIGFueXdheS48L3Nw YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoZSBwcm9i bGVtIHdhcyBzb2x2ZWQgYnkgZG9pbmcgdGhlIGhhc2ggb3V0c2lkZSBvZiB0aGUgSFNNLCBhbmQg cmVxdWVzdGluZyBpdCB0byBvbmx5IHBlcmZvcm0gdGhlIGJhcmUgc2lnbmF0dXJlIG9wZXJhdGlv bi48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9u dC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUt aGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj5JIGRvbid0IGtub3cgaG93IG11Y2ggY3VycmVudCBzb2Z0d2FyZSBpcyBzZXR1cCBm b3IgZGVsZWdhdGVkIENSTHMuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNz PSIiPg0KVGVjaG5pY2FsbHkgc3BlYWtpbmcsIENSTCBkZWxlZ2F0aW9uIGlzIGEgZGlmZmVyZW50 IGJlYXN0LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBzdHlsZT0iZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGlu ZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIi PkkNCiBkb24ndCBzZWUgaXQgYXMgYSBkaWZmZXJlbnQgYmVhc3QuIEl0IGlzIGEgd2F5IHRvIHNh eSB0aGF0IEkgYW0gdXNpbmcgdHdvIGRpZmZlcmVudCBrZXlzLiAmbmJzcDtPbmUgZm9yIGNlcnRz IGFuZCBvbmUgZm9yIENSTHMuICZuYnNwO1NpbmNlIHRoZSBnZW5lcmFsIGFkdmljZSBpcyBkb24n dCB1c2UgdHdvIGRpZmZlcmVudCBhbGdvcml0aG1zIGZvciB0aGUgc2FtZSBwcml2YXRlIGtleSB0 aGlzIGlzIG5lZWRlZCBpZiB5b3Ugd2FudCB0byBwcmV2ZW50IHRoZSBwcmUtaGFzaA0KIHNpZ25h dHVyZSBmb3IgY2VydHMgYW5kIGFsbG93IGl0IGZvciBDUkxzLjwvc3Bhbj48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+Q1JMIGRlbGVnYXRpb24gaXMgbW9yZSBj bG9zZSB0byDCqyZuYnNwO2luZGlyZWN0IENSTCZuYnNwO8K7IHRoYW4gaGF2aW5nIHRoZSBzYW1l IENBIHVzZSBkaWZmZXJlbnQga2V5cy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpIZXJl LCB3ZSBjb3VsZCBoYXZlIGVpdGhlciAoMSkgYSBzZWxmLWlzc3VlZCBjZXJ0aWZpY2F0ZSBkZWRp Y2F0ZWQgZm9yIENSTCBzaWduaW5nLDxiciBjbGFzcz0iIj4NCm9yICgyKSBhbm90aGVyIENBIGNl cnRpZmljYXRlIChhdHRhY2hlZCB0byB0aGUgc2FtZSBpc3N1ZXIgYXMgdGhlIGV4aXN0ZW50IG9u ZSk8YnIgY2xhc3M9IiI+DQpkZWRpY2F0ZWQgZm9yIENSTCBzaWduaW5nLiBSYXJlbHkgc2VlbiBp biBwcmFjdGljZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpFeGFtcGxlIG9mIGEgKDEp LXR5cGUgaGllcmFyY2h5OjxiciBjbGFzcz0iIj4NClJvb3QgKEM9VVQsIE89R292IG9mIFV0b3Bp YSwgQ049Um9vdCBDQSk8YnIgY2xhc3M9IiI+DQombmJzcDstJmd0OyBDQSAxICgmcXVvdDtDPVVU LCBPPU1pbmlzdHJ5IG9mIFBLSSwgQ049TGFiIENBJnF1b3Q7LCBrZXlVc2FnZT1rZXlDZXJ0U2ln biwgaXNzdWVkPGJyIGNsYXNzPSIiPg0KYnkgUm9vdCk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDstJmd0OyBDQSAxICgmcXVvdDtDPVVULCBPPU1pbmlzdHJ5IG9mIFBLSSwgQ049TGFi IENBJnF1b3Q7LCBrZXlVc2FnZT1jcmxTaWduLCBzaWduZWQgYnk8YnIgY2xhc3M9IiI+DQp0aGUg b3RoZXIga2V5IG9mIENBMSwgd2hlbmNlIHNlbGYtaXNzdWVkKTxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkV4YW1wbGUgb2YgYSAoMiktdHlwZSBoaWVyYXJjaHk6 PGJyIGNsYXNzPSIiPg0KUm9vdCAoQz1VVCwgTz1Hb3Ygb2YgVXRvcGlhLCBDTj1Sb290IENBKTxi ciBjbGFzcz0iIj4NCiZuYnNwOy0mZ3Q7IENBIDEgKCZxdW90O0M9VVQsIE89TWluaXN0cnkgb2Yg UEtJLCBDTj1MYWIgQ0EmcXVvdDssIGtleVVzYWdlPWtleUNlcnRTaWduLCBpc3N1ZWQ8YnIgY2xh c3M9IiI+DQpieSBSb290KTxiciBjbGFzcz0iIj4NCiZuYnNwOy0mZ3Q7IENBIDEgKCZxdW90O0M9 VVQsIE89TWluaXN0cnkgb2YgUEtJLCBDTj1MYWIgQ0EmcXVvdDssIGtleVVzYWdlPWNybFNpZ24s IGlzc3VlZCBieTxiciBjbGFzcz0iIj4NClJvb3QpPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KQm90aCBhcmUgcGVyZmVjdGx5IGNvbXBsaWFudCB3aXRoIFguNTA5 IGFuZCBSRkM1MjgwLCBidXQgSSBkb27igJl0IGV4cGVjdCB0aGVtPGJyIGNsYXNzPSIiPg0KdG8g d29yayBvdXQgb2YgdGhlIGJveC4gUmFyZWx5IHVzZWQsIGNvcm5lciBjYXNlLCBldGMuIEFzIGEg Z3Vlc3MgZXhlcmNpc2UsIEnigJlkIHNheTxiciBjbGFzcz0iIj4NCnRoYXQgT3BlblNTTCAoMS4w LjEmIzQzOykgc2hvdWxkIGJlIE9LLCBNaWNyb3NvZnQgYWxzbywgTlNTIG1heSBhY2NlcHQgaXQ8 YnIgY2xhc3M9IiI+DQpkZXBlbmRpbmcgb24gdGhlIHZhbGlkYXRpbmcgbGliICh0aGUgb2xkIG9u ZSBzaG91bGQgYmUgT0ssIG5vdCB0aGUgbmV3IG9uZSksIGFuZDxiciBjbGFzcz0iIj4NCkkgd291 bGRu4oCZdCBiZXQgb24gQXBwbGUuIEFuZCBmcm9tIGEgQ0HigJlzIHBlcnNwZWN0aXZlLCB0aGF0 4oCZcyBhIHdlaXJkIGd1biBwb2ludGVkPGJyIGNsYXNzPSIiPg0Kb24gdGhlaXIgZmVldC48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogZG9uJ3Qg dW5kZXJzdGFuZCB3aGljaCAmbmJzcDt3ZWlyZCBndW4geW91IGFyZSByZWZlcnJpbmcgdG8gaXMu ICZuYnNwO1RoZSB1c2Ugb2YgZGVsZWdhdGVkIENSTHM/PC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5J4oCZdmUgc2VlbiBDQXMgKGFzIG9yZ2FuaXph dGlvbnMpIGZhaWxpbmcgdG8gY29ycmVjdGx5IHJlbmV3JiM0MztyZWtleSBhIENBIGFuZCBwcm9k dWNlIGdvb2QgQ1JMcyBzaWduZWQgYnkgdGhlIG5ldyBrZXkgKGl04oCZcyBzaW1pbGFyIHRvIHRo ZSAoMiktdHlwZSBoaWVyYXJjaHkgZGVzY3JpYmVkKS4gUmVuZXcgYSBDQSBpcyBzZWVuIGFzIGEg c3RhbmRhcmQgb3BlcmF0aW9uLCB5ZXQgc29tZSBmYWlsIHRvIGRvIHNvLiBBc2tpbmcgQ0Etb3Jn cyB0bw0KIHNldHVwIG1vcmUgY29tcGxpY2F0ZWQgc3R1ZmYgc3VjaCBhcyBzZWxmLWlzc3VlZCBj ZXJ0cyBvciBtdWx0aS1rZXkgQ0FzIHRvIGRvIHRoZWlyIGpvYiBpcyB1bmZyaWVuZGx5LjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Q29yZGlhbGVtZW50LDwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5Fcndhbm4gQWJhbGVhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_F65E63F2A35C4383A4450A86E2DA0EC5docusigncom_-- From nobody Tue Aug 23 07:20:45 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15412DA90 for ; Tue, 23 Aug 2016 07:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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=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 GVeMirTv1sMl for ; Tue, 23 Aug 2016 07:20:35 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F6C12D9C6 for ; Tue, 23 Aug 2016 07:14:40 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 93so10204961qtg.2 for ; Tue, 23 Aug 2016 07:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=nrBgs63l03RVQ9YfoMb9EDIT4C8Itd4EjB0QdcNd8yU=; b=Uh5djzDoYd1VT2VAXt2m2g2NB2IaxIW1CBrgwgoTu2vU8lVjh5xI317JEVEdn37eLo rp1HRpF9lzDFLH69BLnu3uAYyZgpEIJBE5RDA9cXwJNkPQ//7CrBaJ9rSW1Fq6qMZkbA 2vdQVyh8aHTiAfMUviF0r5sP8RERY7VejLIPlBchMlJwKrT/TJs3olDFRE5neIVMolj9 y/s5/596CgOd1uvVoh+WqGZqTO8eWCjh7TBqBgCMLGJ6+kM4DXuLBJyDmYsHF0Zx+uul ps+qoRZMBW74FHdSK5sm0XknoYsR8CR4HxOpY0eG3/b3I/2Brb+rysBlPwqFYMfsHZvG wfQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=nrBgs63l03RVQ9YfoMb9EDIT4C8Itd4EjB0QdcNd8yU=; b=CVpkOY4khiXKvzurJ3o0BxTf4FGBbynKmYJH49sqLwwlyPWsCTv2s4Ls1pSJFsUTOD kqXY38FEwWwryngiqkMt2YwrBK/Hh2C+/VkVrIoYbSRnvFiMvUA23Uh5RPL7ZnRsbObZ snsds+9vvWiAta2UPDdBL1EcO9SkYDtAc16p8HNV3QNw3R8N+nxbrfre8+qPdOJ2GHPZ Pv8N6gguM3j8l/ipY2TBGbf/bXd0vuUlWBOy0lvOT/F8JJ2u4LTdqu7lnkdV6kaQxB33 3yaoeWaCnuUuuu1V3cdK35ewbcum16OGS7a+BKFsfns9Ks/33vznBl92nHzr6y5MbPe4 JnKw== X-Gm-Message-State: AEkoouu6D+Nmd35yyfKaY0tGstbpKH8E3MHWPPyHaAvZK0VgJDp5XIzuaBPNxjInaJeQDQ== X-Received: by 10.200.42.153 with SMTP id b25mr30410768qta.72.1471961679479; Tue, 23 Aug 2016 07:14:39 -0700 (PDT) Received: from SantoshBrain (pool-173-73-91-110.washdc.fios.verizon.net. [173.73.91.110]) by smtp.gmail.com with ESMTPSA id d38sm1859463qte.17.2016.08.23.07.14.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Aug 2016 07:14:37 -0700 (PDT) From: "Santosh Chokhani" To: "'Erwann Abalea'" , "'Jim Schaad'" References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> In-Reply-To: Date: Tue, 23 Aug 2016 10:14:37 -0400 Message-ID: <04f301d1fd48$af15d010$0d417030$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04F4_01D1FD27.2805B6B0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQK2d0TroNuVIE0A27Dc80J1726oxAI+ZRKjAYmJKD0DDZXZBgIvidC7AUwfnTmeOxdjYA== Content-Language: en-us Archived-At: Cc: curdle@ietf.org, 'Ilari Liusvaara' Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:20:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04F4_01D1FD27.2805B6B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indirect CRL have inherent security problems and complexity. You should = avoid them if at all possible. =20 For reference to security concerns, see my presentation at IETF meeting = to PKIX circa 2004 Fall in Washington DC or paper at NIST PKI research = conference circa 2005 or 2006. =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Erwann Abalea Sent: Tuesday, August 23, 2016 5:05 AM To: Jim Schaad Cc: curdle@ietf.org; Ilari Liusvaara Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt =20 Bonjour, =20 Le 22 ao=C3=BBt 2016 =C3=A0 20:50, Jim Schaad > a =C3=A9crit : -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Erwann Abalea Sent: Monday, August 22, 2016 9:20 AM To: Jim Schaad > Cc: curdle@ietf.org ; Ilari Liusvaara = > Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Bonjour, Le 19 ao=C3=BBt 2016 =C3=A0 18:59, Jim Schaad > a =C3=A9crit : -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, August 19, 2016 6:38 AM To: curdle@ietf.org =20 Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt On Fri, Aug 19, 2016 at 05:30:23AM -0700, internet-drafts@ietf.org = wrote: =20 =20 [=E2=80=A6] CRLs are never going to be streamed in and out which is where I find the idea of doing hash then sign most attractive. If people believe that CRLs are going to be a problem, then the language would need to be something along the lines of -- a different signing key is needed for CRLs if you do the pre-hash case and client code needs to deal with large CRLs if that is not what is being done. It=E2=80=99s not a question of streaming, but a question of HSM usage. I = already found some HSMs crashing when sending a >32MB message for signature. Not that nice, but plausible. If I was worried about size, then I would encourage people to segment = CRLs by the use of the CRLDistribution point rather than using a = pre-hash version. It seems that is already a problem for you since I = doubt that the HSM you are looking at is doing EdDSA anyway. =20 The problem was solved by doing the hash outside of the HSM, and = requesting it to only perform the bare signature operation. I don't know how much current software is setup for delegated CRLs. Technically speaking, CRL delegation is a different beast. I don't see it as a different beast. It is a way to say that I am using = two different keys. One for certs and one for CRLs. Since the general = advice is don't use two different algorithms for the same private key = this is needed if you want to prevent the pre-hash signature for certs = and allow it for CRLs. =20 CRL delegation is more close to =C2=AB indirect CRL =C2=BB than having = the same CA use different keys. Here, we could have either (1) a self-issued certificate dedicated for = CRL signing, or (2) another CA certificate (attached to the same issuer as the = existent one) dedicated for CRL signing. Rarely seen in practice. Example of a (1)-type hierarchy: Root (C=3DUT, O=3DGov of Utopia, CN=3DRoot CA) -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DkeyCertSign, issued by Root) -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DcrlSign, signed by the other key of CA1, whence self-issued) Example of a (2)-type hierarchy: Root (C=3DUT, O=3DGov of Utopia, CN=3DRoot CA) -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DkeyCertSign, issued by Root) -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DcrlSign, issued by Root) Both are perfectly compliant with X.509 and RFC5280, but I don=E2=80=99t = expect them to work out of the box. Rarely used, corner case, etc. As a guess = exercise, I=E2=80=99d say that OpenSSL (1.0.1+) should be OK, Microsoft also, NSS may accept it depending on the validating lib (the old one should be OK, not the new = one), and I wouldn=E2=80=99t bet on Apple. And from a CA=E2=80=99s perspective, = that=E2=80=99s a weird gun pointed on their feet. I don't understand which weird gun you are referring to is. The use of = delegated CRLs? =20 I=E2=80=99ve seen CAs (as organizations) failing to correctly = renew+rekey a CA and produce good CRLs signed by the new key = (it=E2=80=99s similar to the (2)-type hierarchy described). Renew a CA = is seen as a standard operation, yet some fail to do so. Asking CA-orgs = to setup more complicated stuff such as self-issued certs or multi-key = CAs to do their job is unfriendly. =20 =20 Cordialement, Erwann Abalea =20 ------=_NextPart_000_04F4_01D1FD27.2805B6B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Indirect CRL have inherent security problems and complexity.=C2=A0 You = should avoid them if at all possible.

 

For reference to security concerns, see my presentation at IETF meeting = to PKIX circa 2004 Fall in Washington DC or paper at NIST PKI research = conference circa 2005 or 2006.

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Erwann = Abalea
Sent: Tuesday, August 23, 2016 5:05 AM
To: = Jim Schaad <ietf@augustcellars.com>
Cc: curdle@ietf.org; = Ilari Liusvaara <ilariliusvaara@welho.com>
Subject: Re: = [Curdle] I-D Action: = draft-ietf-curdle-pkix-01.txt

 

Bonjour,

 

Le 22 ao=C3=BBt 2016 =C3=A0 20:50, Jim Schaad <ietf@augustcellars.com> a = =C3=A9crit :



-----Origina= l Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Erwann Abalea
Sent: Monday, August 22, 2016 9:20 = AM
To: Jim Schaad <ietf@augustcellars.com>
= Cc: curdle@ietf.org; Ilari = Liusvaara <ilariliusvaara@welho.com>=
Subject: Re: [Curdle] I-D Action: = draft-ietf-curdle-pkix-01.txt

Bonjour,


Le 19 = ao=C3=BBt 2016 =C3=A0 18:59, Jim Schaad <ietf@augustcellars.com> a = =C3=A9crit :




-----Origina= l Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari
Liusvaara
Sent: Friday, August 19, 2016 6:38 = AM
To: curdle@ietf.org
Subject: Re: = [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt

On Fri, Aug = 19, 2016 at 05:30:23AM -0700, internet-drafts@ietf.org = wrote:

 <= /o:p>

 

[=E2=80=A6]





CRLs are = never going to be streamed in and out which is where I find
the idea = of doing hash then sign most attractive.  If people believe
that = CRLs are going to be a problem, then the language would need to
be = something along the lines of -- a different signing key is needed
for = CRLs if you do the pre-hash case and client code needs to deal
with = large CRLs if that is not what is being = done.


It=E2=80= =99s not a question of streaming, but a question of HSM usage. I already = found
some HSMs crashing when sending a >32MB message for = signature. Not that
nice, but = plausible.


If I = was worried about size, then I would encourage people to segment CRLs by = the use of the CRLDistribution point rather than using a pre-hash = version.  It seems that is already a problem for you since I doubt = that the HSM you are looking at is doing EdDSA = anyway.

 

The problem was solved by doing the hash outside of = the HSM, and requesting it to only perform the bare signature = operation.







I don't = know how much current software is setup for delegated = CRLs.


Technica= lly speaking, CRL delegation is a different = beast.


I don't = see it as a different beast. It is a way to say that I am using two = different keys.  One for certs and one for CRLs.  Since the = general advice is don't use two different algorithms for the same = private key this is needed if you want to prevent the pre-hash signature = for certs and allow it for = CRLs.

 

CRL delegation is more close to =C2=AB indirect = CRL =C2=BB than having the same CA use different = keys.






Here, = we could have either (1) a self-issued certificate dedicated for CRL = signing,
or (2) another CA certificate (attached to the same issuer = as the existent one)
dedicated for CRL signing. Rarely seen in = practice.

Example of a (1)-type hierarchy:
Root (C=3DUT, = O=3DGov of Utopia, CN=3DRoot CA)
 -> CA 1 ("C=3DUT, = O=3DMinistry of PKI, CN=3DLab CA", keyUsage=3DkeyCertSign, = issued
by Root)
   -> CA 1 ("C=3DUT, = O=3DMinistry of PKI, CN=3DLab CA", keyUsage=3DcrlSign, signed = by
the other key of CA1, whence self-issued)


Example of a = (2)-type hierarchy:
Root (C=3DUT, O=3DGov of Utopia, CN=3DRoot = CA)
 -> CA 1 ("C=3DUT, O=3DMinistry of PKI, CN=3DLab = CA", keyUsage=3DkeyCertSign, issued
by Root)
 -> CA 1 = ("C=3DUT, O=3DMinistry of PKI, CN=3DLab CA", = keyUsage=3DcrlSign, issued by
Root)


Both are perfectly = compliant with X.509 and RFC5280, but I don=E2=80=99t expect them
to = work out of the box. Rarely used, corner case, etc. As a guess exercise, = I=E2=80=99d say
that OpenSSL (1.0.1+) should be OK, Microsoft also, = NSS may accept it
depending on the validating lib (the old one should = be OK, not the new one), and
I wouldn=E2=80=99t bet on Apple. And = from a CA=E2=80=99s perspective, that=E2=80=99s a weird gun = pointed
on their feet.


I don't = understand which  weird gun you are referring to is.  The use = of delegated CRLs?

 

I=E2=80=99ve seen CAs (as organizations) failing to = correctly renew+rekey a CA and produce good CRLs signed by the new key = (it=E2=80=99s similar to the (2)-type hierarchy described). Renew a CA = is seen as a standard operation, yet some fail to do so. Asking CA-orgs = to setup more complicated stuff such as self-issued certs or multi-key = CAs to do their job is unfriendly.

 

 

Cordialement,

Erwann Abalea

 

------=_NextPart_000_04F4_01D1FD27.2805B6B0-- From nobody Tue Aug 23 07:42:41 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BAB12DAF8 for ; Tue, 23 Aug 2016 07:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 Vcqk6Tsw2wAw for ; Tue, 23 Aug 2016 07:42:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 34E1512D981 for ; Tue, 23 Aug 2016 07:23:03 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5186D43342D; Tue, 23 Aug 2016 14:23:02 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 3AAF1433413; Tue, 23 Aug 2016 14:23:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471962182; bh=3v9sKiSeaJDKruEFoo44TTbjZz6EACqI1bQN0UOnBCY=; l=292; h=From:To:CC:Date:References:In-Reply-To:From; b=ym49TjdInMPbTjJpS2ULbR0s1HPz1tVUIbpXNa3oON3bgAlb1RKJOt6LN2z9LcW4b vRUOnUj8aXirF7AFAiXHqIM5Hu6SehyQzS6xd4mYhPsqKmj09Ayf7GNuCV0uAZKW2r 3+7dZgzlrux57YugNqfFTsVmgHHKH4ltBpbnz4cQ= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 373521FC88; Tue, 23 Aug 2016 14:23:02 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 10:23:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 10:23:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 10:23:01 -0400 From: "Salz, Rich" To: Santosh Chokhani , 'Erwann Abalea' , 'Jim Schaad' Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR+hWCWz+FG6dHB0ykQX0M3yoKRqBQjNIAgAA4GgCABKwpgIAAKdkAgADu1ACAAFZ9gP//vvcg Date: Tue, 23 Aug 2016 14:23:01 +0000 Message-ID: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> In-Reply-To: <04f301d1fd48$af15d010$0d417030$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.113] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" , 'Ilari Liusvaara' Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 14:42:39 -0000 QXMgY28tY2hhaXI6ICBTbyBwZXJoYXBzIHRoZSBxdWVzdGlvbiBiZWNvbWVzOiAgaG93IGltcG9y dGFudCBpcyBpdCB0aGF0ICJqdW1ibyIgQ1JMJ3MgY2FuIGJlIHNpZ25lZCB3aXRoIHRoZXNlIG5l dyBhbGdvcml0aG1zPw0KDQpBcyBhbiBpbmRpdmlkdWFsOiAgc2luY2Ugd2UgZG9uJ3QgZXZlbiBo YXZlIGNlcnRpZmljYXRlcyB5ZXQsIG5vdCBpbXBvcnRhbnQuDQoNCg== From nobody Tue Aug 23 08:15:22 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40AB12DA24 for ; Tue, 23 Aug 2016 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=docusign2com.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 629YS-395Po2 for ; Tue, 23 Aug 2016 08:15:16 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0117.outbound.protection.outlook.com [104.47.37.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E3A12DBB3 for ; Tue, 23 Aug 2016 07:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/YEd8fkgCPMyAFPw1qVStrwUAVroZlTfpj0hMsAQ5bk=; b=Ic5VkZtibihBhbdJOWPhb/N1vSxCzOcQst7nImeu1nLff0r6Ib3vt1QiJCkaoVNUo91qMfXEnp5qltwYk2Ne9JGQ6gSCpxd5UZFfOEn3mtnqs4ZQos3JjS+1Hyo5X7IcwJ3pMEKk2MM5y8j29lGOlxObWqgynrrsSgnWPlDMiKY= Received: from BN3PR0401MB1395.namprd04.prod.outlook.com (10.161.209.154) by BN3PR0401MB1395.namprd04.prod.outlook.com (10.161.209.154) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 23 Aug 2016 14:49:12 +0000 Received: from BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) by BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) with mapi id 15.01.0557.027; Tue, 23 Aug 2016 14:49:12 +0000 From: Erwann Abalea To: "Salz, Rich" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR/JEZVaOc0mVdR0S33g5msrFEiA== Date: Tue, 23 Aug 2016 14:49:11 +0000 Message-ID: <5EF47F8C-C70D-4A7F-A5EE-0A27BF4DC402@docusign.com> References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erwann.Abalea@docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [84.14.125.226] x-ms-office365-filtering-correlation-id: f326b10e-f123-4991-29d9-08d3cb64a552 x-microsoft-exchange-diagnostics: 1; BN3PR0401MB1395; 6:19grVFTJd7HjJGLDaTtEkkwaNHvo4ZcKAN7sm3ig7FlsQ8PjWNeS+PgjvnskFNwkUAqyI3GEwvI/0cYgRRjRcDv2kR0UtJ4YfKJNHWevuxUh2FcWlMoNk4FNZPliOEotZo5boFUnrS4KJLYmzZzMZNRTf2OC3DnkJePIWOed/E4DR/Ac2jA+kQhEcydXMMBd+2iPSe+HIFZMJI4aqmIxeuWugG36doQeDgLa98vDujUgsVhb1Dt/XlgIHdmvk1D5DO/y600caZk7qDGMd9JFzHCrapooSygzxepFGIrQxio=; 5:cN+K7ua+hdzuWm7h0jjter/b0UvYLCdba1n4DS1zFeYxw/4Zx2kMN2lsUuWq5Avuwr7Wde6mznZiUOlu5K7rvNDvkILqW8LpWV12GKRUkFyD5DbPx+ReeLbtm8tA58WOlsQMA7deBBdurgKIX1RpcQ==; 24:jeBoxMKLpPOJ+Wz91SxKi/plnVEQnSqlnAyD7xDyUd6To2DDgDQDYn4ku/yrv1oGB42tdbvWePmgqcF7WRqi7nHTrvHok3jILhkiAl1wg2A=; 7:1g27AkpYvz49H5AVLDiH96dVY7GYp40iUVdZcUePZIjBlSF/kuDSdm+/UnA8UUWXzZpXB+o6TJ95URTncZBF2zn18j3Z8ETb7bAMyoDpJk4QmlQV2y9JmptlNkv7thCiE8uUvBKFJBFiS98knH52wDFNSL5zzd5o1E2CA20D7PI3z1T3e4YPYjxgAUCyS29Nlkyz0+XO3D0SBrwha8dBnVvWNUsoeaFMlw93WI8fjI/z5DkCJA/L8Z5LAo+8PpHK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0401MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0401MB1395; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0401MB1395; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(82746002)(189998001)(97736004)(77096005)(110136002)(8676002)(81156014)(305945005)(3660700001)(5660300001)(7736002)(105586002)(68736007)(2950100001)(106356001)(2900100001)(99286002)(7846002)(81166006)(83716003)(76176999)(54356999)(8936002)(106116001)(87936001)(93886004)(3280700002)(11100500001)(102836003)(5002640100001)(3846002)(66066001)(6116002)(10400500002)(122556002)(230783001)(50986999)(101416001)(33656002)(86362001)(586003)(2906002)(92566002)(4326007)(36756003)(19580395003)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0401MB1395; H:BN3PR0401MB1395.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: docusign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <6A0D90D6D007B54E94C3047D5F30F712@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 14:49:11.7493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0401MB1395 Archived-At: Cc: Santosh Chokhani , Ilari Liusvaara , "curdle@ietf.org" , Jim Schaad Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:15:21 -0000 SXMgaXQgZ29vZCBwcmFjdGljZSB0byBzcGVjaWZ5IGEgc2lnbmF0dXJlIGFsZ29yaXRobSBhbmQg ZGVjbGFyZSB0aGF0IGl0IGNhbuKAmXQgYmUgdXNlZCBmb3IgeW91LCB5b3UgYW5kIHlvdT8NCg0K Q29yZGlhbGVtZW50LA0KRXJ3YW5uIEFiYWxlYQ0KDQo+IExlIDIzIGFvw7t0IDIwMTYgw6AgMTY6 MjMsIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+IGEgw6ljcml0IDoNCj4gDQo+IEFzIGNv LWNoYWlyOiAgU28gcGVyaGFwcyB0aGUgcXVlc3Rpb24gYmVjb21lczogIGhvdyBpbXBvcnRhbnQg aXMgaXQgdGhhdCAianVtYm8iIENSTCdzIGNhbiBiZSBzaWduZWQgd2l0aCB0aGVzZSBuZXcgYWxn b3JpdGhtcz8NCj4gDQo+IEFzIGFuIGluZGl2aWR1YWw6ICBzaW5jZSB3ZSBkb24ndCBldmVuIGhh dmUgY2VydGlmaWNhdGVzIHlldCwgbm90IGltcG9ydGFudC4NCj4gDQoNCg== From nobody Tue Aug 23 08:33:50 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289B312D633 for ; Tue, 23 Aug 2016 08:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 XvqPZXfK6E0U for ; Tue, 23 Aug 2016 08:33:48 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D216112D9B0 for ; Tue, 23 Aug 2016 08:18:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D77433005B5 for ; Tue, 23 Aug 2016 11:18:10 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JmHbLGfU5Jy1 for ; Tue, 23 Aug 2016 11:18:10 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 9CA763002C2; Tue, 23 Aug 2016 11:18:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 23 Aug 2016 11:18:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:33:49 -0000 > As co-chair: So perhaps the question becomes: how important is it = that "jumbo" CRL's can be signed with these new algorithms? If we hope to see adoption in the Web PKI, then the answer is yes. Russ From nobody Tue Aug 23 08:36:23 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4E412D122 for ; Tue, 23 Aug 2016 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 DZsapv7cPp28 for ; Tue, 23 Aug 2016 08:36:20 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4786712D5E9 for ; Tue, 23 Aug 2016 08:26:25 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B5BE643342D; Tue, 23 Aug 2016 15:26:24 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9B45E433423; Tue, 23 Aug 2016 15:26:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471965984; bh=SppfWEFj3gb1cqugjlu7EmGhj5QOi61HT8O8VqTib78=; l=143; h=From:To:CC:Date:References:In-Reply-To:From; b=AQ/scCuet9EtAjzAWElOjeu6Gz4/tr1gw+vZvnw0LiGvo/HXggSOHQaiyJJoMquEl lExyNRE3EtUBAIa8z2BV8tkoIIAa1uu/QM5+UM/zvZd2BO0+LhXsTwt1OOu/p3XhDU QJ66RGLibocu4KQix/ukfKGaHp9832KKszDKqmqA= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 974FA1FC8E; Tue, 23 Aug 2016 15:26:24 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 08:26:24 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 11:26:24 -0400 From: "Salz, Rich" To: Russ Housley Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR+hWCWz+FG6dHB0ykQX0M3yoKRqBQjNIAgAA4GgCABKwpgIAAKdkAgADu1ACAAFZ9gP//vvcggABSygD//78VwA== Date: Tue, 23 Aug 2016 15:26:23 +0000 Message-ID: <70326f1a873d47fa89c359d81acd4249@usma1ex-dag1mb1.msg.corp.akamai.com> References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.23] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:36:22 -0000 > If we hope to see adoption in the Web PKI, then the answer is yes. Perhaps my definition is off, but where are CRL's used in the webpki? From nobody Tue Aug 23 08:36:46 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A809E12D5CA for ; Tue, 23 Aug 2016 08:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 O-C-TBiDLb6Z for ; Tue, 23 Aug 2016 08:36:44 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6117E12D9C8 for ; Tue, 23 Aug 2016 08:27:37 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CED293F401C; Tue, 23 Aug 2016 15:27:36 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id AE8313F4006; Tue, 23 Aug 2016 15:27:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1471966056; bh=0XcVDNHa+2BtxDgdO4IuWLS+XLCiFvYJQuJTQqRjH6I=; l=292; h=From:To:CC:Date:References:In-Reply-To:From; b=HnvDZMhFdPVycEYPIiL/MiWfOBeqFRwKGPZJUaIwxiiDF0SzE+fkjFRPXIfJe5AQp 8gOePNiR9wjXLJVyea8KpWyE0md4p1T+F7c5fhaoGymTpNKh1nsXMNrmwiyKft2siC WJ2u/DYoO5s1PSjqKfhWeCh3BYPc/eno6TbvT1sU= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 9AFE81FC86; Tue, 23 Aug 2016 15:27:36 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 11:27:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 11:27:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 23 Aug 2016 11:27:36 -0400 From: "Salz, Rich" To: Erwann Abalea Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR+hWCWz+FG6dHB0ykQX0M3yoKRqBQjNIAgAA4GgCABKwpgIAAKdkAgADu1ACAAFZ9gP//vvcggABKsYD//8eQkA== Date: Tue, 23 Aug 2016 15:27:35 +0000 Message-ID: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> <5EF47F8C-C70D-4A7F-A5EE-0A27BF4DC402@docusign.com> In-Reply-To: <5EF47F8C-C70D-4A7F-A5EE-0A27BF4DC402@docusign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.23] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Santosh Chokhani , Ilari Liusvaara , "curdle@ietf.org" , Jim Schaad Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:36:46 -0000 IA0KPiBJcyBpdCBnb29kIHByYWN0aWNlIHRvIHNwZWNpZnkgYSBzaWduYXR1cmUgYWxnb3JpdGht IGFuZCBkZWNsYXJlIHRoYXQgaXQgY2Fu4oCZdCBiZQ0KPiB1c2VkIGZvciB5b3UsIHlvdSBhbmQg eW91Pw0KDQpJIGRvbid0IGtub3cgaWYgaXQncyBnb29kIHByYWN0aWNlLCBidXQgaXQgaGFwcGVu cyBhbGwgdGhlIHRpbWUgd2l0aCBjcnlwdG8gYWxnb3JpdGhtcy4NCg== From nobody Tue Aug 23 08:42:29 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A689712D532 for ; Tue, 23 Aug 2016 08:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 tqlhaZ3WzCSv for ; Tue, 23 Aug 2016 08:42:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B242C12D0C4 for ; Tue, 23 Aug 2016 08:39:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AB6A1300572 for ; Tue, 23 Aug 2016 11:39:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KcEk_oEaCn1P for ; Tue, 23 Aug 2016 11:39:33 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id C29E83002C2; Tue, 23 Aug 2016 11:39:33 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <70326f1a873d47fa89c359d81acd4249@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 23 Aug 2016 11:39:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> <70326f1a873d47fa89c359d81acd4249@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 15:42:27 -0000 >> If we hope to see adoption in the Web PKI, then the answer is yes. >=20 > Perhaps my definition is off, but where are CRL's used in the webpki? Mostly, OCSP Responders take the CRL as input to produce their cached = OCSP Responses. In S/MIME, which is not really a separate PKI, we see some mail user = agent consume the CRL directly. Russ From nobody Tue Aug 23 12:45:24 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9EE12B019 for ; Tue, 23 Aug 2016 12:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=briansmith-org.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 7k11nj_5LhaY for ; Tue, 23 Aug 2016 12:45:21 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFD5112DA39 for ; Tue, 23 Aug 2016 12:45:19 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id e63so168617283ith.1 for ; Tue, 23 Aug 2016 12:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rUFjt+i7hSTk0/bdcuHZPqo2IXInNme4RR/KWEn0V5g=; b=jmvQd5h0RPhfONHL4WwGHttzuW4T2Ezwi1s+45E0ig4q32X9Xp570gl5Lfffwk4ISz s0tig6j3pV70ydLTE4OdtTswBZulwC9ZR5fyy63J/qJ42jqHP3c5h507opvjixXBK94H DlfN74fdJ3ZR9XTitQwXOcL67lZ3PAVqxO+cpMmPDy3tt1FD0Up8vvg5h9pEyDL6f7Oo Cm1Y73MjlzUgMz0Ye2phC/1J3o/BPbsP31RKNMV0CpyhBdGrGTcUOl0sKWkKgUyJLrjx qHpddrjQMfdKgvg7BGPhylRCOHjLHnpV0PApI6Iy2t27SQ4JHX0ev7A3afkLDZ6ZBPUD WUmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rUFjt+i7hSTk0/bdcuHZPqo2IXInNme4RR/KWEn0V5g=; b=PidktekCPGsjGQmcrYmm4gIU9TjJAYmwKZdMTbjVnapBmRgt0N8Djf4VjEJPNwxvi0 k3MouLCC/VK9X8YUJd4ygOHu24CKb54siQgVyrRbo33dNmTmqOLPdDKdSijlZfvKI96V kH99UndnRVjmH3g6/Jxf+llA2xKiqEtCbWNzV2Msv/MjdYlpcypduwLL1bssruGk9jS9 zPjt4gmC5Ns47L+RA8NGUwCSGGF60geyuJpAyf5dR5iqRDbHQ72Qs17w2SNUyiCQyi8c ScIZdN/7CeuGYyNMBCiOnod/rSsi2LR9r/go/ev7XmgJNXsW/QCBATxRc+SL4rGs82S9 MSlw== X-Gm-Message-State: AEkoouvMhT3jk3zMPQZEksaZXvolp6V3rEnSY2kgOdVvtJVsdJsw9VFVfI6yySssF2kaxOCBOr+xsIuZIOLN0w== X-Received: by 10.107.1.7 with SMTP id 7mr31863074iob.196.1471981519264; Tue, 23 Aug 2016 12:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.74.73 with HTTP; Tue, 23 Aug 2016 12:45:18 -0700 (PDT) In-Reply-To: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> From: Brian Smith Date: Tue, 23 Aug 2016 09:45:18 -1000 Message-ID: To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:45:22 -0000 Russ Housley wrote: >> As co-chair: So perhaps the question becomes: how important is it that "jumbo" CRL's can be signed with these new algorithms? > > If we hope to see adoption in the Web PKI, then the answer is yes. The Web PKI in practice has already rejected the use of CRLs. We shouldn't make things more complicated to support CRLs. We should assume that internet protocols don't use CRLs, and let the users of CRLs write their own RFCs to handle their special cases. In particular, I think it is perfectly reasonable and good to require ("MUST") the non-prehash variant be used for certificate and OCSP response signatures, and not say anything about CRLs at all. Another draft could then specify a way to use these algorithms for CRLs. The idea of "PKIX" was that certificates and certificate-related stuff like OCSP, CRLs, ASN.1 decoding and encoding, etc. would work uniformly across S/MIME, TLS, and whatever else uses PKIX stuff. That idea has failed. Now we have to consider "Web PKI" and "the other stuff" separately whenever we get into these details. In the Web PKI, CRLs are dead. (Somebody should write an RFC to this effect.) Cheers, Brian From nobody Tue Aug 23 14:18:09 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4644D12DB2A for ; Tue, 23 Aug 2016 14:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 dDcHnfhzS2XJ for ; Tue, 23 Aug 2016 14:18:07 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F2B12DB36 for ; Tue, 23 Aug 2016 14:18:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2C8523005B4 for ; Tue, 23 Aug 2016 17:18:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 649iw2srnFce for ; Tue, 23 Aug 2016 17:18:01 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id E145E3000E3; Tue, 23 Aug 2016 17:18:00 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Tue, 23 Aug 2016 17:18:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> To: Brian Smith X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 21:18:08 -0000 Brian: > Russ Housley wrote: >>> As co-chair: So perhaps the question becomes: how important is it = that "jumbo" CRL's can be signed with these new algorithms? >>=20 >> If we hope to see adoption in the Web PKI, then the answer is yes. >=20 > The Web PKI in practice has already rejected the use of CRLs. We > shouldn't make things more complicated to support CRLs. We should > assume that internet protocols don't use CRLs, and let the users of > CRLs write their own RFCs to handle their special cases. >=20 > In particular, I think it is perfectly reasonable and good to require > ("MUST") the non-prehash variant be used for certificate and OCSP > response signatures, and not say anything about CRLs at all. Another > draft could then specify a way to use these algorithms for CRLs. >=20 > The idea of "PKIX" was that certificates and certificate-related stuff > like OCSP, CRLs, ASN.1 decoding and encoding, etc. would work > uniformly across S/MIME, TLS, and whatever else uses PKIX stuff. That > idea has failed. Now we have to consider "Web PKI" and "the other > stuff" separately whenever we get into these details. In the Web PKI, > CRLs are dead. (Somebody should write an RFC to this effect.) I am going to try and avoid taking some of the bait you offer. We = actually seem to agree on more than we disagree. I think it is quite reasonable to require ("MUST") the non-prehash = variant of EdDSA for signatures, CRLs, and OCSP response. The ASN.1 = structures are the same, so why put the in different documents. Russ From nobody Tue Aug 23 19:20:25 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 988DF12D5B4 for ; Tue, 23 Aug 2016 19:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 PWH4EJa7_q1m for ; Tue, 23 Aug 2016 19:20:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00F312D587 for ; Tue, 23 Aug 2016 19:20:18 -0700 (PDT) Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 23 Aug 2016 19:32:04 -0700 From: Jim Schaad To: Date: Tue, 23 Aug 2016 19:19:46 -0700 Message-ID: <030101d1fdad$fd33e060$f79ba120$@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: AdH9q40MBwj4IC2eSkKd6vmPUY3Zqg== Content-Language: en-us X-Originating-IP: [24.21.96.37] Archived-At: Subject: [Curdle] PKCS#11, PKI OIDs and EdDSA/X* X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 02:20:23 -0000 Off list somebody has asked me how we are supposed to be working with PKCS#11. I am not an expert on this interface and, since I was toiling away on the bottling line all day, I did not have a lot of time to try and figure out what the problems where. The following is my best guess as to the problem, I will be trying to get some clarifications to make sure that I am right. Currently there is a mechanism for doing Elliptic Curve and it uses structures that are tied very closely to the ASN.1 structure that are defined for EC and ECDSA today. As an example the Parameters ASN.1 structure is used as the EC domain parameters for public and private keys. With the current way we have setup the public key/private key structures, there is no direct and easy mapping between what we are doing here and what is done for the EC Mechanisms. I will note that even if one uses the EC Mechanism there are still going to be some odd things, for example the field CKA_EC_POINT is defined to be the ANSI X9.62 ECPoint value Q which is not what needs to be done here. One way forward is to recommend that a new mechanism be defined as the key formats are going to be different so it is not a clear mapping. However, I don't know that we have the knowledge or the authority to make this decision as the PKCS#11 specification is an OASIS document. If there are OASIS people from there on the list, by all means speak up. For the JOSE and COSE documents, the approach that was taking was along the same vein as create a new mechanism. This is just one data point and may not be relavent. The questions at this point are: 1. Is this the only PKCS#11 issue that people with knowledge of the API can see? 2. Is this a big enough issue to change our approach to use of OIDs? 3. Do we recommend to the appropriate people that a new mechanism be created? Jim From nobody Tue Aug 23 20:15:04 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A412D73E for ; Tue, 23 Aug 2016 20:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 1-bEPTMGKoH6 for ; Tue, 23 Aug 2016 20:15:01 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F7F12D1AD for ; Tue, 23 Aug 2016 20:15:01 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id x131so185762955ite.0 for ; Tue, 23 Aug 2016 20:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gOzQw8FW4EYBtmyBOaav0qHXsoFlXizRtApAg2JxV6U=; b=ST0ffSm2B1cTkDXo8PB/2M+6QHaxBxdXUYU/qf1AHo4lOfKsy3ZtIv8UF1r4CgQxAu MuK7Srnh4s9htHUE8iTXBZL21PsVAXnugP9MeuD1T97rhjYgMM4wgcysJbwfwsTG2rWY YnvoPTpU1p0q7o+reQHFc/Wp979Gpw0L+pVAU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gOzQw8FW4EYBtmyBOaav0qHXsoFlXizRtApAg2JxV6U=; b=edw15mtZL56rx61H7q5ZMgl4OJWB5Yh9ONAm9dtaECiieZFgioqA05yWOcdc+DWi/f H0X0iU8GJMoeFe2opsCKUr8+fZINCRODIf8hGT62noV7Fzh0F56M3YWPJYNhv7ASGsp3 YBQW9f0ctyP79V9teUey2VXFiTaRuqXX1KT5QhcuKuiOrd5LeLo+/54y7lWcO148z+1h tXquZIrDW8RAId+YKa/+ZUjAo24wuWOrCv7ksdirED80vds2i7RAgfhWIZecG1BR4zhD 3U5f5AdINFOc3SxcKL5dYfeOcuMtlxXQuz/zfBs8Iw9o9TZ4ttS5o91He3txkRf+iqAM /Xgg== X-Gm-Message-State: AEkooutx7HQx7PL7Lu0pgWSn5P6AGno+zV/Tw1djlI9MV2ANrjFl2m3wn3R00cZuckzk6+YsVuzxhuWHhxgVkL+i X-Received: by 10.36.200.134 with SMTP id w128mr1631060itf.92.1472008500579; Tue, 23 Aug 2016 20:15:00 -0700 (PDT) MIME-Version: 1.0 References: <030101d1fdad$fd33e060$f79ba120$@augustcellars.com> In-Reply-To: <030101d1fdad$fd33e060$f79ba120$@augustcellars.com> From: David Benjamin Date: Wed, 24 Aug 2016 03:14:49 +0000 Message-ID: To: Jim Schaad , curdle@ietf.org Content-Type: multipart/alternative; boundary=94eb2c057978c8db6d053ac8af59 Archived-At: Subject: Re: [Curdle] PKCS#11, PKI OIDs and EdDSA/X* X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 03:15:03 -0000 --94eb2c057978c8db6d053ac8af59 Content-Type: text/plain; charset=UTF-8 With the caveat that I'm not all that familiar with PKCS#11 either, as you note, it seems trying to stuff EdDSA, etc., into EC mechanisms would require contortions anyway. And we may well wish to define even more novel schemes that are even further from X9.62. So we'll need this path to exist anyway. My gut feeling is that creating new mechanisms and, if needed, cutting down on the friction involved in doing so, would be the best option, for much the same reasons as wanting to use top-level OIDs in SPKIs. David On Tue, Aug 23, 2016 at 7:20 PM Jim Schaad wrote: > Off list somebody has asked me how we are supposed to be working with > PKCS#11. I am not an expert on this interface and, since I was toiling > away > on the bottling line all day, I did not have a lot of time to try and > figure > out what the problems where. The following is my best guess as to the > problem, I will be trying to get some clarifications to make sure that I am > right. > > Currently there is a mechanism for doing Elliptic Curve and it uses > structures that are tied very closely to the ASN.1 structure that are > defined for EC and ECDSA today. As an example the Parameters ASN.1 > structure is used as the EC domain parameters for public and private keys. > > With the current way we have setup the public key/private key structures, > there is no direct and easy mapping between what we are doing here and what > is done for the EC Mechanisms. I will note that even if one uses the EC > Mechanism there are still going to be some odd things, for example the > field > CKA_EC_POINT is defined to be the ANSI X9.62 ECPoint value Q which is not > what needs to be done here. > > One way forward is to recommend that a new mechanism be defined as the key > formats are going to be different so it is not a clear mapping. However, I > don't know that we have the knowledge or the authority to make this > decision > as the PKCS#11 specification is an OASIS document. If there are OASIS > people from there on the list, by all means speak up. > > For the JOSE and COSE documents, the approach that was taking was along the > same vein as create a new mechanism. This is just one data point and may > not be relavent. > > The questions at this point are: > 1. Is this the only PKCS#11 issue that people with knowledge of the API > can > see? > 2. Is this a big enough issue to change our approach to use of OIDs? > 3. Do we recommend to the appropriate people that a new mechanism be > created? > > Jim > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c057978c8db6d053ac8af59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With the caveat that I'm not all that familiar with PK= CS#11 either, as you note, it seems trying to stuff EdDSA, etc., into EC me= chanisms would require contortions anyway. And we may well wish to define e= ven more novel schemes that are even further from X9.62. So we'll need = this path to exist anyway.

My gut feeling is that creati= ng new mechanisms and, if needed, cutting down on the friction involved in = doing so, would be the best option, for much the same reasons as wanting to= use top-level OIDs in SPKIs.

David

On Tue, Aug 23, 2016 at 7:20 PM Jim Schaad <ietf@augustcellars.com> wrote:
Off list somebody has asked me how we= are supposed to be working with
PKCS#11.=C2=A0 I am not an expert on this interface and, since I was toilin= g away
on the bottling line all day, I did not have a lot of time to try and figur= e
out what the problems where.=C2=A0 The following is my best guess as to the=
problem, I will be trying to get some clarifications to make sure that I am=
right.

Currently there is a mechanism for doing Elliptic Curve and it uses
structures that are tied very closely to the ASN.1 structure that are
defined for EC and ECDSA today.=C2=A0 =C2=A0As an example the Parameters AS= N.1
structure is used as the EC domain parameters for public and private keys.<= br>
With the current way we have setup the public key/private key structures, there is no direct and easy mapping between what we are doing here and what=
is done for the EC Mechanisms.=C2=A0 I will note that even if one uses the = EC
Mechanism there are still going to be some odd things, for example the fiel= d
CKA_EC_POINT=C2=A0 is defined to be the ANSI X9.62 ECPoint value Q which is= not
what needs to be done here.

One way forward is to recommend that a new mechanism be defined as the key<= br> formats are going to be different so it is not a clear mapping.=C2=A0 Howev= er, I
don't know that we have the knowledge or the authority to make this dec= ision
as the PKCS#11 specification is an OASIS document.=C2=A0 If there are OASIS=
people from there on the list, by all means speak up.

For the JOSE and COSE documents, the approach that was taking was along the=
same vein as create a new mechanism.=C2=A0 This is just one data point and = may
not be relavent.

The questions at this point are:
1.=C2=A0 Is this the only PKCS#11 issue that people with knowledge of the A= PI can
see?
2.=C2=A0 Is this a big enough issue to change our approach to use of OIDs?<= br> 3.=C2=A0 Do we recommend to the appropriate people that a new mechanism be<= br> created?

Jim


_______________________________________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle
--94eb2c057978c8db6d053ac8af59-- From nobody Wed Aug 24 02:51:44 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DCC12D85E for ; Wed, 24 Aug 2016 02:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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=docusign2com.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j77jl1BNfSDF for ; Wed, 24 Aug 2016 02:51:41 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0116.outbound.protection.outlook.com [104.47.40.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 130EB12D5A1 for ; Wed, 24 Aug 2016 02:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=DOCUSIGN2COM.onmicrosoft.com; s=selector1-docusign-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=t+V3bPSPzrodq+33Dp1i5hg2+ZrOqiPXQWoqsIFavvA=; b=bp3+yBpE2KO/yQlefAPJkSzEWgNhC6VjnUYaonMp1aXb8Rn/+SBToaozy4LavT1D61aZw5KuFK8im/e9MKvswhJrz20B87N+RD/RLarmjVszb343sD7V8uuImMDMqqHq+LfH5ea2CBmBaMNty9iAgk2sjEk1uM/WPxJMtFsqddM= Received: from BN3PR0401MB1395.namprd04.prod.outlook.com (10.161.209.154) by BN3PR0401MB1394.namprd04.prod.outlook.com (10.161.209.153) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Wed, 24 Aug 2016 09:51:38 +0000 Received: from BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) by BN3PR0401MB1395.namprd04.prod.outlook.com ([10.161.209.154]) with mapi id 15.01.0557.027; Wed, 24 Aug 2016 09:51:38 +0000 From: Erwann Abalea To: Brian Smith Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt Thread-Index: AQHR/JEZVaOc0mVdR0S33g5msrFEiA== Date: Wed, 24 Aug 2016 09:51:37 +0000 Message-ID: <69EF42B2-8912-4B05-93DF-FA548D8AE099@docusign.com> References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Erwann.Abalea@docusign.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [192.93.124.97] x-ms-office365-filtering-correlation-id: 8038784e-08b7-4451-d026-08d3cc043dfa x-microsoft-exchange-diagnostics: 1; BN3PR0401MB1394; 6:etJhRssOQz3D9/wNNKk341JhoS6yteCx0HApaO1WK+W+mjOyJNbwZfofvs5fBadtR9vDEMa4IMDroVngQpVSSzxHPHp18sA7+NgIFYNRLsbMyLDXmgpfbSVzsiN4/+hTEzH3dNhTtAi2UXLAIfepGwDlGN7HnzxPsHfSIfEO9adQdecO5AlqzPBlsKLVyTkhXGe6DPbOICf+53838NUPBSpin4K7iM7gwO0yH3T31qQmea4kqpzG3Ms/drV40NUWMjKnWfTACPsxuPcoZ9j9DtPOa5uQnFkY4iJWVZNJHFE=; 5:JvfVA2Fv3SkwcyILHQPw4ucHFjwpbm9Cs4jcKIXowM/HfEWLGqkXuJNEBmRP84yURnq/Yvt3Ly4r2gbUfqTEhItoTEYd9u7GueCFSnt44SvZV3I0fbcFkMHrLeSCGK92pIcKzjUeLHzO9XtxCZpPQQ==; 24:SoASOxM6+0S5KqOddbMFNEvwHtl5IgegOQeEmpLpt8LCgnhSrguOGbUnkMN/+cmeIUHCE2tCHfPiJaovvqwMdN6nFSZ4sLZhk0wszcStoRo=; 7:RoV8tXc5qPBfVetsdp7jzGFv8anolzIO8CPFCYU+YECwseq5t7+y/DtIZ3+wCsvtcaw4XxGmyX7x+WyKUCnhC8NbNuXgW1OnpcnUiYaVL0Uel1RyBqbEl+VfKHACcLJ3wAP7f7X3oClOU5FwrJsOWl1dHvX6lxbYFuz6vGgII+7hIXL0SKVsuOD0bUXaCJX1bMAgi6NU5TCT8yG1VmCQAw2kogwV37yTGboXyCtPNZ4C9qmX4gQbKa4AWh/svAIe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0401MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR0401MB1394; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0401MB1394; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(24454002)(110136002)(106116001)(82746002)(97736004)(99286002)(101416001)(8676002)(2950100001)(2900100001)(10400500002)(50986999)(76176999)(11100500001)(83716003)(77096005)(8936002)(81156014)(105586002)(81166006)(3280700002)(54356999)(19580395003)(87936001)(86362001)(3660700001)(2906002)(5002640100001)(106356001)(19580405001)(5660300001)(122556002)(92566002)(230783001)(33656002)(4326007)(68736007)(36756003)(7846002)(586003)(3846002)(6116002)(7736002)(66066001)(189998001)(305945005)(102836003)(93886004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0401MB1394; H:BN3PR0401MB1395.namprd04.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: docusign.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4DEE3BEE071E684F85058BB07736C6AF@namprd04.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: docusign.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 09:51:37.7622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 237e701c-327f-4cad-a5a1-dda2412d89d9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0401MB1394 Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" , Russ Housley Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 09:51:44 -0000 Qm9uam91ciBCcmlhbiwNCg0KPiBMZSAyMyBhb8O7dCAyMDE2IMOgIDIxOjQ1LCBCcmlhbiBTbWl0 aCA8YnJpYW5AYnJpYW5zbWl0aC5vcmc+IGEgw6ljcml0IDoNCj4gDQo+IFJ1c3MgSG91c2xleSA8 aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPj4+IEFzIGNvLWNoYWlyOiAgU28gcGVyaGFw cyB0aGUgcXVlc3Rpb24gYmVjb21lczogIGhvdyBpbXBvcnRhbnQgaXMgaXQgdGhhdCAianVtYm8i IENSTCdzIGNhbiBiZSBzaWduZWQgd2l0aCB0aGVzZSBuZXcgYWxnb3JpdGhtcz8NCj4+IA0KPj4g SWYgd2UgaG9wZSB0byBzZWUgYWRvcHRpb24gaW4gdGhlIFdlYiBQS0ksIHRoZW4gdGhlIGFuc3dl ciBpcyB5ZXMuDQo+IA0KPiBUaGUgV2ViIFBLSSBpbiBwcmFjdGljZSBoYXMgYWxyZWFkeSByZWpl Y3RlZCB0aGUgdXNlIG9mIENSTHMuIFdlDQo+IHNob3VsZG4ndCBtYWtlIHRoaW5ncyBtb3JlIGNv bXBsaWNhdGVkIHRvIHN1cHBvcnQgQ1JMcy4gV2Ugc2hvdWxkDQo+IGFzc3VtZSB0aGF0IGludGVy bmV0IHByb3RvY29scyBkb24ndCB1c2UgQ1JMcywgYW5kIGxldCB0aGUgdXNlcnMgb2YNCj4gQ1JM cyB3cml0ZSB0aGVpciBvd24gUkZDcyB0byBoYW5kbGUgdGhlaXIgc3BlY2lhbCBjYXNlcy4NCg0K SXMgdGhlIHNjb3BlIG9mIGRyYWZ0IFdlYlBLSSwgb3IgUEtJWD8NClBLSVggaXMgdXNlZCBmb3Ig dGhpbmdzIHRoYXQgYXJlbuKAmXQgbmVjZXNzYXJpbHkgd2ViIHJlbGF0ZWQsIHN1Y2ggYXMgUy9N SU1FLCBwYXNzcG9ydHMsIGNvbnRyYWN0cywgY29kZSwgLi4uDQoNCj4gSW4gcGFydGljdWxhciwg SSB0aGluayBpdCBpcyBwZXJmZWN0bHkgcmVhc29uYWJsZSBhbmQgZ29vZCB0byByZXF1aXJlDQo+ ICgiTVVTVCIpIHRoZSBub24tcHJlaGFzaCB2YXJpYW50IGJlIHVzZWQgZm9yIGNlcnRpZmljYXRl IGFuZCBPQ1NQDQo+IHJlc3BvbnNlIHNpZ25hdHVyZXMsIGFuZCBub3Qgc2F5IGFueXRoaW5nIGFi b3V0IENSTHMgYXQgYWxsLiBBbm90aGVyDQo+IGRyYWZ0IGNvdWxkIHRoZW4gc3BlY2lmeSBhIHdh eSB0byB1c2UgdGhlc2UgYWxnb3JpdGhtcyBmb3IgQ1JMcy4NCg0KVGhhdOKAmXMgcmVhc29uYWJs ZS4gQW5vdGhlciB3YXkgd291bGQgYmUgdG8gZGVmaW5lIHRob3NlIHNpZ25hdHVyZSBhbGdvcml0 aG1zLCBhbmQgbGV0IG90aGVycyBkZWNpZGUgaWYgaXTigJlzIHJlYXNvbmFibGUgdG8gdXNlIHRo ZW0gaW4gdGhlaXIgc2l0dWF0aW9uLg0KSnVzdCBsaWtlIGRlZmluaW5nIFJTQSB3aXRob3V0IGtl eSBzaXplIG9yIHBhZGRpbmcgbGltaXRhdGlvbnMsIGFuZCBsZXQgb3RoZXJzIGRlY2lkZSBpZiAx MDI0IGJpdHMgb3IgUlNBRVMtUEtDUzEgaXMgYWNjZXB0YWJsZSBvciBub3QsIG9yIGlmIFJTQVNT QS0qIHdpdGggTUQ0IGlzIHN1aXRhYmxlIGZvciBhIGNlcnRpZmljYXRlIGluIDIwMTYuIEluIHNv bWUgc2l0dWF0aW9ucyBpdOKAmXMgYW4gZWFzeSBkZWNpc2lvbiwgYnV0IG5vdCBhbHdheXMsIGFu ZCBjZXJ0YWlubHkgbm90IGJpbmFyeS4NCg0KPiBUaGUgaWRlYSBvZiAiUEtJWCIgd2FzIHRoYXQg Y2VydGlmaWNhdGVzIGFuZCBjZXJ0aWZpY2F0ZS1yZWxhdGVkIHN0dWZmDQo+IGxpa2UgT0NTUCwg Q1JMcywgQVNOLjEgZGVjb2RpbmcgYW5kIGVuY29kaW5nLCBldGMuIHdvdWxkIHdvcmsNCj4gdW5p Zm9ybWx5IGFjcm9zcyBTL01JTUUsIFRMUywgYW5kIHdoYXRldmVyIGVsc2UgdXNlcyBQS0lYIHN0 dWZmLiBUaGF0DQo+IGlkZWEgaGFzIGZhaWxlZC4NCg0KV2hhdCBoYXMgZmFpbGVkIGlzIGV4cGVj dGluZyBldmVyeSBvYmplY3QgKENSTCwgT0NTUCwgVFNULCDigKYpIHRvIGJlIGVxdWFsbHkgdXNl ZnVsIGluIGV2ZXJ5IHNpdHVhdGlvbiB3aGVyZSBhbiBYNTA5IGNlcnRpZmljYXRlIGNhbiBiZSB1 c2VkLCB3aXRob3V0IHRha2luZyB0aGUgY29udGV4dCBpbiBhY2NvdW50Lg0KDQo+IE5vdyB3ZSBo YXZlIHRvIGNvbnNpZGVyICJXZWIgUEtJIiBhbmQgInRoZSBvdGhlcg0KPiBzdHVmZiIgc2VwYXJh dGVseSB3aGVuZXZlciB3ZSBnZXQgaW50byB0aGVzZSBkZXRhaWxzLiBJbiB0aGUgV2ViIFBLSSwN Cj4gQ1JMcyBhcmUgZGVhZC4gKFNvbWVib2R5IHNob3VsZCB3cml0ZSBhbiBSRkMgdG8gdGhpcyBl ZmZlY3QuKQ0KDQoNCkFtZW4uDQoNCkNvcmRpYWxlbWVudCwNCkVyd2FubiBBYmFsZWENCg0K From nobody Wed Aug 24 04:31:58 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE8612D90C for ; Wed, 24 Aug 2016 04:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 3zeffn5hhfeK for ; Wed, 24 Aug 2016 04:31:54 -0700 (PDT) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 DD8F312D92F for ; Wed, 24 Aug 2016 04:31:53 -0700 (PDT) Received: (qmail 17300 invoked by uid 1004); 24 Aug 2016 11:31:51 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 24 Aug 2016 12:31:51 +0100 Received: (qmail 24539 invoked by uid 1000); 24 Aug 2016 11:31:51 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 24 Aug 2016 12:31:51 +0100 To: Brian Smith , Russ Housley References: <147160982300.24227.13672889471174044022.idtracker@ietfa.amsl.com> <20160819133828.oowlhynjcprkye5a@LK-Perkele-V2.elisa-laajakaista.fi> <097a01d1fa3b$06c6ee90$1454cbb0$@augustcellars.com> <44FB6332-B0F6-4E39-98E8-A96FAFAF6F5C@docusign.com> <015d01d1fca6$07ae7720$170b6560$@augustcellars.com> <04f301d1fd48$af15d010$0d417030$@gmail.com> From: Rob Stradling Message-ID: Date: Wed, 24 Aug 2016 12:31:50 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Salz, Rich" , "curdle@ietf.org" Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 11:31:57 -0000 On 23/08/16 20:45, Brian Smith wrote: > Russ Housley wrote: >>> As co-chair: So perhaps the question becomes: how important is it that "jumbo" CRL's can be signed with these new algorithms? >> >> If we hope to see adoption in the Web PKI, then the answer is yes. > > The Web PKI in practice has already rejected the use of CRLs. Most of the main browsers have moved away from checking CRLs, but I think most of the CAs are still producing them. (Let's Encrypt is the notable exception). Browsers aren't/weren't the only consumers of CRLs. CRLs are used behind the scenes: Russ already mentioned CRL-based OCSP responders; then there are the revocation aggregators such as Chrome's CRLSets. > We shouldn't make things more complicated to support CRLs. We should > assume that internet protocols don't use CRLs, and let the users of > CRLs write their own RFCs to handle their special cases. > > In particular, I think it is perfectly reasonable and good to require > ("MUST") the non-prehash variant be used for certificate and OCSP > response signatures, and not say anything about CRLs at all. Another > draft could then specify a way to use these algorithms for CRLs. > > The idea of "PKIX" was that certificates and certificate-related stuff > like OCSP, CRLs, ASN.1 decoding and encoding, etc. would work > uniformly across S/MIME, TLS, and whatever else uses PKIX stuff. That > idea has failed. Now we have to consider "Web PKI" and "the other > stuff" separately whenever we get into these details. In the Web PKI, > CRLs are dead. (Somebody should write an RFC to this effect.) > > Cheers, > Brian -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Aug 24 11:07:12 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF88412D667 for ; Wed, 24 Aug 2016 11:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 R2RgeXU4HYXH for ; Wed, 24 Aug 2016 11:07:08 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACFA912D618 for ; Wed, 24 Aug 2016 11:07:07 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id l2so22954316qkf.3 for ; Wed, 24 Aug 2016 11:07:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=GsYzbW3hswdlBCBLx/xG4E70ekjcGju775oJ7duzQ/s=; b=NcyPtUoJ5fEjiOtouo9yH7t3zaPlw9ChXAdxy7vJPW5RBJjs5eqUIQjEFfhKgpAL8A MpsR6rql2BD+A4gNTBGXX/rHnL9BlcmGrRtpKqsCH9E0nIBuPBkbwESqNmhl5u1f7K6R fdrGCPoLahDkHJr5r2qb7hNDFIWBebyP6Bnl03jdiTfV1PVC2NkqK78IBdk7SY4avvm7 xW4wjLzxVe6X+y/eQXxFl64gvGdADGFpgVu5B43QbvF3fo3PbhcrpFu9nbeqRqaAuGPV REW9/RvfUTzerkNnCOQKIQMv8DET4RaHs7o5GM9mcqmazIDNqGMdR3dJ8Z/yhEt8kBqB JHUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=GsYzbW3hswdlBCBLx/xG4E70ekjcGju775oJ7duzQ/s=; b=Pt+AxP94UVegcOpE6rWeJUQ4iOPRPcpycIUISzGPss7f3Dzs0H142MzZndeGDeW3f6 Ty3DSvHoBTVENLwEdgKfguX6M8kqZaKsSbEkYtc6ibX2ASbcVgrTKJxpYA9uh6M/8//E 8c0RSeUc1oHa7hGFbpQPBhtrp2xqu9T8S9Wvct/on0Ero+04CbreYmQA7UUWcS8B94d4 bH002MSrhS8RoOO9MUFKGJsATgFXETwe/VdE4aELcbY+eJnGydGyqE3M0mxzxA0jCH1B LWxgmG2NqDinY2wKTLKHQEujnLIkau2wXM6OGSQJ7UZUQT9qx5SzixxerTsgXPXfAgZh 1zuQ== X-Gm-Message-State: AE9vXwPMiItKQPTu21lDDUExkiRBnrV0/K+4yJ5UZrxnInfoaZN3jOA4p6tXQyKhXR9Zc1Csj5lt96/SnJLf7g== X-Received: by 10.55.99.195 with SMTP id x186mr5009370qkb.26.1472062026476; Wed, 24 Aug 2016 11:07:06 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.158.211 with HTTP; Wed, 24 Aug 2016 11:07:05 -0700 (PDT) From: Phillip Hallam-Baker Date: Wed, 24 Aug 2016 14:07:05 -0400 X-Google-Sender-Auth: LSCdVRhcJYNmGt3ALciuOs6zVUs Message-ID: To: Curdle Content-Type: multipart/alternative; boundary=001a114d38222d102e053ad5260e Archived-At: Subject: [Curdle] Server Fingerprints using UDF X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 18:07:10 -0000 --001a114d38222d102e053ad5260e Content-Type: text/plain; charset=UTF-8 One of the things I am trying to persuade groups writing crypto applications is that we should adopt a common format for fingerprints, Why? 1) Because having a standard approach is the right thing to do 2) Because a direct trust mechanism (i.e. a fingerprint) is useful in every crypto application * OpenPGP Key fingerprints * SSH server keys AND it would be nice to do public keys one day * Roots of trust for PKIX and S/MIME 3) Because simply taking SHA-2 of 'stuff' opens possibilities for semantic substitution attacks 4) Adopting a common format encourages innovation that can benefit all applications that share that format. 5) Adopting a single fingerprint format encourages the development of applications to manage them across applications - like the Mathematical Mesh which I am working on. We are not going to get to one true representation of keys. But I think we could get to a fingerprint format that every application can use without the risk of semantic substitution attacks. I am not too bothered about the possibility that someone generates an OpenPGP key and somehow persuades S/MIME to send a message using the same key. If I am being really strict, I can see it is not ideal. What does worry me however is that if Mallet gives Alice his key fingerprint for OpenPGP, she puts it in her 'trusted key ring' and it turns out that when the SSH app interprets the sequence of bits that were fingerprinted they have some different semantics. My current proposal is in: https://tools.ietf.org/html/draft-hallambaker-udf-03 This allows use SHA-2-512 and SHA-3-512 as the hash algorithms. The default presentation is as a text string encoded in BASE32 encoding with spacing every 5 characters to promote readability. So a SSH server fingerprint might look like: MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ One of the things I find rather difficult with SSH is that the key files for the applications I have seen in the wild do not comply with the spec, lines don't wrap at 72 characters. Rather worse, the files have the full public key in them which makes them a real pain to use when configuring files. I would really like to be able to configure my GitHub accounts without having to cut and paste lines with a thousand characters of text. It would be nice if the SSH config files could use fingerprints rather than the actual keys. --001a114d38222d102e053ad5260e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One= of the things I am trying to persuade groups writing crypto applications i= s that we should adopt a common format for fingerprints, Why?

1) Because having a standard approach = is the right thing to do

= 2) Because a direct trust mechanism (i.e. a fingerprint) is useful in every= crypto application

=C2= =A0 * OpenPGP Key fingerprints
=C2=A0 * SSH server keys AND it would be nice to do public = keys one day
= =C2=A0 * Roots of trust for PKIX and S/MIME

3) Because simply taking SHA-2 of 'stuff' open= s possibilities for semantic substitution attacks

4) Adopting a common format encourages innovation = that can benefit all applications that share that format.

5) Adopting a single fingerprint format = encourages the development of applications to manage them across applicatio= ns - like the Mathematical Mesh which I am working on.


We are not going to get to one true representation of = keys. But I think we could get to a fingerprint format that every applicati= on can use without the risk of semantic substitution attacks.

I am not too bothered about the possib= ility that someone generates an OpenPGP key and somehow persuades S/MIME to= send a message using the same key. If I am being really strict, I can see = it is not ideal.

What doe= s worry me however is that if Mallet gives Alice his key fingerprint for Op= enPGP, she puts it in her 'trusted key ring' and it turns out that = when the SSH app interprets the sequence of bits that were fingerprinted th= ey have some different semantics.


My current proposal is in:

https://tools.ietf.org= /html/draft-hallambaker-udf-03

This allows use = SHA-2-512 and SHA-3-512 as the hash algorithms. The default presentation is= as a text string encoded in BASE32 encoding with spacing every 5 character= s to promote readability.

=
So a SSH server fingerprint m= ight look like: =C2=A0= MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ


One of the things I find rather difficult w= ith SSH is that the key files for the applications I have seen in the wild = do not comply with the spec, lines don't wrap at 72 characters. Rather = worse, the files have the full public key in them which makes them a real p= ain to use when configuring files.

I would really like= to be able to configure my GitHub accounts without having to cut and paste= lines with a thousand characters of text. It would be nice if the SSH conf= ig files could use fingerprints rather than the actual keys.



--001a114d38222d102e053ad5260e-- From nobody Wed Aug 24 20:33:15 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034E212D600 for ; Wed, 24 Aug 2016 20:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 SihGbwPQ2YWA for ; Wed, 24 Aug 2016 20:33:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DA9712D5C5 for ; Wed, 24 Aug 2016 20:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1472095992; x=1503631992; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zRA0gwm42Y6CaOErchfAKblGXaQBeKKu23VK1mJtGzM=; b=mgRHPMz8/R1QKCVjsWiQG06A3peeWcBQnpeY24glL3T0m1lsG0kxIIyM l9gwIPmZkxv4OhiM8QkUGSZskUJlFOzs6zbVc93dlh1C7ZmXy+P4xxsif Q9RgnxMIbJFQ9hqsH/2fVppOvJ6Bp2AReo2RxqL4XdvLOx4HxZjc3EvBS Jv4Gl0AnMZXOYwmSf6mNm3T8UJaDi8qYo/pDcM8mMh18t8wqisi9TAHEX y3CCvs41Smzcki5Hh0yQHrBodTcWIoLkpWzLnVxl1DZdGjW0AGp8SfVQ3 Nn3e9bATd7jzycCaOJRN1FpC+RuQqghnn6xCqtmiKDIKnmUrPzeGR9e1A Q==; X-IronPort-AV: E=Sophos;i="5.28,573,1464609600"; d="scan'208";a="103440980" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Aug 2016 15:33:10 +1200 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.93]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Thu, 25 Aug 2016 15:33:10 +1200 From: Peter Gutmann To: Phillip Hallam-Baker , Curdle Thread-Topic: [Curdle] Server Fingerprints using UDF Thread-Index: AQHR/jJaDGM6WKBIJk+J5thINTfR06BZBkQA Date: Thu, 25 Aug 2016 03:33:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4D01FAE@uxcn10-5.UoA.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Server Fingerprints using UDF X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 03:33:14 -0000 Phillip Hallam-Baker writes:=0A= =0A= >1) Because having a standard approach is the right thing to do=0A= >=0A= >2) Because a direct trust mechanism (i.e. a fingerprint) is useful in ever= y crypto application=0A= >=0A= > * OpenPGP Key fingerprints=0A= > * SSH server keys AND it would be nice to do public keys one day=0A= > * Roots of trust for PKIX and S/MIME=0A= =0A= ObXKCD: https://xkcd.com/927/=0A= =0A= >This allows use SHA-2-512 and SHA-3-512 as the hash algorithms.=0A= =0A= Oh not another SHA-as-big-as-we-can-get. We know from various (public-IP) = =0A= Internet scans that the universal standard on the net is SHA-256, and =0A= anything else, in particular the huge SHA-2 variants, are the GPS signal=0A= of the Internet, their use is so far below the noise floor that you need=0A= specialised signal processing just to see they're there. Just stick with= =0A= SHA-256, which pretty much everything does, rather than going to oddball=0A= exotic algorithms that need special-case support.=0A= =0A= Peter.=0A= From nobody Thu Aug 25 13:01:58 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573A012D0AD for ; Thu, 25 Aug 2016 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ooV-NXScUBGP for ; Thu, 25 Aug 2016 13:01:48 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27F912D5CF for ; Thu, 25 Aug 2016 13:01:47 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id z190so56931528qkc.0 for ; Thu, 25 Aug 2016 13:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0nHNKe0x1L2dk+z7/7os74dCfMN682IApXQUeyZIUGs=; b=B4i1gFA9qWU8WbRn0SQu7uo4xm2LXQtp/aVOAHHSFURalB1AGXJ6TNcpIjH1DWqQRI 6a06CC0/uyGTvF6TLswsHqpI157ZxxB7cZP2Jm559MdcMoX9Xu87kmRfvp2+Z816ToL4 pH0ynjUM07HBhWJM6Ki8jL8MQ1DtW/I1oZJIGCvtNwYjYK7e5fxjjNBhqboDi8ixDYT8 mnRS9jmnmQ17VCHzlpOuHbfWMfomTCW0cbkoCDDLovI31s/Sg8MRZ7m27B307U6DpdZ9 J4W8Gp3yy8UlKmYAu/xZxd0KgprarwYu7TLGRGhz6gFzzuS5LmLBZWcTyMEcse1uu3FR MEmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0nHNKe0x1L2dk+z7/7os74dCfMN682IApXQUeyZIUGs=; b=jhARMzuF+gqdkXYuMr6loR6cq3cdIw4XzUbCZIK8vL1fOoS0MQoqfxEpi78eiskZ+j 7OErOAIcQBEid+i4PqhOXlZYAK0iYLHsxjVo2seN+BzewBAM3oXEKm4F2iNU6w6jtOsW VBYPGb1MRENCvOY3+Gn+Wc+zcRhdVK/ha6Az1bMX8d/rJbkEE/y3JdVtMV3Fxor8wgKq AV1HwdOQufaL1aSoFWCCO4k4J9BH2S/NeCkmF6Da687j3WnvgusrBhPlNU1eRgO0dRav ssTWoT4Uhm8gauXejffbqJFLZhfIt8mglq7iyYmoZo4bIgAQ2Gos9gAe5XYO8afH2pSL RjZw== X-Gm-Message-State: AE9vXwN9iEpPGpdMPax8R4hh4gDscdyDgnDxeWG9wx2inofABcSgdzaHhxxArT4VarEvpVoth6UOY45MNdUhRg== X-Received: by 10.55.186.65 with SMTP id k62mr12677715qkf.204.1472155306956; Thu, 25 Aug 2016 13:01:46 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.55.158.211 with HTTP; Thu, 25 Aug 2016 13:01:46 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4D01FAE@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4D01FAE@uxcn10-5.UoA.auckland.ac.nz> From: Phillip Hallam-Baker Date: Thu, 25 Aug 2016 16:01:46 -0400 X-Google-Sender-Auth: D2uRUjdz_phrKMax54_R0qFoZMI Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=94eb2c0441ce204de1053aeade48 Archived-At: Cc: Curdle Subject: Re: [Curdle] Server Fingerprints using UDF X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 20:01:56 -0000 --94eb2c0441ce204de1053aeade48 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2016 at 11:33 PM, Peter Gutmann wrote: > Phillip Hallam-Baker writes: > > >1) Because having a standard approach is the right thing to do > > > >2) Because a direct trust mechanism (i.e. a fingerprint) is useful in > every crypto application > > > > * OpenPGP Key fingerprints > > * SSH server keys AND it would be nice to do public keys one day > > * Roots of trust for PKIX and S/MIME > > ObXKCD: https://xkcd.com/927/ > > >This allows use SHA-2-512 and SHA-3-512 as the hash algorithms. > > Oh not another SHA-as-big-as-we-can-get. We know from various (public-IP= ) > Internet scans that the universal standard on the net is SHA-256, and > anything else, in particular the huge SHA-2 variants, are the GPS signal > of the Internet, their use is so far below the noise floor that you need > specialised signal processing just to see they're there. Just stick with > SHA-256, which pretty much everything does, rather than going to oddball > exotic algorithms that need special-case support. > =E2=80=8BIt is for compatibility with this: https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-07 My approach is that I do not believe in giving the user unnecessary options. In particular won't give a lower security option unless there is a compelling performance reason. =E2=80=8B So I use SHA-2-512 and truncate to however many bits as are needed. Since people want to use OpenPGP with ed448 curves for a 2^256 work factor, there needs to be a fingerprint option with equivalent strength. The code is going to need SHA-2-512 anyway. Just standardize on the higher level. --94eb2c0441ce204de1053aeade48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Au= g 24, 2016 at 11:33 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
<= span class=3D"">Phillip Hallam-Baker <phill@hallambaker.com> writes:

>1) Because having a standard approach is the right thing to do
>
>2) Because a direct trust mechanism (i.e. a fingerprint) is useful in e= very crypto application
>
> * OpenPGP Key fingerprints
> * SSH server keys AND it would be nice to do public keys one day
> * Roots of trust for PKIX and S/MIME

ObXKCD: https://xkcd.com/927/

>This allows use SHA-2-512 and SHA-3-512 as the hash algorithms.

Oh not another SHA-as-big-as-we-can-get.=C2=A0 We know from various = (public-IP)
Internet scans that the universal standard on the net is SHA-256, and
anything else, in particular the huge SHA-2 variants, are the GPS signal of the Internet, their use is so far below the noise floor that you need specialised signal processing just to see they're there.=C2=A0 Just sti= ck with
SHA-256, which pretty much everything does, rather than going to oddball exotic algorithms that need special-case support.

=
=E2=80=8B= It is for compatibility with this:
https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-07

My approach is that I do not b= elieve in giving the user unnecessary options. In particular won't give= a lower security option unless there is a compelling performance reason. = =E2=80=8B
<= br>
So I use SH= A-2-512 and truncate to however many bits as are needed.

Since people want to use OpenPGP with ed448= curves for a 2^256 work factor, there needs to be a fingerprint option wit= h equivalent strength.

Th= e code is going to need SHA-2-512 anyway. Just standardize on the higher le= vel.

=
=C2=A0
--94eb2c0441ce204de1053aeade48-- From nobody Mon Aug 29 15:01:53 2016 Return-Path: X-Original-To: curdle@ietfa.amsl.com Delivered-To: curdle@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6860612D8B0 for ; Mon, 29 Aug 2016 15:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 VTcw-75WmwDJ for ; Mon, 29 Aug 2016 15:01:49 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id A79D112D8A9 for ; Mon, 29 Aug 2016 15:01:47 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1487420003F for ; Mon, 29 Aug 2016 22:01:47 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id F2D52200012 for ; Mon, 29 Aug 2016 22:01:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1472508106; bh=k8PhoA6SDhwVWW9ZrZBmKBCAC2PeiMrOLaoz5MDkoLY=; l=6754; h=From:To:Date:References:In-Reply-To:From; b=abePaVpQFGN3dPkPLO1TzO6ie16+iMiSNe7NFz3t2sqOy4VsUkqhMbKZ/zKnK7Psq 6puuhCk4eaklItUF9mXzlNEbKYSrE6PNEgGCcVo5ot/1ANqSOYMjST8viAUefDTMA/ bl6pa8xoinh1HcpprRgkvdO96pNkSS+4dZ00M8EQ= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id CB7F21E084 for ; Mon, 29 Aug 2016 22:01:46 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 29 Aug 2016 18:01:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 29 Aug 2016 18:01:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 29 Aug 2016 18:01:46 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: NomCom 2016-2017: Call for Nominations Thread-Index: AQHSAjdGOQj0vA/u3E+/OXAGJuFa8aBgfVow Date: Mon, 29 Aug 2016 22:01:45 +0000 Message-ID: <3dfeef166a994f2fba6d85ac886ba427@usma1ex-dag1mb1.msg.corp.akamai.com> References: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> In-Reply-To: <147250302871.19142.11825877398134368393.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [Curdle] FW: NomCom 2016-2017: Call for Nominations X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "List for discussion of potential new security area wg." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 22:01:51 -0000 SW4gcGFydGljdWxhciwgU3RlcGhlbiBpc24ndCByZS11cHBpbmcsIHNvIHRoZXJlJ3MgYW4gb3Bl bmluZyBpbiB0aGUgU2VjdXJpdHkgQXJlYS4NCg0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWth bWFpIFRlY2hub2xvZ2llcw0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fs eg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOb21Db20gQ2hhaXIgMjAx NiBbbWFpbHRvOm5vbWNvbS1jaGFpci0yMDE2QGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgQXVn dXN0IDI5LCAyMDE2IDQ6MzcgUE0NClRvOiBXb3JraW5nIEdyb3VwIENoYWlycw0KU3ViamVjdDog Tm9tQ29tIDIwMTYtMjAxNzogQ2FsbCBmb3IgTm9taW5hdGlvbnMNCg0KUGxlYXNlIGZvcndhcmQg b24gdG8geW91ciBXb3JraW5nIEdyb3VwcyAtIA0KDQpUaGUgMjAxNi0xNyBOb21pbmF0aW5nIENv bW1pdHRlZSAoTm9tY29tKSBpcyBzZWVraW5nIG5vbWluYXRpb25zIGZyb20gbm93IHVudGlsIE9j dG9iZXIgOCwgMjAxNi4gVGhlIG9wZW4gcG9zaXRpb25zIGJlaW5nIGNvbnNpZGVyZWQgYnkgdGhp cyB5ZWFyJ3MgTm9tY29tIGNhbiBiZSBmb3VuZCBhdCB0aGUgZW5kIG9mIHRoaXMgZW1haWwgYW5k IGFsc28gb24gdGhpcyB5ZWFyJ3MgTm9tY29tIHdlYnNpdGU6DQoNCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTYvDQoNCk5vbWluYXRpb25zIG1heSBiZSBtYWRlIGJ5IHNl bGVjdGluZyB0aGUgTm9taW5hdGUgbGluayBhdCB0aGUgdG9wIG9mIHRoZSBOb21jb20gMjAxNiBo b21lIHBhZ2UsIG9yIGJ5IHZpc2l0aW5nIHRoZSBmb2xsb3dpbmcgVVJMOg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL25vbWNvbS8yMDE2L25vbWluYXRlLw0KDQogIHtOb3RlIHRoYXQg bm9taW5hdGlvbnMgbWFkZSB1c2luZyB0aGUgd2ViIHRvb2wgcmVxdWlyZSBhbiBpZXRmLm9yZw0K ICAgZGF0YXRyYWNrZXIgYWNjb3VudC4gWW91IGNhbiBjcmVhdGUgYSBkYXRhdHJhY2tlciBpZXRm Lm9yZyBhY2NvdW50DQogICBpZiB5b3UgZG9uJ3QgaGF2ZSBvbmUgYWxyZWFkeSBieSB2aXNpdGlu ZyB0aGUgZm9sbG93aW5nIFVSTDoNCiAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvYWNj b3VudHMvY3JlYXRlLyB9DQoNCklmIHlvdSBhcmUgdW5hYmxlIHRvIHVzZSB0aGUgd2ViIGZvcm0s IG5vbWluYXRpb25zIG1heSBpbnN0ZWFkIGJlIG1hZGUgYnkgZW1haWwgdG8gbm9tY29tLTE2QGll dGYub3JnLiBJZiB1c2luZyBlbWFpbCwgcGxlYXNlIGluY2x1ZGUgdGhlIHdvcmQgIk5vbWluYXRl IiBpbiB0aGUgU3ViamVjdCBhbmQgaW5kaWNhdGUgaW4gdGhlIGVtYWlsIHdobyBpcyBiZWluZyBu b21pbmF0ZWQsIHRoZWlyIGVtYWlsIGFkZHJlc3MgKHRvIGNvbmZpcm0gYWNjZXB0YW5jZSBvZiB0 aGUgbm9taW5hdGlvbiksIGFuZCB0aGUgcG9zaXRpb24gZm9yIHdoaWNoIHlvdSBhcmUgbWFraW5n IHRoZSBub21pbmF0aW9uLg0KSWYgeW91IGFyZSBub21pbmF0aW5nIHNvbWVvbmUgb3RoZXIgdGhh biB5b3Vyc2VsZiwgcGxlYXNlIHRlbGwgdXMgaWYgd2UgbWF5IHRlbGwgdGhlIG5vbWluZWUgdGhh dCB5b3Ugd2VyZSB0aGUgb25lIHdobyBtYWRlIHRoZSBub21pbmF0aW9uLg0KSWYgeW91IHdpc2gg dG8gbm9taW5hdGUgc29tZW9uZSB2aWEgZW1haWwgZm9yIG1vcmUgdGhhbiBvbmUgcG9zaXRpb24s IHBsZWFzZSB1c2Ugc2VwYXJhdGUgZW1haWxzIHRvIGRvIHNvLg0KDQpTZWxmLW5vbWluYXRpb24g aXMgd2VsY29tZSENCg0KV2lsbGluZyBub21pbmVlcyB3aWxsIGJlIGFza2VkIHRvIGZpbGwgb3V0 IGEgcXVlc3Rpb25uYWlyZSBzcGVjaWZpYyB0byB0aGUgcG9zaXRpb24gZm9yIHdoaWNoIHRoZXkg YXJlIG5vbWluYXRlZC4gIFRoZSBxdWVzdGlvbm5haXJlcyB3aWxsIGJlIGF2YWlsYWJsZSBvbiBT ZXB0ZW1iZXIgMiwgMjAxNiBhbmQgaGF2ZSBhIHN1Ym1pc3Npb24gZGVhZGxpbmUgb2YgT2N0b2Jl ciAxMywgMjAxNi4NCg0KTm9tQ29tIDIwMTYtMTcgd2lsbCBmb2xsb3cgdGhlIHBvbGljeSBmb3Ig Ik9wZW4gRGlzY2xvc3VyZSBvZiBXaWxsaW5nIE5vbWluZWVzIiBkZXNjcmliZWQgaW4gQkNQIDEw L1JGQyA3NDM3LiAgQXMgc3RhdGVkIGluIFJGQyA3NDM3OiAiVGhlIGxpc3Qgb2Ygbm9taW5lZXMg d2lsbGluZyB0byBiZSBjb25zaWRlcmVkIGZvciBwb3NpdGlvbnMgdW5kZXIgcmV2aWV3IGluIHRo ZSBjdXJyZW50IE5vbWNvbSBjeWNsZSBpcyBub3QgY29uZmlkZW50aWFsIi4gV2lsbGluZyBub21p bmVlcyBmb3IgZWFjaCBwb3NpdGlvbiB3aWxsIGJlIGxpc3RlZCBpbiBhIHB1YmxpY2x5IGFjY2Vz c2libGUgd2F5IC0gYW55b25lIHdpdGggYSBkYXRhdHJhY2tlciBhY2NvdW50IG1heSBhY2Nlc3Mg dGhlIGxpc3RzLiAgQWRkaXRpb25hbGx5LCB0aGUgbm9taW5hdGlvbiBmb3JtIGFza3MgaWYgd2Ug bWF5IHNoYXJlIHlvdXIgb3duIG5hbWUgd2l0aCB0aGUgbm9taW5lZS4gSW4gYWxsIG90aGVyIHdh eXMsIHRoZSBjb25maWRlbnRpYWxpdHkgcmVxdWlyZW1lbnRzIG9mIEJDUDEwIHJlbWFpbiBpbiBl ZmZlY3QuICBBbGwgZmVlZGJhY2sgYW5kIGFsbCBOb21jb20gZGVsaWJlcmF0aW9ucyB3aWxsIHJl bWFpbiBjb25maWRlbnRpYWwgYW5kIHdpbGwgbm90IGJlIGRpc2Nsb3NlZC4NCg0KVGhlcmUgaXMg YSBmaWVsZCBvbiB0aGUgZm9ybSB5b3UgY2FuIG1hcmsgaW4gb3JkZXIgdG8gYWxsb3cgdGhlIE5v bWNvbSB0byB0ZWxsIHRoZSBub21pbmVlIHRoYXQgeW91IHdlcmUgdGhlIG9uZSB3aG8gbWFkZSB0 aGUgbm9taW5hdGlvbi4gVGhpcyBkZWZhdWx0cyB0byDigJxub+KAnSAtIHNvIGlmIHlvdSBkb24n dCBtYXJrIHRoZSBmaWVsZCB3ZSB3b27igJl0IHRlbGwuDQoNCkluIG9yZGVyIHRvIGVuc3VyZSB0 aW1lIHRvIGNvbGxlY3Qgc3VmZmljaWVudCBjb21tdW5pdHkgZmVlZGJhY2sgYWJvdXQgZWFjaCBv ZiB0aGUgd2lsbGluZyBub21pbmVlcywgbm9taW5hdGlvbnMgbXVzdCBiZSByZWNlaXZlZCBieSB0 aGUgTm9tQ29tIG9uIG9yIGJlZm9yZSBPY3RvYmVyIDgsIDIwMTYuDQoNClBsZWFzZSBzdWJtaXQg eW91ciBub21pbmF0aW9ucyBhcyBlYXJseSBhcyBwb3NzaWJsZSBmb3IgdGhlIHNha2Ugb2YgeW91 ciBub21pbmVlcy4gTm90ZSB0aGF0IG5vbWluYXRpb25zIHNob3VsZCBub3Qgd2FpdCBmb3IgbWFu YWdlbWVudCBwZXJtaXNzaW9uLCBhcyBpdCBpcyBlYXNpZXIgdG8gZGVjbGluZSB0aGUgbm9taW5h dGlvbiB0aGFuIHB1dCBvbmUgaW4gbGF0ZS4NCg0KVGhlIE5vbWNvbSBhcHBvaW50cyBpbmRpdmlk dWFscyB0byBmaWxsIHRoZSBvcGVuIHNsb3RzIG9uIHRoZSBJQU9DLCB0aGUgSUFCLCBhbmQgdGhl IElFU0cuIFRoZSBsaXN0IG9mIHBlb3BsZSBhbmQgcG9zdHMgd2hvc2UgdGVybXMgZW5kIHdpdGgg dGhlIE1hcmNoIDIwMTcgSUVURiBtZWV0aW5nLCBhbmQgdGh1cyB0aGUgcG9zaXRpb25zIGZvciB3 aGljaCB0aGlzIE5vbWNvbSBpcyByZXNwb25zaWJsZSwgZm9sbG93czoNCg0KSUFPQw0KDQogICAg TG91IEJlcmdlcg0KDQpJQUINCg0KICAgIFJhbHBoIERyb21zKg0KICAgIFJ1c3MgSG91c2xleSoN CiAgICBSb2JlcnQgU3BhcmtzDQogICAgQW5kcmV3IFN1bGxpdmFuDQogICAgRGF2ZSBUaGFsZXIq DQogICAgU3V6YW5uZSBXb29sZg0KDQpJRVNHDQoNCiAgICBKYXJpIEFya2tvIChHRU4pKg0KICAg IERlYm9yYWggQnJ1bmdhcmQgKFJURykNCiAgICBCZW4gQ2FtcGJlbGwgKEFSVCkNCiAgICBTcGVu Y2VyIERhd2tpbnMgKFRTVikNCiAgICBTdGVwaGVuIEZhcnJlbGwgKFNFQykqDQogICAgSm9lbCBK YWVnZ2xpIChPUFMpKg0KICAgIFRlcnJ5IE1hbmRlcnNvbiAoSU5UKQ0KICAgIEFsdmFybyBSZXRh bmEgKFJURykNCg0KKi0gaGF2ZSBpbmRpY2F0ZWQgdGhhdCB0aGV5IGRvIG5vdCBpbnRlbmQgdG8g YWNjZXB0IGEgcmVub21pbmF0aW9uLiBUaGlzIGluZm9ybWF0aW9uIGlzIGFsd2F5cyB1cCB0byBk YXRlIG9uIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbm9tY29tLzIwMTYvDQoNClBsZWFz ZSBiZSByZXNvdXJjZWZ1bCBpbiBpZGVudGlmeWluZyBwb3NzaWJsZSBjYW5kaWRhdGVzIGZvciB0 aGVzZSBwb3NpdGlvbnMsIGFzIGRldmVsb3Bpbmcgb3VyIHRhbGVudCBpcyBhIHZlcnkgY3J1Y2lh bCByZXF1aXJlbWVudCBmb3IgdGhlIElFVEYsIGFuZCBhbHNvLCBwbGVhc2UgY29uc2lkZXIgYWNj ZXB0aW5nIGEgbm9taW5hdGlvbi4gIFlvdSdsbCBmaW5kIGV4dGVuc2l2ZSBpbmZvcm1hdGlvbiBh Ym91dCBzcGVjaWZpYyBwb3NpdGlvbnMsIGRldmVsb3BlZCBieSB0aGUgSUFCLCBJRVNHLCBhbmQg SUFPQywgdW5kZXIgaW5kaXZpZHVhbCB0YWJzIGF0Og0KDQogIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvbm9tY29tLzIwMTYvcmVxdWlyZW1lbnRzLw0KDQpJbiBhZGRpdGlvbiB0byBub21p bmF0aW9ucywgdGhlIE5vbWNvbSBzZWVrcyBjb21tdW5pdHkgaW5wdXQgb24gdGhlIHBvc2l0aW9u cyB0aGVtc2VsdmVzLiAgV2UgbmVlZCBhbmQgd2VsY29tZSB0aGUgY29tbXVuaXR5J3Mgdmlld3Mg YW5kIGlucHV0IG9uIHRoZSBqb2JzIHdpdGhpbiBlYWNoIG9yZ2FuaXphdGlvbi4gSWYgeW91IGhh dmUgaWRlYXMgb24gdGhlIHBvc2l0aW9ucycgcmVzcG9uc2liaWxpdGllcyAobW9yZSwgbGVzcywg ZGlmZmVyZW50KSwgcGxlYXNlIGxldCB1cyBrbm93Lg0KDQpQbGVhc2Ugc2VuZCBzdWdnZXN0aW9u cyBhbmQgZmVlZGJhY2sgYWJvdXQgdGhpcyB0byBub21jb20tMTZAaWV0Zi5vcmcuDQoNClRoYW5r IHlvdSBmb3IgeW91ciBoZWxwIGluIGlkZW50aWZ5aW5nIHF1YWxpZmllZCBub21pbmVlcyENCg0K THVjeSBMeW5jaA0KTm9tY29tIENoYWlyIDIwMTYtMTcNCm5vbWNvbS1jaGFpci0yMDE2QGlldGYu b3JnDQpsbHluY2hAY2l2aWwtdG9uZ3VlLm5ldA0KDQo=