From nobody Tue Aug 1 01:14:31 2017 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 354ED132B77; Tue, 1 Aug 2017 01:14:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150157527017.9674.1160290643287981430@ietfa.amsl.com> Date: Tue, 01 Aug 2017 01:14:30 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rc4-die-die-die-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 01 Aug 2017 08:14:30 -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 WG of the IETF. Title : Deprecating RC4 in all IETF Protocols Author : Luis Camara Filename : draft-ietf-curdle-rc4-die-die-die-01.txt Pages : 8 Date : 2017-08-01 Abstract: RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx and it needs to be prohibited in all IETF protocols. This document obsoletes RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol" (note Arcfour and RC4 are synonymous). RFC 3501, RFC 4253, RFC 6649 and RFC 6733 are updated to note the deprecation of RC4 in all IETF protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rc4-die-die-die-01 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rc4-die-die-die-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rc4-die-die-die-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 Tue Aug 1 13:17:39 2017 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 4070C132031 for ; Tue, 1 Aug 2017 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CFffgJuTZ4mh for ; Tue, 1 Aug 2017 13:17:36 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37161131FE8 for ; Tue, 1 Aug 2017 13:17:36 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v71KGmkg012950 for ; Tue, 1 Aug 2017 21:17:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=JLGYZZPqouhUZAWo9LMULjyT4NszLU2oCSijv41vh1o=; b=SYDBaQQNuodAjMJUBC0V17K59jB6i9Yn9g7Gij/eqzv4H1n9nVph1ldAR4VjTKE3dsqI KZnOxslkdjlWBg/ikHrZZ6F4YRLlx++AAvaphTf+9w7H9y33S+e8kpmrwEyw1bs0/3pc s+tPKHj18OtmYiQy2sJcReCeGHgSlQUt5FwCwpo9jtzyJfg38oQJGJxxQZ5JL7u+g4Yv dcPL3QFjC1bqxLLsegt+i81kBaO9ULo6QlkNTr2wJheXVgrIGNP4xugkaZquB2wsKx4q nyinMn/IyIoi0kpDdKGVHQRRr5b/F+QOg9LIwGTZOWAOpUmXQt4wWNYPFaGdeUuhcl0l +Q== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2c0hmqh7py-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 01 Aug 2017 21:17:33 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v71KGEcP003331 for ; Tue, 1 Aug 2017 16:17:32 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c0npum2t0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 01 Aug 2017 16:17:32 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 16:17:31 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Tue, 1 Aug 2017 16:17:31 -0400 From: "Short, Todd" To: "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-rc4-die-die-die-01.txt Thread-Index: AQHTCp42HDxfm52xoUS6w57DJxaKeaJwNDgA Date: Tue, 1 Aug 2017 20:17:31 +0000 Message-ID: References: <150157527017.9674.1160290643287981430@ietfa.amsl.com> In-Reply-To: <150157527017.9674.1160290643287981430@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.219] Content-Type: multipart/alternative; boundary="_000_DAF193C1A6BD4BA5B026B4C5AAF3CEBEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-01_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708010329 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-01_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708010329 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-rc4-die-die-die-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 01 Aug 2017 20:17:38 -0000 --_000_DAF193C1A6BD4BA5B026B4C5AAF3CEBEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBmZXcgY29tbWVudHMgb24gdGhpcyBJLUQ6DQoNClNlY3Rpb24gMy4gVXBkYXRlcyB0byBSRkMz NTAxLCB0aGlzIHNob3VsZCByZWZlcmVuY2UgUkZDNzUyNS9CQ1AxOTUgd2l0aCByZXNwZWN0IHRv IFRMUyB1c2FnZSwgcmF0aGVyIHRoYW4gZXhwbGljaXRseSBzdGF0aW5nIFRMU3YxLjIgYW5kIG9u ZSBzcGVjaWZpYyBjaXBoZXIgc3VpdGUgKHRoYXQgZG9lc27igJl0IGV2ZW4gdXNlIEVDQykuDQoN CkFjdHVhbGx5LCBsb29raW5nIGF0IHRoaXMgYXMgYSB3aG9sZSwgd2l0aCByZXNwZWN0IHRvIFRM UyB1c2FnZSwgdGhlIElEIHNob3VsZCByZWZlcmVuY2UgUkZDNzUyNS9CQ1AxOTUgaW5zdGVhZCBv ZiBjb21pbmcgdXAgd2l0aCBhIG5ldyBzZXQgb2YgcnVsZXMuDQoNClNlY3Rpb24gNyBzcGVjaWZp Y2FsbHkgc2luZ2xlcyBvdXQgTWljcm9zb2Z0OyB3aGlsZSBvbGRlciBNaWNyb3NvZnQgb3BlcmF0 aW5nIHN5c3RlbXMgYXJlIGEgYmFuZSB0byB0aGUgY3VycmVudCBzZWN1cml0eSBsYW5kc2NhcGUs IElNSE8gQUxMIHZlbmRvcnMgU0hPVUxEIHRha2UgYWN0aW9uIHRvIGVyYWRpY2F0ZSBSQzQgaW4g YWxsIGl0cyBzb2Z0d2FyZSBhbmQgc3lzdGVtcy4NCi0tDQotVG9kZCBTaG9ydA0KLy8gdHNob3J0 QGFrYW1haS5jb208bWFpbHRvOnRzaG9ydEBha2FtYWkuY29tPg0KLy8gIk9uZSBpZiBieSBsYW5k LCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuIg0KDQpPbiBBdWcgMSwg MjAxNywgYXQgNDoxNCBBTSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRo aXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENVUnZlcywgRGVwcmVjYXRpbmcgYW5kIGEg TGl0dGxlIG1vcmUgRW5jcnlwdGlvbiBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgIFRpdGxlICAg ICAgICAgICA6IERlcHJlY2F0aW5nIFJDNCBpbiBhbGwgSUVURiBQcm90b2NvbHMNCiAgICAgICBB dXRob3IgICAgICAgICAgOiBMdWlzIENhbWFyYQ0KRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1jdXJkbGUtcmM0LWRpZS1kaWUtZGllLTAxLnR4dA0KUGFnZXMgICAgICAgICAgIDogOA0KRGF0 ZSAgICAgICAgICAgIDogMjAxNy0wOC0wMQ0KDQpBYnN0cmFjdDoNCiAgUkM0IGlzIGV4dHJlbWVs eSB3ZWFrIGFzIHNob3duIGJ5IFJGQyA2NjQ5IGFuZCBSRkMgNzQ1NywgaXMNCiAgcHJvaGliaXRl ZCBpbiBUTFMgYnkgUkZDIDc0NjUsIGlzIHByb2hpYml0ZWQgaW4gS2VyYmVyb3MgYnkgUkZDIHh4 eHgNCiAgYW5kIGl0IG5lZWRzIHRvIGJlIHByb2hpYml0ZWQgaW4gYWxsIElFVEYgcHJvdG9jb2xz LiBUaGlzIGRvY3VtZW50DQogIG9ic29sZXRlcyBSRkMgNDM0NSAiSW1wcm92ZWQgQXJjZm91ciBN b2RlcyBmb3IgdGhlIFNlY3VyZSBTaGVsbCAoU1NIKQ0KICBUcmFuc3BvcnQgTGF5ZXIgUHJvdG9j b2wiIChub3RlIEFyY2ZvdXIgYW5kIFJDNCBhcmUgc3lub255bW91cykuDQogIFJGQyAzNTAxLCBS RkMgNDI1MywgUkZDIDY2NDkgYW5kIFJGQyA2NzMzIGFyZSB1cGRhdGVkIHRvIG5vdGUgdGhlDQog IGRlcHJlY2F0aW9uIG9mIFJDNCBpbiBhbGwgSUVURiBwcm90b2NvbHMuDQoNCg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUvDQoN ClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUtMDEN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1jdXJkbGUt cmM0LWRpZS1kaWUtZGllLTAxDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlz IGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUtMDENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ3VyZGxlIG1haWxp bmcgbGlzdA0KQ3VyZGxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2N1cmRsZQ0KDQo= --_000_DAF193C1A6BD4BA5B026B4C5AAF3CEBEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4ED84FD4D95F3048BE1E8A76E2B81111@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSSBmZXcgY29tbWVudHMgb24gdGhp cyBJLUQ6DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5TZWN0aW9uIDMuIFVwZGF0ZXMgdG8gUkZDMzUwMSwgdGhpcyBzaG91bGQgcmVmZXJlbmNlIFJG Qzc1MjUvQkNQMTk1IHdpdGggcmVzcGVjdCB0byBUTFMgdXNhZ2UsIHJhdGhlciB0aGFuIGV4cGxp Y2l0bHkgc3RhdGluZyBUTFN2MS4yIGFuZCBvbmUgc3BlY2lmaWMgY2lwaGVyIHN1aXRlICh0aGF0 IGRvZXNu4oCZdCBldmVuIHVzZSBFQ0MpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWN0dWFsbHksIGxvb2tpbmcgYXQgdGhpcyBhcyBh IHdob2xlLCB3aXRoIHJlc3BlY3QgdG8gVExTIHVzYWdlLCB0aGUgSUQgc2hvdWxkIHJlZmVyZW5j ZSBSRkM3NTI1L0JDUDE5NSBpbnN0ZWFkIG9mIGNvbWluZyB1cCB3aXRoIGEgbmV3IHNldCBvZiBy dWxlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPlNlY3Rpb24gNyBzcGVjaWZpY2FsbHkgc2luZ2xlcyBvdXQgTWljcm9zb2Z0OyB3aGls ZSBvbGRlciBNaWNyb3NvZnQgb3BlcmF0aW5nIHN5c3RlbXMgYXJlIGEgYmFuZSB0byB0aGUgY3Vy cmVudCBzZWN1cml0eSBsYW5kc2NhcGUsIElNSE8gQUxMIHZlbmRvcnMgU0hPVUxEIHRha2UgYWN0 aW9uIHRvIGVyYWRpY2F0ZSBSQzQgaW4gYWxsIGl0cyBzb2Z0d2FyZSBhbmQgc3lzdGVtcy48YnIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LS08L2Rpdj4N CjxkaXYgY2xhc3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gPGEgaHJl Zj0ibWFpbHRvOnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0iIj50c2hvcnRAYWthbWFpLmNvbTwv YT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxhbmQsIHR3byBpZiBi eSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gQXVnIDEsIDIwMTcsIGF0IDQ6MTQgQU0sIDxh IGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIGNsYXNzPSIiPg0KaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPC9hPiB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyIGNsYXNzPSIiPg0KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ1VSdmVzLCBEZXByZWNhdGluZyBhbmQgYSBMaXR0bGUgbW9y ZSBFbmNyeXB0aW9uIFdHIG9mIHRoZSBJRVRGLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogRGVw cmVjYXRpbmcgUkM0IGluIGFsbCBJRVRGIFByb3RvY29sczxiciBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvciAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEx1aXMgQ2FtYXJhPGJyIGNs YXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+RmlsZW5hbWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiBkcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUtMDEudHh0PGJyIGNsYXNz PSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij48L3NwYW4+UGFnZXMgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7OiA4PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IkFwcGxlLXRh Yi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+RGF0ZSAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDIw MTctMDgtMDE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBYnN0cmFjdDo8YnIgY2xhc3M9 IiI+DQombmJzcDsmbmJzcDtSQzQgaXMgZXh0cmVtZWx5IHdlYWsgYXMgc2hvd24gYnkgUkZDIDY2 NDkgYW5kIFJGQyA3NDU3LCBpczxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3Byb2hpYml0ZWQg aW4gVExTIGJ5IFJGQyA3NDY1LCBpcyBwcm9oaWJpdGVkIGluIEtlcmJlcm9zIGJ5IFJGQyB4eHh4 PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7YW5kIGl0IG5lZWRzIHRvIGJlIHByb2hpYml0ZWQg aW4gYWxsIElFVEYgcHJvdG9jb2xzLiBUaGlzIGRvY3VtZW50PGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7b2Jzb2xldGVzIFJGQyA0MzQ1ICZxdW90O0ltcHJvdmVkIEFyY2ZvdXIgTW9kZXMgZm9y IHRoZSBTZWN1cmUgU2hlbGwgKFNTSCk8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtUcmFuc3Bv cnQgTGF5ZXIgUHJvdG9jb2wmcXVvdDsgKG5vdGUgQXJjZm91ciBhbmQgUkM0IGFyZSBzeW5vbnlt b3VzKS48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtSRkMgMzUwMSwgUkZDIDQyNTMsIFJGQyA2 NjQ5IGFuZCBSRkMgNjczMyBhcmUgdXBkYXRlZCB0byBub3RlIHRoZTxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwO2RlcHJlY2F0aW9uIG9mIFJDNCBpbiBhbGwgSUVURiBwcm90b2NvbHMuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1jdXJkbGUtcmM0LWRp ZS1kaWUtZGllLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1jdXJkbGUtcmM0LWRpZS1kaWUtZGllLzwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6PGJy IGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY3VyZGxl LXJjNC1kaWUtZGllLWRpZS0wMTxiciBjbGFzcz0iIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1jdXJkbGUtcmM0LWRpZS1kaWUtZGllLTAxPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0OjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUtMDE8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyIGNs YXNzPSIiPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyIGNsYXNz PSIiPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxiciBjbGFzcz0iIj4NCkN1cmRsZSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQpDdXJk bGVAaWV0Zi5vcmc8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2N1cmRsZTxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DAF193C1A6BD4BA5B026B4C5AAF3CEBEakamaicom_-- From nobody Fri Aug 4 08:27:58 2017 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 4F622132332; Fri, 4 Aug 2017 08:27:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150186047726.18653.15617743185555652342@ietfa.amsl.com> Date: Fri, 04 Aug 2017 08:27:57 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 04 Aug 2017 15:27:57 -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 WG of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-07.txt Pages : 9 Date : 2017-08-04 Abstract: This document specifies the conventions for using Edwards-curve Digital Signature Algorithm (EdDSA) for curve25519 and curve448 in the Cryptographic Message Syntax (CMS). For each curve, EdDSA defines the PureEdDSA and HashEdDSA modes. However, the HashEdDSA mode is not used with the CMS. In addition, no context string is used with the CMS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-07 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatures-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 7 07:11:18 2017 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 D6066132363; Mon, 7 Aug 2017 07:11:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150211507673.19050.13323214544773773031@ietfa.amsl.com> Date: Mon, 07 Aug 2017 07:11:16 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 07 Aug 2017 14:11:17 -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 WG of the IETF. Title : Ed25519 public key algorithm for the Secure Shell (SSH) protocol Authors : Ben Harris Loganaden Velvindron Filename : draft-ietf-curdle-ssh-ed25519-01.txt Pages : 5 Date : 2017-08-06 Abstract: This document describes the use of the Ed25519 digital signature algorithm in the Secure Shell (SSH) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ed25519/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-01 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ed25519-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ed25519-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 7 09:08:14 2017 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 07B9A13263A for ; Mon, 7 Aug 2017 09:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 vec_O0ZSJ87c for ; Mon, 7 Aug 2017 09:08:10 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F9B132632 for ; Mon, 7 Aug 2017 09:08:10 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id o85so3881038lff.3 for ; Mon, 07 Aug 2017 09:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DDPEC9+MYtpck+O1EMXppKd2/E1olXCRnw4CTqJHbGg=; b=ALAdspRhg1ovWdeNI2D4vAz3Mn2Sc9EKQjRwOQ+QLXwdiVGlQMFMY7TbFB7mvLjJlI DoXzIQ+6v+/e17q4jwBskV7RFTW34fwxtDSV87kHXCff4ewH/WS+KkpdBLdaRootZfmt K5r0d3yi/KJSfQqQu7xLIMgSTSi+cXRnBy2wo95GM+DaFYgWl/8bJAKXFJNoiPIZlAed JpZIYUxktx28p7ID/T41TqsfPvG8YiFVLhHUym6A0vCtRec/NX74yGdfChKLs4ZhsjIp 8F26aJFAMy6eVLd2FO3YIaGF5xBOnk3AAjgdfKQQj0c9upd4ZkP60oR9GmDHRmjQIQWE aH7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DDPEC9+MYtpck+O1EMXppKd2/E1olXCRnw4CTqJHbGg=; b=ZTl9hMPSieGPBDV0J7q1e8XfIu6fNrG86I3YVemnz1dYS6NrlsM9II8zDpBwq34SUw 11bcv6V+moQk3xxZqMylWBiKN8kO7093VA1oH8poCzlbGchcAJFTR6XA/viuvhqrN8IZ cPF7i/qogzNSShPmI8Rm3dx3l6i0pq3Vw5qkpiWpPzb2tmWXkM494ZsImPe1fQX9RYE5 ZS3igK1zuvib5CIj5eXLMIjm3RDMZuz6YPGyEz8/Bqq/3N7q6KyoZmHBw6hZZwRm2hxR 2ewYzjiWZqPifo2EFnGNAXxietrsAEoUIBQC/7twfyG+5WCnDq76ozgAyrwSFy6yM+h4 jNkw== X-Gm-Message-State: AHYfb5gpgtTE6pFza6sFGYcPyM/GaMit9u7On5YpdGT6to86g/WM/VN4 mYv4jpi9MeClXWT63C9dn6dVo6oBaQ== X-Received: by 10.46.21.20 with SMTP id s20mr317558ljd.147.1502122088847; Mon, 07 Aug 2017 09:08:08 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.80.68 with HTTP; Mon, 7 Aug 2017 09:08:08 -0700 (PDT) In-Reply-To: <50122.1501430873@eng-mail01.juniper.net> References: <150142547596.17769.2342902440380875523@ietfa.amsl.com> <50122.1501430873@eng-mail01.juniper.net> From: Daniel Migault Date: Mon, 7 Aug 2017 12:08:08 -0400 X-Google-Sender-Auth: -vvFWdW42_0vZZXdtDK7cyHCC6c Message-ID: To: "Mark D. Baushke" Cc: curdle , Eric Rescorla Content-Type: multipart/alternative; boundary="94eb2c1cc94683df9d05562c0dd1" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-09.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 07 Aug 2017 16:08:13 -0000 --94eb2c1cc94683df9d05562c0dd1 Content-Type: text/plain; charset="UTF-8" Hi, We have discussed this draft in session during the IETF99, and Mark updated the draft accordingly. If you disagree with the update, please provide your feed backs by Friday August 11. Here is the summary of the draft: Key Exchange Method Name Reference Implement ---------------------------------- ---------- ---------- curve25519-sha256 ssh-curves SHOULD diffie-hellman-group-exchange-sha1 RFC4419 SHOULD NOT diffie-hellman-group1-sha1 RFC4253 SHOULD NOT diffie-hellman-group14-sha1 RFC4253 SHOULD diffie-hellman-group14-sha256 new-modp MUST diffie-hellman-group16-sha512 new-modp SHOULD ecdh-sha2-nistp256 RFC5656 SHOULD ecdh-sha2-nistp384 RFC5656 SHOULD gss-gex-sha1-* RFC4462 SHOULD NOT gss-group1-sha1-* RFC4462 SHOULD NOT gss-group14-sha256-* gss-keyex SHOULD gss-group16-sha512-* gss-keyex SHOULD gss-nistp256-sha256-* gss-keyex SHOULD gss-nistp384-sha384-* gss-keyex SHOULD gss-curve25519-sha256-* gss-keyex SHOULD rsa1024-sha1 RFC4432 MUST NOT Yours, Rich and Daniel On Sun, Jul 30, 2017 at 12:07 PM, Mark D. Baushke wrote: > Hi, > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-09 > > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-09 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-sha2-09 > > I have tried to incorporate the feedback provided at IETF 99 into this > draft. > > Hearing no feedback on my suggested changes, I have published a new > revision. > > Please let me know if there are any additional changes needed. > > Thank you, > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c1cc94683df9d05562c0dd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We have discussed this draft i= n session during the IETF99, and Mark updated the draft accordingly. If you= disagree with the update, please provide your feed backs by Friday August = 11.

Here is the summary of the draft:

         Key Exchange Method Name           Reference  I=
mplement
         ---------------------------------- ---------- ----------
         curve25519-sha256                  ssh-curves SHOULD
         diffie-hellman-group-exchange-sha1 RFC4419    SHOULD NOT
         diffie-hellman-group1-sha1         RFC4253    SHOULD NOT
         diffie-hellman-group14-sha1        RFC4253    SHOULD
         diffie-hellman-group14-sha256      new-modp   MUST
         diffie-hellman-group16-sha512      new-modp   SHOULD
         ecdh-sha2-nistp256                 RFC5656    SHOULD
         ecdh-sha2-nistp384                 RFC5656    SHOULD
         gss-gex-sha1-*                     RFC4462    SHOULD NOT
         gss-group1-sha1-*                  RFC4462    SHOULD NOT
         gss-group14-sha256-*               gss-keyex  SHOULD
         gss-group16-sha512-*               gss-keyex  SHOULD
         gss-nistp256-sha256-*              gss-keyex  SHOULD
         gss-nistp384-sha384-*              gss-keyex  SHOULD
         gss-curve25519-sha256-*            gss-keyex  SHOULD
         rsa1024-sha1                       RFC4432    MUST NOT

Yours, 
Rich and Daniel

O= n Sun, Jul 30, 2017 at 12:07 PM, Mark D. Baushke <mdb@juniper.net> wrote:
Hi,

> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/d= raft-ietf-curdle-ssh-kex-sha2-09
> https://datatracker.ietf= .org/doc/html/draft-ietf-curdle-ssh-kex-sha2-09
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-curdle-ssh-kex-sha2-09

I have tried to incorporate the feedback provided at IETF 99 into th= is draft.

Hearing no feedback on my suggested changes, I have published a new revisio= n.

Please let me know if there are any additional changes needed.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

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

--94eb2c1cc94683df9d05562c0dd1-- From nobody Mon Aug 7 09:29:07 2017 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 592CB131D69 for ; Mon, 7 Aug 2017 09:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 kVf-uW0sd4Vi for ; Mon, 7 Aug 2017 09:29:03 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327B5131CE8 for ; Mon, 7 Aug 2017 09:29:03 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id d17so4247826lfe.0 for ; Mon, 07 Aug 2017 09:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=obLnATpbrNYppF7D99tv4nguEFkLnxmrIwZ2Ir8epAM=; b=MVEGWxNwgc4vtH/h6IQZbyVHmH94e5wBNMbl3NtkrE4qX/9EzSWLF4y97WhRKcO/kr D/X+xKQ8Bi0VIiDfBBx91lgfI1iRbMzowkIwsuiCWrchzp1N/S5ywRsRKx3a9uhjHODs ptWlIPQhLlPJyvaXdpa8grT+zcTNL+xsVvjRp8fAZoU8TOL+loLJyRMSCskWkQMXBk7/ EjuAuHw7IPP8IzjK0ehdVMKVxUgLh3rQeCZ6b0VyYNzv60GEsexV3qK3qYAUUpZ1edKs 5qnYRw2F03NvG0xmfmuzaHlOZ3eMSI875mMSfl1vnmTR2yiEIl7X6E3ryt7oUHWvpblT MaXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=obLnATpbrNYppF7D99tv4nguEFkLnxmrIwZ2Ir8epAM=; b=Cbn+kYDGihvvAoWKALrzJzxcAv3wglHjg6xa6SIsBd5StUamhyol9GHL8dhj+rbDHf W7qh8HexK62BJc2ylw+Sdpb6VNrRU+LALwqyKH1cK24CcCxMvV1HaHui1I7ryOvCPp4j TKAsmNx1yb/qYT8J14zpN5U6zZlkff06t3L5QOoO+FECCuNiXlenWJWVkCwu+AH3X9xd ASVMq62mgseDwgLsjeExT8V4yS9UEeufQiLTTzvgdEbPpMfFBoulgcIlRWLVJkD9W//g W5Q+8hLxmTkoskRXt+JETcp1/D5RNvNAUokwH9rh1iHf9gU5Vw/vCFkxz68qdpIWXhIY HhKQ== X-Gm-Message-State: AHYfb5gQLrL/oYErsQU28M1kTGJEP5IU7yp5mgeeBtKN/0bZA+2F3XNd KZuQtHX8+I1NUDeBrTkPVlAp8AVrfA== X-Received: by 10.25.160.84 with SMTP id j81mr373254lfe.168.1502123341109; Mon, 07 Aug 2017 09:29:01 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.80.68 with HTTP; Mon, 7 Aug 2017 09:29:00 -0700 (PDT) In-Reply-To: <150211507673.19050.13323214544773773031@ietfa.amsl.com> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> From: Daniel Migault Date: Mon, 7 Aug 2017 12:29:00 -0400 X-Google-Sender-Auth: vW5XAuKZrZZSrqw53jT8_TEDews Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a11402c7427de9405562c5804" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 07 Aug 2017 16:29:05 -0000 --001a11402c7427de9405562c5804 Content-Type: text/plain; charset="UTF-8" Hi, Thank you for updating the draft. I am wondering if there are any reason for not having ed448 in the draft, and if not I would suggest we extend the draft to ed448 as well. Yours, Daniel On Mon, Aug 7, 2017 at 10:11 AM, 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 WG of the IETF. > > Title : Ed25519 public key algorithm for the Secure > Shell (SSH) protocol > Authors : Ben Harris > Loganaden Velvindron > Filename : draft-ietf-curdle-ssh-ed25519-01.txt > Pages : 5 > Date : 2017-08-06 > > Abstract: > This document describes the use of the Ed25519 digital signature > algorithm in the Secure Shell (SSH) protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ed25519/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-01 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ed25519-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ed25519-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 > --001a11402c7427de9405562c5804 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for updating th= e draft. I am wondering if there are any reason for not having ed448 in the= draft, and if not I would suggest we extend the draft to ed448 as well.
Yours,
Daniel
On Mon, Aug 7, 2017 at 10:11 AM, <inte= rnet-drafts@ietf.org> wrote:
https://datatracker.ietf.org/doc= /draft-ietf-curdle-ssh-ed25519/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-i= etf-curdle-ssh-ed25519-01
https://datatracker.ietf.org/<= wbr>doc/html/draft-ietf-curdle-ssh-ed25519-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-ssh-ed25519-01


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

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

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

--001a11402c7427de9405562c5804-- From nobody Mon Aug 7 09:31:45 2017 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 A453313241C for ; Mon, 7 Aug 2017 09:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 zslwqDG2nu4q for ; Mon, 7 Aug 2017 09:31:42 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A6C1324A6 for ; Mon, 7 Aug 2017 09:31:41 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id g25so4217205lfh.1 for ; Mon, 07 Aug 2017 09:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=lsuyxGuGt1AiQzyltLnB66ilLm5yIGlCWk3mY9Z1Bd8=; b=pFqX/HGAAlGQgj3oahB+M+jD6et0IX7fC+mDzQwsVVPmBjZT26mbYRsqwVzwF5a/Wx VYz2v6DoxhVHFhACzlbgJKy6CvTSK7wujZSQnlGfmEYMZxbUCMTT8Z03kcNgoLEls2mY MYLjhgHVsJQJ3cPaemwsEu6cUlJRX1bI+1aIqMP+w+kQjYtlMyp/lpcu9hJ4AuM7FHXx nPfqWhCHCTnXd6bO65I1bg0betnuhp+4rsP4jwL5y2h/2BPLEjaZ2K3/n3LA5xgCzqql SdZ+oM3i2rDSZqed94t2ZsvSppD0f7/hNC8sDd7AMwinnTMFb7AAO6PHdeVmfXG+Yjv3 nVQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=lsuyxGuGt1AiQzyltLnB66ilLm5yIGlCWk3mY9Z1Bd8=; b=fHjXe1UkITTFj/KBmO7v0o/qf8Ma49x4QsPgq4qvRerFcoNP2SeZsEQO6AnNZpnTsq h+CezH2Vwo2NMRUIwjh5uaO+Z2nFKrmPplF7E7lK2T5TWidnwgljrAYN8LBiAJE/KG1D oXZdE2YlLZcjP48d6tNNnL0iID6t7Ja882ahQvpuVi/StAUr4jdnlorbbk1TgRDGTHtg 05Ba9/+H091c7HYibyWlgyiRCABbyguuM8XYzttLgXHXOmkdt1rlPJfJsBQT5YQpGfzc hur6lMFNaVKt2/fZcHg37gyVsrw7XcLnhD23z6PHXs/8idAmLfaUboQt3Q2nDa11RD5C qo1A== X-Gm-Message-State: AHYfb5guAPLxYKv28k8vspkEKlGwATPAO/J2hhffUk0xXP3sgkXPyYdj GJ/IrA9Sg8FCeLp5lEN+gjjOdeNynQ== X-Received: by 10.25.32.202 with SMTP id g193mr373088lfg.183.1502123499618; Mon, 07 Aug 2017 09:31:39 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.80.68 with HTTP; Mon, 7 Aug 2017 09:31:39 -0700 (PDT) In-Reply-To: References: From: Daniel Migault Date: Mon, 7 Aug 2017 12:31:39 -0400 X-Google-Sender-Auth: wk9yEiDHngWlacIvqt8VrCJiHW0 Message-ID: To: curdle Content-Type: multipart/alternative; boundary="001a114036029a857e05562c61a3" Archived-At: Subject: Re: [Curdle] WGLC draft-ietf-curdle-gss-keyex-sha2 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 07 Aug 2017 16:31:44 -0000 --001a114036029a857e05562c61a3 Content-Type: text/plain; charset="UTF-8" Dear WG, So far we have not received any responses to the WGLC. Please let us know if we are ready with the draft by Friday August 11. Yours, Rich and Daniel On Thu, Jun 15, 2017 at 2:55 PM, Daniel Migault wrote: > Hi, > > This email starts a WGLC for draft-ietf-curdle-gss-keyex-sha2 "GSS-API > Key Exchange with SHA2". Please review the draft and provide feed backs by > June 29. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ > > Yours, > > Rich and Daniel > --001a114036029a857e05562c61a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG,

So far we have not r= eceived any responses to the WGLC. Please let us know if we are ready with = the draft by Friday August 11.

Yours,
Rich and Dani= el

On Th= u, Jun 15, 2017 at 2:55 PM, Daniel Migault <daniel.migault@erics= son.com> wrote:
Hi,

This email starts a WGLC for draft-ietf-curdle= -gss-keyex-sha2 "GSS-API Key Exchange with SHA2". Please rev= iew the draft and provide feed backs by June 29. =C2=A0

T= he IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/

Yours,
Rich and Daniel

--001a114036029a857e05562c61a3-- From nobody Mon Aug 7 13:21:13 2017 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 91C97132484 for ; Mon, 7 Aug 2017 13:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwHQj5RxAIXK for ; Mon, 7 Aug 2017 13:21:10 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FAE132480 for ; Mon, 7 Aug 2017 13:21:10 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v77KHYQA027524 for ; Mon, 7 Aug 2017 21:21:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=6ZSAy16GhdvQR0PCEPAKkIuNWspXx/JpnnjRO5q3a9I=; b=P8EXuFvvpqt/gYy+3gmhHuctv2FyS5bHPStJw31YtFacaSarouBqi4QKDgatOys7Bvgu p5ibrQobZ00kkOpk60nwexhcX2WxL/f9wkP2u5qYoIyFCE6MD4TdDAu+fL23EXcf66RP 5gpAoO0IrglWg7KiAUagHL0u68x+BFsOiaZeqqW7JKdRWCoFKjuxok9csuhgUQB0ql8v +DV1SJpds0Oju1uAJPyzG8/JM6w0+YBsihbb7Ei9sl1ZuGe0iFX366Y2T3GAFTzjXnFY v9X1ZfIbU429FRWOhvNeszYOPcLlHVkR6o+s1EYWpmFGyu0MfqUbEr+l36RaGCbEAn8z gw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2c533bwh2b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 07 Aug 2017 21:21:09 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v77KG6XH009488 for ; Mon, 7 Aug 2017 16:21:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c59bur7q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 07 Aug 2017 16:21:08 -0400 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.1263.5; Mon, 7 Aug 2017 13:21:08 -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.1263.000; Mon, 7 Aug 2017 16:21:08 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Call to adopt draft-ietf-curdle-rc4-die-die-die Thread-Index: AdMPumDzGEm1LxOzQIqgK6FraZaC1w== Date: Mon, 7 Aug 2017 20:21:08 +0000 Message-ID: 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.51] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070335 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708070336 Archived-At: Subject: [Curdle] Call to adopt draft-ietf-curdle-rc4-die-die-die X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 07 Aug 2017 20:21:12 -0000 SSBtaXN0YWtlbmx5IG1hcmtlZCB0aGlzIGFzIGFkb3B0ZWQgYmVmb3JlIHRoZSBXRyBjb25zaWRl cmVkIGl0Lg0KDQpUaGlzIGRyYWZ0IHdvdWxkIG1hcmsgUkM0IChhbmQgaXRzICJvdGhlciBuYW1l IiBhcmNmb3VyKSBhcyBhIE1VU1QgTk9UIGluIGFsbCBJRVRGIHByb3RvY29scy4gIFF1b3Rpbmcg dGhlIGFic3RyYWN0Og0KDQogICBSQzQgaXMgZXh0cmVtZWx5IHdlYWsgYXMgc2hvd24gYnkgUkZD IDY2NDkgYW5kIFJGQyA3NDU3LCBpcw0KICAgcHJvaGliaXRlZCBpbiBUTFMgYnkgUkZDIDc0NjUs IGlzIHByb2hpYml0ZWQgaW4gS2VyYmVyb3MgYnkgUkZDIHh4eHgNCiAgIGFuZCBpdCBuZWVkcyB0 byBiZSBwcm9oaWJpdGVkIGluIGFsbCBJRVRGIHByb3RvY29scy4gVGhpcyBkb2N1bWVudA0KICAg b2Jzb2xldGVzIFJGQyA0MzQ1ICJJbXByb3ZlZCBBcmNmb3VyIE1vZGVzIGZvciB0aGUgU2VjdXJl IFNoZWxsIChTU0gpDQogICBUcmFuc3BvcnQgTGF5ZXIgUHJvdG9jb2wiIChub3RlIEFyY2ZvdXIg YW5kIFJDNCBhcmUgc3lub255bW91cykuDQogICBSRkMgMzUwMSwgUkZDIDQyNTMsIFJGQyA2NjQ5 IGFuZCBSRkMgNjczMyBhcmUgdXBkYXRlZCB0byBub3RlIHRoZQ0KICAgZGVwcmVjYXRpb24gb2Yg UkM0IGluIGFsbCBJRVRGIHByb3RvY29scy4NCg0KRG9lcyBhbnlvbmUgc2VlIGEgcmVhc29uIHdo eSB0aGUgV0cgc2hvdWxkIG5vdCBhZG9wdCB0aGlzPyAgUGxlYXNlIHNwZWFrIHVwIGJ5IHRoZSBl bmQgb2YgdGhlIHdlZWsuICBBcyBhIHJlbWluZGVyLCBhZG9wdGlvbiBkb2VzIG5vdCBtZWFuIHRo ZSBkb2N1bWVudCBpcyByZWFkeTsgaXQgdHVybnMgY2hhbmdlIGNvbnRyb2wgb3ZlciB0byB0aGUg SUVURiBhbmQgdGhlIFdHIGNhbiBkZWNpZGUgdG8gY2hhbmdlIGFueXRoaW5nIGFib3V0IGl0LiAg VG9kZCBTaG9ydCBoYXMgYWxyZWFkeSBwb3N0ZWQgc29tZSBjb21tZW50cywgZm9yIGV4YW1wbGUu DQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9w ZW5TU0wgRGV2IFRlYW0NCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElFVEYgU2VjcmV0YXJpYXQgW21h aWx0bzppZXRmLXNlY3JldGFyaWF0LXJlcGx5QGlldGYub3JnXSANClNlbnQ6IE1vbmRheSwgQXVn dXN0IDA3LCAyMDE3IDQ6MTggUE0NClRvOiBkcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1k aWVAaWV0Zi5vcmc7IGN1cmRsZS1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IElFVEYgV0cgc3Rh dGUgY2hhbmdlZCBmb3IgZHJhZnQtaWV0Zi1jdXJkbGUtcmM0LWRpZS1kaWUtZGllDQoNCg0KVGhl IElFVEYgV0cgc3RhdGUgb2YgZHJhZnQtaWV0Zi1jdXJkbGUtcmM0LWRpZS1kaWUtZGllIGhhcyBi ZWVuIGNoYW5nZWQgdG8gIkNhbGwgRm9yIEFkb3B0aW9uIEJ5IFdHIElzc3VlZCIgZnJvbSAiV0cg RG9jdW1lbnQiIGJ5IFJpY2ggU2FsejoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1jdXJkbGUtcmM0LWRpZS1kaWUtZGllLw0KDQpDb21tZW50Og0KRXJyb25l b3VzbHkgYWNjZXB0ZWQgYnkgY28tY2hhaXIgd2l0aG91dCBmb3JtYWwgYWRvcHRpb24uDQo= From nobody Mon Aug 7 13:28:39 2017 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 548E71323B6 for ; Mon, 7 Aug 2017 13:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6Gcr444D0CS for ; Mon, 7 Aug 2017 13:28:36 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0095.outbound.protection.outlook.com [104.47.32.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F311323C3 for ; Mon, 7 Aug 2017 13:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P2qg7IFeYHbQ4gyLjScWioPxkIAtVXsGMoeQZqWZDUk=; b=RBdaD8kiFTGfxIunzW36uQbjSghu7LYogISLAYecgIq0KkwrIrxsAT64G8+IDansreYEZVEFEFUN03kOWJd0tHeT9ytFBxYIzTdYkvxvmW27PK0zpJ9wHQEWZMqq2rTfQVwFtyj2WmcxS4ABXde7ikFhyDQR8eyuHx1eh0Xv5JY= Received: from BN3PR05CA0019.namprd05.prod.outlook.com (10.174.64.29) by BY2PR05MB157.namprd05.prod.outlook.com (10.242.39.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Mon, 7 Aug 2017 20:28:33 +0000 Received: from DM3NAM05FT008.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by BN3PR05CA0019.outlook.office365.com (2603:10b6:400::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1341.9 via Frontend Transport; Mon, 7 Aug 2017 20:28:32 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT008.mail.protection.outlook.com (10.152.98.114) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1304.16 via Frontend Transport; Mon, 7 Aug 2017 20:28:32 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 7 Aug 2017 13:28:30 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v77KSUV5013838; Mon, 7 Aug 2017 13:28:30 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id E9CC41144E; Mon, 7 Aug 2017 13:28:29 -0700 (PDT) To: "Salz, Rich" CC: "curdle@ietf.org" In-Reply-To: References: Comments: In-reply-to: "Salz, Rich" message dated "Mon, 07 Aug 2017 20:21:08 -0000." From: "Mark D. Baushke" Date: Mon, 7 Aug 2017 13:28:29 -0700 Message-ID: <74760.1502137709@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39400400002)(39850400002)(39450400003)(39860400002)(39410400002)(2980300002)(189002)(199003)(77096006)(4326008)(69596002)(38730400002)(2950100002)(626005)(5660300001)(7696004)(97876018)(189998001)(6916009)(105596002)(81166006)(81156014)(110136004)(117636001)(6246003)(6266002)(50466002)(2810700001)(356003)(8936002)(2906002)(86362001)(106466001)(5003940100001)(53936002)(97736004)(229853002)(76506005)(76176999)(54356999)(7846003)(6392003)(50986999)(68736007)(230783001)(53416004)(55016002)(478600001)(305945005)(48376002)(47776003)(8676002)(558084003)(7126002)(4743002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB157; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT008; 1:ggHlcDS9KFJgTKQEklGjDj26FakLgQl9DuZ9uIMzGDjv/3rIFxdkQxQmZBVLvID/a/ltMKdSgMkvlxuYcFn9kfWnzQXbOFQvUcGFMaAai2cvWekMrb+DZxPVbwColg2+dGklyWx7IUHeNl/SDG2NIUz4yOpIIohVJFhUHv1ms+9W06tko9I7pIdTtc3IoPRRyz77dhJxUrDxs8ImaPpHgqdrZi4vlPlmp7lkvWMK/5QI5vvd0QRCo+3uAbqP6AbZft5Jy/qs46XRlJQjYfA1INlUA5wasg8goPk+sPejCeOtmTZyvBKOoLXQOX0RmTMPrPjhNpkMlpF1c1FAuWc3nqV0XVzT+c2hEv4MX/9sAH/Th2VGFVMdM+hHm3b1jXMQ7BA7EYtRUW/BnE6k91fFu2UFecALyMSXnmEsutalboUhzEbX/OKcPorkGGn47hkNAcyy0f5k9IEvr4sSWu11yN9btDtNuAqgiRDUB9tJpvZJJbIXX3LjKrLrryyr8votCzPV2fD+6SsFbJvpiD+ImjczVx7Z5AjPE45/ElBjNVFH4Wv+LAL+Fi9Qk5uJVPf2mU7vrttsGM+2HO9g2hL4spZBeL9PMLj55kbkZd4DQHYPBxF64PFJIDQ+Uh+uZozFFA88moJMOvB10GtuKhafoVZsmCFaIBeeK+e3nAGBYAI6WyL71E2sMD+Z5yk4a+RDsmIsvGrfphZ6kyR1ee7RfeVwtYaD4CDQ5dkRFpfCOnzGFrayJt26Ko0mkZNY12Pa7banio9iYEacvk/fcV4QCo/LBv1dT/LBCwXD5ziPet8OZNsfCYxEWDhDuVNPqfWJw3V1OLS4JA6I9gZ5f1/QvQ== X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2c3ec04d-f18f-434f-b20f-08d4ddd2df4e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR05MB157; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB157; 3:4BecRlAxTf6eldYu2Er/jxgytW58b+QUV+d91cnIsNl43eHUGh1LXpEL7cdBijxG7tROqE3Qnd+MzVNy3sakFNHdZb7VKpWXoBOO7W1rTNMxE13K71tUVwKuNGYioJY8OrVL1jvwkWeeqagV0nM9Pk8ftqxIiLiXwOqZITrFZC1EYtOb9BNVEvenyFh8OT3PgttIWI2Vnp0vEbLdXsw3IBI3KqkibYTMGz9n4J9VRyhLFHpSGDi3Q0p7zAGPIDKqi8nrD/YYU5e2dtBuwFHAPfJEJgzsNUMcw7Ocnicdz0hMPL9g4M0GaI0k4uslembyjdJ2dBe3ad3NysLB3bcMp1OhZ3uSocbEzrnoBu2T6gaOEVHlwzZ5jRKWl1wc0vV0X6DfnaLn6k05VFawGgjo02Psn2gFL1TBqyz51/j5An+a6+UhOEOhrrmj8tEgJKRrsG5jmiR3tTSKpAPhZiO6O+zlVP4ZF0vIjngEsWlKuPm7JzfLT0Dg51jo+FzJJcplChxlpj9jjLw0hTb1se2ET9fgkDFyiy3z9poo8pf2n5JpxqytIKOpxUCePinl2P9p6ivhfqwD/x3WhK6wQMXWSm0vVmNaoKYhW0+/yjoC84Orl3qOcEcVmjQtxaSUkOWefe38rDccz+ZaNmfZT7S/U6GiuSArGEhOuSPJnHszge8WzU3GVuUztXs8Il2uoe7xWZnMuBxiGunPgjKCKdHE3t6DNBpjeB+f5cl2ZBemoCqvAPWG8YVSQ6Sjc0nXmwr9m8InQIyDMlEvZ6+oTAysRQHtV1FPDxeox7wEFMnim2wcfLaXKL2tZrv/TlOd66ACoTxAgU9oOAE4qCwGDH6yxZSeQEiYoXBp6qAEaxQ6gf95vHyYK+moUbhOpYZ3SjLAcgVupm6wWyLGkS4WYN4xalIksl9ljeE2Jud0JcwlX2ZLiEqBqJ7Mt6PJCOQ6zpPy X-MS-TrafficTypeDiagnostic: BY2PR05MB157: X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB157; 25:7dKTrNLnIthc81u+J5pDABtbdeRx7vqGWTvr7EMwUo?= =?us-ascii?Q?LNlLMC/Zk8C6DVD6PL1zAdAhDFXsu+0edLHOiqHf8DrxqrFCslCWm94qO/ej?= =?us-ascii?Q?8gmqUMSWPHWMhKFCJTAO8vCpPhqSBi5RrPiMA/rsm/73Uz6dSOFoGYWfm7Lp?= =?us-ascii?Q?MFqedG5mBHijkYadZxK6h2zbENmzDo7FUrzJurLnj8vLuK8sS+Hqc+g6hKGc?= =?us-ascii?Q?QgmflrW+MuYZ0qmyY47o/EN9C6bVw1lSYkPDd6c9AkS7cVwPFDpJkHcQxAOf?= =?us-ascii?Q?VIjgQMONANtQcatiTmk+9naAW2Q8QrRksmEGNiwYIpXNGdeRV2PcqjwyRQYp?= =?us-ascii?Q?/yXcZQ9ExlNgduX2zfx3/A9ZqgUh6HpX2nGOhGC6UgCAvQBoFa1MTbuHv4nK?= =?us-ascii?Q?zZ2ckOv3QAa422nQaAgZNEHvxXOBPmVI0LPmp1fhSV+1DAGGk6PUQT3xI2Cn?= =?us-ascii?Q?cn9gOZxygGMT6dux+7DxaOqMxMP6vFpIkEyQUv19rWUQFm1qlNxQsCKn8gSG?= =?us-ascii?Q?qjkOVn7Ux+3cpk/zu0krAeCTtMowfpZ9pw+ApQaC3KfbmE88khWL4Z/Q1RC1?= =?us-ascii?Q?Da0ODq/GilPxqm3KlmpPwhSAuRr9h5wzn8HHuaawQXXO4OcH3550Q/ZQ9iT0?= =?us-ascii?Q?ykD5LacoagJePmfnhZOgEcnS0f4mDl7sKGhqTTUXg6amwq2XYPwwHrs58uMa?= =?us-ascii?Q?IMZrJVWbuEzo+fyMlhBoM9VZ1iL5zo2rQkkmttcwzzobTuTFQS9QBuu0asEr?= =?us-ascii?Q?RMeY7ACEYslSJEC1/zvPbhfx0ZzrxAici131TIXDW+crFeNysga9Q4rru0ld?= =?us-ascii?Q?us0iTyOSp+6trZeVBCxtwzTf3hGSta9Puf4mGU0lYPmbDJFhn85DRtk9wjaU?= =?us-ascii?Q?YdN96yUGQxJz//VFFH4an5TANMJDRca0Oe7tQaU8F+ePkEX+q39qSBuXbd3N?= =?us-ascii?Q?wbgrbrxfKaxjYTKWjBYQ2pX0ijM/+vdxrICHNyVA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB157; 31:rQOzBLVfTbVptTVAFkEFH3twGRRWd7jkeD/1uQeIxdcpMJMpjNYWLS1ToKNSRPh5mLgvJAs6xgHqM1Xi3nPbDG2l7K2vGBBTfA2bTM2cbFZ5Lrjc5KFO7GInn1fpnNLDZUc0yRh7c7udEQcMS2FLNryjT7DuDTsi+LcHCNJDN4kaffJurlllgCCrOYh+465Wce/OsLDdTZ/vAtDIrepfbqCuTQKyJXyoJt6x26FkxUfY0qQ/kYe54J0x15YkejH/3crGsnCqjukpicQdZtLpLbhvSso+XohKyAlSanxaf37ePDIuAY/cHlcOo3tJd3GCrusDGUzcYu9EqGdmx/lIhUqIU606m2u9GdVitAwF2NgqCxMTTkwtoab/fD5EvTY1UvdpxAGO3oq5eVWzpLfYaFwGO49WwStMv5fK1cz/vuV1qlgKfA8cPEe+dM9esHrP8ej5YdTVYDUlO5LAoqCePujhyxP/dMIPjbR1rtjet4oXqkWPY0DUPijOzEwFfuMHBkBo6ByaQ5tX9k3BN63belNUfvuqTPanm56ufxMf1EhR4gAyHMb6S1dGHelanm4k4Ces0OK8G0zXS31+XECk3g0Y6kP/Yf2E1Q419uo2N0PsHvxiSHgKiBcGYdDHEQG/250BTQVKp+HkiGn+3NU9gbAzAjo8E/tX8d0JGrtD1h46FqY6i4NiTcwKAxYcnkVmdU01NfbEZN3bvt/dETFudg== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB157; 20:GlWlZtm45x9vlaNXqRCqOYMjve9dGtWXLu0hvR7gLmcA5xZ7DC+8gFbZ4fLIJbFciJn0wyMqPjCMA7xC/gvZPboOPEq/eMDqSYT+IBfIcV/J/WamvJCFZAE3WHESoA1M0fbR6QkTvcrpClX5Hq9oVQti6VYh8/W83Sf0gxcO4lhOuCfGdYB8QlGtMIuUouOeKgB8DyUn0q/zWq5znlOKUCIxsih1SqK9fg1v0MUwGMC5h4gzE9rhQRNt3ZUTl7GidWcvk0RS9o9wlB9i2S+TmxvM0AU+ehG0VmmwbvMClrX0OYnKmzZK1IcfHc20IUFHpLGGk4ENKyHzf2vX+lADhhGbQK6sZrBou/HiiatZniXvV8vTYaE5i4H3Ps9HcqeyZdYBBbjT2fHL5uXMKJQ4CnZhtkOPU1KYJKd7/EE8arnCwLpqf71rzrbd2ukWlBTdjTIU5oqE99LzwjvCdk31P/T82iXemPH4MuaXE47lNK7qxU2TPvuuii5sKFa18DPA X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(13016025)(8121501046)(13018025)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR05MB157; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR05MB157; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB157; 4:Yypi8N2xkIgy0isqp7cR9mjBDDEIpaJUgxSVZGzbDmp?= =?us-ascii?Q?SKfi5kY7uzzeO6b6aqJ9kKbRAuop7rXmGc/czPAplG+QipKqTVI5R5wb5qgU?= =?us-ascii?Q?XTTlk3CRb1vOmlbLUCW0UhoBYmF5y0+p24Xz2GiaXH0/3EZv20SIneV55v7t?= =?us-ascii?Q?ujtT1rBvmJue5gnOrF2TMXUDU76XUGdWsDOk25UuUD0xRuvnjNe8+cb/YoMs?= =?us-ascii?Q?omq+Qcw7AEYdvBR9HNKCfl8FFFySFU2NgFig2lyJUF6wTLYi2tH123h+fo/9?= =?us-ascii?Q?7eJGqxl2dN8CD7ZjtncyGLf72w+Lb9swvX+THOE+Uxi3whP2ZgRBSpXFjiaY?= =?us-ascii?Q?GIjbBdtQXkp6baO+j/g5TeVnWZpYdJJYuMTAr51N6R1yOmUCOUoSlhvp6cjo?= =?us-ascii?Q?L8DnclHna7Xo/idjCLi8teBY1Oz2XZrxGaYUiUt5ZemE0vGTb5vO6Psc35+1?= =?us-ascii?Q?iJnK4meZ5cKB5ehd85JWaorcNrc5pFVTCrZHtDBj9witiZJuXx/N2paIkCAO?= =?us-ascii?Q?skdmMG4YuCjZ2zyUY1+TNKkjVHJLQLxJK8kXBazJ/QkHugBRhmf9ommV08YW?= =?us-ascii?Q?3S9tFrhedfDYoAC+4KBATqaJJFa7TGyqog7INwZIpUQ2oaNgMY0rkh2azB7O?= =?us-ascii?Q?PQ2Sbz7135FW8R1jUHRwT/zZfpfm6zHMH2GFww+Jj73JeX+xdBP4CHRrxmck?= =?us-ascii?Q?j/UO1QIu4y7q+FEjwDECiuiphKWAOgU6e5WE+KdMXIE4m0kwyDoZcBzqBbR2?= =?us-ascii?Q?2tQCpC4xXStwiwUlgGaUoXr7s+QQwqEOItIy48XjLvYVNrZ4NihGpRmuK1Nz?= =?us-ascii?Q?yHf507QFxzWb6MpWtybLHp6dpya3YB1FAfrOvAhBhBcVHbEoGxQTFtxumoI8?= =?us-ascii?Q?dg5itTz6DGd72IU6IQnTfkIZoucQxCLQ5H+TefC6tikHy3IRYdUBb5XtkYJH?= =?us-ascii?Q?SSe5bRAd79EWLSs46VuYrlzduAsXEVp3AO0mdQhAg6xfHbD/QlfnwK/QnwT5?= =?us-ascii?Q?CMj12uBl4qEAk3R9DQUSm68sHOMGVMJoU5yWD6fGapqi75x/hGShHJUl9uYx?= =?us-ascii?Q?+lY1DQMX7BgD7BKy1IyOpeApNttOD1UeDTSh9OV0S3Bu94MEIEos9xlgcnv5?= =?us-ascii?Q?b3yAHNyeFc6VPbms8FUvypyasBj9QdeUUvnbfJi8RcNakAWv1Dt4O8RqlVbE?= =?us-ascii?Q?hnkD4Pkz7fNV2b6U/8lpR5WukMQqkW9a4?= X-Forefront-PRVS: 0392679D18 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB157; 23:BzyukmcOKZp0wdT+WfeI4fXK5g6386poZfpnu3W+QP?= =?us-ascii?Q?pb7w06MRnMCSz7HW63Js+5q+AAld8woxAc0VK0stuP1jYFZzxMEj+09ce+0d?= =?us-ascii?Q?YfeU2wcr6sQ+gLtL7fTX/aClRdEq/zecrgCVdx+hhCFxqKwW55nHlbGYFT5m?= =?us-ascii?Q?6pZcMT7xhr1Mk6WeGApcYMajuAPI4gi3MYEfFzCl6tqwzuosw5QP+gv4NtGl?= =?us-ascii?Q?71qT6YuGn0JWqTmuvIjqPFGEtHEF/+dTHrhvVGG/LWsNHzWW0KZ0alWdV1Aw?= =?us-ascii?Q?0REXMHtAgdG55Nz5bRedr2bdSNKdSo7CiTOExq4mNqKSwU000XX73aA5Emv+?= =?us-ascii?Q?lZMlPBh/nSdwFODo5ED2VAFtz1jTsIKLPvkGDtLllsw9GjxJoeBBXmwkMXpI?= =?us-ascii?Q?VWfFHDr++7hRPcEMAqyGeoJ1qaKUALRl2MY04Bb4Dd1pssqQN3wqm+7rQwx3?= =?us-ascii?Q?BJtuHvjAlHX2YB/UCJEF0QJrYivgA8XVmtIt1hEPxj8vvn9Y1zM8kIop0RrN?= =?us-ascii?Q?RUUwq7afrKHs/mqOqeO1CSOfRTPDxLJ4CgSQACmmgJC19xpn7L9TNr8HfJgj?= =?us-ascii?Q?/dPDkZpVai10Nyjzy7dIWbWkzHqJ+yy8E8JnEFSVNa/vfo7M7WZo9BstLnbC?= =?us-ascii?Q?SAYHbZYUtCQSKSERpCa/wDMAyuz3RohV93/8Y2moawBBW11UhMLAkBehtObl?= =?us-ascii?Q?qJ5muzILJlAFgkWJgL2x4HXcWLBQwispCk81rERvVugOw3EhgE0A10Bvhdh2?= =?us-ascii?Q?CILwaBqMZIp3zOiu//AMgqakyfjsf9avbm1qHgYTOFPXiVuSmV4GFa0a20Lp?= =?us-ascii?Q?o72GW1WxtWTdWP56fbLP1zOKclm21LcCN6d1yXwYACd+UsMMnbFNOc6Bkirx?= =?us-ascii?Q?BqNCdaxCcF3CUN3D03ae/4HqP6RPxh5l9wUPnuJPtH0N7QRxHMXEwjdS4ujV?= =?us-ascii?Q?CDwshQR7cYg0ltZb9bmVPaif9z2aPTqpjvZ+igiHo1oGjmHyPCdqFRAdSvqD?= =?us-ascii?Q?Xdo7VEGk2HIJPQulCxTm2I4977LihbO4HWd5TaFEdJpLMqJjKScAhAVDiOGa?= =?us-ascii?Q?+pEWDtn5ugve7ca5kFqjmbc2LSy3e5MoHj0wU2vj8qEcJsvIZAApxMWZ2F/S?= =?us-ascii?Q?4WeEcxEZXnayqY7ZjpJ0x2pu8bCQrI0LFO2BRMuzCqi3aStfmVoKFTu3EyPE?= =?us-ascii?Q?NyN86TQK5Ivi+yh/Ukr8ipAjCcCxSeY2rrchftw7GjHNCEz/BoPeoi6ifsbD?= =?us-ascii?Q?o3C5XPQAlBWAE+soJKMg/0WEBmvAufSjWd/yLVDfAo79cqiW32ybjBkl6HF3?= =?us-ascii?Q?ffokWq5+6A0i8B0bygzEYroeHKbBbUeLPA6CBQFa73T24YDXgt3n5g/LfsB/?= =?us-ascii?Q?WKEjuMXMMBYx44nhSUpHe8Tpaf13XMlLX9Y1JFmBfYtygS?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB157; 6:zhP19qtBJaAPFn6FKlCR3UOqK3Lit8R3oEuDl3rQPWJ?= =?us-ascii?Q?ehglNLPIdFLjoCtlPHm+eor4evkt0HeN7VK8hQRPfkpoRm+1ZhWBAq0ewr5R?= =?us-ascii?Q?Q4w83y4DzxU11mfgTw0uVAHmt0LW3MUA9SDCeca6s3X965XFa+7stIBVYFRe?= =?us-ascii?Q?jWLw8CMevRwpVMZYFMZZMbW7HzQ87VN882t4IMNCZbkTEqeL0sLQMeN+0gHO?= =?us-ascii?Q?q/vp4Sw6IzyCNrnXyuBKYSNrrNmzmg+s6SZ3FVS55fVKbK0a4GKbhcQd5Ktq?= =?us-ascii?Q?NvgJG5Pf7pSiquih+Nly8+0OtZlCPa2fQ3TwH9HgVe3wxcF6puI6EIYuidvs?= =?us-ascii?Q?5DS0OVGo/N8Iy3day7rpNwk4xFOEyxgnsGyii9XuppLTq3CciVj8s/LhrWoj?= =?us-ascii?Q?vnxaq1MfVflRj3bevMuLXWIVsjeAIZ2FTA8wiN4fGWQVM6Irvko5JyiAo8rG?= =?us-ascii?Q?FcqlBpMfo5YgMlW8Nx7C9OUY1bX3TzP+oy/AxjdaR1w74am0RF6YfBvMJ/9R?= =?us-ascii?Q?P4mrI2ADzwW2UHn+nHSXg/gVGPOXVfaMqifW6PobRJUxvsaeIHpI32YT0A4W?= =?us-ascii?Q?PiNAdYWjWhW53XWpZo9084KUT1b8ztxXp3Ne/vjbuK1l6yxQGLpG0H6yQs2e?= =?us-ascii?Q?8ntCL+nD/BDimYLMajXb7s1R/m7EmZisjs0ACI++ZbcKbtwdchTkkGhiuCBf?= =?us-ascii?Q?GUNH7HqaVqUxQ0aL4I7LDF8aBwu8TZQB00hllSy5JJxAasKTe4VtfLRn56qX?= =?us-ascii?Q?l3hETbIdxQv7QjnXXWlp0T3HjDSeg8RxBE0kJB+Y56IxZ4ryChW0EzhU40bo?= =?us-ascii?Q?i842U8JUWbnhSprvtNnm7f4UpXjRRwbF/8Rz7AS+/eEH5uS4cKI8sndFLGke?= =?us-ascii?Q?9Umj5zfV2JMsc2yWh2oBSOigXihybQYXnoto4GnkUIEmfvJhVKOXZxrIS/0K?= =?us-ascii?Q?SgpQlHMJGhdfarBQZPxVWsl7dycjg5y04+DPUDc3O1yHEHS4Kppg2SPQOMvx?= =?us-ascii?Q?xYZxxYsVfwb7fJhO6W5Jr?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB157; 5:sAio6kLor8uk5oWDdlMJoIovLziV4ZeWHHhEJuIJ2GJqymiqmx0qkg1jUvnqmLATBIw+ruMO3NpDzVxBrzB/DCYrUpL6MPyQuN12T+DxifDQQdxI5dmj8sMTv9+2piE4C4VxASrtUZmLu2BvRLE5dCR0wZ7R9z56mBSBAurgSZ7m4u1qIA6n/p696IaEHLYQIjRxA0EeGq9/E2xzhfm84n9HSAfQjBiRZ+QkfDFWd8mvKZIhK+mLIDa1hW8oW0mwm47/HTabiPGjkpCcTWuQAvByrCIZ93MhaaT2YgkVlcfhl33b0/dsQaw9xdrZA9MmoyvrFNsMjjHQen6baHVn4ucRCv6TfKzAw8yDwak6gXVHLISYTa2HNOAcEjTC9iRWuWiPHd49SWQtV9wAzRAGPFeUEwKjhxGEZ+NpJ2v5QJ0opHxP/qoYAdUGjW9CaTx5GUJ4znYzKMu10S9I8SU0pZeFM4q5S2Wsnv+EB5or4ulVcm6yWo4XzetAp0PsycvS; 24:hRFsGSfB0NDXaHMMd2xdjcXS8aavjaGYBI/wNV/+fTZiAc6GtYFEOYeAWz2JzRH+GSYPG9VLFL0VvKr+ql1G17XkfoDwvgZhCfflQLcKS24= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB157; 7:JKNfYFojmkJI4lkeGhaWtd80/hFKscy8n4Evd3S0Mzp5uw+8Pm6RwYOC87pp8SfRfh5lkal4U5xXk1+CJ+ZlgT5+JQmFk2WamJLg3IhnQDTFDKVQRfz3WyZRUy0NUSzV/2u7gQBCkAiDUfVuWDTd83II9av3sHKQpsSQ2nZX3RZmUHhGzu8FHj8TWCQPTzYxdsCsfEkJMPzQcxDB7cHDqXwcc8LWGAgID+Ez5e/l0wLMRK0goi+xZgSU/ZxJ2FFKBA7IV15lGMy3ww+0CdZsaUPeaNmTkgM7GFi+mZ8A8vdal/XilBjYWj1lbud1h9IAacIUD9wJSL7lLFbFzziYP/SnpIkw2IJBpnTCJo1tbA6Um7+p7kDgdYMdXdooRzPAqhCLAya5y66//vo6O5qonc4TaLHofqbH7YfbejKVLNIGoPoip70J1j4f7RenrCk5RQhLOKe/J5nynbirMF9Rupg2vhzC26j2qYHKXU+Mm42/Ssl3v15PZ12HCNgccwluWTKGsyVumN6a6OMP7W3BLCiNoeOwXxT7Koek1n0PbGOJscfsMZU/5NUrkz0iYpLVhe0ZoI546/QDnO5yCfzFMcb+OybUM3QN+xdolwp35x6XNI65eA5KYkqpeuGy/nrq/WHhnE+0NHBg9n/WX+RAOo6WIdC3NumjFiM1js4a6/HTJq4J4Aq3RarDqFIGTexxqhxOvVtR7Nk8QBR8u1z7BCG15U40If630orH5Y8npTsyCxHF8qmbMEMNO0KrgzMK6UzWsg/bq79kmWomwqTrP/vbTln/XNTV3ToO03Wt0Ac= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Aug 2017 20:28:32.1679 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB157 Archived-At: Subject: Re: [Curdle] Call to adopt draft-ietf-curdle-rc4-die-die-die X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 07 Aug 2017 20:28:38 -0000 I believe adoption of this draft in the Curdle WG is in scope. It would be good to obsolete RC4 as soon as possible. -- Mark From nobody Mon Aug 7 18:40:01 2017 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 DEA31124B09 for ; Mon, 7 Aug 2017 18:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zgHTj5_izyfs for ; Mon, 7 Aug 2017 18:39:56 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 14E77131D71 for ; Mon, 7 Aug 2017 18:39:55 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id o85so8670473lff.3 for ; Mon, 07 Aug 2017 18:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mtTNwhDeGwF8DSkiVEkCSt8Q+BJOJpa/ndgcBb/EOCk=; b=TctiUYtNBGoI1FtbyF2WsdZD6Mc/Brr4hMO3jmmWRvYVri2YM5GLI2f7FonXLMh2nE tn1Oft67/LgcYW7QeoNkO1VgjK33/rNAowf+FwyfQWHgU6R83NH201Ws1Cr2a2ViGyEb cdT1D4oQUhT5Yb3QRRcOXvYIhDHFoWsQhWR4AliyC8yMqRUakMzgnKLPu1Hn3MoDbwgj qTVhFwnMNex+ZGxcDMDZw5z/OgzG9w7VBu6nqDGtAefzOjlpvyCnWUAGb3uddQ2e3khd Ru+yxm8MQtnD33hyX2w341HnwP0D0ZkChODu2O2LeTSf+sTOzWVvWUE0q2RxojTOOKM7 6voQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mtTNwhDeGwF8DSkiVEkCSt8Q+BJOJpa/ndgcBb/EOCk=; b=LfiZjsi7vWVzvspdeyxH60MGAl+IJlEfDgyFk/q1hGB4GxA+d5x1PUL4+jmtX98ELS 7via4jHTmx0jrQQtFMSbXEiKiIwoFOgKrHytNflrBiob8svxOO/5SjyaNj8TE8MgAHKy 9fRlryd+CwTWbbJP20JFGBXeg4VrNaqlpanKa3TaWT3qM1scU4CIjb1r+4yq+1nxIsDd HeNKNA8lhqyRuX6txGluKepcSHwYDb8mCsoEg0/6Nc1+ogzwAuPyC35eGMg7tlqSRnIi oDycZ+KY7of3Q6J5Bf8wGcPzM9enoe49NP9EtBfx7iRoIycEDT3NCcebHFZfvxbZdWkP wiwA== X-Gm-Message-State: AHYfb5guxxz/URr3xTYrm7B9AzgfxLa7Dg1Zq1RoxzQ7zoh+U/KyCYnl d5c51TY2phTGKz1SSVb4MuPX0UvVQg== X-Received: by 10.46.77.84 with SMTP id a81mr802045ljb.24.1502156394112; Mon, 07 Aug 2017 18:39:54 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.18 with HTTP; Mon, 7 Aug 2017 18:39:53 -0700 (PDT) In-Reply-To: <74760.1502137709@eng-mail01.juniper.net> References: <74760.1502137709@eng-mail01.juniper.net> From: Daniel Migault Date: Mon, 7 Aug 2017 21:39:53 -0400 X-Google-Sender-Auth: 84wSQyNHWxPn7Ilo1XjPcBqS-2s Message-ID: To: "Mark D. Baushke" Cc: "Salz, Rich" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1aac3644ac4c0556340a19" Archived-At: Subject: Re: [Curdle] Call to adopt draft-ietf-curdle-rc4-die-die-die X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 08 Aug 2017 01:39:59 -0000 --94eb2c1aac3644ac4c0556340a19 Content-Type: text/plain; charset="UTF-8" I am also in favor of adopting the draft Yours, Daniel On Mon, Aug 7, 2017 at 4:28 PM, Mark D. Baushke wrote: > I believe adoption of this draft in the Curdle WG is in scope. > > It would be good to obsolete RC4 as soon as possible. > > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --94eb2c1aac3644ac4c0556340a19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am also in favor of adopting the draft
Yours,
Daniel

On Mon, Aug 7, 2017 at 4:28 PM, Mark D. Baushke <mdb@junip= er.net> wrote:
I believe ad= option of this draft in the Curdle WG is in scope.

It would be good to obsolete RC4 as soon as possible.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

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

--94eb2c1aac3644ac4c0556340a19-- From nobody Tue Aug 8 00:25:29 2017 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 23F7A132063 for ; Tue, 8 Aug 2017 00:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 pD-50U2mUxoL for ; Tue, 8 Aug 2017 00:25:26 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 BC4081270B4 for ; Tue, 8 Aug 2017 00:25:26 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id x3so25160609oia.1 for ; Tue, 08 Aug 2017 00:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Nja+GwDbB3RvD1pxxVPSLYguPkRIjASEaNDkfow5MJ0=; b=wJyJ0egbGjlegnV5zEre9my/tzyM9j4apVwiU/m2kqk1fjzv/IjOMyE7HkDcNdSbtK bjKq9x9Wj+n3ln2p51bZrdcqe/SYFZLWt0//TQZPWWcEgfBxS1P3g9e1C0sGd+hudGus lqcuoPXwPLaMirbc0I6jFy2vfPyep3mQPC1dDIK4BwFTQCqWZpiNv9rPcRI/7oyE6qlH REUCjYgaljYaW07nXuCXqc/9/SjNPYu8ZZjx29vOLqa5lhJw2WfPZLJfxJgF/MsCxrEC BUyS8Fiia9D2SJnM/OxB70DUShg/+qoLSwMqf/wKZeyx9h0QmCGWg+NByw/h4sFKTbaf 2TlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Nja+GwDbB3RvD1pxxVPSLYguPkRIjASEaNDkfow5MJ0=; b=Jml6apBMJlxSMRNr/NPsZVTigQ2VJ/9yeu1xp+HhOI4CUT8y1vyEEAqpk4o5OC5/lQ gGsHdjpfucugvw1WhAeKUKNu6D1/mYLSyYZcY3CtFWEytau26OKbAzp25Cfea9FlrV24 q3t/Xw2pGHe/Trfne99U3Mz1jIbPllDrMWvHDLqHkFJiR0nwliuxRYqUiBGmcZWmplF2 PWbRJhM1VD5Zl5Xn/jjoWxbjBfdWhtBF22zguPxeVKzePiNWbbzl/MOfH93uSm1NZh4Q MoqJCauddAVt2BD4XJhf/H8WyV8NvtP/FYk5vW0ZSkR/A0SPG9WXPEMwE0nPB6XCtY0Q kggg== X-Gm-Message-State: AHYfb5iYjzK/HoeqYea23B6BGieF2UtD76uky8SbFBGXjM+3kYnzO9pK JklvMUOnZkk50s3js9FcqJTREmLklz6x X-Received: by 10.202.236.209 with SMTP id k200mr3321074oih.120.1502177125893; Tue, 08 Aug 2017 00:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.139.137 with HTTP; Tue, 8 Aug 2017 00:25:25 -0700 (PDT) In-Reply-To: References: <74760.1502137709@eng-mail01.juniper.net> From: Loganaden Velvindron Date: Tue, 8 Aug 2017 11:25:25 +0400 Message-ID: To: Daniel Migault Cc: "Mark D. Baushke" , "Salz, Rich" , "curdle@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Call to adopt draft-ietf-curdle-rc4-die-die-die X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 08 Aug 2017 07:25:28 -0000 On Tue, Aug 8, 2017 at 5:39 AM, Daniel Migault wrote: > I am also in favor of adopting the draft > Yours, > Daniel > > On Mon, Aug 7, 2017 at 4:28 PM, Mark D. Baushke wrote: >> >> I believe adoption of this draft in the Curdle WG is in scope. >> >> It would be good to obsolete RC4 as soon as possible. >> Indeed. I also support adoption of this draft. From nobody Tue Aug 8 07:04:21 2017 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 8F91713254F; Tue, 8 Aug 2017 07:04:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150220105256.12388.15154974208738613511@ietfa.amsl.com> Date: Tue, 08 Aug 2017 07:04:12 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rc4-die-die-die-02.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 08 Aug 2017 14:04:12 -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 WG of the IETF. Title : Deprecating RC4 in all IETF Protocols Author : Luis Camara Filename : draft-ietf-curdle-rc4-die-die-die-02.txt Pages : 8 Date : 2017-08-08 Abstract: RC4 is extremely weak as shown by RFC 6649 and RFC 7457, is prohibited in TLS by RFC 7465, is prohibited in Kerberos by RFC xxxx and it needs to be prohibited in all IETF protocols. This document obsoletes RFC 4345 "Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol" (note Arcfour and RC4 are synonymous). RFC 3501, RFC 4253, RFC 6649 and RFC 6733 are updated to note the deprecation of RC4 in all IETF protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rc4-die-die-die-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rc4-die-die-die-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rc4-die-die-die-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 8 07:11:58 2017 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 7A5541325BD for ; Tue, 8 Aug 2017 07:11:57 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 9CxDWghxs3kD for ; Tue, 8 Aug 2017 07:11:55 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACC813235B for ; Tue, 8 Aug 2017 07:11:55 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v78E7jNg011354; Tue, 8 Aug 2017 15:11:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=rCeuqUnzhIO/Ubxbz7nvYvLhrA08GR9kT6K/CkxqgZc=; b=HLltZrnpAnvj/TxmqX6gJvMn5PQHoZxweRZhzZeJXbh6+YBFQSbRcYtGWAWuo5BLQ10P ta/J0Yhm6JL7gXLsWXGARj9pRhtlSw5BnbNzwRb+pGsmgDhDhi8nBweL42vt7qBrPgIy 3worm8pD+/7m7vJ244DGQAuRZCAP0FtT0AcphliSZKRzeycCQjVgbSfCcqlbAGmL3IyW L46w9XV+aLQBnUnwxXDLv0WOdJgCLpXGuAC1djYkCXzVDplX/+4qaSFFzXB6+1J8fj4q AF2WnYDdT7ZpbS5KSZnfZxr5AnEAS0QrunMC3aebly3cSWZ3dW6jF1yd5hm2fTE8nHlt uQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2c559s2kmg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Aug 2017 15:11:55 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v78E6EXV001355; Tue, 8 Aug 2017 10:11:54 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c59bubdey-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 08 Aug 2017 10:11:54 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 8 Aug 2017 10:11:53 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Tue, 8 Aug 2017 10:11:53 -0400 From: "Short, Todd" To: "curdle@ietf.org" CC: "Salz, Rich" , "Mark D. Baushke" Thread-Topic: [Curdle] Call to adopt draft-ietf-curdle-rc4-die-die-die Thread-Index: AdMPumDzGEm1LxOzQIqgK6FraZaC1wAAWJAcABM/yIAADBFPgAAOMfIA Date: Tue, 8 Aug 2017 14:11:52 +0000 Message-ID: <1ED8B7E6-E173-438E-B4AD-7EF8FEE392D4@akamai.com> References: <74760.1502137709@eng-mail01.juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.179] Content-Type: multipart/alternative; boundary="_000_1ED8B7E6E173438EB4AD7EF8FEE392D4akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-08_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708080226 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-08_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708080224 Archived-At: Subject: Re: [Curdle] Call to adopt draft-ietf-curdle-rc4-die-die-die X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 08 Aug 2017 14:11:57 -0000 --_000_1ED8B7E6E173438EB4AD7EF8FEE392D4akamaicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I support adoption of this draft. -- -Todd Short // tshort@akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 8, 2017, at 3:25 AM, Loganaden Velvindron > wrote: On Tue, Aug 8, 2017 at 5:39 AM, Daniel Migault > wrote: I am also in favor of adopting the draft Yours, Daniel On Mon, Aug 7, 2017 at 4:28 PM, Mark D. Baushke > wrote: I believe adoption of this draft in the Curdle WG is in scope. It would be good to obsolete RC4 as soon as possible. Indeed. I also support adoption of this draft. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle --_000_1ED8B7E6E173438EB4AD7EF8FEE392D4akamaicom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable +1 I support adoption of this draft.
--
-Todd Short
// tshort@a= kamai.com
// "One if by land, two if by sea, three if by the Int= ernet."

On Aug 8, 2017, at 3:25 AM, Loganaden Velvindron <logan@hackers.mu> wrote:
On Tue, Aug 8, 2017 at 5:39 AM, Daniel Migault
<daniel.migaul= t@ericsson.com> wrote:
I am also in favor of adopting the dra= ft
Yours,
Daniel

On Mon, Aug 7, 2017 at 4:28 PM, Mark D. Baushke <mdb@juniper.net> wrote:

I believe adoption of this draft in the Curdle WG is in scope.

It would be good to obsolete RC4 as soon as possible.


Indeed. I also support adoption of this draft.

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

--_000_1ED8B7E6E173438EB4AD7EF8FEE392D4akamaicom_-- From nobody Thu Aug 10 20:34:00 2017 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 91999131D21 for ; Thu, 10 Aug 2017 20:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 P-CWyzEI7RNU for ; Thu, 10 Aug 2017 20:33:58 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D4A131D9F for ; Thu, 10 Aug 2017 20:33:57 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id g131so23723785oic.3 for ; Thu, 10 Aug 2017 20:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y0yujhtCXnOpFtKGVi9Hr5VIW0ZIy4DLev39BBYsvZI=; b=b13ftjyqdyIBEPkWmHgC4bBKuxI31RAz5E6rtT40QRLbbkzHd1oag+tslORzIpNBfm Q8FB3oDcum1ylILBwnB8+FaM3FQap4sJM9XSO+/C82iRi8CUae7JaIiNo+YFDCnPPmlv 1G8IVgE4YbTsCjbTzRW6fZRCcMNQrAaLqv2aPJMdSKDAJIii51oB+hw1spZJu7NSzRqF KrqYaJX5Bl/94uEL7Tn8t1zgyIrGprjSc5HuksQNmYZblDsJJlWQfj4pkJoNg3LZWNqp C4zJu1SBwPzxJ/SEm8sUxfkpGbDpgcVufkBLe/39aVPNl20CkMqFoWNoQ0qXJZEMYLml I8Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y0yujhtCXnOpFtKGVi9Hr5VIW0ZIy4DLev39BBYsvZI=; b=BKm8MgEm7pEA51ToB9W50EredInT1ePnPAnPvrsMZSilc75eYZUviC9+s/qF0SXzKq C0tDUUTlnxs2JX8Uj7i0EZsMN8bxjeWeDfGY/Jhb8w0sgE9EmoVw9pxktC7J2ktLYg/K FuGlbm7YM/2ZSe497btJ13iiDekJ7a2V9OWMwjBpj/Z1m/djEnta9LYqCe5zwqdNouXd MdILXK+uQY9o8COxyluDhLQw+O0Iktcsrabdx9AbP1UUFJF0apJX/lFsr2EtdF7UZofj ZnLBFtPdqyXohDQamYsK6q3c6gysi9sy71iEvMhOAv/GpB7ac6rkPgXDtqKnPaKeGjRd zHhQ== X-Gm-Message-State: AIVw110F7iF99SgVhqiaY09YloYc4ZJI925P6y2/1VBAyjqWysjhWfEW 78ApLgCZEqnydnzxaNouDwlPdWpRf5I1 X-Received: by 10.202.98.137 with SMTP id w131mr16114052oib.177.1502422437291; Thu, 10 Aug 2017 20:33:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.139.137 with HTTP; Thu, 10 Aug 2017 20:33:56 -0700 (PDT) In-Reply-To: References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> From: Loganaden Velvindron Date: Fri, 11 Aug 2017 07:33:56 +0400 Message-ID: To: Daniel Migault Cc: curdle Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 03:34:00 -0000 On Mon, Aug 7, 2017 at 8:29 PM, Daniel Migault wrote: > Hi, > > Thank you for updating the draft. I am wondering if there are any reason for > not having ed448 in the draft, and if not I would suggest we extend the > draft to ed448 as well. > Dear Daniel, ED448 is not currently a target for implementations like OpenSSH. From nobody Fri Aug 11 06:07:52 2017 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 A1E6513218E for ; Fri, 11 Aug 2017 06:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-iz47z2gIE8 for ; Fri, 11 Aug 2017 06:07:48 -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 8CE721288B8 for ; Fri, 11 Aug 2017 06:07:48 -0700 (PDT) X-AuditID: c618062d-b93ff70000004f0a-d8-598dc2d7f9c7 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AE.23.20234.7D2CD895; Fri, 11 Aug 2017 16:44:40 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0352.000; Fri, 11 Aug 2017 09:07:46 -0400 From: Daniel Migault To: Loganaden Velvindron CC: curdle Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt Thread-Index: AQHTD4cMvMNFXD1zWkeOk6zr6uM+kKJ5WIwAgAVwxgCAAFy5cA== Date: Fri, 11 Aug 2017 13:07:46 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> 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.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPuO6NQ72RBgceMlpsXTiL2eLrxPms Dkwee7ctYvVYsuQnUwBTFJdNSmpOZllqkb5dAlfG1mNdLAXnOCo+r57G2sC4gaOLkZNDQsBE 4vzzuYxdjFwcQgJHGSWeHz/HDuEsZ5ToX36NHaSKTcBIou1QP5DNwSEioC3Rd7AAJMwsICPR 9vMTE0hYWMBN4sA7H4gKd4lFc/MgTCeJw2tKQIpZBFQlZu7uYgaxeQV8JQ5/3gi19RKjxMYn u5lAEpwCgRLde76ygNiMAmIS30+tYYLYJC5x68l8JoiTBSSW7DnPDGGLSrx8/I8VwlaSmPP6 GjPIXmYBTYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMorOQTJ2F0DELSccsJB0LGFlWMXKUFhfk 5KYbGWxiBEbBMQk23R2M96d7HmIU4GBU4uGt2dEbKcSaWFZcmXuIUYKDWUmE9+sqoBBvSmJl VWpRfnxRaU5q8SFGaQ4WJXHeCecvRAgJpCeWpGanphakFsFkmTg4pRoYNxulPdPgOCyY9K/h yYUNjk8EVbesLow+sn8ZT3L7ek55GwG7TBYZ4U7FcLc9/HW6si0/Sp1f7VnXvpVvdti/QhmJ t1GL9RKv9fB1pgrySl46FC7wKGdF78l/yRHxfJ6Fi0+rfdE1u8FV1n4ySZC780FeXXjihsTA OD/NJ3eUJIp4donLRSmxFGckGmoxFxUnAgB+XjA4fgIAAA== Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 13:07:51 -0000 QXJlIHRoZXJlIGFueSByZWFzb25zIHRoYXQgd291bGQgcHJldmVudCB1cyB0byBzcGVjaWZ5IGl0 ID8gVGhpcyB3b3VsZCBkb2N1bWVudCBob3cgdG8gaW1wbGVtZW50IGl0IG9uIE9wZW5zc2ggb3Ig b3RoZXIgaW1wbGVtZW50YXRpb24uIA0KWW91cnMsIA0KRGFuaWVsDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBMb2dhbmFkZW4gVmVsdmluZHJvbiBbbWFpbHRvOmxvZ2FuQGhh Y2tlcnMubXVdIA0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxMCwgMjAxNyAxMTozNCBQTQ0KVG86 IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmljc3Nvbi5jb20+DQpDYzogY3VyZGxl IDxjdXJkbGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0N1cmRsZV0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jdXJkbGUtc3NoLWVkMjU1MTktMDEudHh0DQoNCk9uIE1vbiwgQXVnIDcsIDIwMTcg YXQgODoyOSBQTSwgRGFuaWVsIE1pZ2F1bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT4g d3JvdGU6DQo+IEhpLA0KPg0KPiBUaGFuayB5b3UgZm9yIHVwZGF0aW5nIHRoZSBkcmFmdC4gSSBh bSB3b25kZXJpbmcgaWYgdGhlcmUgYXJlIGFueSANCj4gcmVhc29uIGZvciBub3QgaGF2aW5nIGVk NDQ4IGluIHRoZSBkcmFmdCwgYW5kIGlmIG5vdCBJIHdvdWxkIHN1Z2dlc3QgDQo+IHdlIGV4dGVu ZCB0aGUgZHJhZnQgdG8gZWQ0NDggYXMgd2VsbC4NCj4NCg0KRGVhciBEYW5pZWwsDQoNCkVENDQ4 IGlzIG5vdCBjdXJyZW50bHkgYSB0YXJnZXQgZm9yIGltcGxlbWVudGF0aW9ucyBsaWtlIE9wZW5T U0guDQo= From nobody Fri Aug 11 09:02:47 2017 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 243FB1321C4 for ; Fri, 11 Aug 2017 09:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TdfPFnSLy20 for ; Fri, 11 Aug 2017 09:02:44 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0127.outbound.protection.outlook.com [104.47.36.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE9F1321A2 for ; Fri, 11 Aug 2017 09:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=y2Q5IXlcFbW35cMfl7YECDs0U8SwRwPe4SoyEdpFJLs=; b=cuX5wc4p7G53WwfiMUFSbyHNXerBj67ge+iHdfwK+OIo2AwJ3trmB6vc36S47mZgt2WbYZq7zWl1fjug1LdJNqFHryGnBCRplOprHPZY7jgBn6wbLxwTNTTgp4uypmqog52lUUBVuiM5EhZ1JnzaGXfyKvM+fjZDhrsyiGSnkjU= Received: from CO2PR05CA0077.namprd05.prod.outlook.com (10.166.88.173) by BN3PR05MB2513.namprd05.prod.outlook.com (10.167.3.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1320.10; Fri, 11 Aug 2017 16:02:42 +0000 Received: from CO1NAM05FT036.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::200) by CO2PR05CA0077.outlook.office365.com (2603:10b6:102:2::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1341.9 via Frontend Transport; Fri, 11 Aug 2017 16:02:42 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT036.mail.protection.outlook.com (10.152.96.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1304.16 via Frontend Transport; Fri, 11 Aug 2017 16:02:41 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Aug 2017 09:02:29 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v7BG2RM0021871; Fri, 11 Aug 2017 09:02:27 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 49D441141B; Fri, 11 Aug 2017 09:02:25 -0700 (PDT) To: Daniel Migault CC: Loganaden Velvindron , curdle In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> Comments: In-reply-to: Daniel Migault message dated "Fri, 11 Aug 2017 13:07:46 -0000." From: "Mark D. Baushke" Date: Fri, 11 Aug 2017 09:02:25 -0700 Message-ID: <4054.1502467345@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(189002)(199003)(5660300001)(7126002)(105596002)(106466001)(4743002)(54356999)(4326008)(50986999)(76176999)(5003940100001)(53416004)(558084003)(76506005)(7696004)(117636001)(6392003)(53936002)(229853002)(77096006)(55016002)(2810700001)(7846003)(54906002)(356003)(626005)(93886004)(6916009)(110136004)(6246003)(6266002)(230783001)(478600001)(47776003)(48376002)(68736007)(2950100002)(2906002)(50466002)(97876018)(69596002)(305945005)(81156014)(81166006)(8676002)(189998001)(8936002)(97736004)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2513; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT036; 1:3oYV0Vk/6msS1wao+iQ3wpGkB9qtFjuno/1s6G7OWqBVGknH46O+VzcqHEDBnMz4d6FPmVnHwIy8gpRMz8XV2cHfgOxJBGmXNjZ6iymugK/SqidLVBdYkCg9OvhGZBGl5D/aLsNuLesujIChHJ8uOlve8DWwKAvCoLGt5hQI4NMvwFykQSFAl6NcfKmpn+CiRzTWDt7sOBAlVgxZQMy3HiOe798zQ9HalWxZKnGK39jmlFJVt1ePE+VKsgVZleBda3IiiCwKKlOJbH6tbtNHY4AjToHSQzikKE1IdZ0leEkIZ7c9dSQZB+Xhrofxha/2782hd/S+aqRFKYkw8nS43LYfrNuJkT3r/a5tex2wutJ2wNx/Egwo/KkV2jgv2EBb41ZYWdC/KUYnVT8QgUbH1VmdkYx6TogqOaImF6kdp1sjygv93JPYlSASlZ3BDdeIlcnoyFkMdrdv4dFEFeXJRQE/eCgRHXSnihN1lRCckjJ4eJedpnhrIr5023YwMcUHEHKg9q6AmKNYZFX+cJyBQOV5zRQIph7PjmNt0AyXMuXmfTvvAiqkuzBvYYMlZunXY0JzbXnx5gAEcGQLnREmC1GmaRjencUKgSeXShkPZPE0HvAZgE5JqhfZHys7N7J0J3towylb9mlk80y7Jh2bFYnCq6UqMc0uE0bBCPzC8u+u5mVfgc2id7EaD2xUfN6QB1YheySNxPSeQg82Gw/z5zxpmg/7yDlpgZBD+qT5KPVBHoAeaheO/aZAl9nTKIBhHqXC7kjh7k7zjD3/EYyRmaq0f3WJ7qGM9ofSUr5tU1V6Hbdo77PJvHrRW3mwGsB7f+1qLuRNirpeov8vgXVX6/cvMjXNMKbLliHXg4SeFR8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1141b628-8a73-4a75-907e-08d4e0d265ea X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2513; 3:Mv8s8BipuriiZypYBO/YtuAZZqUfzFrEOCklO6yYkhqsaQP6/mkT2li/ZovqTai9uJqiRDWlDMJUbyXU9UskgkTFf7estUJOoaYPWjzFDzt7hiBRb9iOm2+6YpeahMG5/RM/wF6bAhOxmplqnIAaNYQ5SeQLCxrAGKTvar5qnNRLV1DLmibrFgkTs4hUp35e42+1HaWtF4VYUDnKqCrKR5vwAA0IVKf0dn55zJreXd3/8pMtfqgZEwbrMA0rMnBN0bMSaJnuPu/NfgHk37qF6KwZtGBLxOhHJWXzcCXsaYijG2Au55+Z5j0Ty3ST3qyizHdAkCIqw53peaDt519iL489RUsZLJAnVYvIBqG21+k=; 25:/UspuOnammy1/XgTTfDJ23Vc5EXvQHoJPF8h1cJYxKuF+iRQJNeTAy75siB1krFc1x4h2+0+Jx3BOfcRta4jiGLmpnfivABlUU3c4fn63dPCUZH6oEP8FWAPCgp8sV5fTu6Qqo8vnFOdzjbIrr2JJWu45J9cPZiwEW/6bZyfZOUe2Uon0f9Ag8YS/2tS0LnUpoxAWknsi/baP37u/qqlREBmtZ5fwYvZNzIjrwENbHKw8c8RFrRm1u3qrVsqVxcZJFt0VFrNGnlfQJpq3LkGumSk2IDw9gQ4OJRXdQQ1F7yTql4k5mTWFKS0lN8PTy9Vvzh0M41VMaJAJfVlyjjkpw== X-MS-TrafficTypeDiagnostic: BN3PR05MB2513: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2513; 31:HIAlbzgoe4ssi4ae652PrZ0pSLmqSLNaq2oj+cc8pcl2XGA/vITfFrtGwPHGFq8BE2goguaVKxgs7f7SI11L+n6qP5mV/AT7XD6WeyKIQzGyFmAouicQMj27eW5gQwkxQ84lIbJA95NXejqm5WhOplsWwHkMyGz8bSv82Z2oS1W7HezAE71mzKTeywqpWkEhesManRdE+KF5mrnsRAzAR0+YHkjHK1c6KHmSA/c3UwI=; 20:dJQa/2VGTlckPEwtuU+lkA1RGOEz7x4QumzXCIV5QT3ATRrwH+g/ERWyNl2EsDtxbN3I1Auk45/WUr5y4+BAColwZG9sWHB9I2p9lWsvoHZzJf2G83S7IBUBDPveFvNp59vkP/3haLfqCgwjH4PBc6McdLTWrPXR3LrvRlQrTgicy1yg5kwZ0vf6F20/CG/5O4JQjOBcE81dQRRLtzN+G5ahX5GkctQjozlaXEYbnvhIg2ZkP2qQk31SOgBIN/c1z78vllIjbY3JimsgeZUoTcSEimR8z/1HoU405BfKYVALhivQuI8oK0YmYGNL1xHWAv990slARMtlphqgxLO/32nI73pzldHkewcTAsXxP/F0p3CZZoNjUw7FHC+CUcmmpcXzuFwkKZNcc2lPDhrhkAc0B1WoeIn3MOm8/yZXVBPOGV1SHLpAC55EH1ezBiGFkH0Zd23tPvKvqIcO/IgE/GGe1q6BBLpwWLeiWqStU81mcOi1NmvsgLrAz41bkUnv X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(13016025)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2513; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2513; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2513; 4:VZ1p74Pbka/HwIcCygHk0XnwWc7qUwwIBD7SuhWCSt2kvGGFmbhrBHOZqMZyZ4/+JuERQT8c/RD6twgYaXTMeU9aDKa4xeo+mNCe9UkzGbDJvMcpKX0UIiXl9VqtSX0+Pz0Ruqr844OuyZM3ehs0coemycRY0G/Wo5DDPDIFYHqIfYw7ET1paxuJeer6tIBacpk/THpl7+hzq9Yh3ftsZ2oJT8MvAnKz4AC5j7X4FzcsnYSQLu7x8U2iDULLQGLc X-Forefront-PRVS: 03965EFC76 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2513; 23:PsOVuC6vIL337T2DoEJETzow2yjibOheqhjksBYLZ?= =?us-ascii?Q?3PRkb/8+ab/mdZgF8gdVpseKm/HeJmfgzOsjKuIvClP9jnDv9K79FJUocC8f?= =?us-ascii?Q?gzZiC8T1wvsAQeQsVDnwVCpn1uSEAmheYCW22p2vbwms7Ntslzc0MzFjCwRf?= =?us-ascii?Q?mCc553PpUoUCM3YC9arhKmsY9oQGOiNM/uS2xgH6XXDhyCRJDSL/cl66rY/g?= =?us-ascii?Q?r49KI1iO4b3bEwuYE68aqj7SrJMecCLbPRg37p1Y94b0Q//hUdGqA2qRBGQY?= =?us-ascii?Q?qD1au14QKsHkmb0Hb9vzA4YCbPmmc9bOOhRzYgZUXlH4RE/N2w+zbplAPgM0?= =?us-ascii?Q?tkhWi3KUCJ/YYwR9POv92xdsqbtE/nXZvCdA5ZUZ1H1NOZdJrgZoP1/s8/H3?= =?us-ascii?Q?2tIZu2KZUP/HEAAdlRIAZs7WAdP7ijEu1ZU5zzglUYYzxTjn1jJmK6LDtBt3?= =?us-ascii?Q?bnkJ9rLEV+laVRJztI46e3c47eZ9pWhEOMDSsXlL7NeXpqwRk2vPE8zwK4Wt?= =?us-ascii?Q?A2Z598m0k/gqCW0QLyIwaJqLH7T1LvYrG4dQInzpZRzELtHrHi7mCvw5xojS?= =?us-ascii?Q?t6/BN4pFD5NjpF3rsQ+5sNv13fKaUCBq1H/tqZJuweQlXuGTcF2XdepCJpP0?= =?us-ascii?Q?Xz4zYPKmkoDBtZ4CermHrFC1b+p5pQBN6dKdejhiUd+lqRbr2SxemAHrg7YJ?= =?us-ascii?Q?/bB8cZc64ZuuiVRNLA7udutd23gdk6v/Oh78AdifzH6O4x3KKPnyHoOOa78t?= =?us-ascii?Q?lzljol9SaU4q57T5rMa/Nf4tzgBANohhMGCnVjuGDWQv9La8JimzwqPgoi4X?= =?us-ascii?Q?CK88KyKKHwGoIK70DbYYgzknKGm6EXUskofPtGbw46cHBZlf4wsC/DQrx5Zo?= =?us-ascii?Q?CZukkPKrqt9R+AAeQstF9Rkaoauw6UxMmbL3LRU1RMziCyWGuH+zvce094nA?= =?us-ascii?Q?bce/LsSWiBJcL0eQnxWEbW2ZDdsMft+7Y63qdTiiy4K3mdkF0MSDSXHyukNO?= =?us-ascii?Q?UiNof8Gk/mYIoRhIFCaAN8/8lxuhDqIEU8KMyJsEiXSITO28L920PBGqRjKh?= =?us-ascii?Q?B6uOUz1YyqZ6iu6Wo/VwVlM7Lb+Yd9asGiVwK7qVPDIZLiS8zE/Mx4i1/Mbu?= =?us-ascii?Q?BaxQGr0VU2c+W8zMxuFt8VLZ4LGXZ36jyjzspYrgFW2xh+d2I4VAVRbSSyJW?= =?us-ascii?Q?AVk6xKLHaMbaKXca3Nw3Y/cIEDi7EzYhgsS+XSsOLDmOzswZ+532EypylwOk?= =?us-ascii?Q?la4W3eufytJ79x6U/J3DNBOQtPhGbN//cTR+DzP?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2513; 6:iYNXA5qtFhNNHk1dBJNNRB66WLYdDoYMFONN3yVygDBpHQKcXSdlCqARffGcobtWRIQ50Aj7Tj+F1nbGZq85q8DQEFkAdydDThXm9L9INGzvtaqbtWZnpmkE3tzEPiUoaWzGltrtaYWcSCFhS9aOXZyNrBT4EtDeuiqJTPH9ndKja51ocNNBUMDqvoWqf4qYjIUWcYFdTX5/T7sFwywGZGXC0qhzzr7uN28f4YRCEu5N3mImkgcE6XPnR494WUNi+1ZAEoPVzjBZcXxUCKn9p6kcorl+7YiTwew4w+pV54e8THdTtuOliLhmHqKBgffSf8fRecZouhL/C1s8/PWjyA==; 5:+QyiapWYdinkdaWjSwH7GM+4xsIcDeDrPY2iR3cjlV1vYhSIFbwVXMxtMZetogj0U2KhhToIkrv0NLIOAdDm71MBoG1pHcUQvWjc75Cna+W1u5wtKTIpO6dh23F6Jhq/16uPX8IfJrr1hKvvMyyYzg==; 24:/7sv7KTXopDDpscrstkFE4PWW3Ofew92io0IHXEjGOADmeKCc31chbeiI8pqBs0g/oEh67fsLx1cKszYxQgFCmD+9mZHAT00h4E0SHiOJP4=; 7:pG1FpY/0pwFg8L3Xx3ZKTa0JqdeXkjznTFL7S+SjHsQbgvaDX3VyE3R1xP+cb3CB/EfsloaaeCUSeMWhlvNtaweZ6IuAp3sF3g4TRrnyylOH4Dnj9voJDirQLXM3FJNd+4Rlrn9YfmCVD8gLleOG7SzwgRcFcOu3eMvmRJfnplGLQ38ukyJi/XdK8vYxMHyX6OuNy6CYuhsuobCh+r/0bRAh659B5uUUFmJsSpq3HLE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2017 16:02:41.9645 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2513 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 16:02:46 -0000 Hi Daniel & Loganaden, I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06 draft specifies both Curve25519 and Curve448 even though only Curve25519 has been implemented by OpenSSH. -- Mark From nobody Fri Aug 11 09:56:31 2017 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 D5396132695 for ; Fri, 11 Aug 2017 09:56:25 -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 eE4sMghiazeP for ; Fri, 11 Aug 2017 09:56:23 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 9EA26132692 for ; Fri, 11 Aug 2017 09:56:23 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u207so25708450ywc.3 for ; Fri, 11 Aug 2017 09:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hmO/3fXHcj0WrrHad+w9TqvS2bVDnJUtn8kXew22nEw=; b=GoCs4IgeY71wkFEchRTXj+axasbD7r1wq0JFjsmddTlWFQxttQ73lm2rJbnkdAjmx6 0DxWRe6Rem7o8UDv863hHRBtZkal+uZ2SI3dCNWtRa/XLTM41zUb4G9dkaQOe2N1UmYj s/YwfQWXIsJGA3YKIi2b2uYcypjgagkQ7+tGcy11oacyAGw6N7ZVFKEq8zNPGgzbYjID mN2nKUGJxE+JiW67vpa31IP5lKtuQa5oXDMNeyNBF9eEIwff5GfAGW/VXL3zBWHSw9dO gHzEd9ZdmisDPcPdRZ+6HNk+uLqrv018Y2iDxmldm8eA614dywnByopGf1fYTiRnyaTL VXXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hmO/3fXHcj0WrrHad+w9TqvS2bVDnJUtn8kXew22nEw=; b=IQjrIyQLGHllfXBqix+3aca/kuTg+u0HGhj5Dvb2pMZKjjb6zykkVWHp3TamEu1zaM FEpAij/By+kKNRfAO6KgSrmyw5460wmMRN9FEqgSLyk4S0a2xJb1XuVPGkx3QzVsSVqU spvyCtQw2wFxyejPfoJZuO+nMcNQpK7lNA+viJmnBdBRrLKPjT5Ot5tijS/lWqYJy1UA BORkHsyLu5g8R94mgwFA9lF5Oislg7KVW5a+S16QbZ4jjmmYhyX5tJp9pGf7LFSBMrJU 9vSKSATyzhCVG1ZgO5H7RF6exHHA7VgSnHmoRJl5twmXKNUn8VNmriQoqIOLMnkPQ5FC U7Fw== X-Gm-Message-State: AHYfb5iZHzkkQVyFCMSC+0UZUzOPKKNWvRBgX0cOBC4QI2BFwHI0dEKF Vt2/T93SUAPiXpEf2/AjLwxIRcI6UQ== X-Received: by 10.13.212.70 with SMTP id w67mr13029728ywd.215.1502470582904; Fri, 11 Aug 2017 09:56:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.42.81 with HTTP; Fri, 11 Aug 2017 09:56:22 -0700 (PDT) In-Reply-To: <4054.1502467345@eng-mail01.juniper.net> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> From: denis bider Date: Fri, 11 Aug 2017 10:56:22 -0600 Message-ID: To: "Mark D. Baushke" Cc: Daniel Migault , curdle , Loganaden Velvindron Content-Type: multipart/alternative; boundary="001a114fb568612e4305567d3160" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 16:56:26 -0000 --001a114fb568612e4305567d3160 Content-Type: text/plain; charset="UTF-8" I would also like to see it specified, but for a standards track document, the main obstacle I see is the need for 2 implementations. I generally loathe to implement something before OpenSSH, because my installed base is maybe 1% of theirs, so even if I follow the spec, and they implement it later but make a deviation, chances are that (1) they won't care about compatibility with my implementation, (2) they will not test against my implementation, and (3) I will be adapting to their implementation, and not the other way around. For these reasons, I am hesitant to implement something OpenSSH has not yet implemented, but might implement in the future, until they have actually done so. If I go first, then what they do will override my effort if/when they implement it. denis On Fri, Aug 11, 2017 at 10:02 AM, Mark D. Baushke wrote: > Hi Daniel & Loganaden, > > I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06 > draft specifies both Curve25519 and Curve448 even though only Curve25519 > has been implemented by OpenSSH. > > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a114fb568612e4305567d3160 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would also like to see it specified, but for a standards= track document, the main obstacle I see is the need for 2 implementations.=

I generally loathe to implement something before OpenSS= H, because my installed base is maybe 1% of theirs, so even if I follow the= spec, and they implement it later but make a deviation, chances are that (= 1) they won't care about compatibility with my implementation, (2) they= will not test against my implementation, and (3) I will be adapting to the= ir implementation, and not the other way around.

F= or these reasons, I am hesitant to implement something OpenSSH has not yet = implemented, but might implement in the future, until they have actually do= ne so. If I go first, then what they do will override my effort if/when the= y implement it.

denis


On Fri, Aug 11, 201= 7 at 10:02 AM, Mark D. Baushke <mdb@juniper.net> wrote:
Hi Daniel & Loganaden,

I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06
draft specifies both Curve25519 and Curve448 even though only Curve25519 has been implemented by OpenSSH.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

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

--001a114fb568612e4305567d3160-- From nobody Fri Aug 11 10:34:01 2017 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 02D7F1321BA for ; Fri, 11 Aug 2017 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 WzeA-67nmNlU for ; Fri, 11 Aug 2017 10:33:57 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 161F113201B for ; Fri, 11 Aug 2017 10:33:57 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id o85so18895750lff.3 for ; Fri, 11 Aug 2017 10:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=LwK9pSz/nKUyFzI14Dy0xQ9FmW7h1BfbNjgv52GMgO8=; b=o7qy3Fixu2BTOVpZE9VGmwHgmJxGkCsoW8JfS7frZFkYb5M97rKZXgXJR8yCXR/LQ7 voYzgkLGWT5Ndn9ha7h1Fjpi/P/XugzribhQ4xKtQlnoSjG8Ugy66BWGpPFpuIQ8cR0y EkdGrQqU1UgsVpqOZkMZ8uSNxnaeWLe1dpzU4mbXnCpEwAAqaVFuVWGxK2xZCxOGEeC3 AWXoCYMhkQg2vL+PJ0lzD0vfjy662NH+MQH7wjXbLGObTg4ZpJOv0+LkhNLKd3vlV1ao h580bZAH03eOFw2xI70Qw+knfdKtHnLgq6EXSjs/XERLotnVdr96ycgliIWL9MXWCrCz FQHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=LwK9pSz/nKUyFzI14Dy0xQ9FmW7h1BfbNjgv52GMgO8=; b=W8XRoYxhWBze2NgomEstOLQZQ1/21KuNZh+uet2KWeLmgi6UPcd1nijtEv95BF1fCl H0KMJ5IdgBUyDBq6musv5lb9m4mlAsR/O1/QiBEOmZRoMQgclcVRzWEjv6KaztNaIPP7 mZWvuzdVHsgELj36Lk7fM6E2kS9VpPYdAB1BtJpJGRQSLz1NouadL4IQu1/n+Yc9uGIJ ywwJXiR1MH+wj4ppm+N/ryk7IEA29LIjTeuwAo2P/taaF19I1Q+5Pl1abzEHES/8tFVQ jloPHXvgRiq5SpbwGFpxuPneS+Nv61wJVK9HqoHjGqrusIM+Ufa4wECvUp29ILu0/LQO zuDQ== X-Gm-Message-State: AHYfb5jiH0V2TDCWMvBUK8BP8YAJNKsDLR30TtRt0BMyqdyMXAYNIxmQ cwlXOW+i41qpwp0+4XRqOH7Cyq+SIw== X-Received: by 10.46.22.20 with SMTP id w20mr1849962ljd.103.1502472835406; Fri, 11 Aug 2017 10:33:55 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.97.18 with HTTP; Fri, 11 Aug 2017 10:33:54 -0700 (PDT) In-Reply-To: References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> From: Daniel Migault Date: Fri, 11 Aug 2017 13:33:54 -0400 X-Google-Sender-Auth: eOrqnFuvxqpsBIvdPha0iS7PKhs Message-ID: To: denis bider Cc: "Mark D. Baushke" , curdle , Loganaden Velvindron Content-Type: multipart/alternative; boundary="f403045fbbeca3a1b705567db714" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 17:34:00 -0000 --f403045fbbeca3a1b705567db714 Content-Type: text/plain; charset="UTF-8" On a protocol specification I believe that defining later Ed448 will duplicate the effort make for Ed25519 while we can take advantage of the specification of Ed25519 now. In addition, the purpose of the specification is also expected to prevent such issues. That I completely understand the point made by Denis. I wondering if maintaining a record of implementation and RFC would be considered helpful. That might be something we could work on with the codestand initiative [1]. Happy to heard from your feed backs. Yours, Daniel On Fri, Aug 11, 2017 at 12:56 PM, denis bider wrote: > I would also like to see it specified, but for a standards track document, > the main obstacle I see is the need for 2 implementations. > > I generally loathe to implement something before OpenSSH, because my > installed base is maybe 1% of theirs, so even if I follow the spec, and > they implement it later but make a deviation, chances are that (1) they > won't care about compatibility with my implementation, (2) they will not > test against my implementation, and (3) I will be adapting to their > implementation, and not the other way around. > > For these reasons, I am hesitant to implement something OpenSSH has not > yet implemented, but might implement in the future, until they have > actually done so. If I go first, then what they do will override my effort > if/when they implement it. > > denis > > > On Fri, Aug 11, 2017 at 10:02 AM, Mark D. Baushke wrote: > >> Hi Daniel & Loganaden, >> >> I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06 >> draft specifies both Curve25519 and Curve448 even though only Curve25519 >> has been implemented by OpenSSH. >> >> -- Mark >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --f403045fbbeca3a1b705567db714 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On a protocol specification I believe = that defining later Ed448 will duplicate the effort make for Ed25519 while = we can take advantage of the specification of Ed25519 now. In addition, the= purpose of the specification is also expected to prevent such issues. That= I completely understand the point made by Denis.

I wondering = if maintaining a record of implementation and RFC would be considered helpf= ul. That might be something we could work on with the codestand initiative = [1]. Happy to heard from your feed backs.

Yours,
Daniel=C2=A0

On Fri, Aug 11, 2017 at 12:56 PM, denis bider &l= t;denisbider= .ietf@gmail.com> wrote:
I would also like to see it specified, but for a standards tr= ack document, the main obstacle I see is the need for 2 implementations.
I generally loathe to implement something before OpenSSH, = because my installed base is maybe 1% of theirs, so even if I follow the sp= ec, and they implement it later but make a deviation, chances are that (1) = they won't care about compatibility with my implementation, (2) they wi= ll not test against my implementation, and (3) I will be adapting to their = implementation, and not the other way around.

For = these reasons, I am hesitant to implement something OpenSSH has not yet imp= lemented, but might implement in the future, until they have actually done = so. If I go first, then what they do will override my effort if/when they i= mplement it.

<= /div>
denis


On Fri, Aug 11, 2017 at 10:02 AM, Mark D. Baushke <= ;mdb@juniper.net&g= t; wrote:
Hi Daniel & Loganade= n,

I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06
draft specifies both Curve25519 and Curve448 even though only Curve25519 has been implemented by OpenSSH.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

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


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

--f403045fbbeca3a1b705567db714-- From nobody Fri Aug 11 11:19:48 2017 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 F0E9E13252D for ; Fri, 11 Aug 2017 11:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaFX2BgNf1IJ for ; Fri, 11 Aug 2017 11:19:44 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0120.outbound.protection.outlook.com [104.47.38.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54756132382 for ; Fri, 11 Aug 2017 11:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jROeQ77gakTIiLbcyHguOmNTD8GSKBAwX0HqZ/FgO5E=; b=eegQHdCQj/ltZkUd5wXVrTJC/SXdrfkgS9KVk+auUnGvx4s7NaU/dm29YQT68syLBChtFF1mxAY7Al+wC5MAoqazdDBXrwBj4Xz52Fj57ONSIA61GFo9mC1JUKbC/RHO5NoErl5CUNAO5D+uAxKS9QDWJfAR0OPjnZeiBPx/l90= Received: from BY2PR05CA026.namprd05.prod.outlook.com (10.141.250.16) by BN3PR05MB2626.namprd05.prod.outlook.com (10.167.4.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1320.10; Fri, 11 Aug 2017 18:19:42 +0000 Received: from DM3NAM05FT033.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::207) by BY2PR05CA026.outlook.office365.com (2a01:111:e400:2c5f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1341.9 via Frontend Transport; Fri, 11 Aug 2017 18:19:42 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=fail action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT033.mail.protection.outlook.com (10.152.98.145) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1304.16 via Frontend Transport; Fri, 11 Aug 2017 18:19:41 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 11 Aug 2017 11:19:41 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v7BIJeNQ015341; Fri, 11 Aug 2017 11:19:40 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 2B2C81141B; Fri, 11 Aug 2017 11:19:40 -0700 (PDT) To: denis bider CC: Daniel Migault , curdle , Loganaden Velvindron In-Reply-To: References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> Comments: In-reply-to: denis bider message dated "Fri, 11 Aug 2017 10:56:22 -0600." From: "Mark D. Baushke" Date: Fri, 11 Aug 2017 11:19:40 -0700 Message-ID: <10852.1502475580@eng-mail01.juniper.net> Sender: MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(199003)(189002)(54094003)(97736004)(6916009)(81156014)(81166006)(7696004)(189998001)(8936002)(2950100002)(4743002)(97876018)(47776003)(478600001)(2810700001)(7126002)(50466002)(558084003)(48376002)(356003)(86362001)(8676002)(5660300001)(2906002)(76506005)(54356999)(50986999)(105596002)(76176999)(106466001)(68736007)(39060400002)(117636001)(69596002)(229853002)(4326008)(626005)(93886004)(230783001)(305945005)(6246003)(110136004)(6266002)(54906002)(53936002)(55016002)(53416004)(6392003)(7846003)(5003940100001)(77096006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2626; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT033; 1:SHWKExm2QZj8vNXSCx+w452z2bn8FRNWfC7tlaKt8tg00HskB/TM3mOMwceeu+sjWepwJCvdAIuPo8ao4X5FBrF722xRglAmlY5f1AsoGTgR1S8QenGSPzS2u5332McIMm8XTtlY77oM81pYgNel3Ip+OSoK7pE5zBzIIYDnysDROrpdpYvUGzCx/EOlUgKB6E5KYMC4BBrkvjUeEOZUT+XoNLLEGVlo3giiJrPfKdoskFHP/w+VQKnmaYiu8x+JUQw5K/RH40SmjyMGQ0Km0tiidt43NQvSja7+/yusrFB+4WpzOkbig23WbkFbkGygyF0jnlj0H51KsJe4UDLvhEhECgZe88aDqFEK3D5lcCd1WrgeLWClgTcW1YCKlLGt1aHh9QyHq0Ppz74pZ6e0yRAfDbCSj1wa8BEBkD1sH8Z1q/H3u0UKar/2pB6+Af1L33Mzf9Invgyn1fqfkM32KPkL4eWE8omMfLm13JRpGcoGdiwF3fzrO5uzEWJqaewju5DVu3NMFvNEOVKkLXfGhmLg/2ajD2P5CKh/wgrbUjmm8Qk2Lu+2JAc+/0iOIhA2p9Axij1+4yyfyzGUxsPKlrKHpNXJ0tkrqcStsHLwi+d7BZ0p5izXKvbvkRGb5xVf03+6OZ/YMUcorFv4S+FeVszKPU03WDXdtiDnWUuCttPpk75A2q94VGy2wiGgdgpljoYVBIvisA+Fi+l9ZEAXWvCtXkY5asWeafSr5/0yqtU4e4YW1HSkKQruEuWaBPN5DYe/eJjHkCegUA425pTu5sDGdgfNnmnTVzk57SoPte731TMLmwBah51aKgN989JxhwJYSMMVoSS8qSE2T5lN683rySBB2UNo/qWkPlI6tE0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 30536d3b-5377-4547-43d6-08d4e0e58955 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR05MB2626; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2626; 3:nngQhJnE7a6vz9Upjpg7+vwmP3kmZluc4iJkPXz4IOrm3Nh9z7Sg1/qui1WuTH6BeHZU39X96CA+hvF2PW06zkn0TmekTMDYdtlP6VcKiuBusfwL2ZcMDQpx7dOLEMcy6TNi2JKaTJ7Gk8Qs8WO9gOgXZ3of+5NHSDf3qdskq3GU1AB75RFIMuIiPlEXunovorUw5LNOo0W5i3efGjcJ0O+UugnvHBU6KihRM7QvDPfnNxfHG6wkmbxd3S5MXEFLx4oQoFXnMd1zn5HNr7uPONCKzqs5tZb2zN9qfFZbee8QFaQXtlb5vVjni6dCStb7eubpmF+Zz942qK7OVWard+/FcnEO+6nmJHG6H/SILp0=; 25:N4fsGtIF2IcQ3pyzD+c0gwayCPnWqprtRoMeg42KgSbaRxyDEha8XcHpew55MwrNJDj9OJ0JXx75qQu/L6p8710ZXKZZAPpcGuMVM1kIkKUGoT0MHJ37B4AMjOHjx6Uj3YiVPbeiaZ14+2ljdq+wdDgBHzNbIF/6H/UvGwsXygzXTzqwzZ7cpqJ17XxPTyLnPk71rqHlBYM4ZbWnKaZwJmHQ8m9XV7eu4tnuiqlzIpqFyfLradMzSHwXoHfDTc84rnxQy9dYa8G10qnrW0XVLS50Q2YQ1vUE0DtJENdxvKJTmhjP4ssAWokUK2swnnExJiLfAW2UKGeZVWjjoRF+qw== X-MS-TrafficTypeDiagnostic: BN3PR05MB2626: X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2626; 31:hkdBScXkg8DMLIoSn444F5xS/JbkFJmIRr3mcHMjK3TYZlkuAdx4hSvGAVvwNN0paM9Ly5BFq2aJlxid/30kVX+hjIU8hLtCQ3Ri0lHEcGSiGW15fwknxuJX7uufKGHx24xWq+WDTZP9nPF906G7PL1x4K+YkBRcw/YueopyaRHQLxFIi0WkxsitAO+T+sjINuFOvsHNrZifWaTFoMjoygieHdanoN7YUARSBHZqpwA=; 20:XgvD2wdIknRW3Xsgt2qPo4zpDl5A82HMG+KNvQIE+BGhLzA7G9YsF8jVNBhnD7MMVjCdw8lilq9JwRHzjsTC+bs/FtkollhMuTZx90nT1mnVEJirl8xm8V89EEf1DwsfCGTxMHhfU8B4Gu6xaw+KASBYqhy2R2gzwg/b4pSDebuV4nXXpNXR5hxfGi54d9CgvsORklsXBttU9zyeO0Z5nSHiyGK1dmzJKwC/kCwg8VKjSc9G35GZKDLWrV5QOW1+bN53WY0ZHdyk4l3EjUr5TmvFkIG5fJFV9fWFl/4yI+cCesM5WZGEGSe6AsDXNBnCwKUBfWrbo0EpzkWhFSgYdcpqm394sIpsloBGsvZzaCMnarBb2uAWsQNizRBu3eWXEtKGIkEEW2q/FbUVIRHALVJANClDJoh6QFlr0Gtl402Snh1JGTFtuErkZF/hg/LNQaOHYsxFsOrjqlp1AmAj6syQ+ERzHjxiaMdviuGYFXjmlmdhpNb7BDb1t5P0npsY X-Exchange-Antispam-Report-Test: UriScan:; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13016025)(5005006)(13018025)(8121501046)(93006095)(93003095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR05MB2626; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR05MB2626; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2626; 4:CFArRi1WOSP/5OoVEZYF/FHqfR9UlCxyjj/Jnwkdhi3pZ57Xa1bYaHpyuVxcT3kp+ucDXBNH6aP+i2Wgg4Wxia8iuFrQwGMAm/OzVs+5eSZvkSIxDeXC25pVaq8gg5Kych6f+8EXCeZMKHINMm5V7gcPv4KhVsrUAnuXOSWgzbKM9R+hA9+YcFFuuPDI4wIY3iFgzhxn4+cUoBFtyycSwr/SmATdsTDtGrteKeA3UfR6h5ysDhJRKbVUoRf0PbN2 X-Forefront-PRVS: 03965EFC76 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2626; 23:eSAwJtAtlHrL70e69dz8LEHCAutw5OjzsWLU9OQ1+?= =?us-ascii?Q?y2Jrp2gJVPNsw0qezfyED3obTxomugW5lfHQzcurKcnr30mJ3te2dWQljBwn?= =?us-ascii?Q?bYkDifPTwVwVJmPybZltckxsmhsvqt3MGQjOzBTGbbFHUJ28QD30/pctoHhY?= =?us-ascii?Q?w+lEpL8FKm9RARkIJf00JB2ju4SxacC/LG+kunFhZsglzruoJ8dDUPiEsTi5?= =?us-ascii?Q?B31rm0l3/YdhmI5ZCQ0aGPNXgpntnxikChlVSJiCxeG4pkQ/9V6EQ0XCw4WK?= =?us-ascii?Q?JIC2aor8yUQ2xGpBQ0F3ocefAm98iwJSPG3CQSp+44ikXcx3pa9Ob8tgHZlS?= =?us-ascii?Q?0OJnzd0jWvB3xuxFq+AGMa5erPiLAbhbX3UPdLABXR0/pSoJa2pz7xbwKFlx?= =?us-ascii?Q?rT47XlCwPwikGQRcQ7xQwqk9BX+1hQk5+YboCJUz8OSbVQobRNrCnYmrdwO2?= =?us-ascii?Q?lwUqbOX67Kq/iucsvQGESCudYEFKlW5QesfX5O5D2XQcHEdqb+qLnvBEiTll?= =?us-ascii?Q?IuQcnNHG3Ic1Kf8j6RkTtNWX6KADE79J5/VYVtaDt9Oz/hjC2XZgjsyAWNYQ?= =?us-ascii?Q?s2e3PeYuaW6Q4fpkGRzSoceNj+miTHb9niKDbkK1ck9kIsJ+2ITv3Hsc9tEX?= =?us-ascii?Q?mYSK7rp1dtQQGdrlqXzMw7JXGOG61cdNVJDdk+2w1ZCcSDrmdlDxe+iqCe4T?= =?us-ascii?Q?WLzrLSSPBiMO+o9EKTs9QbScgZPE0TuLtemRuZJPd5d10egcW86lkZBbXQSM?= =?us-ascii?Q?YgK/KxL7p41xqFQbqkErffmhFevcS8Phu4wbvV4SfZi8DTs2TFbrE3j2+NF8?= =?us-ascii?Q?ANJh+WZs3uWpkBgGz90X0E1zTIehF8eQPWRY3NCPVqH2lYgDjYoNHs/xmbfd?= =?us-ascii?Q?GbrAdw9VvTn2LZKI/+4qIFxKJNfpkE2w/PTlGusGsI8MrFndtifomGt79Xpp?= =?us-ascii?Q?iX6BHJq5c1BWGa1/kxD86N8dsJt9A3Ss06vC0uoxSsfZq4h7sjrGrS8NJr3+?= =?us-ascii?Q?vtp5Eha+8pUJhVYu8fbANjSWzPyGiyuRu1iWAGM8AclzUru8ISEcZyO/DnoK?= =?us-ascii?Q?UPGTba6TMS7zpSU8Vmm0mUpYPhHp8cwByhM/6zE7sFfGfQCjg7JdP25rYG2t?= =?us-ascii?Q?/paLLYgq2WyqOyGqYhjAypyRCUas9/1bMbpHPEx6ZOilWMcLKXTky5K4W5Tr?= =?us-ascii?Q?W9R0p9XufabyryoFeqYGzYcwRHoPxCAe8HT/DW/fYXrGhAkg2n3tyeLMlcEH?= =?us-ascii?Q?5EetJi/NQkDmxwDN82ZNiFYCNNQO2cS99/4Y75bkJPc2wDccmkhXaGFDse+W?= =?us-ascii?Q?C03NrC1rz87lFg4LI4hADWlzdXPgnOrCiFD1pneFxYt?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2626; 6:Df5/LttYNCMIRYKC6Jx/1zTUBTZGqvAlj9kru4hj6sjVQPmF2xTGhTzlkJtpsyPFONzccQhQjTUxZLGlYVzgC59katGWtELB7nAuBYNEZTUPG+2GF8EtK3mSAqOzAa0+ml+Mq2V+77UQxXrBscWAEKTzsGrI30582aSZ7ElXBu+aanNcNgdDaxk67gNEkpUv9LsxyfVG6kWUPMoZlKFyxFcy3vu9J2ZNIaqKjRYAc+lkumvu7G4i3xMsiTmrtJSGTwW61UErPofSXZYwt1zhvQwkFArmxSnk+Kb+WHT9rKGKx/HUQxrp1PisdYbkzJ0MxKwsVGHqCG2wJp9U5sF2aA==; 5:MXMf3zq7rHG/OyNn8WOPNYJajfuZxhymMiHYDZmqERc3UTY+rKlQpN1JRUkxVsXSVR8nE1bj31mBbgIadaPgVvzZGbbnh36uNI7M69qT77aVieByQ4yIina8J0TUeF9nwoPF50QmovA4m3YlqBK1mA==; 24:vaCveCh/CiSWlttpb9d2IfbAis8mciJzTNNaXwB6f1VvSEmD9LJJjVmIfFJGIYdc2eNfn9WRzh4qvyEXP5NiQ3LEQEWRvbKKezCmFZ79d7M=; 7:dpvHBuMv6tzPIJtvsXm0GLwSXqA9SypCfmJ/QIR5BZ7rdtzwKxQRLhqkrpm749MRwk4uIuoBhEGUsJxJSoL2rXKChl7INyYIilf1E/O4OpFzEsxEcLNtfc6polxN1pAiC/FSuWsOGgdx9j/yYAjFOGa20fgsb7tI1IaQOR/63s+HnWtTXXitLz1c00+iOPZQjVpCht0qtuAC0bn9UpjwZLqr0PEJ5VUoHDTiqEXtoTg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2017 18:19:41.9000 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2626 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 11 Aug 2017 18:19:47 -0000 Hi denis, Yes, the lack of two implementations is a potential problem. Given the libssh.org folks did the original work for curve25519, I wonder if they will be the first to do curve448 and likewise eddsa448. -- Mark From nobody Sat Aug 12 06:36:01 2017 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 40CB21324CF; Sat, 12 Aug 2017 06:35:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150254495425.26585.10604080195828839187.idtracker@ietfa.amsl.com> Date: Sat, 12 Aug 2017 06:35:54 -0700 Archived-At: Subject: [Curdle] Alexey Melnikov's Yes on draft-ietf-curdle-cms-ecdh-new-curves-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 13:35:54 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-curdle-cms-ecdh-new-curves-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 8 still has some TBD. These should be completed before the document is published as an RFC. From nobody Sat Aug 12 12:12:28 2017 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 750AD12741D for ; Sat, 12 Aug 2017 12:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wJBZHS1pgTQ for ; Sat, 12 Aug 2017 12:12:24 -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 98B8F1270AC for ; Sat, 12 Aug 2017 12:12:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EEDA4300580 for ; Sat, 12 Aug 2017 15:12:23 -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 JBZQz4q0jmka for ; Sat, 12 Aug 2017 15:12:22 -0400 (EDT) Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id DCCA0300295; Sat, 12 Aug 2017 15:12:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150254495425.26585.10604080195828839187.idtracker@ietfa.amsl.com> Date: Sat, 12 Aug 2017 15:12:26 -0400 Cc: IESG , draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <803D0AEB-4F9E-4535-B452-B1BD915B65CD@vigilsec.com> References: <150254495425.26585.10604080195828839187.idtracker@ietfa.amsl.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Yes on draft-ietf-curdle-cms-ecdh-new-curves-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 19:12:26 -0000 Alexey: Correct, but the TBDs can't be filled in until the IANA makes the = assignments. Russ > On Aug 12, 2017, at 9:35 AM, Alexey Melnikov = wrote: >=20 > Alexey Melnikov has entered the following ballot position for > draft-ietf-curdle-cms-ecdh-new-curves-09: Yes >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 8 still has some TBD. These should be completed before the = document is published as an RFC. >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sat Aug 12 14:14:07 2017 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 53737132192; Sat, 12 Aug 2017 14:14:05 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMcVyjsvCKn4; Sat, 12 Aug 2017 14:14:03 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8B53E129A92; Sat, 12 Aug 2017 14:14:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502572439; d=isode.com; s=june2016; i=@isode.com; bh=QB8//p97Uz1EZEw/KgXSnG2u/+5v3bQxkQurO38LvZM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=eGU7eIL8SAuyy1CeR/XJwMqBgNDNuvSqQpGa377YsufgE8QkGBJtAyFN1uIZVQPlxwpD4b uyvLEgLarVtW4Gwh+3leLWmVMyST35KptvRxUfujj1TVMWTayEMx50VAOHrc7OpJBv4qcT UHDhmEnlvyFoIN1wfLa73qotaGamhZA=; Received: from [192.168.0.6] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 12 Aug 2017 22:13:58 +0100 From: Alexey Melnikov X-Mailer: iPad Mail (14F89) In-Reply-To: <803D0AEB-4F9E-4535-B452-B1BD915B65CD@vigilsec.com> Date: Sat, 12 Aug 2017 22:15:23 +0100 Cc: Alexey Melnikov , draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org, curdle-chairs@ietf.org, IESG Message-Id: <66679D55-E48F-4794-A69E-651B844DB38C@isode.com> References: <150254495425.26585.10604080195828839187.idtracker@ietfa.amsl.com> <803D0AEB-4F9E-4535-B452-B1BD915B65CD@vigilsec.com> To: Russ Housley MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Curdle] Alexey Melnikov's Yes on draft-ietf-curdle-cms-ecdh-new-curves-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 12 Aug 2017 21:14:05 -0000 > On 12 Aug 2017, at 20:12, Russ Housley wrote: >=20 > Alexey: >=20 > Correct, but the TBDs can't be filled in until the IANA makes the assignme= nts. Ok, a job for AUTH48 then. > Russ >=20 >> On Aug 12, 2017, at 9:35 AM, Alexey Melnikov wro= te: >>=20 >> Alexey Melnikov has entered the following ballot position for >> draft-ietf-curdle-cms-ecdh-new-curves-09: Yes >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html= >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >>=20 >> Section 8 still has some TBD. These should be completed before the docume= nt is published as an RFC. >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Aug 13 02:39:22 2017 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 5AC95126C0F for ; Sun, 13 Aug 2017 02:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEO9c5_NWncH for ; Sun, 13 Aug 2017 02:39:16 -0700 (PDT) Received: from newmailhub.uq.edu.au (mailhub1.soe.uq.edu.au [130.102.132.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2201913213D for ; Sun, 13 Aug 2017 02:39:14 -0700 (PDT) Received: from smtp2.soe.uq.edu.au (smtp2.soe.uq.edu.au [10.138.113.41]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v7D9d1Ee011391; Sun, 13 Aug 2017 19:39:01 +1000 Received: from mailhub.eait.uq.edu.au (holly.eait.uq.edu.au [130.102.79.58]) by smtp2.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v7D9d1dT061942 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 13 Aug 2017 19:39:01 +1000 Received: from haru.mindrot.org (haru.mindrot.org [130.102.96.5]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTP id v7D9d0ws008495; Sun, 13 Aug 2017 19:39:00 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by haru.mindrot.org (OpenSMTPD) with ESMTP id affd260f; Sun, 13 Aug 2017 19:38:16 +1000 (AEST) Date: Sun, 13 Aug 2017 19:38:15 +1000 (AEST) From: Damien Miller To: "Mark D. Baushke" cc: denis bider , Daniel Migault , curdle , Loganaden Velvindron In-Reply-To: <10852.1502475580@eng-mail01.juniper.net> Message-ID: References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> <10852.1502475580@eng-mail01.juniper.net> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.79.58 X-UQ-FilterTime: 1502617144 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 13 Aug 2017 09:39:19 -0000 On Fri, 11 Aug 2017, Mark D. Baushke wrote: > Hi denis, > > Yes, the lack of two implementations is a potential problem. > > Given the libssh.org folks did the original work for curve25519, > I wonder if they will be the first to do curve448 and likewise eddsa448. I looked at adding ed448 to OpenSSH a while back and got stuck looking for a standalone ed448 implementation that was as small, self-contained, clean and suitably licensed as the ed25519 that we use (from Supercop). Now, IMO our priority should be to choose a PQ KEX before another EC one. -d From nobody Sun Aug 13 07:50:07 2017 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 83944126C0F for ; Sun, 13 Aug 2017 07:50:05 -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 8uV7W0kTb4Td for ; Sun, 13 Aug 2017 07:50:03 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7811C131CD5 for ; Sun, 13 Aug 2017 07:50:03 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u207so43600038ywc.3 for ; Sun, 13 Aug 2017 07:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5nTnXiz91dwF2Cc1o4FmTqxCr0QhLf4EAfG5mgO0+gk=; b=qHsk7FilmJ6wgFqikZ5bU/U1peKDmXMQXbAfQwo03C+SlzbWJf4Ldm3UKt4OY09q93 UTnP+CBL4BTgakjGOKESyNOhGlnP0jWKv3aDHjkaddbFAw6F56ievO6AiBhG1+eczK1w EtCSMBvcWPJY0admfg8DlgfyW44bATWdV5r5aqA/zXTMk6e3z3ZlncYudriXyA75qOEC OLRFXfNb1YeoFH07umabjOU64ygWWq9A3deXvtHLKZfSnDJqfacjmHau+2ic8i5nFJ7P djQGpRONBIb8g9SeiZQKcHiYCZLsWKS+dliIGZVGgBvKrAsR15ESUcITKuWXld+0+aAs x+EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5nTnXiz91dwF2Cc1o4FmTqxCr0QhLf4EAfG5mgO0+gk=; b=MLUpdcekiorOet4rnczVdj+JfvivYJrCoKWOuRDbxJVCZby5HTnn5N9ugYWJvf8/o2 O3Eav+9q1evIDzfR2dPF3E06eWNOK0GkISFCgYDU9Fa13uUwAazmKUC1zZnCJajLcPao gb5eMr7kwu4t436hf1CnO6mWa5ScoDJFDt+JdGepOm8erx3VDaUcsgyS3yAim3IcqR08 UAkZMTArmEKtZP6DwscV7DJwdnQu2/vUFyBQjPfd8S84rXeVxIgelf/fmx9IZ8nr9Z7r BZnfjvXseQQElC62HGLY9JoqGlqXSLvNRPDQnkj1m0CNsI6ilrB6tiKYqhRZ8fZNSia5 T9bw== X-Gm-Message-State: AHYfb5j3MICARlKn8/4/apNIK/AycsBa2cMyU5kDxvljTI4bmFbtM7nN GjyhdsQGjH/stRBznwhGtqjqADS5Pw== X-Received: by 10.129.118.73 with SMTP id j9mr18625425ywk.323.1502635802622; Sun, 13 Aug 2017 07:50:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.42.81 with HTTP; Sun, 13 Aug 2017 07:50:02 -0700 (PDT) In-Reply-To: References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> <10852.1502475580@eng-mail01.juniper.net> From: denis bider Date: Sun, 13 Aug 2017 08:50:02 -0600 Message-ID: To: Damien Miller Cc: "Mark D. Baushke" , Daniel Migault , curdle , Loganaden Velvindron Content-Type: multipart/alternative; boundary="f403045f0bac3e02dc0556a3a90f" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 13 Aug 2017 14:50:05 -0000 --f403045f0bac3e02dc0556a3a90f Content-Type: text/plain; charset="UTF-8" Aye, you're right. That is a concern for us as well. SUPERCOP has a MIT-licensed implementation from Mike Hamburg, but this would be a problem for us to, because it requires updating our license terms just for this algorithm. I have historically avoided any external code that has an impact on our license terms. In the absence of a public domain implementation, I would have to either change this policy, or implement my own. And I don't want to subject anyone to crypto I implement on my own. :) On Sun, Aug 13, 2017 at 3:38 AM, Damien Miller wrote: > On Fri, 11 Aug 2017, Mark D. Baushke wrote: > > > Hi denis, > > > > Yes, the lack of two implementations is a potential problem. > > > > Given the libssh.org folks did the original work for curve25519, > > I wonder if they will be the first to do curve448 and likewise eddsa448. > > I looked at adding ed448 to OpenSSH a while back and got stuck looking for > a standalone ed448 implementation that was as small, self-contained, clean > and suitably licensed as the ed25519 that we use (from Supercop). > > Now, IMO our priority should be to choose a PQ KEX before another EC one. > > -d > --f403045f0bac3e02dc0556a3a90f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Aye, you're right. That is a concern for us as well. S= UPERCOP has a MIT-licensed implementation from Mike Hamburg, but this would= be a problem for us to, because it requires updating our license terms jus= t for this algorithm.

I have historically avoided any ex= ternal code that has an impact on our license terms. In the absence of a pu= blic domain implementation, I would have to either change this policy, or i= mplement my own. And I don't want to subject anyone to crypto I impleme= nt on my own. :)

On Sun, Aug 13, 2017 at 3:38 AM, Damien Miller <djm@mindrot.org> wrote:
On = Fri, 11 Aug 2017, Mark D. Baushke wrote:

> Hi denis,
>
> Yes, the lack of two implementations is a potential problem.
>
> Given the libssh.org folks did the original work for curve25519,
> I wonder if they will be the first to do curve448 and likewise eddsa44= 8.

I looked at adding ed448 to OpenSSH a while back and got stuck looki= ng for
a standalone ed448 implementation that was as small, self-contained, clean<= br> and suitably licensed as the ed25519 that we use (from Supercop).

Now, IMO our priority should be to choose a PQ KEX before another EC one.
-d

--f403045f0bac3e02dc0556a3a90f-- From nobody Sun Aug 13 14:20:37 2017 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 E61BA1328DB for ; Sun, 13 Aug 2017 14:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhcloos.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNImiKvJZ5_V for ; Sun, 13 Aug 2017 14:20:34 -0700 (PDT) Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) (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 426B9132D55 for ; Sun, 13 Aug 2017 14:20:34 -0700 (PDT) Received: by ore.jhcloos.com (Postfix, from userid 10) id EB2611E185; Sun, 13 Aug 2017 21:20:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore17; t=1502659231; bh=eB8WuRQ3EGIXo0IllzgWG7Kb7X1TmylgQ4uRG5bqDSA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kjlLKExPJR5Sfqyr+D2PfYFrnqawDdsXP8NBRROxmx1QKOjc3jFufJMfPYiOqY9Pz +lF/oklt7EkogdwBiaH90eYxPBarcyGuqcp7ZFvRf7yjm8Y5a4W0Ys16hx5v8G/agc mG0vEKICDZ4ALMjzPgaSBEZLTBvN1blbsxjrVFwQ3F5BEHPL9901hMvW0TQ15OHzqs AXbyxKUICb90Zijgie7gwGLQGrEDFoKnu+bxf2B2q+U98Mji3srGrAjXIjm0uhp/Sx dSLYPLaKr6JtImGGhAK6kUxyz/wi7WVmnn0U3cfX+dUF/1OqHw9mv7AJJLxJWFZZrL 6ntZKKDqKILaQ== Received: by carbon.jhcloos.org (Postfix, from userid 500) id 5D59D107AC444; Sun, 13 Aug 2017 21:13:22 +0000 (UTC) From: James Cloos To: Damien Miller Cc: "Mark D. Baushke" , Daniel Migault , curdle , denis bider , Loganaden Velvindron In-Reply-To: (Damien Miller's message of "Sun, 13 Aug 2017 19:38:15 +1000 (AEST)") References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> <10852.1502475580@eng-mail01.juniper.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2017 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Sun, 13 Aug 2017 17:13:22 -0400 Message-ID: Lines: 16 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Hashcash: 1:28:170813:djm@mindrot.org::hcZPyqm/lr5PdBnS:09C8AO X-Hashcash: 1:28:170813:mdb@juniper.net::Oa5QjmTBOmv3HUYb:0gUsuJ X-Hashcash: 1:28:170813:daniel.migault@ericsson.com::xkc1XiqQD89N+prb:000000000000000000000000000000000NPBg6 X-Hashcash: 1:28:170813:curdle@ietf.org::tFE53lYJwnRb3aMv:04MWta X-Hashcash: 1:28:170813:denisbider.ietf@gmail.com::KGEuvDenkzn88eEt:00000000000000000000000000000000000cJR1Z X-Hashcash: 1:28:170813:logan@hackers.mu::uouX+csjBewu+8dl:FzDcF Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 13 Aug 2017 21:20:36 -0000 >>>>> "DM" == Damien Miller writes: DM> I looked at adding ed448 to OpenSSH a while back and got stuck looking for DM> a standalone ed448 implementation that was as small, self-contained, clean DM> and suitably licensed as the ed25519 that we use (from Supercop). Powerdns uses Michael’s libdecaf¹ for 448. It uses the mit license. If you prefer, the x448 branch has an implementation with one .c and one .h, also mit. You could just grab those two files. 1] git://git.code.sf.net/p/ed448goldilocks/code.git -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Mon Aug 14 09:33:10 2017 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 5EEC6124207; Mon, 14 Aug 2017 09:33:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150272838938.341.1974126305372406748.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 09:33:09 -0700 Archived-At: Subject: [Curdle] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-curdle-cms-ecdh-new-curves-09=3A_=28with_COMMENT=29?= X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 14 Aug 2017 16:33:09 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-curdle-cms-ecdh-new-curves-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- One purely editorial comment: I much prefer the use of the RFC numbers as reference keys, however, I know that this style is possible as well and I also don't know if there are any recommendations by the RFC editor for this. However, I can say that the other style (use of [RFCXXX]) is more common. From nobody Tue Aug 15 10:13:20 2017 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 D1102132396; Tue, 15 Aug 2017 10:13:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150281719885.21061.4889506424747370613.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 10:13:18 -0700 Archived-At: Subject: [Curdle] Warren Kumari's No Objection on draft-ietf-curdle-cms-ecdh-new-curves-09 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 15 Aug 2017 17:13:19 -0000 Warren Kumari has entered the following ballot position for draft-ietf-curdle-cms-ecdh-new-curves-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are no remarks associated with this position. From nobody Tue Aug 15 17:28:49 2017 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 2F5541323B0; Tue, 15 Aug 2017 17:28:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: curdle@ietf.org, curdle-chairs@ietf.org, ekr@rtfm.com, mglt.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150284332810.12563.2891412257055668430.idtracker@ietfa.amsl.com> Date: Tue, 15 Aug 2017 17:28:48 -0700 Archived-At: Subject: [Curdle] curdle - New Meeting Session Request for IETF 100 X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 00:28:48 -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): 30 Minutes Number of Attendees: 15 Conflicts to Avoid: First Priority: acme anima cfrg dnsop dots homenet ipsecme irtfopen lamps lpwan lwig nfvrg quic saag sacm secevent nvo3 tls People who must be present: Eric Rescorla Rich Salz Daniel Migault Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Aug 16 12:48:36 2017 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 1DE11132143 for ; Wed, 16 Aug 2017 12:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 N56v3QpQj33p for ; Wed, 16 Aug 2017 12:48:32 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957801326D5 for ; Wed, 16 Aug 2017 12:48:32 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7GJlslv017088 for ; Wed, 16 Aug 2017 20:48:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=/HszshDcL5UkPOYpQxYI/fO9eaJt1dcpbcXXwy2dq0k=; b=NzFZHwtiisu8ELdHzmV4Es/tEVqxP+Nq8hMYWsW+7mQzg8KtAJDXH1XgY5cOCndISfYf Q7qmBHWO2Du3/5AgqZPVYz2Mh/Hevfp/dCI3A9OBLCup5fVGmmNMQSklNHzsgF9lJx84 /WSsg0dUhyd6KueOjTsFK1Zl97ZsCcEHs0MrU97JWSibM490uSEpi3Dm80wHy4hdyuU+ scCwpVjXX+ZlOxzXIQOsCPuqjsgei2P/83v/yBVD7sSNaMB/V/PwQSTirT2xV6VvQO1/ gmZwc/gs7TMde2TQQe4kiYrxGqnHCujzRRB14efqAfuWiuwSszHe/6lugkpvjLzHjhWL 9A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2cc6dv3vb7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Aug 2017 20:48:31 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7GJk3Xx015147 for ; Wed, 16 Aug 2017 15:48:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cc6cvc7yy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 16 Aug 2017 15:48:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 16 Aug 2017 15:48:28 -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.1263.000; Wed, 16 Aug 2017 15:48:28 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: Adoption of rc4-die-die-die document Thread-Index: AQHTFsih0LuARi3xekapmVQwQpXY6g== Date: Wed, 16 Aug 2017 19:48:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.75] Content-Type: multipart/alternative; boundary="_000_AF662C78D0D94C578B45B95C2311A048akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160325 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-16_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708160326 Archived-At: Subject: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 19:48:34 -0000 --_000_AF662C78D0D94C578B45B95C2311A048akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBhZG9wdGVkIGRyYWZ0LWlldGYtY3VyZGxlLXJjNC1kaWUtZGllLWRpZS4gIEZ1bGwg ZG9jIGRldGFpbHMgYXJlIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtY3VyZGxlLXJjNC1kaWUtZGllLWRpZS8NCg0KVGhlcmUgYXJlIGNvbmNlcm5zIHRoYXQg dGhpcyBkb2N1bWVudCBpcyBvdmVyLXJlYWNoaW5nIG91ciBjaGFydGVyLCBhbmQgdGhhdCBhIGRv Y3VtZW50IHRvIHJlbW92ZSBSQzQgZnJvbSBhbGwgcHJvdG9jb2xzIGlzIGJleW9uZCBvdXIgc2Nv cGUuICBJdCBpcyBoYXJkIHRvIGFyZ3VlIHdpdGggdGhhdCDimLoNCg0KU2hvdWxkIHdlIGFzayB0 byBleHBhbmQgdGhlIGNoYXJ0ZXI/ICBEYW5pZWwgc3VnZ2VzdGVkIG1heWJlIGEgY3J5cHRvIHBv bGljeSBkb2N1bWVudCwgYnV0IHRoYXQgcHJvYmFibHkgYmVsb25ncyBpbiBTQUFHIG9yIGV2ZW4g SUVTRy4NCg0KU28gd2hhdCBzaG91bGQgYmUgdGFrZW4gb3V0IG9mIHRoaXMgZG9jdW1lbnQgc28g dGhhdCB3ZSBjYW4gbW92ZSBmb3J3YXJkPyAgIE9yIHNob3VsZCB3ZSBhc2sgZm9yIHRoZSBhYmls aXR5IHRvIGNvbmRlbW4gUkM0IGZvciBhbGwgb2YgdGhlIElFVEY/DQo= --_000_AF662C78D0D94C578B45B95C2311A048akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAg MCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsN CglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u bXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIi Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseTpDYWxpYnJp O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPldlIGhhdmUgYWRvcHRlZCBkcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUu Jm5ic3A7IEZ1bGwgZG9jIGRldGFpbHMgYXJlIGF0DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRpZS1kaWUvIj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWN1cmRsZS1yYzQtZGllLWRp ZS1kaWUvPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhl cmUgYXJlIGNvbmNlcm5zIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBvdmVyLXJlYWNoaW5nIG91ciBj aGFydGVyLCBhbmQgdGhhdCBhIGRvY3VtZW50IHRvIHJlbW92ZSBSQzQgZnJvbSBhbGwgcHJvdG9j b2xzIGlzIGJleW9uZCBvdXIgc2NvcGUuJm5ic3A7IEl0IGlzIGhhcmQgdG8gYXJndWUgd2l0aCB0 aGF0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNob3VsZCB3ZSBhc2sgdG8gZXhwYW5k IHRoZSBjaGFydGVyPyZuYnNwOyBEYW5pZWwgc3VnZ2VzdGVkIG1heWJlIGEgY3J5cHRvIHBvbGlj eSBkb2N1bWVudCwgYnV0IHRoYXQgcHJvYmFibHkgYmVsb25ncyBpbiBTQUFHIG9yIGV2ZW4gSUVT Ry48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNvIHdoYXQgc2hv dWxkIGJlIHRha2VuIG91dCBvZiB0aGlzIGRvY3VtZW50IHNvIHRoYXQgd2UgY2FuIG1vdmUgZm9y d2FyZD8mbmJzcDsmbmJzcDsgT3Igc2hvdWxkIHdlIGFzayBmb3IgdGhlIGFiaWxpdHkgdG8gY29u ZGVtbiBSQzQgZm9yIGFsbCBvZiB0aGUgSUVURj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AF662C78D0D94C578B45B95C2311A048akamaicom_-- From nobody Wed Aug 16 12:57:56 2017 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 1E3E11326DB for ; Wed, 16 Aug 2017 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omQCmj8HiflD for ; Wed, 16 Aug 2017 12:57:52 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0113.outbound.protection.outlook.com [104.47.36.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78998132350 for ; Wed, 16 Aug 2017 12:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVverMi+bJPe8ecM1+CrTENLVgfYE579ntUr8ykRCGY=; b=Z8zMOMgxoxzMYp9LRs6t8tq6ZHcEio8K7lvXCne6OP2AW98kwSbd+ULOS1mB+iRgqo9x8W147tTL3hmvo60/C1VeCK7P55WMrdUt1EVgmCvIKdbpXW6oP0oUUxjbD1L7QlbqafFJ6DvKVhJ7GF+jBtxoCz15zT3/D5cPWJKgbEQ= Received: from SN1PR0501CA0005.namprd05.prod.outlook.com (10.163.126.143) by BN6PR05MB3425.namprd05.prod.outlook.com (10.174.232.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Wed, 16 Aug 2017 19:57:49 +0000 Received: from CO1NAM05FT033.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::203) by SN1PR0501CA0005.outlook.office365.com (2a01:111:e400:52fe::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4 via Frontend Transport; Wed, 16 Aug 2017 19:57:49 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by CO1NAM05FT033.mail.protection.outlook.com (10.152.96.145) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.1.1341.23 via Frontend Transport; Wed, 16 Aug 2017 19:57:48 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 16 Aug 2017 12:57:00 -0700 Received: from eng-mail01.juniper.net (eng-mail01.juniper.net [172.17.28.114]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v7GJv0Fv028627; Wed, 16 Aug 2017 12:57:00 -0700 (envelope-from mdb@juniper.net) Received: from eng-mail01.juniper.net (localhost [127.0.0.1]) by eng-mail01.juniper.net (Postfix) with ESMTP id 7D7C21144E; Wed, 16 Aug 2017 12:56:59 -0700 (PDT) To: "Salz, Rich" CC: "curdle@ietf.org" In-Reply-To: References: Comments: In-reply-to: "Salz, Rich" message dated "Wed, 16 Aug 2017 19:48:28 -0000." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Aug 2017 12:56:59 -0700 Message-ID: <98476.1502913419@eng-mail01.juniper.net> Sender: X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(57704003)(189002)(51444003)(199003)(77096006)(626005)(7696004)(69596002)(6392003)(6266002)(117636001)(230783001)(2950100002)(6916009)(86362001)(305945005)(6246003)(5660300001)(7846003)(54356999)(4743002)(110136004)(76176999)(6306002)(53936002)(50986999)(4326008)(55016002)(97736004)(189998001)(2906002)(229853002)(76506005)(50466002)(53416004)(966005)(478600001)(23676002)(8746002)(8676002)(68736007)(97876018)(81166006)(81156014)(105596002)(7126002)(8936002)(106466001)(356003)(47776003)(2810700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB3425; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT033; 1:NhDvjpZggXWLmLZaJq1GyHTK64HptOzz89w8fpQ07qMose3VNdaLED8wcvnJarDn/v900wRfoojByrUAeFSo3+ASouWFN0jiNsGUV4uKvusyLYpyfNjqIFJRIWjNMzht X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ea6067bc-21bc-4f2b-0c90-08d4e4e11267 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603157)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR05MB3425; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3425; 3:LBc+geW2KwqIMeG4kKHgONmMG3Mu2BDQwKU9xdi8Ep6Q3cXRr7EuenJcMNwMAdLm6MYSuejFX8Zazal1M5ShSK62jSJdmRS0xiE6my3DafznPTnPK5bRAS/V01dTvL+KyYtdV7lmFUL3Zl4TILrFJiGdcHAkezS33JADwbBrAkYBY3KrDNMw/b6l3o5gGwihAQNfoALGMOiuc1f3tl+jK8JSsjTyaNLmghTVG4k+vEtU3zezHp7kL98nRJ0j6rmA8anPNjP0VBe6rLcmyeu284/2lx5qNiAO2CCySwtcKkzCKbtEqoylOwEn2nhg4b2TphjexI6XzuvgTxVJsGya7AUDgPHgY+UyjlbiZ1CrHnw=; 25:KaHfrzK1CtR0btvmcE2hy+DDntpQCYh3HTuwcpx7b1tseIY4N6gUBkD28JGrjx6RqC9TMFanxlEYo/52JjgDCbcs+VsYD+z59ag1Aj/uqVmEItoJmyKVThHKHJX+o2tRCpwKXslkQ1Variz+xCYvXsuOi0ibFmyaCt/ZN1l5Zqq7qU2tlz/7A6U5kVufQjzjtq+3lrny9Buy/9S3Zp7YpH4n4TNCH0dlIBPZqFuRPfuZAP5cvW4FkUNhzaXTDyoPLbxUYQ7dmGEFTJ8j5uavAYB90mlqMHmq/hHoVzpb8anSAnQqtl0cc/turSl/pwmqD+GyEBxESWQm7tItOApz4A== X-MS-TrafficTypeDiagnostic: BN6PR05MB3425: X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3425; 31:Kvrj5RjDdB7BnEJokiHIKCW/vz2PjGQCEKW+S/Ba5VbWkOzOr1TEYjqREtBqVGGk/cKoz2fJSztqfvQ3bZU72K79Rz9aUkH604MOlUCUg6wabUoHnpttIuDJId2XlK/lU1TwcU7myQW/W4KF7YiXaji1viEBuVIlF9D7+XL/BnHlZBOyHa3h31YthQvYFfRuz/JP+557AIXJSYy2RpeKuj5DOcGxcWGWSCGyS4FerIA=; 20:BbIh8MSkwlz8UsD5egjcgjRm6Jus7LWlrFbC7JZBbSJaYgoZwfOXli4pG7/4RiFjXmPIIEp3rjEgFbOKL50wnKaXMShilBvXoP2A8Cwqv/mV5Mzwgvq1Ol8G6df21+dFqErE3djc59+C4cjY+s/0k9kkN9gvS8tx+5STYKARaJHw19Fj76ZJK9IVCvItrlyIH5vdiPacc+eOEoZE0K1Xm0jUfBaDVOSSyNyA16VhUw93Hz7HRaMX+MhwDPepuoywr3fMupB1Of8wgWGJY4zb0SH6/G1dlKc95Uuh9J5ZDPJi15mKomFSn6j9t/xbICm3noWQqQ5c632xHEa1mKz3ip1HWtscCrbsj6KjpeFjuU1oP3pdWghUaaVYJUNTs9avNpjyW3VXTrzzatxnhk9Jch8f1iulML3PLzvTWfxZq5NS28msxffmqYgqF4K6Y6iFm90L667T5pmulv28nc98tD9FoExa4NBJaVwGJz23XMd7/AtYNEaZOyJhsm9m5Xvm X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(13016025)(13018025)(10201501046)(93006095)(93003095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR05MB3425; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR05MB3425; X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3425; 4:Gb+bMlY41nfbzDYIr9cAByTS+8PdZEbpLI4VA6iNo5downM7bQFuJlS9UQ/rdwauXaH7GH2cbM3jibEiJ2zCY9sljlT5aVAFRCr4ylFkwoV1rXNtRi9ubXD5IX24rUjF1BSU5o0Nmz/MWvSM8fiBD83vcwGyAspQuqjwIBB6QTQHHszIyKZGw0A2hY52bdR5UiN5L7cMyk9DmIofzuhRyrwI+LdB2OCkOZFWb6UTBGi/g829q2pUoIgQtI8tFWS6KOyMppLpYA0ZK3a8v3NSDMBX2Fom/Pw+uWkfMxgB24Q= X-Forefront-PRVS: 0401647B7F X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjZQUjA1TUIzNDI1OzIzOnpzRExSM2ZnSmJYbDdTYzM0ZEg4eTI0M1VQ?= =?utf-8?B?WlI1TDFZM053QUxJdjdIYXU5aVNkREljOHNTY1AwcU8vdzBFUXNXM1JXUEVs?= =?utf-8?B?ZEN4eDU0ckNXY2dieDBJQUZxT28rMzBKeWxDcUd6UDhPTTdMYUlnNEo5enY4?= =?utf-8?B?Skt4NklLS0swUTRoOVdzbTFhT1FrazRUdjFyM0xHRm9zQXIyN3JWY3dWM3hC?= =?utf-8?B?WXIzNFljeFZoWmh0M3BnLzZpT25XVlF4S015OUVDOFZEOWR6cXJ6SHM0VTR1?= =?utf-8?B?L2JqWTkxK1JBWjA0bnJMdllFU0xGdGx0Sy8zTW5xcjdVRHQyU0xwcVd3THc2?= =?utf-8?B?aVcxUlRDaUVWQ3cxTUtZMDJpc1k0YlNYT1RadmZoU0p4ZDY4eEhVR09qbDVF?= =?utf-8?B?bkpvcWszdUlaMk51K2dVWFFxVCs2VkJVYnNUcGpYQnhzNVhZQldDWnpVN1pS?= =?utf-8?B?MG56Y3RSYmlUaVdSUFFvNC8zUTdwRFBzd0ZEM0k0c21ncVh3NldJZ0RBUXFC?= =?utf-8?B?dmpaUU44NDZGeU5wak9mUWh5ckdhM1FLVWxvM2JwSERuc1hGYkRHb3N1dVhT?= =?utf-8?B?UmZvd0NmQWtaRVlPRzluY3ZZem9rR2ZsRm1ZbnJjUk9jL0Qzc1BQNTFUdFQv?= =?utf-8?B?eGFUNnNQblhqMVRGTWVWYktCOVF6Mi9WWDRPUDd5MHpJTGl6dWE0bEZOVmln?= =?utf-8?B?bTg3clNGSVRoY2s5cEVIODBYcVZ2VThFT2cxa3NrWU5manpLSFArMGNhSEhu?= =?utf-8?B?cDMvT0ZrR0RjVmpFUmJJeTdKNHhCMFRDVXR1Rm9rcStGU3phUWpmZ3JVam1I?= =?utf-8?B?QjFNalhabTdOanJDNHVBOFB6RG9JT0VFeFpwalplaFpaSjVSM2FzV0RadWM4?= =?utf-8?B?QnBDWTVDc1EyTmtpTVRJMmNsMndhZ3cwRWpKTUhLZVF3TGFMMzVDakFBYmMx?= =?utf-8?B?VnpQcEV0cmY0M0dDMWVhdHpyTlFjRVNoTk0rRjFkV1RwY1duRm9GWDcyb2c1?= =?utf-8?B?Mi83eWZoSnJDWXFVTEowZGc1Z25LQ0UwNjNsVGtMVGd4U3BTWnRzN3cxcHpR?= =?utf-8?B?UWFZdk1UcGNCcGZzY2FuYi9QSlRuUHFpNzJ3VTNncGs4RWxweFQvNmxDL2dv?= =?utf-8?B?ZytNSWFRRG4vUUNGV01YQ1o4blcxUWs0Snc4UGZDckZaZ3hHclZpa0Rub3pT?= =?utf-8?B?S0pHdGNLRFoxTlJiYUJEV3lJSEZvWFhGYnMxMEpua3JDSnA3TmR0dzZjWSt4?= =?utf-8?B?ZHd0L0l4TWRFVnpTU2ZCMk10SGRUSkp0QldaNjgzd0VGUzFLK0szZ250Q1li?= =?utf-8?B?cTNiVFltVDhjVnZhcTY0VWplc1dkUS9ERVo1SERSTUN5blFUaEdvc2tocWFh?= =?utf-8?B?ZkJta0ZrTi9tZWtsNW1obVhTL01idlN6eG41Qzlzb1FRMnk5NStyWFBZU2lq?= =?utf-8?B?UWs1MG5XVFNWeGxrQlJ3TXU3aEQ2eUJiM2UzZTBWQWNzUGVsSnlzZE9MbEty?= =?utf-8?B?U2NiMk1ENmViMnpuTi9GTE41T3MrQWR4OTJFK201VFdvM1ozdGFab2J6eklV?= =?utf-8?B?VUx0dnNBaWN6M1hUODR1NnpyRzZKMi9tVlpaNFY4bkF1M3F2NW1Na09rWWRB?= =?utf-8?B?OGo2eGd2QXd1enBRaTcvRHozVXlsSVg4K3pvSU9kZWVnNmhuU09Hc2NFWEJ0?= =?utf-8?Q?cLo+SvbiI7ZcAF7e0Ve6iP+s1qaGhKbD8SeD2VT?= X-Microsoft-Exchange-Diagnostics: 1; BN6PR05MB3425; 6:v8/g19QQweK4kSZT5vMYgpolgTT7uvxw1mWd6Gsk/X92xcQup4LEqhdWqEr8UkwOSeRlGjG0Qh3gAZqtQnZdKdnPZdDP43lA/XLAHlZHqUdJ1egrNLMqErhEUKDAH7xbTHlO/p2JQoZdAc9a7Shqj5wteNk7eqUz9PTCwlxNXHL4xRllVGi/dP0HGy789giK6KC9P2PLNcHUToxNZKWaqJYd0UyogMjmdOsxox0nS/2CcjmRWSOC9+xu/dSn65mLmpFawDJj0i4uhvE6uGFx1ld11k7aOIFi3DmhjTm4pXllbIteyH06nvulsc3+y+8dhbLB0pqJGVB+XiBO7wu74g==; 5:JNMrb34/ABXjel1X2xdnfu7l8tkZVJ391bVjOwDjV15Ek8iXNlSPXfwbeL/p+D5AQcuYHxH1Qs2Wj3OEVme9JZWeH7MpgwZ42ywMN94OCd/V5VmG0v7NJsRFOuJPHjnGEtDFDMwy1Q98KDTm1kTNLQ==; 24:+DMQHk6jWN7V0SK4kGb1Uq85iFhtCNN6+XPpk81C5k7BukmFdzWicJkdAj88N1/F5IY8n4PpsRaJtDNzXu8hOd/EEdP9MvY6JUsM/RI1br4=; 7:45E4OjvNbD2x3urixfpo73ZkrbQ69UTNOBDbrYfhWsHpEO4Ls2VjXfX6lH19xcqAeGebV3OYRuJZgYDmoI2VE7H1h10epInJBZxh65NAt5LdPUsX9X3RpZ5fJ51WyBWLk/w4ZGec/ZZqlivPtj8++wzQaG/aGztpSDNJVAa0IAtVvhg0h6cA6pQ/SLA4/FXQ61jC1enRtL5rXT17RCA/N7ZaV84IfIDOBwE3+4bPlIE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Aug 2017 19:57:48.5318 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB3425 Archived-At: Subject: Re: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 16 Aug 2017 19:57:55 -0000 Salz, Rich writes: > We have adopted draft-ietf-curdle-rc4-die-die-die. Full doc details > are at > https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ >=20 > There are concerns that this document is over-reaching our charter, > and that a document to remove RC4 from all protocols is beyond our > scope. It is hard to argue with that =E2=98=BA >=20 > Should we ask to expand the charter? Daniel suggested maybe a crypto > policy document, but that probably belongs in SAAG or even IESG. >=20 > So what should be taken out of this document so that we can move > forward? Or should we ask for the ability to condemn RC4 for all of > the IETF? Yes, this is probably technically an IESG issue. I think that means it is up to our ADs if they want to shepherd this document to the general IESG, or split it into multiple RFCs for each area. I am just not sure. That said, I believe RC4 should be condemned for all of the IETF. So, who do we need to ask for the ability to speak for all of the IETF about the insecurity of RC4? -- Mark From nobody Wed Aug 16 17:34:32 2017 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 5CFA5132143; Wed, 16 Aug 2017 17:34:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, Daniel Migault , curdle-chairs@ietf.org, daniel.migault@ericsson.com, curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150293007037.12129.14495426099827537268.idtracker@ietfa.amsl.com> Date: Wed, 16 Aug 2017 17:34:30 -0700 Archived-At: Subject: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-cms-ecdh-new-curves-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Aug 2017 00:34:30 -0000 Adam Roach has entered the following ballot position for draft-ietf-curdle-cms-ecdh-new-curves-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This citation does not appear to be used anywhere in the document, and RFC 5480 is not mentioned (at least, not by number): [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. From nobody Wed Aug 16 23:12:43 2017 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 3EE0A1323B1 for ; Wed, 16 Aug 2017 23:12:42 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CIPn_s_pfi7r for ; Wed, 16 Aug 2017 23:12:40 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E82291321BF for ; Wed, 16 Aug 2017 23:12:39 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id o85so25284076lff.3 for ; Wed, 16 Aug 2017 23:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MAhZIcewtJTL5ZL/tL09fUKZboH+Qq9dgJswJ9agNV0=; b=ll91WF82zmwCAUB/F9Rj1cafS5faMtN9uidotI7Cxqu/RdLFAVSC7EwZEyDwW2D1gz 2k4HIkHOAu6aDXGZu17CVIqcwK8NTS7UC/V8F1az8YZ0m3eoB95XrDhOZ2CpnBehMqZg czf3VDGE/LB2oPTipKJRrRPw8umQIQd5AfH7g1Eq8v69VkU66y2x1WjTt3SCisLJU29X 0qOCWQCH70I1txGgwdM5tO3Je/HAtKjJR0zD7YN2JCuVRh+A3W8UPx2aso6HckexBFPO 8cPZm7SnglBY99NtPXdgRJwyBnQuUkRCHgd7J50Q2EWwR7egEmqUKzzOtQA5FIDRsz+B M1tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MAhZIcewtJTL5ZL/tL09fUKZboH+Qq9dgJswJ9agNV0=; b=QPEfnU1DDpNugxeN7DdkrAQLibLRiT6zM80hBQXLKE5lHt0xJcP+T/vG8ZytBnn9k7 9xqWcv+/SyaiINIECa6kz+PdhqdjCEl9u5IytjtOFGWIT6OOoUaBk1fNLawxdwcpId2K q8dbRsnc8GUQ/PwtQfl5XhEe38bCFHzw4pV9rchSBFw/LIY6x2nkA3/rCaHTs3nPt7KU fWmfKdfeuO2LGdb7/NOOeq189Er/JLOK2fKweu+guByh1eG3pKz/QIOj0IDcNovRm9oz YXwXkTz64MWcyjZvsLr9Ge6xYrFeH+3BVZEQsvtIo/RAOZSmRNuny0yJgYu54KK9AXN5 DKsw== X-Gm-Message-State: AHYfb5iSKwRwYqtDDHeBlg1yo9TwG4ae5yPu0F1PYjBX/8eo6VUpnMCu hlZ5cEErlpeYU0qyLh6l7S1Vh9I+eg== X-Received: by 10.46.81.1 with SMTP id f1mr1573893ljb.142.1502950358151; Wed, 16 Aug 2017 23:12:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.20.81 with HTTP; Wed, 16 Aug 2017 23:12:37 -0700 (PDT) In-Reply-To: References: From: Loganaden Velvindron Date: Thu, 17 Aug 2017 10:12:37 +0400 Message-ID: To: "Salz, Rich" Cc: "curdle@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Aug 2017 06:12:42 -0000 On Wed, Aug 16, 2017 at 11:48 PM, Salz, Rich wrote: > We have adopted draft-ietf-curdle-rc4-die-die-die. Full doc details are at > https://datatracker.ietf.org/doc/draft-ietf-curdle-rc4-die-die-die/ > > > > There are concerns that this document is over-reaching our charter, and that > a document to remove RC4 from all protocols is beyond our scope. It is hard > to argue with that J > > > > Should we ask to expand the charter? Daniel suggested maybe a crypto policy > document, but that probably belongs in SAAG or even IESG. > > > > So what should be taken out of this document so that we can move forward? > Or should we ask for the ability to condemn RC4 for all of the IETF? > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > I think that it's better that the document is broken up into smaller documents for each protocol that uses RC4. It appears to overlaps with other drafts that are targetting specific documents. From nobody Thu Aug 17 08:32:07 2017 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 DFBFE132144 for ; Thu, 17 Aug 2017 08:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8uJm5113STGd for ; Thu, 17 Aug 2017 08:32:05 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB8E1321B7 for ; Thu, 17 Aug 2017 08:32:05 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7HFRkqv026062; Thu, 17 Aug 2017 16:32:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=H+nG9NHseP8j4vZCDeLxq0gkyasL8rqgIWkzIsik4/I=; b=Ph99dzBv+9TLFr+uv4X77WR7iIYUSSvIsXILub2AaW3Tob9cZIFwdTO5SfAWEEV+M9io cxXkWVv5jP1XvjPiVq8lDf3RUHtz94OPuoFBJlTnLgNhgsvbaEWcbd6Fpjqkry8yAKr7 wCqmXak44gn8q5UI205ezbKmKlG2doPjXPnz8BilcmlAuLDfjH8ejA5S8YgNWmUyC9FX GFKB2u3LO771XkCKU6P02aOzxU6ZBUxg6x1eiZAOzKIJ1wggdvfcndcmnwd20RDqhl+7 3zsVDBxiSoGYRbiKUdPriOO56vL2WOKVY9OK60mRen9Ci2we9XXn4qWlqbZTR37djR7D tg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2cc6dv6t1s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 16:32:04 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7HFVfpA011875; Thu, 17 Aug 2017 11:32:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cc6cvfqgb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 11:32:02 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 17 Aug 2017 11:32: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.1263.000; Thu, 17 Aug 2017 11:32:01 -0400 From: "Salz, Rich" To: "Mark D. Baushke" CC: "curdle@ietf.org" Thread-Topic: [Curdle] Adoption of rc4-die-die-die document Thread-Index: AQHTFsnxXfoOISFJvEij3YWyT+v8WKKIrlsA Date: Thu, 17 Aug 2017 15:32:00 +0000 Message-ID: <2F006ADF-DEA8-4E9B-8066-BD4F023857AC@akamai.com> References: <98476.1502913419@eng-mail01.juniper.net> In-Reply-To: <98476.1502913419@eng-mail01.juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.156] Content-Type: text/plain; charset="utf-8" Content-ID: <129D616BDB0E9F4CB80252DA76486CC0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170257 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170256 Archived-At: Subject: Re: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Aug 2017 15:32:07 -0000 4p6iIFRoYXQgc2FpZCwgSSBiZWxpZXZlIFJDNCBzaG91bGQgYmUgY29uZGVtbmVkIGZvciBhbGwg b2YgdGhlIElFVEYuIFNvLA0K4p6iIHdobyBkbyB3ZSBuZWVkIHRvIGFzayBmb3IgdGhlIGFiaWxp dHkgdG8gc3BlYWsgZm9yIGFsbCBvZiB0aGUgSUVURiBhYm91dA0K4p6iIHRoZSBpbnNlY3VyaXR5 IG9mIFJDND8NCiAgICANCkl0IHdvdWxkIHN0YXJ0IHdpdGggb3VyIEFELCBFcmljLiAgUGluZyBF cmljIOKYug0KDQo= From nobody Thu Aug 17 08:52:00 2017 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 8297E1321DF for ; Thu, 17 Aug 2017 08:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AzP0ApBJ_PI for ; Thu, 17 Aug 2017 08:51:52 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5410C132144 for ; Thu, 17 Aug 2017 08:51:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9C71B300541 for ; Thu, 17 Aug 2017 11:51:51 -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 LsKHooWvp6wF for ; Thu, 17 Aug 2017 11:51:49 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 688253002A3; Thu, 17 Aug 2017 11:51:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <150293007037.12129.14495426099827537268.idtracker@ietfa.amsl.com> Date: Thu, 17 Aug 2017 11:51:48 -0400 Cc: IESG , draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <150293007037.12129.14495426099827537268.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Adam Roach's No Objection on draft-ietf-curdle-cms-ecdh-new-curves-09: (with COMMENT) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Aug 2017 15:52:00 -0000 Adam: It looks like the reference was used on the early versions of this = draft, and dropped in -04. I'll submit an update to drop the reference = when IESG evaluation is finished. Russ > On Aug 16, 2017, at 8:34 PM, Adam Roach wrote: >=20 > Adam Roach has entered the following ballot position for > draft-ietf-curdle-cms-ecdh-new-curves-09: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > This citation does not appear to be used anywhere in the document, and = RFC 5480 > is not mentioned (at least, not by number): >=20 > [PKIXECC] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, > "Elliptic Curve Cryptography Subject Public Key > Information", RFC 5480, March 2009. >=20 >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Aug 17 09:35:15 2017 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 872081321D2 for ; Thu, 17 Aug 2017 09:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bopukXykdhdM for ; Thu, 17 Aug 2017 09:35:12 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80064132190 for ; Thu, 17 Aug 2017 09:35:12 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id n83so16440156ywn.2 for ; Thu, 17 Aug 2017 09:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Tm2c4J2M3rn/wog3JKJQpXWsLM0Xt9OwWfY5Tq71vBQ=; b=kF+dg7eZYtbsDb1jtANyGN7hPwbMUrARnGbU7Vb+wEtyRk8GHdDFlp6F91oAiEsnBV dzSeVlv1iB1NKE6SkVt2xi180xeMpiFDMPc4L0S0+tNIn9JYFZCgJbjiELgpM0TirzXp RnlCyQtrTC2h+udp3i+7TJ6YaxSKiK/Kx07l6mVAC/7OOEFwajMhnWlrC18cQdBPvUuU 3N92Ej0zN217IdKQ+Vd0M8HmZCQiJkEQX9Ay9e0Nn7hBd52FRBuN4V2VHjlg9rZ11Ucw FQoMWqDxyr3Wzr/X0lqtER96XNiLsztVtYncTtLdPhysglrJq2D2v2lDtTMZ43Gu6BYk JCtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Tm2c4J2M3rn/wog3JKJQpXWsLM0Xt9OwWfY5Tq71vBQ=; b=qixeMt43mAb4CDIvWpZyRgRAc9qFyTN4gZtuX/Pu4iv32sI/zi132QT9ErU1mfOlZS eD82iOKkPyVdMAoYX5r03VeEUF4mnPpVvq2vH6kEgqcVjGeLJ077RzXnt0r2L1uJX8A/ TLeihZiDbk6VdjZeKB0lCUh9fAWWtYXBygoOepyDF5CSUXy3Sdag60+cz1py42gUTDOF MqXoYs+HuUvI8hzslisl5cmrQ6fb/xT1BgNQIAi6spJmDa192W5q/2Xb+IXZXP6ZhEXK ncugren2sGpOdTLUf14JYNpSCIT8bLY+du41Tv8tI+5MDmRsP+4EC46w2d2ap6qvbFhX PCgQ== X-Gm-Message-State: AHYfb5iArH2TFiOqsN/QL7WZwV/Hq8HehEu5BJGGTXQHslmE8Bzohr8Y k7SZn9fgvT5EGUK7RsCiv6PQEuYpe+6Z X-Received: by 10.37.78.65 with SMTP id c62mr5098292ybb.345.1502987711758; Thu, 17 Aug 2017 09:35:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Thu, 17 Aug 2017 09:34:31 -0700 (PDT) In-Reply-To: <2F006ADF-DEA8-4E9B-8066-BD4F023857AC@akamai.com> References: <98476.1502913419@eng-mail01.juniper.net> <2F006ADF-DEA8-4E9B-8066-BD4F023857AC@akamai.com> From: Eric Rescorla Date: Thu, 17 Aug 2017 09:34:31 -0700 Message-ID: To: "Salz, Rich" Cc: "Mark D. Baushke" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="001a113e7984a97c000556f59822" Archived-At: Subject: Re: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 17 Aug 2017 16:35:14 -0000 --001a113e7984a97c000556f59822 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Kathleen and I are discussing how best to proceed and will get back to you shortly. Best, -Ekr On Thu, Aug 17, 2017 at 8:32 AM, Salz, Rich wrote: > =E2=9E=A2 That said, I believe RC4 should be condemned for all of the IET= F. So, > =E2=9E=A2 who do we need to ask for the ability to speak for all of the I= ETF about > =E2=9E=A2 the insecurity of RC4? > > It would start with our AD, Eric. Ping Eric =E2=98=BA > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113e7984a97c000556f59822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Kathleen and I are discussing how best to proceed and will= get back to you shortly.

Best,
-Ekr


= On Thu, Aug 17, 2017 at 8:32 AM, Salz, Rich <rsalz@akamai.com> wrote:
=E2=9E=A2 That said, I believe= RC4 should be condemned for all of the IETF. So,
=E2=9E=A2 who do we need to ask for the ability to speak f= or all of the IETF about
=E2=9E=A2 the insecurity of RC4?

It would start with our AD, Eric.=C2=A0 Ping Eric =E2=98=BA

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

--001a113e7984a97c000556f59822-- From nobody Fri Aug 18 06:07:26 2017 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 DEF4F132064 for ; Fri, 18 Aug 2017 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNxIuJQhe13D for ; Fri, 18 Aug 2017 06:07:23 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::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 3AABA1204DA for ; Fri, 18 Aug 2017 06:07:23 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u207so58434630ywc.3 for ; Fri, 18 Aug 2017 06:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lfnhd9/39NPFROb9cKvTImw1cAeQ1tmu0lT7JpyCqMI=; b=KzAO82reYGaHd+WocTkI4tzsKQTam3UwQEU/hH1+7XRoUkei0+9CV/g2gumk3kSEI1 V/ekxPy47ap5EjXFpocJoObod/R9Usj2v3hdy9DFOtF/m8JxAqaWUnAASrdIbb7jk83Z DQzeOnA9c62b9lCAr5QNxjxExiWq5bB8bfp8JCOmAaMeaQM1Z7uenkNnYQpPfqt+SrYC bUaXsRuxA7XEktyGY/oXp62CODEDlmv8gHfulTt00Guxh9M3j3fCkQ+CGJ7BBe8+JwFH 315CYJMwwt2yyAOpAkvDsnQUx+JAM0+7SQfMFqE6mMh8Rci1Jtrj8ma0wYYI6FB0in1M h36A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lfnhd9/39NPFROb9cKvTImw1cAeQ1tmu0lT7JpyCqMI=; b=RlV+gWJ9HSuB2YBk5NU18tMEicR2MCur1ahzArgCbXYsc7N2cBzWDnWf308kiACmr8 BpjW/gEu05jE9jXs5zXhMdxUGG8pd/u80bGwEJK/0LLFktN5FNYWxCTS8sxMfGTPF1Lz WVHF7Uawq3d0/59D64Nd+VJJfYWRgH2sXRzVxDyk1LYbobOQMVmStsT8FgMX4PnrFE7l wYJmq00FaGqlSzJMT734qhU+we6VOVUQw1VL5Rz28gJ1PtACEFgng7qcI0EJRiXo18Jq x2pN+uLHdkhdrO/0a/0/HU3f04PXXr/bVDmEoLGtJPDZJh1vmk/5QtNKEhMuaRWPa11T kzIA== X-Gm-Message-State: AHYfb5ghHZkwql4Cko5tSPHk3rj2tYF2iYvEkKgzeFbAiVAgY0/eVjsa sme6qHYs/X8Tlpv/+OOBFw6KWvRapJg7 X-Received: by 10.37.45.74 with SMTP id s10mr7180515ybe.204.1503061642502; Fri, 18 Aug 2017 06:07:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 18 Aug 2017 06:06:41 -0700 (PDT) In-Reply-To: References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> From: Eric Rescorla Date: Fri, 18 Aug 2017 06:06:41 -0700 Message-ID: To: denis bider Cc: "Mark D. Baushke" , Daniel Migault , curdle , Loganaden Velvindron Content-Type: multipart/alternative; boundary="f4030435c9f0470556055706cfb2" Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Aug 2017 13:07:25 -0000 --f4030435c9f0470556055706cfb2 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 11, 2017 at 9:56 AM, denis bider wrote: > I would also like to see it specified, but for a standards track document, > the main obstacle I see is the need for 2 implementations. > AD here. Without taking a position on Ed448, there is no requirement for 2 implementations for Proposed Standard. -Ekr > > I generally loathe to implement something before OpenSSH, because my > installed base is maybe 1% of theirs, so even if I follow the spec, and > they implement it later but make a deviation, chances are that (1) they > won't care about compatibility with my implementation, (2) they will not > test against my implementation, and (3) I will be adapting to their > implementation, and not the other way around. > > For these reasons, I am hesitant to implement something OpenSSH has not > yet implemented, but might implement in the future, until they have > actually done so. If I go first, then what they do will override my effort > if/when they implement it. > > denis > > > On Fri, Aug 11, 2017 at 10:02 AM, Mark D. Baushke wrote: > >> Hi Daniel & Loganaden, >> >> I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06 >> draft specifies both Curve25519 and Curve448 even though only Curve25519 >> has been implemented by OpenSSH. >> >> -- Mark >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --f4030435c9f0470556055706cfb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 11, 2017 at 9:56 AM, denis bider <denisbider.ietf@= gmail.com> wrote:
I would also like to see it specified, but for a standards track d= ocument, the main obstacle I see is the need for 2 implementations.

AD here. Without taking a position on Ed448,= there is no requirement for 2 implementations for Proposed Standard.
=

-Ekr
=C2=A0

I generally loathe to implement som= ething before OpenSSH, because my installed base is maybe 1% of theirs, so = even if I follow the spec, and they implement it later but make a deviation= , chances are that (1) they won't care about compatibility with my impl= ementation, (2) they will not test against my implementation, and (3) I wil= l be adapting to their implementation, and not the other way around.
<= div>
For these reasons, I am hesitant to implement something = OpenSSH has not yet implemented, but might implement in the future, until t= hey have actually done so. If I go first, then what they do will override m= y effort if/when they implement it.

denis


=
On Fri, Aug 11, 2017 at 10:02 AM, Mark D. Baushk= e <mdb@juniper.net> wrote:
H= i Daniel & Loganaden,

I see no reason not to specify ed448. The draft-ietf-curdle-ssh-curves-06
draft specifies both Curve25519 and Curve448 even though only Curve25519 has been implemented by OpenSSH.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

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


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

--f4030435c9f0470556055706cfb2-- From nobody Fri Aug 18 06:25:42 2017 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 84473132055 for ; Fri, 18 Aug 2017 06:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqiuHRABUu5j for ; Fri, 18 Aug 2017 06:25:38 -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 3ACF9132391 for ; Fri, 18 Aug 2017 06:25:36 -0700 (PDT) X-AuditID: c618062d-b93ff70000004f0a-cc-599701c7cf24 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.F8.20234.7C107995; Fri, 18 Aug 2017 17:03:35 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0352.000; Fri, 18 Aug 2017 09:25:35 -0400 From: Daniel Migault To: James Cloos , Damien Miller CC: "Mark D. Baushke" , curdle , denis bider , Loganaden Velvindron Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt Thread-Index: AQHTFHj+eaHhXkuIiU23BQcEV1ZR+6KKH4TA Date: Fri, 18 Aug 2017 13:25:35 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0AEE@eusaamb107.ericsson.se> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> <10852.1502475580@eng-mail01.juniper.net> 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.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyuXRPiO5xxumRBi1LDCwuzp3DZrF14Sxm i+Pn5jJbXPn2jMni68T5rBZdd66zObB57Jx1l91j77ZFrB5Llvxk8ri0eCurx/Wmq+we3z61 swWwRXHZpKTmZJalFunbJXBlzNr/hbXgCn/Fi2PnGRsYF/B3MXJySAiYSJz5uJK5i5GLQ0jg KKPE4ql/GSGc5YwSs65fYgapYhMwkmg71M8OYosIuEhcnbaOCaSIWWAqo8TpTyeAijg4hAXc JA688wExRQTcJRbNzYMoN5LYP+0CWAWLgKrE5fdOIGFeAV+J8yfa2SBWTWaReHXmMRNIglPA QOLQrJ9gNqOAmMT3U2vAbGYBcYlbT+YzQRwtILFkz3lmCFtU4uXjf6wQtpLEx9/z2UF2MQto SqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKkaO0uCAnN93IYBMj MLKOSbDp7mC8P93zEKMAB6MSD6/hy2mRQqyJZcWVuYcYJTiYlUR4BZ4BhXhTEiurUovy44tK c1KLDzFKc7AoifNOOH8hQkggPbEkNTs1tSC1CCbLxMEp1cDYlLKULXLT/WqtCHb1NbzvAr02 Oyy/HswmM0X0sJ/D5JrNHeGx3x3YVpmkNLC/zda7I9+QfrjLx1pDL756ygpdsS9TPl1eEteu 92fzpsLN6wJeyppus3z6RF7ALtRa8Dzv9nl5MsfS2s3Nje/znAg9fH+/3p6mO/sX8fpZKxQ7 sUU/Fz0taKXEUpyRaKjFXFScCAA87mxIqAIAAA== Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Aug 2017 13:25:40 -0000 VGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uIEkgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGEgY29u c2Vuc3VzIGluIGFkZGluZyBFZDQ0OCBpbiB0aGUgZG9jdW1lbnQuICANCg0KSWYgcGVvcGxlIGFy ZSBub3QgY3VycmVudGx5IHdvcmtpbmcgb24gaXQgZm9yIG9wZW5zc2gsIG1heWJlIGl0IHdvdWxk IHdvcnRoIG1ha2luZyBhIGNvZGUgcmVxdWVzdCBbMV0gd2l0aCB0aGUgbmVjZXNzYXJ5IGluZm9y bWF0aW9uIHNvIHBlb3BsZSBjYW4gZWFzaWx5IHZvbHVudGVlciBhbmQgY29udHJpYnV0ZS4gSSBh bSBoYXBweSB0byBoZWxwIGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbiByZWdhcmRpbmcgY29kZXN0 YW5kLg0KDQpZb3VycywgDQpEYW5pZWwNCg0KWzFdIGh0dHBzOi8vY29kZXN0YW5kLmlldGYub3Jn L2NvZGVzdGFuZC8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEphbWVzIENs b29zIFttYWlsdG86Y2xvb3NAamhjbG9vcy5jb21dIA0KU2VudDogU3VuZGF5LCBBdWd1c3QgMTMs IDIwMTcgNToxMyBQTQ0KVG86IERhbWllbiBNaWxsZXIgPGRqbUBtaW5kcm90Lm9yZz4NCkNjOiBN YXJrIEQuIEJhdXNoa2UgPG1kYkBqdW5pcGVyLm5ldD47IERhbmllbCBNaWdhdWx0IDxkYW5pZWwu bWlnYXVsdEBlcmljc3Nvbi5jb20+OyBjdXJkbGUgPGN1cmRsZUBpZXRmLm9yZz47IGRlbmlzIGJp ZGVyIDxkZW5pc2JpZGVyLmlldGZAZ21haWwuY29tPjsgTG9nYW5hZGVuIFZlbHZpbmRyb24gPGxv Z2FuQGhhY2tlcnMubXU+DQpTdWJqZWN0OiBSZTogW0N1cmRsZV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1jdXJkbGUtc3NoLWVkMjU1MTktMDEudHh0DQoNCj4+Pj4+ICJETSIgPT0gRGFtaWVuIE1p bGxlciA8ZGptQG1pbmRyb3Qub3JnPiB3cml0ZXM6DQoNCkRNPiBJIGxvb2tlZCBhdCBhZGRpbmcg ZWQ0NDggdG8gT3BlblNTSCBhIHdoaWxlIGJhY2sgYW5kIGdvdCBzdHVjayANCkRNPiBsb29raW5n IGZvciBhIHN0YW5kYWxvbmUgZWQ0NDggaW1wbGVtZW50YXRpb24gdGhhdCB3YXMgYXMgc21hbGws IA0KRE0+IHNlbGYtY29udGFpbmVkLCBjbGVhbiBhbmQgc3VpdGFibHkgbGljZW5zZWQgYXMgdGhl IGVkMjU1MTkgdGhhdCB3ZSB1c2UgKGZyb20gU3VwZXJjb3ApLg0KDQpQb3dlcmRucyB1c2VzIE1p Y2hhZWzigJlzIGxpYmRlY2FmwrkgZm9yIDQ0OC4NCg0KSXQgdXNlcyB0aGUgbWl0IGxpY2Vuc2Uu ICBJZiB5b3UgcHJlZmVyLCB0aGUgeDQ0OCBicmFuY2ggaGFzIGFuIGltcGxlbWVudGF0aW9uIHdp dGggb25lIC5jIGFuZCBvbmUgLmgsIGFsc28gbWl0LiAgWW91IGNvdWxkIGp1c3QgZ3JhYiB0aG9z ZSB0d28gZmlsZXMuDQoNCjFdIGdpdDovL2dpdC5jb2RlLnNmLm5ldC9wL2VkNDQ4Z29sZGlsb2Nr cy9jb2RlLmdpdA0KDQotSmltQw0KLS0gDQpKYW1lcyBDbG9vcyA8Y2xvb3NAamhjbG9vcy5jb20+ ICAgICAgICAgT3BlblBHUDogMHg5OTdBOUYxN0VEN0RBRUE2DQo= From nobody Fri Aug 18 06:52:03 2017 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 4AE6A1323C0 for ; Fri, 18 Aug 2017 06:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hackers-mu.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 CBbNAODlZNkh for ; Fri, 18 Aug 2017 06:52:00 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 E885412008A for ; Fri, 18 Aug 2017 06:51:59 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id f11so96946212oic.0 for ; Fri, 18 Aug 2017 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hackers-mu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IgiVLaqFNnimISvR+QcG9mTXI6T3u5Thyh1e+fIB+7Q=; b=FbCFgTZ2DAEX1stfyUFsVQphcoAItpPiOKe2IpPvwtwqYfSahhs8lQkBFEjl90Vq+5 h850avjXPQCN4HXsTzunACs1SQDEzNEVN7ttgpbhKSgN6lMh5LIAPQShetg6o4OvmwRs hBtZUL6OxaFEQE5VbpC+18qWpX47GYM1ecXfWmw/fPen7ktojZqvSK/QscD8k7ihbNOZ S7XfC6CcPxZM+FA7TgNzVZp7v0YVLxrd43zRTggAth9vV+qrSPTk+mvI1aaTtqhztR14 lOO0ocqDDzKwKlH4/FOMPnsNUiLAHv87Qwe7HZ1n7NUKaYsPjcDOpxyfIU9BejD5b70p Bxjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=IgiVLaqFNnimISvR+QcG9mTXI6T3u5Thyh1e+fIB+7Q=; b=E2QYTGbmDO8jnFzym+/QSLfwDB0rrrbJwOd3csVmHoqmxTytrHkR+hCj+RELcoxKdU WeIbqylK+ouS0HL4eG2rgyMuAhPWcHfZylw5sq/VEIM6Q3+x+q/in+NgaW6FXIODrFdW vqnb0iG/uW9ZlYzj3CO/w5Ew19YBiaePQdViWNRoIyYHD82mZJylIVSM0Z3Re2PP1N5v 4IJVLtKi5B8fhZ7EIbKrh6I5PpjxeV0ki6+nFJyxIY+7oj8tb9QavUXBTjtAbRCcngH+ G3YcWGIH07zuqzE7qz+iHgGjTM36vTAuKIGMsOi2lGG3s3ncxrn0oOuZUFlPXPQ0nPF9 kK9g== X-Gm-Message-State: AHYfb5hGC9xy89vVe0x3faolUAFMXoQl+1Lh9dKIcPpUxy3JD2fmDtnW qx6dolo3/1IfExdxbtP8yWQbH4tWo9lu X-Received: by 10.202.241.131 with SMTP id p125mr10728666oih.4.1503064318976; Fri, 18 Aug 2017 06:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.139.137 with HTTP; Fri, 18 Aug 2017 06:51:58 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0AEE@eusaamb107.ericsson.se> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> <10852.1502475580@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0AEE@eusaamb107.ericsson.se> From: Loganaden Velvindron Date: Fri, 18 Aug 2017 17:51:58 +0400 Message-ID: To: Daniel Migault Cc: James Cloos , Damien Miller , "Mark D. Baushke" , curdle , denis bider Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Aug 2017 13:52:02 -0000 On Fri, Aug 18, 2017 at 5:25 PM, Daniel Migault wrote: > Thanks for the information. I believe that there is a consensus in adding= Ed448 in the document. > I will update the document to include ED 448. > If people are not currently working on it for openssh, maybe it would wor= th making a code request [1] with the necessary information so people can e= asily volunteer and contribute. I am happy to help if you have any question= regarding codestand. > > Yours, > Daniel > > [1] https://codestand.ietf.org/codestand/ I'm registering on codestand. > > -----Original Message----- > From: James Cloos [mailto:cloos@jhcloos.com] > Sent: Sunday, August 13, 2017 5:13 PM > To: Damien Miller > Cc: Mark D. Baushke ; Daniel Migault ; curdle ; denis bider ; Loganaden Velvindron > Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt > >>>>>> "DM" =3D=3D Damien Miller writes: > > DM> I looked at adding ed448 to OpenSSH a while back and got stuck > DM> looking for a standalone ed448 implementation that was as small, > DM> self-contained, clean and suitably licensed as the ed25519 that we us= e (from Supercop). > > Powerdns uses Michael=E2=80=99s libdecaf=C2=B9 for 448. > > It uses the mit license. If you prefer, the x448 branch has an implement= ation with one .c and one .h, also mit. You could just grab those two file= s. > > 1] git://git.code.sf.net/p/ed448goldilocks/code.git > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Fri Aug 18 06:56:53 2017 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 4E09A1323C9 for ; Fri, 18 Aug 2017 06:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzm0J9BlUm-b for ; Fri, 18 Aug 2017 06:56: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 AFD4F12008A for ; Fri, 18 Aug 2017 06:56:47 -0700 (PDT) X-AuditID: c618062d-b93ff70000004f0a-c4-599709162104 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 82.5B.20234.61907995; Fri, 18 Aug 2017 17:34:46 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0352.000; Fri, 18 Aug 2017 09:56:45 -0400 From: Daniel Migault To: Loganaden Velvindron CC: James Cloos , Damien Miller , "Mark D. Baushke" , curdle , denis bider Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt Thread-Index: AQHTFHj+eaHhXkuIiU23BQcEV1ZR+6KKH4TAgABM6QD//742sA== Date: Fri, 18 Aug 2017 13:56:45 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0B32@eusaamb107.ericsson.se> References: <150211507673.19050.13323214544773773031@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118CCF00A@eusaamb107.ericsson.se> <4054.1502467345@eng-mail01.juniper.net> <10852.1502475580@eng-mail01.juniper.net> <2DD56D786E600F45AC6BDE7DA4E8A8C118CD0AEE@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.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXSPn64Y5/RIgy+HTCwuzp3DZrF14Sxm i+Pn5jJbXPn2jMni68T5rBZdd66zObB57Jx1l91j77ZFrB5Llvxk8ri0eCurx/Wmq+we3z61 swWwRXHZpKTmZJalFunbJXBlTGr2LbghVnG2dy9TA2OPWBcjJ4eEgInE8defGbsYuTiEBI4y Srzs+A3lLGeU2H6znRWkik3ASKLtUD97FyMHh4iAtkTfwQKQGmaBDYwSn1qOMoLEhQXcJA68 84EocZdYNDcPpFNEwEliw7WTbCA2i4CqxL2//8BsXgFfiV0LbkOtmscqsWnrBbAxnAKBEp9X GYHUMAqISXw/tYYJxGYWEJe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStJfPw9H+xKZgFNifW7 9CFaFSWmdD9kh1grKHFy5hOWCYyis5BMnYXQMQtJxywkHQsYWVYxcpQWF+TkphsZbGIERtUx CTbdHYz3p3seYhTgYFTi4d3HPj1SiDWxrLgy9xCjBAezkgivwLNpkUK8KYmVValF+fFFpTmp xYcYpTlYlMR5J5y/ECEkkJ5YkpqdmlqQWgSTZeLglGpgbHWXuh65dcm/3C7Lqy/9Yts/CXVv Xah4MZePWXvO7OrE9Le/BH3PJOy+fPai5JrbJ1el/5G0+33iFNNtw4v3SqY+bxN5EilV5yC9 +bs/69GZNt11tj+ZvTonGsjcEd/LULz6/d6KN9pp9VuETIMN/+y0ZVfZcXxq7p4emdUutsYh dYckK2K/KbEUZyQaajEXFScCAN2TKP2mAgAA Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ed25519-01.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Aug 2017 13:56:52 -0000 R3JlYXQhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb2dhbmFkZW4gVmVs dmluZHJvbiBbbWFpbHRvOmxvZ2FuQGhhY2tlcnMubXVdIA0KU2VudDogRnJpZGF5LCBBdWd1c3Qg MTgsIDIwMTcgOTo1MiBBTQ0KVG86IERhbmllbCBNaWdhdWx0IDxkYW5pZWwubWlnYXVsdEBlcmlj c3Nvbi5jb20+DQpDYzogSmFtZXMgQ2xvb3MgPGNsb29zQGpoY2xvb3MuY29tPjsgRGFtaWVuIE1p bGxlciA8ZGptQG1pbmRyb3Qub3JnPjsgTWFyayBELiBCYXVzaGtlIDxtZGJAanVuaXBlci5uZXQ+ OyBjdXJkbGUgPGN1cmRsZUBpZXRmLm9yZz47IGRlbmlzIGJpZGVyIDxkZW5pc2JpZGVyLmlldGZA Z21haWwuY29tPg0KU3ViamVjdDogUmU6IFtDdXJkbGVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y3VyZGxlLXNzaC1lZDI1NTE5LTAxLnR4dA0KDQpPbiBGcmksIEF1ZyAxOCwgMjAxNyBhdCA1OjI1 IFBNLCBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPiB3cm90ZToN Cj4gVGhhbmtzIGZvciB0aGUgaW5mb3JtYXRpb24uIEkgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGEg Y29uc2Vuc3VzIGluIGFkZGluZyBFZDQ0OCBpbiB0aGUgZG9jdW1lbnQuDQo+DQpJIHdpbGwgdXBk YXRlIHRoZSBkb2N1bWVudCB0byBpbmNsdWRlIEVEIDQ0OC4NCg0KDQoNCj4gSWYgcGVvcGxlIGFy ZSBub3QgY3VycmVudGx5IHdvcmtpbmcgb24gaXQgZm9yIG9wZW5zc2gsIG1heWJlIGl0IHdvdWxk IHdvcnRoIG1ha2luZyBhIGNvZGUgcmVxdWVzdCBbMV0gd2l0aCB0aGUgbmVjZXNzYXJ5IGluZm9y bWF0aW9uIHNvIHBlb3BsZSBjYW4gZWFzaWx5IHZvbHVudGVlciBhbmQgY29udHJpYnV0ZS4gSSBh bSBoYXBweSB0byBoZWxwIGlmIHlvdSBoYXZlIGFueSBxdWVzdGlvbiByZWdhcmRpbmcgY29kZXN0 YW5kLg0KPg0KPiBZb3VycywNCj4gRGFuaWVsDQo+DQo+IFsxXSBodHRwczovL2NvZGVzdGFuZC5p ZXRmLm9yZy9jb2Rlc3RhbmQvDQoNCkknbSByZWdpc3RlcmluZyBvbiBjb2Rlc3RhbmQuDQoNCj4N Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFtZXMgQ2xvb3MgW21haWx0 bzpjbG9vc0BqaGNsb29zLmNvbV0NCj4gU2VudDogU3VuZGF5LCBBdWd1c3QgMTMsIDIwMTcgNTox MyBQTQ0KPiBUbzogRGFtaWVuIE1pbGxlciA8ZGptQG1pbmRyb3Qub3JnPg0KPiBDYzogTWFyayBE LiBCYXVzaGtlIDxtZGJAanVuaXBlci5uZXQ+OyBEYW5pZWwgTWlnYXVsdCANCj4gPGRhbmllbC5t aWdhdWx0QGVyaWNzc29uLmNvbT47IGN1cmRsZSA8Y3VyZGxlQGlldGYub3JnPjsgZGVuaXMgYmlk ZXIgDQo+IDxkZW5pc2JpZGVyLmlldGZAZ21haWwuY29tPjsgTG9nYW5hZGVuIFZlbHZpbmRyb24g PGxvZ2FuQGhhY2tlcnMubXU+DQo+IFN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWN1cmRsZS1zc2gtZWQyNTUxOS0wMS50eHQNCj4NCj4+Pj4+PiAiRE0iID09IERh bWllbiBNaWxsZXIgPGRqbUBtaW5kcm90Lm9yZz4gd3JpdGVzOg0KPg0KPiBETT4gSSBsb29rZWQg YXQgYWRkaW5nIGVkNDQ4IHRvIE9wZW5TU0ggYSB3aGlsZSBiYWNrIGFuZCBnb3Qgc3R1Y2sgDQo+ IERNPiBsb29raW5nIGZvciBhIHN0YW5kYWxvbmUgZWQ0NDggaW1wbGVtZW50YXRpb24gdGhhdCB3 YXMgYXMgc21hbGwsIA0KPiBETT4gc2VsZi1jb250YWluZWQsIGNsZWFuIGFuZCBzdWl0YWJseSBs aWNlbnNlZCBhcyB0aGUgZWQyNTUxOSB0aGF0IHdlIHVzZSAoZnJvbSBTdXBlcmNvcCkuDQo+DQo+ IFBvd2VyZG5zIHVzZXMgTWljaGFlbOKAmXMgbGliZGVjYWbCuSBmb3IgNDQ4Lg0KPg0KPiBJdCB1 c2VzIHRoZSBtaXQgbGljZW5zZS4gIElmIHlvdSBwcmVmZXIsIHRoZSB4NDQ4IGJyYW5jaCBoYXMg YW4gaW1wbGVtZW50YXRpb24gd2l0aCBvbmUgLmMgYW5kIG9uZSAuaCwgYWxzbyBtaXQuICBZb3Ug Y291bGQganVzdCBncmFiIHRob3NlIHR3byBmaWxlcy4NCj4NCj4gMV0gZ2l0Oi8vZ2l0LmNvZGUu c2YubmV0L3AvZWQ0NDhnb2xkaWxvY2tzL2NvZGUuZ2l0DQo+DQo+IC1KaW1DDQo+IC0tDQo+IEph bWVzIENsb29zIDxjbG9vc0BqaGNsb29zLmNvbT4gICAgICAgICBPcGVuUEdQOiAweDk5N0E5RjE3 RUQ3REFFQTYNCg== From nobody Fri Aug 18 14:29:49 2017 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 EF0CC13234C for ; Fri, 18 Aug 2017 14:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d6h1ea1B8zd for ; Fri, 18 Aug 2017 14:29:45 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E7813228D for ; Fri, 18 Aug 2017 14:29:45 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id n83so38264810ywn.2 for ; Fri, 18 Aug 2017 14:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mENMc6EpGSVoocfJicVK3wKuC5yDPCohk7e0pOWe1tE=; b=Z0jdKh8gbi5EOGyMj2u0XSfcNVoZHKKa/vSauDaELT7N+fqBOM7FuBAh+WmPJe4fp3 T9eYTyEFnx2JFRal7cQ/Zr/mizEqzweR03k5tRVg1B2QKXofcg7PAAdrhAJvr1OKBqgO r2EP/p4X/U3F4H9wIrXimdlzZakBEqTaV0xDkZn2oTNbwXCe7DTazx3uJRBR6GKCpClX 0vK+NJ4t035br8mQLNK3ghwuXlAqJyZ8PNFdvFgjJA/XJXdV4EIC8xKaRgj3Fg22lwcX dWTsNlmHIxgxvS0jp0xme3h3T14gfJMtr42rQrcpESXw1OJw2StCaUqNSsjULH+CsBgh YYlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mENMc6EpGSVoocfJicVK3wKuC5yDPCohk7e0pOWe1tE=; b=P4spTUmou2yM+JlJgUPTxqw5h1o8BqA33n5B5gIh/8KoUJxyIPVdQnAKAjYLJ5bQ3v x/6KU4ZtOSplW0yltYpMI/9wphAozzU3wU7hfxsjt/ep3WOWJHgawqzpK+FGJ+j/26Vi lsASM0hgdjfx8GHRGNb9+JWzoul+IRt/Ouv90TH+liLwBhy18jKB6BtQeHEeNsb9pc+8 7Q6lrSA5P+wM7nSR1RX7Wn+nge0LGSQAu47tHpZqKNmZ6CRaMnKU9VEy+X6nQ21R7tjx htVQIhhZ3g1wUlU7xtUBLn3s/OHzyCiRjTpmC7w6C87yEo63uzt66/FCiD07TRr+BAK3 eeow== X-Gm-Message-State: AHYfb5gvYOHIibTchcM0uV0N8jrWJHJPhy2pgqllfRee89lYr2bMgKVK V6pNSF7/Z8oI+ySmwXE+UOFQkNk6ACyy X-Received: by 10.37.45.74 with SMTP id s10mr8381183ybe.204.1503091784884; Fri, 18 Aug 2017 14:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Fri, 18 Aug 2017 14:29:04 -0700 (PDT) In-Reply-To: References: <98476.1502913419@eng-mail01.juniper.net> <2F006ADF-DEA8-4E9B-8066-BD4F023857AC@akamai.com> From: Eric Rescorla Date: Fri, 18 Aug 2017 14:29:04 -0700 Message-ID: To: "Salz, Rich" Cc: "Mark D. Baushke" , "curdle@ietf.org" Content-Type: multipart/alternative; boundary="f4030435c9f0e73afe05570dd3ba" Archived-At: Subject: Re: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Aug 2017 21:29:48 -0000 --f4030435c9f0e73afe05570dd3ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Rich, Given the cross-area nature of this work, we think it would be best if you presented it at the SECDISPATCH meeting in Singapore (see my post a few minutes ago at SAAG for context). Then we can use that process to figure out the best approach. Best, -Ekr On Thu, Aug 17, 2017 at 9:34 AM, Eric Rescorla wrote: > Kathleen and I are discussing how best to proceed and will get back to yo= u > shortly. > > Best, > -Ekr > > > On Thu, Aug 17, 2017 at 8:32 AM, Salz, Rich wrote: > >> =E2=9E=A2 That said, I believe RC4 should be condemned for all of the IE= TF. So, >> =E2=9E=A2 who do we need to ask for the ability to speak for all of the = IETF about >> =E2=9E=A2 the insecurity of RC4? >> >> It would start with our AD, Eric. Ping Eric =E2=98=BA >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > --f4030435c9f0e73afe05570dd3ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rich,

Given the cross-area nature of= this work, we think it would be best if you
presented it at the = SECDISPATCH meeting in Singapore (see my post
a few minutes ago a= t SAAG for context). Then we can use that process
to figure out t= he best approach.

Best,
-Ekr
<= br>

On= Thu, Aug 17, 2017 at 9:34 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
Kathleen and I are di= scussing how best to proceed and will get back to you shortly.

Best,
-Ekr


On Thu, Aug 17, 2017 at 8:32 AM, Salz, Rich <rsalz@akamai.com> wrote:
=E2=9E=A2 That said, I believe= RC4 should be condemned for all of the IETF. So,
=E2=9E=A2 who do we need to ask for the ability to speak for all of t= he IETF about
=E2=9E=A2 the insecurity of RC4?

It would start with our AD, Eric.=C2=A0 Ping Eric =E2=98=BA

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


--f4030435c9f0e73afe05570dd3ba-- From nobody Fri Aug 18 15:46:23 2017 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 4FDF913214D for ; Fri, 18 Aug 2017 15:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dq1sMxCF4t-R for ; Fri, 18 Aug 2017 15:46:20 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 193CC126C7A for ; Fri, 18 Aug 2017 15:46:19 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7IMfaAZ023539; Fri, 18 Aug 2017 23:46:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=wusDM8yPxKrUkTwztJRr+V+TUIR9xSStH8AhlqXkGB8=; b=RMvhIpq00pzeUO4QUtHHX3VHmQss9Fc+zBtEFjY+/6sjQWQiT+zeWH58jxWdy3d01hCU L9aeKfp1cMXI+H5a+DWZwv1cB3s/8iuUIsUNTzS5Pp5JGY6OiVxeAYPFgZea1HTJ7eES wC2a8PVE0AqeUVzhPw3uuFlMijwbXdIba5jaXIy822Pq9/IvPMoG8jnprcrV5oPR0dtR +w4gn62w4PFkzW5zDuYHfLf+9OrdyRvyJuYVi0YbvspcnSvh5hJBZ8wFhx0PfSiKRkTL jvhH1EtQBsGtH+mVKHl109BatAdco4Ta54kFnZo7Qbkung3VTqsslz5kxrdXnOv+e/tN LQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2cc6dvbb2d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 18 Aug 2017 23:46:17 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7IMf6xW012700; Fri, 18 Aug 2017 18:46:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2cc6cvnj24-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 Aug 2017 18:46:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 18 Aug 2017 18:46: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.1263.000; Fri, 18 Aug 2017 18:46:15 -0400 From: "Salz, Rich" To: Eric Rescorla CC: "Mark D. Baushke" , "curdle@ietf.org" Thread-Topic: [Curdle] Adoption of rc4-die-die-die document Thread-Index: AQHTF3bO/gU8zOJx5kir/NO0yGiBKaKK5igA///SgQA= Date: Fri, 18 Aug 2017 22:46:14 +0000 Message-ID: References: <98476.1502913419@eng-mail01.juniper.net> <2F006ADF-DEA8-4E9B-8066-BD4F023857AC@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.217] Content-Type: text/plain; charset="utf-8" Content-ID: <3515B0F853BEF844832F9346E3F7D380@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-18_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708180361 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-18_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708180362 Archived-At: Subject: Re: [Curdle] Adoption of rc4-die-die-die document X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 18 Aug 2017 22:46:21 -0000 DQrinqIgR2l2ZW4gdGhlIGNyb3NzLWFyZWEgbmF0dXJlIG9mIHRoaXMgd29yaywgd2UgdGhpbmsg aXQgd291bGQgYmUgYmVzdCBpZiB5b3UNCnByZXNlbnRlZCBpdCBhdCB0aGUgU0VDRElTUEFUQ0gg bWVldGluZyBpbiBTaW5nYXBvcmUgKHNlZSBteSBwb3N0DQphIGZldyBtaW51dGVzIGFnbyBhdCBT QUFHIGZvciBjb250ZXh0KS4gVGhlbiB3ZSBjYW4gdXNlIHRoYXQgcHJvY2Vzcw0KdG8gZmlndXJl IG91dCB0aGUgYmVzdCBhcHByb2FjaC4NCg0KSGFwcHkgdG8gZG8gc28uDQoNCg== From nobody Sat Aug 19 09:28:18 2017 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 D4760132377 for ; Sat, 19 Aug 2017 09:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCNp45nD13Ho for ; Sat, 19 Aug 2017 09:28:13 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7633E1321C0 for ; Sat, 19 Aug 2017 09:28:13 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id h127so4831393ywf.0 for ; Sat, 19 Aug 2017 09:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5ZZSE++7tyQv498CZzLvicPpFWxkzxdoUupLiFXwbBY=; b=USaU3PBGf3RqiRtSK+ntLpKa21/AnaELWsEu2fbb5E/s7R6KJn1d9FqoT2hVDrs5yP AIvRFvP98FN+weXaa9BE5kQtxe9TtPOSS1rgbcpzRsnlb7DtgAieb2jJhZ5xIZuUzVOG dYOjEsxaLr7rt2Cyk66prOuY377ZtDWYMja9/L1Y1sbQCIe3oVrpIHm+H+OkB7zbYsos uA9ovDwP1FvGVQfzTW+PDbX2FN1qYZmgp8ZbndqQrAUqRvIP+LlvmxhEF2EgmC6HnBT5 2PbgPxzgsf+QW5QEaV6KRAY2CjZqPj7A+Ew44DVbY//E9w4cABmlsKnyPgo75S8Ok9iW JXtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5ZZSE++7tyQv498CZzLvicPpFWxkzxdoUupLiFXwbBY=; b=tZOLv7hWrZL+ZK5R0UDdAfYpdHW6xkVvWsgk9GvX8BkxqYaQOsYi9oKYogGyZx6gqI hl2Wg9i2LCgTQQ6rmHLAFEtAPGeEnE5s0TD891hBxaxoiyulAnBJC46kyOVj4nrFQSSL DU41WctOfBAdT4XRKNV8NQf9e7cRD1bgwEkbWrnbAmluZYswMW8CS8cL9gB1R4+XakJz txMyFQRD5t0//Nwma9PGF2my3bMNMZjEEkbVHBe/fQjFgWpPvQ56LVKjkbx1RUrivrZm YAoKhl/rr/cxnuBrZhsm7g/ZtVH/6IucAW4sehxQ/omkSUuY90W/ZEEJdsBvS8EYngnU wmQA== X-Gm-Message-State: AHYfb5izR5AlrkU8GuTl/mjllIM7fWYAN49Np6gImJUXXFN3J62v3lVK q0iSCxg2KXZNL4tGoh2FVuJ58QOmTB+4 X-Received: by 10.13.251.3 with SMTP id l3mr10635029ywf.71.1503160092808; Sat, 19 Aug 2017 09:28:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Sat, 19 Aug 2017 09:27:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sat, 19 Aug 2017 09:27:32 -0700 Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c07f0365f6dba05571dbbe3" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 19 Aug 2017 16:28:16 -0000 --94eb2c07f0365f6dba05571dbbe3 Content-Type: text/plain; charset="UTF-8" Ping? -Ekr On Tue, Jun 20, 2017 at 3:55 PM, Eric Rescorla wrote: > Usually, I would say "we're getting rid of finite field" :) > > -Ekr > > > On Tue, Jun 20, 2017 at 7:14 AM, denis bider > wrote: > >> I agree, but there has to be a reason it's on its way out. :) This is the >> one reason I know how to phrase. If there's something else I can do >> instead, let me know. >> >> On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla wrote: >> >>> >>> >>> On Mon, Jun 19, 2017 at 8:28 AM, denis bider >>> wrote: >>> >>>> > Either you are using PKCS#1 v1.5 or you are using PSS. >>>> > In the former case, there is no mask function and salt. >>>> >>>> Yikes, thanks. :) This was left over from an early version that >>>> specified PSS. This was before PKCS#1 v1.5 was requested. (The change took >>>> place before any implementation was released, so all deployed >>>> implementations use PKCS#1 v1.5.) >>>> >>>> >>>> > You say in the intro that RSA was defined as 1024 bit >>>> > keys. Are these keys of arbitrary length? Is there an >>>> > upper or lower limit? >>>> >>>> I believe this may refer to the following sentence: >>>> >>>> "In [RFC4253], SSH originally defined the public key algorithms >>>> "ssh-rsa" for server and client authentication using RSA with SHA-1, and >>>> "ssh-dss" using 1024-bit DSA and SHA-1." >>>> >>>> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key >>>> sizes. >>>> >>>> >>>> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>> > > hash, THEN compare the encoded bytes with the output of [...] >>>> >>>> > Why "SHOULD? >>>> >>>> Fair point. Changed as follows: >>>> >>>> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, >>>> then compare the encoded bytes with the output of the RSA operation." >>>> >>>> >>>> > This is an odd argument given that ECDSA is often also >>>> > implemented with random k. >>>> >>>> I agree, but that is the main argument that was given by multiple >>>> people as the main reason to remove DSA from the original draft (which >>>> covered DSA in addition). >>>> >>> >>> How about just "DSA is on its way out" :) >>> >>> >>>> >>>> >>>> denis >>>> >>>> >>>> >>>> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: >>>> >>>>> TECHNICAL >>>>> S 3. >>>>> Signing and verifying using these algorithms is performed according >>>>> to >>>>> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; >>>>> MGF1 as mask function; and salt length equal to hash size. >>>>> >>>>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >>>>> using PSS. In the former case, there is no mask function and salt. >>>>> Appendix 5.3 suggests that you are not using PSS. In any case, >>>>> you need to fix the inconsistency. >>>>> >>>>> You say in the intro that RSA was defined as 1024 bit keys. Are >>>>> these keys of arbitrary length? Is there an upper or lower limit? >>>>> >>>>> >>>>> S 5.3. >>>>> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>> hash, >>>>> THEN compare the encoded bytes with the output of the RSA operation. >>>>> >>>>> Why "SHOULD? >>>>> >>>>> >>>>> S 6. >>>>> A draft version of this memo also defined an algorithm name for use >>>>> of >>>>> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 >>>>> hashing. It is possible to implement DSA securely by generating "k" >>>>> deterministically as per [RFC6979]. However, a plurality of reviewers >>>>> were concerned that implementers would continue to use libraries that >>>>> generate "k" randomly. This is vulnerable to biased "k" generation, >>>>> and extremely vulnerable to "k" reuse. This document therefore >>>>> disrecommends DSA, in favor of RSA and elliptic curve cryptography. >>>>> >>>>> This is an odd argument given that ECDSA is often also implemented >>>>> with random k. Not that I am in favor of adding DSA here. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Curdle mailing list >>>>> Curdle@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/curdle >>>>> >>>>> >>>> >>> >> > --94eb2c07f0365f6dba05571dbbe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ping?

-Ekr


On Tue, Jun 20, 201= 7 at 3:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Usually, I would say "we're ge= tting rid of finite field" :)

-Ekr


On Tue, Jun 20, 2017 at 7:14 AM, denis bid= er <denisbider.ietf@gmail.com> wrote:
I agree, but there has to be a reason = it's on its way out. :) This is the one reason I know how to phrase. If= there's something else I can do instead, let me know.

On Mon, Jun 19, 2017 a= t 11:11 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Mon, Jun 19, 2017 at 8:28 AM, denis bider <denisbider.ietf@gmail.com> wrote:
> Either you are using PKCS#1 v1.5 = or you are using PSS.
> In the former case, there is no mask function= and salt.

Yikes, thanks. :) This was left over from an early= version that specified PSS. This was before PKCS#1 v1.5 was requested. (Th= e change took place before any implementation was released, so all deployed= implementations use PKCS#1 v1.5.)


> You say in the int= ro that RSA was defined as 1024 bit
> keys. Are these keys of arbitra= ry length? Is there an
> upper or lower limit?

I believ= e this may refer to the following sentence:

"In [RFC4253], SSH = originally defined the public key algorithms "ssh-rsa" for server= and client authentication using RSA with SHA-1, and "ssh-dss" us= ing 1024-bit DSA and SHA-1."

Here, 1024-bit refers to DSA. RFC = 4253 imposes no limits on RSA key sizes.


> > Impleme= ntations SHOULD apply PKCS#1 v1.5 padding to the expected
> &g= t; hash, THEN compare the encoded bytes with the output of [...]

>= ; Why "SHOULD?

Fair point. Changed as follows:

"Ver= ifiers MUST instead apply PKCS#1 v1.5 padding to the expected hash, then co= mpare the encoded bytes with the output of the RSA operation."

> This is an odd argument given that ECDSA is often also
&g= t; implemented with random k.

I agree, but that is the main a= rgument that was given by multiple people as the main reason to remove DSA = from the original draft (which covered DSA in addition).

How about just "DSA is on its way out&q= uot; :)
=C2=A0

denis


On Sat, Jun 17, 2017 at 1:30 PM, Er= ic Rescorla <ekr@rtfm.com> wrote:
TECHNICAL
S 3.
=C2=A0 Signing and verifying using these algorithms is performed ac= cording to
=C2=A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using= SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; and salt leng= th equal to hash size.

This seems incorrect. Eithe= r you are using PKCS#1 v1.5 or you are
using PSS. In the former c= ase, there is no mask function and salt.
Appendix 5.3 suggests th= at you are not using PSS. In any case,
you need to fix the incons= istency.

You say in the intro that RSA was defined= as 1024 bit keys. Are
these keys of arbitrary length? Is there a= n upper or lower limit?


S 5.3.
=C2=A0 Implementations SHOULD apply PKCS#1 v1.5 padding to the expect= ed hash,
=C2=A0 THEN compare the encoded bytes with the output of= the RSA operation.

Why "SHOULD?

S 6.
=C2=A0 A draft version of this m= emo also defined an algorithm name for use of
=C2=A0 2048-bit and= 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256
=C2=A0 h= ashing. It is possible to implement DSA securely by generating "k"= ;
=C2=A0 deterministically as per [RFC6979]. However, a plurality= of reviewers
=C2=A0 were concerned that implementers would conti= nue to use libraries that
=C2=A0 generate "k" randomly.= This is vulnerable to biased "k" generation,
=C2=A0 an= d extremely vulnerable to "k" reuse. This document therefore
=C2=A0 disrecommends DSA, in favor of RSA and elliptic curve cryptogr= aphy.

This is an odd argument given that ECDSA is = often also implemented
with random k. Not that I am in favor of a= dding DSA here.

-Ekr


=

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





--94eb2c07f0365f6dba05571dbbe3-- From nobody Mon Aug 21 09:30:31 2017 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 0F15D132A81; Mon, 21 Aug 2017 09:30:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, ekr@rtfm.com, The IESG , Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150333303105.6831.9859332851213651422.idtracker@ietfa.amsl.com> Date: Mon, 21 Aug 2017 09:30:31 -0700 Archived-At: Subject: [Curdle] Protocol Action: 'Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-ietf-curdle-cms-ecdh-new-curves-09.txt) X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 21 Aug 2017 16:30:31 -0000 The IESG has approved the following document: - 'Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS)' (draft-ietf-curdle-cms-ecdh-new-curves-09.txt) as Proposed Standard This document is the product of the CURves, Deprecating and a Little more Encryption Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ Technical Summary This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). Working Group Summary The document had two reviews on the mailing list (including Jim Schaad). The author mentions in its acknowledgment feed backs from Stefan Santesson, Sean Turner. There is significant confidence the document is mature and ready to be sent to the IESG. None object the the draft and only nits have been raised. Document Quality Jim Schaad provided a thorough review of the draft. Personnel Daniel Migault is the document shepherd and Eric Rescorla is the Security Area AD. From nobody Mon Aug 21 10:36:10 2017 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 18B6F1323C0 for ; Mon, 21 Aug 2017 10:36:10 -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 thKiJwC4dHmx for ; Mon, 21 Aug 2017 10:36:07 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93E01323B8 for ; Mon, 21 Aug 2017 10:36:06 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id y15so69527213lfd.5 for ; Mon, 21 Aug 2017 10:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eIknO9T4hoeRjdaixHNQ3imVBrmvGZCeoFxmX942rck=; b=d6SUqyWHwLpFBIi6kkSDvPF1R7Z57mD8JiDBqyfwo9CVD93iCCdlU17NC2QlrQZoQT j0eOXMI0ZsS/UJj3YFm/yVClhzqNLQNi0UHTvfAezLGXJqEWmo91+djy+9gciDU23rot tEO+xTJvwd0CN5HmeezlqS0HYzcoLqPjHIa6uvSAIPaPAwNVHehuR0VXnuAEojiODa2u X666wjrMU26VE2ActBtWn/ar5UV9Qs6oe/IwwQhjPaWR6MH24Vbi8QSPG+Hi4Q0cZg9d a6W8O7PDwaV7OgxQMP0uL9j0Zd2FzkS1TD6v+qDGcjMuU0OTyQApQn39TEoQ6NnvzgO4 x8WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eIknO9T4hoeRjdaixHNQ3imVBrmvGZCeoFxmX942rck=; b=slbFsgSvk8gWaLinXXF9tj9CUVIj01PIQMiEP4DbJgpwGwAjB0k2QC0u1ly+L9cB81 f2FR5veDI4/AgfWCpK2P98xyM1byDA0P6yLkgHgVcmw8dKW7+zmZuAn4NBYuVccCVUi3 ohkiqeIePmSzFKsPMv7ozQLzFb40pj056Thvgsi9mji81bQbRS4asUt7uMAz9HUO7bM2 L78PEMoBMebuelSWmLdbYJdL//ubcWPblJ2X7ZRcFViR+LCqzw6a7O511HXKqYsKISVj 5pNBQ14+2px+ddPzZjlxgW82YkEITqknheuX1qvY1I7SEhS6PKApyPVD5e4FRn5e7Glj cDGQ== X-Gm-Message-State: AHYfb5hhcQz86V909UvCmWTFTDTscmofn8wdXMCKHuBFGtggJ+jrLBbc fxU/B1p4mSGlED+evFWe9OaNY+ytrw== X-Received: by 10.46.5.80 with SMTP id 77mr6494948ljf.91.1503336965041; Mon, 21 Aug 2017 10:36:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Mon, 21 Aug 2017 10:36:04 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Mon, 21 Aug 2017 12:36:04 -0500 Message-ID: To: Eric Rescorla Cc: curdle Content-Type: multipart/alternative; boundary="001a114a7264c77736055746e9e4" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 21 Aug 2017 17:36:10 -0000 --001a114a7264c77736055746e9e4 Content-Type: text/plain; charset="UTF-8" Hey! Apologies, I am currently in the middle of moving to another country again (for the third, and hopefully final time!). I can still make changes as necessary to this draft, though. With respect to the below issue, I'm still not sure how to best phrase it differently. Maybe we could just remove the paragraph about why we're not doing DSA? At the time I wrote it, I thought it was a good idea to justify the removal, but maybe we don't even really need to explain anything there. Especially if the justification is simply "we don't wanna". :) denis On Sat, Aug 19, 2017 at 11:27 AM, Eric Rescorla wrote: > Ping? > > -Ekr > > > On Tue, Jun 20, 2017 at 3:55 PM, Eric Rescorla wrote: > >> Usually, I would say "we're getting rid of finite field" :) >> >> -Ekr >> >> >> On Tue, Jun 20, 2017 at 7:14 AM, denis bider >> wrote: >> >>> I agree, but there has to be a reason it's on its way out. :) This is >>> the one reason I know how to phrase. If there's something else I can do >>> instead, let me know. >>> >>> On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Mon, Jun 19, 2017 at 8:28 AM, denis bider >>> > wrote: >>>> >>>>> > Either you are using PKCS#1 v1.5 or you are using PSS. >>>>> > In the former case, there is no mask function and salt. >>>>> >>>>> Yikes, thanks. :) This was left over from an early version that >>>>> specified PSS. This was before PKCS#1 v1.5 was requested. (The change took >>>>> place before any implementation was released, so all deployed >>>>> implementations use PKCS#1 v1.5.) >>>>> >>>>> >>>>> > You say in the intro that RSA was defined as 1024 bit >>>>> > keys. Are these keys of arbitrary length? Is there an >>>>> > upper or lower limit? >>>>> >>>>> I believe this may refer to the following sentence: >>>>> >>>>> "In [RFC4253], SSH originally defined the public key algorithms >>>>> "ssh-rsa" for server and client authentication using RSA with SHA-1, and >>>>> "ssh-dss" using 1024-bit DSA and SHA-1." >>>>> >>>>> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key >>>>> sizes. >>>>> >>>>> >>>>> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>> > > hash, THEN compare the encoded bytes with the output of [...] >>>>> >>>>> > Why "SHOULD? >>>>> >>>>> Fair point. Changed as follows: >>>>> >>>>> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected >>>>> hash, then compare the encoded bytes with the output of the RSA operation." >>>>> >>>>> >>>>> > This is an odd argument given that ECDSA is often also >>>>> > implemented with random k. >>>>> >>>>> I agree, but that is the main argument that was given by multiple >>>>> people as the main reason to remove DSA from the original draft (which >>>>> covered DSA in addition). >>>>> >>>> >>>> How about just "DSA is on its way out" :) >>>> >>>> >>>>> >>>>> >>>>> denis >>>>> >>>>> >>>>> >>>>> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: >>>>> >>>>>> TECHNICAL >>>>>> S 3. >>>>>> Signing and verifying using these algorithms is performed according >>>>>> to >>>>>> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as hash; >>>>>> MGF1 as mask function; and salt length equal to hash size. >>>>>> >>>>>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >>>>>> using PSS. In the former case, there is no mask function and salt. >>>>>> Appendix 5.3 suggests that you are not using PSS. In any case, >>>>>> you need to fix the inconsistency. >>>>>> >>>>>> You say in the intro that RSA was defined as 1024 bit keys. Are >>>>>> these keys of arbitrary length? Is there an upper or lower limit? >>>>>> >>>>>> >>>>>> S 5.3. >>>>>> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>>> hash, >>>>>> THEN compare the encoded bytes with the output of the RSA operation. >>>>>> >>>>>> Why "SHOULD? >>>>>> >>>>>> >>>>>> S 6. >>>>>> A draft version of this memo also defined an algorithm name for use >>>>>> of >>>>>> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256 >>>>>> hashing. It is possible to implement DSA securely by generating "k" >>>>>> deterministically as per [RFC6979]. However, a plurality of >>>>>> reviewers >>>>>> were concerned that implementers would continue to use libraries >>>>>> that >>>>>> generate "k" randomly. This is vulnerable to biased "k" generation, >>>>>> and extremely vulnerable to "k" reuse. This document therefore >>>>>> disrecommends DSA, in favor of RSA and elliptic curve cryptography. >>>>>> >>>>>> This is an odd argument given that ECDSA is often also implemented >>>>>> with random k. Not that I am in favor of adding DSA here. >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Curdle mailing list >>>>>> Curdle@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/curdle >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a114a7264c77736055746e9e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey!

Apologies, I am currently in the m= iddle of moving to another country again (for the third, and hopefully fina= l time!). I can still make changes as necessary to this draft, though.

With respect to the below issue, I'm still not sur= e how to best phrase it differently. Maybe we could just remove the paragra= ph about why we're not doing DSA? At the time I wrote it, I thought it = was a good idea to justify the removal, but maybe we don't even really = need to explain anything there. Especially if the justification is simply &= quot;we don't wanna". :)

denis
=
=C2=A0

On Sat, Aug 19, 2017 at 11:27 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
Ping?
-Ekr


On Tu= e, Jun 20, 2017 at 3:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Usually, I would say &quo= t;we're getting rid of finite field" :)

-Ekr


On Tue, Jun 20, 2017 at 7:14 AM, denis bider <denisb= ider.ietf@gmail.com> wrote:
I agree, but there has to be a reason it's on its way= out. :) This is the one reason I know how to phrase. If there's someth= ing else I can do instead, let me know.

= On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla <ekr@rtfm.com> wr= ote:


On Mon, Jun 19, 2017 at 8:= 28 AM, denis bider <denisbider.ietf@gmail.com> wrote= :
> Either you = are using PKCS#1 v1.5 or you are using PSS.
> In the former case, the= re is no mask function and salt.

Yikes, thanks. :) This was l= eft over from an early version that specified PSS. This was before PKCS#1 v= 1.5 was requested. (The change took place before any implementation was rel= eased, so all deployed implementations use PKCS#1 v1.5.)


&= gt; You say in the intro that RSA was defined as 1024 bit
> keys. Are= these keys of arbitrary length? Is there an
> upper or lower limit?<= br>
I believe this may refer to the following sentence:

&q= uot;In [RFC4253], SSH originally defined the public key algorithms "ss= h-rsa" for server and client authentication using RSA with SHA-1, and = "ssh-dss" using 1024-bit DSA and SHA-1."

Here, 1024-b= it refers to DSA. RFC 4253 imposes no limits on RSA key sizes.

> > Implementations SHOULD apply PKCS#1 v1.5 padding to the expe= cted
> > hash, THEN compare the encoded bytes with the outp= ut of [...]

> Why "SHOULD?

Fair point. Changed as fol= lows:

"Verifiers MUST instead apply PKCS#1 v1.5 padding to the = expected hash, then compare the encoded bytes with the output of the RSA op= eration."


> This is an odd argument given that ECD= SA is often also
> implemented with random k.

I agree, = but that is the main argument that was given by multiple people as the main= reason to remove DSA from the original draft (which covered DSA in additio= n).

How about just "D= SA is on its way out" :)
=C2=A0


denis


On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla= <ek= r@rtfm.com> wrote:
TECHNICAL
S 3.
=C2=A0 Signing and verifying using these algorithms is pe= rformed according to
=C2=A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8= 017] using SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; and= salt length equal to hash size.

This seems incorr= ect. Either you are using PKCS#1 v1.5 or you are
using PSS. In th= e former case, there is no mask function and salt.
Appendix 5.3 s= uggests that you are not using PSS. In any case,
you need to fix = the inconsistency.

You say in the intro that RSA w= as defined as 1024 bit keys. Are
these keys of arbitrary length? = Is there an upper or lower limit?


S= 5.3.
=C2=A0 Implementations SHOULD apply PKCS#1 v1.5 padding to = the expected hash,
=C2=A0 THEN compare the encoded bytes with the= output of the RSA operation.

Why "SHOULD?


S 6.
=C2=A0 A draft version= of this memo also defined an algorithm name for use of
=C2=A0 20= 48-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256
=C2=A0 hashing. It is possible to implement DSA securely by generating &q= uot;k"
=C2=A0 deterministically as per [RFC6979]. However, a= plurality of reviewers
=C2=A0 were concerned that implementers w= ould continue to use libraries that
=C2=A0 generate "k"= randomly. This is vulnerable to biased "k" generation,
=C2=A0 and extremely vulnerable to "k" reuse. This document ther= efore
=C2=A0 disrecommends DSA, in favor of RSA and elliptic curv= e cryptography.

This is an odd argument given that= ECDSA is often also implemented
with random k. Not that I am in = favor of adding DSA here.

-Ekr



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






--001a114a7264c77736055746e9e4-- From nobody Tue Aug 22 08:03:06 2017 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 91E8B1329CE; Tue, 22 Aug 2017 08:02:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150341417953.6041.8422176121272596338@ietfa.amsl.com> Date: Tue, 22 Aug 2017 08:02:59 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-10.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 15:02:59 -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 WG of the IETF. Title : Use of the Elliptic Curve Diffie-Hellman Key Agreement Algorithm with X25519 and X448 in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-ecdh-new-curves-10.txt Pages : 17 Date : 2017-08-22 Abstract: This document describes the conventions for using Elliptic Curve Diffie-Hellman (ECDH) key agreement algorithm using curve25519 and curve448 in the Cryptographic Message Syntax (CMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-10 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-10 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 Tue Aug 22 12:05:05 2017 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 004CF1329DB for ; Tue, 22 Aug 2017 12:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUkES1dSi4WB for ; Tue, 22 Aug 2017 12:05:02 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 BC8EB1320C9 for ; Tue, 22 Aug 2017 12:05:01 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id y64so28904924ywf.3 for ; Tue, 22 Aug 2017 12:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=C+DjWphtvbG/wl52Ha5W/Uo5lNK8qb/DwipnB46vKsY=; b=zzfTwaM2tNH5crVoZV9IotglPGtlPRMX0gWkPVtE+IUMOqi/WwUbWJcyz1uGaIYOk8 4op+CyfZaiuP5fXdtkRnjSWlOx4ffPtEy1Ot5IW75nCkPZvZRi2t9OfZA/BG6getIVj/ tpIAieaS7FyCcdhZl+4YF9mqwEY7DQi9k3pAU5YCV/EMi37gNNsUDMLR1KbAvH+zztKJ dhdb7Q7BaJKVeu2hHjMhKaNWrN/HS4TWcmcg8pHkcQxQ2/R5jffFKaLBNmEcSJK3+zr9 lODPnomr3Ryfy/351WsgqpQB52ZMrSbZscTv6S3BR1JvWJvidscTlvrgxOjj5695gBrD f0Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C+DjWphtvbG/wl52Ha5W/Uo5lNK8qb/DwipnB46vKsY=; b=VXlFORFd3Z81ku//HrX8lQC7G+lqb2Dx1l3eHq1OyijNE37ylEiWh2zAdUE5Yb1s8S qJNoCWevOXEHCuBi8if1xD413Xo8KcnbF0iOJIv2m4tCy1euzf9GHqZdXJGW/+pZYFWY ND5lXUh2LG0DVROJ5Dm8YMSCZyOuVbcl1Ixw/GQTA+iBptmUThRPyaw/L02pZ5HJxXMa NpSnBMtAWBFubn0L7zSsoyz5oBIQtoITc1tf3TP5ZEEolQuQE8bc4fPML/3clp5VCjRB YLCXR8U2NZI26DZ1Y8CJRwOAFnRvvIy/rKhXM+fxSgMBbCwU6O2rO0G5XyjPkKoiMGN6 O78A== X-Gm-Message-State: AHYfb5hOpYmHN70bK7MfS8rtBKUmgjo1mytKveATGg3g77flgZrMDgEK GPOmjGAgNt+B/oMZ8FUNGK6SdkJXM6vY X-Received: by 10.37.160.41 with SMTP id x38mr96848ybh.339.1503428700800; Tue, 22 Aug 2017 12:05:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 22 Aug 2017 12:04:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 22 Aug 2017 12:04:20 -0700 Message-ID: To: denis bider Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c1a0650a8257905575c45d5" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 19:05:04 -0000 --94eb2c1a0650a8257905575c45d5 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 21, 2017 at 10:36 AM, denis bider wrote: > Hey! > > Apologies, I am currently in the middle of moving to another country again > (for the third, and hopefully final time!). I can still make changes as > necessary to this draft, though. > > With respect to the below issue, I'm still not sure how to best phrase it > differently. Maybe we could just remove the paragraph about why we're not > doing DSA? At the time I wrote it, I thought it was a good idea to justify > the removal, but maybe we don't even really need to explain anything there. > Especially if the justification is simply "we don't wanna". :) > This seems like a fine resolution. -Ekr > > denis > > > > On Sat, Aug 19, 2017 at 11:27 AM, Eric Rescorla wrote: > >> Ping? >> >> -Ekr >> >> >> On Tue, Jun 20, 2017 at 3:55 PM, Eric Rescorla wrote: >> >>> Usually, I would say "we're getting rid of finite field" :) >>> >>> -Ekr >>> >>> >>> On Tue, Jun 20, 2017 at 7:14 AM, denis bider >>> wrote: >>> >>>> I agree, but there has to be a reason it's on its way out. :) This is >>>> the one reason I know how to phrase. If there's something else I can do >>>> instead, let me know. >>>> >>>> On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla wrote: >>>> >>>>> >>>>> >>>>> On Mon, Jun 19, 2017 at 8:28 AM, denis bider < >>>>> denisbider.ietf@gmail.com> wrote: >>>>> >>>>>> > Either you are using PKCS#1 v1.5 or you are using PSS. >>>>>> > In the former case, there is no mask function and salt. >>>>>> >>>>>> Yikes, thanks. :) This was left over from an early version that >>>>>> specified PSS. This was before PKCS#1 v1.5 was requested. (The change took >>>>>> place before any implementation was released, so all deployed >>>>>> implementations use PKCS#1 v1.5.) >>>>>> >>>>>> >>>>>> > You say in the intro that RSA was defined as 1024 bit >>>>>> > keys. Are these keys of arbitrary length? Is there an >>>>>> > upper or lower limit? >>>>>> >>>>>> I believe this may refer to the following sentence: >>>>>> >>>>>> "In [RFC4253], SSH originally defined the public key algorithms >>>>>> "ssh-rsa" for server and client authentication using RSA with SHA-1, and >>>>>> "ssh-dss" using 1024-bit DSA and SHA-1." >>>>>> >>>>>> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key >>>>>> sizes. >>>>>> >>>>>> >>>>>> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>>> > > hash, THEN compare the encoded bytes with the output of [...] >>>>>> >>>>>> > Why "SHOULD? >>>>>> >>>>>> Fair point. Changed as follows: >>>>>> >>>>>> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected >>>>>> hash, then compare the encoded bytes with the output of the RSA operation." >>>>>> >>>>>> >>>>>> > This is an odd argument given that ECDSA is often also >>>>>> > implemented with random k. >>>>>> >>>>>> I agree, but that is the main argument that was given by multiple >>>>>> people as the main reason to remove DSA from the original draft (which >>>>>> covered DSA in addition). >>>>>> >>>>> >>>>> How about just "DSA is on its way out" :) >>>>> >>>>> >>>>>> >>>>>> >>>>>> denis >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: >>>>>> >>>>>>> TECHNICAL >>>>>>> S 3. >>>>>>> Signing and verifying using these algorithms is performed >>>>>>> according to >>>>>>> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as >>>>>>> hash; >>>>>>> MGF1 as mask function; and salt length equal to hash size. >>>>>>> >>>>>>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >>>>>>> using PSS. In the former case, there is no mask function and salt. >>>>>>> Appendix 5.3 suggests that you are not using PSS. In any case, >>>>>>> you need to fix the inconsistency. >>>>>>> >>>>>>> You say in the intro that RSA was defined as 1024 bit keys. Are >>>>>>> these keys of arbitrary length? Is there an upper or lower limit? >>>>>>> >>>>>>> >>>>>>> S 5.3. >>>>>>> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>>>> hash, >>>>>>> THEN compare the encoded bytes with the output of the RSA >>>>>>> operation. >>>>>>> >>>>>>> Why "SHOULD? >>>>>>> >>>>>>> >>>>>>> S 6. >>>>>>> A draft version of this memo also defined an algorithm name for >>>>>>> use of >>>>>>> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 >>>>>>> 256 >>>>>>> hashing. It is possible to implement DSA securely by generating "k" >>>>>>> deterministically as per [RFC6979]. However, a plurality of >>>>>>> reviewers >>>>>>> were concerned that implementers would continue to use libraries >>>>>>> that >>>>>>> generate "k" randomly. This is vulnerable to biased "k" generation, >>>>>>> and extremely vulnerable to "k" reuse. This document therefore >>>>>>> disrecommends DSA, in favor of RSA and elliptic curve cryptography. >>>>>>> >>>>>>> This is an odd argument given that ECDSA is often also implemented >>>>>>> with random k. Not that I am in favor of adding DSA here. >>>>>>> >>>>>>> -Ekr >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Curdle mailing list >>>>>>> Curdle@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/curdle >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --94eb2c1a0650a8257905575c45d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 21, 2017 at 10:36 AM, denis bider <denisbider.ietf= @gmail.com> wrote:
Hey!

Apologies, I am currently in the middle of= moving to another country again (for the third, and hopefully final time!)= . I can still make changes as necessary to this draft, though.
With respect to the below issue, I'm still not sure how to= best phrase it differently. Maybe we could just remove the paragraph about= why we're not doing DSA? At the time I wrote it, I thought it was a go= od idea to justify the removal, but maybe we don't even really need to = explain anything there. Especially if the justification is simply "we = don't wanna". :)

This = seems like a fine resolution.

-Ekr
=C2= =A0

denis
<= div>

=C2=A0

On Sat, Aug 19, 2017 at 11:27 AM, Eric= Rescorla <ekr@rtfm.com> wrote:
Ping?

-Ekr

<= div class=3D"m_2488872198310070650HOEnZb">

On Tue, Jun= 20, 2017 at 3:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Usually, I would say "we&#= 39;re getting rid of finite field" :)

-Ekr


On Tue, Jun 20, 2017 at 7= :14 AM, denis bider <denisbider.ietf@gmail.com> wrot= e:
I agree, but there ha= s to be a reason it's on its way out. :) This is the one reason I know = how to phrase. If there's something else I can do instead, let me know.=

On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Mon, Jun 19, 2017 = at 8:28 AM, denis bider <denisbider.ietf@gmail.com> = wrote:
> Either= you are using PKCS#1 v1.5 or you are using PSS.
> In the former case= , there is no mask function and salt.

Yikes, thanks. :) This = was left over from an early version that specified PSS. This was before PKC= S#1 v1.5 was requested. (The change took place before any implementation wa= s released, so all deployed implementations use PKCS#1 v1.5.)

=
> You say in the intro that RSA was defined as 1024 bit
> keys= . Are these keys of arbitrary length? Is there an
> upper or lower li= mit?

I believe this may refer to the following sentence:
<= br>"In [RFC4253], SSH originally defined the public key algorithms &qu= ot;ssh-rsa" for server and client authentication using RSA with SHA-1,= and "ssh-dss" using 1024-bit DSA and SHA-1."

Here, 1= 024-bit refers to DSA. RFC 4253 imposes no limits on RSA key sizes.

> > Implementations SHOULD apply PKCS#1 v1.5 padding to the= expected
> > hash, THEN compare the encoded bytes with the= output of [...]

> Why "SHOULD?

Fair point. Changed a= s follows:

"Verifiers MUST instead apply PKCS#1 v1.5 padding to= the expected hash, then compare the encoded bytes with the output of the R= SA operation."


> This is an odd argument given tha= t ECDSA is often also
> implemented with random k.

I ag= ree, but that is the main argument that was given by multiple people as the= main reason to remove DSA from the original draft (which covered DSA in ad= dition).

How about just &q= uot;DSA is on its way out" :)
=C2=A0


denis=



On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla <ekr@rtfm.com> wr= ote:
TECHNICAL
S 3.=
=C2=A0 Signing and verifying using these algorithms is performed= according to
=C2=A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8017] us= ing SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; and salt l= ength equal to hash size.

This seems incorrect. Ei= ther you are using PKCS#1 v1.5 or you are
using PSS. In the forme= r case, there is no mask function and salt.
Appendix 5.3 suggests= that you are not using PSS. In any case,
you need to fix the inc= onsistency.

You say in the intro that RSA was defi= ned as 1024 bit keys. Are
these keys of arbitrary length? Is ther= e an upper or lower limit?


S 5.3.
=C2=A0 Implementations SHOULD apply PKCS#1 v1.5 padding to the exp= ected hash,
=C2=A0 THEN compare the encoded bytes with the output= of the RSA operation.

Why "SHOULD?


S 6.
=C2=A0 A draft version of thi= s memo also defined an algorithm name for use of
=C2=A0 2048-bit = and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256
=C2= =A0 hashing. It is possible to implement DSA securely by generating "k= "
=C2=A0 deterministically as per [RFC6979]. However, a plur= ality of reviewers
=C2=A0 were concerned that implementers would = continue to use libraries that
=C2=A0 generate "k" rand= omly. This is vulnerable to biased "k" generation,
=C2= =A0 and extremely vulnerable to "k" reuse. This document therefor= e
=C2=A0 disrecommends DSA, in favor of RSA and elliptic curve cr= yptography.

This is an odd argument given that ECD= SA is often also implemented
with random k. Not that I am in favo= r of adding DSA here.

-Ekr



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







--94eb2c1a0650a8257905575c45d5-- From nobody Tue Aug 22 13:26:51 2017 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 AEBD0132A40; Tue, 22 Aug 2017 13:26:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150343360769.6130.2025981938810011424@ietfa.amsl.com> Date: Tue, 22 Aug 2017 13:26:47 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-12.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 20:26:48 -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 WG of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-12.txt Pages : 11 Date : 2017-08-22 Abstract: This memo updates RFC 4252, RFC 4253, and RFC 4254 to define a mechanism for SSH clients and servers to exchange information about supported protocol extensions confidentially after SSH key exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ext-info-12 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-12 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 Tue Aug 22 13:27:17 2017 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 C79A9132A3E; Tue, 22 Aug 2017 13:27:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150343362478.5978.3148784383994718643@ietfa.amsl.com> Date: Tue, 22 Aug 2017 13:27:04 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-10.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 20:27:05 -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 WG 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-10.txt Pages : 8 Date : 2017-08-22 Abstract: This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-2 hashing 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-rsa-sha2-10 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-10 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 Tue Aug 22 13:29:11 2017 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 61DCA132A30 for ; Tue, 22 Aug 2017 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wcjq0-hVAcc for ; Tue, 22 Aug 2017 13:29:06 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E955132A28 for ; Tue, 22 Aug 2017 13:29:06 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id y15so84064665lfd.5 for ; Tue, 22 Aug 2017 13:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oAU5cwQW0rvMytWkNwM+lBTbiogcipua6Gzl269++g8=; b=E+IydsIinWj8xeECVtZc43C9kSGPNR0BD0v15aEfEe/k/IsSLkjH+D23gBsdlFaieR 79NGaA4TvL1572ck/YnR4pl1by2EV7Wq8mX1mUULRfy7Oo0sP8g6FFxgiuEQF/4KtICf G56xfher7DdUZBhao2xsbBOVyDtd4TXSSdknqNKHFF7IY+d6Tp2V6y8KWwhzUzcbUKXa wH48qbmUxy4A50mAHcfs6MziiJD5t/ORRr1QVb9fM5L3kde0mPAXesubQuS+yV/F7B4Q XViAmSyo7K4GEIXkRMeEyyNJtxf0sfWGC1kAhqxB56kSyGIfhB+kZIKHZYO7cwHkutVn y2jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oAU5cwQW0rvMytWkNwM+lBTbiogcipua6Gzl269++g8=; b=likVncTV+olNGwqBzccOJPWnkmBGB+9Y7UPtY5wQoiVyXM/8vyfUh/2WSnyQcT5JNT yHktEldPMObXIR95Jh3935c+fjk6mhEN9LnINp6qI6L2yrV4Zx00KkOwDxanoqB4Y9Rc Yw0P6TCLb8tZJs40w09RleQb7+TxbRg+wbM/KWHHxuAhTgNosdGFsooICHqVzx5dQNFj pdHHgLOsZnvt+d7UtQTzSVhVb+NvSUFbj7d5fOwlS5JSTyoXuVoQM6UjDmkW21yeMDMN Zxl1PsZoQ6v0Tln7Xu88ttN+wpoD3hLu6ZXkjIOezwtN8+U8e+IomrULw+RVmoq/HX0D iZyg== X-Gm-Message-State: AHYfb5h0kJPlm6s8AywddLuRNpDujDEplJ6kugQJP+gJAxwg6PZN8C4E ui+E16itHqaNLvdZy7z6Itie0AYkIA== X-Received: by 10.46.21.84 with SMTP id 20mr136005ljv.72.1503433744342; Tue, 22 Aug 2017 13:29:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.179.27.209 with HTTP; Tue, 22 Aug 2017 13:29:03 -0700 (PDT) In-Reply-To: References: From: denis bider Date: Tue, 22 Aug 2017 15:29:03 -0500 Message-ID: To: Eric Rescorla Cc: curdle Content-Type: multipart/alternative; boundary="94eb2c1cda1e46630005575d7205" Archived-At: Subject: Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 22 Aug 2017 20:29:09 -0000 --94eb2c1cda1e46630005575d7205 Content-Type: text/plain; charset="UTF-8" Done and submitted. :-) On Tue, Aug 22, 2017 at 2:04 PM, Eric Rescorla wrote: > > > On Mon, Aug 21, 2017 at 10:36 AM, denis bider > wrote: > >> Hey! >> >> Apologies, I am currently in the middle of moving to another country >> again (for the third, and hopefully final time!). I can still make changes >> as necessary to this draft, though. >> >> With respect to the below issue, I'm still not sure how to best phrase it >> differently. Maybe we could just remove the paragraph about why we're not >> doing DSA? At the time I wrote it, I thought it was a good idea to justify >> the removal, but maybe we don't even really need to explain anything there. >> Especially if the justification is simply "we don't wanna". :) >> > > This seems like a fine resolution. > > -Ekr > > >> >> denis >> >> >> >> On Sat, Aug 19, 2017 at 11:27 AM, Eric Rescorla wrote: >> >>> Ping? >>> >>> -Ekr >>> >>> >>> On Tue, Jun 20, 2017 at 3:55 PM, Eric Rescorla wrote: >>> >>>> Usually, I would say "we're getting rid of finite field" :) >>>> >>>> -Ekr >>>> >>>> >>>> On Tue, Jun 20, 2017 at 7:14 AM, denis bider >>> > wrote: >>>> >>>>> I agree, but there has to be a reason it's on its way out. :) This is >>>>> the one reason I know how to phrase. If there's something else I can do >>>>> instead, let me know. >>>>> >>>>> On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla wrote: >>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 19, 2017 at 8:28 AM, denis bider < >>>>>> denisbider.ietf@gmail.com> wrote: >>>>>> >>>>>>> > Either you are using PKCS#1 v1.5 or you are using PSS. >>>>>>> > In the former case, there is no mask function and salt. >>>>>>> >>>>>>> Yikes, thanks. :) This was left over from an early version that >>>>>>> specified PSS. This was before PKCS#1 v1.5 was requested. (The change took >>>>>>> place before any implementation was released, so all deployed >>>>>>> implementations use PKCS#1 v1.5.) >>>>>>> >>>>>>> >>>>>>> > You say in the intro that RSA was defined as 1024 bit >>>>>>> > keys. Are these keys of arbitrary length? Is there an >>>>>>> > upper or lower limit? >>>>>>> >>>>>>> I believe this may refer to the following sentence: >>>>>>> >>>>>>> "In [RFC4253], SSH originally defined the public key algorithms >>>>>>> "ssh-rsa" for server and client authentication using RSA with SHA-1, and >>>>>>> "ssh-dss" using 1024-bit DSA and SHA-1." >>>>>>> >>>>>>> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key >>>>>>> sizes. >>>>>>> >>>>>>> >>>>>>> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>>>> > > hash, THEN compare the encoded bytes with the output of [...] >>>>>>> >>>>>>> > Why "SHOULD? >>>>>>> >>>>>>> Fair point. Changed as follows: >>>>>>> >>>>>>> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected >>>>>>> hash, then compare the encoded bytes with the output of the RSA operation." >>>>>>> >>>>>>> >>>>>>> > This is an odd argument given that ECDSA is often also >>>>>>> > implemented with random k. >>>>>>> >>>>>>> I agree, but that is the main argument that was given by multiple >>>>>>> people as the main reason to remove DSA from the original draft (which >>>>>>> covered DSA in addition). >>>>>>> >>>>>> >>>>>> How about just "DSA is on its way out" :) >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> denis >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla wrote: >>>>>>> >>>>>>>> TECHNICAL >>>>>>>> S 3. >>>>>>>> Signing and verifying using these algorithms is performed >>>>>>>> according to >>>>>>>> the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as >>>>>>>> hash; >>>>>>>> MGF1 as mask function; and salt length equal to hash size. >>>>>>>> >>>>>>>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are >>>>>>>> using PSS. In the former case, there is no mask function and salt. >>>>>>>> Appendix 5.3 suggests that you are not using PSS. In any case, >>>>>>>> you need to fix the inconsistency. >>>>>>>> >>>>>>>> You say in the intro that RSA was defined as 1024 bit keys. Are >>>>>>>> these keys of arbitrary length? Is there an upper or lower limit? >>>>>>>> >>>>>>>> >>>>>>>> S 5.3. >>>>>>>> Implementations SHOULD apply PKCS#1 v1.5 padding to the expected >>>>>>>> hash, >>>>>>>> THEN compare the encoded bytes with the output of the RSA >>>>>>>> operation. >>>>>>>> >>>>>>>> Why "SHOULD? >>>>>>>> >>>>>>>> >>>>>>>> S 6. >>>>>>>> A draft version of this memo also defined an algorithm name for >>>>>>>> use of >>>>>>>> 2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 >>>>>>>> 256 >>>>>>>> hashing. It is possible to implement DSA securely by generating >>>>>>>> "k" >>>>>>>> deterministically as per [RFC6979]. However, a plurality of >>>>>>>> reviewers >>>>>>>> were concerned that implementers would continue to use libraries >>>>>>>> that >>>>>>>> generate "k" randomly. This is vulnerable to biased "k" >>>>>>>> generation, >>>>>>>> and extremely vulnerable to "k" reuse. This document therefore >>>>>>>> disrecommends DSA, in favor of RSA and elliptic curve >>>>>>>> cryptography. >>>>>>>> >>>>>>>> This is an odd argument given that ECDSA is often also implemented >>>>>>>> with random k. Not that I am in favor of adding DSA here. >>>>>>>> >>>>>>>> -Ekr >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Curdle mailing list >>>>>>>> Curdle@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/curdle >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --94eb2c1cda1e46630005575d7205 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Done and submitted. :-)


On Tue, Aug 22,= 2017 at 2:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:


=
On Mon, Aug 21, 2017 at 10:36 A= M, denis bider <denisbider.ietf@gmail.com> wrote:
Hey!

Ap= ologies, I am currently in the middle of moving to another country again (f= or the third, and hopefully final time!). I can still make changes as neces= sary to this draft, though.

With respect to the be= low issue, I'm still not sure how to best phrase it differently. Maybe = we could just remove the paragraph about why we're not doing DSA? At th= e time I wrote it, I thought it was a good idea to justify the removal, but= maybe we don't even really need to explain anything there. Especially = if the justification is simply "we don't wanna". :)

This seems like a fine resolution= .

-Ekr
=C2=A0

denis
<= /font>

=C2=A0

On = Sat, Aug 19, 2017 at 11:27 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
Ping?

<= div>-Ekr


On Tue, = Jun 20, 2017 at 3:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Usually, I would say "w= e're getting rid of finite field" :)

-Ekr
=


On Tue, Jun 20, 2017 at 7:14 AM, denis bider <denisbider.ietf@gmail.com> wrote:
I agree, but there has to be a reason it's on = its way out. :) This is the one reason I know how to phrase. If there's= something else I can do instead, let me know.

On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla <ekr@rtfm.com= > wrote:
<= br>

On Mon, = Jun 19, 2017 at 8:28 AM, denis bider <denisbider.ietf@gmail.com> wrote:
> Either you are using PKCS#1 v1.5 or you are using PSS.
> In th= e former case, there is no mask function and salt.

Yikes, tha= nks. :) This was left over from an early version that specified PSS. This w= as before PKCS#1 v1.5 was requested. (The change took place before any impl= ementation was released, so all deployed implementations use PKCS#1 v1.5.)<= span>


> You say in the intro that RSA was defined as 1024 bit=
> keys. Are these keys of arbitrary length? Is there an
> uppe= r or lower limit?

I believe this may refer to the following s= entence:

"In [RFC4253], SSH originally defined the public key a= lgorithms "ssh-rsa" for server and client authentication using RS= A with SHA-1, and "ssh-dss" using 1024-bit DSA and SHA-1."
Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key s= izes.


> > Implementations SHOULD apply PKCS#1 v1.5 p= adding to the expected
> > hash, THEN compare the encoded b= ytes with the output of [...]

> Why "SHOULD?

Fair poi= nt. Changed as follows:

"Verifiers MUST instead apply PKCS#1 v1= .5 padding to the expected hash, then compare the encoded bytes with the ou= tput of the RSA operation."


> This is an odd argum= ent given that ECDSA is often also
> implemented with random k.
I agree, but that is the main argument that was given by multiple = people as the main reason to remove DSA from the original draft (which cove= red DSA in addition).

<= div class=3D"gmail_extra">
=
TECHNICAL
S 3= .
=C2=A0 Signing and verifying using these algorithms is performe= d according to
=C2=A0 the RSASSA-PKCS1-v1_5 scheme in [RFC8017] u= sing SHA-2 [SHS] as hash;
=C2=A0 MGF1 as mask function; and salt = length equal to hash size.

This seems incorrect. E= ither you are using PKCS#1 v1.5 or you are
using PSS. In the form= er case, there is no mask function and salt.
Appendix 5.3 suggest= s that you are not using PSS. In any case,
you need to fix the in= consistency.

You say in the intro that RSA was def= ined as 1024 bit keys. Are
these keys of arbitrary length? Is the= re an upper or lower limit?


S 5.3.<= /div>
=C2=A0 Implementations SHOULD apply PKCS#1 v1.5 padding to the ex= pected hash,
=C2=A0 THEN compare the encoded bytes with the outpu= t of the RSA operation.

Why "SHOULD?


S 6.
=C2=A0 A draft version of th= is memo also defined an algorithm name for use of
=C2=A0 2048-bit= and 3072-bit DSA keys with a 256-bit subgroup and SHA-2 256
=C2= =A0 hashing. It is possible to implement DSA securely by generating "k= "
=C2=A0 deterministically as per [RFC6979]. However, a plur= ality of reviewers
=C2=A0 were concerned that implementers would = continue to use libraries that
=C2=A0 generate "k" rand= omly. This is vulnerable to biased "k" generation,
=C2= =A0 and extremely vulnerable to "k" reuse. This document therefor= e
=C2=A0 disrecommends DSA, in favor of RSA and elliptic curve cr= yptography.

This is an odd argument given that ECD= SA is often also implemented
with random k. Not that I am in favo= r of adding DSA here.

-Ekr



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








--94eb2c1cda1e46630005575d7205-- From nobody Fri Aug 25 07:53:09 2017 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 AF9771321CB for ; Fri, 25 Aug 2017 07:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0E1vZkvNGsx for ; Fri, 25 Aug 2017 07:53:05 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5F531132BF7 for ; Fri, 25 Aug 2017 07:53:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 41CE253704 for ; Fri, 25 Aug 2017 17:53:03 +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 9ML-E6DF0Aud for ; Fri, 25 Aug 2017 17:53:02 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 7619A27B for ; Fri, 25 Aug 2017 17:53:01 +0300 (EEST) Date: Fri, 25 Aug 2017 17:53:01 +0300 From: Ilari Liusvaara To: curdle@ietf.org Message-ID: <20170825145300.fhbmibsdiwxtyqxg@LK-Perkele-VII> References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <149912398826.16176.10478215253595868540@ietfa.amsl.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 25 Aug 2017 14:53:08 -0000 On Mon, Jul 03, 2017 at 04:19:48PM -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, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure > Authors : Simon Josefsson > Jim Schaad > Filename : draft-ietf-curdle-pkix-05.txt > Pages : 17 > Date : 2017-07-03 I Did a review (except section 9, the ASN.1 module) of this draft and I did not find technical issues. Also checked in examples that the public/private keys seem to match, and that the certificate signature verifies). (On editorial front, the one-per-line lists with one or two elements look somewhat odd in section 5). -Ilari From nobody Fri Aug 25 08:22:34 2017 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 D500A132C07 for ; Fri, 25 Aug 2017 08:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9aqSssEULEK for ; Fri, 25 Aug 2017 08:22:30 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDAC1132940 for ; Fri, 25 Aug 2017 08:22:30 -0700 (PDT) X-AuditID: c6180641-0f7ff70000002d27-48-599ffa53847c Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C6.3A.11559.35AFF995; Fri, 25 Aug 2017 12:22:11 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0352.000; Fri, 25 Aug 2017 11:22:29 -0400 From: Daniel Migault To: Ilari Liusvaara , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt Thread-Index: AQHS9FLhgRcAACgxUkuSQupJxL6pYaKVvhqA///DzIA= Date: Fri, 25 Aug 2017 15:22:28 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CDDD29@eusaamb107.ericsson.se> References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> <20170825145300.fhbmibsdiwxtyqxg@LK-Perkele-VII> In-Reply-To: <20170825145300.fhbmibsdiwxtyqxg@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXRPlG7wr/mRBkuuG1psXTiL2eL97uks DkweS5b8ZPK43T2HLYApissmJTUnsyy1SN8ugStjQe92loIPXBUr9l9nbGBcztHFyMkhIWAi MX/lYkYQW0jgKKPEmj3FXYxcQPZyRom2yRvYQRJsAkYSbYf6wWwRgVCJ5mcTmLoYOTiEBewl vrZHQ4QdJHYtWckCYVtJNHU+YQYpYRFQlXjyzRskzCvgK9Ey8xQ7xKpyiV/nDoKVcwrYSuz8 9R0sziggJvH91BomEJtZQFzi1pP5TBBnCkgs2XOeGcIWlXj5+B8rhK0osa9/OjtEvY7Egt2f 2CBsbYllC18zQ+wVlDg58wnLBEaRWUjGzkLSMgtJyywkLQsYWVYxcpQWF+TkphsZbmIEBvwx CTbHHYx7ez0PMQpwMCrx8GY9mR8pxJpYVlyZe4hRgoNZSYRX1HZBpBBvSmJlVWpRfnxRaU5q 8SFGaQ4WJXHed+UXIoQE0hNLUrNTUwtSi2CyTBycUg2MEXmHFjwwOns6IHGX+s2v3RI1HtmC tu8mWcrmNosaPAjctlb85Ofzzez2Zz74rlnVO7fgqtRUu90Mpuc/XxXY5MT4xClth5Wx1h7B LxlP4nLjf8+oM1r+X6awW3nyWnZXFo38KTpzr+dIb319vcN29aO8ztU9Mt/DHR1zXnp3Gv39 cO9n+1FuJZbijERDLeai4kQASwdt/nQCAAA= Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 25 Aug 2017 15:22:33 -0000 Hi,=20 Thank you for your review.=20 Yours,=20 -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Ilari Liusvaara Sent: Friday, August 25, 2017 10:53 AM To: curdle@ietf.org Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt On Mon, Jul 03, 2017 at 04:19:48PM -0700, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the CURves, Deprecating and a Little more En= cryption of the IETF. >=20 > Title : Algorithm Identifiers for Ed25519, Ed448, X2551= 9 and X448 for use in the Internet X.509 Public Key Infrastructure > Authors : Simon Josefsson > Jim Schaad > Filename : draft-ietf-curdle-pkix-05.txt > Pages : 17 > Date : 2017-07-03 I Did a review (except section 9, the ASN.1 module) of this draft and I did= not find technical issues. Also checked in examples that the public/private keys seem to match, and th= at the certificate signature verifies). (On editorial front, the one-per-line lists with one or two elements look s= omewhat odd in section 5). -Ilari _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Aug 25 08:26:51 2017 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 C3B32132C16 for ; Fri, 25 Aug 2017 08:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5U1j4T-iPiA for ; Fri, 25 Aug 2017 08:26: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 25BA5132C10 for ; Fri, 25 Aug 2017 08:26:42 -0700 (PDT) X-AuditID: c618062d-b7bff70000004f0a-ff-59a058ec171e Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id D8.D6.20234.CE850A95; Fri, 25 Aug 2017 19:05:49 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0352.000; Fri, 25 Aug 2017 11:26:41 -0400 From: Daniel Migault To: Ilari Liusvaara , Yoav Nir CC: Rich Salz , Jim Schaad , "curdle@ietf.org" Thread-Topic: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt Thread-Index: AQHS9FLhgRcAACgxUkuSQupJxL6pYaJDYoAAgACgUICAAA0agIATEkmAgD5fHtA= Date: Fri, 25 Aug 2017 15:26:40 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118CDDD37@eusaamb107.ericsson.se> References: <149912398826.16176.10478215253595868540@ietfa.amsl.com> <006b01d2f484$0dfcfdf0$29f6f9d0$@augustcellars.com> <600eb1cae49c4993a11d477c2036ef2e@usma1ex-dag1mb1.msg.corp.akamai.com> <52B36760-2973-4781-A677-F273DC0F28D7@gmail.com> <20170716184655.tius2wcdbp3bumou@LK-Perkele-VII> In-Reply-To: <20170716184655.tius2wcdbp3bumou@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZXLonSvdtxIJIg8vXOCy2LpzFbLF6+nc2 i/e7p7NY/N/SyWKx9NgHJgdWj8lHFjB7bJwznc1j56y77B5Llvxk8rjdPYctgDWKyyYlNSez LLVI3y6BK2Pr9u/MBZNEK17Ob2FqYDwj0sXIySEhYCKx8vxy5i5GLg4hgaOMEm/a3zBBOMsZ JY4duMsMUsUmYCTRdqifHcQWEfCTuHJtIguIzSyQI7H0Uh9QnINDWMBe4mt7NESJg8SuJStZ YMrnXn8LNoZFQFViw+x/YGN4BXwlnne9ZITYtZJJ4u6Z40wgCU4BW4mnq1pZQWxGATGJ76fW MEHsEpe49WQ+E8TVAhJL9pxnhrBFJV4+/scKYStK7OufDnYPs4CmxPpd+hCtihJTuh9C7RWU ODnzCcsERtFZSKbOQuiYhaRjFpKOBYwsqxg5SosLcnLTjQw2MQLj6JgEm+4OxvvTPQ8xCnAw KvHw/ndcECnEmlhWXJl7iFGCg1lJhDfGASjEm5JYWZValB9fVJqTWnyIUZqDRUmcd8L5CxFC AumJJanZqakFqUUwWSYOTqkGxuNX3kl/qng9Yee6JSeEJ++YWcggtvbCmW3WRVmHHCapr3LJ 8TiXJRg6+c/VSfzsE58surPtk8Ik79nr7W+UN09YfOxZcJHzrfU9BywlTN6nR1095RcWPu+C Z1slXwS7uGHJBr3HK5VCstn1vZey7Pl/pVtmvbzJ3RW6O85/mfV+Nl9SwZyfB7uUWIozEg21 mIuKEwFJ18fGnwIAAA== Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-pkix-05.txt X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 25 Aug 2017 15:26:44 -0000 SGksIA0KDQpBZ2FpbiB0aGFuayB5b3UgZm9yIHRoZSByZXZpZXcsIGFuZCBJIGFtIGNhdGNoaW5n IHVwIHdpdGggdGhpcyBlbWFpbC4gDQpKdXN0IHRvIHJlc3BvbmQgYnJpZWZseSB0byB5b3VyIHF1 ZXN0aW9ucywgb25lIHJlYXNvbiB0byBjb25zaWRlciB0aGUgcHJpdmF0ZSBrZXlzIGlzIHRoYXQg aXQgaXMgaW4gb3VyIGNoYXJ0ZXIuIFJlZ2FyZGluZyB0aGUgc3RhdHVzIG9mIHRoZSBkcmFmdCBp dCBpcyB1bmRlciByZXZpZXcgYnkgdGhlIElFU0cuIA0KDQpZb3VycywgDQpEYW5pZWwNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEN1cmRsZSBbbWFpbHRvOmN1cmRsZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWxhcmkgTGl1c3ZhYXJhDQpTZW50OiBTdW5kYXks IEp1bHkgMTYsIDIwMTcgMjo0NyBQTQ0KVG86IFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29t Pg0KQ2M6IFJpY2ggU2FseiA8cnNhbHpAYWthbWFpLmNvbT47IEppbSBTY2hhYWQgPGlldGZAYXVn dXN0Y2VsbGFycy5jb20+OyBjdXJkbGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWN1cmRsZS1wa2l4LTA1LnR4dA0KDQpPbiBUdWUsIEp1bCAw NCwgMjAxNyBhdCAwNjozMjozM1BNICswMzAwLCBZb2F2IE5pciB3cm90ZToNCj4gDQo+ID4gT24g NCBKdWwgMjAxNywgYXQgMTc6NDUsIFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb20+IHdyb3Rl Og0KPiA+IA0KPiA+PiBCcmlhbiBTbWl0aCB3YW50cyB0byBoYXZlIGEgZnVsbCB0ZXN0IHNldCBh dCB0aGUgZW5kIG9mIHRoZSANCj4gPj4gZG9jdW1lbnQuICBJIGRvIG5vdCBiZWxpZXZlIHRoYXQg aXQgaXMgYXBwcm9wcmlhdGUgZm9yIHRoaXMgDQo+ID4+IGRvY3VtZW50IGFuZCB0aGVyZWZvcmUg aGF2ZSBvbmx5IGluY2x1ZGVkIGEgY291cGxlIG9mIHRlc3QgdGhhdCANCj4gPj4gZGVtb25zdHJh dGUgZXJyb3JzLg0KPiA+IA0KPiA+IElzIHRoZXJlIGFueW9uZSBlbHNlIGluIHRoZSBXRyB3aG8g c2hhcmVzIEJyaWFuJ3Mgb3Bpbmlvbj8NCj4gDQo+IElNTyB0aGUgZXhhbXBsZXMgaW4gc2VjdGlv biAxMCBhcmUgc3VmZmljaWVudC4gQSBmdWxsIHRlc3QgaXMgDQo+IGFwcHJvcHJpYXRlIHRoZSBh biBhbGdvcml0aG0gUkZDIHN1Y2ggYXMgODAzMiAoZm9yIEVkRFNBKSBhbmQgNzc0OCANCj4gKGZv ciBDdXJ2ZTI1NTE5IGFuZCBDdXJ2ZTQ0OCkNCj4gDQo+IFJGQyA4MDMyIGhhcyAgYSBnb29kIHNl dCBvZiB0ZXN0IHZlY3RvcnMuIFJGQyA3NzQ4IGhhcyBhIHJhdGhlciBzbWFsbCANCj4gc2V0LCBi dXQgZXZlbiBpZiBpdOKAmXMgbm90IGVub3VnaCwgSSBkb27igJl0IHRoaW5rIGEgUEtJWCB1cGRh dGUgaXMgdGhlIA0KPiBwbGFjZSB0byBmaXggaXQuDQoNCkZ1cnRoZXJtb3JlLCBhbGwgdGhlc2Ug Y29uY2VybiBwcml2YXRlIGtleSBmb3JtYXR0aW5nLCB3aGljaCBJIHJlZ2FyZCBhcyBzb21lIG9m IHRoZSBsZWFzdCBpbXBvcnRhbnQgdGhpbmdzIGluIHRoaXMgZG9jdW1lbnQgKEkgYW0gZXZlbiBu b3Qgc3VyZSBpZiB0aGUgcHJpdmF0ZSBrZXkgZXhhbXBsZXMgYWxyZWFkeSBhcmUgdXNlZnVsIG9y IG5vdCkuDQoNClNvIEkgZG8gbm90IGNvbnNpZGVyIG1vcmUgZXhhbXBsZXMgaGVyZSBpbXBvcnRh bnQuDQoNCg0KQWxzbywgd2hhdCdzIGdvaW5nIG9uIHdpdGggdGhlIGRyYWZ0PyBJdHMgc3RhdHVz IHdhcyBzZXQgb3ZlciB0d28gbW9udGhzIGFnbyAoYW5kIHRvIHZhbHVlIEkgY29uc2lkZXIgcmF0 aGVyIGJpemFycmUpLCBhbmQgc2luY2UgdGhlcmUgb25seSBoYXMgYmVlbiBhIHZlcnNpb24gYnVt cC4NCg0KDQotSWxhcmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkN1cmRsZSBtYWlsaW5nIGxpc3QNCkN1cmRsZUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jdXJkbGUNCg== From nobody Mon Aug 28 08:07:00 2017 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 AD49D132F97; Mon, 28 Aug 2017 08:06:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk CC: ekr@rtfm.com, Daniel Migault , curdle-chairs@ietf.org, curdle@ietf.org, daniel.migault@ericsson.com, draft-ietf-curdle-rsa-sha2@ietf.org Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150393281270.9783.16777160517882722368.idtracker@ietfa.amsl.com> Date: Mon, 28 Aug 2017 08:06:52 -0700 Archived-At: Subject: [Curdle] Last Call: (Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)) to Proposed Standard X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 28 Aug 2017 15:06:53 -0000 The IESG has received a request from the CURves, Deprecating and a Little more Encryption WG (curdle) to consider the following document: - 'Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-09-11. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo updates RFC 4252 and RFC 4253 to define new public key algorithms for use of RSA keys with SHA-2 hashing for server and client authentication in SSH connections. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Aug 30 10:22:47 2017 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 E92AD13240D for ; Wed, 30 Aug 2017 10:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no 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 FBJ7a3n1EaHF for ; Wed, 30 Aug 2017 10:22:40 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F6613213F for ; Wed, 30 Aug 2017 10:22:40 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id r203so56566868oih.0 for ; Wed, 30 Aug 2017 10:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=MHJKV2EJBwQsQsPLBh9VWBSRRXG6deqLwdlE8jy3PHI=; b=OLw1p2Egq/BzLygdjsH1YvqYxmJkis6Dt578AzKUHYqxemR0e8j+FXgSGqOWIeJlJ3 LI8LJQXS5wtsOoik4ID8fUyBDWFsGsqgNax1NiK6zO1JKyTc+SPSDQ3Blo0989yaOOzq C1ryBiVcdtSHoRL/uxXd/OplF2x6Nr0xW9nZnnNGGJ55lAXKnra6+PlXNYo1X1JbJyfC /4tSy72xA6Z//F3BP1yaIPt0EaeplxiH1lsC9IAvFmpsQaOMhA/IuesUkCA8zj3G73T7 WP5T+gAaCTYcuRGa/7M+s7BWcJ+hPW5f2NwmwPFPKI/B0AGlRn28rupYtR/KR2fsc0cu OX0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=MHJKV2EJBwQsQsPLBh9VWBSRRXG6deqLwdlE8jy3PHI=; b=EeP/Ud1pqDHf7Kby39ZP+dUk9FKqHbi6cfPtQRE8sKRvfnnrkkTsga/Se2AF7Q88lY FyLqpi0c94/dQw8rqpvUAUoLeoGPNtx0zBtEsxkFquRggxh2L/WiEb8M2ab9WChQ7FMq /opfRj4j+qNaraAH/FOd6uIOZAx2tq79j4ErDeLk0bik0UAfIomxgUh+YkqxxCqjoZRO +O9cd66bkk/r4dDSZZb6gEIehdFfXla/ky6z2cS4M2QyeRGzlakEYtr4XaYpOGU6DGbD S3JtWo8MmbfZsnhfa8nlsa08hOCY5Rk58N3x5Z2LNuTKQtZz3NAzkQh5ZxldFAp6FhcT p27g== X-Gm-Message-State: AHYfb5hPBIUxLr3s+18NBA2ETVATlvPRKUaXyptGjfvIoukrmWDRI4W4 6ZeFdOIfCMNwi/y7wQ5bhUuuegal/QGB X-Received: by 10.202.228.10 with SMTP id b10mr2459929oih.39.1504113759525; Wed, 30 Aug 2017 10:22:39 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.48.212 with HTTP; Wed, 30 Aug 2017 10:22:38 -0700 (PDT) From: Phillip Hallam-Baker Date: Wed, 30 Aug 2017 13:22:38 -0400 X-Google-Sender-Auth: 8zzVgg27u7dpmCJX_JqK7fTN4k8 Message-ID: To: Curdle Content-Type: multipart/alternative; boundary="001a1140933456a2620557fbc679" Archived-At: Subject: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 17:22:43 -0000 --001a1140933456a2620557fbc679 Content-Type: text/plain; charset="UTF-8" I am currently working on making Mesh/Recrypt work. This is basically three key public key cryptography. Instead of having one key to encrypt and one to decrypt, we have one to encrypt and the decryption key is split into two that have to BOTH be applied for decryption. OK so for the purposes of this issue, the encryption is exactly the same as for two key DH. Since the world is moving to ECDH, I am writing my code using Diffie-Hellman key agreement which RFC7516 doesn't really support. So I extended the format as follows: Sender: * Generates a random session key * Encrypts message under the session key * jwk = a new ephemeral generated per key exchange. * kid = identifier of group public key which is the UDF fingerprint of the key itself. * Performs a key exchange against the group public key to create the key agreement value. * Performs HKDF as specified in RFC 5869 to obtain an encryption key * encrypted_key = Key wrapping as specified in RFC 3394 to encrypt the session key This produces the following JSON package: { "protected": " ewogICJlbmMiOiAiQTI1NkNCQyJ9", "iv": " zLuTMmoOJHUp68hl8eB6Fw", "recipients": [{ "Header": { "kid": "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-45BX7", "jwk": { "PublicKeyDH": { "kid": "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB", "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByfraUGTMrYdZxbrpVIpP 5-60Jysf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb8mcbCnpvJRGMDGx6WV tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncmASBJWqxRZJErfCkWku HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn_kVgm6YcckdYM4lw6d TndMNjb8fQn0_giaK4USRo6B27WsNx6wjNiKD3OIA05NgpM2HPB4RZ1rvJaugH0J bgWEalUCQDS3ME4THMiMxgA"}}}, "encrypted_key": " NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIzST3NPyuA"}], "ciphertext": " -p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58"} OK so what is wrong? Well jwk is supposed to be the key identifier of the recipient key for a start. There is no way to express the DH key exchange properly in JOSE because it assumes that the Key Exchange is performed using symmetric or public key encryption. DH is neither, it is a key exchange. RFC 7818 is no help: https://tools.ietf.org/html/rfc7518#section-4.6 So as I was looking into this, I had the idea of looking at RFC 8037 to see how the problems are solved there and, well they aren't as far as I can see. In fact things look worse as the Edwards and Montgomery forms are treated as if they are the same and they are not. It looks to me as if we actually do need to do quite a bit of work to specify how to do encryption with ECDH in Jose. Unless of course I am reading the spec wrong which is quite possible. But my impression is that nobody implemented these options in running code or if they did, their work didn't make it back to the spec as it should. I need a package that contains exactly enough information to be able to decrypt the message. Which means that I need both keys to be specified in the recipients entry. I don't want to mix the ephemeral key data into the encrypted_key blob which would be the other way to do things. It is not clear to me which way is the best way forward here. I am going to be writing up a draft to describe the format for recryption which is going to be rather different to JOSE work anyway because my format is designed to allow efficient encryption of entire files. So my eventual format is going to be something like: {JSON stuff} If we are doing end-to-end encrypted Web, we might not want to do a Key Exchange mediated by the recryption service on every file encrypted. So it is likely that multiple data items will share a set of key exchange parameters. So I am going to have some identification information to allow those results to be cached. One option is to add the additional pieces I need into an extension draft covering my additional tags. Another is to produce two drafts. My feeling is that right now, I am probably the only person using JSON as a replacement for PKCS#7 / CMS so it is quite likely I am the only person who is going to be using Ed25518 or X25519 to encrypt large chunks of data. --001a1140933456a2620557fbc679 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m currently working on making Mesh/Recrypt work. This is basically three ke= y public key cryptography. Instead of having one key to encrypt and one to = decrypt, we have one to encrypt and the decryption key is split into two th= at have to BOTH be applied for decryption.

OK so for the purposes of this issue, the encryption is e= xactly the same as for two key DH.

Since the world is moving to ECDH, I am writing my code using Di= ffie-Hellman key agreement which RFC7516 doesn't really support. So I e= xtended the format as follows:

Sender:

* Generates a random session = key
= * Encrypts message und= er the session key

* jwk =3D a new ephemeral generated per key exchange.
* kid =3D identifier of group publi= c key which is the UDF fingerprint of the key itself.
* Performs a key exchange against th= e group public key to create the key agreement value.
* Performs HKDF as specified in RFC= =C2=A05869 to obtain a= n encryption key
*=C2=A0encrypted_key =3D=C2=A0=C2=A0Key wrapping as specified in RFC 3394 to encrypt the session key=C2= =A0

=
This produces = the following JSON package:

{
=C2=A0 "protected": "
ewogICJlbmMiOiAiQTI1NkNCQyJ9&q= uot;,
=C2=A0 &q= uot;iv": "
zLuTMmoOJHUp68hl8eB6Fw",
=C2=A0 "recipients": [{
=C2=A0 =C2=A0 =C2=A0 "Header&q= uot;: {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 "kid": "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-4= 5BX7",
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 "jwk": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Publi= cKeyDH": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "kid": "MAQ74-DJJ= MN-Y4GJ6-ZDXR5-A2SV7-5JGEB",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Domain= ": "YE6bnq1MlX5ojaJto6PLP_PEwA",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = "Public": "
hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByfraUGTMrYdZxbrpVIp= P
5-60Jysf5VXTd= URyviEOu-dDjVVpOddAjB6jZSVSzxIiqb8mcbCnpvJRGMDGx6WV
tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhG= C757xncmASBJWqxRZJErfCkWku
HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn_kVgm6YcckdYM4lw6= d
TndMNjb8fQn0_= giaK4USRo6B27WsNx6wjNiKD3OIA05NgpM2HPB4RZ1rvJaugH0J
bgWEalUCQDS3ME4THMiMxgA"}}},
=C2=A0 =C2=A0 =C2= =A0 "encrypted_key": "
NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIzST3NPy= uA"}],
=C2= =A0 "ciphertext": "
-p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58"}

OK so what is wrong?

Well jwk is supposed to be the= key identifier of the recipient key for a start. There is no way to expres= s the DH key exchange properly in JOSE because it assumes that the Key Exch= ange is performed using symmetric or public key encryption. DH is neither, = it is a key exchange.

RFC= 7818 is no help:
https://tools.ietf.org/html/rfc7518#se= ction-4.6

So as I= was looking into this, I had the idea of looking at RFC 8037 to see how th= e problems are solved there and, well they aren't as far as I can see. = In fact things look worse as the Edwards and Montgomery forms are treated a= s if they are the same and they are not.

It looks to me as if we actually do need to do quite a bit = of work to specify how to do encryption with ECDH in Jose. Unless of course= I am reading the spec wrong which is quite possible. But my impression is = that nobody implemented these options in running code or if they did, their= work didn't make it back to the spec as it should.


I need a package that contains exactly enough informat= ion to be able to decrypt the message. Which means that I need both keys to= be specified in the recipients entry.

I don't want to mix the ephemeral key data into the encry= pted_key blob which would be the other way to do things.


It is not clear to me which way is the best way forwa= rd here. I am going to be writing up a draft to describe the format for rec= ryption which is going to be rather different to JOSE work anyway because m= y format is designed to allow efficient encryption of entire files. So my e= ventual format is going to be something like:=C2=A0

{JSON stuff}
<RS><WrappedKey><IV><Cipherte= xt><MAC>

If we a= re doing end-to-end encrypted Web, we might not want to do a Key Exchange m= ediated by the recryption service on every file encrypted. So it is likely = that multiple data items will share a set of key exchange parameters. So I = am going to have some identification information to allow those results to = be cached.

=
One option is = to add the additional pieces I need into an extension draft covering my add= itional tags. Another is to produce two drafts.


My feeling is that right now, I am probably the only person us= ing JSON as a replacement for PKCS#7 / CMS so it is quite likely I am the o= nly person who is going to be using Ed25518 or X25519 to encrypt large chun= ks of data.




--001a1140933456a2620557fbc679-- From nobody Wed Aug 30 11:54:46 2017 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 706C213243E for ; Wed, 30 Aug 2017 11:54:44 -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 fjWOco6q-0_2 for ; Wed, 30 Aug 2017 11:54:41 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 731841321AF for ; Wed, 30 Aug 2017 11:54:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A297753695; Wed, 30 Aug 2017 21:54:39 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id jKIGEvR5B11H; Wed, 30 Aug 2017 21:54:38 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id AF65EC4; Wed, 30 Aug 2017 21:54:36 +0300 (EEST) Date: Wed, 30 Aug 2017 21:54:36 +0300 From: Ilari Liusvaara To: Phillip Hallam-Baker Cc: Curdle Message-ID: <20170830185436.vrrnarmyeecnzbb5@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 18:54:44 -0000 On Wed, Aug 30, 2017 at 01:22:38PM -0400, Phillip Hallam-Baker wrote: > I am currently working on making Mesh/Recrypt work. This is basically three > key public key cryptography. Instead of having one key to encrypt and one > to decrypt, we have one to encrypt and the decryption key is split into two > that have to BOTH be applied for decryption. > > OK so for the purposes of this issue, the encryption is exactly the same as > for two key DH. > OK so what is wrong? > > Well jwk is supposed to be the key identifier of the recipient key for a > start. There is no way to express the DH key exchange properly in JOSE > because it assumes that the Key Exchange is performed using symmetric or > public key encryption. DH is neither, it is a key exchange. > > RFC 7818 is no help: > https://tools.ietf.org/html/rfc7518#section-4.6 > > So as I was looking into this, I had the idea of looking at RFC 8037 to see > how the problems are solved there and, well they aren't as far as I can > see. In fact things look worse as the Edwards and Montgomery forms are > treated as if they are the same and they are not. RFC 8037 doesn't do anything really new, it just does the JWE ECDH-ES and JWS with CFRG curves. So if you are looking at some operational mode that base JOSE doesn't support, RFC 8037 is not going to support it either. > It looks to me as if we actually do need to do quite a bit of work to > specify how to do encryption with ECDH in Jose. Unless of course I am > reading the spec wrong which is quite possible. But my impression is that > nobody implemented these options in running code or if they did, their work > didn't make it back to the spec as it should. It seems like ECDH-ES in JWE was designed for the usual method of encrypting data using ECC, not to do anything exotic (like you seem to be doing). > I need a package that contains exactly enough information to be able to > decrypt the message. Which means that I need both keys to be specified in > the recipients entry. There are two logical recipients but one encryption key, that sounds exotic, yes. I presume the actual encryption key is a point sum of the two public keys? If so, be careful: To compute point sums on X25519 correctly, you need to know the y coordinate signs of the points, as the resulting point will be different depending on if the signs are the same or the opposite. > It is not clear to me which way is the best way forward here. I am going to > be writing up a draft to describe the format for recryption which is going > to be rather different to JOSE work anyway because my format is designed to > allow efficient encryption of entire files. So my eventual format is going > to be something like: > > {JSON stuff} > Be careful: Encrypting entiere files is not as easy as it seems. For some ideas, maybe look at HTTP encrypted content-coding, as that also has the problem of encrypting possibly very large files. Neither AES-GCM nor Chacha20-Poly1305-AEAD can encrypt a 500GB file in one shot, even if you had enough memory. -Ilari From nobody Wed Aug 30 12:03:01 2017 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 AF8D5132942 for ; Wed, 30 Aug 2017 12:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 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, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4X2FVmWwvAX for ; Wed, 30 Aug 2017 12:02:58 -0700 (PDT) Received: from mail4.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 B4D5A132811 for ; Wed, 30 Aug 2017 12:02:57 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0140_01D32187.E767D6C0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504119738; h=from:subject:to:date:message-id; bh=qGVdy7crRvwIsNKYoJH3SBEQSbzuNGXtYv463bWzFKQ=; b=MZwxQf2ACTTcD0aSKGLO593K1hNOezuO2yeiEWm8t4ebYPbCT74SYfRWrBB+D5dACEIgcXpz5IY 0Am43hrsSFIos1veULW6dSF3ICmie2ePWWLR7U04qRXV9/1urWWIB3uIWwpybkSQ0ppfMw+ximJRH rZDL+9gUF1EqsyMAYGOFDuAq8F26PwqVOq940BfyX4tKmrfkwLnIa9SvpAs3RACLm/wnU5pfijPEj 3Hh5FA3aH4w6hXnIu/VxregXp76T3J8Z7Pfxe5fGB+VlbRh2qmY1Ro0kxnGgouF+9Uwj73eJh+2ht zP7wjIxIpSqHHg20NMkTC/I32OiT1xmXf4ew== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 12:02:17 -0700 Received: from Hebrews (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 12:02:16 -0700 From: Jim Schaad To: 'Phillip Hallam-Baker' , 'Curdle' References: In-Reply-To: Date: Wed, 30 Aug 2017 12:02:48 -0700 Message-ID: <013f01d321c2$93c3c890$bb4b59b0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFxU7uyFKtn27vXYLlCM8cWvmQn5aNg3L5w X-Originating-IP: [192.168.1.162] Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 19:03:00 -0000 ------=_NextPart_000_0140_01D32187.E767D6C0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Start by looking at section 5.4 of RFC 7520 =E2=80=93 which is doing = what you are looking for. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker Sent: Wednesday, August 30, 2017 10:23 AM To: Curdle Subject: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient =20 I am currently working on making Mesh/Recrypt work. This is basically = three key public key cryptography. Instead of having one key to encrypt = and one to decrypt, we have one to encrypt and the decryption key is = split into two that have to BOTH be applied for decryption. =20 OK so for the purposes of this issue, the encryption is exactly the same = as for two key DH. =20 Since the world is moving to ECDH, I am writing my code using = Diffie-Hellman key agreement which RFC7516 doesn't really support. So I = extended the format as follows: =20 Sender: =20 * Generates a random session key * Encrypts message under the session key =20 * jwk =3D a new ephemeral generated per key exchange. * kid =3D identifier of group public key which is the UDF fingerprint of = the key itself. * Performs a key exchange against the group public key to create the key = agreement value. * Performs HKDF as specified in RFC 5869 to obtain an encryption key * encrypted_key =3D Key wrapping as specified in RFC 3394 to encrypt = the session key=20 =20 This produces the following JSON package: =20 { "protected": " ewogICJlbmMiOiAiQTI1NkNCQyJ9", "iv": " zLuTMmoOJHUp68hl8eB6Fw", "recipients": [{ "Header": { "kid": "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-45BX7", "jwk": { "PublicKeyDH": { "kid": "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB", "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByfraUGTMrYdZxbrpVIpP 5-60Jysf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb8mcbCnpvJRGMDGx6WV tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncmASBJWqxRZJErfCkWku HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn_kVgm6YcckdYM4lw6d TndMNjb8fQn0_giaK4USRo6B27WsNx6wjNiKD3OIA05NgpM2HPB4RZ1rvJaugH0J bgWEalUCQDS3ME4THMiMxgA"}}}, "encrypted_key": " NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIzST3NPyuA"}], "ciphertext": " -p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58"} =20 OK so what is wrong? =20 Well jwk is supposed to be the key identifier of the recipient key for a = start. There is no way to express the DH key exchange properly in JOSE = because it assumes that the Key Exchange is performed using symmetric or = public key encryption. DH is neither, it is a key exchange. =20 RFC 7818 is no help: https://tools.ietf.org/html/rfc7518#section-4.6 =20 So as I was looking into this, I had the idea of looking at RFC 8037 to = see how the problems are solved there and, well they aren't as far as I = can see. In fact things look worse as the Edwards and Montgomery forms = are treated as if they are the same and they are not. =20 It looks to me as if we actually do need to do quite a bit of work to = specify how to do encryption with ECDH in Jose. Unless of course I am = reading the spec wrong which is quite possible. But my impression is = that nobody implemented these options in running code or if they did, = their work didn't make it back to the spec as it should. =20 =20 I need a package that contains exactly enough information to be able to = decrypt the message. Which means that I need both keys to be specified = in the recipients entry. =20 I don't want to mix the ephemeral key data into the encrypted_key blob = which would be the other way to do things. =20 =20 It is not clear to me which way is the best way forward here. I am going = to be writing up a draft to describe the format for recryption which is = going to be rather different to JOSE work anyway because my format is = designed to allow efficient encryption of entire files. So my eventual = format is going to be something like:=20 =20 {JSON stuff} =20 If we are doing end-to-end encrypted Web, we might not want to do a Key = Exchange mediated by the recryption service on every file encrypted. So = it is likely that multiple data items will share a set of key exchange = parameters. So I am going to have some identification information to = allow those results to be cached. =20 One option is to add the additional pieces I need into an extension = draft covering my additional tags. Another is to produce two drafts. =20 =20 My feeling is that right now, I am probably the only person using JSON = as a replacement for PKCS#7 / CMS so it is quite likely I am the only = person who is going to be using Ed25518 or X25519 to encrypt large = chunks of data. =20 =20 =20 =20 =20 ------=_NextPart_000_0140_01D32187.E767D6C0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Start by = looking at section 5.4 of RFC 7520 =E2=80=93 which is doing what you are = looking for.

 

Jim

 

 

From: = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip = Hallam-Baker
Sent: Wednesday, August 30, 2017 10:23 = AM
To: Curdle <curdle@ietf.org>
Subject: = [Curdle] Encryption in CFRG curves, RFC 8037 not = sufficient

 

I am currently = working on making Mesh/Recrypt work. This is basically three key public = key cryptography. Instead of having one key to encrypt and one to = decrypt, we have one to encrypt and the decryption key is split into two = that have to BOTH be applied for = decryption.

 

OK so for the = purposes of this issue, the encryption is exactly the same as for two = key DH.

 

Since the world is = moving to ECDH, I am writing my code using Diffie-Hellman key agreement = which RFC7516 doesn't really support. So I extended the format as = follows:

 

Sender:

 

* = Generates a random session key

* = Encrypts message under the session key

 

* jwk =3D a new = ephemeral generated per key exchange.

* kid =3D identifier = of group public key which is the UDF fingerprint of the key = itself.

* Performs a key exchange against the group = public key to create the key agreement = value.

* Performs HKDF as specified in = RFC 5869 to = obtain an encryption key

* encrypted_key =3D  Key wrapping as specified = in RFC 3394 to encrypt the session key 

 

This produces the = following JSON package:

 

{

  = "protected": "

ewogICJlbmMiOiAiQTI1NkNCQyJ9",=

  "iv": = "

zLuTMmoOJHUp68hl8eB6Fw",

  "recipients": = [{

      "Header": = {

        "kid": = "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-45BX7",

  =       "jwk": = {

          = "PublicKeyDH": {

      =       "kid": = "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB",

  =           "Domain": = "YE6bnq1MlX5ojaJto6PLP_PEwA",

<= p class=3DMsoNormal>    =         "Public": = "

hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByf= raUGTMrYdZxbrpVIpP

5-60Jysf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb= 8mcbCnpvJRGMDGx6WV

tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncm= ASBJWqxRZJErfCkWku

HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn= _kVgm6YcckdYM4lw6d

TndMNjb8fQn0_giaK4USRo6B27WsNx6wjNiKD3OIA05Ngp= M2HPB4RZ1rvJaugH0J

bgWEalUCQDS3ME4THMiMxgA"}}},

      = "encrypted_key": "

NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIz= ST3NPyuA"}],

  = "ciphertext": "

-p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58&qu= ot;}

 

OK so what is = wrong?

 

Well jwk is supposed = to be the key identifier of the recipient key for a start. There is no = way to express the DH key exchange properly in JOSE because it assumes = that the Key Exchange is performed using symmetric or public key = encryption. DH is neither, it is a key = exchange.

 

RFC 7818 is no = help:

 

So as I was looking = into this, I had the idea of looking at RFC 8037 to see how the problems = are solved there and, well they aren't as far as I can see. In fact = things look worse as the Edwards and Montgomery forms are treated as if = they are the same and they are not.

 

It looks to me as if = we actually do need to do quite a bit of work to specify how to do = encryption with ECDH in Jose. Unless of course I am reading the spec = wrong which is quite possible. But my impression is that nobody = implemented these options in running code or if they did, their work = didn't make it back to the spec as it = should.

 

 

I need a package that = contains exactly enough information to be able to decrypt the message. = Which means that I need both keys to be specified in the recipients = entry.

 

I don't want to mix = the ephemeral key data into the encrypted_key blob which would be the = other way to do things.

 

 

It is not clear to me = which way is the best way forward here. I am going to be writing up a = draft to describe the format for recryption which is going to be rather = different to JOSE work anyway because my format is designed to allow = efficient encryption of entire files. So my eventual format is going to = be something like: 

 

{JSON = stuff}

<RS><WrappedKey><IV><Ciph= ertext><MAC>

 

If we are doing = end-to-end encrypted Web, we might not want to do a Key Exchange = mediated by the recryption service on every file encrypted. So it is = likely that multiple data items will share a set of key exchange = parameters. So I am going to have some identification information to = allow those results to be cached.

 

One option is to add = the additional pieces I need into an extension draft covering my = additional tags. Another is to produce two = drafts.

 

 

My feeling is that = right now, I am probably the only person using JSON as a replacement for = PKCS#7 / CMS so it is quite likely I am the only person who is going to = be using Ed25518 or X25519 to encrypt large chunks of = data.

 

 

 

 

 

=
------=_NextPart_000_0140_01D32187.E767D6C0-- From nobody Wed Aug 30 12:26:52 2017 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 168871321DC for ; Wed, 30 Aug 2017 12:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no 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 Mp0H7j3U8qpz for ; Wed, 30 Aug 2017 12:26:48 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD5F713248B for ; Wed, 30 Aug 2017 12:26:48 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id t75so59306676oie.3 for ; Wed, 30 Aug 2017 12:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8hHekx6IyrVcsltCCgeaHRUgHAsLwcOmZr5B8IQlOBI=; b=lnpIYL2j7cA9EXef4vNsioiLsdCKf0hJ3gd92QfTCgCTIIWrNwnEeWKF7mNzEKhmgb wvdBp4tYfgMiDZyon1fI7QnKwfJSeYhFs28SfqQJWeF2UKfUv1U0d1Lv+do2/E3Kee2W wZt0r5hHef5jOm560L0G3qGwAOr2wkIuQU/E5OnR2vKk/O5zIwslMTq0Bcyz5Rrxy9g4 4dWtYMgLIh8kW2UhN01Yv1ZSR0bDZu691wpxx+iZ7/qIeLenu8bzL+xL3vIG1nMKDRyp g7E5edVAefzKcKv95gsagyTzRaQm9kwSNaKFRieZJivlHVFWPxwC/vb0WW39rB63HY3F 9DYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8hHekx6IyrVcsltCCgeaHRUgHAsLwcOmZr5B8IQlOBI=; b=euQnwbaI8Qh17/Ryfz0OaNGQ4uwLU2sG/as5UeO8qI00/hEA1EZiK8Q9oyeMcmD0V/ aYgRAIJQf+wa/Q4MkPEPHqLMruAzcJqLxctjZVJ7BP0O64+/Xf54AwSdrFa+Uyg8zxX5 WL3cpzXLDHXRIKzcJHwSqOGaazoXjJZLplADpveq43BwnQQsLUw1cJMyFHJ5YLb8f8QI 7CXBh5JP8RL6HuobF4m0FjU+77Jjonog8xdh5DCF0DdUzgHkRxQVRM/4aH7QWqLt7bo+ RUrv/E2P/vbJZYDlDxgZykZW04mUtvhnTTOkvvaXSH3tbRT9H3FePD3At8+R/ozH57eS hNhw== X-Gm-Message-State: AHYfb5hBayVKarusKqTVMINQrcdFITEF9Rj9bd5TX4b52zzW+JpJwMFm 6TLWkNbZbGGGBnSV2l1nifkzj134+5pX X-Received: by 10.202.235.209 with SMTP id j200mr3063852oih.104.1504121207990; Wed, 30 Aug 2017 12:26:47 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.48.212 with HTTP; Wed, 30 Aug 2017 12:26:47 -0700 (PDT) In-Reply-To: <013f01d321c2$93c3c890$bb4b59b0$@augustcellars.com> References: <013f01d321c2$93c3c890$bb4b59b0$@augustcellars.com> From: Phillip Hallam-Baker Date: Wed, 30 Aug 2017 15:26:47 -0400 X-Google-Sender-Auth: K-qPSxaE9hmq4EElPTFgt-LUQ7Y Message-ID: To: Jim Schaad Cc: Curdle Content-Type: multipart/alternative; boundary="001a113ce6ae4d31820557fd8280" Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 19:26:51 -0000 --001a113ce6ae4d31820557fd8280 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, the epk parameter is defined in RFC7518 (JSON Web Algorithms) and not RFC 7516 (JSON Web Encryption) =E2=80=8B=E2=80=8B4.6.1.1. I think that deserves an errata as it is entirely reasonable for the encryption mechanism to be specified in the RFC titled 'encryption'. On Wed, Aug 30, 2017 at 3:02 PM, Jim Schaad wrote: > Start by looking at section 5.4 of RFC 7520 =E2=80=93 which is doing what= you are > looking for. > > > > Jim > > > > > > *From:* Curdle [mailto:curdle-bounces@ietf.org] *On Behalf Of *Phillip > Hallam-Baker > *Sent:* Wednesday, August 30, 2017 10:23 AM > *To:* Curdle > *Subject:* [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient > > > > I am currently working on making Mesh/Recrypt work. This is basically > three key public key cryptography. Instead of having one key to encrypt a= nd > one to decrypt, we have one to encrypt and the decryption key is split in= to > two that have to BOTH be applied for decryption. > > > > OK so for the purposes of this issue, the encryption is exactly the same > as for two key DH. > > > > Since the world is moving to ECDH, I am writing my code using > Diffie-Hellman key agreement which RFC7516 doesn't really support. So I > extended the format as follows: > > > > Sender: > > > > * Generates a random session key > > * Encrypts message under the session key > > > > * jwk =3D a new ephemeral generated per key exchange. > > * kid =3D identifier of group public key which is the UDF fingerprint of = the > key itself. > > * Performs a key exchange against the group public key to create the key > agreement value. > > * Performs HKDF as specified in RFC 5869 to obtain an encryption key > > * encrypted_key =3D Key wrapping as specified in RFC 3394 to encrypt the > session key > > > > This produces the following JSON package: > > > > { > > "protected": " > > ewogICJlbmMiOiAiQTI1NkNCQyJ9", > > "iv": " > > zLuTMmoOJHUp68hl8eB6Fw", > > "recipients": [{ > > "Header": { > > "kid": "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-45BX7", > > "jwk": { > > "PublicKeyDH": { > > "kid": "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB", > > "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", > > "Public": " > > hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByfraUGTMrYdZxbrpVIpP > > 5-60Jysf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb8mcbCnpvJRGMDGx6WV > > tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncmASBJWqxRZJErfCkWku > > HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn_kVgm6YcckdYM4lw6d > > TndMNjb8fQn0_giaK4USRo6B27WsNx6wjNiKD3OIA05NgpM2HPB4RZ1rvJaugH0J > > bgWEalUCQDS3ME4THMiMxgA"}}}, > > "encrypted_key": " > > NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIzST3NPyuA"}], > > "ciphertext": " > > -p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58"} > > > > OK so what is wrong? > > > > Well jwk is supposed to be the key identifier of the recipient key for a > start. There is no way to express the DH key exchange properly in JOSE > because it assumes that the Key Exchange is performed using symmetric or > public key encryption. DH is neither, it is a key exchange. > > > > RFC 7818 is no help: > > https://tools.ietf.org/html/rfc7518#section-4.6 > > > > So as I was looking into this, I had the idea of looking at RFC 8037 to > see how the problems are solved there and, well they aren't as far as I c= an > see. In fact things look worse as the Edwards and Montgomery forms are > treated as if they are the same and they are not. > > > > It looks to me as if we actually do need to do quite a bit of work to > specify how to do encryption with ECDH in Jose. Unless of course I am > reading the spec wrong which is quite possible. But my impression is that > nobody implemented these options in running code or if they did, their wo= rk > didn't make it back to the spec as it should. > > > > > > I need a package that contains exactly enough information to be able to > decrypt the message. Which means that I need both keys to be specified in > the recipients entry. > > > > I don't want to mix the ephemeral key data into the encrypted_key blob > which would be the other way to do things. > > > > > > It is not clear to me which way is the best way forward here. I am going > to be writing up a draft to describe the format for recryption which is > going to be rather different to JOSE work anyway because my format is > designed to allow efficient encryption of entire files. So my eventual > format is going to be something like: > > > > {JSON stuff} > > > > > > If we are doing end-to-end encrypted Web, we might not want to do a Key > Exchange mediated by the recryption service on every file encrypted. So i= t > is likely that multiple data items will share a set of key exchange > parameters. So I am going to have some identification information to allo= w > those results to be cached. > > > > One option is to add the additional pieces I need into an extension draft > covering my additional tags. Another is to produce two drafts. > > > > > > My feeling is that right now, I am probably the only person using JSON as > a replacement for PKCS#7 / CMS so it is quite likely I am the only person > who is going to be using Ed25518 or X25519 to encrypt large chunks of dat= a. > > > > > > > > > > > --001a113ce6ae4d31820557fd8280 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah,= the epk parameter is defined in RFC7518 (JSON Web Algorithms) and not RFC = 7516 (JSON Web Encryption)

=E2=80=8B=E2=80=8B4.6.1.1.

I think that deserves an errata as it is entirely reasonable for the enc= ryption mechanism to be specified in the RFC titled 'encryption'.


On Wed, Aug 30, 2017 at 3:02 PM, Jim Scha= ad <ietf@augustcellars.com> wrote:

Start by looking at= section 5.4 of RFC 7520 =E2=80=93 which is doing what you are looking for.=

=C2=A0

Jim

=C2=A0=

=C2=A0

From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Phillip Hallam-Baker
Sent: Wednesday, Aug= ust 30, 2017 10:23 AM
To: Curdle <curdle@ietf.org>
Subject: [Curdle= ] Encryption in CFRG curves, RFC 8037 not sufficient

=C2=A0=

I a= m currently working on making Mesh/Recrypt work. This is basically three ke= y public key cryptography. Instead of having one key to encrypt and one to = decrypt, we have one to encrypt and the decryption key is split into two th= at have to BOTH be applied for decryption.

=C2=A0

OK so for the purposes of this issue, the encryption is exactly the same= as for two key DH.

=C2=A0

Since the world is m= oving to ECDH, I am writing my code using Diffie-Hellman key agreement whic= h RFC7516 doesn't really support. So I extended the format as follows:<= u>

=C2=A0

Sender:

=C2=A0

* Generates a random session key

* Encrypts message under the session k= ey

=C2=A0=

* jwk =3D a new ephemeral generated per key exchange.=

* kid = =3D identifier of group public key which is the UDF fingerprint of the key = itself.

* Performs a key exchange against the group public ke= y to create the key agreement value.

* Performs HKDF as speci= fied in RFC=C2=A05869 to = obtain an encryption key

*=C2=A0encrypted_key = =3D=C2=A0=C2=A0Key wrappi= ng as specified in RFC 3394 to encrypt the session key=C2=A0

=C2=A0

=

This produces th= e following JSON package:

=C2=A0

{<= u>

=C2=A0 "protected": "

<= div>

ewogICJlbmMiOiAiQ= TI1NkNCQyJ9",

=C2=A0 "iv": "

zLuTMmoOJHUp68hl8eB6Fw",

=C2=A0 "recipients"= : [{

=C2=A0 =C2=A0 =C2=A0 "Header": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "kid": "MDQIW-GSFHP-YFE5E-O6IT= K-3EUGH-45BX7",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "j= wk": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "PublicKe= yDH": {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "= kid": "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB",<= /u>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Domain": "YE6= bnq1MlX5ojaJto6PLP_PEwA",

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 "Public": "

hO-l2oeNCKGubSGpSjcw= A9j1VmsF_CboNMEwqhzv4PlByfraUGTMrYdZxbrpVIpP=

5-60Jy= sf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb8mcbCnpvJRGMDGx6WV=

tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncmASBJWqxRZJE= rfCkWku

HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn_<= wbr>kVgm6YcckdYM4lw6d

TndMNjb8fQn0_giaK4USRo6B27WsNx6wjN= iKD3OIA05NgpM2HPB4RZ1rvJaugH0J

bgWEalUCQDS3ME4THMiMxgA&q= uot;}}},

=C2=A0 =C2=A0 =C2=A0 "encrypted_key": &quo= t;

NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIzST3NPyu= A"}],

=C2=A0 "ciphertext": "

-p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58"}

= =C2=A0

OK so what is wrong?

=C2=A0=

Well jwk is supposed to be the key identifier of the recipient key for a s= tart. There is no way to express the DH key exchange properly in JOSE becau= se it assumes that the Key Exchange is performed using symmetric or public = key encryption. DH is neither, it is a key exchange.

= =C2=A0

RFC 7818 is no help:


--001a113ce6ae4d31820557fd8280-- From nobody Wed Aug 30 13:11:11 2017 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 91D04132153 for ; Wed, 30 Aug 2017 13:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no 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 mwCT-wogNY1a for ; Wed, 30 Aug 2017 13:11:08 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E8D126B7E for ; Wed, 30 Aug 2017 13:11:08 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id k77so60094587oib.2 for ; Wed, 30 Aug 2017 13:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=72xaRU1svSgdjkXyRAmoRdNuaVKnGGXZSH8x8MjYkBU=; b=Rn0dKE52LhPVVvUjxduolDPe6qPwLECTGszZi9GNn24PiR4b7nlzHNBU7Tk9pDBHNu 5zKtJ2xV1hZPr34S7ZO0+BBM7eLddd+SyemGGAnfxeTSYiHgeIMuhidq0EZqniIvix5m jwAUM3WFA6t4CpAoWDzXcvfB0JFj/5EneUG7VffIdGEcIC9t9dwNOpAt/XNv1q85KuBZ Uij1FG7Vb4cm5Rya3fbnmx+VmDSOdAjoX6iNrzd52c7fyVaSu3F69gkzGStc+fquTw+M yHli/hxIzDy3QC+TVMB10HgJCsUWXvsXNz7g9pp25QiE5mrAwZdUPEnDEdRyrjyPtYWb pvrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=72xaRU1svSgdjkXyRAmoRdNuaVKnGGXZSH8x8MjYkBU=; b=QDelOl3OaGqXLGADNSFZ6QCasFXhmWagHNTymii8V4TNaQ84J29D5J+p/cAoFXlbt6 5XLUczIcoUkgS4CSBwJApfi5KPOKOcT/kc7vkhluc+bFNzaVwR2tWMUKtgGd0B9CTEdc w0C+7JBmFpDrocOf/UnkyXYnBFBfTRVg4YFA74ZFG9a6f78/nH4xAWMwsIx9rDsZ1DXw e8Yne37aojwrpm9VLhCLx+T0sSgnNngomou16az2zPDLIBXonFLzmvTbEPWtbgIWQSIg Clgw/sdim0bRbRn1hjpJeSCoGdGsgmg9aHOcjs2hsowWYqf/2CGDnMk6NH4secz4U+Mu NJAw== X-Gm-Message-State: AHYfb5jqLM5B1YxsjjDUhSN+2DMiVzIUhJWon4RjgP2U3w42QcOaPXHS LF3z4gTmHsdmozYojNx91IF7ZGNCmw== X-Received: by 10.202.98.7 with SMTP id w7mr2507383oib.262.1504123867827; Wed, 30 Aug 2017 13:11:07 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.48.212 with HTTP; Wed, 30 Aug 2017 13:11:07 -0700 (PDT) In-Reply-To: <20170830185436.vrrnarmyeecnzbb5@LK-Perkele-VII> References: <20170830185436.vrrnarmyeecnzbb5@LK-Perkele-VII> From: Phillip Hallam-Baker Date: Wed, 30 Aug 2017 16:11:07 -0400 X-Google-Sender-Auth: O2y5dNjWkKABx459LxHwSN7V5SA Message-ID: To: Ilari Liusvaara Cc: Curdle Content-Type: multipart/alternative; boundary="001a113cc6b6d715550557fe207b" Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 20:11:10 -0000 --001a113cc6b6d715550557fe207b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2017 at 2:54 PM, Ilari Liusvaara wrote: > On Wed, Aug 30, 2017 at 01:22:38PM -0400, Phillip Hallam-Baker wrote: > > RFC 8037 doesn't do anything really new, it just does the JWE ECDH-ES > and JWS with CFRG curves. > > So if you are looking at some operational mode that base JOSE doesn't > support, RFC 8037 is not going to support it either. =E2=80=8BAs I pointed out to Jim, the problem is that the epk field is defi= ned in RFC 7518 as a field specific to Diffie-Hellman whereas it should be specified in RFC 7516 as a JWE header. Making sense of RFC 8037 is hard unless you know where to look. I think this can probably be fixed by a minor revision to 8037 section 3.2. It seems like ECDH-ES in JWE was designed for the usual method of > encrypting data using ECC, not to do anything exotic (like you seem to > be doing). > > > I need a package that contains exactly enough information to be able to > > decrypt the message. Which means that I need both keys to be specified = in > > the recipients entry. > > There are two logical recipients but one encryption key, that sounds > exotic, yes. > =E2=80=8BNo, there is one recipient entry that maps to one encryption key. = The corresponding decryption keys are split. Each recipient has a different split. So if the encryption key is x Alice has Recryption key x-a, Decryption key a =E2=80=8BBob has Recryption key x-b, Decryption key b =E2=80=8B.. =E2=80=8BZaphod has Recryption key x-z, Decryption key z =E2=80=8BEncryption is exactly as usual. Here is the revised version: { "protected": " ewogICJlbmMiOiAiQTI1NkNCQyJ9", "iv": " XprRRLxypOEdc8e6Sfzeuw", "recipients": [{ "Header": { "kid": "recrypt@example.com.mm--ma6ni-jml7o-yuc3d-p54vt-nhhov-rpwhy ", "epk": { "PublicKeyDH": { "kid": "MAFWJ-EITV3-YYCTK-VBYMH-QISR2-AB4XR", "Domain": " YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " ly6Ly2hTOA7LiyNOzFeza9NdP2YWONYDfPRryU7iA4UJ0XR89DeoCYyirkKwo-Dy _R13gBS8ssUIPAlbLw9ZG2TMUQXsDXOfm_C4NuUyGSOKDZXmFVpGs6a1ZDZUHgXK JbmcVmOuc0fPuHeupnHab4xKMrcN1JnLb25NYLLP38BMNHgwzsHW86_amQkJfkcP GE06ftDSLx58hM3GMIBPzs1CaPxlRQq-Z-XUa-PphpluiBPUyY59WZp7_VQiFeJL KCqVE6RAemPUpB0L4KJN986NH-UKOg1oMqmLI_OBRHct4ReUIHgj20BGNvgLkee9 RaPYcnjpGO39C6POMsc1vwA"}}}, "encrypted_key": " jp0wv-ScBiM8C51p9Whiw8JRM_8z91KO7JLJJknWMfrHMbGabSdqnA"}], "ciphertext": " rLbzveATVYv2jaMnsKz0LkVzz6O5DNrN5B-ZtSOoODY"} =E2=80=8B(yes, I know epk is not standard yet). I presume the actual encryption key is a point sum of the two public > keys? If so, be careful: To compute point sums on X25519 correctly, you > need to know the y coordinate signs of the points, as the resulting > point will be different depending on if the signs are the same or > the opposite. =E2=80=8BWhich is why I plan to use the Edwards curves for encryption, not = the Montgomery.=E2=80=8B Yes, I know it is possible to do point sums on X25519 = but why go through the covfefe when you need Edwards anyway? > It is not clear to me which way is the best way forward here. I am going > to > > be writing up a draft to describe the format for recryption which is > going > > to be rather different to JOSE work anyway because my format is designe= d > to > > allow efficient encryption of entire files. So my eventual format is > going > > to be something like: > > > =E2=80=8B=E2=80=8B > > {JSON stuff} > > > > Be careful: Encrypting entiere files is not as easy as it seems. > =E2=80=8B=E2=80=8BYes, particularly when you have to support modes like str= eaming. The question I have been asking myself is whether to have a 'simple' format which is unchunked and an advanced format which is chunked. Now that you point out that the 'simple' mode also gets complex for very large files, I am thinking of just making chunking a requirement. The corner case would be to support random access efficiently. Which could be done by fixing the chunk size in advance. If you know the chunk size is fixed at 1MB, and the framing records are also fixed size (always rekey, always drop the MAC tag), you can do random access provided that your encryption mode allows a block to be changed in the middle of the cipher stream without causing changes to any blocks other than the next one. For some ideas, maybe look at > =E2=80=8B=E2=80=8B > HTTP encrypted content-coding, as that > also has the problem of encrypting possibly very large files. > > Neither > =E2=80=8B=E2=80=8B > AES-GCM nor > =E2=80=8B=E2=80=8B > Chacha20-Poly1305-AEAD can encrypt a 500GB file in > one shot, even if you had enough memory. > =E2=80=8B256GB seems to be the limit... Given that the framing overhead is going to be a 256 bit key + 128 bit wrap+ 128 bit tag + 128 bit IV =3D 80 bytes, I don't see having to introduc= e framing every 1GB or so would be an imposition. It is probably prudent to have a checksum every GB or so anyway. =E2=80=8BSo I think I will make the framing mandatory=E2=80=8B {JSON stuff} =E2=80=8B Frame [=E2=80=8B =E2=80=8B =E2=80=8B =E2=80=8B ]=E2=80=8B I will probably mandate that the header be in JSON and use JSON-B for the rest. That allows me to avoid the overhead of BASE64 encoding everything without introducing a new encoding data model. --001a113cc6b6d715550557fe207b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Au= g 30, 2017 at 2:54 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Wed, Aug 30, 2017 at 01:22:38PM -0400, Phillip Hall= am-Baker wrote:

RFC 8037 doesn't do anything really new, it just does the JWE EC= DH-ES
and JWS with CFRG curves.

So if you are looking at some operational mode that base JOSE doesn't support, RFC 8037 is not going to support it either.

<= /div>
=E2=80=8BA= s I pointed out to Jim, the problem is that the epk field is defined in RFC= 7518 as a field specific to Diffie-Hellman whereas it should be specified = in RFC 7516 as a JWE header. Making sense of RFC 8037 is hard unless you kn= ow where to look.

I think= this can probably be fixed by a minor revision to 8037 section 3.2.
<= div class=3D"gmail_default" style=3D"font-size:small">

It seems like ECDH-ES in JWE was design= ed for the usual method of
encrypting data using ECC, not to do anything exotic (like you seem to
be doing).

> I need a package that contains exactly enough information to be able t= o
> decrypt the message. Which means that I need both keys to be specified= in
> the recipients entry.

There are two logical recipients but one encryption key, that sounds=
exotic, yes.

=E2=80=8BNo, there is one recipient entry that= maps to one encryption key. The corresponding decryption keys are split. E= ach recipient has a different split.=C2=A0

So if the encryption key is x

Alice has Recryption key x-a, Decryption key a
=
=E2=80=8BBob has Rec= ryption key x-b, Decryption key b
=E2=80=8B..
=E2=80=8BZaphod has Recryption key x-z, Decryption key z<= /div>
= =E2=80=8BEncryption is exactly as usual. Here is the revised version:
=

{=
=C2=A0 "protected": "
ewogICJlbmMiOiAiQTI1NkNCQyJ9",
=C2=A0 "iv": "
XprRRLxypOEdc8e6Sfzeuw",
=C2=A0 "recipients": [{
=C2= =A0 =C2=A0 =C2=A0 "Header": {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 "kid": "recrypt@example.com.mm--= ma6ni-jml7o-yuc3d-p54vt-nhhov-rpwhy",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "epk": {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "PublicKeyDH": {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &quo= t;kid": "MAFWJ-EITV3-YYCTK-VBYMH-QISR2-AB4XR",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Domain= ": "
YE6bnq1MlX5ojaJto6PLP_PEwA= ",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 "Public": "
ly6= Ly2hTOA7LiyNOzFeza9NdP2YWONYDfPRryU7iA4UJ0XR89DeoCYyirkKwo-Dy
_R13gBS8ssUIPAlbLw9ZG2TMUQXsDXOfm_C4NuUyGSOKDZXmFVpGs6= a1ZDZUHgXK
JbmcVmOuc0fPuHeupnHab4xKMrcN1J= nLb25NYLLP38BMNHgwzsHW86_amQkJfkcP
GE06ft= DSLx58hM3GMIBPzs1CaPxlRQq-Z-XUa-PphpluiBPUyY59WZp7_VQiFeJL
KCqVE6RAemPUpB0L4KJN986NH-UKOg1oMqmLI_OBRHct4ReUIHgj20BG= NvgLkee9
RaPYcnjpGO39C6POMsc1vwA"}}}= ,
=C2=A0 =C2=A0 =C2=A0 "encrypted_ke= y": "
jp0wv-ScBiM8C51p9Whiw8JRM= _8z91KO7JLJJknWMfrHMbGabSdqnA"}],
= =C2=A0 "ciphertext": "
rLb= zveATVYv2jaMnsKz0LkVzz6O5DNrN5B-ZtSOoODY"}

=E2=80=8B(yes, I know epk is not standard yet)= .


I presume the actual encryption key is a point sum of the two public
keys? If so, be careful: To compute point sums on X25519 correctly, you
need to know the y coordinate signs of the points, as the resulting
point will be different depending on if the signs are the same or
the opposite.

=E2=80=8BWhich is why I plan to use the Edwards c= urves for encryption, not the Montgomery.=E2=80=8B Yes, I know it is possib= le to do point sums on X25519 but why go through the covfefe when you need = Edwards anyway?


> It is not clear to me whic= h way is the best way forward here. I am going to
> be writing up a draft to describe the format for recryption which is g= oing
> to be rather different to JOSE work anyway because my format is design= ed to
> allow efficient encryption of entire files. So my eventual format is g= oing
> to be something like:
>
=E2= =80=8B=E2=80=8B
> {JSON stuff}
> <RS><WrappedKey><IV><Ciphertext><MAC&g= t;

Be careful: Encrypting entiere files is not as easy as it seems.
=

=E2=80=8B=E2=80=8BYes, particularly when you have to support m= odes like streaming. The question I have been asking myself is whether to h= ave a 'simple' format which is unchunked and an advanced format whi= ch is chunked.

Now = that you point out that the 'simple' mode also gets complex for ver= y large files, I am thinking of just making chunking a requirement.

The corner case would be to su= pport random access efficiently. Which could be done by fixing the chunk si= ze in advance. If you know the chunk size is fixed at 1MB, and the framing = records are also fixed size (always rekey, always drop the MAC tag), you ca= n do random access provided that your encryption mode allows a block to be = changed in the middle of the cipher stream without causing changes to any b= locks other than the next one.


For some ideas, maybe look at
=E2=80=8B=E2=80=8B
HTTP encrypted content-cod= ing, as that
also has the problem of encrypting possibly very large files.

Neither
=E2=80=8B=E2=80=8B
AES-GCM nor
=E2=80=8B=E2=80=8B
Chacha20-Poly13= 05-AEAD can encrypt a 500GB file in
one shot, even if you had enough memory.

=E2=80=8B256GB see= ms to be the limit...=C2=A0

Given that the framing overhead is going to be a 256 bit key + 128 bit w= rap+ 128 bit tag + 128 bit IV =3D 80 bytes, I don't see having to intro= duce framing every 1GB or so would be an imposition.

It is probably prudent to have a checksum every= GB or so anyway.


--001a113cc6b6d715550557fe207b-- From nobody Wed Aug 30 14:36:43 2017 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 1B83C13239A for ; Wed, 30 Aug 2017 14:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 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, SPF_PASS=-0.001, TRACKER_ID=1.306] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l77pf01_Ehsm for ; Wed, 30 Aug 2017 14:36:39 -0700 (PDT) Received: from mail4.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 62095132A91 for ; Wed, 30 Aug 2017 14:36:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0153_01D3219D.5F8A5640" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504128964; h=from:subject:to:date:message-id; bh=rolG4tCtCD5sJN3BIUt3fs1duernef0TSTJYh6VAUWM=; b=BnC+Dzs6VJOIM60IMbDWKOIhxNV/KG+CPzdEDTLz7+VDn5G0aqD8pYhHewV64L0vRhF6pNNk8JF AIMF9dVoBtmFkMb9Kl1KZJG6NPU7dEBLxxiL2LxT+U6euNykGZ+7IfgLyHRI6IBQZ18EwoZGkTjXi n5nHvA81WALWIuNAhzmcOd+hfdfZBTn/e3PbplcIG2OoFXJmyic9IZr9ebJHapFvDL5vDjyUryBVZ P8RW0JstvXkuguWuxxSP6LSvp0KGqn5oQNiiNMCis5rutvn5C6kmU+o2q560Ng4T2Kk+L535KH/rz 4VGjJg7zdUdJvm8xd/HrOrcU7Wl/XU/RUBGg== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 14:36:03 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 14:35:58 -0700 From: Jim Schaad To: 'Phillip Hallam-Baker' CC: 'Curdle' References: <013f01d321c2$93c3c890$bb4b59b0$@augustcellars.com> In-Reply-To: Date: Wed, 30 Aug 2017 14:36:29 -0700 Message-ID: <015201d321d8$0be70b60$23b52220$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFxU7uyFKtn27vXYLlCM8cWvmQn5QF3mPXfAajjbmujSARnQA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 21:36:42 -0000 ------=_NextPart_000_0153_01D3219D.5F8A5640 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t understand you position here. =20 =20 Either you are using the existing algorithm, and the field is therefore = defined or You are creating a new algorithm, and are therefore free to define the = use of the field for your algorithm =20 Jim =20 =20 From: hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip = Hallam-Baker Sent: Wednesday, August 30, 2017 12:27 PM To: Jim Schaad Cc: Curdle Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient =20 Ah, the epk parameter is defined in RFC7518 (JSON Web Algorithms) and = not RFC 7516 (JSON Web Encryption) =20 =E2=80=8B=E2=80=8B4.6.1.1. =20 I think that deserves an errata as it is entirely reasonable for the = encryption mechanism to be specified in the RFC titled 'encryption'. =20 =20 =20 On Wed, Aug 30, 2017 at 3:02 PM, Jim Schaad > wrote: Start by looking at section 5.4 of RFC 7520 =E2=80=93 which is doing = what you are looking for. =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org = ] On Behalf Of Phillip Hallam-Baker Sent: Wednesday, August 30, 2017 10:23 AM To: Curdle > Subject: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient =20 I am currently working on making Mesh/Recrypt work. This is basically = three key public key cryptography. Instead of having one key to encrypt = and one to decrypt, we have one to encrypt and the decryption key is = split into two that have to BOTH be applied for decryption. =20 OK so for the purposes of this issue, the encryption is exactly the same = as for two key DH. =20 Since the world is moving to ECDH, I am writing my code using = Diffie-Hellman key agreement which RFC7516 doesn't really support. So I = extended the format as follows: =20 Sender: =20 * Generates a random session key * Encrypts message under the session key =20 * jwk =3D a new ephemeral generated per key exchange. * kid =3D identifier of group public key which is the UDF fingerprint of = the key itself. * Performs a key exchange against the group public key to create the key = agreement value. * Performs HKDF as specified in RFC 5869 to obtain an encryption key * encrypted_key =3D Key wrapping as specified in RFC 3394 to encrypt = the session key=20 =20 This produces the following JSON package: =20 { "protected": " ewogICJlbmMiOiAiQTI1NkNCQyJ9", "iv": " zLuTMmoOJHUp68hl8eB6Fw", "recipients": [{ "Header": { "kid": "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-45BX7", "jwk": { "PublicKeyDH": { "kid": "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB", "Domain": "YE6bnq1MlX5ojaJto6PLP_PEwA", "Public": " hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByfraUGTMrYdZxbrpVIpP 5-60Jysf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb8mcbCnpvJRGMDGx6WV tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncmASBJWqxRZJErfCkWku HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn_kVgm6YcckdYM4lw6d TndMNjb8fQn0_giaK4USRo6B27WsNx6wjNiKD3OIA05NgpM2HPB4RZ1rvJaugH0J bgWEalUCQDS3ME4THMiMxgA"}}}, "encrypted_key": " NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIzST3NPyuA"}], "ciphertext": " -p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58"} =20 OK so what is wrong? =20 Well jwk is supposed to be the key identifier of the recipient key for a = start. There is no way to express the DH key exchange properly in JOSE = because it assumes that the Key Exchange is performed using symmetric or = public key encryption. DH is neither, it is a key exchange. =20 RFC 7818 is no help: https://tools.ietf.org/html/rfc7518#section-4.6 =20 So as I was looking into this, I had the idea of looking at RFC 8037 to = see how the problems are solved there and, well they aren't as far as I = can see. In fact things look worse as the Edwards and Montgomery forms = are treated as if they are the same and they are not. =20 It looks to me as if we actually do need to do quite a bit of work to = specify how to do encryption with ECDH in Jose. Unless of course I am = reading the spec wrong which is quite possible. But my impression is = that nobody implemented these options in running code or if they did, = their work didn't make it back to the spec as it should. =20 =20 I need a package that contains exactly enough information to be able to = decrypt the message. Which means that I need both keys to be specified = in the recipients entry. =20 I don't want to mix the ephemeral key data into the encrypted_key blob = which would be the other way to do things. =20 =20 It is not clear to me which way is the best way forward here. I am going = to be writing up a draft to describe the format for recryption which is = going to be rather different to JOSE work anyway because my format is = designed to allow efficient encryption of entire files. So my eventual = format is going to be something like:=20 =20 {JSON stuff} =20 If we are doing end-to-end encrypted Web, we might not want to do a Key = Exchange mediated by the recryption service on every file encrypted. So = it is likely that multiple data items will share a set of key exchange = parameters. So I am going to have some identification information to = allow those results to be cached. =20 One option is to add the additional pieces I need into an extension = draft covering my additional tags. Another is to produce two drafts. =20 =20 My feeling is that right now, I am probably the only person using JSON = as a replacement for PKCS#7 / CMS so it is quite likely I am the only = person who is going to be using Ed25518 or X25519 to encrypt large = chunks of data. =20 =20 =20 =20 =20 =20 ------=_NextPart_000_0153_01D3219D.5F8A5640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I = don=E2=80=99t understand you position here.=C2=A0

 

Either you = are using the existing algorithm, and the field is therefore defined = or

You are creating a new algorithm, = and are therefore free to define the use of the field for your = algorithm

 

Jim

 

 

From: = hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip = Hallam-Baker
Sent: Wednesday, August 30, 2017 12:27 = PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: = Curdle <curdle@ietf.org>
Subject: Re: [Curdle] = Encryption in CFRG curves, RFC 8037 not = sufficient

 

Ah, the epk parameter = is defined in RFC7518 (JSON Web Algorithms) and not RFC 7516 (JSON Web = Encryption)

 

=E2=80=8B=E2=80=8B4.6.1.1.

 

I think that deserves = an errata as it is entirely reasonable for the encryption mechanism to = be specified in the RFC titled = 'encryption'.

 

 

 

On Wed, = Aug 30, 2017 at 3:02 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

Start by = looking at section 5.4 of RFC 7520 =E2=80=93 which is doing what you are = looking for.

 <= /o:p>

Jim

 <= /o:p>

 <= /o:p>

From:= Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of = Phillip Hallam-Baker
Sent: Wednesday, August 30, 2017 = 10:23 AM
To: Curdle <curdle@ietf.org>
Subject: [Curdle] = Encryption in CFRG curves, RFC 8037 not = sufficient

 <= /o:p>

I am currently working on making Mesh/Recrypt = work. This is basically three key public key cryptography. Instead of = having one key to encrypt and one to decrypt, we have one to encrypt and = the decryption key is split into two that have to BOTH be applied for = decryption.

 

OK so for the purposes of this issue, the = encryption is exactly the same as for two key = DH.

 

Since the world is moving to ECDH, I am = writing my code using Diffie-Hellman key agreement which RFC7516 doesn't = really support. So I extended the format as = follows:

 

Sender:

 

* Generates a random session = key

* Encrypts message under the = session key

 

* jwk =3D a new ephemeral generated per key = exchange.

* kid =3D identifier of group public key = which is the UDF fingerprint of the key = itself.

* Performs a key exchange against the group = public key to create the key agreement = value.

* Performs HKDF as specified in = RFC 5869 to = obtain an encryption key

* encrypted_key =3D  Key wrapping as specified = in RFC 3394 to encrypt the session = key 

 

This produces the following JSON = package:

 

{

  "protected": = "

ewogICJlbmMiOiAiQTI1NkNCQyJ9",

  "iv": = "

zLuTMmoOJHUp68hl8eB6Fw",

  "recipients": = [{

      "Header": = {

        "kid": = "MDQIW-GSFHP-YFE5E-O6ITK-3EUGH-45BX7",

        "jwk": = {

          = "PublicKeyDH": {

            = "kid": = "MAQ74-DJJMN-Y4GJ6-ZDXR5-A2SV7-5JGEB",

            = "Domain": = "YE6bnq1MlX5ojaJto6PLP_PEwA",

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>            = "Public": "

hO-l2oeNCKGubSGpSjcwA9j1VmsF_CboNMEwqhzv4PlByf= raUGTMrYdZxbrpVIpP

5-60Jysf5VXTdURyviEOu-dDjVVpOddAjB6jZSVSzxIiqb= 8mcbCnpvJRGMDGx6WV

tOE6yF7MX-2pXPO5Jp7c-vaKYcV0gVOTmO4FhGC757xncm= ASBJWqxRZJErfCkWku

HCb1sFXXJX0IbvxJR6-GF-azFuSufcj7j1ACuFNR5Ejvyn= _kVgm6YcckdYM4lw6d

TndMNjb8fQn0_giaK4USRo6B27WsNx6wjNiKD3OIA05Ngp= M2HPB4RZ1rvJaugH0J

bgWEalUCQDS3ME4THMiMxgA"}}},<= /o:p>

      = "encrypted_key": "

NfsohR3nHvwlopACABCQIdDIU1mZf5BLwWRThdDTSA0UIz= ST3NPyuA"}],

  "ciphertext": = "

-p2gBUNot_ecZQalDmkyS-I1M5UxB4_6X0pPlojPM58&qu= ot;}

 

OK so what is = wrong?

 

Well jwk is supposed to be the key identifier = of the recipient key for a start. There is no way to express the DH key = exchange properly in JOSE because it assumes that the Key Exchange is = performed using symmetric or public key encryption. DH is neither, it is = a key exchange.

 

RFC 7818 is no = help:

 

So as I was looking into this, I had the idea = of looking at RFC 8037 to see how the problems are solved there and, = well they aren't as far as I can see. In fact things look worse as the = Edwards and Montgomery forms are treated as if they are the same and = they are not.

 

It looks to me as if we actually do need to = do quite a bit of work to specify how to do encryption with ECDH in = Jose. Unless of course I am reading the spec wrong which is quite = possible. But my impression is that nobody implemented these options in = running code or if they did, their work didn't make it back to the spec = as it should.

 

 

I need a package that contains exactly enough = information to be able to decrypt the message. Which means that I need = both keys to be specified in the recipients = entry.

 

I don't want to mix the ephemeral key data = into the encrypted_key blob which would be the other way to do = things.

 

 

It is not clear to me which way is the best = way forward here. I am going to be writing up a draft to describe the = format for recryption which is going to be rather different to JOSE work = anyway because my format is designed to allow efficient encryption of = entire files. So my eventual format is going to be something = like: 

 

{JSON = stuff}

<RS><WrappedKey><IV><Ciph= ertext><MAC>

 

If we are doing end-to-end encrypted Web, we = might not want to do a Key Exchange mediated by the recryption service = on every file encrypted. So it is likely that multiple data items will = share a set of key exchange parameters. So I am going to have some = identification information to allow those results to be = cached.

 

One option is to add the additional pieces I = need into an extension draft covering my additional tags. Another is to = produce two drafts.

 

 

My feeling is that right now, I am probably = the only person using JSON as a replacement for PKCS#7 / CMS so it is = quite likely I am the only person who is going to be using Ed25518 or = X25519 to encrypt large chunks of = data.

 

 

 

 

 

=

 

------=_NextPart_000_0153_01D3219D.5F8A5640-- From nobody Wed Aug 30 15:01:30 2017 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 9EF31132A80 for ; Wed, 30 Aug 2017 15:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, 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 tRSvb96TGwQD for ; Wed, 30 Aug 2017 15:01:27 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 B8A9413239A for ; Wed, 30 Aug 2017 15:01:27 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id t75so62190671oie.3 for ; Wed, 30 Aug 2017 15:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=McSIz4oqrFBEiGuBwnRYkBHM3t45lC/Aooubghf+vWo=; b=gTHAKQtXl2bspoooTcwyrfVhSqSQbvBcGm0R9+/BizRZ8lVyCy4oH8CtHmtuRQWGo+ 2D6pflpvZQ+rXnCUT1iQINfMAjCYXMj3bewfd23048lkbOajetemO8fUtQ9LdqgViMrf SCVEOZ9Giumh8064Gsyhu7ynu4m3JzjS1GRCwQSpoOTW2OTbnUeKEGPXCtkOw9S6RB+/ hMRgKsptKpVO0TW1Ym1hUcTapYKwGtQEQJJbJ6TT2EVK+HHBONk+QnhNZrCW6TN3KcsT VibfIr6K0oWtGQA7X5ByrnLk5zavTKBQg2n9avewS9pQB9GUPZIZmVqcKvvCRgaRKIv8 HkmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=McSIz4oqrFBEiGuBwnRYkBHM3t45lC/Aooubghf+vWo=; b=cum/MGFq9iPi6UASMPs8EJBbDT3ZClUH7qhNGlcqKMU5QjF8QbZ+XukaQ+iR195MFk 5KTqXhKE84tXUpN7h3smIQzOMhZre2ljFlzYs/8yvzanaiC2en1BTnqAvkBM5TL+h9oW 62eesYa3IRYGdGLNNo2ofi8QxU+KR+REvmemdtJJNuecwKUoLmBvMR00e4H7EqM05NkL KXwCQ3jjkIs6LzMORCMjfc90g/yJDE2dWeTF/lBEaKtpVPOWTkBEsNaTTqbbLCaQLxYi SwqFzAsgO+zLYpSGWoph63Ix3xWxli2JkAxT+bMIK3LOOrDdM83xOUMkw9e3PewYLGM0 E9UA== X-Gm-Message-State: AHYfb5gVt6gJGS2D6trdX2AL3XIpWn/bAW4fEIetk/R7DWYFLnXd3dDn mNhYy8Xbppw2SkWWp+/qxgNVSvUF6HnZ X-Received: by 10.202.229.198 with SMTP id c189mr2631539oih.5.1504130486508; Wed, 30 Aug 2017 15:01:26 -0700 (PDT) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.157.48.212 with HTTP; Wed, 30 Aug 2017 15:01:25 -0700 (PDT) In-Reply-To: <015201d321d8$0be70b60$23b52220$@augustcellars.com> References: <013f01d321c2$93c3c890$bb4b59b0$@augustcellars.com> <015201d321d8$0be70b60$23b52220$@augustcellars.com> From: Phillip Hallam-Baker Date: Wed, 30 Aug 2017 18:01:25 -0400 X-Google-Sender-Auth: hzMzIxlNGICcT1SZ1aQbbLyQLvY Message-ID: To: Jim Schaad Cc: Curdle Content-Type: multipart/alternative; boundary="001a11413ef45821e20557ffab5f" Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 22:01:29 -0000 --001a11413ef45821e20557ffab5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 30, 2017 at 5:36 PM, Jim Schaad wrote: > I don=E2=80=99t understand you position here. > > > > Either you are using the existing algorithm, and the field is therefore > defined or > > You are creating a new algorithm, and are therefore free to define the us= e > of the field for your algorithm > > > > Ji > =E2=80=8Bm > > =E2=80=8Bepk looks to me to be a field to specify an ephemeral key for use = in any key agreement based encryption rather than a =E2=80=8Bfield that is specifi= c to just one key agreement. When the JOSE docs were created, there was only one key agreement mechanism specified. Now 8037 adds a second. The problem is that 8037 does not actually define a epk field, it assumes that it is already specified for JWE where it is actually only specified for one EC curve on JWE. This is going to get even more confusing if someone comes along and specifies a new key agreement, even more so if they used a different field. --001a11413ef45821e20557ffab5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 30= , 2017 at 5:36 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I don=E2=80=99t understand you position here.=C2=A0 <= /p>

=C2=A0

Ei= ther you are using the existing algorithm, and the field is therefore defin= ed or

You are creating a new algori= thm, and are therefore free to define the use of the field for your algorit= hm

=C2=A0

Ji

=E2=80=8Bm


=E2=80=8Bepk loo= ks to me to be a field to specify an ephemeral key for use in any key agree= ment based encryption rather than a =E2=80=8Bfield that is specific to just= one key agreement.

When = the JOSE docs were created, there was only one key agreement mechanism spec= ified. Now 8037 adds a second. The problem is that 8037 does not actually d= efine a epk=C2=A0field, it assumes that it is already specified for JWE whe= re it is actually only specified for one EC curve on JWE.

This is going to get even more confusing= if someone comes along and specifies a new key agreement, even more so if = they used a different field.

--001a11413ef45821e20557ffab5f-- From nobody Wed Aug 30 15:36:50 2017 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 2EB0D132960 for ; Wed, 30 Aug 2017 15:36:49 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjgERM1GSJeA for ; Wed, 30 Aug 2017 15:36:47 -0700 (PDT) Received: from mail4.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 60809132A19 for ; Wed, 30 Aug 2017 15:36:35 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01D321A5.A88D0150" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1504132561; h=from:subject:to:date:message-id; bh=EUTlkNuutA7EHbQm8dqSBRETMvY15h4BzENNSdGpDC0=; b=B522gDjNmBAM9NnSLkc8b6XEuCgw7r3vNqcVR6vXfITi0Y6wr1VqhmSi/g70OJU7zg/ipVeqRJG QIqypWB9FkTQ6xAdt26zR7m6I0+YMzqtIlGwI/zN5bbWTFXOx/pkm5/TQP9Y81qY37+U89kS586bP HDP7DQRSJC5qRPxXZLruKary8hs0Hxxrs48L7bg3wXXs1n37NxAH7pQDT5dUtxMylAr8jOIqioZkC QSZWDVW65CQN39vPhFPcKosHzMYkyblRzkknL9h2sDpRaGTP9xT5PZ2RreZ9QSWzdzALxCStPxJ7K W9yhzyVbBfrj1THo+3uS3Ura5wY2aUftvXjQ== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 15:36:00 -0700 Received: from Hebrews (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 15:35:16 -0700 From: Jim Schaad To: 'Phillip Hallam-Baker' CC: 'Curdle' References: <013f01d321c2$93c3c890$bb4b59b0$@augustcellars.com> <015201d321d8$0be70b60$23b52220$@augustcellars.com> In-Reply-To: Date: Wed, 30 Aug 2017 15:35:47 -0700 Message-ID: <015f01d321e0$54eb3d10$fec1b730$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFxU7uyFKtn27vXYLlCM8cWvmQn5QF3mPXfAajjbmsBVaMkSwC9GGRwozd9QjA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient X-BeenThere: curdle@ietf.org X-Mailman-Version: 2.1.22 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, 30 Aug 2017 22:36:49 -0000 ------=_NextPart_000_0160_01D321A5.A88D0150 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip = Hallam-Baker Sent: Wednesday, August 30, 2017 3:01 PM To: Jim Schaad Cc: Curdle Subject: Re: [Curdle] Encryption in CFRG curves, RFC 8037 not sufficient =20 =20 On Wed, Aug 30, 2017 at 5:36 PM, Jim Schaad > wrote: I don=E2=80=99t understand you position here. =20 =20 Either you are using the existing algorithm, and the field is therefore = defined or You are creating a new algorithm, and are therefore free to define the = use of the field for your algorithm =20 Ji =E2=80=8Bm =20 =E2=80=8Bepk looks to me to be a field to specify an ephemeral key for = use in any key agreement based encryption rather than a =E2=80=8Bfield = that is specific to just one key agreement. =20 When the JOSE docs were created, there was only one key agreement = mechanism specified. Now 8037 adds a second. The problem is that 8037 = does not actually define a epk field, it assumes that it is already = specified for JWE where it is actually only specified for one EC curve = on JWE. =20 This is going to get even more confusing if someone comes along and = specifies a new key agreement, even more so if they used a different = field. =20 =20 [JLS] RFC 8037 does define a new key type, however it does not define a = new key agreement algorithm. It uses the same set of algorithms that = are defined in the JWA document. This can be seen in the text of = section 3.2 where it points to section 4.6 of 7518 to say that these are = the algorithms that are being used. This is different than the = signature algorithm, where a new algorithm is defined. This is also = reflected in the IANA considerations where only one algorithm (EdDSA) = has been defined. =20 This is exactly the same approach that is used or both COSE and CMS. =20 Jim =20 ------=_NextPart_000_0160_01D321A5.A88D0150 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = hallam@gmail.com [mailto:hallam@gmail.com] On Behalf Of Phillip = Hallam-Baker
Sent: Wednesday, August 30, 2017 3:01 = PM
To: Jim Schaad <ietf@augustcellars.com>
Cc: = Curdle <curdle@ietf.org>
Subject: Re: [Curdle] = Encryption in CFRG curves, RFC 8037 not = sufficient

 

 

On Wed, Aug 30, 2017 at 5:36 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

I = don=E2=80=99t understand you position here. 

 <= /o:p>

Either you = are using the existing algorithm, and the field is therefore defined = or

You are = creating a new algorithm, and are therefore free to define the use of = the field for your algorithm

 <= /o:p>

Ji

=E2=80=8Bm

 

=E2=80=8Bepk looks to = me to be a field to specify an ephemeral key for use in any key = agreement based encryption rather than a =E2=80=8Bfield that is specific = to just one key agreement.

 

When the JOSE docs = were created, there was only one key agreement mechanism specified. Now = 8037 adds a second. The problem is that 8037 does not actually define a = epk field, it assumes that it is already specified for JWE where it = is actually only specified for one EC curve on = JWE.

 

This is going to get = even more confusing if someone comes along and specifies a new key = agreement, even more so if they used a different = field.

 

 

[JLS] =C2=A0RFC 8037 does define a new key type, = however it does not define a new key agreement algorithm.=C2=A0 It uses = the same set of algorithms that are defined in the JWA document.=C2=A0 = This can be seen in the text of section 3.2 where it points to section = 4.6 of 7518 to say that these are the algorithms that are being = used.=C2=A0 =C2=A0This is different than the signature algorithm, where = a new algorithm is defined.=C2=A0 =C2=A0=C2=A0This is also reflected in = the IANA considerations where only one algorithm (EdDSA) has been = defined.

 

This is exactly the same = approach that is used or both COSE and CMS.

 

Jim

 

------=_NextPart_000_0160_01D321A5.A88D0150--