From nobody Sat Apr 1 15:37: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 DE3741299B8 for ; Fri, 31 Mar 2017 11:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtFygEp38lTg for ; Fri, 31 Mar 2017 11:27:02 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0109.outbound.protection.outlook.com [104.47.33.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7B51297AA for ; Fri, 31 Mar 2017 11:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2pCJtzpJUH499KA1SJ4gVQEMbFAD7z0zQpgR9PrL/+8=; b=hA9Ey/Tslvtaa/hXffOgLB9lppdGSgTv5q8yyMRH6arbx20H8mXBdjqXf6V8cfy8IOFqBJIQ83PK/1GLMztRZcDsHs1y3S+zSIWi9OPxV9TVYbX0nCi0hm/jZoNUb9HCkiqwJ8WqBiJwfR6thBTKpaOPyj4b8j6wu3HxxxumdFc= Received: from CO2PR0501MB1032.namprd05.prod.outlook.com (10.160.7.143) by BY2PR05MB696.namprd05.prod.outlook.com (10.141.222.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Fri, 31 Mar 2017 18:27:00 +0000 Received: from CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) by CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) with mapi id 15.01.1005.015; Fri, 31 Mar 2017 18:27:00 +0000 From: Anna Johnston To: Hubert Kario , "curdle@ietf.org" CC: Tero Kivinen , "Salz, Rich" , "Mark Baushke" , Peter Gutmann Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKNq8oLudfhpKUOh06KCX76vZaGrvzmAgACdpYD//7XDgIABeAuAgAFZ24D//+2rAA== Date: Fri, 31 Mar 2017 18:27:00 +0000 Message-ID: References: <22749.10831.799493.535716@fireball.acr.fi> <2986600.fVcP7dNXcW@pintsize.usersys.redhat.com> In-Reply-To: <2986600.fVcP7dNXcW@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [98.246.69.232] x-microsoft-exchange-diagnostics: 1; BY2PR05MB696; 7:rxLTm3a4yxOcYCY6AFgiYUaCHcrfoMIQoelN+9TIULNsN0+y0X9qrAfSDEPnLryNTgDAcBt/prrXnhIBnIaiDSBPbopvHPOBg2iUn5LcbOTjRA/wydBIm1dXOg3D9XOwTeZFfDPYxlCq01SzqMdYsJy0cM7SGLHEH0Dwbm0DZkhXdEUS1tK2PTjuoUoqR1/kQa2sP2UwwB0laL8qH0Z3TDFW5Pt9OuZK/JZN/J+jAisRDFHYRpLxysMZzIPfNc5fOc02gP5SI7y3+0lrMNd2CEI8MO6XVKDJGZFY4J5Hz9RoNR1VcqNAOayEqqwLxL59Dc+yRsKKYnwobl6rSTx7DQ== x-ms-office365-filtering-correlation-id: 8aadc97f-4f68-42cb-cc44-08d478638582 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:BY2PR05MB696; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148); SRVR:BY2PR05MB696; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB696; x-forefront-prvs: 02638D901B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39860400002)(39450400003)(39400400002)(39410400002)(39840400002)(24454002)(377454003)(6486002)(2906002)(36756003)(2950100002)(6506006)(77096006)(93886004)(15974865002)(86362001)(229853002)(7736002)(230783001)(38730400002)(122556002)(6246003)(54356999)(76176999)(50986999)(66066001)(2900100001)(8936002)(2501003)(8676002)(4326008)(53546009)(81166006)(83716003)(102836003)(99286003)(6116002)(54906002)(3660700001)(25786009)(6436002)(5660300001)(3846002)(6512007)(33656002)(189998001)(53936002)(82746002)(3280700002)(305945005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB696; H:CO2PR0501MB1032.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2B91F9D0BAB49547876F2B86296C4AE5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2017 18:27:00.1548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB696 Archived-At: X-Mailman-Approved-At: Sat, 01 Apr 2017 15:37:09 -0700 Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Fri, 31 Mar 2017 18:27:05 -0000 QSDigJhCYWNrZG9vcuKAmSBpbiBjcnlwdG8gaXMgYW4gYXR0YWNrIHdoaWNoIGlzIGhhcmQgdG8g ZmluZC4gIEl0IGlzIHRyaXZpYWwgdG8gdGVzdCB0aGF0IGFuIGVsZW1lbnQgaXMgaW4gYSBwcmlt ZSBvcmRlciBzdWJncm91cC4gIEluIHByaW1lcywgYmFja2Rvb3LigJlzIGdlbmVyYWxseSByZWZl ciB0byBhIHByaW1lIHZ1bG5lcmFibGUgdG8gdGhlIFNwZWNpYWxOdW1iZXJGaWVsZFNpZXZlLiAg QmVpbmcg4oCYc2FmZeKAmSBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlIHByaW1lIGlzIG5vdCB2dWxu ZXJhYmxlIHRvIHRoZSBTTkZTLCB3aGljaCBpcyB0aGUgYmFjayBkb29yIG9mIGNvbmNlcm4uICBG b3IgZXhhbXBsZSAyXnsyMDQ4fS0xOTQyMjggaXMgYSBzYWZlIHByaW1lLCBidXQgaXMgdnVsbmVy YWJsZSB0byB0aGUgU05GUyDigJMgYXQgbGVhc3QgdGhlb3JldGljYWxseSAoU05GUyBpcyBzdGls bCBub3QgY3VycmVudGx5IHBvc3NpYmxlIGF0IDIwNDggYml0cywgYXMgaXQgcm91Z2hseSByZWR1 Y2VzIGNvbXB1dGF0aW9uIG9uIHRoZSBzaWV2ZSBieSBhYm91dCDCvCB0aGUgc2l6ZSDigJMgZXg6 IDc2OCAoSUFDUiBlUHJpbnQgMjAxNy8wNjcpIGJpdCBHTkZTIGlzIGFib3V0IGFzIGV4cGVuc2l2 ZSBhcyBhIDEwMjQgKElBQ1IgZVByaW50IDIwMTYvOTYxICkpLiAgDQoNClVzaW5nIGEgc3ViZ3Jv dXAgb2Ygb3JkZXIgMnEgaXMgbm90IHNhZmUuICBJdCBjYW4gZWFzaWx5IGJlIG1hbmlwdWxhdGVk IHRvIGxlYWsgb25lIGJpdCBwZXIgZXhwb25lbnRpYXRpb24uICBUaGUgb25seSBzYWZlIHN1Ymdy b3VwIGlzIG9uZSB0aGF0IGhhcyBhIGxhcmdlIHByaW1lIG9yZGVyDQoNCk9uIDMvMzEvMTcsIDU6 MzIgQU0sICJIdWJlcnQgS2FyaW8iIDxoa2FyaW9AcmVkaGF0LmNvbT4gd3JvdGU6DQoNCiAgICBP biBUaHVyc2RheSwgMzAgTWFyY2ggMjAxNyAxNzo1NDo1NSBDRVNUIFRlcm8gS2l2aW5lbiB3cm90 ZToNCiAgICA+IEFubmEgSm9obnN0b24gd3JpdGVzOg0KICAgID4gPiBUaGVyZSBpc27igJl0IHRo YXQgbXVjaCB0byBQb2NrbGluZ3RvbuKAmXMgdGhlb3JlbS4gIEEgZGVjZW50IHdyaXRlIHVwDQog ICAgPiA+IG9mIGl0IGlzIGluIFdpa2lwZWRpYS4gIEFzIGZvciB5b3VyIGNvbW1lbnRzOg0KICAg ID4gPiANCiAgICA+ID4gMS4gIFByb29mIG9mIG5vIGJhY2tkb29yOiAgT2YgY291cnNlIHRoZXJl IGlzIG5vIHByb29mIHRoYXQNCiAgICA+ID4gYmFja2Rvb3JzIGRvIG5vdCBleGlzdC4gIFNob3cg bWUgc3VjaCBhIHByb29mIGZvciB0aGUgZml4ZWQgcHJpbWVzLg0KICAgID4gDQogICAgPiBJIGtu b3cgdGhlcmUgaXMgbm8gYmFja2Rvb3JzIG9uIHRoZSBwcmltZXMgSSBnZW5lcmF0ZWQsIGFzIEkg ZGlkIG5vdA0KICAgID4gcHV0IGJhY2tkb29yIHRoZXJlLi4uIDotKQ0KICAgID4gDQogICAgPiBG aXhlZCBwcmltZXMgdXNlcyBOb3RoaW5nIHVwIG15IHNsZWV2ZSBudW1iZXJzIFsxXSBqdXN0IHRv IHRyeSB0bw0KICAgID4gY29udmluY2UgcGVvcGxlIHRoYXQgdGhleSBjYW5ub3QgYmUgYmFja2Rv b3JlZC4NCiAgICANCiAgICBzYWZlIHByaW1lcyBjYW4ndCBiZSBiYWNrZG9vcmVkIHRvbw0KICAg IA0KICAgIHRoZXkgaGF2ZSBzdWJncm91cHMgb2Ygc2l6ZSBwLTEsIChwLTEpLzIsIDIgYW5kIDEu DQogICAgU3ViZ3JvdXBzIG9mIHNpemUgcC0xIGFuZCAocC0xKS8yIGFyZSBzYWZlLCBzdWJncm91 cHMgb2Ygc2l6ZSAyIGFuZCAxIGFyZSANCiAgICB0cml2aWFsbHkgZGV0ZWN0YWJsZSAoanVzdCBk b24ndCBwcm9jZXNzIHZhbHVlcyBvZiBwLTEsIDAgYW5kIDEpLg0KICAgIA0KICAgIC0tIA0KICAg IFJlZ2FyZHMsDQogICAgSHViZXJ0IEthcmlvDQogICAgU2VuaW9yIFF1YWxpdHkgRW5naW5lZXIs IFFFIEJhc2VPUyBTZWN1cml0eSB0ZWFtDQogICAgV2ViOiB3d3cuY3oucmVkaGF0LmNvbQ0KICAg IFJlZCBIYXQgQ3plY2ggcy5yLm8uLCBQdXJrecWIb3ZhIDk5LzcxLCA2MTIgNDUsIEJybm8sIEN6 ZWNoIFJlcHVibGljDQoNCg== From nobody Mon Apr 3 03:49: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 028FF1250B8 for ; Mon, 3 Apr 2017 03:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tixSciqbPaGH for ; Mon, 3 Apr 2017 03:49:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7317A127B73 for ; Mon, 3 Apr 2017 03:49:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C1F280F7B; Mon, 3 Apr 2017 10:49:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5C1F280F7B Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5C1F280F7B Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BBC8B7EB8A; Mon, 3 Apr 2017 10:49:15 +0000 (UTC) From: Hubert Kario To: Anna Johnston Cc: "curdle@ietf.org" , Tero Kivinen , "Salz, Rich" , Mark Baushke , Peter Gutmann Date: Mon, 03 Apr 2017 12:49:06 +0200 Message-ID: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> In-Reply-To: References: <2986600.fVcP7dNXcW@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9625126.dMFsi95KkU"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 03 Apr 2017 10:49:28 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 10:49:33 -0000 --nextPart9625126.dMFsi95KkU Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote: > A =E2=80=98Backdoor=E2=80=99 in crypto is an attack which is hard to find= =2E It is trivial to > test that an element is in a prime order subgroup. In primes, backdoor= =E2=80=99s > generally refer to a prime vulnerable to the SpecialNumberFieldSieve.=20 > Being =E2=80=98safe=E2=80=99 does not mean that the prime is not vulnerab= le to the SNFS, > which is the back door of concern. For example 2^{2048}-194228 is a safe > prime, but is vulnerable to the SNFS but for a published parameter, it's trivial to say if it is vulnerable to S= NFS=20 or not, isn't it? > =E2=80=93 at least theoretically (SNFS is > still not currently possible at 2048 bits, as it roughly reduces > computation on the sieve by about =C2=BC the size =E2=80=93 ex: 768 (IACR= ePrint > 2017/067) bit GNFS is about as expensive as a 1024 (IACR ePrint 2016/961 > )). =20 but if you operate on a non-safe prime, you can manipulate the group so tha= t=20 it's as easy as attacking a 512 bit, if not smaller, prime. =20 > Using a subgroup of order 2q is not safe. It can easily be manipulated to > leak one bit per exponentiation. The only safe subgroup is one that has a > large prime order Interesting, any pointers on how it's done? Also, wouldn't that be a problem only if your key share is static or your R= NG=20 was really crappy? > On 3/31/17, 5:32 AM, "Hubert Kario" wrote: >=20 > On Thursday, 30 March 2017 17:54:55 CEST Tero Kivinen wrote: >=20 > > Anna Johnston writes: > >=20 > > > There isn=E2=80=99t that much to Pocklington=E2=80=99s theorem. = A decent write up > > > of it is in Wikipedia. As for your comments: > > >=20 > > > 1. Proof of no backdoor: Of course there is no proof that > > > backdoors do not exist. Show me such a proof for the fixed prime= s. > >=20 > >=20 > > I know there is no backdoors on the primes I generated, as I did not > > put backdoor there... :-) > >=20 > > Fixed primes uses Nothing up my sleeve numbers [1] just to try to > > convince people that they cannot be backdoored. >=20 > =20 > safe primes can't be backdoored too > =20 > they have subgroups of size p-1, (p-1)/2, 2 and 1. > Subgroups of size p-1 and (p-1)/2 are safe, subgroups of size 2 and 1 > are=20 > trivially detectable (just don't process values of p-1, 0 and 1).=20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Repub= lic >=20 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart9625126.dMFsi95KkU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY4iiiAAoJEJKo0bgB0vX1t8kP/3Oad8J8xybqhhyluCg+ZjbP BKz5yvagzAOSNPbbQFzhEdiB7GKFbMM0VO6QpQRkWrdJc5NQn0FXuwiRAMDLLyDj pZyR0Us5HWT4fngTbLZg28ZRpaJ0XSV2Bg+rNKGx5K6XHmweaeQmDRNCw85vArVi AVoeegQ0UDW1xVDqouyS2FLMZhOVuGwNBwAeuHWPOMnbLenJGH8p4/Ntm1Py6e6/ yrQDDPhEuPXPbUF5bFQIZkOAdI+wIoA5iPj4obc0iZyDQrb2E2R/yWDE+lcOjF4q wueBIceJ3vojGc+BnZud0d1IQecX19dTSLF9UOXiJ7PBWPCUJm/7MvfQFZ/sHqPv GBA0/7hQuYN+AhjUqFkTYxkHSsbUU7n4ZXw/YiM0xA2BdZRCPbi/MOtvh6UhCicV j8J0s1IGn3En4ahjSbCsEg7fW0fsdjWdSzYC00L94axiPrx7B1rjs1dZDf7sOdul vRnXolfrQBziM5ed/c+jhvJYN0mh8Rh8yrIOQPCu4JOfhiZ5CfWQxHzd3bW9QPh6 dpFn7mg3OvoUNlnrpqMxVARGWrP8a40/jTwzDowtxF5HhVsD0hm9KcHO6wMF3S8a g0iXk169oAy0G6O2RaevtDm5PjjHETx7+7dIpWOrqgvV9TdRG4opuMQSiKcAVw5H nTu653Dnl+dcncutJtEy =er8S -----END PGP SIGNATURE----- --nextPart9625126.dMFsi95KkU-- From nobody Mon Apr 3 07:26: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 306F6126C89 for ; Mon, 3 Apr 2017 07:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 W1TgBbzR5Xmh for ; Mon, 3 Apr 2017 07:26:26 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 199E7128CB9 for ; Mon, 3 Apr 2017 07:26:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3CD2221553; Mon, 3 Apr 2017 17:26:23 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id r1KfaZZ3BvMN; Mon, 3 Apr 2017 17:26:23 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id ED6BFC4; Mon, 3 Apr 2017 17:26:22 +0300 (EEST) Date: Mon, 3 Apr 2017 17:26:22 +0300 From: Ilari Liusvaara To: Hubert Kario Cc: Anna Johnston , "Salz, Rich" , "curdle@ietf.org" , Mark Baushke , Tero Kivinen , Peter Gutmann Message-ID: <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> References: <2986600.fVcP7dNXcW@pintsize.usersys.redhat.com> <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 14:26:29 -0000 On Mon, Apr 03, 2017 at 12:49:06PM +0200, Hubert Kario wrote: > On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote: > > A ‘Backdoor’ in crypto is an attack which is hard to find. It is trivial to > > test that an element is in a prime order subgroup. In primes, backdoor’s > > generally refer to a prime vulnerable to the SpecialNumberFieldSieve. > > Being ‘safe’ does not mean that the prime is not vulnerable to the SNFS, > > which is the back door of concern. For example 2^{2048}-194228 is a safe > > prime, but is vulnerable to the SNFS > > but for a published parameter, it's trivial to say if it is vulnerable to SNFS > or not, isn't it? AFAIK, at least some "backdoored" DH primes were primes that are secretly vulernable to SNFS, in a way that is quite hard to discover. > > Using a subgroup of order 2q is not safe. It can easily be manipulated to > > leak one bit per exponentiation. The only safe subgroup is one that has a > > large prime order > > Interesting, any pointers on how it's done? AFAIK, using subgroup of order 2q leaks a bit, but it is always the LSB that leaks, so one can't recover the scalar even from many outputs. And one way to recover the LSB is to raise the public key to power of q modulo p. If the LSB is clear, the result is 1, if the LSB is set, the result is -1. Then in some protocols, you absolutely have to use subgroup of order 2q, because if you don't, you get absolutely fatal information leakage. -Ilari From nobody Mon Apr 3 10:11: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 C416F129486 for ; Mon, 3 Apr 2017 10:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPbYLDYZIYzU for ; Mon, 3 Apr 2017 10:11:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381C2129492 for ; Mon, 3 Apr 2017 10:11:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C0DF64D8F; Mon, 3 Apr 2017 17:11:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 5C0DF64D8F Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 5C0DF64D8F Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 979A0A0A36; Mon, 3 Apr 2017 17:11:04 +0000 (UTC) From: Hubert Kario To: curdle@ietf.org Cc: Ilari Liusvaara , Anna Johnston , Peter Gutmann , "Salz, Rich" , Tero Kivinen , Mark Baushke Date: Mon, 03 Apr 2017 19:10:57 +0200 Message-ID: <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> In-Reply-To: <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1896810.bpqyYtoglI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 03 Apr 2017 17:11:05 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 17:11:12 -0000 --nextPart1896810.bpqyYtoglI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 3 April 2017 16:26:22 CEST Ilari Liusvaara wrote: > On Mon, Apr 03, 2017 at 12:49:06PM +0200, Hubert Kario wrote: > > On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote: > > > A =E2=80=98Backdoor=E2=80=99 in crypto is an attack which is hard to = find. It is > > > trivial to test that an element is in a prime order subgroup. In > > > primes, backdoor=E2=80=99s generally refer to a prime vulnerable to t= he > > > SpecialNumberFieldSieve. Being =E2=80=98safe=E2=80=99 does not mean t= hat the prime is > > > not vulnerable to the SNFS, which is the back door of concern. For > > > example 2^{2048}-194228 is a safe prime, but is vulnerable to the SNFS > >=20 > > but for a published parameter, it's trivial to say if it is vulnerable = to > > SNFS or not, isn't it? >=20 > AFAIK, at least some "backdoored" DH primes were primes that are > secretly vulernable to SNFS, in a way that is quite hard to discover. Wikipedia[1] says that the algorithm is "very efficient" (I'm assuming it's= =20 the 25% reduction in effective key size) for numbers in form r^e +- s ($ r^= {e} \pm s $), only if r and s are "relatively small". What "relatively small"=20 means in this context? Relatively small in relation to general numbers used= in=20 crypto, or in relation to number tested? 194228 is only 18bit long, iterating over all `r` up to, say, 2^20 and=20 checking if the needed s is smaller than 2^64 shouldn't take more time than= =20 verifying primality certificates for a 2048 or 4096 bit safe prime anyway... It also states that it is "efficient" (no idea if that means 20% or 5%=20 reduction in effective key size) for number in form ar^e+-bs^f ($ ar^{e}\pm= =20 bs^{f} $) or ones with low Hamming weight. While Hamming weight is trivial = to=20 test, the more complex form is more problematic. > > > Using a subgroup of order 2q is not safe. It can easily be manipulat= ed > > > to > > > leak one bit per exponentiation. The only safe subgroup is one that = has > > > a > > > large prime order > >=20 > > Interesting, any pointers on how it's done? >=20 > AFAIK, using subgroup of order 2q leaks a bit, but it is always the LSB t= hat > leaks, so one can't recover the scalar even from many outputs. >=20 > And one way to recover the LSB is to raise the public key to power of q > modulo p. If the LSB is clear, the result is 1, if the LSB is set, the > result is -1. that was my understanding too 1 - Please excuse me, I'm not a cryptographer/mathematician, I just play o= ne=20 on TV. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1896810.bpqyYtoglI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY4oIhAAoJEJKo0bgB0vX1pn4P/iiSGBM23EeV/ZWDzkJRYzdD FZsD2nghBq05EAVkZJP/B+CoKyjwqZb2TWtzMkWAcsJgbm2PKRHU+8Y8cujjq7L3 nld9JeTitF00rlzFOZGx8YRQYgNRUSfq/bgtBS679KKdeHjL0FdXGkZqH9tjzvvv FTVX8pTC1Fx7mIlhu59CvKF9zP8Q9LbXHSXmR4O9Q80+EYlzB/YmC2/Zm13w8pW1 DlOzFhOtzfdGWAZ60CczayXKLdlMJP8chaHM7h9+pR+Aj9f6u0fI2TbOa/xm3ImW b3sjKNMkRthPmIA4DhEreachTYBdhCRWpYzNh0/qGNWyC8KETpcLWN4bj5DMB2l5 3QAXEgBibwMBf4m+xQdpXR7QNbc5q0F1zHUE+fEmM2aJwZO2zA00yOGQNt2svSOt agkhiw960K5vctR1XPsMswNCgvhV9/l9NscqmjIH3/t7UavaxoJTtPe9l2RIwO1/ 1+5g8mIxFVOzL1VK5zKgTYZQ8H7aZwBuJm05oiWqh1tk6Ek/zNfMR1JMSnR/3lAR 7mD1S9yiQgiLv4kr8P7mDRAI0Araj7E3jYy6wkd4PWahge8pSEjjB00fvvuZVafu OYfDRXUCc2k7vPphVeFB6t57xeMEtX8nWX9vOD1Z3LEPYZyvK19ywCHdRqjgbhmZ lDlykN4LPyNQGyPsD7iz =0JtW -----END PGP SIGNATURE----- --nextPart1896810.bpqyYtoglI-- From nobody Mon Apr 3 10:30: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 306E112949B for ; Mon, 3 Apr 2017 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 8DBuz1CFFojG for ; Mon, 3 Apr 2017 10:30:05 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id C561112949D for ; Mon, 3 Apr 2017 10:30:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4830620D77; Mon, 3 Apr 2017 20:30: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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id iElA0p47gbKH; Mon, 3 Apr 2017 20:30:03 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 0FA9921C; Mon, 3 Apr 2017 20:30:03 +0300 (EEST) Date: Mon, 3 Apr 2017 20:30:02 +0300 From: Ilari Liusvaara To: Hubert Kario Cc: curdle@ietf.org, Anna Johnston , Peter Gutmann , "Salz, Rich" , Tero Kivinen , Mark Baushke Message-ID: <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 17:30:07 -0000 On Mon, Apr 03, 2017 at 07:10:57PM +0200, Hubert Kario wrote: > On Monday, 3 April 2017 16:26:22 CEST Ilari Liusvaara wrote: > > On Mon, Apr 03, 2017 at 12:49:06PM +0200, Hubert Kario wrote: > > > On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote: > > > > A ‘Backdoor’ in crypto is an attack which is hard to find. It is > > > > trivial to test that an element is in a prime order subgroup. In > > > > primes, backdoor’s generally refer to a prime vulnerable to the > > > > SpecialNumberFieldSieve. Being ‘safe’ does not mean that the prime is > > > > not vulnerable to the SNFS, which is the back door of concern. For > > > > example 2^{2048}-194228 is a safe prime, but is vulnerable to the SNFS > > > > > > but for a published parameter, it's trivial to say if it is vulnerable to > > > SNFS or not, isn't it? > > > > AFAIK, at least some "backdoored" DH primes were primes that are > > secretly vulernable to SNFS, in a way that is quite hard to discover. > > Wikipedia[1] says that the algorithm is "very efficient" (I'm assuming it's > the 25% reduction in effective key size) for numbers in form r^e +- s ($ r^{e} > \pm s $), only if r and s are "relatively small". What "relatively small" > means in this context? Relatively small in relation to general numbers used in > crypto, or in relation to number tested? AFAIK, the problem is that those numbers (however "small" is defined) aren't the only ones SNFS is efficient for: There are random-looking numbers that turn out to be vulernable to SNFS, or worse, are vulernable to SNFS if one knows some hidden piece of information. -Ilari From nobody Mon Apr 3 10:35: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 0C6451294AE for ; Mon, 3 Apr 2017 10:35:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhWwCpOn3RWZ for ; Mon, 3 Apr 2017 10:35:00 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D531294B6 for ; Mon, 3 Apr 2017 10:34:59 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id x35so118337861qtc.2 for ; Mon, 03 Apr 2017 10:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yI+as5kniDZ0/+wkOitJm4hhNCsbSM4WjCKdsiDEAKI=; b=Mg1gohib31nL0wjQ8SP7g1dq7Bn6rfKMuAk+Fv7pz+xr/YQFZsGzEWdBmGrGOXDAuU ozqIBLyZOTukasjC78HbijTwy0QvyqV6ijkbDHO0Q5kax271UoGKRpqb48CRoCHufLvQ JWNEjxBqSA4krlrxToO6cjJbqiAag3pldqMg0= 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=yI+as5kniDZ0/+wkOitJm4hhNCsbSM4WjCKdsiDEAKI=; b=exI/L8+oW04wbbexyxAVTXJ552HvBoKo/itjkeNQ4cq0sKoJTmPZ5O6b3mamPBAdPb QqHL+yEZN79RgEsuvzR6a579hJha9gSzJsFZdykvYVYUOWsEz7rF8kcFFpq9iJIfQx4Y GZJDepUn60si83ata8T2oe84Qm/+7g2vbm7AkFIsSv0g3/hlwxrILN7MxGEZ5be0+bhF WCxwt8tmf5GqMVEk6Wf1Si/PvW7O+zZhdtBJ/DUUNMu9X1QighbALNH+MG4Mo62vXuU3 0+nqfLjbFvcRbSwzWhlD7qu+ijm/+WL58k+Rqb6kz9gbReWpv6GSdebH4F3agKU/41Fb rqcw== X-Gm-Message-State: AFeK/H1co+U2ew92vsr9xzjobijzVYui1/TUra/wgXNHKutFTXLIZUzFvriVA0cj4jdwOl+9Tae44Sok4AfUMA== X-Received: by 10.200.49.76 with SMTP id h12mr17608085qtb.44.1491240898216; Mon, 03 Apr 2017 10:34:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Mon, 3 Apr 2017 10:34:57 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> From: Kyle Rose Date: Mon, 3 Apr 2017 12:34:57 -0500 Message-ID: To: Ilari Liusvaara Cc: Hubert Kario , Anna Johnston , curdle@ietf.org, Peter Gutmann , "Salz, Rich" , Tero Kivinen , Mark Baushke Content-Type: multipart/alternative; boundary=001a11403046035d1e054c4694df Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 17:35:12 -0000 --001a11403046035d1e054c4694df Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 3, 2017 at 12:30 PM, Ilari Liusvaara wrote: > On Mon, Apr 03, 2017 at 07:10:57PM +0200, Hubert Kario wrote: > > On Monday, 3 April 2017 16:26:22 CEST Ilari Liusvaara wrote: > > > On Mon, Apr 03, 2017 at 12:49:06PM +0200, Hubert Kario wrote: > > > > On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote: > > > > > A =E2=80=98Backdoor=E2=80=99 in crypto is an attack which is hard= to find. It is > > > > > trivial to test that an element is in a prime order subgroup. In > > > > > primes, backdoor=E2=80=99s generally refer to a prime vulnerable = to the > > > > > SpecialNumberFieldSieve. Being =E2=80=98safe=E2=80=99 does not me= an that the prime > is > > > > > not vulnerable to the SNFS, which is the back door of concern. F= or > > > > > example 2^{2048}-194228 is a safe prime, but is vulnerable to the > SNFS > > > > > > > > but for a published parameter, it's trivial to say if it is > vulnerable to > > > > SNFS or not, isn't it? > > > > > > AFAIK, at least some "backdoored" DH primes were primes that are > > > secretly vulernable to SNFS, in a way that is quite hard to discover. > > > > Wikipedia[1] says that the algorithm is "very efficient" (I'm assuming > it's > > the 25% reduction in effective key size) for numbers in form r^e +- s (= $ > r^{e} > > \pm s $), only if r and s are "relatively small". What "relatively smal= l" > > means in this context? Relatively small in relation to general numbers > used in > > crypto, or in relation to number tested? > > AFAIK, the problem is that those numbers (however "small" is defined) > aren't the only ones SNFS is efficient for: There are random-looking > numbers that turn out to be vulernable to SNFS, or worse, are vulernable > to SNFS if one knows some hidden piece of information. > How likely are you to end up with one of those numbers (the unintentionally-vulnerable to SNFS variety) if you choose a prime in a nothing-up-my-sleeve manner? Kyle --001a11403046035d1e054c4694df Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 12:30 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
On Mon, Apr 03, 2017 at 07:10:57PM +0200, Hubert Kario wrote:
> On Monday, 3 April 2017 16:26:22 CEST Ilari Liusvaara wrote:
> > On Mon, Apr 03, 2017 at 12:49:06PM +0200, Hubert Kario wrote:
> > > On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote:<= br> > > > > A =E2=80=98Backdoor=E2=80=99 in crypto is an attack whi= ch is hard to find.=C2=A0 It is
> > > > trivial to test that an element is in a prime order sub= group.=C2=A0 In
> > > > primes, backdoor=E2=80=99s generally refer to a prime v= ulnerable to the
> > > > SpecialNumberFieldSieve. Being =E2=80=98safe=E2=80=99 d= oes not mean that the prime is
> > > > not vulnerable to the SNFS, which is the back door of c= oncern.=C2=A0 For
> > > > example 2^{2048}-194228 is a safe prime, but is vulnera= ble to the SNFS
> > >
> > > but for a published parameter, it's trivial to say if it= is vulnerable to
> > > SNFS or not, isn't it?
> >
> > AFAIK, at least some "backdoored" DH primes were primes= that are
> > secretly vulernable to SNFS, in a way that is quite hard to disco= ver.
>
> Wikipedia[1] says that the algorithm is "very efficient" (I&= #39;m assuming it's
> the 25% reduction in effective key size) for numbers in form r^e +- s = ($ r^{e}
> \pm s $), only if r and s are "relatively small". What "= ;relatively small"
> means in this context? Relatively small in relation to general numbers= used in
> crypto, or in relation to number tested?

AFAIK, the problem is that those numbers (however "small" = is defined)
aren't the only ones SNFS is efficient for: There are random-looking numbers that turn out to be vulernable to SNFS, or worse, are vulernable to SNFS if one knows some hidden piece of information.
=C2=A0
How likely are you to end up with one of those numbers (t= he unintentionally-vulnerable to SNFS variety) if you choose a prime in a n= othing-up-my-sleeve manner?

Kyle
--001a11403046035d1e054c4694df-- From nobody Mon Apr 3 11:03: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 A452A1293DF for ; Mon, 3 Apr 2017 11:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p9Btyhr5JTs for ; Mon, 3 Apr 2017 11:03:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3221124281 for ; Mon, 3 Apr 2017 11:03:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 033153B74F; Mon, 3 Apr 2017 18:03:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 033153B74F Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 033153B74F Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9046B18500; Mon, 3 Apr 2017 18:03:05 +0000 (UTC) From: Hubert Kario To: Ilari Liusvaara Cc: curdle@ietf.org, Anna Johnston , Peter Gutmann , "Salz, Rich" , Tero Kivinen , Mark Baushke Date: Mon, 03 Apr 2017 20:03:03 +0200 Message-ID: <7105530.JWnP7qziXW@pintsize.usersys.redhat.com> In-Reply-To: <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> References: <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2312800.39SG4jeE6P"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Mon, 03 Apr 2017 18:03:06 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 18:03:08 -0000 --nextPart2312800.39SG4jeE6P Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 3 April 2017 19:30:02 CEST Ilari Liusvaara wrote: > On Mon, Apr 03, 2017 at 07:10:57PM +0200, Hubert Kario wrote: > > On Monday, 3 April 2017 16:26:22 CEST Ilari Liusvaara wrote: > > > On Mon, Apr 03, 2017 at 12:49:06PM +0200, Hubert Kario wrote: > > > > On Friday, 31 March 2017 20:27:00 CEST Anna Johnston wrote: > > > > > A =E2=80=98Backdoor=E2=80=99 in crypto is an attack which is hard= to find. It is > > > > > trivial to test that an element is in a prime order subgroup. In > > > > > primes, backdoor=E2=80=99s generally refer to a prime vulnerable = to the > > > > > SpecialNumberFieldSieve. Being =E2=80=98safe=E2=80=99 does not me= an that the prime > > > > > is > > > > > not vulnerable to the SNFS, which is the back door of concern. F= or > > > > > example 2^{2048}-194228 is a safe prime, but is vulnerable to the > > > > > SNFS > > > >=20 > > > > but for a published parameter, it's trivial to say if it is vulnera= ble > > > > to > > > > SNFS or not, isn't it? > > >=20 > > > AFAIK, at least some "backdoored" DH primes were primes that are > > > secretly vulernable to SNFS, in a way that is quite hard to discover. > >=20 > > Wikipedia[1] says that the algorithm is "very efficient" (I'm assuming > > it's > > the 25% reduction in effective key size) for numbers in form r^e +- s ($ > > r^{e} \pm s $), only if r and s are "relatively small". What "relatively > > small" means in this context? Relatively small in relation to general > > numbers used in crypto, or in relation to number tested? >=20 > AFAIK, the problem is that those numbers (however "small" is defined) > aren't the only ones SNFS is efficient for: There are random-looking > numbers that turn out to be vulernable to SNFS, or worse, are vulernable > to SNFS if one knows some hidden piece of information. But if I read the MathWorld correctly[1], the speedup for polynomials is=20 marginal (from crypto PoV) compared to numbers of no special form... Unless you mean something else by "hidden piece of information". I mean, 25% margin on keysize is quite reasonable, so there is use in=20 backdooring this way, but <5% margin on keysize is crazy small. So if we sh= ow=20 that the prime does not lie near a large power, we gain a lot of trust in i= t.=20 1 - http://mathworld.wolfram.com/NumberFieldSieve.html =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2312800.39SG4jeE6P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY4o5XAAoJEJKo0bgB0vX1gt4P/iW7HASFvNg3SQrqDNV6VSXU awoRcPK3sa6aZPgulTZR0JdV9h1sDGa5bCRRo7TXgQvIe27fU50YsPjGFzbDbSsI Z5Q7AlIRn2T4RuAiFRjwtIg4Q2GFNjEP2fu+iUnbq0gJTBqEe7VdIyUxrbQFrK07 jgIaLFYlYTLZp8bWIRz0zVCXKGW6sltSTfnkVFhb1/k45uxG/pWH80AI3bs69qqq z22H7qmzFj7pDqykFAMKZRCg8rmp07yK4El0LlWAE/yhWSK7RTJTDWUVVCc00546 qfYJfxBwaTKWtspbOp+f0XhwLIxjbyCE28SyEID1lQ0lKDDaadihN2WrInk5LKWL fPJeqGWzyScUBic7GZaPa7guVDmzAiJtZ+DpJ0V/eAQpJC/BfgXy1O0WQowekBpa 7mXmB27zmc/NzXTw/zN3byIUC1eATgeVy7sXiIiesNxtu8COVInWaWqYCv9idJSO dOseYgQ4r0BcG5GTEZVKDNOE6pzQXZE9KaobN2buJL+VErViiAGBhOFKTneDM62q 45WT9zKhzULs29/WPXaCFJtLqe25giUVPP7Mqqw0jDUp3QmF7/bC3AdY/lZvzfKt FT95nr4guYoheH4z5tKJ2DKrlUDaULrm94YLe1gzV5YTfMjfsTN5caOVobFOjOHW 39eB6Mo680i/wXMpO6Z6 =yGhy -----END PGP SIGNATURE----- --nextPart2312800.39SG4jeE6P-- From nobody Mon Apr 3 11:26:12 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 6DF5E1294E9 for ; Mon, 3 Apr 2017 11:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AoxNJ_UbHYH for ; Mon, 3 Apr 2017 11:25:50 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 C567D1294D3 for ; Mon, 3 Apr 2017 11:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491243946; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aqB1DCFhR3C3sucGwjg1EXvYbnwslYGpH6xuejQHf7Y=; b=yqDlcVWtLW8hOEVIvFOeT0IbI2aFSt6HOtlzoXUhrkyyoahUzfvPULdC6jYNB4as V4i9trYRgL0okUF2HZhMqF4fpSecnNPgUqyYy+CAu4/oP5yMLoJ7xeh72UoZutBS N/hjgPdRAfoJ7eJnAHRU7x8rPlCKX+2XfrSnw5PFCi3EG0Dk/20isrV/abUmIAWj jc7cMGMhXlRXCRdlaUBC/ArPGVlzsfZPuaqdurxMi1MRu5coA0SJmJAZxfIEOdD8 E0Iy5wL66CfX5qFe1excRCt9mJ9CaDUe30xroCVMeSUSGHbLD2ebte02WutOmp2D 2r3e8TNS+loaIV/z8BcDMg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 17.7E.23264.9A392E85; Mon, 3 Apr 2017 11:25:46 -0700 (PDT) X-AuditID: 11ab0216-e218d9a000005ae0-97-58e293a97095 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 87.77.31597.8A392E85; Mon, 3 Apr 2017 11:25:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.71.197] (unknown [17.153.71.197]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU004LLJ6WJI50@nwk-phonehomebzp-sz01.apple.com>; Mon, 03 Apr 2017 11:25:44 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> Date: Mon, 03 Apr 2017 11:25:44 -0700 Cc: Jim Schaad , Daniel Migault , "spasm@ietf.org" , IPsecME WG , "saag@ietf.org" , "tls@ietf.org" Message-id: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> To: "curdle@ietf.org" X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAYpbtq8qMIg6eLOS22LpzFbDFl+h42 i9XTv7NZ7N/ygs1iSn8nk8W8a8kWn853MTqwe2ycM53N49fXq2weS5b8ZApgjuKySUnNySxL LdK3S+DKWHdpGXPBNKmKA4s+MTcwzhDtYuTkkBAwkdg4ez4jiC0ksI9R4vD+EJj4ko+/2LoY uYDixxglXmzbzgyS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnvj1pZIOoXMklsPnKNFSQh LCAt0XXhLpQdIHHxyH1mkF42oIYDa4xAwpwCfhKPLr8GK2ERUJWYvOczE8gcZoHbjBLzpq1h hdhrI/F/2SxmiEOBDjp7rATEFhFQlzhxaAcrxNGyEp+e/2QHaZYQuM4m8Wj+TrYJjMKzkNw9 C+HuWUjuXsDIvIpRODcxM0c3M8/ISC+xoCAnVS85P3cTIygqVjOJ7WC899rwEKMAB6MSD69H 96MIIdbEsuLK3EOM0hwsSuK8InfvRQgJpCeWpGanphakFsUXleakFh9iZOLglGpgVI85Zvnm Qf3Fro21ufJsll3bDSWvSr3eePS/9b8FBTsPG7/uuukyfZbULd7p11Kf6VTPj524XUWf98zB UNHEF3xpC4KTmu5uyLxfcILvsWLLVodHBxiF/9wL6pO6F/h376ceJg8RLuZL2lXec/dddWOy tDrzU31C6bar8j92vHgwsauSv255oxJLcUaioRZzUXEiAHCmXpZrAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUiON3OQXfl5EcRBo/28lpsXTiL2WLK9D1s Fqunf2ez2L/lBZvFlP5OJot515ItPp3vYnRg99g4Zzqbx6+vV9k8liz5yRTAHMVlk5Kak1mW WqRvl8CVse7SMuaCaVIVBxZ9Ym5gnCHaxcjJISFgIrHk4y+2LkYuDiGBY4wSL7ZtZwZJ8AoI SvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPULmSQ2H7nGCpIQFpCW6LpwF8oOkLh45D4z SC8bUMOBNUYgYU4BP4lHl1+DlbAIqEpM3vOZCWQOs8BtRol509awQuy1kfi/bBbYDWAHnT1W AmKLCKhLnDi0gxXiaFmJT89/sk9gFJiF5NRZCKfOQnLqAkbmVYwCRak5iZVmeokFBTmpesn5 uZsYQUHcUBi1g7FhudUhRgEORiUe3gVOjyKEWBPLiitzDzFKcDArifBemQgU4k1JrKxKLcqP LyrNSS0+xFgF9MBEZinR5HxghOWVxBuamBiYGBubGRubm5hTRVhJnDen/F6EkEB6Yklqdmpq QWoRzHImDk6pBkbZIIlSxetqol5XrE8XeD/4xmT/LPTutbxJf5alF9/Ml/V4+0f2xt412/6l L+ZecLv6VjBb+M49uV1buaZLzo3fkrpj6cbuP5Pvzmlwl3AQ3d9hp6Mfc9p37UwLbim1iyXy pf2S3C7HjCeEMOgaqVxI8jmjw297as+hwvXvel/fCL1nGMpTJ6vEUpyRaKjFXFScCADgdmvP vQIAAA== Archived-At: Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.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, 03 Apr 2017 18:25:52 -0000 Thanks for the update! I've reviewed -04 and I think the draft is ready to move forward. Regards, David Schinazi > On Mar 28, 2017, at 15:43, Daniel Migault wrote: > > Hi, > > Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. > > Yours, > Daniel > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, March 28, 2017 4:40 PM > To: curdle@ietf.org > Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt > > Here is the promised updated draft. > > Changes: > 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. > 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. > > That should be the final issues in the draft > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, March 28, 2017 4:31 PM >> To: Jim Schaad ; Simon Josefsson >> >> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> >> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >> successfully submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-curdle-pkix >> Revision: 04 >> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >> use in the Internet X.509 Public Key Infrastructure >> Document date: 2017-03-28 >> Group: curdle >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >> >> Abstract: >> This document specifies algorithm identifiers and ASN.1 encoding >> formats for Elliptic Curve constructs using the Curve25519 and >> Curve448 curves. The signature algorithms covered are Ed25519 and >> Ed448. The key agreement algorithm covered are X25519 and X448. The >> encoding for Public Key, Private Key and EdDSA digital signature >> structures is provided. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > > > _______________________________________________ > 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 From nobody Mon Apr 3 11:39:57 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 37AC01294D4 for ; Mon, 3 Apr 2017 11:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ5JHDHXB2h5 for ; Mon, 3 Apr 2017 11:39:54 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0132.outbound.protection.outlook.com [104.47.33.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 136031294E7 for ; Mon, 3 Apr 2017 11:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FtOjpNMUbDBr+9A8ye0S8L4/dxPh1bPVeSvSUhEEQsI=; b=ZJXc4VbIJt0PU/Pp1HU67QCC3YB2zRCEpix4C+I5eyZwaL5nITEsp5GmgwzQKD3OcCqd8kvKvDmQUI1VlU1uclJ72Zoa0W7JPz8Dy87TKYCV5ec0mj9mJaXJFh/8jiAkJSFqqlB0VzIWAw8rqRYab5WTQZNW131oOZb/Cxcm4ts= Received: from SN1PR05CA0001.namprd05.prod.outlook.com (10.163.68.139) by SN1PR05MB1917.namprd05.prod.outlook.com (10.162.131.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Mon, 3 Apr 2017 18:39:52 +0000 Received: from CO1NAM05FT060.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::202) by SN1PR05CA0001.outlook.office365.com (2a01:111:e400:5197::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8 via Frontend Transport; Mon, 3 Apr 2017 18:39:52 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 CO1NAM05FT060.mail.protection.outlook.com (10.152.96.178) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1005.5 via Frontend Transport; Mon, 3 Apr 2017 18:39:51 +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, 3 Apr 2017 11:39:44 -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 v33IdfjP022218; Mon, 3 Apr 2017 11:39:41 -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 72BFC115E7; Mon, 3 Apr 2017 11:39:41 -0700 (PDT) To: Kyle Rose CC: Ilari Liusvaara , Hubert Kario , Anna Johnston , , Peter Gutmann , "Salz, Rich" , Tero Kivinen In-Reply-To: References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> Comments: In-reply-to: Kyle Rose message dated "Mon, 03 Apr 2017 12:34:57 -0500." From: "Mark D. Baushke" Date: Mon, 3 Apr 2017 11:39:41 -0700 Message-ID: <98403.1491244781@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)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(39410400002)(2980300002)(189002)(199003)(9170700003)(110136004)(38730400002)(53936002)(105596002)(6916009)(77096006)(6266002)(54906002)(53416004)(6246003)(55016002)(86362001)(117636001)(50466002)(4326008)(48376002)(76506005)(50986999)(5660300001)(54356999)(76176999)(305945005)(93886004)(7126002)(229853002)(230783001)(7696004)(8676002)(8936002)(7846003)(2906002)(81166006)(356003)(5003940100001)(106466001)(47776003)(2810700001)(189998001)(6392003)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB1917; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT060; 1:5HsgsbLoseUJIw2U+Q8Yk/Re9RFMtapTc38PDXzqRSqRk4l01UVsJfUEOmtFt7AbPfB6BMBxjvABsjUq1xvo17bqGfAp63Bn/i/1nrb+W1VbLpES3oPIMvpMBG8jviv3+/QYaF7kUrlxcJavaXfReooNzUDihBAKzpkKbKrY8BhCyGTMfQ09kqRXZWGOKQFABLLGy4LfuV1as6mkm8wD5Bj8gnb6j6As//JwWZ/zIamZ7GUSWFXTulAFhjXyk4AspD0qHbIJ/d5YM5KnqkoOmxxBbJ7z+/ykUpty7cA/nCUEj5kuq9IC8XCFzrO6a/7gq3Nl8+SCqOFx6Gq9vY0GUMot8NxaFUUwCMCNkvrapVqPOwM2Zi0heiJaSfJX9RKBqkctwU2mfgR356gHPMFteSaMY9cAatPDs1eeTciA9AiGJxAzUWhfhj0AayCziDPLGtDPD1HcByrYqBCBdHIbBG5qpbqWAloDZlZwWMeyTX09KUZtLtHOziT75V2IjnaXf5D3zfMsD0Zfo9AEQCwZuUP9CChbVML8tAi6KQ31aQNBNHhle2k/yA3NbZ62/yyWD3E8d03xUXN4lV6WODYzk+m1AqHwI0+Y8K4PKNgafn0= X-MS-Office365-Filtering-Correlation-Id: 08c7b3da-2abc-4dd5-5643-08d47ac0d0fc X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN1PR05MB1917; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1917; 3:ul363IOR1/VaNF26hiaocis822lNjazQa86kxpGw8mz7hd6gjILNlOgjqw3TIquqtQdfrd6JIGSSOut707o7ZZqtSUDqhM4LtdpXIocymTVtNAvv6gb356n8pF4Qp3kFv0EUBrJA9M1pAVBR/wIoIsa1SjU5DsfEkXqXcsYNUsKulDXg6io/dUAkilB8i2SdgI6yqLqNPbPINjiKntL97ja67HJXFX6ruZeagNZUszejPskgAs4Ja8Az4NZgi2onbkQosHcKaFQA0r5nC8r6mCj9k8dEpPalqgFL5a6u850JWeCDgeDVj9P9l2EKMDM8XtyEb5HTcQB0z77UeTKnb+M/HJ5AVD6VgRIM3HmrzkPp7JV5NxH5Fkv6yrTIkwL3DkzKt45B/O/Y0TBNCTvY1yJTtS2dxZlDk8ebApKBcIaWVdk1nie4bzz2Q9XTHLHxt9tpz4hX+JV9Kp9W4t5o6A==; 25:G0XxmwYeTSrfQU5o76GRVx0WExf1VSsUZ/US+AX6M5FYAFKZKAKV7p0c7XwSXcWRwIDe6MDgwdzBk1uttwJONvw2AKJBJJqTq5qPAqFOQh+ciO6OEX23pXGLvDSyz8q3GPvO09Bo57M4DJyYuZTijLuUsQigp9CJD01dxkStd2AEGUMZ3q3rRcWPlNYdvFRSeRy2oMTtQTqX511mXcAh6KJIqjy/0DfyZLoZD5yLloCBncAP7Mg3ivRpD+x5QLbD932rgANPlFQKoZwPS5EgMvlT1T2gpgKpPQw0k6dPJ20o9HctQSN/7AbPF+agyUu56EBySLpEYQDOwlEPs5+FcdTt8HVoLtNno4Iqdn0HEFV5BLWVJ6fbzCOrGvlDdcg3dia3OavvS1ZBnU8tipfGM5gUjcRYw8PVGq1rXqXfI50XLtZGkTUUzCB3wnSFAzZMJKpptcwUapRghMuRHdxZVQ== X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1917; 31:5tY9p2mja9YWtyBfz7fufhv6iCSSvExJX86weJMag90RtP9Sk6enTRzbTgiIxCor2SVgyoCKJ3Ik+KEE8mzrBmVoklvrxmgtaBvLS6Mjx/qCmw4bO3RBma4UNiM1wWVsBLYrwCZCmR4azG8ixmk57TLk2AexhlIu1PxL9bjEAM30k8s9z/gJSlDg+OEEVa+RsUmyaOw5D0dmmogsfWpNQc/pgiH+WJdlziQBw4EFfHBkyLS26PZP5t3CR0I6zh1iqUdByKPN0vh+ZC7QVG0ZCQ==; 20:4HV19ubWzLv3+zoot+r+yGPKgg1qbelTRuc/IwAXB+a0EhK3pqtFqm21LFUmuwjrMf0pBhsDuYp6qjFv7riwOKWmVLbrP6cXdS5UWEyJ4FVpyWH5hbOTVPq+9/IfFRMW/Di2z7WTE2jOvXnZeGdnCvphSzbL33V/un8uKIQeUdI5YsISQHE3XTfTuV5xOhexjVoy9VzRvPobodoqgiuwCaycCyxrjk8cmh3JpkIthI4lCfVXN9xW2J9tFhQYUvOGy4DP62jgtnijQZq1SaE1dhTv1WUHBtd6olXVtoeAMY/BU6qh5XW77stuVPz9SXRw0YQjepUkEpNkMmlSGuM7YrhObzGtJSmvFjtJ4J1TjVyA9qP6YF2ziM4guGtrrOWSSyx7ZbplitsK/CRCcbQYQoMRJqbW30m6uj6+yVphIo2ASBshyug+H8w6MHjSErzYdqIbtpzT4cNsZaF3p4dRVnFLzCcurYAdIQCE3J1hjo0zE08q6EqShEkpo/i0yCVd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13024025)(13018025)(13023025)(8121501046)(13015025)(13017025)(5005006)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:SN1PR05MB1917; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB1917; X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1917; 4:1Qb/sgOoOAVf6A9xcP9BIeFFhw++MWkSMSUyKLQ9jcUuGAr/btY2JpeFHKZ/DEkx8F8Mf2Res0lzcwGPTO4lcBSpAO9UNJBj55HNdY4xl0wjd0c89yEAFfQiq9ieXdEdT6GTQWBUEB0IKcOGhEQCOoZVH4tXJHwbKbGh8UeIhXWBeV57lH0IjuK6oHXUNJtarI2O3ARjLMi0Xe/v31Z84BCJZFdP8FhNuMTcUgDaBCJ2nDSemM1MDFKkCHjo1lghlKKFuMKqyjHO/f/1Vf3NJbHN4/gw8R/FA9zFboZvDNynlC49Vbz0PFDIPIr+AUlnxpQ1RfblvvLZum5hi5dpaRocmaUf6crUyP+4u9PvbWJFj8ejhEcaEdj3lzTbTxASww0WBAjBb4JSO2jr12LvEZeDYe9ZYe0ZKKCxBnJgnahqLPqn+3gsH3Q1Y3PmjU2IjnGkv5h+WFUcv1ik+7mW0ItbypgCP2ynsT1/xzJWbqUNgHuwOA0QIw5hNl0WXZpYc0jGJUnAWoIcU3vELvV6FrRt7kVvsV9qwtQ6OUq8BuBgZ4fBMZLD6XG/zJFlalarKJd3qqR0TtnOgNF/LB4nBRC4UNe17blCQhTh5azXpoBd3kVFT9312/PdFpSAqsOeE3i7Lqdukpdgh0G1VN5VGiOXi732ArgJ9byhLFVF4OmX7HA5BcDuoFC4oPBFpV1X32E5C4g0Vws3FsW2fcMLcgkuvvm7vp3RflrfrtOQnGqajTUO9pR7W2kABZSBCAjnYsQpEv/CB2nQEE9GNEYd9Rh0qRiqMD+c9/i8ec9JEsChXzIacAvwMhxw7qgvHCDyvDIIyxFeDvK2yY1NCQUr6jkmy6qbjBktpCY5lNR561U= X-Forefront-PRVS: 0266491E90 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR05MB1917; 23:X6x7FPYdBpQdzHuvIbocb96Z96UbMoKAHdsGphdul?= =?us-ascii?Q?45q5WEwR7Jg4ptiva5ja1fAnpTDdMjz2D6qOis/rzZVzyK29d6FzEp/O/8D+?= =?us-ascii?Q?f0k/pwC0yUBdojQc5syO0ZXpNmOo2FZcXkLpN0Elu5bbwDEro+TW4XzbaH8T?= =?us-ascii?Q?Kav7dGkVtNn+rCvaEoMilY5SFsk0R6HUSRq1OzmV58O9OLZlorr1dGamcftK?= =?us-ascii?Q?Wk5AvJ8j3/Kvoh1z8oZYanxwdfBpi2ZX6gBcmiUQFds4mHPRr0mdX5OpiWsy?= =?us-ascii?Q?/83t5oYkVuQBT1d/bNA/itT+D1w58Of4ySlchbibGfpuYXcvO7+W/8ndiMcm?= =?us-ascii?Q?GwqznaV+OQo/REWF9+VfkI8lOWFPb9kSHwza0VJhWOxjEnr1Xa9fgwS+qRLB?= =?us-ascii?Q?+RprOjfhin3YA0Izi+Eo0N5TbEUpg4Q/ZXW/hQAeTXAqUXVucaupUq77F9X0?= =?us-ascii?Q?1hvimFX02oEgEanGGuZyhVHNoC4UXyaCBbzyMDqct3HrUkX8RCRwa97NZ0MH?= =?us-ascii?Q?XjhipXMgxYV9aeWNelQKZE/2PBTtbVQd8mIYQ5lTjK68eojqfr6ZApRu1+WI?= =?us-ascii?Q?zsUg/y2slg2iqMs7SekoOUrYc3Gkd2GplMoUseZudXtPkzN7hw7Iswrk0bRy?= =?us-ascii?Q?O2AP8YNZs32q+CGnibXfFXI2gxQCnntxHQtHkoLn2adqRCZZrDl1aJNpEsKR?= =?us-ascii?Q?vi7HXssoyECSWAuTpZIzkX9Iz4QK5boAA1hafZ2fEFUGQai4jVZN84wW7NNz?= =?us-ascii?Q?GMJliHLP5j5MqH3lXWfA56HApMSh+NWUX2Qz7tMdQ5hJJewWOcMoGKT4iqtC?= =?us-ascii?Q?3zMqxWTA90nl4cBlaPuu1kA+fR9uNeORqbxPE4ci80VFaAbHZZIiQu8saM6B?= =?us-ascii?Q?WzOfTbUHD2c/dlhjOSjlf76lcibu9McVyRuiXCyBvgosowMxCb9hH7hta4lx?= =?us-ascii?Q?yOyI8EL7e3nZP7spWQ+DDhVjdKEJZ2Ay3USqrMp6/nqreGwS47PajOdQprQE?= =?us-ascii?Q?S9ekEbDWoY2Fxyb8BTMe7L8SS4wDdp+Rfr7yFVslr1IKXfGrVO36A9zfemqb?= =?us-ascii?Q?1ymP5BC9LHK/jz709vYJKGGcGglJ2MbunAGs8uMRgruhInO4Ib84X3v6Xl8E?= =?us-ascii?Q?KDZugYYuoR0Ph3J6KW+adW3+MDtQQuYt5R94xQWJ4yi4qCxiICTs6sRXMlBf?= =?us-ascii?Q?ZOW8ncRX9u8O5W/ivc7ItIg2ziBBeTQk2IrRQ1hooapj9Noi/8TlDiOhrJI3?= =?us-ascii?Q?e6ebBoDCDSPb2C0tzI/HlIw+pFKwvbVdycEarSv?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1917; 6:NaEz6TCVJ6eNcdsV+QisMewalNCwWX1ZNVqmKspqIdxpDfdyW9TUsdKVecmhaH8TFMbxBeTe7rW0N9704L3JH5ZIRSYXx3mg3sszZSXZFzJLx+8xUh+s8UAxFwNAJA7JJvNFpWKtwQ0EMUOdx8n0vQsfxWzLhtdMSxGrPk7AvUBXl3OtYdDAkalGWhwHNSrhk/h/CeUQwNPXR1gQgODc/ilbGVBPNumFr+QfN89sO0uXXX8+cR0ahTK/AaBhyZwVVmTZBggn16ey4H0fNH0HCXvc/LJcC6zLcUvwQtYqfVu0va/giDrO0KjUR0zeaiKSEL3COs5I4Tb5cAUA5gA7SO/EAopov7p3pC2exaC1tDQkQtX6+rl+442KricJ7texBH5yTavj/iB+OVe5I2ip21ECoAAWy0KhfQLhixlf6jw=; 5:60p4LDHNluNOpatsRMYXDO8pNrDLlNjuzsO+eLKZb980l3ITTtrt4BTJIyRckMrUTXQiD4jSuykUGssFQPcLkUbrK3yelHTcKGXltlEUrmTPbjA4vnhHJhSVRcFPvETqiWhI4laG+Z/y1bkuYpy5Lg==; 24:D2ufZnI8ablKs+r42AyYSkL0nUdbayr66u1KS5qtEItodoPMbYd1FffCi9/KjAaY4iKH+vEyl8yuX1PDscVDjWF28marRRE+guzwjto5KG8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR05MB1917; 7:dwpNF7rCwJsQH/0/rvZNZkaWoSLmYAQcQV7hRZNb5uKR0/5neILe5oZALUhUDUcOZihnSB0zKXiu1TKX+1Gj+JieEUxlEzC0Ek84UWM5iI9ZXri10eY6wT2/IOKqJRc6w6KJc4TsxvsC8eUcbhQfKDEMVWq11NQcKgTO4DaaTJkLT0DKV5fSo0z8KjWW5bnLOfu3J3Fcox7P9lj9coCjmLiGdgpO47R57UFouQ50IgFYE704h0/FecREMe61mRDJtfzoyD6LCXfehhxlCIbHY8bgmLcGt7hvb+6g7mX6aoLsrP3XAr/nwArooC/yoYaYplZMvJU7j1ldegc4JTxg0w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2017 18:39:51.1320 (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: SN1PR05MB1917 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 18:39:56 -0000 Kyle Rose writes: > How likely are you to end up with one of those numbers (the > unintentionally-vulnerable to SNFS variety) if you choose a prime in a > nothing-up-my-sleeve manner? I don't think we know how effective Nothing Up My Sleeve (NUMS) techniques will be in the long run. I do not know if transcendental numbers are more or less vulnerable than plain irrational numbers as the basis for NUMS. Now that we have selected pi (RFC 3526) which is shared by IKE and SSH, or e (RFC 7919) for TLS, we can expect they will be the focus of extensive precoputation efforts. I guess I will hope that transcendental numbers are safe for NUMS. For now, does everyone believe that adding diffie-hellman-group14-sha256 diffie-hellman-group15-sha512 diffie-hellman-group16-sha512 diffie-hellman-group17-sha512 diffie-hellman-group18-sha512 is a good next step? Or, are folks sufficiently concerned that should we generate another set of NUMS MODP safe primes with 2048, 3072, 4096, 6144, 8192-bit modulus values primarily for use with SSH? I suppose we could select digits from some other irrational or transcendental number... Thanks, -- Mark From nobody Mon Apr 3 12:06: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 E5AF6127449 for ; Mon, 3 Apr 2017 12:06:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwMXxSF-H-Yg for ; Mon, 3 Apr 2017 12:06:05 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 609F0129468 for ; Mon, 3 Apr 2017 12:06:05 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id x35so120650920qtc.2 for ; Mon, 03 Apr 2017 12:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4oV1LAZMVixjodyFLgeEpFdeRw1QnI9f8A6AGvPu72A=; b=Ttn1OwXfObbW4FOZEoFBQi/Lgg3pYHN+nfUE4+rbsD50iY4ps9pkDN8FwfpavS/ipJ aHMLu9kshJ8Jc0ejzgmGPie3JP/1/NMXh6jcyuVGrhMDtYQiIEhzWsRtTtavysxDdg4c IOe0XhNN7D9SAt/Y7UkcrJMqTtaayF6NAHKoI= 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=4oV1LAZMVixjodyFLgeEpFdeRw1QnI9f8A6AGvPu72A=; b=YnUKlSBnL16Vq0MA/0AXo4wIPHyrWwAZ6tgbcitNfhZF5TFz6wdRrX2pDAhMjf58JS AIWrJKj/IUifBElI0uZf2sH7OVpRVqppp/8iN+vw/opcIk+PPoCEkp04viUmxHfPRur4 0q/oE0GIMyDmY5CDvX5sSgELTTEI/5fO/E+JVZefzFdKs9UizIrfKTVrnqmXVZQOVFg6 Pm35HE2ybCo5QpU0FxKNNws4ImbNOK4cI19n+2Bs5/q5TdOQun8kR17Tz/FOWyr8BvrM nArudcjJHMEVug3bZDodKXyih1+Oq204yBizcusrjSGY9gY3UtkmWgEsR9T5YBAOdNem M/ZQ== X-Gm-Message-State: AFeK/H1N4xTXtfb3I0mDr8dUGy9lSYes8oLf/5+d6Piwi/xTGQt0N8YtmuHRxu8X/jupzxG1Nj2e/vqrE4Cgsg== X-Received: by 10.200.37.81 with SMTP id 17mr17909788qtn.165.1491246364162; Mon, 03 Apr 2017 12:06:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Mon, 3 Apr 2017 12:06:03 -0700 (PDT) X-Originating-IP: [72.246.0.14] In-Reply-To: <98403.1491244781@eng-mail01.juniper.net> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> <98403.1491244781@eng-mail01.juniper.net> From: Kyle Rose Date: Mon, 3 Apr 2017 14:06:03 -0500 Message-ID: To: "Mark D. Baushke" Cc: Ilari Liusvaara , Hubert Kario , Anna Johnston , curdle@ietf.org, Peter Gutmann , "Salz, Rich" , Tero Kivinen Content-Type: multipart/alternative; boundary=001a113ffca6cf365b054c47d9f2 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 19:06:09 -0000 --001a113ffca6cf365b054c47d9f2 Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 1:39 PM, Mark D. Baushke wrote: > Kyle Rose writes: > > > How likely are you to end up with one of those numbers (the > > unintentionally-vulnerable to SNFS variety) if you choose a prime in a > > nothing-up-my-sleeve manner? > > I don't think we know how effective Nothing Up My Sleeve (NUMS) > techniques will be in the long run. > I guess what I'm asking is: do we have a sense for how common these numbers are? As the point of NUMS is presumably to choose something short and natural (i.e., without magic numbers) as a seed for a well-known random prime number generation algorithm such that it's easy to convince the world that the resulting prime doesn't have secret properties relative to the target cryptosystem, it makes a difference to our confidence level whether SNFS-susceptible 2048-bit primes are 1 in a thousand, 1 in ten billion, or 1 in 10^100 if we can't tell but others (e.g., state-level actors) can. If they're 1 in 1000, then FFDH should probably just be considered broken until we can definitely test for and rule out those primes, or rule out the ability to find the unintentional weakness without first generating the prime that way. In the other cases, having multiple groups chosen in a NUMS manner in which all but the first are held in reserve in case we got unlucky on the first try (or in case other attacks appear for different subsets of primes) is probably a prudent approach. But getting back to this specific case: what is the provenance of the IKE groups? Kyle --001a113ffca6cf365b054c47d9f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 1:39 PM, Mark D. Baushke <mdb@juniper.net> wrote:
Kyle Rose <krose@krose.or= g> writes:

> How likely are you to end up with one of those numbers (the
> unintentionally-vulnerable to SNFS variety) if you choose a prime in a=
> nothing-up-my-sleeve manner?

I don't think we know how effective Nothing Up My Sleeve (NUMS)<= br> techniques will be in the long run.

I g= uess what I'm asking is: do we have a sense for how common these number= s are? As the point of NUMS is presumably to choose something short and nat= ural (i.e., without magic numbers) as a seed for a well-known random prime = number generation algorithm such that it's easy to convince the world t= hat the resulting prime doesn't have secret properties relative to the = target cryptosystem, it makes a difference to our confidence level whether = SNFS-susceptible 2048-bit primes are 1 in a thousand, 1 in ten billion, or = 1 in 10^100 if we can't tell but others (e.g., state-level actors) can.=

If they're 1 in 1000, then FFDH should probably just be conside= red broken until we can definitely test for and rule out those primes, or r= ule out the ability to find the unintentional weakness without first genera= ting the prime that way.

In the other cases, having multi= ple groups chosen in a NUMS manner in which all but the first are held in r= eserve in case we got unlucky on the first try (or in case other attacks ap= pear for different subsets of primes) is probably a prudent approach.
But getting back to this specific case: what is the provenance= of the IKE groups?

Kyle

--001a113ffca6cf365b054c47d9f2-- From nobody Mon Apr 3 12:55: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 320D2129501 for ; Mon, 3 Apr 2017 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 8Hw3dnQzOXd7 for ; Mon, 3 Apr 2017 12:55:06 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id C031D1294F5 for ; Mon, 3 Apr 2017 12:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id BD2F9215FA; Mon, 3 Apr 2017 22:55:05 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 5itjl_pj6WhA; Mon, 3 Apr 2017 22:55:05 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 6DF11C4; Mon, 3 Apr 2017 22:55:05 +0300 (EEST) Date: Mon, 3 Apr 2017 22:55:05 +0300 From: Ilari Liusvaara To: Hubert Kario Cc: curdle@ietf.org, Anna Johnston , Peter Gutmann , "Salz, Rich" , Tero Kivinen , Mark Baushke Message-ID: <20170403195504.GA5603@LK-Perkele-V2.elisa-laajakaista.fi> References: <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> <7105530.JWnP7qziXW@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7105530.JWnP7qziXW@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 19:55:09 -0000 On Mon, Apr 03, 2017 at 08:03:03PM +0200, Hubert Kario wrote: > On Monday, 3 April 2017 19:30:02 CEST Ilari Liusvaara wrote: > > > > AFAIK, the problem is that those numbers (however "small" is defined) > > aren't the only ones SNFS is efficient for: There are random-looking > > numbers that turn out to be vulernable to SNFS, or worse, are vulernable > > to SNFS if one knows some hidden piece of information. > > But if I read the MathWorld correctly[1], the speedup for polynomials is > marginal (from crypto PoV) compared to numbers of no special form... > > Unless you mean something else by "hidden piece of information". Might have been misremembering that it had something to do with polynomials. What I mean: Numbers that look random and one can't apply SNFS in any obvious way, but knowing some hidden piece of information enables one to get decent speedup from SNFS. That was at least my understanding of some "backdoored DH primes" stuff. Obviously, generating numbers in NUMS fashion eliminates that problem: The probability that anyone knows how to apply SNFS to arbitrary number is vanishingly small. -Ilari From nobody Mon Apr 3 16:23: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 BC9F7126B7F for ; Mon, 3 Apr 2017 16:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxqLX77eKgay for ; Mon, 3 Apr 2017 16:23:18 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0124.outbound.protection.outlook.com [104.47.32.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25846124BE8 for ; Mon, 3 Apr 2017 16:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ksbY4rMG8DBVDEtKo5NPGuFi0PKr7v7TgoY+HHYjPKI=; b=UDsFtlKOTofqX1q1ZLtKICaG5sgCry5EfpZGmVYnkUgrWYnDCsg8YTaRjWqYxvYsSm7vQUE/3QSnHD1iwzE3wcKt6sW21eojJy3EJzyHTy1IJ6qlzs5DQssa1tTGAJRRrbwysf6ey2K8JBDjIMih2mG5Mdd/0qHYIQCRbHCWc/Q= Received: from SN1PR0501CA0012.namprd05.prod.outlook.com (10.163.126.150) by BN1PR05MB534.namprd05.prod.outlook.com (10.141.65.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Mon, 3 Apr 2017 23:23:15 +0000 Received: from BY2NAM05FT023.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::209) by SN1PR0501CA0012.outlook.office365.com (2a01:111:e400:52fe::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8 via Frontend Transport; Mon, 3 Apr 2017 23:23:15 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 BY2NAM05FT023.mail.protection.outlook.com (10.152.100.160) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1005.5 via Frontend Transport; Mon, 3 Apr 2017 23:23:14 +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, 3 Apr 2017 16:23:13 -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 v33NNCk9024601; Mon, 3 Apr 2017 16:23:12 -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 B88CF11516; Mon, 3 Apr 2017 16:23:11 -0700 (PDT) To: Kyle Rose CC: Ilari Liusvaara , Hubert Kario , Anna Johnston , , Peter Gutmann , Rich Salz , Tero Kivinen In-Reply-To: References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> <98403.1491244781@eng-mail01.juniper.net> Comments: In-reply-to: Kyle Rose message dated "Mon, 03 Apr 2017 14:06:03 -0500." From: "Mark D. Baushke" Date: Mon, 3 Apr 2017 16:23:11 -0700 Message-ID: <57491.1491261791@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)(39450400003)(39860400002)(39840400002)(39400400002)(39410400002)(39850400002)(2980300002)(189002)(377454003)(24454002)(199003)(9170700003)(189998001)(81166006)(305945005)(8936002)(356003)(5660300001)(48376002)(54356999)(50466002)(6306002)(53936002)(966004)(106466001)(54906002)(55016002)(5003940100001)(8676002)(50986999)(76176999)(7846003)(77096006)(53546009)(6392003)(2906002)(2810700001)(86362001)(7696004)(53416004)(105596002)(76506005)(7126002)(2950100002)(110136004)(6916009)(6246003)(38730400002)(6266002)(229853002)(4326008)(230783001)(117636001)(93886004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB534; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT023; 1:/T5tLdBV498xHtmm76CYd71zjGsNBzBTPn/aOTBT7LMicyE11/h5A1PX8ZHh+f11cmuPKBoBNFFba4r7Ci5LO6jIvIKuks98Z2iAZ35Shp8MuaVpibqadzYFD195rCTe0yCQWA17EHn/00L+KyN8rAH3tmKzP7COUQhWUyaBN6ljuYpapgSN2iN8PWOSHj6BViw8AtD/j66YlKnyytgziKchuEgKum8TA39vpCFu0tUSwcy9lLTUnwr3XoaGSZY/5qn3jjpgau9/R8jy7zRkKg+6EKbXCAlaeefVMj6TgKpuMb520EnytWzyKAXfxJU4Q20/RulNKoPVlQvdUB0fWZxQX+bwrQZtkAmeEFeix2//o5TqKKv+5uNBzx3DIorI9PicOfsskXNgQ9qolxWG8JDZ+Sv5tFGUg4Sa+ZLiLUC/qDlNK+XdBVDOfHsPzlcWbEyWFh3kVI+EASf8JoRuV/c8LaoVlmSpCXFeidFMeOHjfmbDijkhTdaZMZud5gJnZgMyCofZR+ApvpHUUtL3MCeaqQxaI/55P708taQYD3zskzsvL/13Xy331QrMfy6YjM5Y+8sy+pgQpaE7Syrq5Ia9L+DFnXuFVVnUjEQEsuQ= X-MS-Office365-Filtering-Correlation-Id: a680e027-7168-439f-fb67-08d47ae867d4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN1PR05MB534; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB534; 3:dYSzzoIr3am1qNiG8kyocD6boYMMZwCT45JqWa3hfepNVa1/pu+RHILT7fwEEqIhstOHIL+7ljAOal/KLmQgjaVJbjnD0JwELYoy07ySk4RUbBRYiGwdAqiHqwH+ZNvA+HJjybAY5coanKu2mU1yrFSNgmMdCby9fn4WZGeesGEvK6aEAIeaDR9cYUL2P15+e6e5kfvZAinr7OXJJwbxCMrhnq2u0U1ZdmwyWskDrMgFDy9cVRJm5CdybRMuh+CGfjDc7rLbZCm85pFMMAO1+cMV6/90W4YcYDOhkQmKfzdeFdsBxDYPNG76uvQgJNaJyZJNrLIFoZAJisvffQUCLdeiN3tX2hs1rT1mTLpGgwcvlr5Ww5R9tmHT1X4jOp+yqBsBXvgDmYzGeJrHWA9W5LZTK5L1axWijWur70UPcgQ3mui5Rqphb9FwSBoz5VgvtzcyVd7Xl9dyYdQtPaWz9g3QYQpOixBbb5uLdR+FWaX5CaDzndI8ce0R7pUG/m9k X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB534; 25:8h0lP+pXygIKifTkJ23aGpbxEKyFM5j+eB0zP7R3FunDOGZVoSF0WEbFE56US2f+l7nnblsbDG+WEcMcMitnN0Z4vShnxmpmYmPJmYiEJ/Blw7P8yyLEVB7/B5dS1kJXMeGtJh4rMrxXU49UI9+mWQ8FjGcgWPFqTz4vB3AsaRcBwoIS4DV6PQ67p2FNrYXOjDG5oqFiC81/P7YT06KuwP0Db95XIlvXEjLl2o/hEBWNSq6hh0w9oeHrgr1pduo+ErHclbRQ3TZgrSgG2joCNeaCEuU0lBn8E4yq5oDU8NrW+25yy1PIa6fF3vLCfZ+QI7K5QmqI71yqM/jGY31H5sJYmkUKsto9Z1DgxJhItepwexU2OAVZ2tAgvayqlkysZhwrqAh2YUTzpsqERQvmtlq5E02DqL+A6ZSWwvoHjrF+OzKXsCWgzpORBjMJCzYf/V5+nHeNtCtNAIA9smk5Zw==; 31:ISjrgvduE8en8so4W4C7TGiShkkSu8dviOg8SqsbrHZvjfo+CRJ9w4pdOALlOpdXLCIDfhqO0WamFLm8kduFKezhngbV3dixtS9uDUjziA7B22d2SJ54v0uHtrgi5K4Q8lrVyF44EmHLx+3HLzT/RlGy9sWr5f8u290nUJ05gzw1/xYl8CAaoXNsb4ln32EH7bJwew36EorsQT36zIvLXCHMV9+21Kcn7NQQLb7Oj2mzBbIlaDCInmJci5N3vqTa4rUcOzerm8IvIGM6waeci9c1ycglKYLL5k269TQ6EHI= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB534; 20:jzPyVtSFGdL040OZaMVDHqWj2eqx6l8hGkB0HKWkxZrAvTIJ6uzCdAw7+LgmT3qaCHH8aLJVw31q7oaOqkpbb1kWh0J34TySFGN6QAQutB3gPnaYdMrm6iFscCpelQyn/5XcNlt+00IuuvyDYyTG7vVImwwdap5Ljj87Q/nG5fzA3Fu+v/FxZYwsmd7veNxIlBFFdQWezHnN4WwLxzU6i+ehD7Fo/WHGdZF7tKRq33ijvZyuacjpXT/1Yozy2W2lB6HsMILfvY6Q01HP9cW+qpsJizqcCqleHJTD3KN2KHSv6fkTZA5LtW6R+aKq/j6ydbET4+2/7IjanS0cLB+Qej51YDSK1mGuaXdNSwbBaZxcuUdJFS2CnpI/l/UxM5qWgjHEnaIH0ALKzjQ7jY4T7Yb4NAwMF3OiI30yZAbfiZnpMtGOMssnsDPcWcm9dkVnHVC5nrdBZXtBQM/WWo8n7+dZ51CeY2vfl68bxlR48yKUsvnWiVp+6wfuA96D70tM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13024025)(13018025)(13023025)(8121501046)(13015025)(13017025)(5005006)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:BN1PR05MB534; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB534; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB534; 4:rEL7ntD8hc86XAdYsg+futCFqexsRxEvv11OeTkrhMfTJycUP5BpMrCe5RbF1P3J0QQFaRaHzsL9jlsaTZNNuNNNlGBMAzhlGr3AjJDiBWbhvyRh5IgzK4T8RtDBM2bTct1WN9TY6DoozPZMzYxA0rbQwIdLL8crSMoa1yhVsrheCzoACNASjnIcKjYKRoUI0q4AKMC4HaJaGxOTv1iCg46L45s8NuwCn6mpbgJpuyXrbly+cm2726LvRAHIgauhpfrxr2byXmNOVvLuEbqyjREJmS8l3nPcNAEZv4Bjmsj0rsNMmqjqP1nC7XnKuRspduXuz7j0XWMdrT7jmp5dpKGbc8vD8EsykcahxSzQVceweNTweiOGLIreh4QPjs+ICE0oeGY15+xmThlkjYxXWZKX/rkL+GDjVtI/vSFa9yp9jOsfK61deQUiUA9xSnTeGv+sIvTEjFnQbVorNJ8tkZz9bqjkPj4BiQv3e60YPN8HxvqTw5tM7ao/hMaI/OBvO70z5ixsTUXkDv+C1eyBuCu+i71oxiK6OKhb9KpMZ2ejgQwFm6EThkD4S4O3Yd9t2wkB91S8OX9SSbJk+MoXjLpXRSsQ3ugqhsZOhaXjcUSIWDTzm+PdOt/0sh7cvGgDoUu7D2LXYu+Jr5A1blVSlTXYbp49v+3iKAOly8grWF933rf0werYXbmTBb5s82pNLMub7gtsoKF1uJRiHJqMO641fISyKfulIgOx9TlYj/hx35W5xSimlVrJBzQTpz21ZvawOMotWW4HiWie4X0GTFDOQuU5rqB+KBeXumsiMiibMbEQIfOjo77BwGUJ/BKzFXY6VNhYok+JyhJPeOj4gnjRkiYhzjxdqta/eoQH23RhToh4YEPb+RbpTCkCY6+IMdklAvvnp6IotnHWmXtDog== X-Forefront-PRVS: 0266491E90 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB534; 23:QFvuzyM4RSADjtPn1Q4FnOFREsRbzoRr8YSWTBK+sH?= =?us-ascii?Q?Pj+zfdpLMBZXsL+Vs0RH4GQN9zo4jsX09NpCMFuTfCCfmhaoBrqSzAjSwyAt?= =?us-ascii?Q?+W710bTeoY5nfr7HL36kZ50BWoPkJ7SD9onyO0kVmhObnh5jbOfiG0KY9FEc?= =?us-ascii?Q?q1ORFA3smxn4j1C7M+2FDRP8KH5UCJ2Wi1gfG5+KzLDTj7XWgqUyST7a/YzV?= =?us-ascii?Q?R4xHWmP/gMkCJw6S5Rrjxo+KKsmiDPAMzA8f+9xr21ZiSojIksA1LjL0eiAg?= =?us-ascii?Q?oDxo2BRXo4LdcyR7mGn6vmFoU3f78Jb5+WY3ROfRyrj64RzRuC0oOSKcDFjF?= =?us-ascii?Q?uC3jzr001o1b/i/jGr6JGdhSPtYZEPxPpjBkmrR34QFiBScdIcbwRJwscEka?= =?us-ascii?Q?NKI/Ffp0wjPcCNMLRM79ohdg14cY+Z3GxQrJzQUo3/MEpU9U0EXsT3Phfp+1?= =?us-ascii?Q?y2AMu/kS1N8HLIab+UKdM6+qz/nFimdxPAdR7YE7oudv8sqwJpVAOVTRZ//H?= =?us-ascii?Q?SeMSuXWNsN8+gro7JK7kfOtLqZLv7e17joVGKPh35ScNgpQ7FcIdtDkYWV/g?= =?us-ascii?Q?elGILFyedYuwIv9XXsV5kRJbfry+bCHaGtosIoY/CNPRwVpO4T7/jmq986+W?= =?us-ascii?Q?Szbk1rdCA5qcOpBxo4kVYozyC/iGp5orhiyYQXt1kq43FRMBs2Ii1lnppViF?= =?us-ascii?Q?sW9lNh3zmBZ1N0rwCH8wmvI+iHMZw277U3tFQqPamJBMywRPD5KmQvkY9viF?= =?us-ascii?Q?ngtWsxalJC1HU4DFkgh3+2mtmnOU8oasOJjUkrtMahx8/JUg4dkcNlCeQvCP?= =?us-ascii?Q?dNpxK7nLT539IWtusYfkGfUaeBs7wsZNECgyGOZIoLARcV2dA8UnX6Y+CxGv?= =?us-ascii?Q?TqHFhZayigMoWe9jBSQ8ITr2pdZZIYH9G7xGRf9hYXkc6ukxBcvs9MCJFoay?= =?us-ascii?Q?3Z9eyuz/3Zk7qpNuJikODevTAtYM39cHIXPob2kdUjbFcbB9tInZn5SWQk6W?= =?us-ascii?Q?qoF/VavJuxMahYJvhDKzBv4MDDgeuPqGouYcqQ+gYe5/I4tfV2+zO8zEimMB?= =?us-ascii?Q?T8isWRZN+Nnx4G8XrYlvoDclMeW8LXc703ACk7iRYRbgEUh0pGTQZ4jBVLdl?= =?us-ascii?Q?7EOs+acNHmo36aMGkI5RerkwRsGFLgvSD/xhHjMKKzw60Z3du5UjyB3kNjzN?= =?us-ascii?Q?gebs3EgbauBWcs7h/tw/KoXgzC7ZNtFRcH2O+5HWw55tmTS4EJQFrBz54NwJ?= =?us-ascii?Q?/08aPIYRRuZVQNm2IdFYbIuOM2Q7HApZH23Ur9a4vBePVyrO8w7bzak2xW5d?= =?us-ascii?Q?tNGne9LyfvmpS5iZizUmBzeCQdzFlzfLdR+WNHpdyLS8B9sMoD9RmnQil2KS?= =?us-ascii?Q?iv0w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB534; 6:LMFguQhyEr2VJUHztvDXP70uJQy1DiYXgNAVvc3BP2oay+Nt14d/VbGtyXqru7KyN6EHsQ0oKTRtDdaeHAa228t5Oz5wLA1XlpLoVqIZGrIcD72tmxDz/Wh0SjjOIm4n0BJWLzuzObNhYQOOB+qQMxt0/vzCuywDO2gBxniczIX/1yYLff9zzKqUctYISINqb+uHwPk2DOPQRSVuornyGFnYGywRwMixpJZ5oAWOpiaBG5XXijS/Meyb4e7aUrMC8ux+5vZ0RZkflspR8Hw7R+vvARF8BW7mGVysBL8xR+79t4cNaM8glNg6vQWzlsGmy6GrlzCReSy7M3AjvtIl6X5x+7jIZ8KJ+N1svjf3BBO5p1K0WiqPLAtCe2W+gU5rtzIhH1dAL9l+p+9xEEqjPMChErJHRCEB6RE/zrDD0E4=; 5:IrWzOyJHM8ZVTlotHgDSxZ0QtiHQJIcBv0kmJ8gJf6ea6zib6pDG/88DgfRYkCUedaT2PcqjS6XvEPLYp9JNa/tYfhmj5Pye5IoZKSuxR+9P8dUf+rarbOTfw/z41R9We44N0VAKuuzAHAnNOA7s8w==; 24:UgqRze1PHONrsRF9CYLZdC7K2vFb6oyCIzGTO0G0oiZ7kgPqY2zpIO84GgvrTDz2NiG5caFA1VXoUVSlgvvqJNkmaukQjiAFQpQGe1MJ6fg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB534; 7:kIW4C2Mkyd0d+Hr/EFDdpWcUIxLdsNTdg2Bm1s3VFUjUJfU0jfz6uJ/i/4NCVdBkLVpRx/+cRr7BDHlkqCGFzAVkjNIV+Ke//2yOOtGXD4d1JhQqUeCXLmZt0+85NsebePFfjYT/9HAWqBy05Eu+ucdSePMbezEfsktQe6fVBvOOqEoV19ck060rhtnDKiWMZg9XPaVD/c2XfzhC65FhgOW/Z7HGthHkLLRBcwwuZEuZYSjLY40XPGYtzh7caWF8+qKHnCbSe038xELNc4KJE5eaqt/qb4IB6a5GowJahwxy/Coot2SxWIXCs0IF6iZTqNU1CgPzvtHxPdGyUP97Kg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2017 23:23:14.1715 (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: BN1PR05MB534 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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, 03 Apr 2017 23:23:21 -0000 Kyle Rose writes: > On Mon, Apr 3, 2017 at 1:39 PM, Mark D. Baushke wrote: > But getting back to this specific case: what is the provenance of the IKE > groups? The RFC 3526 DH MODP groups were provided by Tero Kivinen and Mika Kojo based on pi. You may find Tero's respsonse about them https://www.ietf.org/mail-archive/web/curdle/current/msg00808.html Reference o the proofs of the primality of both RFC 3526 and RFC 7919 numbers may be found here: https://www.ietf.org/mail-archive/web/curdle/current/msg00790.html which leads to URLs: https://kivinen.iki.fi/primes/ and https://www.ietf.org/mail-archive/web/tls/current/msg15716.html For what it is worth, I also used Primo to verify the RFC 3526 prime p and q values (q = (p-1)/2) a few years ago, but I have misplaced the proofs. (Primo URL: http://www.ellipsa.eu/public/primo/primo.html) Primo is a primality proving program based on the ECPP (Elliptic Curve Primality Proving) algorithm. Given positive odd integers, it tests whether these integers are prime, and if they are it produces primality certificates. With Primo, one can check crypto-primes and prove whether they are actually prime... or not. So, again for this specific case, are there any objections to proceeding with the RFC 3526 prime numbers as provided in this draft? -- Mark From nobody Mon Apr 3 18:33: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 4804612952E for ; Mon, 3 Apr 2017 18:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZyAtAjJUVoO for ; Mon, 3 Apr 2017 18:33:24 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 537981267BB for ; Mon, 3 Apr 2017 18:33:24 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id r45so127507876qte.3 for ; Mon, 03 Apr 2017 18:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nLYP/CwzCHzzlzAowWjkdpJYFa8CHakrZ8tvTjw4ySE=; b=MXPbryzZfbQWqKac1An10FkV6vRLSlz9sTq+n9DTk0/NpEOHidxzR624IZvcLQDTbb Q9Ru8GjO8bt+EE3eueXl51UNFE5d+lt3w3zXnOhp42XtvZjLE77StuAW+5qR4GCWGLAu I49kquHNoxID23Zg7ttU1Nw8NuX6l8+IHKlrM= 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=nLYP/CwzCHzzlzAowWjkdpJYFa8CHakrZ8tvTjw4ySE=; b=tWYDKqAY8Rd3j/MwGSTB0quNWUL+r0HPzZtH/f1+d/hT90E8KGvuwm+/3aCcTMVN2N DiFa2Bhd5ICj42PiZNqa9YSllmBR0kkIaqIPO2DGHivhBXgF3tq/HTxQ71JL4aK7Jvzy +2sAsS8bvIji4tI/ukKljoQfpd3hn/AaicSPBbNb21I+eDYENwG2CxBu6/dDDpFZa55d kUntkM6AO40xISFc9nGvcUJ13JcYpl8KJAMPV3v8uEzR6a4BpsZfLONHIrXU56+JkarA DvEnMXgkmL8bNruDAz2lo/I6CC7ngDXYEMEbv+RnFOmlZI0vhTLRYKTSk4fRKR+AWx9S a9sQ== X-Gm-Message-State: AFeK/H1o7pCOCGdmFxVYZfBuKpb4InB89BHxiivjKxmXY6xyYHQ4xxOo8ygBzUc4tz4j5/gPEDqbuQfML3PzDQ== X-Received: by 10.200.42.151 with SMTP id b23mr20010424qta.163.1491269603237; Mon, 03 Apr 2017 18:33:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Mon, 3 Apr 2017 18:33:22 -0700 (PDT) X-Originating-IP: [2001:470:1f07:121:802e:2aff:fea9:7bd] In-Reply-To: <57491.1491261791@eng-mail01.juniper.net> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> <98403.1491244781@eng-mail01.juniper.net> <57491.1491261791@eng-mail01.juniper.net> From: Kyle Rose Date: Mon, 3 Apr 2017 21:33:22 -0400 Message-ID: To: "Mark D. Baushke" Cc: Ilari Liusvaara , Hubert Kario , Anna Johnston , curdle@ietf.org, Peter Gutmann , Rich Salz , Tero Kivinen Content-Type: multipart/alternative; boundary=001a1142f5c2f732b8054c4d422a Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 04 Apr 2017 01:33:26 -0000 --001a1142f5c2f732b8054c4d422a Content-Type: text/plain; charset=UTF-8 On Mon, Apr 3, 2017 at 7:23 PM, Mark D. Baushke wrote: > So, again for this specific case, are there any objections to proceeding > with the RFC 3526 prime numbers as provided in this draft? > This non-cryptographer has no specific objections based on what I've read here. FWIW. Kyle --001a1142f5c2f732b8054c4d422a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Apr 3, 2017 at 7:23 PM, Mark D. Baushke <mdb@juniper.net> wrote:
So, again for this specific case= , are there any objections to proceeding
with the RFC 3526 prime numbers as provided in this draft?

This non-cry= ptographer has no specific objections based on what I've read here. FWI= W.

Kyle
--001a1142f5c2f732b8054c4d422a-- From nobody Tue Apr 4 01:28: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 4A79012778D for ; Tue, 4 Apr 2017 01:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFFhKmZCUEsa for ; Tue, 4 Apr 2017 01:28:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472CA12947C for ; Tue, 4 Apr 2017 01:28:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 45117CA008; Tue, 4 Apr 2017 08:28:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 45117CA008 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 45117CA008 Received: from pintsize.usersys.redhat.com (unknown [10.34.250.200]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BCCF791008; Tue, 4 Apr 2017 08:28:07 +0000 (UTC) From: Hubert Kario To: Ilari Liusvaara Cc: curdle@ietf.org, Anna Johnston , Peter Gutmann , "Salz, Rich" , Tero Kivinen , Mark Baushke Date: Tue, 04 Apr 2017 10:28:01 +0200 Message-ID: <7424886.CJaF7KyKNh@pintsize.usersys.redhat.com> In-Reply-To: <20170403195504.GA5603@LK-Perkele-V2.elisa-laajakaista.fi> References: <7105530.JWnP7qziXW@pintsize.usersys.redhat.com> <20170403195504.GA5603@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1844345.78niUWYmOl"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 04 Apr 2017 08:28:08 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 04 Apr 2017 08:28:11 -0000 --nextPart1844345.78niUWYmOl Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 3 April 2017 21:55:05 CEST Ilari Liusvaara wrote: > On Mon, Apr 03, 2017 at 08:03:03PM +0200, Hubert Kario wrote: > > On Monday, 3 April 2017 19:30:02 CEST Ilari Liusvaara wrote: > > > AFAIK, the problem is that those numbers (however "small" is defined) > > > aren't the only ones SNFS is efficient for: There are random-looking > > > numbers that turn out to be vulernable to SNFS, or worse, are vulerna= ble > > > to SNFS if one knows some hidden piece of information. > >=20 > > But if I read the MathWorld correctly[1], the speedup for polynomials is > > marginal (from crypto PoV) compared to numbers of no special form... > >=20 > > Unless you mean something else by "hidden piece of information". >=20 > Might have been misremembering that it had something to do with > polynomials. >=20 > What I mean: Numbers that look random and one can't apply SNFS in any > obvious way, but knowing some hidden piece of information enables one > to get decent speedup from SNFS. yes, but that "decent" speedup is in practice an order or two in magnitude= =20 (downgrade of a 1024 bit prime to 1000 bit)[2]. That applies only for the=20 sieve step of the attack, it does not apply to the linear algebra (the thin= g=20 that dominates the precomputation) or the descent step[1]. 1 - https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf 2 - Coppersmith, D. "Modifications to the Number Field Sieve." J. Cryptolo= gy=20 6, 169-180, 1993 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1844345.78niUWYmOl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY41kRAAoJEJKo0bgB0vX1yhMP/RYVO+EX6AWXnqycuwtyKTYe XVEq9po9DL66jCHzuF9E5PpPU0OxPpRERQmlzTJcy1a4AAC+7U99DwBZJvMqdF8J jzaRT8nSuy/Vnq5zBOVyT0vy42XOnzUNvJTqDDNgevNzH146PFNSSBRA65u/K5Bu 8yea9MW1H4f6u+Wp1sjS0t6zEpPO+Bs19nnaQd3BiHNNRbhOyvvQtAeuYrGWepzf BmasBOa0WPP0gYFKvYG6imlLiE2cjXr0BPPvDCGKcm1CxQStW6/ozCoQouCXWfrT alePmYcmzgAQGJoDjcSQj7v/8DIj7Hi8RKCE5Te/VRUCAugEaeicoYbD69kpriH4 7pP24qKK9YnHgZH2fq4foPToZ7kpzX7tw+nYGO3PaPLHrtf63PssvVliIDpXChaU SO5QWbtd05cnQUumXmynxQZyOwks33Bt8ex6LgpCcY555DVkOKeImvPAARGRrgS6 F4iPY/uM84uznJYGO8LWf4c+AQ2mJG3slXqZ01KspJ490YU8i5U1M9NmzNIcScIA vpXMn6taL6ynrlbfG2HRIR3QEGNiECHvY1xf8J5Hhz5jiNPS85Zj9JRYWVHcxk76 t5wI82tkCcuh3NeLhBA5u62z+MIUZx4OZoE5WLgw+JZ6TQ1Fo180FnNdyJmF0m8H La/uUbe2ezuD4Dwulzu/ =KXo0 -----END PGP SIGNATURE----- --nextPart1844345.78niUWYmOl-- From nobody Tue Apr 4 05:09:38 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 C10E112773A for ; Tue, 4 Apr 2017 05:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EvRUb-9j7Lj for ; Tue, 4 Apr 2017 05:09:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 256751275AB for ; Tue, 4 Apr 2017 05:09:34 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v34C9TAI029176 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 15:09:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v34C9Sdp026634; Tue, 4 Apr 2017 15:09:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22755.36088.902385.670179@fireball.acr.fi> Date: Tue, 4 Apr 2017 15:09:28 +0300 From: Tero Kivinen To: "Mark D. Baushke" Cc: In-Reply-To: <57491.1491261791@eng-mail01.juniper.net> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> <98403.1491244781@eng-mail01.juniper.net> <57491.1491261791@eng-mail01.juniper.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 37 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Tue, 04 Apr 2017 12:09:37 -0000 Mark D. Baushke writes: > Kyle Rose writes: > > > On Mon, Apr 3, 2017 at 1:39 PM, Mark D. Baushke wrote: > > > But getting back to this specific case: what is the provenance of the IKE > > groups? > > The RFC 3526 DH MODP groups were provided by Tero Kivinen and Mika Kojo > based on pi. You may find Tero's respsonse about them > https://www.ietf.org/mail-archive/web/curdle/current/msg00808.html And the method used was following the method described in the RFC2412 Appendix E: ---------------------------------------------------------------------- Classical Diffie-Hellman Modular Exponentiation Groups The primes for groups 1 and 2 were selected to have certain properties. The high order 64 bits are forced to 1. This helps the classical remainder algorithm, because the trial quotient digit can always be taken as the high order word of the dividend, possibly +1. The low order 64 bits are forced to 1. This helps the Montgomery- style remainder algorithms, because the multiplier digit can always be taken to be the low order word of the dividend. The middle bits are taken from the binary expansion of pi. This guarantees that they are effectively random, while avoiding any suspicion that the primes have secretly been selected to be weak. Because both primes are based on pi, there is a large section of overlap in the hexadecimal representations of the two primes. The primes are chosen to be Sophie Germain primes (i.e., (P-1)/2 is also prime), to have the maximum strength against the square-root attack on the discrete logarithm problem. The starting trial numbers were repeatedly incremented by 2^64 until suitable primes were located. Because these two primes are congruent to 7 (mod 8), 2 is a quadratic residue of each prime. All powers of 2 will also be quadratic residues. This prevents an opponent from learning the low order bit of the Diffie-Hellman exponent (AKA the subgroup confinement problem). Using 2 as a generator is efficient for some modular exponentiation algorithms. [Note that 2 is technically not a generator in the number theory sense, because it omits half of the possible residues mod P. From a cryptographic viewpoint, this is a virtue.] ---------------------------------------------------------------------- > Reference o the proofs of the primality of both RFC 3526 and RFC 7919 > numbers may be found here: > > https://www.ietf.org/mail-archive/web/curdle/current/msg00790.html > > which leads to URLs: > > https://kivinen.iki.fi/primes/ > and > https://www.ietf.org/mail-archive/web/tls/current/msg15716.html > > For what it is worth, I also used Primo to verify the RFC 3526 prime p > and q values (q = (p-1)/2) a few years ago, but I have misplaced the > proofs. (Primo URL: http://www.ellipsa.eu/public/primo/primo.html) In addition to verify that primality of the primes, it is important to verify that the primes are also the first ones you will find by following the algorithm described above. I.e., that the one generating them did not skip a number trying to find the "good" one. I.e., that there was not a bug in our software we used to find those primes... Btw, in early days I used program called ECPP written by Francois Morain (INRIA) on alpha architecture to verify the primes, and moved to Primo 1.0.0 on x86 when starting to work on the 6144, and 8192. Then I moved to primo 2.0 when trying to proove 12288 and 16384 bit primes. So the smaller primes (<6144) have been verified by using two different programs, on two different architectures and using different operating systems, so perhaps we can trust those verifications... > So, again for this specific case, are there any objections to proceeding > with the RFC 3526 prime numbers as provided in this draft? -- kivinen@iki.fi From nobody Tue Apr 4 08:39:55 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 84F03129789 for ; Tue, 4 Apr 2017 08:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rr6M6vvi-oIR for ; Tue, 4 Apr 2017 08:39:27 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 BFB351296E0 for ; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491320364; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c3Ej7qso2fQl3ZbvjqAnUcD43bbgy/FW5MdFSflIKOI=; b=Az5VdoBa9xGr0geZ5oV3rxbIjbJ0MAZo0P+MLGJ3egzs0peDuIWvt/TREJhlTKjy liMh04yfEphrtXqjZazrZ68N6VM1NpUW+qfZVc1ZZOfSu1bNM4vtGpu4ituLOO+g uqWLrSzSqhMHHKPiFc+K2UjCDApqyDXgByufhpi5jDZoYP4fEZdwqP2nL7HEErHO 4KZEVvx6/FT3i5CVgTPZe8HSxxJHKUTeJuUBM5SCo4+IcLz0UqDpAklIgj7uZR8w JuPmlIbwtu+b1Z+YKeBhKIKytPQ2C/LCCMZcODiVRsWhoBGdETkx7jdzzbpat5yR 9U4EjEDs0rQ5yQy+41siOw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 47.2D.25383.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) X-AuditID: 11973e12-003389a000006327-80-58e3be2c8244 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id C5.7C.06512.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)" Received: from [17.153.62.197] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONW00H6265NOG30@nwk-mmpp-sz10.apple.com>; Tue, 04 Apr 2017 08:39:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <87BF9C95-B970-4579-AC73-A5E1EC7F2BF8@apple.com> Date: Tue, 04 Apr 2017 08:39:23 -0700 In-reply-to: Cc: "curdle@ietf.org" , IPsecME WG , Daniel Migault , Jim Schaad , "spasm@ietf.org" , "tls@ietf.org" , "saag@ietf.org" To: David Schinazi References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FDorKuz73GEwY9N0hZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnBICJhI/FqR28XIxSEksJdRYuqn/axdjJxg 8d5dn5khEocYJSbufgeW4BUQlPgx+R4LiM0sECbx581Jdoiir4wSW3/1s4FMFRaQkNi8JxGk hk1AReL4tw3MEL02Em+2f2cHsYUFAiQuHrkPFmcRUJXofDcVbCangK3E8slbwBYzCzQwSbyZ /JcJJCEioCGxrWkBK8Syn4wSG3s+QJ0qK9G9cBpYh4TAdzaJNQf/s05gFJqF5NpZSK6FsLUk vj9qBYpzANnyEgfPy0KENSWe3fsEVaIt8eTdBdYFjGyrGIVyEzNzdDPzTPQSCwpyUvWS83M3 MYJiabqd0A7GU6usDjEKcDAq8fBemPE4Qog1say4MvcQozQHi5I4b8CdexFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGHX0H9dtW+b2u3+LfH/h9ezVyQeKj1zyMd+l3N1rbTZtEd/jbRyx Dxt2f2iQTnb4/Obw/0Mr+C+y1T3O3HPRZFaID9vfyPrXdz5uS9l0KWRCqaHxl2eLS0Vml0xU 0BPe3Vrq6VkRJH/g7l3tS7cPnAuIfN/4dpNVjlCnldK8j3VXhJQsZY6GLlRiKc5INNRiLipO BAAkoxtAhgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUi2FBcpauz73GEwelZwhZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnJICJhI9O76zNzFyMUhJHCIUWLi7nesIAle AUGJH5PvsYDYzAJhEn/enGSHKPrKKLH1Vz9bFyMHh7CAhMTmPYkgNWwCKhLHv21ghui1kXiz /Ts7iC0sECBx8ch9sDiLgKpE57upYDM5BWwllk/eAraYWaCBSeLN5L9MIAkRAQ2JbU0LWCGW /WSU2NjzgRXiVFmJ7oXTmCcw8s9CcuAsJAdC2FoS3x+1AsU5gGx5iYPnZSHCmhLP7n2CKtGW ePLuAusCRrZVjAJFqTmJlUZ6iQUFOal6yfm5mxjBwV/ovIPx2DKrQ4wCHIxKPLwXZjyOEGJN LCuuzAWGEgezkgiv/R6gEG9KYmVValF+fFFpTmrxIcaJjEBvTmSWEk3OB8ZmXkm8oYmJgYmx sZmxsbmJOS2FlcR5c8rvRQgJpCeWpGanphakFsEcxcTBKdXA6MM4uzd10kED8clhtuwcE0Tm 3l874yDPz7fiXFtj7t/5xchbnqRSZ3HiVe2sirzO+0KNblNdp/h+/rtcqLW0ifXP8l2n7GuW 5fcpXi9KSNrREhZvty6bZZNW9pL6DImZ18xPbWqdtlpPxLVrt+7lYLkuWTZp7Y0/3J0ftvzM Snsu3p3/VGepEktxRqKhFnNRcSIAtItIifECAAA= Archived-At: Subject: Re: [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.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, 04 Apr 2017 15:39:34 -0000 --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, > David Schinazi > > >> On Mar 28, 2017, at 15:43, Daniel Migault > wrote: >> >> Hi, >> >> Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. >> >> Yours, >> Daniel >> >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Tuesday, March 28, 2017 4:40 PM >> To: curdle@ietf.org >> Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> Here is the promised updated draft. >> >> Changes: >> 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. >> 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. >> >> That should be the final issues in the draft >> >> Jim >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, March 28, 2017 4:31 PM >>> To: Jim Schaad ; Simon Josefsson >>> >>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >>> >>> >>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >>> successfully submitted by Jim Schaad and posted to the IETF repository. >>> >>> Name: draft-ietf-curdle-pkix >>> Revision: 04 >>> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >>> use in the Internet X.509 Public Key Infrastructure >>> Document date: 2017-03-28 >>> Group: curdle >>> Pages: 15 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >>> >>> Abstract: >>> This document specifies algorithm identifiers and ASN.1 encoding >>> formats for Elliptic Curve constructs using the Curve25519 and >>> Curve448 curves. The signature algorithms covered are Ed25519 and >>> Ed448. The key agreement algorithm covered are X25519 and X448. The >>> encoding for Public Key, Private Key and EdDSA digital signature >>> structures is provided. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at tools.ietf.org. >>> >>> The IETF Secretariat >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I've gone through my review of the draft as = well, and I think this version looks good!

Thanks,
Tommy

On Apr 3, 2017, at 11:25 AM, David Schinazi = <dschinazi@apple.com> wrote:

Thanks for the update!
I've reviewed -04 and I think the draft is ready = to move forward.

Regards,
David Schinazi

On Mar 28, 2017, at 15:43, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 

Thank you Jim for the update. Here is the = version resulting from the discussion we had during the WG meeting = yesterday.  Please review the document and provide your feed backs = by April 4 so we can move the draft to the IESG. 

Yours, 
Daniel

-----Original = Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Tuesday, March 28, 2017 4:40 PM
To: curdle@ietf.org
Subject: [Curdle] FW: New = Version Notification for draft-ietf-curdle-pkix-04.txt

Here is the promised updated draft.

Changes:
1.  Fixed an example that David = Benjamin found was wrong.  (Incorrect sign bit in public key.) 2. =  Remove all of the pre-hash text except to note that it does = exist.
3.  No changes to the OID arc being used = despite the agreement during the meeting.  After the meeting, Russ, = the chairs and I had a short talk and decided that this did not need to = occur.  The problem was only with getting new values assigned not = with the current values which were already assigned.

That should be the final issues in the draft

Jim


-----Original Message-----
From: = internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: = Tuesday, March 28, 2017 4:31 PM
To: Jim Schaad <ietf@augustcellars.com>; Simon Josefsson 
<simon@josefsson.org>
Subject: New = Version Notification for draft-ietf-curdle-pkix-04.txt


A new version of I-D, = draft-ietf-curdle-pkix-04.txt has been 
successfully = submitted by Jim Schaad and posted to the IETF repository.

Name: draft-ietf-curdle-pkix
Revision: 04
Title: Algorithm Identifiers for = Ed25519, Ed448, X25519 and X448 for
use in the Internet = X.509 Public Key Infrastructure
Document date: = 2017-03-28
Group: curdle
Pages: 15
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.= txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-04

Abstract:
 This = document specifies algorithm identifiers and ASN.1 encoding
 formats for Elliptic Curve constructs using the = Curve25519 and
 Curve448 curves.  The signature = algorithms covered are Ed25519 and
 Ed448.  The = key agreement algorithm covered are X25519 and X448.  The
 encoding for Public Key, Private Key and EdDSA digital = signature
 structures is provided.




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

The IETF Secretariat


_______________________________________________
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

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

= --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)-- From nobody Thu Apr 6 05:04: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 B90141201F8 for ; Thu, 6 Apr 2017 05:04:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0gOhNVc88CW for ; Thu, 6 Apr 2017 05:04:34 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798D7129461 for ; Thu, 6 Apr 2017 05:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491480272; x=1523016272; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jaMUm5N8h0r2ijyIddZmeQ9NtMuejgE72S1uYjtN+k8=; b=t1bVnPy04SobfM8dsWGvK07Yml7eJNLf+ohg3qt0BazZLPsYUPQZTW0o yFL8xmehSNdwZdM8EbRBTWpT8Pw632o+0z2cyVxWTp48OvUo813dxOGj0 s3O1YP7AAGO3cB9HFXmqbz7twMuUc3yDZX4yZFcAIjLRac5mihttsgYs/ TpaiRL4r2NRGS741xJJ+NhIyYrnBWrfoTWLms/sXFywORTAiCUfXCxEH/ 3ymlC4YjjYGKyRENJgMKsiDQy2yzcVkNwqJdmyWovEccTf87x8Z06k8uU uYMYaSQPMAtWjUy5/4BDC72fh5tRW2TTo5kRYqa1LJD29e7dMCMiyjSgM A==; X-IronPort-AV: E=Sophos;i="5.37,159,1488798000"; d="scan'208";a="148258507" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2017 00:04:29 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 00:04:28 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Fri, 7 Apr 2017 00:04:28 +1200 From: Peter Gutmann To: "denis bider (Bitvise)" , Daniel Migault , curdle Thread-Topic: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info Thread-Index: AQHSn+vj75AP59wDbUy5ryRiOFPQYKGb4DhQgAWgX4CAA91Jyf//yxWAgBMy0Xk= Date: Thu, 6 Apr 2017 12:04:27 +0000 Message-ID: <1491480250094.74577@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz>, <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz>, <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz>, <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> In-Reply-To: <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 06 Apr 2017 12:04:37 -0000 denis bider (Bitvise) writes:=0A= =0A= >Can you point out some of these subtle problems that could occur in this= =0A= >regard in SSH?=0A= =0A= I was thinking of the problem that it's essentially impossible to safely do= n-=0A= RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn't= =0A= going to be any better. I was reasoning by analogy from TLS rather than=0A= sitting down and drawing diagrams for SSH to try and figure out all the=0A= possible issues.=0A= =0A= >Under the assumption that such an extension were defined, can you point ou= t=0A= >at least one way that sending this info right after NEWKEYS can help an=0A= >attacker?=0A= =0A= It depends on the extension. Without one defined, there's no way to tell a= t=0A= the moment. I could invent something that works out badly, but that'd be= =0A= creating a strawman... my concern is that in the future someone may define = a=0A= problematic extension without realising that they're creating a problem.=0A= Perhaps adding an implementation note to say that at this point the crypto= =0A= hasn't been confirmed yet and so you may want to be careful about what you = put=0A= into your extension data would be useful?=0A= =0A= >But the extension value field is generically a string (it must be same typ= e=0A= >for all extensions, so unsupported extensions can be decoded and ignored).= =0A= >"p" and "s" are therefore fitting ways to express this boolean.=0A= =0A= Wouldn't "true" and "false" be a better way to express a boolean? I realis= e=0A= this is kinda bikeshedding, but having to look up the spec just to figure o= ut=0A= what mysterious magic values in a boolean field specify seems a bit awkward= .=0A= =0A= >Properly implemented flow control is superior. However, this extension is = a=0A= >nod to that not everyone will be using an SSH library that does this right= ,=0A= >and "no-flow-control" is a better option if your needs are simple, and you= =0A= >don't have a few years to get this right.=0A= =0A= Given that there are a nonzero number of implementations that send a window= =0A= size of ~0 to indicate no flow control, it may be useful to add an=0A= implementation note to point this out. I enabled some diagnostic code to= =0A= throw an exception in my code if it found this from another implementation= =0A= (other than mine) and got, uh, feedback from beta-testers about it, so at= =0A= least some implementations are using a pseudo-infinite window size to indic= ate=0A= no flow control. I'm not saying it should be adopted as an alternative to= =0A= "no-flow-control", but merely to alert implementers about the practice, e.g= . a=0A= certain big iron vendor whose device would crash and reboot as it tried to= =0A= allocate ~0 bytes of memory to match the widow size.=0A= =0A= Peter.= From nobody Thu Apr 6 05:14: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 545A81242EA for ; Thu, 6 Apr 2017 05:14:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XX1QGYBj2sSL for ; Thu, 6 Apr 2017 05:14:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6793D12946C for ; Thu, 6 Apr 2017 05:14:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491480852; x=1523016852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MiUr4wrEJjSSjg/PszI9KDfNZy6hLwlHF17BzHQeosk=; b=uxyRmVe3nf0jif6GozmnJxOPHrDgDHCn/p5gNpycmDaF4mPysy7LU3yW jvMDNY/PAM4SXg9mUBrHPVphGElTloWOdkjvfS3Uh7jkz9k1Er19O5xQS uVa2G5X6cGxYIsL66mMbLcspaO2Q5mf4Ut0NjW+caLxYTz9So3SktIllf oFJNF6Hxm9BXXwRx7B/HO1QTk5u55u51iWEU+0tLr383tAFSZ9NXxs//o K+oo5plNqP88naLA6k7uLkIj37m8QYQiE2wIiJFXl4B+oc+3cROoOtqwi Q3oFlaPpMR3fr+y++Ry3bmGSGFC8rsvFXQK/I8ZBCXYIjz6duazp46/ub g==; X-IronPort-AV: E=Sophos;i="5.37,159,1488798000"; d="scan'208";a="148259544" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2017 00:14:11 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 00:14:10 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Fri, 7 Apr 2017 00:14:10 +1200 From: Peter Gutmann To: Tero Kivinen , Anna Johnston CC: "Salz, Rich" , curdle , Mark Baushke Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSp+P9Zh0d3oAyu0685TNgkwvXXqGptgiAgAGYQ13//87UgIAAPwAAgAAoUICAACsZAIABArWAgAucd7Q= Date: Thu, 6 Apr 2017 12:14:09 +0000 Message-ID: <1491480832075.44727@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <22747.54905.670599.560304@fireball.acr.fi> <58EFAF37-42A8-4AFE-B2A5-57100710B201@juniper.net> <22748.11555.248359.687303@fireball.acr.fi> , <22749.10831.799493.535716@fireball.acr.fi> In-Reply-To: <22749.10831.799493.535716@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 12:14:14 -0000 Tero Kivinen writes:=0A= =0A= >In SSH RFC4419 allows transfering also p and g only. There is no space for= q=0A= >or h.=0A= >=0A= >Not sure about TLS.=0A= =0A= TLS-LTS updates the spec to send { p, q, g }, that was one of the explicit= =0A= changes made so you can now verify the DH values.=0A= =0A= Peter.= From nobody Thu Apr 6 05:21: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 6030612947C for ; Thu, 6 Apr 2017 05:21:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5SHHCNYu3eC for ; Thu, 6 Apr 2017 05:21:04 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA38C129411 for ; Thu, 6 Apr 2017 05:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491481262; x=1523017262; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OYke58g4m1gtMtlzpW/bCrBf6pfjA8MRAyRQ5CecNN4=; b=F2/O6jzlLlTetJArcYzEh37wKYbM35fQhr+Sq4Y6uCeia/EK+wfQTuL/ JSXmkBgu2EnXfjbdAlsDAh0rl+lp+Rkr+e/NiRol8ci1QNFnqwXYBSjUt Qf55O1cHJTLR8Eq8kvJyI7SdGCGJp9S6Uam9RzdsD9Y0v22w23+lqJAjN bp0UrvQHbhQPamnEkeskLZG2RurZ7AG7z8oWBNu9iSETLNI7G7q6y5r+/ NI/QoE3FAd3t+bsUDuwzXQ2N7udqlRxdcriMWplXKAexrh6HiBSglWq+0 1nUD6NzMwQXPxUBj6cnjGteV7AAu/FBpm78TOneDdR0JVTGeFkju23a/D g==; X-IronPort-AV: E=Sophos;i="5.37,159,1488798000"; d="scan'208";a="148260275" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2017 00:21:00 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 00:21:00 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Fri, 7 Apr 2017 00:20:59 +1200 From: Peter Gutmann To: Tero Kivinen CC: "Mark D. Baushke" , "Salz, Rich" , curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKbDCCDwtgJ6TEe+nT3SNcvyA6Gst6HVgAAWtwCAC4CwUA== Date: Thu, 6 Apr 2017 12:20:59 +0000 Message-ID: <1491481241400.6079@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz>, <22749.17194.509999.470077@fireball.acr.fi> In-Reply-To: <22749.17194.509999.470077@fireball.acr.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 12:21:08 -0000 Tero Kivinen writes:=0A= =0A= >How about you verifying both IKE and TLS groups and make sure they are=0A= >actually generated as explained, and that they are first primes matching t= he=0A= >process...=0A= =0A= And now we run into the Bystander Effect problem of security audits, everyo= ne=0A= wants to have source code for whatever security tool they use published but= =0A= no-one would ever dream of checking the code themselves, they all expect=0A= someone else to do it for them...=0A= =0A= >If you are scared about that then just go to the 4096 bit Diffie-Hellman. = If=0A= >it will take years to break 1024-bit DH, and billion years (10^9) more to= =0A= >break 2048-bit DH, then 4096-bit DH should be safe... :-)=0A= =0A= I think we'll have to agree to disagree on our approaches here, you seem to= be=0A= advocating putting all your trust in a single honkin' big key, while I pref= er=0A= to diversify as much as possible so that if something breaks in one locatio= n=0A= then there are a pile of other measures that'll serve as a backup.=0A= =0A= Peter.= From nobody Thu Apr 6 05:59: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 6C871124BFA for ; Thu, 6 Apr 2017 05:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW7lPG9OZ_AD for ; Thu, 6 Apr 2017 05:59:03 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1FA127F0E for ; Thu, 6 Apr 2017 05:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491483539; x=1523019539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bgP5eAhr7RCZHYZ51spJcFkvueHHNVJeQa89PUjwCr8=; b=arAxCmqbnklm3JrwBXz1g9mSEyCbdkpZYIN6ucnLFuk9WkEd5c6kOJxy ob5efrEeeU78oy52Ywso5/4KG4ZY905OnkDsM0uCTrh1TXeJ7DKUsrKaA 412rJ+fN2qkTzdXYq4ni/Vw0K0ufRvjI+EYHTC1sQMHUDQjvoGo27B06q ZpAEQ3gXwFDlrvvor8fZjDUDbqicL5sQiBBCHdaCDa3ebZiMNGpWK6o4y S5Fqt5dC+rfCe3wCvVLyeaQZfiliIig8CsAknrVe8Vm/epUiH0LYLbFLR qNh2h7Nb2LRIcQ/YRqhdnqOTHKLUrb2bguwzRMfRLS+1GLtlJtfw05Ywz w==; X-IronPort-AV: E=Sophos;i="5.37,159,1488798000"; d="scan'208";a="148263968" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Apr 2017 00:58:56 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 7 Apr 2017 00:58:56 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Fri, 7 Apr 2017 00:58:56 +1200 From: Peter Gutmann To: "Mark D. Baushke" , Kyle Rose CC: Ilari Liusvaara , Hubert Kario , Anna Johnston , "curdle@ietf.org" , "Salz, Rich" , Tero Kivinen Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSrKmyRagmY9p5fUGTi9Rjy6QOhqG4UUeu Date: Thu, 6 Apr 2017 12:58:55 +0000 Message-ID: <1491483517406.49325@cs.auckland.ac.nz> References: <2593292.GJxAngHQUW@pintsize.usersys.redhat.com> <20170403142621.GA4071@LK-Perkele-V2.elisa-laajakaista.fi> <2634426.8WAjDsKgoR@pintsize.usersys.redhat.com> <20170403173002.GA4761@LK-Perkele-V2.elisa-laajakaista.fi> , <98403.1491244781@eng-mail01.juniper.net> In-Reply-To: <98403.1491244781@eng-mail01.juniper.net> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 12:59:05 -0000 Mark D. Baushke writes:=0A= =0A= >I don't think we know how effective Nothing Up My Sleeve (NUMS) techniques= =0A= >will be in the long run.=0A= =0A= I think the first thing we'd need to do is figure out what people agree on = as=0A= being NUMS. The Brainpool ECC curves, for example, are meant to be NUMS, b= ut=0A= then people have pointed out that there are various sources of attacker-=0A= controlled (or at least curve-generator-controlled) entropy that went into= =0A= those such as the choice of hash algorithm (you can get several bits by=0A= deciding to use SHA-1 vs SHA2-256 vs SHA2-512 vs. ...), and other odds and= =0A= ends. What PRF do you use? What constant(s) do you start with? etc. In= =0A= any case, is this actually an issue or is it just people nitpicking?=0A= =0A= Then there's the question of how you generate them. I'd prefer something t= hat=0A= can be coded up relatively easily in your bignum library of choice, so that= =0A= anybody can verify, using something they've built themselves, that things a= re=0A= kosher. It's been pointed out that https://kivinen.iki.fi/primes/ contains= =0A= primality proofs, but what it really contains is a huge amount of text that= =0A= doesn't mean anything to anyone who isn't intimately familiar with the tool= =0A= used. This isn't in any way meant as a criticism of Tero, but more to poin= t=0A= out that saying "here is a large amount of incomprehensible machine-generat= ed=0A= text, trust me, the primes are OK" reduces directly to "trust me, the prime= s=0A= are OK". Since most people won't be able to make head or tail of what's on= =0A= that page, the result ends up as "trust me" again.=0A= =0A= Extending this further, if I wanted to replicate the results on that web pa= ge,=0A= I'd end up on http://www.ellipsa.eu/public/primo/primo.html, an HTTP (non-= =0A= HTTPS) web page with an unsigned, unauthenticated 7z file containing a bina= ry=0A= blob that I'm expected to download and run on a 64-bit Linux box to verify= =0A= that my precious crypto parameters aren't backdoored. =0A= =0A= So, how many people can see the problem here?=0A= =0A= Again, I'm not saying that any of this has been deliberately backdoored or= =0A= rigged, but more that if you're going for NUMS then it needs to be NUMS all= =0A= the way down, not "this bit can be verified, and after that you'll just hav= e=0A= to trust me". So perhaps the doc that specifies the values could contain= =0A= pseudocode that anyone can use with (at least) GMP and the OpenSSL bignum= =0A= routines to check that all is OK. And by that I don't mean a full-on=0A= primality prover, just a standard probabilistic check of the kind that a=0A= generic crypto library would be using in any case to generate DH parameter= =0A= sets.=0A= =0A= Peter.= From nobody Thu Apr 6 06:24: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 78C531294FD for ; Thu, 6 Apr 2017 06:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSD8QflntCED for ; Thu, 6 Apr 2017 06:24:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E98129415 for ; Thu, 6 Apr 2017 06:23:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B56F5104D5; Thu, 6 Apr 2017 13:23:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B56F5104D5 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B56F5104D5 Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 309CE9E8FB; Thu, 6 Apr 2017 13:23:42 +0000 (UTC) From: Hubert Kario To: Peter Gutmann Cc: "Mark D. Baushke" , Kyle Rose , Ilari Liusvaara , Anna Johnston , "curdle@ietf.org" , "Salz, Rich" , Tero Kivinen Date: Thu, 06 Apr 2017 15:23:35 +0200 Message-ID: <6604004.EhiNI3UWHj@pintsize.usersys.redhat.com> In-Reply-To: <1491483517406.49325@cs.auckland.ac.nz> References: <98403.1491244781@eng-mail01.juniper.net> <1491483517406.49325@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2658400.4sMh9AVq4F"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 06 Apr 2017 13:23:44 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 13:24:11 -0000 --nextPart2658400.4sMh9AVq4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 6 April 2017 14:58:55 CEST Peter Gutmann wrote: > Mark D. Baushke writes: > >I don't think we know how effective Nothing Up My Sleeve (NUMS) techniqu= es > >will be in the long run. >=20 > Then there's the question of how you generate them. I'd prefer something > that can be coded up relatively easily in your bignum library of choice, = so > that anybody can verify, using something they've built themselves, that > things are kosher. It's been pointed out that > https://kivinen.iki.fi/primes/ contains primality proofs, but what it > really contains is a huge amount of text that doesn't mean anything to > anyone who isn't intimately familiar with the tool used. This isn't in a= ny > way meant as a criticism of Tero, but more to point out that saying "here > is a large amount of incomprehensible machine-generated text, trust me, t= he > primes are OK" reduces directly to "trust me, the primes are OK". Since > most people won't be able to make head or tail of what's on that page, the > result ends up as "trust me" again. That how _all of cryptography_ works. Either you understand enough of the maths to follow along or you delegate i= t=20 to others and trust them. =20 > Extending this further, if I wanted to replicate the results on that web > page, I'd end up on http://www.ellipsa.eu/public/primo/primo.html, an HTTP > (non- HTTPS) web page with an unsigned, unauthenticated 7z file containing > a binary blob that I'm expected to download and run on a 64-bit Linux box > to verify that my precious crypto parameters aren't backdoored. >=20 > So, how many people can see the problem here? the point of generating primality certificates is that you don't care where= =20 they come from, either you can verify them and then you know that the numbe= r=20 tested is prime or you can't verify it and the number is likely not a prime= =20 (or the certificate is bogus) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2658400.4sMh9AVq4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY5kFXAAoJEJKo0bgB0vX1WDIP/3vTaFBT9fTI6TLfZQDuGIYW u6cn/1QYJKpJswhLGK+nBFYDxPuFVvDNf9TXnZAxiZy4VAWH9E9qJNvx5tWw50CV v7vsEH1fCkRcNBWhDKAeupH8p1cM1bTe7NzZrosxzPTuhu6nNyzvWSooW32f1N2P BzGSylXnNbvyyIRoF8qwzhi2jgXJ1yOx6oSC+DDvRStFbOkPWmmdowldAzysssFP +8cmGeUoTk1TkbfrokO+XO6ND8Gsdh4p9LEKyIiaTd32kXT6T2qe7c+lIt6Elyu3 8oWfzTqeqAQLqOKYnEIRAZAX8JkTorJxcu4aVL/pRJikgwlBiK3UJ4S1GIRI6WU4 ++2U6I4Cg3A2+kPaEMgxWJFrpRrdU30CKtwi9GWc8Qldk9tBG6zEaiXE6Jo3v7t7 Vp4zQEOOY2k7+s/UEf8r2psyMFWVEkZcC0+XKqbs36fWIFfApzavHdUiLQpmtMKT lsABOUHlGwT/E3/QgQ2VcDFxQpmQq+dRXYEUEif8mVK5XeV7sdWjYku1nP/PHwCd fzsdcMqZZUmUwpLa6GbftH+4jl7aA40QIDgBJPL2jub+3AAAR/6ou3Fg+OAenc6i B/bYkGw5LLQk5Iek5jT7bgUGjn69SDbs5xNTCAHDHiuUDAw55IQ3AY+JOJXR1tU2 RRLxv6h1B4Y4KEAJpRiy =QWQp -----END PGP SIGNATURE----- --nextPart2658400.4sMh9AVq4F-- From nobody Thu Apr 6 07:32:16 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 8201E127BA3 for ; Thu, 6 Apr 2017 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQEMi-C1H4ky for ; Thu, 6 Apr 2017 07:32:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 0468E1294B9 for ; Thu, 6 Apr 2017 07:32:12 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v36EViYi010115 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 17:31:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v36EVhPN020111; Thu, 6 Apr 2017 17:31:43 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22758.20815.777038.486083@fireball.acr.fi> Date: Thu, 6 Apr 2017 17:31:43 +0300 From: Tero Kivinen To: Peter Gutmann Cc: "Salz\, Rich" , curdle , "Mark D. Baushke" In-Reply-To: <1491481241400.6079@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> <22749.17194.509999.470077@fireball.acr.fi> <1491481241400.6079@cs.auckland.ac.nz> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 14:32:14 -0000 Peter Gutmann writes: > Tero Kivinen writes: > > >How about you verifying both IKE and TLS groups and make sure they are > >actually generated as explained, and that they are first primes matching the > >process... > > And now we run into the Bystander Effect problem of security audits, everyone > wants to have source code for whatever security tool they use published but > no-one would ever dream of checking the code themselves, they all expect > someone else to do it for them... I did verify the tools I used to verify those numbers, and I did verify the numbers generated by others. I cannot really do anything else than try to convince others to do same, so we get more independent audits done. > >If you are scared about that then just go to the 4096 bit Diffie-Hellman. If > >it will take years to break 1024-bit DH, and billion years (10^9) more to > >break 2048-bit DH, then 4096-bit DH should be safe... :-) > > I think we'll have to agree to disagree on our approaches here, you seem to be > advocating putting all your trust in a single honkin' big key, while I prefer > to diversify as much as possible so that if something breaks in one location > then there are a pile of other measures that'll serve as a backup. Yes, I definately think it is good to have one secure lock leading to room having dozen of important things, compared to have dozen rooms each with important things, and of those rooms have separate door and weak lock on the door. In my case the attacker needs to break the one secure lock, but when they do that they get everything, in your case they just need to break one weak lock to get something, and then they need to repeat the process dozen time, but their expected time to complete is still small fraction of time they require to break the one secure lock. And actually you also want to weak locks to be manufactured by different companies, where some of the companies might tell how the lock designed and manufactured, but most of the companies do not tell anything how the lock was designed or manufactured, you just assume they are good as they are the one providing the lock. And from the outside you cannot even see if the lock has any internal mechanisms inside, or wheter it can be opened with just screw driver... -- kivinen@iki.fi From nobody Thu Apr 6 10:38:32 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 D96BB129611 for ; Thu, 6 Apr 2017 10:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfLgiOag-fNI for ; Thu, 6 Apr 2017 10:38:27 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0110.outbound.protection.outlook.com [104.47.32.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CE9129618 for ; Thu, 6 Apr 2017 10:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OHPxhrddc8h19p1+XZAR8vlBk5QP347RfpynBnUQFyM=; b=Htr+LRCZlCZBCEZqiU8ZjkQXUVVkcnlGAr+QowmLBCkrJN28d8+sShxHq8J+le9wfu7DyFrLlkBcNaVBKIjdASEuLk8Nau3Wm37HxLGfw31wPNTEJaRJLVrkYyrR0Pqph0BiM5XLoYlsTM2SETYf0VuqbSKNKKb4Y8WWgMjNsUM= Received: from CO2PR0501MB1032.namprd05.prod.outlook.com (10.160.7.143) by DM2PR05MB704.namprd05.prod.outlook.com (10.141.177.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 17:38:24 +0000 Received: from CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) by CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) with mapi id 15.01.1019.019; Thu, 6 Apr 2017 17:38:24 +0000 From: Anna Johnston To: Hubert Kario , Peter Gutmann CC: Mark Baushke , Kyle Rose , "Ilari Liusvaara" , "curdle@ietf.org" , "Salz, Rich" , Tero Kivinen Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKNq8oLudfhpKUOh06KCX76vZaGrvzmAgACdpYD//7XDgIABeAuAgAFZ24D//+2rAIAErFsAgAA8tACAAC38gIAABVUAgAABYICAABI9BYAEV6KAgAAG5ID//9HYgA== Date: Thu, 6 Apr 2017 17:38:23 +0000 Message-ID: References: <98403.1491244781@eng-mail01.juniper.net> <1491483517406.49325@cs.auckland.ac.nz> <6604004.EhiNI3UWHj@pintsize.usersys.redhat.com> In-Reply-To: <6604004.EhiNI3UWHj@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; DM2PR05MB704; 7:qxDEMP99Ifk6MgUkI/MP31mSYuPiUMKQLLdAg33y6+jT8Kc89qPjPn54b3AA8VBgbq75dzDCVUWD25Gmx3vrpNOJ6WCmWfNnlMNNcLkVHev/+17Erdi3oOYip81VxdBRDZDhD9tbYn3YYlQIo/hE5B/0dtPvEak34OB2RPotjMr+94haThHZXofyO8T86JWpKBUtSuu2hIKslh+Az6humBKlxTMyqEvYMhJffVEE+6Kg+GafOb3TqHISarCblD8wDCpYcEnsuHdhIrPLqTQyyW5FMRvwi1oDXR2LX79sOXuNzHGwrK5ED6oecrcJPYe5Rl8Mi5pydXAtkl7x8xcXCQ== x-ms-office365-filtering-correlation-id: cf5e4a54-cabb-455a-c754-08d47d13b9d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR05MB704; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR05MB704; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB704; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39450400003)(39840400002)(39850400002)(39860400002)(39410400002)(24454002)(377454003)(6246003)(7736002)(102836003)(6116002)(3846002)(230783001)(122556002)(8676002)(93886004)(36756003)(8936002)(5660300001)(81166006)(6306002)(54906002)(966004)(6506006)(6512007)(99286003)(229853002)(15974865002)(305945005)(6486002)(86362001)(53936002)(77096006)(6436002)(3660700001)(2950100002)(33656002)(76176999)(50986999)(54356999)(25786009)(53546009)(2900100001)(4326008)(189998001)(2906002)(66066001)(3280700002)(38730400002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB704; H:CO2PR0501MB1032.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <411AD2389609EB42A99A6E7526246757@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 17:38:23.8698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB704 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 17:38:30 -0000 UGVyaGFwcyBpdCB3b3VsZCBiZSB3aXNlIHRvIHByb3ZpZGUgZG9jdW1lbnRhdGlvbiBvbiB3aGF0 IGlzIGluIHRoZSBjZXJ0aWZpY2F0ZSBhbmQgaG93IGl0IGlzIHVzZWQgdG8gdmVyaWZ5IHByaW1h bGl0eT8gIFRoYXQgd2F5IOKAmHRydXN0IG1l4oCZIGNhbiBiZSB2ZXJpZmllZCBtYXRoZW1hdGlj YWxseS4gIA0KDQpBbm5hDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIdWJl cnQgS2FyaW8gPGhrYXJpb0ByZWRoYXQuY29tPg0KRGF0ZTogVGh1cnNkYXksIEFwcmlsIDYsIDIw MTcgYXQgNjoyMyBBTQ0KVG86IFBldGVyIEd1dG1hbm4gPHBndXQwMDFAY3MuYXVja2xhbmQuYWMu bno+DQpDYzogIk1hcmsgRC4gQmF1c2hrZSIgPG1kYkBqdW5pcGVyLm5ldD4sIEt5bGUgUm9zZSA8 a3Jvc2VAa3Jvc2Uub3JnPiwgSWxhcmkgTGl1c3ZhYXJhIDxpbGFyaWxpdXN2YWFyYUB3ZWxoby5j b20+LCBBbm5hIEpvaG5zdG9uIDxhbWpAanVuaXBlci5uZXQ+LCAiY3VyZGxlQGlldGYub3JnIiA8 Y3VyZGxlQGlldGYub3JnPiwgIlNhbHosIFJpY2giIDxyc2FsekBha2FtYWkuY29tPiwgVGVybyBL aXZpbmVuIDxraXZpbmVuQGlraS5maT4NClN1YmplY3Q6IFJlOiBbQ3VyZGxlXSBkcmFmdC1pZXRm LWN1cmRsZS1zc2gtbW9kcC1kaC1zaGEyDQoNCiAgICBPbiBUaHVyc2RheSwgNiBBcHJpbCAyMDE3 IDE0OjU4OjU1IENFU1QgUGV0ZXIgR3V0bWFubiB3cm90ZToNCiAgICA+IE1hcmsgRC4gQmF1c2hr ZSA8bWRiQGp1bmlwZXIubmV0PiB3cml0ZXM6DQogICAgPiA+SSBkb24ndCB0aGluayB3ZSBrbm93 IGhvdyBlZmZlY3RpdmUgTm90aGluZyBVcCBNeSBTbGVldmUgKE5VTVMpIHRlY2huaXF1ZXMNCiAg ICA+ID53aWxsIGJlIGluIHRoZSBsb25nIHJ1bi4NCiAgICA+IA0KICAgID4gVGhlbiB0aGVyZSdz IHRoZSBxdWVzdGlvbiBvZiBob3cgeW91IGdlbmVyYXRlIHRoZW0uICBJJ2QgcHJlZmVyIHNvbWV0 aGluZw0KICAgID4gdGhhdCBjYW4gYmUgY29kZWQgdXAgcmVsYXRpdmVseSBlYXNpbHkgaW4geW91 ciBiaWdudW0gbGlicmFyeSBvZiBjaG9pY2UsIHNvDQogICAgPiB0aGF0IGFueWJvZHkgY2FuIHZl cmlmeSwgdXNpbmcgc29tZXRoaW5nIHRoZXkndmUgYnVpbHQgdGhlbXNlbHZlcywgdGhhdA0KICAg ID4gdGhpbmdzIGFyZSBrb3NoZXIuICBJdCdzIGJlZW4gcG9pbnRlZCBvdXQgdGhhdA0KICAgID4g aHR0cHM6Ly9raXZpbmVuLmlraS5maS9wcmltZXMvIGNvbnRhaW5zIHByaW1hbGl0eSBwcm9vZnMs IGJ1dCB3aGF0IGl0DQogICAgPiByZWFsbHkgY29udGFpbnMgaXMgYSBodWdlIGFtb3VudCBvZiB0 ZXh0IHRoYXQgZG9lc24ndCBtZWFuIGFueXRoaW5nIHRvDQogICAgPiBhbnlvbmUgd2hvIGlzbid0 IGludGltYXRlbHkgZmFtaWxpYXIgd2l0aCB0aGUgdG9vbCB1c2VkLiAgVGhpcyBpc24ndCBpbiBh bnkNCiAgICA+IHdheSBtZWFudCBhcyBhIGNyaXRpY2lzbSBvZiBUZXJvLCBidXQgbW9yZSB0byBw b2ludCBvdXQgdGhhdCBzYXlpbmcgImhlcmUNCiAgICA+IGlzIGEgbGFyZ2UgYW1vdW50IG9mIGlu Y29tcHJlaGVuc2libGUgbWFjaGluZS1nZW5lcmF0ZWQgdGV4dCwgdHJ1c3QgbWUsIHRoZQ0KICAg ID4gcHJpbWVzIGFyZSBPSyIgcmVkdWNlcyBkaXJlY3RseSB0byAidHJ1c3QgbWUsIHRoZSBwcmlt ZXMgYXJlIE9LIi4gIFNpbmNlDQogICAgPiBtb3N0IHBlb3BsZSB3b24ndCBiZSBhYmxlIHRvIG1h a2UgaGVhZCBvciB0YWlsIG9mIHdoYXQncyBvbiB0aGF0IHBhZ2UsIHRoZQ0KICAgID4gcmVzdWx0 IGVuZHMgdXAgYXMgInRydXN0IG1lIiBhZ2Fpbi4NCiAgICANCiAgICBUaGF0IGhvdyBfYWxsIG9m IGNyeXB0b2dyYXBoeV8gd29ya3MuDQogICAgDQogICAgRWl0aGVyIHlvdSB1bmRlcnN0YW5kIGVu b3VnaCBvZiB0aGUgbWF0aHMgdG8gZm9sbG93IGFsb25nIG9yIHlvdSBkZWxlZ2F0ZSBpdCANCiAg ICB0byBvdGhlcnMgYW5kIHRydXN0IHRoZW0uDQogICAgIA0KICAgID4gRXh0ZW5kaW5nIHRoaXMg ZnVydGhlciwgaWYgSSB3YW50ZWQgdG8gcmVwbGljYXRlIHRoZSByZXN1bHRzIG9uIHRoYXQgd2Vi DQogICAgPiBwYWdlLCBJJ2QgZW5kIHVwIG9uIGh0dHA6Ly93d3cuZWxsaXBzYS5ldS9wdWJsaWMv cHJpbW8vcHJpbW8uaHRtbCwgYW4gSFRUUA0KICAgID4gKG5vbi0gSFRUUFMpIHdlYiBwYWdlIHdp dGggYW4gdW5zaWduZWQsIHVuYXV0aGVudGljYXRlZCA3eiBmaWxlIGNvbnRhaW5pbmcNCiAgICA+ IGEgYmluYXJ5IGJsb2IgdGhhdCBJJ20gZXhwZWN0ZWQgdG8gZG93bmxvYWQgYW5kIHJ1biBvbiBh IDY0LWJpdCBMaW51eCBib3gNCiAgICA+IHRvIHZlcmlmeSB0aGF0IG15IHByZWNpb3VzIGNyeXB0 byBwYXJhbWV0ZXJzIGFyZW4ndCBiYWNrZG9vcmVkLg0KICAgID4gDQogICAgPiBTbywgaG93IG1h bnkgcGVvcGxlIGNhbiBzZWUgdGhlIHByb2JsZW0gaGVyZT8NCiAgICANCiAgICB0aGUgcG9pbnQg b2YgZ2VuZXJhdGluZyBwcmltYWxpdHkgY2VydGlmaWNhdGVzIGlzIHRoYXQgeW91IGRvbid0IGNh cmUgd2hlcmUgDQogICAgdGhleSBjb21lIGZyb20sIGVpdGhlciB5b3UgY2FuIHZlcmlmeSB0aGVt IGFuZCB0aGVuIHlvdSBrbm93IHRoYXQgdGhlIG51bWJlciANCiAgICB0ZXN0ZWQgaXMgcHJpbWUg b3IgeW91IGNhbid0IHZlcmlmeSBpdCBhbmQgdGhlIG51bWJlciBpcyBsaWtlbHkgbm90IGEgcHJp bWUgDQogICAgKG9yIHRoZSBjZXJ0aWZpY2F0ZSBpcyBib2d1cykNCiAgICANCiAgICAtLSANCiAg ICBSZWdhcmRzLA0KICAgIEh1YmVydCBLYXJpbw0KICAgIFNlbmlvciBRdWFsaXR5IEVuZ2luZWVy LCBRRSBCYXNlT1MgU2VjdXJpdHkgdGVhbQ0KICAgIFdlYjogd3d3LmN6LnJlZGhhdC5jb20NCiAg ICBSZWQgSGF0IEN6ZWNoIHMuci5vLiwgUHVya3nFiG92YSA5OS83MSwgNjEyIDQ1LCBCcm5vLCBD emVjaCBSZXB1YmxpYw0KDQo= From nobody Thu Apr 6 11:04: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 8752112422F for ; Thu, 6 Apr 2017 11:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZWNsWJHchuv for ; Thu, 6 Apr 2017 11:03:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164D91276AF for ; Thu, 6 Apr 2017 11:03:49 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 274CBC04B951; Thu, 6 Apr 2017 18:03:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 274CBC04B951 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 274CBC04B951 Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 54E6F7EF6C; Thu, 6 Apr 2017 18:03:47 +0000 (UTC) From: Hubert Kario To: Anna Johnston Cc: Peter Gutmann , Mark Baushke , Kyle Rose , Ilari Liusvaara , "curdle@ietf.org" , "Salz, Rich" , Tero Kivinen Date: Thu, 06 Apr 2017 20:03:37 +0200 Message-ID: <1788606.qOqSWdbvFW@pintsize.usersys.redhat.com> In-Reply-To: References: <6604004.EhiNI3UWHj@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2731207.zM2xxzzb89"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 06 Apr 2017 18:03:48 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 18:03:59 -0000 --nextPart2731207.zM2xxzzb89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 6 April 2017 19:38:23 CEST Anna Johnston wrote: > Perhaps it would be wise to provide documentation on what is in the > certificate and how it is used to verify primality? That way =E2=80=98tr= ust me=E2=80=99 > can be verified mathematically. =20 It is. If you download the archive, there's a primo.html file inside. In th= at=20 file there is a "What is a primality certificate?" section that explains it. We will Real Soon Now=E2=84=A2 release a pure python verifier for the Primo= =20 certificates (in version 4 format). (if somebody wants it now, I can provide it to them, but the code has horri= ble=20 usability currently - it's basically a prototype). > Anna >=20 > -----Original Message----- > From: Hubert Kario > Date: Thursday, April 6, 2017 at 6:23 AM > To: Peter Gutmann > Cc: "Mark D. Baushke" , Kyle Rose , Ila= ri > Liusvaara , Anna Johnston , > "curdle@ietf.org" , "Salz, Rich" , Tero > Kivinen > Subject: Re: [Curdle] > draft-ietf-curdle-ssh-modp-dh-sha2 >=20 > On Thursday, 6 April 2017 14:58:55 CEST Peter Gutmann wrote: >=20 > > Mark D. Baushke writes: > >=20 > > >I don't think we know how effective Nothing Up My Sleeve (NUMS) > > >techniques > > >will be in the long run. > >=20 > >=20 > > Then there's the question of how you generate them. I'd prefer > > something > > that can be coded up relatively easily in your bignum library of > > choice, so > > that anybody can verify, using something they've built > > themselves, that things are kosher. It's been pointed out that > > https://kivinen.iki.fi/primes/ contains primality proofs, but what = it > > really contains is a huge amount of text that doesn't mean anything > > to > > anyone who isn't intimately familiar with the tool used. This isn't > > in any > > way meant as a criticism of Tero, but more to point out that > > saying "here is a large amount of incomprehensible machine-generated > > text, trust me, the primes are OK" reduces directly to "trust me, t= he > > primes are OK". Since most people won't be able to make head or ta= il > > of what's on that page, the result ends up as "trust me" again. >=20 > =20 > That how _all of cryptography_ works. > =20 > Either you understand enough of the maths to follow along or you > delegate it=20 > to others and trust them. > =20 >=20 > > Extending this further, if I wanted to replicate the results on that > > web > > page, I'd end up on http://www.ellipsa.eu/public/primo/primo.html, = an > > HTTP > > (non- HTTPS) web page with an unsigned, unauthenticated 7z file > > containing > > a binary blob that I'm expected to download and run on a 64-bit Lin= ux > > box > > to verify that my precious crypto parameters aren't backdoored. > >=20 > > So, how many people can see the problem here? >=20 > =20 > the point of generating primality certificates is that you don't care > where=20 > they come from, either you can verify them and then you know that > the number tested is prime or you can't verify it and the number is likely > not a prime (or the certificate is bogus) > =20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Repub= lic >=20 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2731207.zM2xxzzb89 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY5oL5AAoJEJKo0bgB0vX1iF4QAJbnV9D2SjERgxN1ZO2syrnj ENyozRhx4hdatFbp0dWoSr+srZHOl5qKaQ0JHFPPux4ey5T3yOcmNef/533j5a54 RbwQk0M8epz6BXVpD9pm0RjGrso1qzt8G2arWkLaDSYbjhxMc6K1qHf1nCuIvOwz 4lOLKKRx97otWKEARJb7EGjSgFMQ2LkJXTK0ELTiU5M2LETlfJEj0fTtZQwrK5rR k6oopzzLRRtMcSRc4wF0EirdYHUxB+Q2TESomvIIlbTZsAX0KiIB6GWxFMUHMmjs KHO7l2yEbVCKMjfJfzbLpDR8F9pPTkUSZYC7em07I78SMh+AAy7daedZknQ+Xn+J ackhb/ww/8/RPDoW8rC8QV5ZTWURY3RZBbUGo/3C5gwew+GdRzGeNXmIrYqa4nKc HUAjGvcskdCDRa2Wt6Q8Dvgiuk5xkJFb0oz7iET9b3wtU3fdASAiEkgFXmkltlR4 BUs9ELf3zEikB0ob3y7+I3mB47MA1ZnKXho7Tha+FUh6I8eN/YzJ3/nlkuQLq9zA esuFPCKTPJ6vPXOrj3UUpgzOW2wjK3QzzenIv3xK4bQWrMn7gRGCniI4u8+b+kDG fNObpaA+YiWJZJQe2PCBRT4Qwkr/TqCVEudL+x32WFCWCSRdcVZJvhV1EjP0AJlr 3v9JgbqqKE9R4sgE7SJ2 =94sD -----END PGP SIGNATURE----- --nextPart2731207.zM2xxzzb89-- From nobody Thu Apr 6 11:21: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 CF67012426E for ; Thu, 6 Apr 2017 11:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1b7lGKF2Dro for ; Thu, 6 Apr 2017 11:21:32 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0126.outbound.protection.outlook.com [104.47.41.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F5F126BFD for ; Thu, 6 Apr 2017 11:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=btIX8XZhJHaOZKBQRS9/BGYtffCdbwO2Wqk1tG0lifo=; b=JT77bbMQrY9C/mRJCPGGlwmmtd6M2h4CNavJhCPUVU8dZkU4kcX/lAXGu+as0VIxD+eJUhPjh6V++V/MKubwSWDVGA4k4VQFgkTUCJIeEqQD2JzUkx9F/qYaIR4wUX2L4b6ZA5Cv/iqNramHkJE0DkY+Q7kr4lSLDLZ+VBtHKjQ= Received: from CO2PR0501MB1032.namprd05.prod.outlook.com (10.160.7.143) by DM2PR05MB704.namprd05.prod.outlook.com (10.141.177.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 18:21:30 +0000 Received: from CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) by CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) with mapi id 15.01.1019.019; Thu, 6 Apr 2017 18:21:30 +0000 From: Anna Johnston To: Hubert Kario CC: Peter Gutmann , Mark Baushke , Kyle Rose , Ilari Liusvaara , "curdle@ietf.org" , "Salz, Rich" , "Tero Kivinen" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKNq8oLudfhpKUOh06KCX76vZaGrvzmAgACdpYD//7XDgIABeAuAgAFZ24D//+2rAIAErFsAgAA8tACAAC38gIAABVUAgAABYICAABI9BYAEV6KAgAAG5ID//9HYgAAPjMqA//+PpYA= Date: Thu, 6 Apr 2017 18:21:30 +0000 Message-ID: References: <6604004.EhiNI3UWHj@pintsize.usersys.redhat.com> <1788606.qOqSWdbvFW@pintsize.usersys.redhat.com> In-Reply-To: <1788606.qOqSWdbvFW@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; DM2PR05MB704; 7:fHe0OWSMfdAaLNT/8gzdURSElOGRaHLQlXDrKcqNArySVaq1amlscYBQ7nir+EYY6vU/VnuiSHIoBgBhgFQLBUO8cM0bETAbAU43Ol5SUt+2IuQi4Pzvebv+uosb7neVx5c9LHQVJ1qe+GiDOgY2TG8REszMlRoG/3e3I7hikypnafIDh2/i/1gQSrUjvPcgxKTUIBl2RKGxFok53WPS4bIlDur+PFsLK8UTFbOlMiBYkyNmDkfXrmPK6KyoDCFiZY7i/ZxtmeshWyo9nR+JEUHTqihUr+81I2iOPeGC4HYWAP6NCdCml24SMSBE/SJ7vA0XDmEv7LWvji/VqyrudQ== x-ms-office365-filtering-correlation-id: 816ac96a-5938-40dc-6138-08d47d19bf95 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR05MB704; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148); SRVR:DM2PR05MB704; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB704; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(39400400002)(377454003)(24454002)(53546009)(25786009)(4326008)(189998001)(2900100001)(3660700001)(54356999)(50986999)(2950100002)(33656002)(6916009)(76176999)(66066001)(2906002)(38730400002)(110136004)(3280700002)(8676002)(93886004)(8936002)(5660300001)(81166006)(36756003)(6246003)(230783001)(102836003)(3846002)(6116002)(122556002)(7736002)(305945005)(15974865002)(6436002)(6486002)(86362001)(77096006)(53936002)(6306002)(54906002)(99286003)(6512007)(229853002)(966004)(6506006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB704; H:CO2PR0501MB1032.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <359B0A9FFDFB0545A29750C8BEEBB96F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 18:21:30.7064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB704 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 18:21:36 -0000 QWxsIHRoZSBwcmltZXMgaW4gdGhlIGxpc3QgYXJlIHNhZmUuICBUaGUgY2VydGlmaWNhdGVzIGFy ZSBiYXNlZCBvZmYgZWxsaXB0aWMgY3VydmUgdGVzdGluZywgYSB2YXJpYW50IG9mIFBvY2tsaW5n dG9u4oCZcyB3aGljaCBPTkxZIG1ha2VzIHNlbnNlIHRvIHVzZSBpZiB5b3UgZG9u4oCZdCBrbm93 IHRoZSBjb21wbGV0ZSBmYWN0b3JpemF0aW9uIG9mIGF0IGxlYXN0IMK9IHRoZSBiaXRzIG9mIChQ LTEpLiAgV2h5IG5vdCByZXBsYWNlIHRoZXNlIHdpdGggbXVjaCBlYXNpZXIgdG8gdmVyaWZ5IFBv Y2tsaW5ndG9uIGNlcnRpZmljYXRlcz8gIFRoaXMgd291bGQgYWxzbyBndWFyYW50ZWUsIGF0IG5v IGV4dHJhIGNvc3QsIGFuIGVsZW1lbnQgb2Ygb3JkZXIgcS4NCg0KQS4gSm9obnN0b24NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEh1YmVydCBLYXJpbyA8aGthcmlvQHJlZGhh dC5jb20+DQpEYXRlOiBUaHVyc2RheSwgQXByaWwgNiwgMjAxNyBhdCAxMTowMyBBTQ0KVG86IEFu bmEgSm9obnN0b24gPGFtakBqdW5pcGVyLm5ldD4NCkNjOiBQZXRlciBHdXRtYW5uIDxwZ3V0MDAx QGNzLmF1Y2tsYW5kLmFjLm56PiwgTWFyayBCYXVzaGtlIDxtZGJAanVuaXBlci5uZXQ+LCBLeWxl IFJvc2UgPGtyb3NlQGtyb3NlLm9yZz4sIElsYXJpIExpdXN2YWFyYSA8aWxhcmlsaXVzdmFhcmFA d2VsaG8uY29tPiwgImN1cmRsZUBpZXRmLm9yZyIgPGN1cmRsZUBpZXRmLm9yZz4sICJTYWx6LCBS aWNoIiA8cnNhbHpAYWthbWFpLmNvbT4sIFRlcm8gS2l2aW5lbiA8a2l2aW5lbkBpa2kuZmk+DQpT dWJqZWN0OiBSZTogW0N1cmRsZV0gZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLW1vZHAtZGgtc2hhMg0K DQogICAgT24gVGh1cnNkYXksIDYgQXByaWwgMjAxNyAxOTozODoyMyBDRVNUIEFubmEgSm9obnN0 b24gd3JvdGU6DQogICAgPiBQZXJoYXBzIGl0IHdvdWxkIGJlIHdpc2UgdG8gcHJvdmlkZSBkb2N1 bWVudGF0aW9uIG9uIHdoYXQgaXMgaW4gdGhlDQogICAgPiBjZXJ0aWZpY2F0ZSBhbmQgaG93IGl0 IGlzIHVzZWQgdG8gdmVyaWZ5IHByaW1hbGl0eT8gIFRoYXQgd2F5IOKAmHRydXN0IG1l4oCZDQog ICAgPiBjYW4gYmUgdmVyaWZpZWQgbWF0aGVtYXRpY2FsbHkuICANCiAgICANCiAgICBJdCBpcy4g SWYgeW91IGRvd25sb2FkIHRoZSBhcmNoaXZlLCB0aGVyZSdzIGEgcHJpbW8uaHRtbCBmaWxlIGlu c2lkZS4gSW4gdGhhdCANCiAgICBmaWxlIHRoZXJlIGlzIGEgIldoYXQgaXMgYSBwcmltYWxpdHkg Y2VydGlmaWNhdGU/IiBzZWN0aW9uIHRoYXQgZXhwbGFpbnMgaXQuDQogICAgDQogICAgV2Ugd2ls bCBSZWFsIFNvb24gTm934oSiIHJlbGVhc2UgYSBwdXJlIHB5dGhvbiB2ZXJpZmllciBmb3IgdGhl IFByaW1vIA0KICAgIGNlcnRpZmljYXRlcyAoaW4gdmVyc2lvbiA0IGZvcm1hdCkuDQogICAgDQog ICAgKGlmIHNvbWVib2R5IHdhbnRzIGl0IG5vdywgSSBjYW4gcHJvdmlkZSBpdCB0byB0aGVtLCBi dXQgdGhlIGNvZGUgaGFzIGhvcnJpYmxlIA0KICAgIHVzYWJpbGl0eSBjdXJyZW50bHkgLSBpdCdz IGJhc2ljYWxseSBhIHByb3RvdHlwZSkuDQogICAgDQogICAgPiBBbm5hDQogICAgPiANCiAgICA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBIdWJlcnQgS2FyaW8gPGhr YXJpb0ByZWRoYXQuY29tPg0KICAgID4gRGF0ZTogVGh1cnNkYXksIEFwcmlsIDYsIDIwMTcgYXQg NjoyMyBBTQ0KICAgID4gVG86IFBldGVyIEd1dG1hbm4gPHBndXQwMDFAY3MuYXVja2xhbmQuYWMu bno+DQogICAgPiBDYzogIk1hcmsgRC4gQmF1c2hrZSIgPG1kYkBqdW5pcGVyLm5ldD4sIEt5bGUg Um9zZSA8a3Jvc2VAa3Jvc2Uub3JnPiwgSWxhcmkNCiAgICA+IExpdXN2YWFyYSA8aWxhcmlsaXVz dmFhcmFAd2VsaG8uY29tPiwgQW5uYSBKb2huc3RvbiA8YW1qQGp1bmlwZXIubmV0PiwNCiAgICA+ ICJjdXJkbGVAaWV0Zi5vcmciIDxjdXJkbGVAaWV0Zi5vcmc+LCAiU2FseiwgUmljaCIgPHJzYWx6 QGFrYW1haS5jb20+LCBUZXJvDQogICAgPiBLaXZpbmVuIDxraXZpbmVuQGlraS5maT4NCiAgICA+ IFN1YmplY3Q6IFJlOiBbQ3VyZGxlXQ0KICAgID4gZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLW1vZHAt ZGgtc2hhMg0KICAgID4gDQogICAgPiAgICAgT24gVGh1cnNkYXksIDYgQXByaWwgMjAxNyAxNDo1 ODo1NSBDRVNUIFBldGVyIEd1dG1hbm4gd3JvdGU6DQogICAgPiANCiAgICA+ICAgICA+IE1hcmsg RC4gQmF1c2hrZSA8bWRiQGp1bmlwZXIubmV0PiB3cml0ZXM6DQogICAgPiAgICAgPiANCiAgICA+ ICAgICA+ID5JIGRvbid0IHRoaW5rIHdlIGtub3cgaG93IGVmZmVjdGl2ZSBOb3RoaW5nIFVwIE15 IFNsZWV2ZSAoTlVNUykNCiAgICA+ICAgICA+ID50ZWNobmlxdWVzDQogICAgPiAgICAgPiA+d2ls bCBiZSBpbiB0aGUgbG9uZyBydW4uDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IA0KICAgID4g ICAgID4gVGhlbiB0aGVyZSdzIHRoZSBxdWVzdGlvbiBvZiBob3cgeW91IGdlbmVyYXRlIHRoZW0u ICBJJ2QgcHJlZmVyDQogICAgPiAgICAgPiBzb21ldGhpbmcNCiAgICA+ICAgICA+IHRoYXQgY2Fu IGJlIGNvZGVkIHVwIHJlbGF0aXZlbHkgZWFzaWx5IGluIHlvdXIgYmlnbnVtIGxpYnJhcnkgb2YN CiAgICA+ICAgICA+IGNob2ljZSwgc28NCiAgICA+ICAgICA+IHRoYXQgYW55Ym9keSBjYW4gdmVy aWZ5LCB1c2luZyBzb21ldGhpbmcgdGhleSd2ZSBidWlsdA0KICAgID4gICAgID4gdGhlbXNlbHZl cywgdGhhdCB0aGluZ3MgYXJlIGtvc2hlci4gIEl0J3MgYmVlbiBwb2ludGVkIG91dCB0aGF0DQog ICAgPiAgICAgPiBodHRwczovL2tpdmluZW4uaWtpLmZpL3ByaW1lcy8gY29udGFpbnMgcHJpbWFs aXR5IHByb29mcywgYnV0IHdoYXQgaXQNCiAgICA+ICAgICA+IHJlYWxseSBjb250YWlucyBpcyBh IGh1Z2UgYW1vdW50IG9mIHRleHQgdGhhdCBkb2Vzbid0IG1lYW4gYW55dGhpbmcNCiAgICA+ICAg ICA+IHRvDQogICAgPiAgICAgPiBhbnlvbmUgd2hvIGlzbid0IGludGltYXRlbHkgZmFtaWxpYXIg d2l0aCB0aGUgdG9vbCB1c2VkLiAgVGhpcyBpc24ndA0KICAgID4gICAgID4gaW4gYW55DQogICAg PiAgICAgPiB3YXkgbWVhbnQgYXMgYSBjcml0aWNpc20gb2YgVGVybywgYnV0IG1vcmUgdG8gcG9p bnQgb3V0IHRoYXQNCiAgICA+ICAgICA+IHNheWluZyAiaGVyZSBpcyBhIGxhcmdlIGFtb3VudCBv ZiBpbmNvbXByZWhlbnNpYmxlIG1hY2hpbmUtZ2VuZXJhdGVkDQogICAgPiAgICAgPiB0ZXh0LCB0 cnVzdCBtZSwgdGhlIHByaW1lcyBhcmUgT0siIHJlZHVjZXMgZGlyZWN0bHkgdG8gInRydXN0IG1l LCB0aGUNCiAgICA+ICAgICA+IHByaW1lcyBhcmUgT0siLiAgU2luY2UgbW9zdCBwZW9wbGUgd29u J3QgYmUgYWJsZSB0byBtYWtlIGhlYWQgb3IgdGFpbA0KICAgID4gICAgID4gb2Ygd2hhdCdzIG9u IHRoYXQgcGFnZSwgdGhlIHJlc3VsdCBlbmRzIHVwIGFzICJ0cnVzdCBtZSIgYWdhaW4uDQogICAg PiANCiAgICA+ICAgICANCiAgICA+ICAgICBUaGF0IGhvdyBfYWxsIG9mIGNyeXB0b2dyYXBoeV8g d29ya3MuDQogICAgPiAgICAgDQogICAgPiAgICAgRWl0aGVyIHlvdSB1bmRlcnN0YW5kIGVub3Vn aCBvZiB0aGUgbWF0aHMgdG8gZm9sbG93IGFsb25nIG9yIHlvdQ0KICAgID4gZGVsZWdhdGUgaXQg DQogICAgPiB0byBvdGhlcnMgYW5kIHRydXN0IHRoZW0uDQogICAgPiAgICAgIA0KICAgID4gDQog ICAgPiAgICAgPiBFeHRlbmRpbmcgdGhpcyBmdXJ0aGVyLCBpZiBJIHdhbnRlZCB0byByZXBsaWNh dGUgdGhlIHJlc3VsdHMgb24gdGhhdA0KICAgID4gICAgID4gd2ViDQogICAgPiAgICAgPiBwYWdl LCBJJ2QgZW5kIHVwIG9uIGh0dHA6Ly93d3cuZWxsaXBzYS5ldS9wdWJsaWMvcHJpbW8vcHJpbW8u aHRtbCwgYW4NCiAgICA+ICAgICA+IEhUVFANCiAgICA+ICAgICA+IChub24tIEhUVFBTKSB3ZWIg cGFnZSB3aXRoIGFuIHVuc2lnbmVkLCB1bmF1dGhlbnRpY2F0ZWQgN3ogZmlsZQ0KICAgID4gICAg ID4gY29udGFpbmluZw0KICAgID4gICAgID4gYSBiaW5hcnkgYmxvYiB0aGF0IEknbSBleHBlY3Rl ZCB0byBkb3dubG9hZCBhbmQgcnVuIG9uIGEgNjQtYml0IExpbnV4DQogICAgPiAgICAgPiBib3gN CiAgICA+ICAgICA+IHRvIHZlcmlmeSB0aGF0IG15IHByZWNpb3VzIGNyeXB0byBwYXJhbWV0ZXJz IGFyZW4ndCBiYWNrZG9vcmVkLg0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBTbywgaG93IG1h bnkgcGVvcGxlIGNhbiBzZWUgdGhlIHByb2JsZW0gaGVyZT8NCiAgICA+IA0KICAgID4gICAgIA0K ICAgID4gICAgIHRoZSBwb2ludCBvZiBnZW5lcmF0aW5nIHByaW1hbGl0eSBjZXJ0aWZpY2F0ZXMg aXMgdGhhdCB5b3UgZG9uJ3QgY2FyZQ0KICAgID4gd2hlcmUgDQogICAgPiB0aGV5IGNvbWUgZnJv bSwgZWl0aGVyIHlvdSBjYW4gdmVyaWZ5IHRoZW0gYW5kIHRoZW4geW91IGtub3cgdGhhdA0KICAg ID4gdGhlIG51bWJlciB0ZXN0ZWQgaXMgcHJpbWUgb3IgeW91IGNhbid0IHZlcmlmeSBpdCBhbmQg dGhlIG51bWJlciBpcyBsaWtlbHkNCiAgICA+IG5vdCBhIHByaW1lIChvciB0aGUgY2VydGlmaWNh dGUgaXMgYm9ndXMpDQogICAgPiAgICAgDQogICAgPiAgICAgLS0gDQogICAgPiAgICAgUmVnYXJk cywNCiAgICA+ICAgICBIdWJlcnQgS2FyaW8NCiAgICA+ICAgICBTZW5pb3IgUXVhbGl0eSBFbmdp bmVlciwgUUUgQmFzZU9TIFNlY3VyaXR5IHRlYW0NCiAgICA+ICAgICBXZWI6IHd3dy5jei5yZWRo YXQuY29tDQogICAgPiAgICAgUmVkIEhhdCBDemVjaCBzLnIuby4sIFB1cmt5xYhvdmEgOTkvNzEs IDYxMiA0NSwgQnJubywgQ3plY2ggUmVwdWJsaWMNCiAgICA+IA0KICAgIA0KICAgIA0KICAgIC0t IA0KICAgIFJlZ2FyZHMsDQogICAgSHViZXJ0IEthcmlvDQogICAgU2VuaW9yIFF1YWxpdHkgRW5n aW5lZXIsIFFFIEJhc2VPUyBTZWN1cml0eSB0ZWFtDQogICAgV2ViOiB3d3cuY3oucmVkaGF0LmNv bQ0KICAgIFJlZCBIYXQgQ3plY2ggcy5yLm8uLCBQdXJrecWIb3ZhIDk5LzcxLCA2MTIgNDUsIEJy bm8sIEN6ZWNoIFJlcHVibGljDQoNCg== From nobody Thu Apr 6 11:32: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 44957129408 for ; Thu, 6 Apr 2017 11:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWwrMiQJkNAM for ; Thu, 6 Apr 2017 11:32:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1697129546 for ; Thu, 6 Apr 2017 11:32:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 56AB5C04BD43; Thu, 6 Apr 2017 18:32:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 56AB5C04BD43 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 56AB5C04BD43 Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 97F9717B8F; Thu, 6 Apr 2017 18:32:16 +0000 (UTC) From: Hubert Kario To: Anna Johnston Cc: Peter Gutmann , Mark Baushke , Kyle Rose , Ilari Liusvaara , "curdle@ietf.org" , "Salz, Rich" , Tero Kivinen Date: Thu, 06 Apr 2017 20:32:14 +0200 Message-ID: <4253810.u6Ox2pht7m@pintsize.usersys.redhat.com> In-Reply-To: References: <1788606.qOqSWdbvFW@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2271235.I6VGkJPuV5"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 06 Apr 2017 18:32:17 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 18:32:28 -0000 --nextPart2271235.I6VGkJPuV5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 6 April 2017 20:21:30 CEST Anna Johnston wrote: > All the primes in the list are safe. The certificates are based off > elliptic curve testing, a variant of Pocklington=E2=80=99s which ONLY mak= es sense > to use if you don=E2=80=99t know the complete factorization of at least = =C2=BD the bits > of (P-1). Why not replace these with much easier to verify Pocklington > certificates? This would also guarantee, at no extra cost, an element of > order q. but for Pocklington to work, we need to be certain that q is prime, don't w= e? > A. Johnston >=20 > -----Original Message----- > From: Hubert Kario > Date: Thursday, April 6, 2017 at 11:03 AM > To: Anna Johnston > Cc: Peter Gutmann , Mark Baushke > , Kyle Rose , Ilari Liusvaara > , "curdle@ietf.org" , "Salz, > Rich" , Tero Kivinen > Subject: Re: > [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 >=20 > On Thursday, 6 April 2017 19:38:23 CEST Anna Johnston wrote: >=20 > > Perhaps it would be wise to provide documentation on what is in the > > certificate and how it is used to verify primality? That way =E2= =80=98trust > > me=E2=80=99 > > can be verified mathematically. =20 >=20 > =20 > It is. If you download the archive, there's a primo.html file inside.= In > that=20 > file there is a "What is a primality certificate?" section that > explains it.=20 > We will Real Soon Now=E2=84=A2 release a pure python verifier for the= Primo=20 > certificates (in version 4 format). > =20 > (if somebody wants it now, I can provide it to them, but the code has > horrible=20 > usability currently - it's basically a prototype). > =20 >=20 > > Anna > >=20 > > -----Original Message----- > > From: Hubert Kario > > Date: Thursday, April 6, 2017 at 6:23 AM > > To: Peter Gutmann > > Cc: "Mark D. Baushke" , Kyle Rose , > > Ilari > Liusvaara , Anna Johnston > > , "curdle@ietf.org" , "Salz, Rich" > > , Tero Kivinen > > Subject: Re: [Curdle] > > draft-ietf-curdle-ssh-modp-dh-sha2 > >=20 > >=20 > > On Thursday, 6 April 2017 14:58:55 CEST Peter Gutmann wrote: > >=20 > >=20 > >=20 > > > Mark D. Baushke writes: > > >=20 > > >=20 > > > >I don't think we know how effective Nothing Up My Sleeve > > > >(NUMS) > > > >techniques > > > >will be in the long run. > > >=20 > > >=20 > > >=20 > > > Then there's the question of how you generate them. I'd pref= er > > > something > > > that can be coded up relatively easily in your bignum library > > > of > > > choice, so > > > that anybody can verify, using something they've built > > > themselves, that things are kosher. It's been pointed out th= at > > > https://kivinen.iki.fi/primes/ contains primality proofs, but > > > what it > > > really contains is a huge amount of text that doesn't mean > > > anything > > > to > > > anyone who isn't intimately familiar with the tool used. This > > > isn't > > > in any > > > way meant as a criticism of Tero, but more to point out that > > > saying "here is a large amount of incomprehensible > > > machine-generated > > > text, trust me, the primes are OK" reduces directly to "trust > > > me, the > > > primes are OK". Since most people won't be able to make head= or > > > tail > > > of what's on that page, the result ends up as "trust me" agai= n. > >=20 > >=20 > >=20 > > =20 > > That how _all of cryptography_ works. > > =20 > > Either you understand enough of the maths to follow along or you > >=20 > > delegate it=20 > > to others and trust them. > >=20 > > =20 > >=20 > >=20 > >=20 > > > Extending this further, if I wanted to replicate the results = on > > > that > > > web > > > page, I'd end up on > > > http://www.ellipsa.eu/public/primo/primo.html, an > > > HTTP > > > (non- HTTPS) web page with an unsigned, unauthenticated 7z fi= le > > > containing > > > a binary blob that I'm expected to download and run on a 64-b= it > > > Linux > > > box > > > to verify that my precious crypto parameters aren't backdoore= d. > > >=20 > > > So, how many people can see the problem here? > >=20 > >=20 > >=20 > > =20 > > the point of generating primality certificates is that you don't > > care > >=20 > > where=20 > > they come from, either you can verify them and then you know that > > the number tested is prime or you can't verify it and the number is > > likely > > not a prime (or the certificate is bogus) > >=20 > > =20 > > --=20 > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech > > Republic > >=20 > >=20 >=20 > =20 > =20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Repub= lic >=20 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2271235.I6VGkJPuV5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY5omuAAoJEJKo0bgB0vX1mHIQAJ2DSUCqsTRVzo2p3CEq818q 5JN2l6DmHHBfEKIwaFpNT139Re7SXQNFL4PeBoZa6vUYye2idHtCu8R2gN/03nkM o7hjlj9sK3EVeujP2L2zsq+vjeaQGHGtzbiraU0HxqbUrGiG8RKzjImneFC5iTaS TD8zOUmcE6W1vQpBhJtotHPJbDblzjEy3IQRjROUcuVCYXEHK1a0PDROMqEIVrVh VauiV3QJmlx1VgpUpbmc4nZl2nUt175ZC05cFwnPJ38WDFLfTHgw+rpTtrmG+Yiv n4FK/nbV0Mf+LEMh/aiQYTKmxqyejVnxoBo9MGRP8a6mAU/7eng+c7FaR8y8OCRw OQ9a4ltzZAppmlaYo/Zy/nYMH9wYa/VI+moL3yPJW4p9tAB3tbWtF3zXkWBb29Vy BydjXUwjvPuaqx33KcYW4YKVSo5Nwu8uH/kOsGEqXUDRDeUqRIOa/RC8YBAQ0JYY CqAhCoqPR7pFAyF7Mqybi2sVP2p+2SiZjMxVrWYrmpEIKWlOuI2F7ltR2v1xTNW7 N2ujHWiDCy20anb+TQqSuDdODivezMcbdKz4ooBrestaQ1m4WFYPgYV6LVYw0I0e kRLKV9CTmaNZkl69M+z1WliUKrJwyWYKdTN/lc/BwaPY6M+U9akR0ho+4qIOMejK Td55q5kEgdz4pFKT4aeg =24g/ -----END PGP SIGNATURE----- --nextPart2271235.I6VGkJPuV5-- From nobody Thu Apr 6 11:45: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 4B40A129570 for ; Thu, 6 Apr 2017 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgvLM0XYTCyg for ; Thu, 6 Apr 2017 11:45:46 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0127.outbound.protection.outlook.com [104.47.33.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 4C0CF12741D for ; Thu, 6 Apr 2017 11:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dHx5wwC5mBp8OFbULB0V1ML9lMYg0NixiuTXvX0dIJM=; b=CxCMRe+BPbSKryhWERmN6XzCfsFN9yzTToohwdJdVzfQdGQ7rKALu29QlYWdWoo3gzkC3xmx0+ilCK6Yk+Utjm4D1NhxT+1JgmOdXRdYk8PXaLI4oXwyK+mRlPaVRwzqjPr+70Rk94nig9//9ltCiKka/HIiYxJpN5v9GEcOVq4= Received: from CO2PR0501MB1032.namprd05.prod.outlook.com (10.160.7.143) by CO2PR05MB697.namprd05.prod.outlook.com (10.141.229.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 18:45:42 +0000 Received: from CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) by CO2PR0501MB1032.namprd05.prod.outlook.com ([10.160.7.143]) with mapi id 15.01.1019.019; Thu, 6 Apr 2017 18:45:42 +0000 From: Anna Johnston To: Hubert Kario CC: Peter Gutmann , Mark Baushke , Kyle Rose , Ilari Liusvaara , "curdle@ietf.org" , "Salz, Rich" , "Tero Kivinen" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKNq8oLudfhpKUOh06KCX76vZaGrvzmAgACdpYD//7XDgIABeAuAgAFZ24D//+2rAIAErFsAgAA8tACAAC38gIAABVUAgAABYICAABI9BYAEV6KAgAAG5ID//9HYgAAPjMqA//+PpYCAAHhZAP//jmqA Date: Thu, 6 Apr 2017 18:45:42 +0000 Message-ID: <9D44228F-011F-44EF-81EC-FFECD9F9C8BB@juniper.net> References: <1788606.qOqSWdbvFW@pintsize.usersys.redhat.com> <4253810.u6Ox2pht7m@pintsize.usersys.redhat.com> In-Reply-To: <4253810.u6Ox2pht7m@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: redhat.com; dkim=none (message not signed) header.d=none;redhat.com; dmarc=none action=none header.from=juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.11] x-microsoft-exchange-diagnostics: 1; CO2PR05MB697; 7:3J9cSBNTmoF+THL+i6PyajaAv1Zsx4RgnrKpSSHkKqp0KdVGk6rzpPw3qVzYyrxW0HnfTRSBJgr/Ug48GsRck5XF+gu3dwHaBa+Gyp+5E7cQFp/34KCnnfcMHn/Q/sfrka8jV2sZZil+PCoOBHW0f0Cjrz7isc6sNqxw3UcP3VeN6/6/uZT4bct7d0aFNCu5v0eGFHMnTGQSkfq7oX20RQguDPCa7yvVgZYcujSnJe2pUBFwrRWerMjeWOzr+LHesw+AxsYnHXD7NBDxtMEdqYMKiLaDJmllNzJnifIZc6MxXyuAgZE4prYDM7NnErWAUc619C++bcw9/7MuJTVFTA== x-ms-office365-filtering-correlation-id: 86dbaab2-fcc9-4a3d-448e-08d47d1d2101 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:CO2PR05MB697; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(138986009662008)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:CO2PR05MB697; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB697; x-forefront-prvs: 02698DF457 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39840400002)(39860400002)(39450400003)(52314003)(377454003)(24454002)(13464003)(53936002)(6512007)(6436002)(3660700001)(54906002)(110136004)(99286003)(4326008)(6306002)(25786009)(38730400002)(7736002)(2906002)(966004)(53546009)(77096006)(6506006)(6486002)(305945005)(82746002)(2900100001)(81166006)(93886004)(8936002)(230783001)(6916009)(8676002)(229853002)(2950100002)(5660300001)(83716003)(15974865002)(36756003)(122556002)(189998001)(86362001)(66066001)(76176999)(54356999)(50986999)(6116002)(102836003)(3846002)(33656002)(3280700002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB697; H:CO2PR0501MB1032.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2017 18:45:42.4515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB697 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Thu, 06 Apr 2017 18:45:49 -0000 WWVzLCBidXQgYW5vdGhlciBwcmltYWxpdHkgcHJvb2Ygb2YgdGhlIHNhbWUgc2l6ZSBpcyBhbHNv IHJlcXVpcmVkIGZvciBFQyBwcmltYWxpdHkgdGVzdGluZy4gIEVDIHByaW1hbGl0eSB0ZXN0aW5n IGlzIHNpbWlsYXIgdG8gUG9ja2xpbmd0b27igJlzIOKAkyBpdCBqdXN0IGdvZXMgYXJvdW5kIHRo ZSBwcm9ibGVtIG9mIHBhcnRpYWxseSBmYWN0b3JpbmcgKFAtMSkgYnkgbW92aW5nIHRvIGFuIEVD IGdyb3VwIGFuZCBwYXJ0aWFsbHkgZmFjdG9yaW5nIHRoZSBvcmRlciBvZiB0aGUgZ3JvdXAgKH4g c2FtZSBzaXplIGFzIHByaW1lKSwgYW5kIHByb3ZpbmcgdGhhdCB0aG9zZSBmYWN0b3JzIGFyZSBw cmltZS4gIFNpbmNlIHlvdeKAmXJlIGdvaW5nIHRvIG5lZWQgdG8gcHJvdmUgdGhhdCAocC0xKS8y IGlzIHByaW1lIGFueXdheSwgaXTigJlzIGEgaHVnZSB3YXN0ZSBvZiByZXNvdXJjZXMgYW5kIGFk ZGluZyBhIGxvdCBtb3JlIGNvbXBsaWNhdGlvbiB0byBhIHNpbXBsZSB2YWxpZGF0aW9uIHRoYW4g aXMgbmVjZXNzYXJ5IHRvIHVzZSBFQy4NCg0KQS4gSm9obnN0b24NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEh1YmVydCBLYXJpbyA8aGthcmlvQHJlZGhhdC5jb20+DQpEYXRl OiBUaHVyc2RheSwgQXByaWwgNiwgMjAxNyBhdCAxMTozMiBBTQ0KVG86IEFubmEgSm9obnN0b24g PGFtakBqdW5pcGVyLm5ldD4NCkNjOiBQZXRlciBHdXRtYW5uIDxwZ3V0MDAxQGNzLmF1Y2tsYW5k LmFjLm56PiwgTWFyayBCYXVzaGtlIDxtZGJAanVuaXBlci5uZXQ+LCBLeWxlIFJvc2UgPGtyb3Nl QGtyb3NlLm9yZz4sIElsYXJpIExpdXN2YWFyYSA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPiwg ImN1cmRsZUBpZXRmLm9yZyIgPGN1cmRsZUBpZXRmLm9yZz4sICJTYWx6LCBSaWNoIiA8cnNhbHpA YWthbWFpLmNvbT4sIFRlcm8gS2l2aW5lbiA8a2l2aW5lbkBpa2kuZmk+DQpTdWJqZWN0OiBSZTog W0N1cmRsZV0gZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLW1vZHAtZGgtc2hhMg0KDQogICAgT24gVGh1 cnNkYXksIDYgQXByaWwgMjAxNyAyMDoyMTozMCBDRVNUIEFubmEgSm9obnN0b24gd3JvdGU6DQog ICAgPiBBbGwgdGhlIHByaW1lcyBpbiB0aGUgbGlzdCBhcmUgc2FmZS4gIFRoZSBjZXJ0aWZpY2F0 ZXMgYXJlIGJhc2VkIG9mZg0KICAgID4gZWxsaXB0aWMgY3VydmUgdGVzdGluZywgYSB2YXJpYW50 IG9mIFBvY2tsaW5ndG9u4oCZcyB3aGljaCBPTkxZIG1ha2VzIHNlbnNlDQogICAgPiB0byB1c2Ug aWYgeW91IGRvbuKAmXQga25vdyB0aGUgY29tcGxldGUgZmFjdG9yaXphdGlvbiBvZiBhdCBsZWFz dCDCvSB0aGUgYml0cw0KICAgID4gb2YgKFAtMSkuICBXaHkgbm90IHJlcGxhY2UgdGhlc2Ugd2l0 aCBtdWNoIGVhc2llciB0byB2ZXJpZnkgUG9ja2xpbmd0b24NCiAgICA+IGNlcnRpZmljYXRlcz8g IFRoaXMgd291bGQgYWxzbyBndWFyYW50ZWUsIGF0IG5vIGV4dHJhIGNvc3QsIGFuIGVsZW1lbnQg b2YNCiAgICA+IG9yZGVyIHEuDQogICAgDQogICAgYnV0IGZvciBQb2NrbGluZ3RvbiB0byB3b3Jr LCB3ZSBuZWVkIHRvIGJlIGNlcnRhaW4gdGhhdCBxIGlzIHByaW1lLCBkb24ndCB3ZT8NCiAgICAN CiAgICA+IEEuIEpvaG5zdG9uDQogICAgPiANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQogICAgPiBGcm9tOiBIdWJlcnQgS2FyaW8gPGhrYXJpb0ByZWRoYXQuY29tPg0KICAgID4g RGF0ZTogVGh1cnNkYXksIEFwcmlsIDYsIDIwMTcgYXQgMTE6MDMgQU0NCiAgICA+IFRvOiBBbm5h IEpvaG5zdG9uIDxhbWpAanVuaXBlci5uZXQ+DQogICAgPiBDYzogUGV0ZXIgR3V0bWFubiA8cGd1 dDAwMUBjcy5hdWNrbGFuZC5hYy5uej4sIE1hcmsgQmF1c2hrZQ0KICAgID4gPG1kYkBqdW5pcGVy Lm5ldD4sIEt5bGUgUm9zZSA8a3Jvc2VAa3Jvc2Uub3JnPiwgSWxhcmkgTGl1c3ZhYXJhDQogICAg PiA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPiwgImN1cmRsZUBpZXRmLm9yZyIgPGN1cmRsZUBp ZXRmLm9yZz4sICJTYWx6LA0KICAgID4gUmljaCIgPHJzYWx6QGFrYW1haS5jb20+LCBUZXJvIEtp dmluZW4gPGtpdmluZW5AaWtpLmZpPg0KICAgID4gIFN1YmplY3Q6IFJlOg0KICAgID4gW0N1cmRs ZV0gZHJhZnQtaWV0Zi1jdXJkbGUtc3NoLW1vZHAtZGgtc2hhMg0KICAgID4gDQogICAgPiAgICAg T24gVGh1cnNkYXksIDYgQXByaWwgMjAxNyAxOTozODoyMyBDRVNUIEFubmEgSm9obnN0b24gd3Jv dGU6DQogICAgPiANCiAgICA+ICAgICA+IFBlcmhhcHMgaXQgd291bGQgYmUgd2lzZSB0byBwcm92 aWRlIGRvY3VtZW50YXRpb24gb24gd2hhdCBpcyBpbiB0aGUNCiAgICA+ICAgICA+IGNlcnRpZmlj YXRlIGFuZCBob3cgaXQgaXMgdXNlZCB0byB2ZXJpZnkgcHJpbWFsaXR5PyAgVGhhdCB3YXkg4oCY dHJ1c3QNCiAgICA+ICAgICA+IG1l4oCZDQogICAgPiAgICAgPiBjYW4gYmUgdmVyaWZpZWQgbWF0 aGVtYXRpY2FsbHkuICANCiAgICA+IA0KICAgID4gICAgIA0KICAgID4gICAgIEl0IGlzLiBJZiB5 b3UgZG93bmxvYWQgdGhlIGFyY2hpdmUsIHRoZXJlJ3MgYSBwcmltby5odG1sIGZpbGUgaW5zaWRl LiBJbg0KICAgID4gdGhhdCANCiAgICA+IGZpbGUgdGhlcmUgaXMgYSAiV2hhdCBpcyBhIHByaW1h bGl0eSBjZXJ0aWZpY2F0ZT8iIHNlY3Rpb24gdGhhdA0KICAgID4gZXhwbGFpbnMgaXQuIA0KICAg ID4gICAgIFdlIHdpbGwgUmVhbCBTb29uIE5vd+KEoiByZWxlYXNlIGEgcHVyZSBweXRob24gdmVy aWZpZXIgZm9yIHRoZSBQcmltbyANCiAgICA+ICAgICBjZXJ0aWZpY2F0ZXMgKGluIHZlcnNpb24g NCBmb3JtYXQpLg0KICAgID4gICAgIA0KICAgID4gICAgIChpZiBzb21lYm9keSB3YW50cyBpdCBu b3csIEkgY2FuIHByb3ZpZGUgaXQgdG8gdGhlbSwgYnV0IHRoZSBjb2RlIGhhcw0KICAgID4gaG9y cmlibGUgDQogICAgPiB1c2FiaWxpdHkgY3VycmVudGx5IC0gaXQncyBiYXNpY2FsbHkgYSBwcm90 b3R5cGUpLg0KICAgID4gICAgIA0KICAgID4gDQogICAgPiAgICAgPiBBbm5hDQogICAgPiAgICAg PiANCiAgICA+ICAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiAgICAgPiBG cm9tOiBIdWJlcnQgS2FyaW8gPGhrYXJpb0ByZWRoYXQuY29tPg0KICAgID4gICAgID4gRGF0ZTog VGh1cnNkYXksIEFwcmlsIDYsIDIwMTcgYXQgNjoyMyBBTQ0KICAgID4gICAgID4gVG86IFBldGVy IEd1dG1hbm4gPHBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+DQogICAgPiAgICAgPiBDYzogIk1h cmsgRC4gQmF1c2hrZSIgPG1kYkBqdW5pcGVyLm5ldD4sIEt5bGUgUm9zZSA8a3Jvc2VAa3Jvc2Uu b3JnPiwNCiAgICA+ICAgICA+IElsYXJpDQogICAgPiBMaXVzdmFhcmEgPGlsYXJpbGl1c3ZhYXJh QHdlbGhvLmNvbT4sIEFubmEgSm9obnN0b24NCiAgICA+ICAgICA+IDxhbWpAanVuaXBlci5uZXQ+ LCAiY3VyZGxlQGlldGYub3JnIiA8Y3VyZGxlQGlldGYub3JnPiwgIlNhbHosIFJpY2giDQogICAg PiAgICAgPiA8cnNhbHpAYWthbWFpLmNvbT4sIFRlcm8gS2l2aW5lbiA8a2l2aW5lbkBpa2kuZmk+ DQogICAgPiAgICAgPiBTdWJqZWN0OiBSZTogW0N1cmRsZV0NCiAgICA+ICAgICA+IGRyYWZ0LWll dGYtY3VyZGxlLXNzaC1tb2RwLWRoLXNoYTINCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gDQog ICAgPiAgICAgPiAgICAgT24gVGh1cnNkYXksIDYgQXByaWwgMjAxNyAxNDo1ODo1NSBDRVNUIFBl dGVyIEd1dG1hbm4gd3JvdGU6DQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IA0KICAgID4gICAg ID4gDQogICAgPiAgICAgPiAgICAgPiBNYXJrIEQuIEJhdXNoa2UgPG1kYkBqdW5pcGVyLm5ldD4g d3JpdGVzOg0KICAgID4gICAgID4gICAgID4gDQogICAgPiAgICAgPiAgICAgPiANCiAgICA+ICAg ICA+ICAgICA+ID5JIGRvbid0IHRoaW5rIHdlIGtub3cgaG93IGVmZmVjdGl2ZSBOb3RoaW5nIFVw IE15IFNsZWV2ZQ0KICAgID4gICAgID4gICAgID4gPihOVU1TKQ0KICAgID4gICAgID4gICAgID4g PnRlY2huaXF1ZXMNCiAgICA+ICAgICA+ICAgICA+ID53aWxsIGJlIGluIHRoZSBsb25nIHJ1bi4N CiAgICA+ICAgICA+ICAgICA+IA0KICAgID4gICAgID4gICAgID4gDQogICAgPiAgICAgPiAgICAg PiANCiAgICA+ICAgICA+ICAgICA+IFRoZW4gdGhlcmUncyB0aGUgcXVlc3Rpb24gb2YgaG93IHlv dSBnZW5lcmF0ZSB0aGVtLiAgSSdkIHByZWZlcg0KICAgID4gICAgID4gICAgID4gc29tZXRoaW5n DQogICAgPiAgICAgPiAgICAgPiB0aGF0IGNhbiBiZSBjb2RlZCB1cCByZWxhdGl2ZWx5IGVhc2ls eSBpbiB5b3VyIGJpZ251bSBsaWJyYXJ5DQogICAgPiAgICAgPiAgICAgPiBvZg0KICAgID4gICAg ID4gICAgID4gY2hvaWNlLCBzbw0KICAgID4gICAgID4gICAgID4gdGhhdCBhbnlib2R5IGNhbiB2 ZXJpZnksIHVzaW5nIHNvbWV0aGluZyB0aGV5J3ZlIGJ1aWx0DQogICAgPiAgICAgPiAgICAgPiB0 aGVtc2VsdmVzLCB0aGF0IHRoaW5ncyBhcmUga29zaGVyLiAgSXQncyBiZWVuIHBvaW50ZWQgb3V0 IHRoYXQNCiAgICA+ICAgICA+ICAgICA+IGh0dHBzOi8va2l2aW5lbi5pa2kuZmkvcHJpbWVzLyBj b250YWlucyBwcmltYWxpdHkgcHJvb2ZzLCBidXQNCiAgICA+ICAgICA+ICAgICA+IHdoYXQgaXQN CiAgICA+ICAgICA+ICAgICA+IHJlYWxseSBjb250YWlucyBpcyBhIGh1Z2UgYW1vdW50IG9mIHRl eHQgdGhhdCBkb2Vzbid0IG1lYW4NCiAgICA+ICAgICA+ICAgICA+IGFueXRoaW5nDQogICAgPiAg ICAgPiAgICAgPiB0bw0KICAgID4gICAgID4gICAgID4gYW55b25lIHdobyBpc24ndCBpbnRpbWF0 ZWx5IGZhbWlsaWFyIHdpdGggdGhlIHRvb2wgdXNlZC4gIFRoaXMNCiAgICA+ICAgICA+ICAgICA+ IGlzbid0DQogICAgPiAgICAgPiAgICAgPiBpbiBhbnkNCiAgICA+ICAgICA+ICAgICA+IHdheSBt ZWFudCBhcyBhIGNyaXRpY2lzbSBvZiBUZXJvLCBidXQgbW9yZSB0byBwb2ludCBvdXQgdGhhdA0K ICAgID4gICAgID4gICAgID4gc2F5aW5nICJoZXJlIGlzIGEgbGFyZ2UgYW1vdW50IG9mIGluY29t cHJlaGVuc2libGUNCiAgICA+ICAgICA+ICAgICA+IG1hY2hpbmUtZ2VuZXJhdGVkDQogICAgPiAg ICAgPiAgICAgPiB0ZXh0LCB0cnVzdCBtZSwgdGhlIHByaW1lcyBhcmUgT0siIHJlZHVjZXMgZGly ZWN0bHkgdG8gInRydXN0DQogICAgPiAgICAgPiAgICAgPiBtZSwgdGhlDQogICAgPiAgICAgPiAg ICAgPiBwcmltZXMgYXJlIE9LIi4gIFNpbmNlIG1vc3QgcGVvcGxlIHdvbid0IGJlIGFibGUgdG8g bWFrZSBoZWFkIG9yDQogICAgPiAgICAgPiAgICAgPiB0YWlsDQogICAgPiAgICAgPiAgICAgPiBv ZiB3aGF0J3Mgb24gdGhhdCBwYWdlLCB0aGUgcmVzdWx0IGVuZHMgdXAgYXMgInRydXN0IG1lIiBh Z2Fpbi4NCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiANCiAgICA+ICAg ICA+ICAgICANCiAgICA+ICAgICA+ICAgICBUaGF0IGhvdyBfYWxsIG9mIGNyeXB0b2dyYXBoeV8g d29ya3MuDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAgPiAgICAgRWl0aGVyIHlvdSB1bmRl cnN0YW5kIGVub3VnaCBvZiB0aGUgbWF0aHMgdG8gZm9sbG93IGFsb25nIG9yIHlvdQ0KICAgID4g ICAgID4gDQogICAgPiAgICAgPiBkZWxlZ2F0ZSBpdCANCiAgICA+ICAgICA+IHRvIG90aGVycyBh bmQgdHJ1c3QgdGhlbS4NCiAgICA+ICAgICA+IA0KICAgID4gICAgID4gICAgICANCiAgICA+ICAg ICA+IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICAgICA+IEV4dGVu ZGluZyB0aGlzIGZ1cnRoZXIsIGlmIEkgd2FudGVkIHRvIHJlcGxpY2F0ZSB0aGUgcmVzdWx0cyBv bg0KICAgID4gICAgID4gICAgID4gdGhhdA0KICAgID4gICAgID4gICAgID4gd2ViDQogICAgPiAg ICAgPiAgICAgPiBwYWdlLCBJJ2QgZW5kIHVwIG9uDQogICAgPiAgICAgPiAgICAgPiBodHRwOi8v d3d3LmVsbGlwc2EuZXUvcHVibGljL3ByaW1vL3ByaW1vLmh0bWwsIGFuDQogICAgPiAgICAgPiAg ICAgPiBIVFRQDQogICAgPiAgICAgPiAgICAgPiAobm9uLSBIVFRQUykgd2ViIHBhZ2Ugd2l0aCBh biB1bnNpZ25lZCwgdW5hdXRoZW50aWNhdGVkIDd6IGZpbGUNCiAgICA+ICAgICA+ICAgICA+IGNv bnRhaW5pbmcNCiAgICA+ICAgICA+ICAgICA+IGEgYmluYXJ5IGJsb2IgdGhhdCBJJ20gZXhwZWN0 ZWQgdG8gZG93bmxvYWQgYW5kIHJ1biBvbiBhIDY0LWJpdA0KICAgID4gICAgID4gICAgID4gTGlu dXgNCiAgICA+ICAgICA+ICAgICA+IGJveA0KICAgID4gICAgID4gICAgID4gdG8gdmVyaWZ5IHRo YXQgbXkgcHJlY2lvdXMgY3J5cHRvIHBhcmFtZXRlcnMgYXJlbid0IGJhY2tkb29yZWQuDQogICAg PiAgICAgPiAgICAgPiANCiAgICA+ICAgICA+ICAgICA+IFNvLCBob3cgbWFueSBwZW9wbGUgY2Fu IHNlZSB0aGUgcHJvYmxlbSBoZXJlPw0KICAgID4gICAgID4gDQogICAgPiAgICAgPiANCiAgICA+ ICAgICA+IA0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAgIHRoZSBwb2ludCBvZiBn ZW5lcmF0aW5nIHByaW1hbGl0eSBjZXJ0aWZpY2F0ZXMgaXMgdGhhdCB5b3UgZG9uJ3QNCiAgICA+ ICAgICA+ICAgICBjYXJlDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IHdoZXJlIA0KICAgID4g ICAgID4gdGhleSBjb21lIGZyb20sIGVpdGhlciB5b3UgY2FuIHZlcmlmeSB0aGVtIGFuZCB0aGVu IHlvdSBrbm93IHRoYXQNCiAgICA+ICAgICA+IHRoZSBudW1iZXIgdGVzdGVkIGlzIHByaW1lIG9y IHlvdSBjYW4ndCB2ZXJpZnkgaXQgYW5kIHRoZSBudW1iZXIgaXMNCiAgICA+ICAgICA+IGxpa2Vs eQ0KICAgID4gICAgID4gbm90IGEgcHJpbWUgKG9yIHRoZSBjZXJ0aWZpY2F0ZSBpcyBib2d1cykN CiAgICA+ICAgICA+IA0KICAgID4gICAgID4gICAgIA0KICAgID4gICAgID4gICAgIC0tIA0KICAg ID4gICAgID4gICAgIFJlZ2FyZHMsDQogICAgPiAgICAgPiAgICAgSHViZXJ0IEthcmlvDQogICAg PiAgICAgPiAgICAgU2VuaW9yIFF1YWxpdHkgRW5naW5lZXIsIFFFIEJhc2VPUyBTZWN1cml0eSB0 ZWFtDQogICAgPiAgICAgPiAgICAgV2ViOiB3d3cuY3oucmVkaGF0LmNvbQ0KICAgID4gICAgID4g ICAgIFJlZCBIYXQgQ3plY2ggcy5yLm8uLCBQdXJrecWIb3ZhIDk5LzcxLCA2MTIgNDUsIEJybm8s IEN6ZWNoDQogICAgPiAgICAgPiAgICAgUmVwdWJsaWMNCiAgICA+ICAgICA+IA0KICAgID4gICAg ID4gDQogICAgPiANCiAgICA+ICAgICANCiAgICA+ICAgICANCiAgICA+ICAgICAtLSANCiAgICA+ ICAgICBSZWdhcmRzLA0KICAgID4gICAgIEh1YmVydCBLYXJpbw0KICAgID4gICAgIFNlbmlvciBR dWFsaXR5IEVuZ2luZWVyLCBRRSBCYXNlT1MgU2VjdXJpdHkgdGVhbQ0KICAgID4gICAgIFdlYjog d3d3LmN6LnJlZGhhdC5jb20NCiAgICA+ICAgICBSZWQgSGF0IEN6ZWNoIHMuci5vLiwgUHVya3nF iG92YSA5OS83MSwgNjEyIDQ1LCBCcm5vLCBDemVjaCBSZXB1YmxpYw0KICAgID4gDQogICAgDQog ICAgDQogICAgLS0gDQogICAgUmVnYXJkcywNCiAgICBIdWJlcnQgS2FyaW8NCiAgICBTZW5pb3Ig UXVhbGl0eSBFbmdpbmVlciwgUUUgQmFzZU9TIFNlY3VyaXR5IHRlYW0NCiAgICBXZWI6IHd3dy5j ei5yZWRoYXQuY29tDQogICAgUmVkIEhhdCBDemVjaCBzLnIuby4sIFB1cmt5xYhvdmEgOTkvNzEs IDYxMiA0NSwgQnJubywgQ3plY2ggUmVwdWJsaWMNCg0K From nobody Thu Apr 6 15:43: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 CD37D129683 for ; Thu, 6 Apr 2017 15:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhJgXc-blxwd for ; Thu, 6 Apr 2017 15:43:24 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 7A517129498 for ; Thu, 6 Apr 2017 15:43:20 -0700 (PDT) X-AuditID: 1209190d-4b7ff700000023dc-85-58e6c486e611 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id F0.09.09180.684C6E85; Thu, 6 Apr 2017 18:43:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v36MhHKf013308 for ; Thu, 6 Apr 2017 18:43:18 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v36MhEVF009160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 6 Apr 2017 18:43:17 -0400 Date: Thu, 6 Apr 2017 17:43:14 -0500 From: Benjamin Kaduk To: curdle@ietf.org Message-ID: <20170406224314.GC30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUixG6nrtt+5FmEwaI5shZbF85idmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtofa1kKpjJXNBz4zdbAeJypi5GDQ0LAROLVI6cuRi4OIYE2 Jok9tyexQzjHGCUe/9/JCOG8YpK4v2A9WxcjJweLgIrEpW/7mEFsNiC7ofsyM8gkEQFhiZ4F kiBhYQEXiRd3djGC2LxAC750LGSBsAUlTs58AmYzC2hJ3Pj3EuwIZgFpieX/OEDCogLKEg0z HjBPYOSdhaRjFpKOWQgdCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuka6eVmluilppRuYgSF Eack7w7Gf3e9DjEKcDAq8fB6PH4SIcSaWFZcmXuIUZKDSUmUV8EHKMSXlJ9SmZFYnBFfVJqT WnyIUYKDWUmE9/OmZxFCvCmJlVWpRfkwKWkOFiVxXnGNxgghgfTEktTs1NSC1CKYrAwHh5IE r8xhoEbBotT01Iq0zJwShDQTByfIcB6g4UYgNbzFBYm5xZnpEPlTjLocc+59fc8kxJKXn5cq Jc57/hBQkQBIUUZpHtwcUPxLZO+vecUoDvSWMK8ayCgeYOqAm/QKaAkT0BKfW09BlpQkIqSk GhhrGuWdSmw/6aq8PRb9YtncQ6VRyz3b/jDvTP38/FcEd6/Wgmc9u4SFvXbMe6franqStcJb WrPQSzp1ReXnA90vs8/H9t24WJSr7W3Kenq7y4HG55t+PRdwOfCSyfFKpQ3bmpmNLV+PHVW1 iW7bP2Ha9Jif2ek6TpPCK8v/G+8q6lqy2/3Fe3UlluKMREMt5qLiRADlcrqe2gIAAA== Archived-At: Subject: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-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: Thu, 06 Apr 2017 22:43:26 -0000 Hi all, I started work on https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 some time ago but had to set it aside due to lack of cycles. It's a pretty straightforward deprecation of the triple-DES and RC4-based kerberos enctypes, which seems in scope for this WG if it will free up some more cycles in kitten. Does it seem worth doing here to people? Thanks, Ben From nobody Thu Apr 6 16:35: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 BD5D51296B7 for ; Thu, 6 Apr 2017 16:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84ecpDFLEWjJ for ; Thu, 6 Apr 2017 16:35:47 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0090.outbound.protection.outlook.com [104.47.34.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDEA127978 for ; Thu, 6 Apr 2017 16:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wzJWp7kIG8keC0jjgbdLR8B3WBk+ty+3IyfptalPCMc=; b=VaaSo+rPBtbgah0b2YrQlU+3MlZO0cNIZux+XOTT8B7xYVC+CVl2TBn0hPxmKoLcp8vR64ViRfJN4qhGdMaw/1Yl+Hec2zDpw8RTErTSy32CJx4n3Odl+38+Vz4dVBJm0qdHyaP+Bk/yFtwlJ/LhbKJT16/FAbb1rLWYUMUD8ww= Received: from BL2PR05CA0013.namprd05.prod.outlook.com (10.255.226.13) by BLUPR05MB531.namprd05.prod.outlook.com (10.141.29.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Thu, 6 Apr 2017 23:35:46 +0000 Received: from BY2NAM05FT005.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by BL2PR05CA0013.outlook.office365.com (2a01:111:e400:c04::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5 via Frontend Transport; Thu, 6 Apr 2017 23:35:46 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 BY2NAM05FT005.mail.protection.outlook.com (10.152.100.142) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1005.5 via Frontend Transport; Thu, 6 Apr 2017 23:35:45 +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; Thu, 6 Apr 2017 16:35: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 v36NZfFU003923; Thu, 6 Apr 2017 16:35:41 -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 9E98711454; Thu, 6 Apr 2017 16:35:40 -0700 (PDT) To: Benjamin Kaduk CC: In-Reply-To: <20170406224314.GC30306@kduck.kaduk.org> References: <20170406224314.GC30306@kduck.kaduk.org> Comments: In-reply-to: Benjamin Kaduk message dated "Thu, 06 Apr 2017 17:43:14 -0500." From: "Mark D. Baushke" Date: Thu, 6 Apr 2017 16:35:40 -0700 Message-ID: <91285.1491521740@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)(39450400003)(39840400002)(39410400002)(39400400002)(39850400002)(2980300002)(189002)(199003)(9170700003)(230783001)(558084003)(54356999)(50986999)(117636001)(7126002)(5660300001)(86362001)(356003)(50466002)(305945005)(229853002)(105596002)(6916009)(2950100002)(7696004)(5003940100001)(76176999)(55016002)(189998001)(47776003)(53416004)(2906002)(2810700001)(106466001)(76506005)(4326008)(77096006)(6392003)(81166006)(8676002)(7846003)(8936002)(38730400002)(110136004)(53936002)(6266002)(2171002)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB531; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT005; 1:bZEw9j8CRYPB2gPv4WNKtdBOXW30hPj/5NgfYtiHv75u/6LvX3Eai4ifUC0hgl7i2ibNSNbu2lMLGitJOQQc6haTb3KesCCIvjAAicpe3IyNF8N9PS9DfeNySeU+jfCWxlM6muAuHs+CoO3bc6a8cZgz286pLDQNnp/qt/roLlbN345ClWQjjYO0vbaICJPQnRnLnVDZs3wB8Eqg7w2R3Z3mgnbPY2a/RVeYmR+Wuvph7KE1c5n2uRSx623GfvwHPz7Re35k9t96+Ne3rQ2CgQsvfm8Vi7CQALPN2vnRYVl0dI+N4aHJyZMw5JPKjzDsVlCyX4R+vOavjXwz2k4TgUbwibyYXq/Dv+3np6fSwBPWRAPK1swDGfVmS9pnxxXBdNeP+srexjxwp0RofS6AqGoDy85DGo2NA6LtlBd/ZKGGr5rY14oLM3J9+Oyi+cw3nG0N6T4OKxtL/6DwOcPCSe7/9x1P58UH0O8mJuEfTnNad5+MweVaHGBgaZ8hpBhMmd5fQfvnTC4yxv3qt9guwm92uH8qvVSlwG2oWW6j5DiVXKtlLuZITrJ6tNnlBnMoCm1uS7weqMXKtyx4aBYCL90d5uFoCeuF0tWsj4oyA5Pafjlo52FIqXF73Hyuxiu/ X-MS-Office365-Filtering-Correlation-Id: 45ffdb8c-5845-41ac-ff5f-08d47d45a626 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BLUPR05MB531; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 3:hfxOaXga4pgLe9ozrq5GkNbzunOtbBJ7JLRaQQ7vs7FlR58ylnxZLsXjPyU+tgIDf0wr2mEmo52iJGWA5pzji5+JAEh5ZcecTHjm6pHbEuHnt+kdGQX+ezsNeZvJdRHoVXAMsO4pB9HxejLOVq7GOzUOg+6kp13MMrIh+b3fRr2uoRdkyY9culvsKlpEw0dJ3Rb9OstIwDEwbV7FDd0HihKqszy4ZPhMt617mK6gr2HPGOWrAZ4giVXwc+sHKv7p6qaGIs4Rxnye2e7KQdIXDB4SZtCQ6xa/7dX/dJBZs52gvnYeH3z11wKw5Yxtg+jdH/MCyiNJIeucQdqieWRM/NYI8RMnJ3xxRH+nNImJ8de9+fcSb0jafdyiEuDowsfWBgWXecZVzq9Z5rsds5yoC5aG8ma6NGz0B5luYeHiQfO6TEfIv0DfgA9kxGjh3O4A8NZ0DV7nW21QsfoJiAL/1A==; 25:vsiyGNU2+2AQG+DufIinF52VM9YapQ+BjKBB73h8UqAkvEJI1TDg9qacfB3VXkVDdBMVmrFiYIOF1erVn9EKIB7zIPrlTmA7UMolQxVKaxZlYcsa1ftA+ap21exF1XVgrCFZ/jNXsZDI4avrPafREtPqEBgkfkk9XGtIBDnJnG04c4uRh50ef1hhnfh9VwL6dgoJ6kZSYwU0GPN+cOh7knlNcLH008vQhcyfVifsMV8I47IQRhBWLKGnrxEi7VekK6NaDtW8zMOGdyejxcO2/otk5cGKnR1ijcFfCD1/n5khfUtKVdaIsFHnfLnqN/Vx5YSbfiXswZ5NCROsH9qHLVuG7gjAAn0lmlTp+o9LJEULGJPLaP9KtQNUwvzG0c/hdtxy1epZc6hSyPJg1/SdMQ+NYns2DmxrxAWRonnOo5EXRA7BEG2lOJyZQVe3IQZ+qKvchNipFgvo8KhSfJ92lA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 31:Mb7toylhQh03AxbuxPoiRPizGOovbHMnORyFO7OfN7rdJIVacaE8JujYjOeMeTERXc0h5+6y/g9SU5eMcIWZXiKSAa8Qa+F40fCdJwB5/zOxROmQ/AC3VPO1U9G5zK6ROpVDjYvwZocUH1xYl83ru6V84+Lbe3kfsAumS2HH0p1AC8VDSfOW9EhbRZig5mw0dSKv24xZ59QZ6PIkG3pLP5EeKqV2qEN3+p0Z3MVFB0EBqXgVDm9ZWT+GhKlbzjRxm/zQs2gLrHlDFIaEmxq/mg==; 20:ttnC9HYybNVE1MOOLsH2cE2UYNi2MC6Wc7efdd9H9cYBguP33Tz384AYyzKOOB7PR2mwy2VlEnWJ1voGHA1PlUT7kgJOxkvqVTHnVw43xXsd2YYkBehsWsJTZQF03tkxpziOJY/HYbfDDL9eBvD7AZBcbUe9zczMBpIHGAwS5gO5T5eVOHy2kCqTlMvLIyXFka5wuaRnnYOxk5eWdDyOCh7iUKTbiB8kAwPh0mQqZZLDCof5hI9pi4nYsdSAC472vZrWAnAYF7/LO4PTQ9zizchVZKAm6G0dUuMv7bxEZnMXBmBwdvxCGEAFqZO/qykmB+LpuFba5LtL6FP9XHpFfYe2JrZ/GmqobNjH6nZIq4M0yY9FJNPa8aKuHNRzaffgTHQu3T9LroPSi7lsE8vOUwS5Mvh88ErjBNsTe7emCfACdmMj8OVcrBPf3u5aSmYfeYrACWef2WffJuMGd84DyTzIJEu+WiZUMvqY3XYSbsyD0RcIrcqb9Spvgx4KQMI4 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(5005006)(13015025)(13024025)(13023025)(8121501046)(13018025)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(6072148); SRVR:BLUPR05MB531; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB531; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 4:N20qP7oLA5OOogyVmJSbw636odUH3puOmrKyojI8u8BtK6fPh8Tw9SxXvefpZOJyJ4sWZ6JDfM0c+aXYB4h32E5lyQIrpR3C+keYPySxpGdARstPFQr5YfwrbonBuDR+dbPKqsN+ukiOIdHGP1cFhh6at2kPRXW9XVVzumUUQ0vEIgemVfu/qyvxewrD323clpZRWv9vVH7U1ta+DoXEsI8S2MOXj/DLWY83F7HBxWt0Wl4RjHvhdVsGO5km79t9vYS8PRHpIAwm0uwqxxfdU+a5dstY7l4iEr/ojXMe87rZel2xrS6L1azmotdoyfsAT4O/jE6IP5xiU4UKifzRnHApWwLlFYGxOGrM2TFYOrA5skgw0y30vsuanZr/16MdmXm4FHsJaeo6kM0d2YD4du2z+tM2Pzx03NNCgEyPmg5gVIw2V4GPdnkPzfFzmxkKYXPC1MSBSLDDE+TitqvX5BzDgEMXRh6aRrXAcynO53NT3c3ZwyjVzEXk8YWby0PeiCwGsDMIdO//bRjzJnjZAMfxacadU8IZkGJaOC+CYOQc6L/zEAHZdgmyfB8X/dycjfj9ZUNDa0atJWPRX0CmrwjJuQsKrw/CbATdStrjIY8kXE8Q9MpaIkzQjy/ef6FmwIvY2iHDmlAHnbim8JGN1u56QWzKgyu7Lpf1p+yjDiiE+bcgDxbqHseZBzjNY1LHv14+mGfjeboM0C3FVHYUwDJo2+/GeQ0E3gig4i1mYlIKj8BLEShE/QDoBRtZ/WooCI8C+jTjzUSK0KU/2xE7IAJwaO7L85JCbp5/qZgirQ3q3gs3aqvWpl8Lf2Uc/fy9YlYZILBTT8EDxZvVDS0u/g== X-Forefront-PRVS: 02698DF457 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB531; 23:Nnop9wOl6wq+8D0qIsqGh+lmKhvfR3tsaJIfN9nSCT?= =?us-ascii?Q?7BBt475P03TLAgDXvXh2HnOC0EoHbWoouO7o5V4FPJ2wSxwt60o/awt+GHr6?= =?us-ascii?Q?pARjypSlDGStzABtKqfUZbS/5uhMS5i4HrQNlbsIVG+Y630SBsUR2YkGRYF8?= =?us-ascii?Q?dfAehuHYxF4r93I2I0PFhtAwSUJvPZrnQZ1jPEPe3KiAiFQBLjaqMMFnjkpp?= =?us-ascii?Q?KY43yDK0pO2wejkd/RYKajMPdU0RIUuzuEqn8YqgkzQLAQ+SbH7+cf8BuM8J?= =?us-ascii?Q?XJehWZugVdcuk8KmNzURazchjAqhYMH72JWcFhBwG90rvteLa21Y3tcx/SzC?= =?us-ascii?Q?w1E0KU5aBqqMsPMBHwYxRHii6Wm0cRHBkBZ+21ZIHqg8J2gXhQ4knPneDo7b?= =?us-ascii?Q?HGiTaCr1modjaJkC/X0QsnB/Jpa7iIz7R78BVmHYzjSfIXs62fqUyUdzPAVw?= =?us-ascii?Q?O3JrzupbI65P2IuiG/4kn076P+m2HkpY9lhJHNQ/sBKVi9plTGzZ8lo4Xnnp?= =?us-ascii?Q?5bbKLeDQqXErgWkaGLucQnZsMd/U5Zc47uPZo4AxaFk3ozu7olTNfJns9y0H?= =?us-ascii?Q?GEOBSjZjVPxwghHNUHMh4J6hdoordkB7Ax5CW6/hSgk4MUAR3LHkiNUKhz44?= =?us-ascii?Q?rPRn/QISHvix66iBXLI4wQ0BhB8hDafeW0HU6wjqFfBy26vViYF6x5aOthfe?= =?us-ascii?Q?wFBgWyFWfApnnaEcf4tw62heaZPpmKIR/TOf9vjAZF9abxlhUA7XQH+lU2Yd?= =?us-ascii?Q?6mKOfNQtKaz1d07gKD354RatGFsVeXpml73ooKix3sk842erdflXejjVlgKs?= =?us-ascii?Q?GSJ8Y63MEw9Zjfj0zyaVO/qiIyLGwUu+lena3mcI/J35aCQHDENkntSSmDFe?= =?us-ascii?Q?v6olnKpKvYQ5J1rYa6t4iBhfLP/uPK542Bek1h7JSVTbky5YlIPX8vc04QXc?= =?us-ascii?Q?nmxvo7X+5Wdsumd4ecJqhJvCVxiF0RvYAohWCYCeyTbVQewCZTFMM+B4TFz+?= =?us-ascii?Q?10miHwWMmRZLEuonDwoU8HscxlcXmYRZBjppUvp3WPptx4ngwcdGVklLCosq?= =?us-ascii?Q?ife6okybo+iz+mFilf/CpWYsNTHulZaMTTb9CofwoPs+kDqYpMSMterM0TEZ?= =?us-ascii?Q?wXmcigOptWTdNG24odWE2uLD2WDijJI7S/RFESlOfhrY700a46QyrTwbiIHb?= =?us-ascii?Q?bfQw/FHTZA8pzaXzOTw5EWFjz363LhxlsaCKmrGHTsgLJp4UaQWmXOH4MpNH?= =?us-ascii?Q?T5x76f935OuONWW/A=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 6:HKkUkN2MZk0hA8X82TX8/dMRD7tAQsJ8OTelQrQWnnI9UICHwKoyA7OrPtQRofNQZVmvGsCczNBChB8QmVCDShkd3J1FGNGmO1C580G+AXLZV6nH4XGCv2BRK4hUNkf4t3jeX4kW7HkZ6wnv4wvLyV+KyAfyALyKdfg+5Quk5SoeVtHtu8doGpcm+5btLPDKF5CQRva4NApf7nX65n76qhNGFqcjWKtoPcDrangf5mwkqAn8+dD5zg1xXo1UduuFX295L15V9kFGDnnqPYZI1zSyLFCipU8fpR7A64stNQl2s9U3P29xFBfWFGCylBmHWHXAHW1qLS5tjaygl1JvL5BTvm4yY0IAqal2o8FSn3vEqBMjstgoqedKDIbPbHOGSY60sbQfeZgxATgCB9BFBafBjfJ1QZih1JMGEwl7FrYg/4+kCGyoYb4RU0MoQkK/epdY3MojxHJHWMiAcz8GY7T4PRSbGpomabhjz+hdLK4=; 5:zakEeQDXwLIgZe2p6tf+Kai6HD8YIYB4J/Bo/xCf/i7AseRQ0gmNooByd5Zx+1A02X6fx45o4dosKkntb1vFjzxl+ZZ5yNLhb/jhGEDaP2zA1eZjCRRtnkETCXffnOH0+lFc9MAxCjxJ4qQwcSX82vOJOSSJcNAQG5RerT58uaQ=; 24:ztb1GCHv0Fc4C1kIitq2z1s2PT/aO/Ep+LZZiqifMiW+eL1c2w4TIOETOzIrhmwnaTgIv/QxVOuaxlh4a4mToO0/nc6zxRLe6eIHRORDwcI= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB531; 7:dBgAedJtW+mDXMKP0OP6T9EAbrJeTdt2QVuTy+iyJDkKevdRon2L3tLt+yBRschWpzMxs4I+wWqHl4nc+Qrv0jxWItiAdOKOuSrXgg+yANKPNKxkcn2WMWUB64eMOhQf6nGqjEHyc1rlomsa9DDzfDRhsOIQyX/pphajekxQJRT1TteRewatQrRym5U68XoSEbLBOCMsqtbWtCEHtcD4j9oYjyBndWmwn/FyK9IwYfRIz1PSymXDZc9rwgaZioswVmzoYLmIz7RhvLfRLbWtbqd7F4YRV06COiD8yCfKLvlKqDq3RaPu/U4pIzLZ/wvcKHrfF9H1XFdltabdEzRfHg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2017 23:35:45.6999 (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: BLUPR05MB531 Archived-At: Subject: Re: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-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: Thu, 06 Apr 2017 23:35:50 -0000 Hi Ben, The curdle-chairs should probably give you the official answer, but I would think that deprecation of triple-DES and RC4 in kerberos is in scope for this WG. -- Mark From nobody Thu Apr 6 17:54: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 5A3AF1296C8 for ; Thu, 6 Apr 2017 17:54:28 -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 S7bf0iCFTrWC for ; Thu, 6 Apr 2017 17:54:15 -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 A198A126E01 for ; Thu, 6 Apr 2017 17:54:15 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v370qpbM021383; Fri, 7 Apr 2017 01:54:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ta56zPG365F1JqetWQ22vV84p+rrw5Vrgfy9VubbX8w=; b=l4Jko9fUxlDRrJQAeWg2pV2np5WlfnVMOTO+HS0D8tzlRyfcojA8Q4oIxzDW7R68ItwW NL330DsI+eiHbECMI7zwrMABRvde9AmyvaU8scqjsbcVnW5YSeSEB5+EeCj4rR45FOxq So/xH/du66RWpEMhvlLS1FXIvT2Czo750cLh7A7ck89HJAnW7nNGmoh7VZBS5l9zLwEB 837SAyAUt60ZOMPxKc8enm4gCa6gw6AAU0vfJofQ4CWK9KT4004tmriWus4F1sGnMXYM M7yH0Z7P2NkdVyQc/myO2K/3RRDeudj5fJXTnKb+JqKXVLcut3ntwh7BV6BLWskDKBsa Cg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 29nh66nfrp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 07 Apr 2017 01:54:14 +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 v370sDXd023565; Thu, 6 Apr 2017 20:54:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 29j7huargy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 20:54:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 6 Apr 2017 20:54:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 6 Apr 2017 20:54:12 -0400 From: "Salz, Rich" To: Benjamin Kaduk , "curdle@ietf.org" Thread-Topic: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-die-die-die? Thread-Index: AQHSryc3L0eJRKzP102IjwphEoKZO6G5Ea+A Date: Fri, 7 Apr 2017 00:54:12 +0000 Message-ID: <7e593282241c4b7882bef51defad551c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170406224314.GC30306@kduck.kaduk.org> In-Reply-To: <20170406224314.GC30306@kduck.kaduk.org> 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.38.243] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_01:, , 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-1702020001 definitions=main-1704070005 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-07_01:, , 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-1702020001 definitions=main-1704070005 Archived-At: Subject: Re: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-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: Fri, 07 Apr 2017 00:54:28 -0000 It is in-scope for this WG. If you want us to do a call for adoption, let = us know. From nobody Thu Apr 6 18:28: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 1CF51129551 for ; Thu, 6 Apr 2017 18:28:12 -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 mOXu7HyPn56i for ; Thu, 6 Apr 2017 18:28:10 -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 541C6126E01 for ; Thu, 6 Apr 2017 18:28:10 -0700 (PDT) X-AuditID: c6180641-80136980000058cf-2c-58e6a4d019dc Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id B5.E3.22735.0D4A6E85; Thu, 6 Apr 2017 22:28:00 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0339.000; Thu, 6 Apr 2017 21:28:08 -0400 From: Daniel Migault To: "Salz, Rich" , Benjamin Kaduk , "curdle@ietf.org" Thread-Topic: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-die-die-die? Thread-Index: AQHSryc4nWmdHbM+rEazjWRwWgILG6G5V7EA///GDFA= Date: Fri, 7 Apr 2017 01:28:07 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BC8344@eusaamb107.ericsson.se> References: <20170406224314.GC30306@kduck.kaduk.org> <7e593282241c4b7882bef51defad551c@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <7e593282241c4b7882bef51defad551c@usma1ex-dag1mb1.msg.corp.akamai.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPgu6FJc8iDBZe1bDYunAWs8XyjTOZ LP5v6WRxYPaYfGQBs8eSJT+ZPJrOHGUOYI7isklJzcksSy3St0vgymhY5lDwkKXi95JzjA2M f5m7GDk5JARMJO72zmXqYuTiEBLYwChxbPMEFghnGaPE674LjCBVbAJGEm2H+tlBbBGBLIkd CyaD2cICwRJf13xkg4iHSNzvvMoMYVtJLDzTD9bLIqAisf71W7A4r4CvxPNr88HiQgK1EmcO /wCbwwk05/TnX2A2o4CYxPdTa5hAbGYBcYlbT+YzQVwqILFkz3moq0UlXj7+xwphK0nMeX2N GaJeR2LB7k9sELa2xLKFr6H2CkqcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGDlKiwtyctON DDcxAiPhmASb4w7Gvb2ehxgFOBiVeHgVDjyJEGJNLCuuzD3EKMHBrCTC+/rRswgh3pTEyqrU ovz4otKc1OJDjNIcLErivO/KL0QICaQnlqRmp6YWpBbBZJk4OKUaGL0N7uxN4FHtKzuy1+po Rd7zyPUr7XoWMpRtT73ksPTJpTLFmYGzX7Anr7DjUUp9dlzhVPXh+Z0Xy/+mV7Upn1kt3WWS y2zlbqduFHz4/k/Zymdn3Nr/mOpM72FfVjmzqmjXmu5DjvdveG3llr90pX8dK/v87XZ12SIv z3R2Lbwl0eGundU3R4mlOCPRUIu5qDgRAEFk84uAAgAA Archived-At: Subject: Re: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-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: Fri, 07 Apr 2017 01:28:12 -0000 Once the pipe is clearer we have a few draft to adopt. Maximum a few weeks.= =20 Yours,=20 Daniel -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Salz, Rich Sent: Thursday, April 06, 2017 8:54 PM To: Benjamin Kaduk ; curdle@ietf.org Subject: Re: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-die-di= e-die? It is in-scope for this WG. If you want us to do a call for adoption, let = us know. _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Apr 6 20:11:25 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 6CC95129622 for ; Thu, 6 Apr 2017 20:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2ECgS9C6MKn for ; Thu, 6 Apr 2017 20:11:22 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 BD279129569 for ; Thu, 6 Apr 2017 20:11:20 -0700 (PDT) X-AuditID: 12074425-167ff70000007129-68-58e7035620db Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 0B.94.28969.65307E85; Thu, 6 Apr 2017 23:11:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v373BHVn024241; Thu, 6 Apr 2017 23:11:18 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v373BDQD016740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Apr 2017 23:11:16 -0400 Date: Thu, 6 Apr 2017 22:11:13 -0500 From: Benjamin Kaduk To: "Salz, Rich" Cc: "curdle@ietf.org" Message-ID: <20170407031113.GD30306@kduck.kaduk.org> References: <20170406224314.GC30306@kduck.kaduk.org> <7e593282241c4b7882bef51defad551c@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e593282241c4b7882bef51defad551c@usma1ex-dag1mb1.msg.corp.akamai.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrBvO/DzCYMkjI4utC2cxW/zf0sni wOQx+cgCZo8lS34yBTBFcdmkpOZklqUW6dslcGVMvLeWueAiY8WKhe8YGxjnMnYxcnBICJhI LF+r38XIxSEk0MYk0f7xOjuEs4FRouHMe1YI5wqTRP+L00AZTg4WARWJKfs3sYHYbEB2Q/dl ZhBbREBZ4vjMB4wgNrOAusSvY8fAbGGBYImXr76ygti8QNs2v98PFhcSqJU4c/gHO0RcUOLk zCcsEL1aEjf+vWQCuY5ZQFpi+T8OkDAn0JjTn3+BlYsCrWqY8YB5AqPALCTds5B0z0LoXsDI vIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyMoSNldVHcwzvnrdYhRgINRiYfX 4/GTCCHWxLLiytxDjJIcTEqivAo+QCG+pPyUyozE4oz4otKc1OJDjBIczEoivAx/nkUI8aYk VlalFuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvF1MzyOEBItS01Mr0jJzShDS TBycIMN5gIaXg9TwFhck5hZnpkPkTzHqcsy59/U9kxBLXn5eqpQ47wyQIgGQoozSPLg5oOQi kb2/5hWjONBbwrxqIFU8wMQEN+kV0BImoCU+t56CLClJREhJNTAW/RQXL7pr/tZ167qnW02d G349ywzYejxbXe1oilHvppX/H4ZEvu4xy/Cc8OMJm9pd/hfZ7FbX+LsL9p3fPnX/Xptjsz8J y6d0hhRzKvxMnvglijXhlrDox9SU4im/Lxo3JH5fekDxwazpfWu4uZSvxvh56v//m8RyZcPW O+/7Itk65TIlOeyUWIozEg21mIuKEwHl7PLmCQMAAA== Archived-At: Subject: Re: [Curdle] Any interest in draft-kaduk-kitten-des-des-des-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: Fri, 07 Apr 2017 03:11:24 -0000 On Fri, Apr 07, 2017 at 12:54:12AM +0000, Salz, Rich wrote: > It is in-scope for this WG. If you want us to do a call for adoption, let us know. Sure, please do so at your convenience. Thanks, Ben From nobody Thu Apr 6 22:32: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 19D1C12702E for ; Thu, 6 Apr 2017 22:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 PlDSRNsbv7DK for ; Thu, 6 Apr 2017 22:32:10 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 1824F1270FC for ; Thu, 6 Apr 2017 22:32:09 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id i34so53232033qtc.0 for ; Thu, 06 Apr 2017 22:32:09 -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=iwgxIoIlJlyRp0vyKgHqHToVQfE/w4MK5haHcWAjUKE=; b=QV1zUI9YgoGZnpNu1Qp7QkdcypY3FFwbopuVgcncl+phkEHw8YZXyVz8N/MD3ou8bH PdGjoJRqKe2UvTXAnE0KI1s9/QWuco2EVt61xFUsn90Vi5Xi68Nwvo5K+vGXrXlSf1yT CnfjYeo/XhMYGC926CKKufWQErShYDhagB/yp+LO+RylIlUb4IlxB8RbaBRo182x9HA6 eAYCuiwGlR+m3RjSqQtRHH5aUCBHehZRlFpeQVfcZzqIDaCcjz17rEFIsA1keu2xZ/Se A3qp4zNFsAdXYW2Pc0KZIO9j7IgRRP9dmg4GXf3QwNKdMUadmHhmCB9Dl5xmXk1fuBuT JUXQ== 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=iwgxIoIlJlyRp0vyKgHqHToVQfE/w4MK5haHcWAjUKE=; b=T5TEqdcosPQMaAIkOuQLjrX5ha6pomRgLdwnOn1nm7FyI647oYA/KOdCMvPWXTpaRi w8NnT80gdLnEOwDXRtpGSQrz0juuKn6ZJCIHt5+bmIjfJqTIQywfg1N6SBPJcgerb/hb 0cTuXy4K6F7Q29uCr41R4UfQDFNdx4KgTBtKFB/CCp6nVhQtqExo12+Kb5uO52c80+A/ QyE5oRh/ZEu4zzSF56cLXh4hAl4rvKEdZ0csEWBfOoCP/egYtCSmkcUtCttFDkK+O8iY R1RvYZua2r+5WuBXw3FeJviw0wQEOvxNe2b6KDK8i1vQEZz3PqFHOTaoqNJCAuO3n9oy 6tqg== X-Gm-Message-State: AFeK/H0+4PKEJcL48mMJN9T+WkJWz9M0tj975Uqj1UuU35oKhzhtaHPektqq5qbHGTwmg1QDiicyzWKB748+RA== X-Received: by 10.237.34.8 with SMTP id n8mr41276685qtc.98.1491543128018; Thu, 06 Apr 2017 22:32:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Thu, 6 Apr 2017 22:32:07 -0700 (PDT) In-Reply-To: <1491480250094.74577@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> From: denis bider Date: Thu, 6 Apr 2017 23:32:07 -0600 Message-ID: To: Peter Gutmann Cc: curdle Content-Type: multipart/alternative; boundary=001a113f09385015b4054c8cf207 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 07 Apr 2017 05:32:14 -0000 --001a113f09385015b4054c8cf207 Content-Type: text/plain; charset=UTF-8 > I was thinking of the problem that it's essentially > impossible to safely do n-RTT, n < 1, for TLS, which > meant that doing the same thing for SSH wasn't going > to be any better. I was reasoning by analogy from TLS > rather than sitting down and drawing diagrams for SSH > to try and figure out all the possible issues. OK, but I'm not familiar with the security implications of this on TLS. Can you link to any resources where this was discussed? Whether for TLS, or in any other context? > Perhaps adding an implementation note to say that at this > point the crypto hasn't been confirmed yet and so you may > want to be careful about what you put into your extension > data would be useful? I agree, if this is a threat, we should add a warning in Security Considerations. But to make that warning, I have to understand the threat. If someone asks me about this warning, I want to be able to explain the reason in detail. At this point, what I can say is, "Peter said this on the list." That is, to me, insufficient backing. > Wouldn't "true" and "false" be a better way to express a > boolean? Yes if you could choose the type. But you can't choose the type, because all extensions have to use the same type. That type is a string. > I realise this is kinda bikeshedding, but having to look > up the spec just to figure out what mysterious magic > values in a boolean field specify seems a bit awkward. Booleans are equally mysterious. The third parameter to the Windows API function WaitForMultipleObjects is a boolean. Suppose an application passes "TRUE". Without checking the docs - what does that mean? If you check the docs, you know what "TRUE" in that context means. And if you check the spec here, you know what "p" and "s" mean. Booleans are not inherently self-documenting. (In fact - when used in languages with positional parameters, they are more frequently self-obfuscating.) > Given that there are a nonzero number of implementations > that send a window size of ~0 to indicate no flow control, > it may be useful to add an implementation note to point > this out. OK. I added the following sub-section to my current working copy: 3.3.1. Implementation Note: Prior "No Flow Control" Practice Before this extension, some applications would simply not implement SSH flow control, sending an initial channel window size of 2^32 - 1. Applications SHOULD NOT do this for the following reasons: - It is entirely within the realm of possibility to transfer more than 2^32 bytes over a channel. The channel will then hang if the other party implements SSH flow control according to [RFC4254]. - There exist implementations which cannot handle such large channel window sizes, and will exhibit non-graceful behaviors, including disconnection. denis On Thu, Apr 6, 2017 at 6:04 AM, Peter Gutmann wrote: > denis bider (Bitvise) writes: > > >Can you point out some of these subtle problems that could occur in this > >regard in SSH? > > I was thinking of the problem that it's essentially impossible to safely > do n- > RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn't > going to be any better. I was reasoning by analogy from TLS rather than > sitting down and drawing diagrams for SSH to try and figure out all the > possible issues. > > >Under the assumption that such an extension were defined, can you point > out > >at least one way that sending this info right after NEWKEYS can help an > >attacker? > > It depends on the extension. Without one defined, there's no way to tell > at > the moment. I could invent something that works out badly, but that'd be > creating a strawman... my concern is that in the future someone may define > a > problematic extension without realising that they're creating a problem. > Perhaps adding an implementation note to say that at this point the crypto > hasn't been confirmed yet and so you may want to be careful about what you > put > into your extension data would be useful? > > >But the extension value field is generically a string (it must be same > type > >for all extensions, so unsupported extensions can be decoded and ignored). > >"p" and "s" are therefore fitting ways to express this boolean. > > Wouldn't "true" and "false" be a better way to express a boolean? I > realise > this is kinda bikeshedding, but having to look up the spec just to figure > out > what mysterious magic values in a boolean field specify seems a bit > awkward. > > >Properly implemented flow control is superior. However, this extension is > a > >nod to that not everyone will be using an SSH library that does this > right, > >and "no-flow-control" is a better option if your needs are simple, and you > >don't have a few years to get this right. > > Given that there are a nonzero number of implementations that send a window > size of ~0 to indicate no flow control, it may be useful to add an > implementation note to point this out. I enabled some diagnostic code to > throw an exception in my code if it found this from another implementation > (other than mine) and got, uh, feedback from beta-testers about it, so at > least some implementations are using a pseudo-infinite window size to > indicate > no flow control. I'm not saying it should be adopted as an alternative to > "no-flow-control", but merely to alert implementers about the practice, > e.g. a > certain big iron vendor whose device would crash and reboot as it tried to > allocate ~0 bytes of memory to match the widow size. > > Peter. > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113f09385015b4054c8cf207 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> I was thinking of the problem that it's esse= ntially
> impossible to safely do n-RTT, n < 1, for TLS, wh= ich
> meant that doing the same thing for SSH wasn't going=
> to be any better.=C2=A0 I was reasoning by analogy from TLS=
> rather than sitting down and drawing diagrams for SSH
=
> to try and figure out all the possible issues.

OK, but I'm not familiar with the security implications of this = on TLS.

Can you link to any resources where this w= as discussed? Whether for TLS, or in any other context?


> Perhaps adding an implementation note to say that= at this
> point the crypto hasn't been confirmed yet and = so you may
> want to be careful about what you put into your e= xtension
> data would be useful?

=C2= =A0I agree, if this is a threat, we should add a warning in Security Consid= erations. But to make that warning, I have to understand the threat.
<= div>
If someone asks me about this warning, I want to be able= to explain the reason in detail. At this point, what I can say is, "P= eter said this on the list." That is, to me, insufficient backing.


> Wouldn't "true" and= "false" be a better way to express a
> boolean?

Yes if you could choose the type. But you can't c= hoose the type, because all extensions have to use the same type. That type= is a string.


> I realise this i= s kinda bikeshedding, but having to look
> up the spec just to= figure out what mysterious magic
> values in a boolean field = specify seems a bit awkward.

Booleans are equally = mysterious.

The third parameter to the Windows API= function WaitForMultipleObjects is a boolean. Suppose an application passe= s "TRUE". Without checking the docs - what does that mean?
<= div>
If you check the docs, you know what "TRUE" in= that context means. And if you check the spec here, you know what "p&= quot; and "s" mean.

Booleans are not inh= erently self-documenting. (In fact - when used in languages with positional= parameters, they are more frequently self-obfuscating.)


> Given that there are a nonzero number of impleme= ntations
> that send a window size of ~0 to indicate no flow c= ontrol,
> it may be useful to add an implementation note to po= int
> this out.=C2=A0

OK. I added the= following sub-section to my current working copy:


3.3.1.=C2=A0 Implementation Note: Prior "No Flow Contr= ol" Practice

=C2=A0 Before this extension, so= me applications would simply not implement
=C2=A0 SSH flow contro= l, sending an initial channel window size of 2^32 - 1.
=C2=A0 App= lications SHOULD NOT do this for the following reasons:
=C2=A0=C2= =A0
=C2=A0 - It is entirely within the realm of possibility to tr= ansfer more than
=C2=A0 =C2=A0 2^32 bytes over a channel. The cha= nnel will then hang if the other
=C2=A0 =C2=A0 party implements S= SH flow control according to [RFC4254].
=C2=A0 =C2=A0=C2=A0
=
=C2=A0 - There exist implementations which cannot handle such large ch= annel
=C2=A0 =C2=A0 window sizes, and will exhibit non-graceful b= ehaviors, including
=C2=A0 =C2=A0 disconnection.


denis



On Thu, Apr 6, 2017 a= t 6:04 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz>= wrote:
denis bider (Bitvise) <ietf-ssh3@denisbider.com> write= s:

>Can you point out some of these subtle problems that could occur in thi= s
>regard in SSH?

I was thinking of the problem that it's essentially impossible to safel= y do n-
RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn&= #39;t
going to be any better.=C2=A0 I was reasoning by analogy from TLS rather th= an
sitting down and drawing diagrams for SSH to try and figure out all the
possible issues.

>Under the assumption that such an extension were defined, can you point= out
>at least one way that sending this info right after NEWKEYS can help an=
>attacker?

It depends on the extension.=C2=A0 Without one defined, there's no way = to tell at
the moment.=C2=A0 I could invent something that works out badly, but that&#= 39;d be
creating a strawman... my concern is that in the future someone may define = a
problematic extension without realising that they're creating a problem= .
Perhaps adding an implementation note to say that at this point the crypto<= br> hasn't been confirmed yet and so you may want to be careful about what = you put
into your extension data would be useful?

>But the extension value field is generically a string (it must be same = type
>for all extensions, so unsupported extensions can be decoded and ignore= d).
>"p" and "s" are therefore fitting ways to express t= his boolean.

Wouldn't "true" and "false" be a better way to expr= ess a boolean?=C2=A0 I realise
this is kinda bikeshedding, but having to look up the spec just to figure o= ut
what mysterious magic values in a boolean field specify seems a bit awkward= .

>Properly implemented flow control is superior. However, this extension = is a
>nod to that not everyone will be using an SSH library that does this ri= ght,
>and "no-flow-control" is a better option if your needs are si= mple, and you
>don't have a few years to get this right.

Given that there are a nonzero number of implementations that send a window=
size of ~0 to indicate no flow control, it may be useful to add an
implementation note to point this out.=C2=A0 I enabled some diagnostic code= to
throw an exception in my code if it found this from another implementation<= br> (other than mine) and got, uh, feedback from beta-testers about it, so at least some implementations are using a pseudo-infinite window size to indic= ate
no flow control.=C2=A0 I'm not saying it should be adopted as an altern= ative to
"no-flow-control", but merely to alert implementers about the pra= ctice, e.g. a
certain big iron vendor whose device would crash and reboot as it tried to<= br> allocate ~0 bytes of memory to match the widow size.

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

--001a113f09385015b4054c8cf207-- From nobody Thu Apr 6 22:40: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 E212E126C25 for ; Thu, 6 Apr 2017 22:40:55 -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 FbwbtaGS0WVz for ; Thu, 6 Apr 2017 22:40:53 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 30E0F1267BB for ; Thu, 6 Apr 2017 22:40:53 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id h67so55080390qke.0 for ; Thu, 06 Apr 2017 22:40:53 -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=fXnImdIZQMspl3/7RNxcsN5s2MdDlXTuHCwW/0WVNTY=; b=ZgKU8RjfZjSKgS57b7IH74WWK277l8ipCY+ggoTw6FiCzl2mgjXWr/L9Beza417Ahg H8MR/PapByUQCnBUEqUigXM9GY3dy5Fsm0mercbC7aNev9Tu5e4BjsFgPfB6L+HEMPqS IBaPvxF6c5qru1uxpdvStKdboq+Xg8ABgf/I1pimZJsGQeSvqvtl4Qo+hf89Q23Z4hd3 E7+FOSg/l2wQArU4KPz3USptB6KDg58E5tpq85Gryi6/PxqdtfhZjwr6eWVMQfxXjz17 M3nOWZaX1Q1gtc3KhhHmmqMcOiNQg1uvs7JqxPCOzqZ96xso6xYni0qwiJSIc5chKRyK IrnA== 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=fXnImdIZQMspl3/7RNxcsN5s2MdDlXTuHCwW/0WVNTY=; b=guLf5XCPC7wCA/W2G7BHW9FnWZEBcgC0KrcwwugMPlqrJJh6m1RFiO6afB4GC8EcoU 6pDgxLuCUL537ME30W2/lTd55ryqxoK47nS/GApCWQ4Q8nUf/qpR7JS5TkWlcsaGUyv2 +49G6xZCeEQFkkWWLSH+WVQ1qWkj7G6bdQC2u+dHZG9B9Hm9mVmQyZv1ijrWqGy20zPm W7vLb2YNzl+l+OGSQuOBc3XlwKKkE95PFGbWm0gpvvNqcBr2PAA0ck62znEPrchMl4p3 FITuroUdoPOfE62N/zY3/n71hNm2MSQO1lvLr2R0+PFamNPVkD16qMZyHsL+yel1O0jP xArg== X-Gm-Message-State: AFeK/H3sLBlY7z09zSnAnClL1B0WxxlUbmDAMfUFYZbYhSVOyjm9yl0vRbHbdoWNDLRELEK0bfL1078Plx+riA== X-Received: by 10.55.56.134 with SMTP id f128mr33299081qka.296.1491543652413; Thu, 06 Apr 2017 22:40:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Thu, 6 Apr 2017 22:40:51 -0700 (PDT) In-Reply-To: <1491481241400.6079@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> <22749.17194.509999.470077@fireball.acr.fi> <1491481241400.6079@cs.auckland.ac.nz> From: denis bider Date: Thu, 6 Apr 2017 23:40:51 -0600 Message-ID: To: Peter Gutmann Cc: Tero Kivinen , "Salz, Rich" , curdle , "Mark D. Baushke" Content-Type: multipart/alternative; boundary=001a1147fdd291bb5d054c8d1117 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Fri, 07 Apr 2017 05:40:56 -0000 --001a1147fdd291bb5d054c8d1117 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Tero in this case. Having four keys instead of one adds 2 bits of security. If one of those keys is broken, the others are most likely too= . To quote Carnegie from June 1885: *The concerns which fail are those which have scattered their capital, which means that they have scattered their brains also. They have investments in this, or that, or the other, here, there and everywhere. =E2=80=9CDon=E2=80=99t put all your eggs in one basket=E2=80=9D is all wron= g. I tell you =E2=80=9Cput all your eggs in one basket, and then watch that basket.=E2=80=9D* On Thu, Apr 6, 2017 at 6:20 AM, Peter Gutmann wrote: > Tero Kivinen writes: > > >How about you verifying both IKE and TLS groups and make sure they are > >actually generated as explained, and that they are first primes matching > the > >process... > > And now we run into the Bystander Effect problem of security audits, > everyone > wants to have source code for whatever security tool they use published b= ut > no-one would ever dream of checking the code themselves, they all expect > someone else to do it for them... > > >If you are scared about that then just go to the 4096 bit Diffie-Hellman= . > If > >it will take years to break 1024-bit DH, and billion years (10^9) more t= o > >break 2048-bit DH, then 4096-bit DH should be safe... :-) > > I think we'll have to agree to disagree on our approaches here, you seem > to be > advocating putting all your trust in a single honkin' big key, while I > prefer > to diversify as much as possible so that if something breaks in one > location > then there are a pile of other measures that'll serve as a backup. > > Peter. > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1147fdd291bb5d054c8d1117 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with Tero in this case. Having four keys instead o= f one adds 2 bits of security. If one of those keys is broken, the others a= re most likely too.

To quote Carnegie from June 1885:

The concerns which fail are those which have scat= tered their capital, which means that they have scattered their brains also= . They have investments in this, or that, or the other, here, there and eve= rywhere. =E2=80=9CDon=E2=80=99t put all your eggs in one basket=E2=80=9D is= all wrong. I tell you =E2=80=9Cput all your eggs in one basket, and then w= atch that basket.=E2=80=9D


On Thu, Apr 6, 2017 at 6:20 AM, Pet= er Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Tero Kivinen <kivinen@iki.fi> writes:

>How about you verifying both IKE and TLS groups and make sure they are<= br> >actually generated as explained, and that they are first primes matchin= g the
>process...

And now we run into the Bystander Effect problem of security audits,= everyone
wants to have source code for whatever security tool they use published but=
no-one would ever dream of checking the code themselves, they all expect someone else to do it for them...

>If you are scared about that then just go to the 4096 bit Diffie-Hellma= n. If
>it will take years to break 1024-bit DH, and billion years (10^9) more = to
>break 2048-bit DH, then 4096-bit DH should be safe... :-)

I think we'll have to agree to disagree on our approaches here, = you seem to be
advocating putting all your trust in a single honkin' big key, while I = prefer
to diversify as much as possible so that if something breaks in one locatio= n
then there are a pile of other measures that'll serve as a backup.

Peter.
_____________________= __________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

--001a1147fdd291bb5d054c8d1117-- From nobody Fri Apr 7 03:06:24 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 32F7E127A91 for ; Fri, 7 Apr 2017 03:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uFCPmOJKXfl for ; Fri, 7 Apr 2017 03:06:18 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A3912940B for ; Fri, 7 Apr 2017 03:06:18 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 36F037F7CE; Fri, 7 Apr 2017 10:06:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 36F037F7CE Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 36F037F7CE Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5702DAC16F; Fri, 7 Apr 2017 10:06:16 +0000 (UTC) From: Hubert Kario To: Anna Johnston Cc: Peter Gutmann , Mark Baushke , Kyle Rose , Ilari Liusvaara , "curdle@ietf.org" , "Salz, Rich" , Tero Kivinen Date: Fri, 07 Apr 2017 12:06:09 +0200 Message-ID: <3157694.x7dcLsDI1d@pintsize.usersys.redhat.com> In-Reply-To: <9D44228F-011F-44EF-81EC-FFECD9F9C8BB@juniper.net> References: <4253810.u6Ox2pht7m@pintsize.usersys.redhat.com> <9D44228F-011F-44EF-81EC-FFECD9F9C8BB@juniper.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2223874.YKvJWPMz2a"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 07 Apr 2017 10:06:17 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Fri, 07 Apr 2017 10:06:20 -0000 --nextPart2223874.YKvJWPMz2a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 6 April 2017 20:45:42 CEST Anna Johnston wrote: > Yes, but another primality proof of the same size is also required for EC > primality testing. EC primality testing is similar to Pocklington=E2=80= =99s =E2=80=93 it > just goes around the problem of partially factoring (P-1) by moving to an > EC group and partially factoring the order of the group (~ same size as > prime), and proving that those factors are prime. Since you=E2=80=99re g= oing to > need to prove that (p-1)/2 is prime anyway, it=E2=80=99s a huge waste of = resources > and adding a lot more complication to a simple validation than is necessa= ry > to use EC. But then you reduce the size of the p by one bit. Primo in first step usual= ly=20 reduces the size of the number-needed-to-be-proven-prime by 20-30 bits, and= =20 jumps of 50 bits are not uncommon either. So while yes, you can use that property of the safe primes, the gain isn't= =20 much and the primality certificate will be unnecessarily large. Either way, I'm just a user of Primo, you should talk to developers of it i= f=20 you really are convinced that special approach for safe primes will make th= e=20 process faster. > A. Johnston >=20 > -----Original Message----- > From: Hubert Kario > Date: Thursday, April 6, 2017 at 11:32 AM > To: Anna Johnston > Cc: Peter Gutmann , Mark Baushke > , Kyle Rose , Ilari Liusvaara > , "curdle@ietf.org" , "Salz, > Rich" , Tero Kivinen Subject: Re: > [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 >=20 > On Thursday, 6 April 2017 20:21:30 CEST Anna Johnston wrote: >=20 > > All the primes in the list are safe. The certificates are based off > > elliptic curve testing, a variant of Pocklington=E2=80=99s which ON= LY makes > > sense > > to use if you don=E2=80=99t know the complete factorization of at l= east =C2=BD the > > bits > > of (P-1). Why not replace these with much easier to verify > > Pocklington > > certificates? This would also guarantee, at no extra cost, an elem= ent > > of > > order q. >=20 > =20 > but for Pocklington to work, we need to be certain that q is prime, > don't we? =20 >=20 > > A. Johnston > >=20 > > -----Original Message----- > > From: Hubert Kario > > Date: Thursday, April 6, 2017 at 11:03 AM > > To: Anna Johnston > > Cc: Peter Gutmann , Mark Baushke > > , Kyle Rose , Ilari Liusvaara > > , "curdle@ietf.org" , > > "Salz, > > Rich" , Tero Kivinen > >=20 > > Subject: Re: > >=20 > > [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 > >=20 > >=20 > > On Thursday, 6 April 2017 19:38:23 CEST Anna Johnston wrote: > >=20 > >=20 > >=20 > > > Perhaps it would be wise to provide documentation on what is = in > > > the > > > certificate and how it is used to verify primality? That way > > > =E2=80=98trust > > > me=E2=80=99 > > > can be verified mathematically. =20 > >=20 > >=20 > >=20 > > =20 > > It is. If you download the archive, there's a primo.html file > > inside. In > >=20 > > that=20 > > file there is a "What is a primality certificate?" section that > > explains it.=20 > >=20 > > We will Real Soon Now=E2=84=A2 release a pure python verifier f= or the > > Primo=20 > > certificates (in version 4 format). > > =20 > > (if somebody wants it now, I can provide it to them, but the co= de > > has > >=20 > > horrible=20 > > usability currently - it's basically a prototype). > >=20 > > =20 > >=20 > >=20 > >=20 > > > Anna > > >=20 > > > -----Original Message----- > > > From: Hubert Kario > > > Date: Thursday, April 6, 2017 at 6:23 AM > > > To: Peter Gutmann > > > Cc: "Mark D. Baushke" , Kyle Rose > > > , > > > Ilari > >=20 > > Liusvaara , Anna Johnston > >=20 > > > , "curdle@ietf.org" , "Salz, > > > Rich" > > > , Tero Kivinen > > > Subject: Re: [Curdle] > > > draft-ietf-curdle-ssh-modp-dh-sha2 > > >=20 > > >=20 > > >=20 > > > On Thursday, 6 April 2017 14:58:55 CEST Peter Gutmann > > > wrote: > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > Mark D. Baushke writes: > > > >=20 > > > >=20 > > > >=20 > > > > >I don't think we know how effective Nothing Up My Slee= ve > > > > >(NUMS) > > > > >techniques > > > > >will be in the long run. > > > >=20 > > > >=20 > > > >=20 > > > >=20 > > > > Then there's the question of how you generate them. I'd > > > > prefer > > > > something > > > > that can be coded up relatively easily in your bignum > > > > library > > > > of > > > > choice, so > > > > that anybody can verify, using something they've built > > > > themselves, that things are kosher. It's been pointed = out > > > > that > > > > https://kivinen.iki.fi/primes/ contains primality proof= s, > > > > but > > > > what it > > > > really contains is a huge amount of text that doesn't > > > > mean > > > > anything > > > > to > > > > anyone who isn't intimately familiar with the tool used= =2E=20 > > > > This > > > > isn't > > > > in any > > > > way meant as a criticism of Tero, but more to point out > > > > that > > > > saying "here is a large amount of incomprehensible > > > > machine-generated > > > > text, trust me, the primes are OK" reduces directly to > > > > "trust > > > > me, the > > > > primes are OK". Since most people won't be able to make > > > > head or > > > > tail > > > > of what's on that page, the result ends up as "trust me" > > > > again. > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > That how _all of cryptography_ works. > > > =20 > > > Either you understand enough of the maths to follow along= or > > > you > > >=20 > > >=20 > > > delegate it=20 > > > to others and trust them. > > >=20 > > >=20 > > > =20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > > Extending this further, if I wanted to replicate the > > > > results on > > > > that > > > > web > > > > page, I'd end up on > > > > http://www.ellipsa.eu/public/primo/primo.html, an > > > > HTTP > > > > (non- HTTPS) web page with an unsigned, unauthenticated= 7z > > > > file > > > > containing > > > > a binary blob that I'm expected to download and run on a > > > > 64-bit > > > > Linux > > > > box > > > > to verify that my precious crypto parameters aren't > > > > backdoored. > > > >=20 > > > > So, how many people can see the problem here? > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > > =20 > > > the point of generating primality certificates is that you > > > don't > > > care > > >=20 > > >=20 > > > where=20 > > > they come from, either you can verify them and then you know > > > that > > > the number tested is prime or you can't verify it and the num= ber > > > is > > > likely > > > not a prime (or the certificate is bogus) > > >=20 > > >=20 > > > =20 > > > --=20 > > > Regards, > > > Hubert Kario > > > Senior Quality Engineer, QE BaseOS Security team > > > Web: www.cz.redhat.com > > > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno,= Czech > > > Republic > > >=20 > > >=20 > > >=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > --=20 > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech > > Republic > >=20 > >=20 >=20 > =20 > =20 > --=20 > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Repub= lic >=20 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2223874.YKvJWPMz2a Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY52SRAAoJEJKo0bgB0vX1i4gP/j+SzFY//7jCoqAa6HayEoCC QOzQfRwiyEkK6BW2gGeWHhe9thWJutLi5KtoAgZTAW/Yqubemr10UacomOe9wzjE /xFyVUizMEf/4t2YR6ldydB1PRFxeCiuqKHr1MHaJQxRtJkuYPF88r77NN3e3Nw1 juEQAitXFzk7V9PyyUZgB0LVNNDji7lsjR2qfOFp7VbMRqaeSvOwvdvlG10dCyC+ xzAC4HQtk2LlaDK01iW7gvZC5I+NTLPYBrMv1AbsJwOKmMLfLKeyaEhTuxl4+m/a jC/nYJ60zCobJXkkuyna3qSf/77jh4GZdJSitmVlmMaDGcu/M6zL2Ff7u/KdQtY8 Rt2yt/TNAHFrw/+Bl+2lQhjyeyfm0b/UOq06khFbkaIMypcvD6GoPpaOGm7DGiDe 1P4Bx58BlJy73N6ye0RgpSGALxTnht5Dt9wQAuYhxpASmBmWHZcwHYRg65ShenkA objSVJZHa+iTqV/eQGH3Gb+LF0fw6Mewv32yf7gTWumRwMlLaqaa9Rsn2SpALyOQ d0ZIRQF5N9EPPFZ4xMrSsmV7lZ8p2Mjby2ub4dc8KHt4sJhkr2ouoUrzRSpmW8w+ 1ohB3Qulf32apuTZVOEbwNrTN0ZWesFlv16hzsssBHVPr6g4vBWelxTWdqcPjN/r /0NdmUyXbQbWQ3n8h8BF =5y2B -----END PGP SIGNATURE----- --nextPart2223874.YKvJWPMz2a-- From nobody Fri Apr 7 08:22: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 D4F5B1270A0 for ; Fri, 7 Apr 2017 08:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1Ada0BObgwyL for ; Fri, 7 Apr 2017 08:21:56 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 7F207127BA3 for ; Fri, 7 Apr 2017 08:21:54 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id m133so17797182ybb.1 for ; Fri, 07 Apr 2017 08:21:54 -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=G1Zon5pkAJVlhfRYSlI2t349eu6OxE5relxZhY9NAnE=; b=zj4m/WoG/h/lKHK4rQM3myB8SKa4n99BQVoIP9JNES/OTdYhGZja/o2avmv+5Md72x 7LVwRj8NS1UQH0DKFpGYkR5Re9dq+t0pSSvxRopxYpivzWpz7PS0+NvtEJ/fn8tmfR4A g00p4A4DQnm7+rPQZbYBMWgyXieRaL9tlhuh+Rq2EKesoqQSamEgyCaQYOExcrWyWDZo 1bDzUfY/Om3PXm7MuUQZfImuIobFtMhuZ8+5jRvNzNSdNUL+LfVA42f5OH86swZ0RX9v 12/L8oWPTe3B0hJLqeS6j0SQPeE30PU7cdufpLdC3FYRY9vQQPtknT1lgcPrk/XFZGLw Obzg== 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=G1Zon5pkAJVlhfRYSlI2t349eu6OxE5relxZhY9NAnE=; b=TMVRiwjtNTAhzw3wedhKQgUHzOnN82BDo9xllwPJ7n6ZoKN/r1YeO5XruNlaVzzeIV AiBaZ+7P5lAzlBd4ZUcq0ZyJ/Pg11w1G96vCV3k8cFKvi33ecNpGXT3f6kk3mgwGVxfQ P6QsID6OyHPtvrKrpj5lqHLn7LU7Txt22bD7AYFvz+l1SSG74Yp3CLLX1clBp15soewW neNjNuP43JX6wwzeWQ4omX4y/CYsctRGuwU3xmuCU0u9TNViOlmMJ/sVfR24NqqYjUOT z5k1+/+fNm8V/Mvg6tDMQDvlX9Tv8aUqoCKmAwcYT50ecl86rmL+ReOO2VgV5bMEUCKM eqDQ== X-Gm-Message-State: AN3rC/7tI2nnePI+sSjORhHvOergsaegSbVesUv6eqzYRwhmhu9RVCghXrsQVqcv/NhH32/1fFliffAQTS/Naw== X-Received: by 10.37.199.11 with SMTP id w11mr7631338ybe.161.1491578513640; Fri, 07 Apr 2017 08:21:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Fri, 7 Apr 2017 08:21:13 -0700 (PDT) In-Reply-To: References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> From: Eric Rescorla Date: Fri, 7 Apr 2017 08:21:13 -0700 Message-ID: To: denis bider Cc: Peter Gutmann , curdle Content-Type: multipart/alternative; boundary=94eb2c148114762f09054c952fe5 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 07 Apr 2017 15:22:00 -0000 --94eb2c148114762f09054c952fe5 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 6, 2017 at 10:32 PM, denis bider wrote: > > I was thinking of the problem that it's essentially > > impossible to safely do n-RTT, n < 1, for TLS, which > > meant that doing the same thing for SSH wasn't going > > to be any better. I was reasoning by analogy from TLS > > rather than sitting down and drawing diagrams for SSH > > to try and figure out all the possible issues. > > OK, but I'm not familiar with the security implications of this on TLS. > > Can you link to any resources where this was discussed? Whether for TLS, > or in any other context? > Here is the section of TLS 1.3 that describes the security implications of 0-RTT data: https://tlswg.github.io/tls13-spec/#zero-rtt-data FWIW, it's less clear to me that these apply to SSH because at least the replay issues stem from the desire to have loosely coupled distributed servers and seamless fall back from server state or synchronization failure. -Ekr > > > Perhaps adding an implementation note to say that at this > > point the crypto hasn't been confirmed yet and so you may > > want to be careful about what you put into your extension > > data would be useful? > > I agree, if this is a threat, we should add a warning in Security > Considerations. But to make that warning, I have to understand the threat. > > If someone asks me about this warning, I want to be able to explain the > reason in detail. At this point, what I can say is, "Peter said this on the > list." That is, to me, insufficient backing. > > > > Wouldn't "true" and "false" be a better way to express a > > boolean? > > Yes if you could choose the type. But you can't choose the type, because > all extensions have to use the same type. That type is a string. > > > > I realise this is kinda bikeshedding, but having to look > > up the spec just to figure out what mysterious magic > > values in a boolean field specify seems a bit awkward. > > Booleans are equally mysterious. > > The third parameter to the Windows API function WaitForMultipleObjects is > a boolean. Suppose an application passes "TRUE". Without checking the docs > - what does that mean? > > If you check the docs, you know what "TRUE" in that context means. And if > you check the spec here, you know what "p" and "s" mean. > > Booleans are not inherently self-documenting. (In fact - when used in > languages with positional parameters, they are more frequently > self-obfuscating.) > > > > Given that there are a nonzero number of implementations > > that send a window size of ~0 to indicate no flow control, > > it may be useful to add an implementation note to point > > this out. > > OK. I added the following sub-section to my current working copy: > > > 3.3.1. Implementation Note: Prior "No Flow Control" Practice > > Before this extension, some applications would simply not implement > SSH flow control, sending an initial channel window size of 2^32 - 1. > Applications SHOULD NOT do this for the following reasons: > > - It is entirely within the realm of possibility to transfer more than > 2^32 bytes over a channel. The channel will then hang if the other > party implements SSH flow control according to [RFC4254]. > > - There exist implementations which cannot handle such large channel > window sizes, and will exhibit non-graceful behaviors, including > disconnection. > > > denis > > > > On Thu, Apr 6, 2017 at 6:04 AM, Peter Gutmann > wrote: > >> denis bider (Bitvise) writes: >> >> >Can you point out some of these subtle problems that could occur in this >> >regard in SSH? >> >> I was thinking of the problem that it's essentially impossible to safely >> do n- >> RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn't >> going to be any better. I was reasoning by analogy from TLS rather than >> sitting down and drawing diagrams for SSH to try and figure out all the >> possible issues. >> >> >Under the assumption that such an extension were defined, can you point >> out >> >at least one way that sending this info right after NEWKEYS can help an >> >attacker? >> >> It depends on the extension. Without one defined, there's no way to tell >> at >> the moment. I could invent something that works out badly, but that'd be >> creating a strawman... my concern is that in the future someone may >> define a >> problematic extension without realising that they're creating a problem. >> Perhaps adding an implementation note to say that at this point the crypto >> hasn't been confirmed yet and so you may want to be careful about what >> you put >> into your extension data would be useful? >> >> >But the extension value field is generically a string (it must be same >> type >> >for all extensions, so unsupported extensions can be decoded and >> ignored). >> >"p" and "s" are therefore fitting ways to express this boolean. >> >> Wouldn't "true" and "false" be a better way to express a boolean? I >> realise >> this is kinda bikeshedding, but having to look up the spec just to figure >> out >> what mysterious magic values in a boolean field specify seems a bit >> awkward. >> >> >Properly implemented flow control is superior. However, this extension >> is a >> >nod to that not everyone will be using an SSH library that does this >> right, >> >and "no-flow-control" is a better option if your needs are simple, and >> you >> >don't have a few years to get this right. >> >> Given that there are a nonzero number of implementations that send a >> window >> size of ~0 to indicate no flow control, it may be useful to add an >> implementation note to point this out. I enabled some diagnostic code to >> throw an exception in my code if it found this from another implementation >> (other than mine) and got, uh, feedback from beta-testers about it, so at >> least some implementations are using a pseudo-infinite window size to >> indicate >> no flow control. I'm not saying it should be adopted as an alternative to >> "no-flow-control", but merely to alert implementers about the practice, >> e.g. a >> certain big iron vendor whose device would crash and reboot as it tried to >> allocate ~0 bytes of memory to match the widow size. >> >> Peter. >> _______________________________________________ >> 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 > > --94eb2c148114762f09054c952fe5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 6, 2017 at 10:32 PM, denis bider <denisbider.ietf@= gmail.com> wrote:
> I was thinking= of the problem that it's essentially
> impossible = to safely do n-RTT, n < 1, for TLS, which
> meant that doing the same thing for SSH wasn't going
= > to be any better.=C2=A0 I was reasoning by analogy from TLS
= > rather than sitting down and drawing diagrams for SSH
> t= o try and figure out all the possible issues.

OK, but I'm not familiar with the security implications of this on T= LS.

Can you link to any resources where this was d= iscussed? Whether for TLS, or in any other context?

Here is the section of TLS 1.3 that describes the secu= rity implications of
0-RTT data:


FWIW, it'= ;s less clear to me that these apply to SSH because at least the
= replay issues stem from the desire to have loosely coupled distributed
servers and seamless fall back from server state or synchronization f= ailure.

-Ekr



> Perhaps adding an implementation note= to say that at this
> point the crypto hasn't been confir= med yet and so you may
> want to be careful about what you put= into your extension
> data would be useful?

=C2=A0I agree, if this is a threat, we should add a warning = in Security Considerations. But to make that warning, I have to understand = the threat.

If someone asks me about this warning,= I want to be able to explain the reason in detail. At this point, what I c= an say is, "Peter said this on the list." That is, to me, insuffi= cient backing.


> Wouldn't "true" and "false" be a better way= to express a
> boolean?

Yes i= f you could choose the type. But you can't choose the type, because all= extensions have to use the same type. That type is a string.


> I realise this is ki= nda bikeshedding, but having to look
> up the spec just to fig= ure out what mysterious magic
> values in a boolean field spec= ify seems a bit awkward.

Booleans are equal= ly mysterious.

The third parameter to the Windows = API function WaitForMultipleObjects is a boolean. Suppose an application pa= sses "TRUE". Without checking the docs - what does that mean?

If you check the docs, you know what "TRUE"= in that context means. And if you check the spec here, you know what "= ;p" and "s" mean.

Booleans are not = inherently self-documenting. (In fact - when used in languages with positio= nal parameters, they are more frequently self-obfuscating.)


> Given that there are a= nonzero number of implementations
> that send a window size o= f ~0 to indicate no flow control,
> it may be useful to add an= implementation note to point
> this out.=C2=A0

=
OK. I added the following sub-section to my current worki= ng copy:


3.3.1.=C2=A0 Implementatio= n Note: Prior "No Flow Control" Practice

=C2=A0 Before this extension, some applications would simply not implement=
=C2=A0 SSH flow control, sending an initial channel window size = of 2^32 - 1.
=C2=A0 Applications SHOULD NOT do this for the follo= wing reasons:
=C2=A0=C2=A0
=C2=A0 - It is entirely with= in the realm of possibility to transfer more than
=C2=A0 =C2=A0 2= ^32 bytes over a channel. The channel will then hang if the other
=C2=A0 =C2=A0 party implements SSH flow control according to [RFC4254].
=C2=A0 =C2=A0=C2=A0
=C2=A0 - There exist implementations = which cannot handle such large channel
=C2=A0 =C2=A0 window sizes= , and will exhibit non-graceful behaviors, including
=C2=A0 =C2= =A0 disconnection.


denis


=

On Thu, Apr 6, 20= 17 at 6:04 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bide= r (Bitvise) <ietf-ssh3@denisbider.com> writes:

>Can you point out some of these subtle problems that could occur in thi= s
>regard in SSH?

I was thinking of the problem that it's essentially impossible to safel= y do n-
RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn&= #39;t
going to be any better.=C2=A0 I was reasoning by analogy from TLS rather th= an
sitting down and drawing diagrams for SSH to try and figure out all the
possible issues.

>Under the assumption that such an extension were defined, can you point= out
>at least one way that sending this info right after NEWKEYS can help an=
>attacker?

It depends on the extension.=C2=A0 Without one defined, there's no way = to tell at
the moment.=C2=A0 I could invent something that works out badly, but that&#= 39;d be
creating a strawman... my concern is that in the future someone may define = a
problematic extension without realising that they're creating a problem= .
Perhaps adding an implementation note to say that at this point the crypto<= br> hasn't been confirmed yet and so you may want to be careful about what = you put
into your extension data would be useful?

>But the extension value field is generically a string (it must be same = type
>for all extensions, so unsupported extensions can be decoded and ignore= d).
>"p" and "s" are therefore fitting ways to express t= his boolean.

Wouldn't "true" and "false" be a better way to expr= ess a boolean?=C2=A0 I realise
this is kinda bikeshedding, but having to look up the spec just to figure o= ut
what mysterious magic values in a boolean field specify seems a bit awkward= .

>Properly implemented flow control is superior. However, this extension = is a
>nod to that not everyone will be using an SSH library that does this ri= ght,
>and "no-flow-control" is a better option if your needs are si= mple, and you
>don't have a few years to get this right.

Given that there are a nonzero number of implementations that send a window=
size of ~0 to indicate no flow control, it may be useful to add an
implementation note to point this out.=C2=A0 I enabled some diagnostic code= to
throw an exception in my code if it found this from another implementation<= br> (other than mine) and got, uh, feedback from beta-testers about it, so at least some implementations are using a pseudo-infinite window size to indic= ate
no flow control.=C2=A0 I'm not saying it should be adopted as an altern= ative to
"no-flow-control", but merely to alert implementers about the pra= ctice, e.g. a
certain big iron vendor whose device would crash and reboot as it tried to<= br> allocate ~0 bytes of memory to match the widow size.

Peter.
_______________________________________________
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

--94eb2c148114762f09054c952fe5-- From nobody Fri Apr 7 09:31: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 3F9D31294F0 for ; Fri, 7 Apr 2017 09:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 MS21VWY1BSx6 for ; Fri, 7 Apr 2017 09:31:09 -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 2A06A12951D for ; Fri, 7 Apr 2017 09:30:16 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id s141so9280981lfe.3 for ; Fri, 07 Apr 2017 09:30:16 -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=CZn7LW+lZziEgsc4NBKl/I+dL97ouLD39FFuNLpQdHM=; b=MQMYbJ3DTi5alqpIeNOiz2PId3RWDMGKEQAMtwYuLiWk+GqrrFEM9Bv12K+mUFRUeo eMmHEoDJ+32GKRTs27LXVUemfL+x/8FIrkVbyzByPVHVyDHav8wsyniByfvgzbz5Zxs9 pfXXLDYdFhnD/S5WQ+ipvH3uNWEN6xoz6zSxBR/rF7SQ2n/ETi9nc+6iTTGkeU1Xtf6J yY5oytytl5VrSpMgCVolCQTDeE/oa95/dIn2hy8whl658DMTfw6HyCP1Q7MvqBdGFu98 9/7ZMOCmOxi3E2hJb1xw4p+fnBFpyKraZ4P/f7JEXpZ5uSQdGHHOjNLb7Kz9jzaJBse0 1QVQ== 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=CZn7LW+lZziEgsc4NBKl/I+dL97ouLD39FFuNLpQdHM=; b=t4qPDcjVMOzJPUQSmV2qWDGMYX6uJfErg9kyqG3IKYx2A3cLDlkIFZcNw9a1fx7w/b aeVTGQ6KjAgqtsq+dOF8ZUvJxO2Gsuf73RvcT53jPHFsLqo9D7P1IRGFf9/yi/BPgsOf /u/Pz2auJaKMwulZqrCXOIhK4wAsdxjYxoiLGPzKikpNI7lcNV8DS5DL7HYRsyJCQcCJ pySOXL1H6ZQL9d4+dLPZ2GqEx8VpqZwgIP+RTjxzF9bJzYj2VsZqF+gGG9htvbhQmqZL kDIejBPeylfVsVVGfJr27EQuK86td+WzJ7Wjl3Xv7H1kv6h/Fce9CYBJklZbUQ+5v1Rj 7dTg== X-Gm-Message-State: AFeK/H1E4IPHhGEpFBlGgJNNZHNmiMLmkfMgrcEEgmW28feuPkIMfhMDctgMyLIkTKe006aOjPSHporWiJF04A== X-Received: by 10.25.20.202 with SMTP id 71mr15127226lfu.102.1491582614397; Fri, 07 Apr 2017 09:30:14 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 09:30:13 -0700 (PDT) In-Reply-To: <05d701d2a8b6$d1895bc0$749c1340$@augustcellars.com> References: <059001d2a8a0$da207680$8e616380$@augustcellars.com> <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> <05d701d2a8b6$d1895bc0$749c1340$@augustcellars.com> From: Daniel Migault Date: Fri, 7 Apr 2017 12:30:13 -0400 X-Google-Sender-Auth: fhu56gSN16gzkvrW8qeajTpPimg Message-ID: To: Jim Schaad Cc: Russ Housley , curdle Content-Type: multipart/alternative; boundary=001a113fb2fce2686b054c9623e2 Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 07 Apr 2017 16:31:12 -0000 --001a113fb2fce2686b054c9623e2 Content-Type: text/plain; charset=UTF-8 Hi, Please find my comments regarding the draft. This is mostly nits and minor changes and I believe that the next version will be ready to be sent to the IESG. Any concerned on this draft shoudl be raised before the last call ends. Yours, Daniel 1) nits tool the nits tools returns the following additional error: == The "Author's Address" (or "Authors' Addresses") section title is misspelled. 2) section 2.1 defining KEK OLD: To generate a key-encryption key, generates one or more KM blocks, NEW: To generate a key-encryption key (KEK), KDF generates one or more KM blocks, 3) section 2.2 defining HKDF OLD: The HKDF key derivation function is a robust construct based on a one-way hash function described in RFC 5869 [HKDF]. NEW: The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a robust construct based on a one-way hash function described in RFC 5869 [HKDF]. 4) IANA section: * Wouldn't it be appropriated to mention RFC7107 section 3.3 and section 3.6 for each allocation. * I have been recommended to ask to add the IANA link hosting the registries as an informational reference. In that case, that would be the following one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smime-3 * The presentation in the IANA section differs from the one of RFC7107 which uses a table with Decimal , Description, Reference rather than using the OID presentation. * I am wondering whether the current draft does not update RFC7107, in which case it should be mentioned in the header, abstract and introduction. What do you think ? On Wed, Mar 29, 2017 at 2:03 PM, Jim Schaad wrote: > > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Wednesday, March 29, 2017 12:40 PM > > To: Jim Schaad > > Cc: curdle > > Subject: Re: Review of draft-ietf-curdle-cms-ecdh-new-curves-02 > > > > Jim: > > > > > Major > > > > > 3. In section 2 - note that the 32-bit number is encoded in network > > > by order. This can be inferred from the example but being explicit is > > > always good. > > > > I think this is the text you are talking about: > > > > To generate a key-encryption key, generates one or more KM blocks, > with > > the counter starting at 0x00000001, and incrementing the counter for > each > > subsequent KM block until enough material has been generated. The > 32-bit > > counter is represented in network byte order. The KM blocks are > > concatenated left to right to produce the pairwise key-encryption key, > > KEK: > > > > Let me know if you meant something else. > > wfm > > > > > > 4. Section 6 is incorrect for the X25519 and X448 curves. > > > > Right. This needs simple point to draft-ietf-curdle-pkix for the > details: > > > > RFC 5280 [PROFILE] specifies the profile for using X.509 Certificates > in > > Internet applications. A recipient static public key is needed for > X25519 > > or X448, and the originator obtains that public key from the > recipient's > > certificate. The conventions for carrying X25519 and X448 public keys > are > > specified in [ID.curdle-pkix]. > > wfm > > Jim > > > > > Thanks for your review. > > > > Russ > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113fb2fce2686b054c9623e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

<= /div>Please find my comments regarding the draft. This is mostly nits and m= inor changes and I believe that the next version will be ready to be sent t= o the IESG. Any concerned on this draft shoudl be raised before the last ca= ll ends.

Yours,

Daniel

1) nit= s tool
the nits tools returns the following additional error:
<= br>=3D=3D The "Author's Address" (or "Authors' Addre= sses") section title is
=C2=A0=C2=A0=C2=A0=C2=A0 misspelled.
2) section 2.1 defining KEK

OLD:
To genera= te a key-encryption key, generates one or more KM blocks,

NEW:
To generate a key-encryption key (KEK), KDF generates one or more = KM blocks,

3) section 2.2 defining HKDF
OLD:
The HKDF key derivation function is a robust construct = based on a one-way hash function described in RFC 5869 [HKDF].

NEW:
The HMAC-based Extract-and-Expand Key Derivation F= unction (HKDF) is a robust construct based on a one-way hash function descr= ibed in RFC 5869 [HKDF].


4) IANA section:

* = Wouldn't it be appropriated to mention RFC7107 section 3.3 and section = 3.6 for each allocation.
* I have been recommended to ask to add = the IANA link hosting the registries as an informational reference. In that= case, that would be the following one: http://www.iana.org= /assignments/smi-numbers/smi-numbers.xhtml#security-smime-3
* = The presentation in the IANA section differs from=C2=A0 the one of RFC7107 = which uses a table with Decimal , Description, Reference rather than using = the OID presentation.
* I am wondering whether the current draft d= oes not update RFC7107, in which case it should be mentioned in the header= , abstract and introduction. What do you think ?






=C2=A0

On Wed, Mar 29, 2017 at 2:03 PM, Jim Schaad <ietf@augustcellars.co= m> wrote:


> -----Original Message-----
> From: Russ Housley [mailto:hou= sley@vigilsec.com]
> Sent: Wednesday, March 29, 2017 12:40 PM
> To: Jim Schaad <ietf@augu= stcellars.com>
> Cc: curdle <curdle@ietf.org&= gt;
> Subject: Re: Review of draft-ietf-curdle-cms-ecdh-new-curves-02 >
> Jim:
>
> > Major
>
> > 3.=C2=A0 In section 2 - note that the 32-bit number is encoded in= network
> > by order.=C2=A0 This can be inferred from the example but being e= xplicit is
> > always good.
>
> I think this is the text you are talking about:
>
>=C2=A0 =C2=A0 To generate a key-encryption key, generates one or more K= M blocks, with
>=C2=A0 =C2=A0 the counter starting at 0x00000001, and incrementing the = counter for
each
>=C2=A0 =C2=A0 subsequent KM block until enough material has been genera= ted.=C2=A0 The
32-bit
>=C2=A0 =C2=A0 counter is represented in network byte order.=C2=A0 The K= M blocks are
>=C2=A0 =C2=A0 concatenated left to right to produce the pairwise key-en= cryption key,
>=C2=A0 =C2=A0 KEK:
>
> Let me know if you meant something else.

wfm

>
> > 4.=C2=A0 Section 6 is incorrect for the X25519 and X448 curves. >
> Right.=C2=A0 This needs simple point to draft-ietf-curdle-pkix for the= details:
>
>=C2=A0 =C2=A0 RFC 5280 [PROFILE] specifies the profile for using X.509 = Certificates
in
>=C2=A0 =C2=A0 Internet applications.=C2=A0 A recipient static public ke= y is needed for
X25519
>=C2=A0 =C2=A0 or X448, and the originator obtains that public key from = the
recipient's
>=C2=A0 =C2=A0 certificate.=C2=A0 The conventions for carrying X25519 an= d X448 public keys
are
>=C2=A0 =C2=A0 specified in [ID.curdle-pkix].

wfm

Jim

>
> Thanks for your review.
>
> Russ


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

--001a113fb2fce2686b054c9623e2-- From nobody Fri Apr 7 11:15:16 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 38863124234 for ; Fri, 7 Apr 2017 11:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 4KltHUG86mIH for ; Fri, 7 Apr 2017 11:15:10 -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 CB875128C82 for ; Fri, 7 Apr 2017 11:15:09 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id q141so16216800lfe.2 for ; Fri, 07 Apr 2017 11:15:09 -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=Drb9QdZJzQ+h5G4AcirJg+PcUQEd2JG5kO8rcWaxvdw=; b=JRALmzLxFIU4pYOSTauuQn2NqIOzWSfomWqJJPYOSof2HnDA19HjrEnBl2Jd21ze2r 0A0UL5GdhBF0AFDCCnuDru/J8P2RLn/psJMxVYWFINjUXfX6Z3+nxbbKEOli74UExDSt 1RsXbTPPKiwx/nfaovlSoUAjdTrmwksPnOe7oDoF0OZvmHCXBuq9W8nqbAYA5L0c5GCJ MVnBuq39L51ehCQyWSLkCCWzwQXy0F9ChB++RlxoDM57ALRtpGvGu/Eo7S6FdxfP8h9K Lwf3gAFrfKiSeMLuyOLaFXRT/lVrOndkaXwOGnS1UoHJRmnsbMxUSiB+qAhTZV3em3zE oOZw== 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=Drb9QdZJzQ+h5G4AcirJg+PcUQEd2JG5kO8rcWaxvdw=; b=eyxRfmBe3+i0h8PTXTATC8ZYhX2GKiiI74Jn6yxvvc3OSpMUy9SG6xpUMvSVV5Vica Wgh4qmZkDNv0fOg3pUnV/xv7SkurL3mVnFDNBCaHqruDySpnLcNTbzMwIF76D1DDcMvD iMoTfPyBJ828StW5bv1MYYfw86KDsOiOF4yL5PDuX7CvHI/S+Kkly21s2XB29moKf56N Hc7YbiFcpx2gTJKR+zCCBQo0GQ1tmgSP5IOk/kjc+lBBs/8rG6azDnLl63YzX7TN92qX ND1lSz0rXoY6J3oEKWtqw1Hk+y+jWjCoPpmIzvzPqurIvLrzbgk5RAqga0oAPB9FpVhG 5SEw== X-Gm-Message-State: AFeK/H130tHta1/UGBa3dhWRDzSY+C2hYEbXoY7tSToI66ut9W8r955KeFM6ef2PzpZoeZvbdD1ybmRI6SkO0Q== X-Received: by 10.25.141.73 with SMTP id p70mr14691443lfd.147.1491588907955; Fri, 07 Apr 2017 11:15:07 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 11:15:07 -0700 (PDT) In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41C0@eusaamb107.ericsson.se> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41C0@eusaamb107.ericsson.se> From: Daniel Migault Date: Fri, 7 Apr 2017 14:15:07 -0400 X-Google-Sender-Auth: 3Wlk_4hQ_x-mSPyEbkyvBMbNG0U Message-ID: To: Russ Housley Cc: curdle Content-Type: multipart/alternative; boundary=001a1140374a027ca6054c979bd8 Archived-At: Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.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, 07 Apr 2017 18:15:14 -0000 --001a1140374a027ca6054c979bd8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The nit tool reports the following warnings/errors: Checking nits according to http://www.ietf.org/id-info/checklist : -------------------------------------------------------------------------= --- ** The document seems to lack an IANA Considerations section. (See Secti= on 2.2 of http://www.ietf.org/id-info/checklist for how to handle the cas= e when there are no actions for IANA.) Miscellaneous warnings: -------------------------------------------------------------------------= --- =3D=3D The "Author's Address" (or "Authors' Addresses") section title is misspelled. Just for clarification, IANA registries do not register IODs outside their arc. Am I correct ? [1] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security= -smime-9 On Fri, Mar 10, 2017 at 4:39 PM, Daniel Migault wrote: > Thank you Russ for the responses. They were useful to me. > > Yours, > Daniel > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Friday, March 10, 2017 12:13 PM > To: Daniel Migault > Cc: curdle > Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa- > signatures-03.txt > > Daniel: > > > Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) > > > > > > 2. EdDSA Signature Algorithm > > > > One of the parameters of the EdDSA algorithm is the "prehash" > > function. This may be the identity function, resulting in an > > algorithm called PureEdDSA, or a collision-resistant hash function, > > resulting in an algorithm called HashEdDSA. In most situations the > > CMS SignedData includes signed attributes, including the message > > digest of the content. Since HashEdDSA offers no benefit when signed > > attributes are present, only PureEdDSA is used with the CMS. > > > > MGLT: My understanding of the two latest sentences is that, in most > cases the CMS when used with signed attributes may specify the hash of th= e > content. As prehashing is performed by CMS, there is no need to have a pr= e > hash variant version. > > > > From the two sentences it may appear that without signed attributes, > they might be some advantages of having HashEdDSA over PureEdDSA. If that > is the case, maybe we should provide them and then motivate our choice. > > > > What is unclear to me is why signed attributed make it different ? My > understanding is that in any case digestAlgorithm is used to compute the > digest of the eContent and when defined additional signed attributes. > > CMS supports signatures with and without signed attributes. In most > cases, signed attributes are present. When signed attributes are present= , > the message-digest attribute MUST be one of the attributes. It was signe= d > to work like this: > > IF (signed attributes are absent) > THEN md =3D Hash(content) > ELSE message-digest attribute =3D Hash(content); > md =3D Hash(DER(SignedAttributes)) > > Sign(md) > > > I am also wondering if we were using the prehash variant a combination > of digestAlgorithm with the prehash function would not be problematic. At > least, the signing operation would not be performed on the same content > this might add unnecessary overhead. If that is the case, it would provid= e > a generic motivation to only consider PureHash with CMS. > > Yes, HashEdDSA could be useful when signed attributes are present. I was > not including HashEdDSA in this document because curdle-pkix did not > support that algorithm. If that changes (as is being discussed on a > separate thread), then it should be supported here as well. > > > My understanding of EdDSA is that when PureEdDSA is possible, it is > always recommended over HashEdDSA. I assume this is also recommended for > CMS. > > We could RECOMMEND PureEdDSA when signed attributes are present, and we > could RECOMMEND PureEdDSA when signed attributes are absent, but the > content is not very large. > > > > 2.3. Message Digest Algorithm Identifiers > > > > When the signer includes signed attributes, a message digest > > algorithm is used to compute the message digest on the eContent > > value. When signing with Ed25519, the message digest algorithm MUST > > be SHA-512 [RFC4634]. When signing with Ed448, the message digest > > algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value. > > > > MGLT: I am wondering why the digestAlgorithm cannot be the identity. > > Since CMS allows multiple signatures on the content, the idea is to tell > the implementation which hash functions are needed in a field that appear= s > before the content that needs to be hashed. > > > Signing with Ed25519 uses SHA-512 as part of the signing operation, > > and signing with Ed448 uses SHAKE256 as part of the signing > > operation. > > > > MGLT: I am wondering if the text above wants to specify that the digest > algorithm specified are already part of the signature and as such no > additional hash functions really need to be added or if there is another > motivation for this text. > > This is the rationale for the earlier statement. > > > For convenience, the object identifiers and parameter syntax for > > these algorithms are repeated here: > > > > MGLT: IOD are repeated, maybe we could add a reference where these hav= e > been defined. -- Note that the ref becomes clearer on the next page. > > These OIDs all come from the NIST website, but NIST does not publish an > ASN.1 module that includes them. > > Most of them appear in the ASN.1 module in the curdle-pkix document. I > should probably add a module to this document too. > > > > 2.4. EdDSA Signatures > > > > The id-Ed25519 and id-Ed448 object identifiers are also used for > > signature values. When used to identify signature algorithms, the > > AlgorithmIdentifier parameters field MUST be absent. > > > > MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for the > signature value. My understanding is that the Signer Info carries the > signature algorithm, which defines the signature. > > SignerInfo ::=3D SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } > > This text is talking about the SignatureAlgorithmIdentifier, which uses > the same OID as the subject public key in the certificate that will be us= ed > to validate the signature. > > > > 3. Signed-data Conventions > > > > The processing depends on whether the signer includes signed > > attributes. > > > > The inclusion of signed attributes is preferred, but the conventions > > for signed-data without signed attributes are provided for > > completeness. > > > > MGLT: Maybe we could briefly explain or provide a reference why signed > attributes are preferred. > > This is a statement about what most implementation do. S/MIME says that > sending agents SHOULD include signed attributes, and I cannot think of an= y > that don=E2=80=99t do so. > > > > 3.1. Signed-data Conventions With Signed Attributes > > > > The SignedData digestAlgorithms field includes the identifiers of th= e > > message digest algorithms used by one or more signer. There MAY be > > any number of elements in the collection, including zero. When > > signing with Ed25519, the digestAlgorithm SHOULD include id-sha512, > > and if present, the algorithm parameters field MUST be absent. When > > > > signing with Ed448, the digestAlgorithm SHOULD include > > id-shake256-len, and if present, the algorithm parameters field MUST > > also be present, and the parameter MUST contain 512, encoded as a > > positive integer value. > > > > MGLT: For which reason do we have a SHOULD and not a MUST, as the hash > function specified have a MUST status in te message digest identifier. > > This is at odds with your comment on section 2. I=E2=80=99m fine with ma= king this > a MUST. > > Russ > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1140374a027ca6054c979bd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The nit tool reports the follo= wing warnings/errors:

  Checking nits according to http://www.ietf.org/id-info/checklist=
 :
  -------------------------------------------------------------------------=
---

  ** The document seems to lack an IANA Considerations section.  (See Secti=
on
     2.2 of http://www.ie=
tf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)


  Miscellaneous warnings:
  -------------------------------------------------------------------------=
---

  =3D=3D The "Author's Address" (or "Authors' Addres=
ses") section title is
     misspelled.

Just for clarification, IANA registries =
do not register IODs outside their arc. Am I correct ? 

[1] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#se=
curity-smime-9
=C2=A0

On Fri, Mar 10, 2017 at 4:39 PM, Daniel Mi= gault <daniel.migault@ericsson.com> wrote:
Thank you Russ for the responses. They were usef= ul to me.

Yours,
Daniel

-----Original Message-----
From: Russ Housley [mailto:housley@= vigilsec.com]
Sent: Friday, March 10, 2017 12:13 PM
To: Daniel Migault <danie= l.migault@ericsson.com>
Cc: curdle <curdle@ietf.org> Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatu= res-03.txt

Daniel:

>=C2=A0 =C2=A0 Use of EdDSA Signatures in the Cryptographic Message Synt= ax (CMS)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<draft-ietf-curdle-c= ms-eddsa-signatures-03.txt>
>
> 2.=C2=A0 EdDSA Signature Algorithm
>
>=C2=A0 =C2=A0 One of the parameters of the EdDSA algorithm is the "= ;prehash"
>=C2=A0 =C2=A0 function.=C2=A0 This may be the identity function, result= ing in an
>=C2=A0 =C2=A0 algorithm called PureEdDSA, or a collision-resistant hash= function,
>=C2=A0 =C2=A0 resulting in an algorithm called HashEdDSA.=C2=A0 In most= situations the
>=C2=A0 =C2=A0 CMS SignedData includes signed attributes, including the = message
>=C2=A0 =C2=A0 digest of the content. Since HashEdDSA offers no benefit = when signed
>=C2=A0 =C2=A0 attributes are present, only PureEdDSA is used with the C= MS.
>
> MGLT: My understanding of the two latest sentences is that, in most ca= ses the CMS when used with signed attributes may specify the hash of the co= ntent. As prehashing is performed by CMS, there is no need to have a pre ha= sh variant version.
>
> From the two sentences it may appear that without signed attributes, t= hey might be some advantages of having HashEdDSA over PureEdDSA. If that is= the case, maybe we should provide them and then motivate our choice.
>
> What is unclear to me is why signed attributed make it different ? My = understanding is that in any case digestAlgorithm is used to compute the di= gest of the eContent and when defined additional signed attributes.

CMS supports signatures with and without signed attributes.=C2=A0 In most c= ases, signed attributes are present.=C2=A0 When signed attributes are prese= nt, the message-digest attribute MUST be one of the attributes.=C2=A0 It wa= s signed to work like this:

=C2=A0 =C2=A0 =C2=A0 IF (signed attributes are absent)
=C2=A0 =C2=A0 =C2=A0 THEN md =3D Hash(content)
=C2=A0 =C2=A0 =C2=A0 ELSE message-digest attribute =3D Hash(content);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0md =3D Hash(DER(SignedAttributes))=

=C2=A0 =C2=A0 =C2=A0 Sign(md)

> I am also wondering if we were using the prehash variant a combination= of digestAlgorithm with the prehash function would not be problematic. At = least, the signing operation would not be performed on the same content thi= s might add unnecessary overhead. If that is the case, it would provide a g= eneric motivation to only consider PureHash with CMS.

Yes, HashEdDSA could be useful when signed attributes are present.=C2=A0 I = was not including HashEdDSA in this document because curdle-pkix did not su= pport that algorithm.=C2=A0 If that changes (as is being discussed on a sep= arate thread), then it should be supported here as well.

> My understanding of EdDSA is that when PureEdDSA is possible, it is al= ways recommended over HashEdDSA. I assume this is also recommended for CMS.=

We could RECOMMEND PureEdDSA when signed attributes are present, and we cou= ld RECOMMEND PureEdDSA when signed attributes are absent, but the content i= s not very large.


> 2.3.=C2=A0 Message Digest Algorithm Identifiers
>
>=C2=A0 =C2=A0 When the signer includes signed attributes, a message dig= est
>=C2=A0 =C2=A0 algorithm is used to compute the message digest on the eC= ontent
>=C2=A0 =C2=A0 value.=C2=A0 When signing with Ed25519, the message diges= t algorithm MUST
>=C2=A0 =C2=A0 be SHA-512 [RFC4634].=C2=A0 When signing with Ed448, the = message digest
>=C2=A0 =C2=A0 algorithm MUST be SHAKE256 [FIPS202] with a 512-bit outpu= t value.
>
> MGLT: I am wondering why the digestAlgorithm cannot be the identity.
Since CMS allows multiple signatures on the content, the idea is to tell th= e implementation which hash functions are needed in a field that appears be= fore the content that needs to be hashed.

>=C2=A0 =C2=A0 Signing with Ed25519 uses SHA-512 as part of the signing = operation,
>=C2=A0 =C2=A0 and signing with Ed448 uses SHAKE256 as part of the signi= ng
>=C2=A0 =C2=A0 operation.
>
> MGLT: I am wondering if the text above wants to specify that the diges= t algorithm specified are already part of the signature and as such no addi= tional hash functions really need to be added or if there is another motiva= tion for this text.

This is the rationale for the earlier statement.

>=C2=A0 =C2=A0 For convenience, the object identifiers and parameter syn= tax for
>=C2=A0 =C2=A0 these algorithms are repeated here:
>
>=C2=A0 MGLT: IOD are repeated, maybe we could add a reference where the= se have been defined. -- Note that the ref becomes clearer on the next page= .

These OIDs all come from the NIST website, but NIST does not publish an ASN= .1 module that includes them.

Most of them appear in the ASN.1 module in the curdle-pkix document.=C2=A0 = I should probably add a module to this document too.


>=C2=A0 2.4.=C2=A0 EdDSA Signatures
>
>=C2=A0 =C2=A0 The id-Ed25519 and id-Ed448 object identifiers are also u= sed for
>=C2=A0 =C2=A0 signature values.=C2=A0 When used to identify signature a= lgorithms, the
>=C2=A0 =C2=A0 AlgorithmIdentifier parameters field MUST be absent.
>
> MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for the= signature value. My understanding is that the Signer Info carries the sign= ature algorithm, which defines the signature.

=C2=A0 =C2=A0 =C2=A0 SignerInfo ::=3D SEQUENCE {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 version CMSVersion,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 sid SignerIdentifier,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 digestAlgorithm DigestAlgorithmIdentifier,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signedAttrs [0] IMPLICIT SignedAttributes OPTIO= NAL,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signatureAlgorithm SignatureAlgorithmIdentifier= ,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 signature SignatureValue,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 unsignedAttrs [1] IMPLICIT UnsignedAttributes O= PTIONAL }

This text is talking about the SignatureAlgorithmIdentifier, which uses the= same OID as the subject public key in the certificate that will be used to= validate the signature.


> 3.=C2=A0 Signed-data Conventions
>
>=C2=A0 =C2=A0 The processing depends on whether the signer includes sig= ned
>=C2=A0 =C2=A0 attributes.
>
>=C2=A0 =C2=A0 The inclusion of signed attributes is preferred, but the = conventions
>=C2=A0 =C2=A0 for signed-data without signed attributes are provided fo= r
>=C2=A0 =C2=A0 completeness.
>
> MGLT: Maybe we could briefly explain or provide a reference why signed= attributes are preferred.

This is a statement about what most implementation do.=C2=A0 S/MIME says th= at sending agents SHOULD include signed attributes, and I cannot think of a= ny that don=E2=80=99t do so.


> 3.1.=C2=A0 Signed-data Conventions With Signed Attributes
>
>=C2=A0 =C2=A0 The SignedData digestAlgorithms field includes the identi= fiers of the
>=C2=A0 =C2=A0 message digest algorithms used by one or more signer.=C2= =A0 There MAY be
>=C2=A0 =C2=A0 any number of elements in the collection, including zero.= =C2=A0 When
>=C2=A0 =C2=A0 signing with Ed25519, the digestAlgorithm SHOULD include = id-sha512,
>=C2=A0 =C2=A0 and if present, the algorithm parameters field MUST be ab= sent.=C2=A0 When
>
>=C2=A0 =C2=A0 signing with Ed448, the digestAlgorithm SHOULD include >=C2=A0 =C2=A0 id-shake256-len, and if present, the algorithm parameters= field MUST
>=C2=A0 =C2=A0 also be present, and the parameter MUST contain 512, enco= ded as a
>=C2=A0 =C2=A0 positive integer value.
>
>=C2=A0 MGLT: For which reason do we have a SHOULD and not a MUST, as th= e hash function specified have a MUST status in te message digest identifie= r.

This is at odds with your comment on section 2.=C2=A0 I=E2=80=99m fine with= making this a MUST.

Russ

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

--001a1140374a027ca6054c979bd8-- From nobody Fri Apr 7 11:43: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 27680129550 for ; Fri, 7 Apr 2017 11:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 jt9VwxOwhkGC for ; Fri, 7 Apr 2017 11:43:06 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FF3B1294A0 for ; Fri, 7 Apr 2017 11:43:06 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id z15so46501084lfd.1 for ; Fri, 07 Apr 2017 11:43:06 -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=3fzClIh6BQhjvMEQqGEQ2HtNVHZDPjfCXmr7eCXjb1s=; b=f0qRlFsMeqxn4xCMq9biEwLArIO3bTrbWTNyam+sP+HstP5wfQrYa+YqvlYjBALo2Z fRtQnStUs6fRxC3V9RQIqh2bV5rfjtoknslOlGi+AIyQaqI9IJfV4LascH8hrSG834nc LvjYwDxfFVwRKx8cMzxQ+vjwGUNEo06xZi0pz2TECWiwYQry3NNpX3j5t2xHuQ1NSvZS JPkBCNYAP+f7QU80FSRd6TqU9FXnl4gVcrylYtu2CWe6pZesJ483oS2u61b0CyTnr89/ TIqe59dAWuZHJPJDO35/t3v+eicBYfKrA/bTOFksG312T6MhMHDaFfudIQm6cEz7Cbxg M9iA== 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=3fzClIh6BQhjvMEQqGEQ2HtNVHZDPjfCXmr7eCXjb1s=; b=rDxOkhYp7Xp8UgKbS7K9SpjAdK05CefRB1BzG7zAOfXuqEnT60SrJRzOpdpHcxD4eB Y+JAqvCNaUdRC9oKKwpQTWZvhqEti+UPhwkLMkW4lJaD889AAEuwx4fBqnMKyn0MRGi0 xLbuhHFqBXQXKD/ZgdD3UWrWLU5DOUHJ8Gex2LQ5inJdPQ1guSJOFKK6IAzxM82WTCTj 9HgmjM5tjRcB/fUKMWTtKGFp/25ivFv9FndUBygJKYoFn6ZMFQG78ua9bDgYQ7y9bsnW f+Zi22V3Pc4I9RPD/YcrJ0dOpN9/O2c8x/5KbqKDxC9JhKd+XhIuzejeUjP1AxMoXCUK 7ZNg== X-Gm-Message-State: AFeK/H1NzxaPpOULRWjRg1ylNPvwnf8Fr9wAqeVjmXbKg3k+HlVBNWSBpxvfKcg/uPiG2N2j3jmWxZbeSXqD2Q== X-Received: by 10.46.33.135 with SMTP id h7mr12060590lji.96.1491590584610; Fri, 07 Apr 2017 11:43:04 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 11:43:03 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Fri, 7 Apr 2017 14:43:03 -0400 X-Google-Sender-Auth: XhdCFqLypTX2CSYmozQLU7w1uqs Message-ID: To: denis bider Cc: Ilari Liusvaara , "curdle@ietf.org" , Peter Gutmann Content-Type: multipart/alternative; boundary=001a1142b632f2342e054c97fecf Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 07 Apr 2017 18:43:09 -0000 --001a1142b632f2342e054c97fecf Content-Type: text/plain; charset=UTF-8 Hi, In the chicago meeting [1], the consensus seems that even though pss would be defined, there is no plane to implement nor to use it. I am confirming this consensus on the mailing list. If you desagree with that, please raise your opinion. If not we will move the draft forward. The nits tool on the current version provides teh following output: [1] https://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00.txt Checking nits according to http://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4253, but the abstract doesn't seem to mention this, which it should. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3629' is mentioned on line 100, but not defined == Unused Reference: 'RFC4250' is defined on line 298, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' ** Obsolete normative reference: RFC 3447 yours, Daniel On Mon, Mar 27, 2017 at 4:51 PM, denis bider wrote: > That is a welcome assurance. If PSS is added, it sounds like something to > mention in Security Considerations as a further argument against small keys. > > On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara > wrote: > >> On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote: >> > Whether pss variant have to be added is up to the WG to decide. That I >> > would be in favor is only one opinion ;-) [1] lists some advantages of >> PSS >> > vs PKCS1v1.5. Note that enabling a given key may be used by two variants >> > needs also some thoughts. I will raise the question during the meeting, >> but >> > discussion will be made on the mailing list. >> >> This thing came up in context of TLS 1.3. >> >> The probability PKCS#1v1.5 and PSS signature overlaps depends on key >> size and salt size. Where overlap is defined as encoded message that >> is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm >> and number of bits in n, but not precise value of n. >> >> TLS restricts salt length to be the same as hash length. Which makes >> overlaps highly unlikely with key sizes >=2048 bits and hash sizes >> <=512 bits. The problem being to control ~1000 bits using 512 bits. >> >> As key size decreases or salt size increases, the overlap probability >> increases, and eventually overlaps become almost certain, and further >> one gets multiple overlaps. >> >> > >> > [1] >> > https://www.emc.com/emc-plus/rsa-labs/historical/raising-sta >> ndard-rsa-signatures-rsa-pss.htm >> >> >> -Ilari >> > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --001a1142b632f2342e054c97fecf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In the chicago meeting [1], the consensus seem= s that even though pss would be defined, there is no plane to implement nor= to use it. I am confirming this consensus on the mailing list. If you desa= gree with that, please raise your opinion. If not we will move the draft fo= rward. =C2=A0

The nits tool on the current version provides teh fol= lowing output:

[1] https://www.ietf.org/proceedings/98/minutes= /minutes-98-curdle-00.txt

  Checking nits according to http://www.ietf.org/id-info/c=
hecklist :
  -------------------------------------------------------------------------=
---

  -- The draft header indicates that this document updates RFC4252, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC4253, but the
     abstract doesn't seem to mention this, which it should.


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but =
may
     have content which was first submitted before 10 November 2008.  If yo=
u
     have contacted all the original authors and they are all willing to gr=
ant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ign=
ore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.=
=20
     (See the Legal Provisions document at
     http://trustee.ietf.o=
rg/license-info for more information.)


  Checking references for intended status: Proposed Standard
  -------------------------------------------------------------------------=
---

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  =3D=3D Missing Reference: 'RFC3629' is mentioned on line 100, but=
 not defined

  =3D=3D Unused Reference: 'RFC4250' is defined on line 298, but no=
 explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-=
4'

  ** Obsolete normative reference: RFC 3447

yours, 
Daniel

On Mo= n, Mar 27, 2017 at 4:51 PM, denis bider <denisbider.ietf@gmail.com= > wrote:
T= hat is a welcome assurance. If PSS is added, it sounds like something to me= ntion in Security Considerations as a further argument against small keys.<= /div>
On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaar= a <ilariliusvaara@welho.com> wrote:
On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Mi= gault wrote:
> Whether pss variant have to be added is up to the WG to decide. That I=
> would be in favor is only one opinion ;-) [1] lists some advantages of= PSS
> vs PKCS1v1.5. Note that enabling a given key may be used by two varian= ts
> needs also some thoughts. I will raise the question during the meeting= , but
> discussion will be made on the mailing list.

This thing came up in context of TLS 1.3.

The probability PKCS#1v1.5 and PSS signature overlaps depends on key
size and salt size. Where overlap is defined as encoded message that
is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
and number of bits in n, but not precise value of n.

TLS restricts salt length to be the same as hash length. Which makes
overlaps highly unlikely with key sizes >=3D2048 bits and hash sizes
<=3D512 bits. The problem being to control ~1000 bits using 512 bits.
As key size decreases or salt size increases, the overlap probability
increases, and eventually overlaps become almost certain, and further
one gets multiple overlaps.

>
> [1]
> htt= ps://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rs= a-signatures-rsa-pss.htm


-Ilari


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

--001a1142b632f2342e054c97fecf-- From nobody Fri Apr 7 11:50: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 848A8129583 for ; Fri, 7 Apr 2017 11:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OrNfW5lBAeO for ; Fri, 7 Apr 2017 11:50:07 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 D3D45129553 for ; Fri, 7 Apr 2017 11:50:06 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id g2so73140103pge.3 for ; Fri, 07 Apr 2017 11:50: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=wSwT+Lpase2HE9y/RKb4AtM+lkFDoKMTMTotWRhATH4=; b=lHTAEk44t3QuU7CzkkcpAI6zaHMq9xsPEVmPvi3ebUGcA4vzDwJtGVjM7ngoqDhdJm jH6MVy0of+SGPyhWvhB4NpT2czqXXrB5U+UYjOus+KCCzUb3c2uudKkhUm3Swm58Pxn3 Ky15mP8j1eNLANig1n3XLyUWydYMPCQ44c2882Wrqf1dBTj06bQgYa3uPzeWNi+PjHXM hwFQh/ECCGJ39KiuuEn0K2FCKlx8HKQGlWdWRo9A3B36JxTLUgNdi5hrvl6JzudjXLi7 e5Q1rcGZ9fMEZaL5fof2irlPw6HAXt7NVKqw5DHO3LbZW6IFCGLJzW9rwCPD4V7ZHNQM siJw== 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=wSwT+Lpase2HE9y/RKb4AtM+lkFDoKMTMTotWRhATH4=; b=ie7gLgObDacWhuRgpVCbSXaFPHiNIJxiHcw7kYW0gIaft94FpIzXQaCEcBg2i7Nja/ qFHC+s9l2gSL7iCdFXWRHLoeAQX9uNBM3JTDDnk8oQIux7/rgmXAoP9ifx6I+sIN5g3w lG8x075wvdh9AkAftb2VjCO7r8nMRt+s3Q0S/4Rncd1BHUn1I1jLxS10Lc0ECCZFpZaW lFKfpDaCidNkKyK/06y8qMacODPuxW4X9/j0hWAxpB2OYYdIGfzJHUjT6cnfbiN2vJGe o2A/76r6JM1WumV358vYm1tQnJsg8J2ywYlx0c4uMZGhktQu1iIF/CBertlFBUEVjFTm nhPA== X-Gm-Message-State: AFeK/H3sxRK/v5JNuWZ2lZE9YqeJfIwtbLnhatwjOuqKDR9lLRiG54IGQhCwvGTVm1S3FUjh051nQAlAsp4DQg== X-Received: by 10.84.231.9 with SMTP id f9mr50670696plk.191.1491591006427; Fri, 07 Apr 2017 11:50:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.160.194 with HTTP; Fri, 7 Apr 2017 11:50:05 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Fri, 7 Apr 2017 11:50:05 -0700 Message-ID: To: Daniel Migault Cc: denis bider , "curdle@ietf.org" , Ilari Liusvaara , Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 07 Apr 2017 18:50:10 -0000 On Fri, Apr 7, 2017 at 11:43 AM, Daniel Migault wrote: > Hi, > > In the chicago meeting [1], the consensus seems that even though pss would > be defined, there is no plane to implement nor to use it. I am confirming > this consensus on the mailing list. If you desagree with that, please raise > your opinion. If not we will move the draft forward. I strongly object. PKCS 1.5 signature verification has a long and inglorious history of exploitation. PSS does not. Ideally everyone would have used FDH or equivalently strong signatures, with simple verification, but that didn't happen. From nobody Fri Apr 7 12:49: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 50310126C7A for ; Fri, 7 Apr 2017 12:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 NwVMhlggC2Zj for ; Fri, 7 Apr 2017 12:49:24 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC316126BFD for ; Fri, 7 Apr 2017 12:49:23 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id s141so11634161lfe.3 for ; Fri, 07 Apr 2017 12:49:23 -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=zbu3INOvAWdWqXQfDCDjrV/G6bVNqMq9R7GUuPTSxZg=; b=o5Ra+sfMJ5OM/lcPtZnYryjG4c8GS7RRu7lbclYyHq6ycTjNj/yu+RFkYbEaGjQ12C APxkqU7INczaCIwvi7OXMV2CztvFxCKI86yLS+mNq5zivJXE2kVIdI8+nfl6mWAlnSdA Xr7IosZ7nLoeCnrwI27SpqafjFt1sqKkWW2cmHSRUia1ms/8lrjfPgYrmt7NdmXMW1kM QaOaoWRyXeD7hX6qr1DYEgAIdpvDCqd8kbYyJYHbQT+dscQpPsrjee8nQYNpe/UT8ot8 Wh1NMyP9UVdFo+fUh5ahoAe4KFGiLknWAhsdKWVZSv5TVzOEvjfnbgCMYbzW5uco/gO6 7BFw== 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=zbu3INOvAWdWqXQfDCDjrV/G6bVNqMq9R7GUuPTSxZg=; b=tKM9ogFdjZZ+0ni0jmwX3nuoX8eUtKFrN3bicClFVlmseZ7gg9XK/E2WCEyq2+SjK4 UHWVrkfTlpjHnEVYlC3RkkUciRJ8USZsTLSGizp6P+dZapUu30529jIpu73thYRyGMA3 7syXc9SHX65kLL+w6NiVkMECKY4vqhagc6LBJS/3i6O4SWwBMJhIUBkCWmeyYWGAG6AE g2wVCiO6Eqw4METLU4xFJRr7OBLCpq8jrrBPNg2QPJda2snH5OSsDvzG7bH+A+Z+qMCS HR8eeSSMFyQfxF1zXl+r7reeNvoMFP8F3tx0t/IQ/zBstIo0pXY3RVj3wUo0gdE/Tv2p tAHw== X-Gm-Message-State: AFeK/H3/qRE/te/+EsJHQqNrKv+hZg/V6v1CowoMN6XJT6LzcVwVzykT6vy4RCXOl2iT1pyQj5hoAB9IR7DTdA== X-Received: by 10.46.33.135 with SMTP id h7mr12129961lji.96.1491594561957; Fri, 07 Apr 2017 12:49:21 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 12:49:21 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Fri, 7 Apr 2017 15:49:21 -0400 X-Google-Sender-Auth: hIXAdlNORh3z-NMG3Mq_-BIEuAI Message-ID: To: denis bider Cc: Ilari Liusvaara , "curdle@ietf.org" , Peter Gutmann Content-Type: multipart/alternative; boundary=001a1142b63203b676054c98ecc0 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 07 Apr 2017 19:49:27 -0000 --001a1142b63203b676054c98ecc0 Content-Type: text/plain; charset=UTF-8 In addition, I have also been requested by the IESG to add as an informative reference the link of the IANA page. In our case the link is the following one: https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-19 Yours, Daniel On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migault wrote: > Hi, > > In the chicago meeting [1], the consensus seems that even though pss would > be defined, there is no plane to implement nor to use it. I am confirming > this consensus on the mailing list. If you desagree with that, please raise > your opinion. If not we will move the draft forward. > > The nits tool on the current version provides teh following output: > > [1] https://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00.txt > > > Checking nits according to http://www.ietf.org/id-info/checklist : > ---------------------------------------------------------------------------- > > -- The draft header indicates that this document updates RFC4252, but the > abstract doesn't seem to mention this, which it should. > > -- The draft header indicates that this document updates RFC4253, but the > abstract doesn't seem to mention this, which it should. > > -- The document seems to lack a disclaimer for pre-RFC5378 work, but may > have content which was first submitted before 10 November 2008. If you > have contacted all the original authors and they are all willing to grant > the BCP78 rights to the IETF Trust, then this is fine, and you can ignore > this comment. If not, you may need to add the pre-RFC5378 disclaimer. > (See the Legal Provisions document at > http://trustee.ietf.org/license-info for more information.) > > > Checking references for intended status: Proposed Standard > ---------------------------------------------------------------------------- > > (See RFCs 3967 and 4897 for information about using normative references > to lower-maturity documents in RFCs) > > == Missing Reference: 'RFC3629' is mentioned on line 100, but not defined > > == Unused Reference: 'RFC4250' is defined on line 298, but no explicit > reference was found in the text > > -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' > > ** Obsolete normative reference: RFC 3447 > > yours, > > Daniel > > > On Mon, Mar 27, 2017 at 4:51 PM, denis bider > wrote: > >> That is a welcome assurance. If PSS is added, it sounds like something to >> mention in Security Considerations as a further argument against small keys. >> >> On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara < >> ilariliusvaara@welho.com> wrote: >> >>> On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote: >>> > Whether pss variant have to be added is up to the WG to decide. That I >>> > would be in favor is only one opinion ;-) [1] lists some advantages of >>> PSS >>> > vs PKCS1v1.5. Note that enabling a given key may be used by two >>> variants >>> > needs also some thoughts. I will raise the question during the >>> meeting, but >>> > discussion will be made on the mailing list. >>> >>> This thing came up in context of TLS 1.3. >>> >>> The probability PKCS#1v1.5 and PSS signature overlaps depends on key >>> size and salt size. Where overlap is defined as encoded message that >>> is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm >>> and number of bits in n, but not precise value of n. >>> >>> TLS restricts salt length to be the same as hash length. Which makes >>> overlaps highly unlikely with key sizes >=2048 bits and hash sizes >>> <=512 bits. The problem being to control ~1000 bits using 512 bits. >>> >>> As key size decreases or salt size increases, the overlap probability >>> increases, and eventually overlaps become almost certain, and further >>> one gets multiple overlaps. >>> >>> > >>> > [1] >>> > https://www.emc.com/emc-plus/rsa-labs/historical/raising-sta >>> ndard-rsa-signatures-rsa-pss.htm >>> >>> >>> -Ilari >>> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > --001a1142b63203b676054c98ecc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In addition, I have also been requested by the I= ESG to add as an informative reference the link of the IANA page. In our ca= se the link is the following one:
https://www.ia= na.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-19

Yours,
Daniel
=
On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migau= lt <daniel.migault@ericsson.com> wrote:
Hi,

In the chicago meeting= [1], the consensus seems that even though pss would be defined, there is n= o plane to implement nor to use it. I am confirming this consensus on the m= ailing list. If you desagree with that, please raise your opinion. If not w= e will move the draft forward. =C2=A0

The nits tool on the current = version provides teh following output:

[1] h= ttps://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00.t= xt

  Checking nits according to http://www.ietf.org/id-info/c=
hecklist :
  ---------------------------------------------------------------=
-------------

  -- The draft header indicates that this document updates RFC4252, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC4253, but the
     abstract doesn't seem to mention this, which it should.


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but =
may
     have content which was first submitted before 10 November 2008.  If yo=
u
     have contacted all the original authors and they are all willing to gr=
ant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ign=
ore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.=
=20
     (See the Legal Provisions document at
     htt=
p://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ---------------------------------------------------------------=
-------------

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  =3D=3D Missing Reference: 'RFC3629' is mentioned on line 100, but=
 not defined

  =3D=3D Unused Reference: 'RFC4250' is defined on line 298, but no=
 explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-=
4'

  ** Obsolete normative reference: RFC 3447

yours, 
Daniel

=
On Mon, Mar 27, 2017 at 4:51 PM, denis bider <de= nisbider.ietf@gmail.com> wrote:
That is a welcome = assurance. If PSS is added, it sounds like something to mention in Security= Considerations as a further argument against small keys.

On Mon, Mar 27, 2017= at 1:24 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Sun, Mar 26, 2017 at 1= 0:50:02PM -0500, Daniel Migault wrote:
> Whether pss variant have to be added is up to the WG to decide. That I=
> would be in favor is only one opinion ;-) [1] lists some advantages of= PSS
> vs PKCS1v1.5. Note that enabling a given key may be used by two varian= ts
> needs also some thoughts. I will raise the question during the meeting= , but
> discussion will be made on the mailing list.

This thing came up in context of TLS 1.3.

The probability PKCS#1v1.5 and PSS signature overlaps depends on key
size and salt size. Where overlap is defined as encoded message that
is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
and number of bits in n, but not precise value of n.

TLS restricts salt length to be the same as hash length. Which makes
overlaps highly unlikely with key sizes >=3D2048 bits and hash sizes
<=3D512 bits. The problem being to control ~1000 bits using 512 bits.
As key size decreases or salt size increases, the overlap probability
increases, and eventually overlaps become almost certain, and further
one gets multiple overlaps.

>
> [1]
> htt= ps://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rs= a-signatures-rsa-pss.htm


-Ilari


______________________________= _________________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--001a1142b63203b676054c98ecc0-- From nobody Fri Apr 7 12:54: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 66AE612741D for ; Fri, 7 Apr 2017 12:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 KGtldWG24uVd for ; Fri, 7 Apr 2017 12:54:28 -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 DE1631267BB for ; Fri, 7 Apr 2017 12:54:27 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id s141so11689040lfe.3 for ; Fri, 07 Apr 2017 12:54: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=X8v2KLIXe3d1hKt+zw3jzQAmeOaqH3V/134b7fvsvTY=; b=OnfEN8UCdhYq+FG3wsRMy+AYzf7dZADIs6rU0QeJrWRNUuaCdeybpZkjUNoUNIXLQI VqcCVrPJLzWKDFjnnS4sRqB4X0/FNRJR7qor9hNHdQcmc+Y3muOKgL16VRrfyxeHGfvJ 8WXfpfF1yiFd+seuZyYgtwXNxAOvQLnMwl0TKKadSAdbqCfk/ksTjBeJQFgudz15KaI2 9yOsVanvR2/1ZipkyX8PZ08zWd/ccjmgWN18ruxo0ogEhI7k+NbLRY3kWqla9M2JImP+ ImQM4LHV1pkabwuzNUhDRZCpEuKdu4JnZQilt6yzciSd2VUwLyTL88dxgG9Y5IXatX0n 8+VQ== 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=X8v2KLIXe3d1hKt+zw3jzQAmeOaqH3V/134b7fvsvTY=; b=bPLmcRq6LAiFbqN8q0cQxirmVwABLqFHmmNqVzl8vJc82r4csnfRZI6U2lL/8LcXCW lPQVm1ArP7musS1FYUyjrnNO/DVdBZnLA2BdyLFK8hXUGlW/hovFQv0xd4uZEIqZhB26 p7VgMi2FPIitWl/ohzAXS3aQV/USyEpISlti1VPAwzgxy+yXwr2QKL5AhvcFG8ynB5LD HjBWXUJpR99z05fWcdryNJEtx0t44hPw+gcxFUcKiCQzcu/elUn+cTImSZ+ZS3oMzgCU 0a/xtWqRnoI3w1cBc+b87Ljedt9vUXpgz0DEPwkopUFxdyTrqaBv9EBDlKL9VQFMoNZ6 2nHQ== X-Gm-Message-State: AFeK/H2aXQhseFOwoirODIV8s181hK4giEiMJGfYqUWqY3J8JQpfDOUo65tfBcV4BfHaJy95LcB+IkL5Opi+Rw== X-Received: by 10.46.0.5 with SMTP id 5mr12898982lja.35.1491594866265; Fri, 07 Apr 2017 12:54:26 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 12:54:25 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Fri, 7 Apr 2017 15:54:25 -0400 X-Google-Sender-Auth: 3GUVuuJMY0kfbYYN4GAOzAZKw0k Message-ID: To: Watson Ladd Cc: "curdle@ietf.org" , Ilari Liusvaara , denis bider , Peter Gutmann Content-Type: multipart/alternative; boundary=001a1142b998271544054c98fed0 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 07 Apr 2017 19:54:30 -0000 --001a1142b998271544054c98fed0 Content-Type: text/plain; charset=UTF-8 Hi, My understanding was that PSS is proved secured while pkcs1v1.5 is not. Could you provide reference of such exploitation, that would be helpful. Yours, Daniel On Fri, Apr 7, 2017 at 2:50 PM, Watson Ladd wrote: > On Fri, Apr 7, 2017 at 11:43 AM, Daniel Migault > wrote: > > Hi, > > > > In the chicago meeting [1], the consensus seems that even though pss > would > > be defined, there is no plane to implement nor to use it. I am confirming > > this consensus on the mailing list. If you desagree with that, please > raise > > your opinion. If not we will move the draft forward. > > I strongly object. PKCS 1.5 signature verification has a long and > inglorious history of exploitation. PSS does not. Ideally everyone > would have used FDH or equivalently strong signatures, with simple > verification, but that didn't happen. > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a1142b998271544054c98fed0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

My understanding was that= PSS is proved secured while pkcs1v1.5 is not. Could you provide reference = of such exploitation, that would be helpful.

Yours,
Daniel=C2=A0

On Fri, Apr 7, 2017 at 2:50 PM, Watson Ladd <watsonbladd@gmail.= com> wrote:
On Fri, Apr 7, 2017 at 11:43 AM, Daniel Migault
<daniel.migault@ericsson.= com> wrote:
> Hi,
>
> In the chicago meeting [1], the consensus seems that even though pss w= ould
> be defined, there is no plane to implement nor to use it. I am confirm= ing
> this consensus on the mailing list. If you desagree with that, please = raise
> your opinion. If not we will move the draft forward.

I strongly object. PKCS 1.5 signature verification has a long and inglorious history of exploitation. PSS does not. Ideally everyone
would have used FDH or equivalently strong signatures, with simple
verification, but that didn't happen.

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

--001a1142b998271544054c98fed0-- From nobody Fri Apr 7 13:21: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 C24221273E2 for ; Fri, 7 Apr 2017 13:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 J2O84bOg0HGf for ; Fri, 7 Apr 2017 13:20:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A98FE128DF6 for ; Fri, 7 Apr 2017 13:20:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0DE6E300440 for ; Fri, 7 Apr 2017 16:20:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QRXve5yyrY34 for ; Fri, 7 Apr 2017 16:20:20 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id B4264300261; Fri, 7 Apr 2017 16:20:20 -0400 (EDT) From: Russ Housley Message-Id: <191698B4-2096-4501-A2BD-7392EFE59099@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8B2786A2-0109-43B6-BAD0-2679930FD29A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 7 Apr 2017 16:20:20 -0400 In-Reply-To: Cc: curdle To: Daniel Migault References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41C0@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.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, 07 Apr 2017 20:20:32 -0000 X-List-Received-Date: Fri, 07 Apr 2017 20:20:32 -0000 X-List-Received-Date: Fri, 07 Apr 2017 20:20:32 -0000 --Apple-Mail=_8B2786A2-0109-43B6-BAD0-2679930FD29A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Daniel: IANA maintains registration in two object identifier arcs: 1. with a prefix of 1.3.6.1 https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml = 2. with a prefix of 1.2.840.113549.1.9.16 = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-sm= ime = Russ > On Apr 7, 2017, at 2:15 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > The nit tool reports the following warnings/errors: >=20 > Checking nits according to http://www.ietf.org/id-info/checklist = : > = --------------------------------------------------------------------------= -- >=20 > ** The document seems to lack an IANA Considerations section. (See = Section > 2.2 of http://www.ietf.org/id-info/checklist = for how to handle the case > when there are no actions for IANA.) >=20 >=20 > Miscellaneous warnings: > = --------------------------------------------------------------------------= -- >=20 > =3D=3D The "Author's Address" (or "Authors' Addresses") section = title is > misspelled. >=20 > Just for clarification, IANA registries do not register IODs outside = their arc. Am I correct ?=20 >=20 > [1] = https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-sm= ime-9 = > =20 >=20 > On Fri, Mar 10, 2017 at 4:39 PM, Daniel Migault = > = wrote: > Thank you Russ for the responses. They were useful to me. >=20 > Yours, > Daniel >=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com = ] > Sent: Friday, March 10, 2017 12:13 PM > To: Daniel Migault > > Cc: curdle > > Subject: Re: [Curdle] questions on = draft-ietf-curdle-cms-eddsa-signatures-03.txt >=20 > Daniel: >=20 > > Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) > > > > > > 2. EdDSA Signature Algorithm > > > > One of the parameters of the EdDSA algorithm is the "prehash" > > function. This may be the identity function, resulting in an > > algorithm called PureEdDSA, or a collision-resistant hash = function, > > resulting in an algorithm called HashEdDSA. In most situations = the > > CMS SignedData includes signed attributes, including the message > > digest of the content. Since HashEdDSA offers no benefit when = signed > > attributes are present, only PureEdDSA is used with the CMS. > > > > MGLT: My understanding of the two latest sentences is that, in most = cases the CMS when used with signed attributes may specify the hash of = the content. As prehashing is performed by CMS, there is no need to have = a pre hash variant version. > > > > =46rom the two sentences it may appear that without signed = attributes, they might be some advantages of having HashEdDSA over = PureEdDSA. If that is the case, maybe we should provide them and then = motivate our choice. > > > > What is unclear to me is why signed attributed make it different ? = My understanding is that in any case digestAlgorithm is used to compute = the digest of the eContent and when defined additional signed = attributes. >=20 > CMS supports signatures with and without signed attributes. In most = cases, signed attributes are present. When signed attributes are = present, the message-digest attribute MUST be one of the attributes. It = was signed to work like this: >=20 > IF (signed attributes are absent) > THEN md =3D Hash(content) > ELSE message-digest attribute =3D Hash(content); > md =3D Hash(DER(SignedAttributes)) >=20 > Sign(md) >=20 > > I am also wondering if we were using the prehash variant a = combination of digestAlgorithm with the prehash function would not be = problematic. At least, the signing operation would not be performed on = the same content this might add unnecessary overhead. If that is the = case, it would provide a generic motivation to only consider PureHash = with CMS. >=20 > Yes, HashEdDSA could be useful when signed attributes are present. I = was not including HashEdDSA in this document because curdle-pkix did not = support that algorithm. If that changes (as is being discussed on a = separate thread), then it should be supported here as well. >=20 > > My understanding of EdDSA is that when PureEdDSA is possible, it is = always recommended over HashEdDSA. I assume this is also recommended for = CMS. >=20 > We could RECOMMEND PureEdDSA when signed attributes are present, and = we could RECOMMEND PureEdDSA when signed attributes are absent, but the = content is not very large. >=20 >=20 > > 2.3. Message Digest Algorithm Identifiers > > > > When the signer includes signed attributes, a message digest > > algorithm is used to compute the message digest on the eContent > > value. When signing with Ed25519, the message digest algorithm = MUST > > be SHA-512 [RFC4634]. When signing with Ed448, the message = digest > > algorithm MUST be SHAKE256 [FIPS202] with a 512-bit output value. > > > > MGLT: I am wondering why the digestAlgorithm cannot be the identity. >=20 > Since CMS allows multiple signatures on the content, the idea is to = tell the implementation which hash functions are needed in a field that = appears before the content that needs to be hashed. >=20 > > Signing with Ed25519 uses SHA-512 as part of the signing = operation, > > and signing with Ed448 uses SHAKE256 as part of the signing > > operation. > > > > MGLT: I am wondering if the text above wants to specify that the = digest algorithm specified are already part of the signature and as such = no additional hash functions really need to be added or if there is = another motivation for this text. >=20 > This is the rationale for the earlier statement. >=20 > > For convenience, the object identifiers and parameter syntax for > > these algorithms are repeated here: > > > > MGLT: IOD are repeated, maybe we could add a reference where these = have been defined. -- Note that the ref becomes clearer on the next = page. >=20 > These OIDs all come from the NIST website, but NIST does not publish = an ASN.1 module that includes them. >=20 > Most of them appear in the ASN.1 module in the curdle-pkix document. = I should probably add a module to this document too. >=20 >=20 > > 2.4. EdDSA Signatures > > > > The id-Ed25519 and id-Ed448 object identifiers are also used for > > signature values. When used to identify signature algorithms, = the > > AlgorithmIdentifier parameters field MUST be absent. > > > > MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for = the signature value. My understanding is that the Signer Info carries = the signature algorithm, which defines the signature. >=20 > SignerInfo ::=3D SEQUENCE { > version CMSVersion, > sid SignerIdentifier, > digestAlgorithm DigestAlgorithmIdentifier, > signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, > signatureAlgorithm SignatureAlgorithmIdentifier, > signature SignatureValue, > unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } >=20 > This text is talking about the SignatureAlgorithmIdentifier, which = uses the same OID as the subject public key in the certificate that will = be used to validate the signature. >=20 >=20 > > 3. Signed-data Conventions > > > > The processing depends on whether the signer includes signed > > attributes. > > > > The inclusion of signed attributes is preferred, but the = conventions > > for signed-data without signed attributes are provided for > > completeness. > > > > MGLT: Maybe we could briefly explain or provide a reference why = signed attributes are preferred. >=20 > This is a statement about what most implementation do. S/MIME says = that sending agents SHOULD include signed attributes, and I cannot think = of any that don=E2=80=99t do so. >=20 >=20 > > 3.1. Signed-data Conventions With Signed Attributes > > > > The SignedData digestAlgorithms field includes the identifiers of = the > > message digest algorithms used by one or more signer. There MAY = be > > any number of elements in the collection, including zero. When > > signing with Ed25519, the digestAlgorithm SHOULD include = id-sha512, > > and if present, the algorithm parameters field MUST be absent. = When > > > > signing with Ed448, the digestAlgorithm SHOULD include > > id-shake256-len, and if present, the algorithm parameters field = MUST > > also be present, and the parameter MUST contain 512, encoded as a > > positive integer value. > > > > MGLT: For which reason do we have a SHOULD and not a MUST, as the = hash function specified have a MUST status in te message digest = identifier. >=20 > This is at odds with your comment on section 2. I=E2=80=99m fine with = making this a MUST. >=20 > Russ >=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 --Apple-Mail=_8B2786A2-0109-43B6-BAD0-2679930FD29A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Daniel:

IANA maintains registration in two object identifier = arcs:

1. with = a prefix of 1.3.6.1

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml<= /a>

2. =  with a prefix of 1.2.840.113549.1.9.16

https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#= security-smime

Russ


On Apr 7, 2017, at 2:15 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

The nit tool reports the following warnings/errors:

  Checking nits according to =
http://www.ietf.org/id-info/checklist :
  =
--------------------------------------------------------------------------=
--

  ** The document seems to lack an IANA Considerations section.  (See =
Section
     2.2 of http://www.ietf.org/id-info/checklist for how to handle =
the case
     when there are no actions for IANA.)


  Miscellaneous warnings:
  =
--------------------------------------------------------------------------=
--

  =3D=3D The "Author's Address" (or "Authors' Addresses") section title =
is
     misspelled.

Just =
for clarification, IANA registries do not register IODs outside their =
arc. Am I correct ? 

[1] https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#=
security-smime-9
 

On Fri, Mar 10, 2017 at 4:39 PM, = Daniel Migault <daniel.migault@ericsson.com> wrote:
Thank you Russ for the = responses. They were useful to me.

Yours,
Daniel

-----Original Message-----
From: Russ Housley [mailto:housley@vigilsec.com]
Sent: Friday, March 10, 2017 12:13 PM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: curdle <curdle@ietf.org>
Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.txt

Daniel:

>    Use of EdDSA Signatures in the Cryptographic Message = Syntax (CMS)
>            =  <draft-ietf-curdle-cms-eddsa-signatures-03.txt>
>
> 2.  EdDSA Signature Algorithm
>
>    One of the parameters of the EdDSA algorithm is the = "prehash"
>    function.  This may be the identity function, = resulting in an
>    algorithm called PureEdDSA, or a collision-resistant = hash function,
>    resulting in an algorithm called HashEdDSA.  In = most situations the
>    CMS SignedData includes signed attributes, including = the message
>    digest of the content. Since HashEdDSA offers no = benefit when signed
>    attributes are present, only PureEdDSA is used with = the CMS.
>
> MGLT: My understanding of the two latest sentences is that, in most = cases the CMS when used with signed attributes may specify the hash of = the content. As prehashing is performed by CMS, there is no need to have = a pre hash variant version.
>
> =46rom the two sentences it may appear that without signed = attributes, they might be some advantages of having HashEdDSA over = PureEdDSA. If that is the case, maybe we should provide them and then = motivate our choice.
>
> What is unclear to me is why signed attributed make it different ? = My understanding is that in any case digestAlgorithm is used to compute = the digest of the eContent and when defined additional signed = attributes.

CMS supports signatures with and without signed attributes.  In = most cases, signed attributes are present.  When signed attributes = are present, the message-digest attribute MUST be one of the = attributes.  It was signed to work like this:

      IF (signed attributes are absent)
      THEN md =3D Hash(content)
      ELSE message-digest attribute =3D Hash(content);
           md =3D = Hash(DER(SignedAttributes))

      Sign(md)

> I am also wondering if we were using the prehash variant a = combination of digestAlgorithm with the prehash function would not be = problematic. At least, the signing operation would not be performed on = the same content this might add unnecessary overhead. If that is the = case, it would provide a generic motivation to only consider PureHash = with CMS.

Yes, HashEdDSA could be useful when signed attributes are present.  = I was not including HashEdDSA in this document because curdle-pkix did = not support that algorithm.  If that changes (as is being discussed = on a separate thread), then it should be supported here as well.

> My understanding of EdDSA is that when PureEdDSA is possible, it is = always recommended over HashEdDSA. I assume this is also recommended for = CMS.

We could RECOMMEND PureEdDSA when signed attributes are present, and we = could RECOMMEND PureEdDSA when signed attributes are absent, but the = content is not very large.


> 2.3.  Message Digest Algorithm Identifiers
>
>    When the signer includes signed attributes, a message = digest
>    algorithm is used to compute the message digest on the = eContent
>    value.  When signing with Ed25519, the message = digest algorithm MUST
>    be SHA-512 [RFC4634].  When signing with Ed448, = the message digest
>    algorithm MUST be SHAKE256 [FIPS202] with a 512-bit = output value.
>
> MGLT: I am wondering why the digestAlgorithm cannot be the = identity.

Since CMS allows multiple signatures on the content, the idea is to tell = the implementation which hash functions are needed in a field that = appears before the content that needs to be hashed.

>    Signing with Ed25519 uses SHA-512 as part of the = signing operation,
>    and signing with Ed448 uses SHAKE256 as part of the = signing
>    operation.
>
> MGLT: I am wondering if the text above wants to specify that the = digest algorithm specified are already part of the signature and as such = no additional hash functions really need to be added or if there is = another motivation for this text.

This is the rationale for the earlier statement.

>    For convenience, the object identifiers and parameter = syntax for
>    these algorithms are repeated here:
>
>  MGLT: IOD are repeated, maybe we could add a reference where = these have been defined. -- Note that the ref becomes clearer on the = next page.

These OIDs all come from the NIST website, but NIST does not publish an = ASN.1 module that includes them.

Most of them appear in the ASN.1 module in the curdle-pkix = document.  I should probably add a module to this document too.


>  2.4.  EdDSA Signatures
>
>    The id-Ed25519 and id-Ed448 object identifiers are = also used for
>    signature values.  When used to identify = signature algorithms, the
>    AlgorithmIdentifier parameters field MUST be = absent.
>
> MGLT: I do not understand why id-Ed25519 and id-Ed448 are used for = the signature value. My understanding is that the Signer Info carries = the signature algorithm, which defines the signature.

      SignerInfo ::=3D SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm = DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes = OPTIONAL,
        signatureAlgorithm = SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT = UnsignedAttributes OPTIONAL }

This text is talking about the SignatureAlgorithmIdentifier, which uses = the same OID as the subject public key in the certificate that will be = used to validate the signature.


> 3.  Signed-data Conventions
>
>    The processing depends on whether the signer includes = signed
>    attributes.
>
>    The inclusion of signed attributes is preferred, but = the conventions
>    for signed-data without signed attributes are provided = for
>    completeness.
>
> MGLT: Maybe we could briefly explain or provide a reference why = signed attributes are preferred.

This is a statement about what most implementation do.  S/MIME says = that sending agents SHOULD include signed attributes, and I cannot think = of any that don=E2=80=99t do so.


> 3.1.  Signed-data Conventions With Signed Attributes
>
>    The SignedData digestAlgorithms field includes the = identifiers of the
>    message digest algorithms used by one or more = signer.  There MAY be
>    any number of elements in the collection, including = zero.  When
>    signing with Ed25519, the digestAlgorithm SHOULD = include id-sha512,
>    and if present, the algorithm parameters field MUST be = absent.  When
>
>    signing with Ed448, the digestAlgorithm SHOULD = include
>    id-shake256-len, and if present, the algorithm = parameters field MUST
>    also be present, and the parameter MUST contain 512, = encoded as a
>    positive integer value.
>
>  MGLT: For which reason do we have a SHOULD and not a MUST, as = the hash function specified have a MUST status in te message digest = identifier.

This is at odds with your comment on section 2.  I=E2=80=99m fine = with making this a MUST.

Russ

_______________________________________________
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

= --Apple-Mail=_8B2786A2-0109-43B6-BAD0-2679930FD29A-- From nobody Fri Apr 7 13:26:57 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 C9ECA128BBB for ; Fri, 7 Apr 2017 13:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.197, 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 RSPIAz_PiSWi for ; Fri, 7 Apr 2017 13:26:24 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 408E3129469 for ; Fri, 7 Apr 2017 13:26:07 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id q141so17684759lfe.2 for ; Fri, 07 Apr 2017 13:26:07 -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=AfbXI4unH0XfC0j7pq4ZNZLEdnzucitJHJTwRAoA7UI=; b=YWNDzZNo82jvVyrN2hPKQp87HLDVoewOm+ck5mCEuuGRtEGYCI/Irlv0+NG625BKis tvs9LWwhRJ0ll37b+xn8Apfd1Bs10QrJx9m7tHz3iN97UAz7VGBIV7WVO+QZH4/sOw67 0ZBFvLdyYVLRMhmDVGM1utPukl+M70WXhWKvHSN3AxIz+rxNYQZ307mj1bE5Z0ZQsUn1 v68ntxUZ0K4JLvn6u69KBYMXiSImtEJpVeV6spV7Q5qZRXA6QUyxnB8HCDWIFu6BwepB KV8isWbcU84ouefla1nJ4dkmcq2lMJXRCPjJvo2QuQo2WzUISSQwxpF87uQnglfDdyIu McMQ== 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=AfbXI4unH0XfC0j7pq4ZNZLEdnzucitJHJTwRAoA7UI=; b=WTwHgWpZsoxGe3VRqtQ7ifsOA6LagqCJAprNB3K7QfpGHEdy/aLttaY5n/pFRHMTnp jriOkpHa9JEQPldPgeEtbj2h2RETvWYVG/0Sm+l6nO3whO/I8eM8Wd2h/pfRP+zQEdQ5 5+yCxRbWuMRfSIi4jlS/dW7jKw/8boGgh9daWHXkDM4DRDU0gZ8NIGVWadoljG24G7H7 Z8a5tEkqxrZsxnL5vYJ3b62nwxBiYTy9+ARmCzl5Qt07Il/dECdLDNuQDatfr/4rGUPV xRjhWozwB+dHjZdiXlO6WbfJLt6EgGEvnVwhLxfR2urlQIpq8bpy3sfjW7+hA7LnOt8A V/AA== X-Gm-Message-State: AFeK/H1OcO0vHzu0nzsWBcI9NUyOLyVi9tAI3v5h9xI+10Y8ggeJXYMlq+MlSIV9Xurye+LqeGGeE9Rdq3ezTw== X-Received: by 10.46.0.5 with SMTP id 5mr12932184lja.35.1491596765296; Fri, 07 Apr 2017 13:26:05 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Fri, 7 Apr 2017 13:26:04 -0700 (PDT) From: Daniel Migault Date: Fri, 7 Apr 2017 16:26:04 -0400 X-Google-Sender-Auth: DQ3qGXwA01rovaFYKNKpzzqeuAY Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a1142b998582093054c996fdf Archived-At: Subject: [Curdle] CURDLE clean up 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, 07 Apr 2017 20:26:30 -0000 --001a1142b998582093054c996fdf Content-Type: text/plain; charset=UTF-8 Hi, This email provides a reminder of the various draft's status: The following drafts are in a pretty good shape to be submitted to the IESG. As soon as received comments have been addressed, I am expecting to move them forward -- possibly next week. - draft-ietf-curdle-cms-ecdh-new-curves - draft-ietf-curdle-cms-eddsa-signatures - draft-ietf-curdle-pkix-04 - draft-ietf-curdle-ssh-curves 1) If you are an author... Please publish an up-to-date version of the draft. 1) if you disagree.... If you disagree, raise your concern as soon as possible. If you are an author of these drafts, please publish an update version addressing the lastest received comments and nits. 2) If you are aware of implementations... * Send it to the mailing list. This is especially helpful for the shepherd write up. * Entering them into CodeStand. Listing can be to open source or proprietary implementations, where the open source ones would link to code repositories. Before entering your code project, check to see if the standard, draft, or set of standards/drafts is already listed as a project. https://codestand.ietf.org/ Here are the draft that may need an additional iteration: - draft-ietf-curdle-ssh-kex-sha2 - draft-ietf-curdle-ssh-ext-info -- draft-ietf-curdle-ssh-modp-dh-sha2 Here are the next candidate draft. Call for adoption will be send when the pipe is a bit cleaner. one or two weeks. - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des -die-die-die-01 If I am missing anything, just let me know. Yours, Daniel --001a1142b998582093054c996fdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This = email provides a reminder of the various draft's status:

T= he following drafts are in a pretty good shape to be submitted to the IESG.= As soon as received comments have been addressed, I am expecting to move t= hem forward -- possibly next week.

=C2=A0=C2=A0=C2=A0 - draft-ietf-c= urdle-cms-ecdh-new-curves
=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-cms-edd= sa-signatures
=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-pkix-04
=C2=A0= =C2=A0=C2=A0 - draft-ietf-curdle-ssh-curves=

1) If you are an author...
Please p= ublish an up-to-date version of the draft.

1) if you dis= agree.... =C2=A0=C2=A0
If you disagree, raise your concern as soo= n as possible. If you are an author of these drafts, please publish an upda= te version addressing the lastest received comments and nits.

2) If you are aware of implementations...
* Send it to the m= ailing list. This is especially helpful for the shepherd write up.
* En= tering them into CodeStand.=C2=A0 Listing can be to open source or propriet= ary implementations, where the open source ones would link to code reposito= ries.=C2=A0 Before entering your code project, check to see if the standard= , draft, or set of standards/drafts is already listed as a project. https= ://codestand.ietf.org/


Here are the draft that may nee= d an additional iteration:
=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-ssh-ke= x-sha2
=C2=A0=C2=A0=C2=A0 - draft-ietf-curdle-ssh-ext-info
= =C2=A0=C2=A0 --=C2=A0 draft-ietf-curdle-ssh-modp-dh-sha2
<= br>
Here are the next candidate draft. Call for adoption will be send = when the pipe is a bit cleaner. one or two weeks.
=C2=A0=C2=A0=C2=A0 - <= a href=3D"https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt" rel= =3D"noreferrer" target=3D"_blank">https://www.ietf.org/id/draft-ssorce= -gss-keyex-sha2-00.txt
=C2=A0=C2=A0=C2=A0 - https://tools.ietf.org/html/draft-kaduk-kitten= -des-des-des-die-die-die-01

If I am missing anything, just let me know.
Yours,
Daniel

--001a1142b998582093054c996fdf-- From nobody Fri Apr 7 13:52:24 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 07782120454 for ; Fri, 7 Apr 2017 13:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFwkARDh4Fsv for ; Fri, 7 Apr 2017 13:52:20 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::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 1BD70128B90 for ; Fri, 7 Apr 2017 13:52:09 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id x125so76619362pgb.0 for ; Fri, 07 Apr 2017 13:52:09 -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=KlN2qd2iZzwT8zDLCdZ2AE5f7s3579muYtDuHsruauE=; b=D0kH2qaRZtJaLd89jiuxsemKDCY6vr6VzrGQd5B8Q70Pd0WncaJhjvrxC2J4iiIFzU GfyQETbFAtCNWVO1BpwhiDx5J6XUfvz9bsGmxt6bozEJ7S7GhLUYQqkrNjY41ntFM/Md 4NfAg6sSLR43IXsr2wCwx2qAFHGz7CJZm72OEMhaWThfBejucZXGjzfcWujtT7uZZIvR AwRbDb3vtS53pSj5bCtQlYpw40GBv5SFVEy+q+qVaG2pyVRc3DzMA3ro3/GniRk0jGqT 7pA3yWiMRP1E6I4c+odNiy4NENBxQXeAK4W9aTKrTepHPeTRm+1o+dFiGqdHHeNF65RV oPNA== 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=KlN2qd2iZzwT8zDLCdZ2AE5f7s3579muYtDuHsruauE=; b=aNIqQCjGaPMMh5MUArP1q1jCcLjyRgYJADxNtrgHD0w5Fea6wME69FA5zAHNI9UjVo uwPqDyPY8xhsRmTLLxRLbVfC6k0m4yleTfWqYrKDfoYNlMn9l7N6w0gj1YhUTtX5UmO1 MjEKuusI6vBJWJtiqBywRHSSvC0MwT18o/q6Kk1STV3givicVPoYsX5/l3R7bnUaYwG9 iCeS4NJTbhtYXJHV0qZvzcPtLI2SHkpEgiRGvv/o7OnpLZSolo4wbNiY8XB0YADQOkQg yS8E9oJugLJ6WSmYi7mYwsJKrR0qNeBXWPzgoBUxWeFnsLgFZGJjQbCz/bL+0FvY5bg+ F4Xg== X-Gm-Message-State: AFeK/H3Du3m1SoZuJs8I8DUP1UMiMXEYhsuqkvYI5HvSC0dotFzbd0/HxSVhSIPgjVnYKJqkHpmJL4ISmbo0jg== X-Received: by 10.98.202.80 with SMTP id n77mr42542146pfg.167.1491598328712; Fri, 07 Apr 2017 13:52:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.160.194 with HTTP; Fri, 7 Apr 2017 13:52:08 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: Watson Ladd Date: Fri, 7 Apr 2017 13:52:08 -0700 Message-ID: To: Daniel Migault Cc: "curdle@ietf.org" , Ilari Liusvaara , denis bider , Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 07 Apr 2017 20:52:22 -0000 On Fri, Apr 7, 2017 at 12:54 PM, Daniel Migault wrote: > Hi, > > My understanding was that PSS is proved secured while pkcs1v1.5 is not. > Could you provide reference of such exploitation, that would be helpful. All the exploitation stems Bleichenbacher's on stage demonstration that improper validation can lead to issues at Crypto '06. This bug broke Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1064636. It broke GnuTLS https://security.gentoo.org/glsa/200609-15, It broke OpenSSL https://www.rapid7.com/db/vulnerabilities/http-openssl-rsa-signature-forgery-vuln. In many cases bug reporters don't note the origins of this attack, making it hard to know if additional examples exist. CVE-2016-8021 may also be an instance of this. > > Yours, > Daniel > > On Fri, Apr 7, 2017 at 2:50 PM, Watson Ladd wrote: >> >> On Fri, Apr 7, 2017 at 11:43 AM, Daniel Migault >> wrote: >> > Hi, >> > >> > In the chicago meeting [1], the consensus seems that even though pss >> > would >> > be defined, there is no plane to implement nor to use it. I am >> > confirming >> > this consensus on the mailing list. If you desagree with that, please >> > raise >> > your opinion. If not we will move the draft forward. >> >> I strongly object. PKCS 1.5 signature verification has a long and >> inglorious history of exploitation. PSS does not. Ideally everyone >> would have used FDH or equivalently strong signatures, with simple >> verification, but that didn't happen. >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Apr 7 20:24:24 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 C267B128E19 for ; Fri, 7 Apr 2017 20:24:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taCQ27Cv7rWf for ; Fri, 7 Apr 2017 20:24:20 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9D3120724 for ; Fri, 7 Apr 2017 20:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491621860; x=1523157860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AZ0C3MKQ7KE3x4scQUgTc9oQgyu3gpIgYBKWi1ri5ac=; b=0xlOgStcEf3t1rxy2CydSQgO+hdWpeZQ0KjlSsV/zXpt53yC9OOmzbux 1VNgBMHR82FXUYf82rWVVm52XQBFn1RBo7WAGcrJD5tjKys2X3Dv9Gdpp owz5xYaR6Nw0RuNHLBStSIvpzMHp35yemQEV/iC3hNw6mDeHCtsqoMssg 8NF+s/qEOHBqnIsJqEHkV9Yp5V/m7e32yLadRDvWUXMh1w6Fe3gbeF2zi dM+4fmhH8UhV+3n6bcsSA4oJ5BB1WxpfJMm06dfm8zqinBdHw5oWdJHv1 rxY6Bb9GQOeL0azKFrCyZvSq2H3NhnsxpYNHus3FrCnOI2qqAYuxymX2Q g==; X-IronPort-AV: E=Sophos;i="5.37,169,1488798000"; d="scan'208";a="148583094" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from uxcn13-tdc-c.uoa.auckland.ac.nz ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Apr 2017 15:24:17 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 8 Apr 2017 15:24:17 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sat, 8 Apr 2017 15:24:17 +1200 From: Peter Gutmann To: denis bider CC: curdle Thread-Topic: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info Thread-Index: AQHSn+vj75AP59wDbUy5ryRiOFPQYKGb4DhQgAWgX4CAA91Jyf//yxWAgBMy0XmAAFvPgIACNyu/ Date: Sat, 8 Apr 2017 03:24:16 +0000 Message-ID: <1491621835513.71448@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 08 Apr 2017 03:24:23 -0000 denis bider writes:=0A= =0A= >Can you link to any resources where this was discussed? Whether for TLS, o= r=0A= >in any other context?=0A= =0A= It's difficult providing a useful link because it's been discussed on and o= ff=0A= in various threads on the TLS WG list for quite some time.=A0 There are a r= ange=0A= of opinions on how safe it is, but in general it seems 0RTT is bad and 0.5R= TT=0A= is iffy.=A0 That is, you can do 0RTT if you're incredibly careful (I talked= to a=0A= dev at a large content provider and he said their analysis showed they'd ha= ve=0A= to implement nonzero-RTT at the application layer in order to deal with 0RT= T=0A= at the TLS layer, which kinda defeats the point), but if anyone ever tries = it=0A= I foresee a range of Black Hat/Defcon talks and conference papers on how to= =0A= exploit it following shortly afterwards.=0A= =0A= >Yes if you could choose the type. But you can't choose the type, because a= ll=0A= >extensions have to use the same type. That type is a string.=0A= =0A= What I meant was use the string value "true" for boolean true and "false" f= or=0A= boolean false.=A0 It seemed pretty intuitive :-).=0A= =0A= >OK. I added the following sub-section to my current working copy:=0A= =0A= Thanks, that helps to document existing practice and alert implementers.=0A= =0A= Incidentally, the places where I've found this is typically embedded, where= =0A= there's no chance of every transferring anywhere near ~0 bytes, so it's not= a=0A= problem.=A0 OTOH the second issue is real, you can force a reboot of one=0A= vendor's carrier-grade routers by opening an SSH connection to it with a=0A= window size of ~0.=0A= =0A= Speaking of embedded, would there be any interest in adding an extension to= =0A= say that an implementation only supports one channel, and for the other sid= e=0A= to not try anything fancy beyond treating it as an encrypted telnet? This = is=0A= also fairly common in embedded, where you're emulating encrypted telnet and= =0A= nothing more. scp/SFTP is handled by moving the binary data over the=0A= encrypted-telnet channel, with various degrees of hackery.=0A= =0A= Peter.=0A= =0A= = From nobody Fri Apr 7 20:37: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 026351293D9 for ; Fri, 7 Apr 2017 20:37:30 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOb3nLJbfO4e for ; Fri, 7 Apr 2017 20:37:28 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E5C129353 for ; Fri, 7 Apr 2017 20:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491622648; x=1523158648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dxZuNeXwb8iT/L1uEicgEF85mcKvJj5aXDWViJJ7o/I=; b=vA2A6sXWvsdbd69s1BOg9QdC0x77c4nxCqRmmVPFLRRoCyBiuGNMSTSF 0yLwFKHZXOwtlRYtiAnn3+YDYZJCk5YrYS1pKZk5H0LXMe8LwCS3oqHl7 RHpDoXD8meJWBWGqYmTL1orCb7YiQkYgBDdCynTyGUng6t/tl7AMyd7BS ZlK8MEyGMCMFb9M++7R/ZK3xWyoFKOZOwJIcs0Bx7LVQvPsv3hAiw10oi jiDlR9k72uWkM51eSJgo5YRivtounv7dBViKMD0e/Jm1i55l1vrOgq4Kc f2SEVyPM/jpZ+qe8YfC8idyqoK732wuhN1/52JOvZQwp/SvuLc7kO+tRc g==; X-IronPort-AV: E=Sophos;i="5.37,169,1488798000"; d="scan'208";a="148584289" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Apr 2017 15:37:26 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 8 Apr 2017 15:37:20 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sat, 8 Apr 2017 15:37:20 +1200 From: Peter Gutmann To: denis bider CC: Tero Kivinen , "Salz, Rich" , curdle , "Mark D. Baushke" Thread-Topic: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 Thread-Index: AQHSqKbDCCDwtgJ6TEe+nT3SNcvyA6Gst6HVgAAWtwCAC4CwUIAAWYiAgAI4sek= Date: Sat, 8 Apr 2017 03:37:19 +0000 Message-ID: <1491622618430.28210@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> <22749.17194.509999.470077@fireball.acr.fi> <1491481241400.6079@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Sat, 08 Apr 2017 03:37:30 -0000 denis bider writes:=0A= =0A= >I agree with Tero in this case. Having four keys instead of one adds 2 bit= s=0A= >of security. If one of those keys is broken, the others are most likely to= o.=0A= =0A= I've already responded to this when someone else made the same erroneous=0A= claim, this only holds if you can solve the DLP for (say) a 2048-bit parame= ter=0A= set in constant time.=A0 Unless you have a mechanism for mapping a solution= for=0A= any given 2048-bit DLP to every other 2048-bit DLP in O( 1 ) time, that cla= im=0A= is fallacious.=0A= =0A= (Or perhaps disingenious, if you're aware of, but have omitted to mention,= =0A= that each bit of security represents 10,000 years of supercomputer time, or= =0A= whatever it takes to solve a 2048-bit DLP).=0A= =0A= There's a great analysis of security by diversification by "Daniel" from Br= uce=0A= Schneier's blog, in the discussion of the Kalnya block cipher:=0A= =0A= =A0 The issue of efficiency vs security works both ways. Let me draw on an= =0A= =A0 example from the law. Currently, in the USA, it is well recognized that= more=0A= =A0 than 90% of all criminal cases end with a plea bargain. Further, it is= =0A= =A0 recognized that the system has become financially dependent on this rea= lity.=0A= =A0 The consequence being is that if everyone stopped pleading guilty and= =0A= =A0 instead went to trial the entire system would freeze because there is n= o=0A= =A0 manpower or funding to try all the case, not even 25% of them.=0A= =0A= =A0 So same situation is true for crypto. Anyone who rolls their own crypto= is=0A= =A0 at one level a fool because anyone can make a standard they themselves= =0A= =A0 cannot break. Yet imagine if the world of hurt the NSA would be in if i= t had=0A= =A0 to confront one million different kinds of crypto. Each one individuall= y=0A= =A0 might be trivial to break but collectively they would freeze the agency= .=0A= =A0 There simply isn't the manpower or the funding to go through a million = cases=0A= =A0 and break each individually.=0A= =0A= =A0 So there is a strong argument that with crypto standards, whether they = be=0A= =A0 set by NIST or the Ukrainian government, makes individuals stronger whi= le=0A= =A0 making the collective weaker whereas if everyone rolled their own the= =0A= =A0 individual cyphers would be weaker but the collective would be stronger= .=0A= =0A= Peter.= From nobody Fri Apr 7 20:43:04 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 73B1C129353 for ; Fri, 7 Apr 2017 20:43:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGzh0mT0u-Se for ; Fri, 7 Apr 2017 20:43:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B854612778E for ; Fri, 7 Apr 2017 20:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491622979; x=1523158979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ewdcuH1IAt6VioLB7Vjb4dyAOAwpG87QZGHxH4LxS2c=; b=pdcMwAPhWy6NIR9aTlL1zJH2eCXecJTdKdldJGJRFtkzgFo0SiP+ypWO zUbWlmyJJ1f8T7DJbQED7IW29zs9klMlrk+de+cr7ub91rU5XH3GjuqpC IrbPbZEnF/dGSdbFsVlxYSF0VPi7LX+yxio8M8b0jpofCfIFlS9ki2qpp RxKGUdEIw+2R2TiZ+p2zoWCVea0VcDIgweNu/0BSorRb9Jean2eshc+8i FdneUeL+4ae4K0np9nJJCVxi1Zag470kVLy9sCQWVA6f0ykuxGivX26qw CBRm+gZgJfg1hzygAFShxwlW4EeNv7ZWrHEucrUbYmskhco29DQtrLtpD Q==; X-IronPort-AV: E=Sophos;i="5.37,169,1488798000"; d="scan'208";a="148584751" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Apr 2017 15:42:58 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 8 Apr 2017 15:42:57 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Sat, 8 Apr 2017 15:42:58 +1200 From: Peter Gutmann To: Watson Ladd , Daniel Migault CC: denis bider , "curdle@ietf.org" , Ilari Liusvaara Thread-Topic: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt Thread-Index: AQHSppDoJRcP16zDJU+R0iPNB50hdaGn22mQ//8x1oCAACYeAIAAPAEAgADhXwCAETaKgIAAAfeAgAFdcsk= Date: Sat, 8 Apr 2017 03:42:57 +0000 Message-ID: <1491622956832.39612@cs.auckland.ac.nz> References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 08 Apr 2017 03:43:01 -0000 Watson Ladd writes:=0A= =0A= >I strongly object. PKCS 1.5 signature verification has a long and inglorio= us=0A= >history of exploitation. PSS does not. =0A= =0A= That's because nothing uses PSS, so there's no chance to exploit it. By th= at=0A= argument we should all be using IYOPS, which not only isn't implemented but= =0A= hasn't even been defined yet, making it even more immune to exploitation.= =0A= =0A= The problem with PKCS #1 was that people implemented it wrong in a variety = of=0A= ways, if you follow the spec (encode-then-memcmp) then it's perfectly sound= .=0A= Given that most PKCS #1 implementations should by now have been fixed (it's= =0A= been what, 20 years) while if we moved to PSS we'd be starting again from= =0A= scratch with everyone getting the chance to mess things up in different way= s,=0A= PSS is at best no better than PKCS #1, at worst a lot worse.=0A= =0A= Peter.=0A= From nobody Sat Apr 8 03:50:57 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 5A0E9126CF9 for ; Sat, 8 Apr 2017 03:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 vgAzo6pgCS2p for ; Sat, 8 Apr 2017 03:50:53 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::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 D0C2F128959 for ; Sat, 8 Apr 2017 03:50:52 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id h67so80392692qke.0 for ; Sat, 08 Apr 2017 03:50:52 -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=nbm9CyvXbW4T7Ce2JwNMUTfm4aCwxcLD9zrv0O+ZZZ0=; b=lDeJJmhcPF1qo0algSLGzqablLuHgQeg5uNIqRrvWEnGVYjq3c9llABEjkoXpGzGmD jIIY3vKxxrzKwD2gm/JIPcWRwS23ITPYIsj21wElvtkLS/XTLmfG46+ZLTBJPYDeDGSa fZirekQPNwyiQh6sgX5djoIO9eju2movDHOqGNaZ901xOCyapxtJCh1YGp7FZgXcUFg/ huo4UKUl87pnpj0cztaq/njo2I7GNBTmToj+eJa+G9Z/CZw0Q9/v/XbcqeziwrUc2IP4 uy1Bt39UrgvUtw2k6ee/rQpq4QDsk6Kc33GpW9Z8YkaHoau5W+yepFnqGnC2uWfzfvUE GO+A== 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=nbm9CyvXbW4T7Ce2JwNMUTfm4aCwxcLD9zrv0O+ZZZ0=; b=oBydS/Zgtwfwog3I9Fp9Ee5E2dlh2cnjLq0hIFM7zxppaCTBCtufloQjeW4Aw9b00n C2B2QXFMfVG9+UOmTIIhxwcv+CoW/uvbRXwOZOrx0Ka0zhO4tvXGW1TMAQNm2Gd4mZSP XMnFNpGZfb8bDGdT7B3U+EKoetetu6Ffi0sYX0Bw3JyfTMCWe3IXNZImIJUH1XZUVwEi YeDadry7njPd+k3KRSLqv4AJFI3+nJf1u3+48cRrozDUrwNf7CbWkJ68sLylbO0l/mAh 1pJ07cEmA9SHTyVHYtlSvMkogy7kX1NFZXHSsgc3jw5g9Jib0Ie9xVG+O38XFsBsbUYQ /RrA== X-Gm-Message-State: AFeK/H3E44zyUma4rWsQnS+g/j/OmkP3fz3+FM9HkETIpC9LMhiHfmgnr8gawv5ynKRhPSyM2xezE6ettJqBTA== X-Received: by 10.55.144.6 with SMTP id s6mr40289967qkd.27.1491648039544; Sat, 08 Apr 2017 03:40:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Sat, 8 Apr 2017 03:40:39 -0700 (PDT) In-Reply-To: References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> From: denis bider Date: Sat, 8 Apr 2017 04:40:39 -0600 Message-ID: To: Eric Rescorla Cc: Peter Gutmann , curdle Content-Type: multipart/alternative; boundary=94eb2c08596886ed3f054ca55fa2 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 08 Apr 2017 10:50:55 -0000 --94eb2c08596886ed3f054ca55fa2 Content-Type: text/plain; charset=UTF-8 Thank you for providing this link, Eric. What this TLS section terms Zero-RTT, and what Peter appears to imply is 0RTT, seem to be completely different things. In TLS, "0RTT" data appears to be data that are sent upfront in the client's first packet to the server, encrypted using a pre-shared key before the handshake has derived a traffic secret. In SSH, there is no such concept at all. This would be equivalent to sending data encrypted with some type of pre-shared key as part of the client's KEXINIT, which is not what is happening here. The EXT_INFO packet sent by the client after NEWKEYS is not Zero-RTT. It is data sent after a full and completed key exchange. On Fri, Apr 7, 2017 at 9:21 AM, Eric Rescorla wrote: > > > On Thu, Apr 6, 2017 at 10:32 PM, denis bider > wrote: > >> > I was thinking of the problem that it's essentially >> > impossible to safely do n-RTT, n < 1, for TLS, which >> > meant that doing the same thing for SSH wasn't going >> > to be any better. I was reasoning by analogy from TLS >> > rather than sitting down and drawing diagrams for SSH >> > to try and figure out all the possible issues. >> >> OK, but I'm not familiar with the security implications of this on TLS. >> >> Can you link to any resources where this was discussed? Whether for TLS, >> or in any other context? >> > > Here is the section of TLS 1.3 that describes the security implications of > 0-RTT data: > > https://tlswg.github.io/tls13-spec/#zero-rtt-data > > FWIW, it's less clear to me that these apply to SSH because at least the > replay issues stem from the desire to have loosely coupled distributed > servers and seamless fall back from server state or synchronization > failure. > > -Ekr > > >> >> > Perhaps adding an implementation note to say that at this >> > point the crypto hasn't been confirmed yet and so you may >> > want to be careful about what you put into your extension >> > data would be useful? >> >> I agree, if this is a threat, we should add a warning in Security >> Considerations. But to make that warning, I have to understand the threat. >> >> If someone asks me about this warning, I want to be able to explain the >> reason in detail. At this point, what I can say is, "Peter said this on the >> list." That is, to me, insufficient backing. >> >> >> > Wouldn't "true" and "false" be a better way to express a >> > boolean? >> >> Yes if you could choose the type. But you can't choose the type, because >> all extensions have to use the same type. That type is a string. >> >> >> > I realise this is kinda bikeshedding, but having to look >> > up the spec just to figure out what mysterious magic >> > values in a boolean field specify seems a bit awkward. >> >> Booleans are equally mysterious. >> >> The third parameter to the Windows API function WaitForMultipleObjects is >> a boolean. Suppose an application passes "TRUE". Without checking the docs >> - what does that mean? >> >> If you check the docs, you know what "TRUE" in that context means. And if >> you check the spec here, you know what "p" and "s" mean. >> >> Booleans are not inherently self-documenting. (In fact - when used in >> languages with positional parameters, they are more frequently >> self-obfuscating.) >> >> >> > Given that there are a nonzero number of implementations >> > that send a window size of ~0 to indicate no flow control, >> > it may be useful to add an implementation note to point >> > this out. >> >> OK. I added the following sub-section to my current working copy: >> >> >> 3.3.1. Implementation Note: Prior "No Flow Control" Practice >> >> Before this extension, some applications would simply not implement >> SSH flow control, sending an initial channel window size of 2^32 - 1. >> Applications SHOULD NOT do this for the following reasons: >> >> - It is entirely within the realm of possibility to transfer more than >> 2^32 bytes over a channel. The channel will then hang if the other >> party implements SSH flow control according to [RFC4254]. >> >> - There exist implementations which cannot handle such large channel >> window sizes, and will exhibit non-graceful behaviors, including >> disconnection. >> >> >> denis >> >> >> >> On Thu, Apr 6, 2017 at 6:04 AM, Peter Gutmann >> wrote: >> >>> denis bider (Bitvise) writes: >>> >>> >Can you point out some of these subtle problems that could occur in this >>> >regard in SSH? >>> >>> I was thinking of the problem that it's essentially impossible to safely >>> do n- >>> RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn't >>> going to be any better. I was reasoning by analogy from TLS rather than >>> sitting down and drawing diagrams for SSH to try and figure out all the >>> possible issues. >>> >>> >Under the assumption that such an extension were defined, can you point >>> out >>> >at least one way that sending this info right after NEWKEYS can help an >>> >attacker? >>> >>> It depends on the extension. Without one defined, there's no way to >>> tell at >>> the moment. I could invent something that works out badly, but that'd be >>> creating a strawman... my concern is that in the future someone may >>> define a >>> problematic extension without realising that they're creating a problem. >>> Perhaps adding an implementation note to say that at this point the >>> crypto >>> hasn't been confirmed yet and so you may want to be careful about what >>> you put >>> into your extension data would be useful? >>> >>> >But the extension value field is generically a string (it must be same >>> type >>> >for all extensions, so unsupported extensions can be decoded and >>> ignored). >>> >"p" and "s" are therefore fitting ways to express this boolean. >>> >>> Wouldn't "true" and "false" be a better way to express a boolean? I >>> realise >>> this is kinda bikeshedding, but having to look up the spec just to >>> figure out >>> what mysterious magic values in a boolean field specify seems a bit >>> awkward. >>> >>> >Properly implemented flow control is superior. However, this extension >>> is a >>> >nod to that not everyone will be using an SSH library that does this >>> right, >>> >and "no-flow-control" is a better option if your needs are simple, and >>> you >>> >don't have a few years to get this right. >>> >>> Given that there are a nonzero number of implementations that send a >>> window >>> size of ~0 to indicate no flow control, it may be useful to add an >>> implementation note to point this out. I enabled some diagnostic code to >>> throw an exception in my code if it found this from another >>> implementation >>> (other than mine) and got, uh, feedback from beta-testers about it, so at >>> least some implementations are using a pseudo-infinite window size to >>> indicate >>> no flow control. I'm not saying it should be adopted as an alternative >>> to >>> "no-flow-control", but merely to alert implementers about the practice, >>> e.g. a >>> certain big iron vendor whose device would crash and reboot as it tried >>> to >>> allocate ~0 bytes of memory to match the widow size. >>> >>> Peter. >>> _______________________________________________ >>> 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 >> >> > --94eb2c08596886ed3f054ca55fa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for providing this link, Eric.

What this TLS section terms Zero-RTT, and what Peter appears to imply is = 0RTT, seem to be completely different things.

In T= LS, "0RTT" data appears to be data that are sent upfront in the c= lient's first packet to the server, encrypted using a pre-shared key be= fore the handshake has derived a traffic secret.

I= n SSH, there is no such concept at all. This would be equivalent to sending= data encrypted with some type of pre-shared key as part of the client'= s KEXINIT, which is not what is happening here.

Th= e EXT_INFO packet sent by the client after NEWKEYS is not Zero-RTT. It is d= ata sent after a full and completed key exchange.

=

O= n Fri, Apr 7, 2017 at 9:21 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:


On Thu, Apr 6, 20= 17 at 10:32 PM, denis bider <denisbider.ietf@gmail.com> wrote:
> I was thinking = of the problem that it's essentially
> impossible t= o safely do n-RTT, n < 1, for TLS, which
> meant that doing the same thing for SSH wasn= 9;t going
> to be any better.=C2=A0 I was reasoning by analogy= from TLS
> rather than sitting down and drawing diagrams for = SSH
> to try and figure out all the possible issues.

OK, but I'm not familiar with the security impli= cations of this on TLS.

Can you link to any resour= ces where this was discussed? Whether for TLS, or in any other context?

Here is the section of TLS = 1.3 that describes the security implications of
0-RTT data:
=


FWIW, it's less clear to me that = these apply to SSH because at least the
replay issues stem from t= he desire to have loosely coupled distributed
servers and seamles= s fall back from server state or synchronization failure.

-Ekr



> Perhaps adding a= n implementation note to say that at this
> point the crypto h= asn't been confirmed yet and so you may
> want to be caref= ul about what you put into your extension
> data would be usef= ul?

=C2=A0I agree, if this is a threat, we = should add a warning in Security Considerations. But to make that warning, = I have to understand the threat.

If someone asks m= e about this warning, I want to be able to explain the reason in detail. At= this point, what I can say is, "Peter said this on the list." Th= at is, to me, insufficient backing.


> Wouldn't "true&q= uot; and "false" be a better way to express a
> bool= ean?

Yes if you could choose the type. But = you can't choose the type, because all extensions have to use the same = type. That type is a string.


> I realise this is kinda bikeshed= ding, but having to look
> up the spec just to figure out what= mysterious magic
> values in a boolean field specify seems a = bit awkward.

Booleans are equally mysteriou= s.

The third parameter to the Windows API function= WaitForMultipleObjects is a boolean. Suppose an application passes "T= RUE". Without checking the docs - what does that mean?

<= /div>
If you check the docs, you know what "TRUE" in that con= text means. And if you check the spec here, you know what "p" and= "s" mean.

Booleans are not inherently s= elf-documenting. (In fact - when used in languages with positional paramete= rs, they are more frequently self-obfuscating.)


> Given that th= ere are a nonzero number of implementations
> that send a wind= ow size of ~0 to indicate no flow control,
> it may be useful = to add an implementation note to point
> this out.=C2=A0
=

OK. I added the following sub-section to my curr= ent working copy:


3.3.1.=C2=A0 Impl= ementation Note: Prior "No Flow Control" Practice

<= /div>
=C2=A0 Before this extension, some applications would simply not = implement
=C2=A0 SSH flow control, sending an initial channel win= dow size of 2^32 - 1.
=C2=A0 Applications SHOULD NOT do this for = the following reasons:
=C2=A0=C2=A0
=C2=A0 - It is enti= rely within the realm of possibility to transfer more than
=C2=A0= =C2=A0 2^32 bytes over a channel. The channel will then hang if the other<= /div>
=C2=A0 =C2=A0 party implements SSH flow control according to [RFC= 4254].
=C2=A0 =C2=A0=C2=A0
=C2=A0 - There exist impleme= ntations which cannot handle such large channel
=C2=A0 =C2=A0 win= dow sizes, and will exhibit non-graceful behaviors, including
=C2= =A0 =C2=A0 disconnection.


denis



On Thu, Apr 6, 2017 at= 6:04 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> = wrote:
denis bider (Bi= tvise) <ie= tf-ssh3@denisbider.com> writes:

>Can you point out some of these subtle problems that could occur in thi= s
>regard in SSH?

I was thinking of the problem that it's essentially impossible to safel= y do n-
RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn&= #39;t
going to be any better.=C2=A0 I was reasoning by analogy from TLS rather th= an
sitting down and drawing diagrams for SSH to try and figure out all the
possible issues.

>Under the assumption that such an extension were defined, can you point= out
>at least one way that sending this info right after NEWKEYS can help an=
>attacker?

It depends on the extension.=C2=A0 Without one defined, there's no way = to tell at
the moment.=C2=A0 I could invent something that works out badly, but that&#= 39;d be
creating a strawman... my concern is that in the future someone may define = a
problematic extension without realising that they're creating a problem= .
Perhaps adding an implementation note to say that at this point the crypto<= br> hasn't been confirmed yet and so you may want to be careful about what = you put
into your extension data would be useful?

>But the extension value field is generically a string (it must be same = type
>for all extensions, so unsupported extensions can be decoded and ignore= d).
>"p" and "s" are therefore fitting ways to express t= his boolean.

Wouldn't "true" and "false" be a better way to expr= ess a boolean?=C2=A0 I realise
this is kinda bikeshedding, but having to look up the spec just to figure o= ut
what mysterious magic values in a boolean field specify seems a bit awkward= .

>Properly implemented flow control is superior. However, this extension = is a
>nod to that not everyone will be using an SSH library that does this ri= ght,
>and "no-flow-control" is a better option if your needs are si= mple, and you
>don't have a few years to get this right.

Given that there are a nonzero number of implementations that send a window=
size of ~0 to indicate no flow control, it may be useful to add an
implementation note to point this out.=C2=A0 I enabled some diagnostic code= to
throw an exception in my code if it found this from another implementation<= br> (other than mine) and got, uh, feedback from beta-testers about it, so at least some implementations are using a pseudo-infinite window size to indic= ate
no flow control.=C2=A0 I'm not saying it should be adopted as an altern= ative to
"no-flow-control", but merely to alert implementers about the pra= ctice, e.g. a
certain big iron vendor whose device would crash and reboot as it tried to<= br> allocate ~0 bytes of memory to match the widow size.

Peter.
_______________________________________________
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


--94eb2c08596886ed3f054ca55fa2-- From nobody Sat Apr 8 03:56: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 6B3BE128B51 for ; Sat, 8 Apr 2017 03:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 ZXR7c5vwXLtf for ; Sat, 8 Apr 2017 03:56:25 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 87AC2126CF9 for ; Sat, 8 Apr 2017 03:56:25 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id f133so62992428qke.2 for ; Sat, 08 Apr 2017 03:56:25 -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=U61i3SjaFo/SeW5Uzq+QLJBxTEB/RQ6poWne5IT28Iw=; b=CkKIxDNxOd3oJdhm0OvpaHMBu6a8uQ/Cw8yo5to7Uvs0KrZ6pppNMeL3Y2sXiWGzjV hIJSwsc0Ts05ltsCEk0YseqKNUJorOKVOy9AMWkJedkkVJCGwGAP0Z+HCTnEEtBXpxy6 gmZF9ZpJE9EL5GXCtG0Tca0yNaGLx+NGJGobVTrqCe0NJvXEPBsTgEIvGm0lyr2ag263 1i6E8IxWEsfljPgiJb/SThOACtE+deCi7pUNN7B7tJ4L5U0SfM9Ae7wuSBM5r2bK3q/d Y4PUkg1nn4WSZ1qMReL3oaC/oL+Q1xnibw/RtMSC1hVkvQssHLTUHrws7vz7KQWtfUdg R1BQ== 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=U61i3SjaFo/SeW5Uzq+QLJBxTEB/RQ6poWne5IT28Iw=; b=Pe/O2n9ycFbXm4r21osUcRLS9DNjTPqf04DXAayKtkT/Xnlqk5g3iLIgbzJTuRbvNM +QOHOpku6Bo5hGPA8VK8q7w+0ePXE2EekqrPs9BrsmXx586llf4E5Vq1CopakU865H2l 8dwqJ4XwhQWrhbwvz/LfiWVnvf0KRs50TRg3kycYqdTesrcbY8GQM2EjqyjERkXCiY84 zADN27402W4Nqvc7wmc0Uj6kOwaVd17H1l3ixZZItKbUnGCnui8E4espppuyNR3kDjbN cwnxq8RM2X4lPS0gtk94iHGcKqPhSHDwvHF2L0xI874WxGyGAlpXgul6mI5LcqzGrj4x T7jw== X-Gm-Message-State: AN3rC/4c4bEHxt34WZRTNqeoliQAT8wn1yocgeyySAJCN1Cqsii9U4QRw58MG9CkrPcdTYojt7sPz87kK1LfIQ== X-Received: by 10.55.71.137 with SMTP id u131mr11958835qka.317.1491648984690; Sat, 08 Apr 2017 03:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Sat, 8 Apr 2017 03:56:24 -0700 (PDT) In-Reply-To: <1491621835513.71448@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> <1491621835513.71448@cs.auckland.ac.nz> From: denis bider Date: Sat, 8 Apr 2017 04:56:24 -0600 Message-ID: To: Peter Gutmann Cc: curdle Content-Type: multipart/alternative; boundary=001a114a7fb6dcb6bf054ca597a0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 08 Apr 2017 10:56:27 -0000 --001a114a7fb6dcb6bf054ca597a0 Content-Type: text/plain; charset=UTF-8 > There are a range of opinions on how safe it is, > but in general it seems 0RTT is bad According to the link provided by Eric, Zero-RTT in TLS is a concept that does not even exist in SSH. I can see why people would have concerns about sending data upfront encrypted with a make-do key based only on a pre-shared secret. That is inherently problematic and needs care. If SSH had this concept, it would involve bundling some kind of pre-encrypted data with the client's original KEXINIT. We do not have anything like that. EXT_INFO is sent after several round-trips, encrypted after a full, completed key exchange. I don't see any way that's similar to Zero-RTT. > What I meant was use the string value "true" for > boolean true and "false" for boolean false. In that case I would prefer to go for full strings like "preferred" and "supported", but that seemed like a waste. :) > Speaking of embedded, would there be any interest in > adding an extension to say that an implementation only > supports one channel, and for the other side to not try > anything fancy beyond treating it as an encrypted telnet? As-is, the "no-flow-control" extension already dictates there will be no more than one concurrent channel. What do you have in mind beyond that? denis On Fri, Apr 7, 2017 at 9:24 PM, Peter Gutmann wrote: > denis bider writes: > > >Can you link to any resources where this was discussed? Whether for TLS, > or > >in any other context? > > It's difficult providing a useful link because it's been discussed on and > off > in various threads on the TLS WG list for quite some time. There are a > range > of opinions on how safe it is, but in general it seems 0RTT is bad and > 0.5RTT > is iffy. That is, you can do 0RTT if you're incredibly careful (I talked > to a > dev at a large content provider and he said their analysis showed they'd > have > to implement nonzero-RTT at the application layer in order to deal with > 0RTT > at the TLS layer, which kinda defeats the point), but if anyone ever tries > it > I foresee a range of Black Hat/Defcon talks and conference papers on how to > exploit it following shortly afterwards. > > >Yes if you could choose the type. But you can't choose the type, because > all > >extensions have to use the same type. That type is a string. > > What I meant was use the string value "true" for boolean true and "false" > for > boolean false. It seemed pretty intuitive :-). > > >OK. I added the following sub-section to my current working copy: > > Thanks, that helps to document existing practice and alert implementers. > > Incidentally, the places where I've found this is typically embedded, where > there's no chance of every transferring anywhere near ~0 bytes, so it's > not a > problem. OTOH the second issue is real, you can force a reboot of one > vendor's carrier-grade routers by opening an SSH connection to it with a > window size of ~0. > > Speaking of embedded, would there be any interest in adding an extension to > say that an implementation only supports one channel, and for the other > side > to not try anything fancy beyond treating it as an encrypted telnet? This > is > also fairly common in embedded, where you're emulating encrypted telnet and > nothing more. scp/SFTP is handled by moving the binary data over the > encrypted-telnet channel, with various degrees of hackery. > > Peter. > > --001a114a7fb6dcb6bf054ca597a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0There are a ran= ge=C2=A0of opinions on how safe it = is,
> but in general it seem= s 0RTT is bad

=
According to the link provided = by Eric, Zero-RTT in TLS is a concept that does not even exist in SSH. I ca= n see why people would have concerns about sending data upfront encrypted w= ith a make-do key based only on a pre-shared secret. That is inherently pro= blematic and needs care.
=
If SSH had this conc= ept, it would involve bundling some kind of pre-encrypted data with the cli= ent's original KEXINIT. We do not have anything like that.
=

EXT_INFO is sent after several round-trips, encrypted aft= er a full, completed key exchange. I don't see any way that's simil= ar to Zero-RTT.


>=C2=A0What I meant was use the string value "true" for
> boolean true and "false" = for=C2=A0boolean false.

In that case I would prefer to go for full strings like = "preferred" and "supported", but that seemed like a was= te. :)

<= div>
>=C2=A0Speaking= of embedded, would there be any interest in
> adding an extension to=C2=A0say that an implementation only
> supports one channel, and for the other s= ide=C2=A0to not try
> anything fancy beyond treating it a= s an encrypted telnet?
As-is, the "no-fl= ow-control" extension already dictates there will be no more than one = concurrent channel. What do you have in mind beyond that?
=
denis



On Fri, Apr 7, 2017 = at 9:24 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bider <= ;denisbider.ietf@gmail.com= > writes:

>Can you link to any resources where this was discussed? Whether for TLS= , or
>in any other context?

It's difficult providing a useful link because it's been dis= cussed on and off
in various threads on the TLS WG list for quite some time.=C2=A0 There are = a range
of opinions on how safe it is, but in general it seems 0RTT is bad and 0.5R= TT
is iffy.=C2=A0 That is, you can do 0RTT if you're incredibly careful (I= talked to a
dev at a large content provider and he said their analysis showed they'= d have
to implement nonzero-RTT at the application layer in order to deal with 0RT= T
at the TLS layer, which kinda defeats the point), but if anyone ever tries = it
I foresee a range of Black Hat/Defcon talks and conference papers on how to=
exploit it following shortly afterwards.

>Yes if you could choose the type. But you can't choose the type, be= cause all
>extensions have to use the same type. That type is a string.

What I meant was use the string value "true" for boolean t= rue and "false" for
boolean false.=C2=A0 It seemed pretty intuitive :-).

>OK. I added the following sub-section to my current working copy:

Thanks, that helps to document existing practice and alert implement= ers.

Incidentally, the places where I've found this is typically embedded, w= here
there's no chance of every transferring anywhere near ~0 bytes, so it&#= 39;s not a
problem.=C2=A0 OTOH the second issue is real, you can force a reboot of one=
vendor's carrier-grade routers by opening an SSH connection to it with = a
window size of ~0.

Speaking of embedded, would there be any interest in adding an extension to=
say that an implementation only supports one channel, and for the other sid= e
to not try anything fancy beyond treating it as an encrypted telnet?=C2=A0 = This is
also fairly common in embedded, where you're emulating encrypted telnet= and
nothing more.=C2=A0 scp/SFTP is handled by moving the binary data over the<= br> encrypted-telnet channel, with various degrees of hackery.

Peter.

=C2=A0 =C2=A0

--001a114a7fb6dcb6bf054ca597a0-- From nobody Sat Apr 8 04:13: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 56D8A1287A3 for ; Sat, 8 Apr 2017 04:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[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 2UMJ49QBg73O for ; Sat, 8 Apr 2017 04:13:20 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909DD128B51 for ; Sat, 8 Apr 2017 04:13:20 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id f133so63135692qke.2 for ; Sat, 08 Apr 2017 04:13:20 -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=eH3Q+U0WjYrZzt13okEztjnqKGEHTBmSzaIGyNDoF2w=; b=YwEUCrVXqLo9jXGvxc+bY0q/TzBfQ6VdadcBY+xdU6DwXgxbod+SMx25WKLaNd8/Yi TVv9mkXT0LBadlaVSlhaDHhiSB5mLnargiCEQYyoYmPvzfc2Iq9gdMgr8ILDDChBocf8 RIOREOMcIthsPM8Gm3QFc3+WO/JdrtKfhXwslEo3LhubaQuvcSCXa6JYhebGXc7TE13j DRSqxE3EGiPwlZAES1+SqHyoP/FQMQcyBD6ECjvJYmi0Dv1J8ZYx0YcBsF5e+1RsOz+M SHJVFu+8ZejlKJgoVRZvcIrK2msQg6laygjqrnrJaZZR23YWTUzqU6qQTya8ZvOAEAkB GM7w== 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=eH3Q+U0WjYrZzt13okEztjnqKGEHTBmSzaIGyNDoF2w=; b=Dgv2hU9zrCZ5UfNTZHZak7J+B2Is8DT2YkULjBlKwesBAU97Kvhxhoysgq36P5nnOa ihXmJu7muF6uRMrcV2jR8MrhiNAcGMS7/FlWb/rd8waS55aU8fUMWQB8sJ9OyOQrGNes zhEy5AtYqLfvSwYVuYUZvZ3pPaVTWjlD3eTtV9xTQMwnZILVLWCdmRYamHd0E0m0xfvC jB6moBol8SGHMRtJXCTfLBl/idxlCVs9J0IBx5rqHgs5gyDmOtLxwTtyM4SJ4ZB9oe8+ /Ji4nN61JA6GqAw7fvtDnSFDbrhGoJ57BfKrjlj5pgfvBnsXXHDuY4oZitqk67taHU7C xjqg== X-Gm-Message-State: AFeK/H0ZJD/1BPsW1gu7WXs77YcLbM3J5HZs/C+T1GxISNOq7KvgvZhOGF4m0bYdKPEBDUHUnEUz65WtTgQRew== X-Received: by 10.55.110.131 with SMTP id j125mr41192364qkc.106.1491649999731; Sat, 08 Apr 2017 04:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Sat, 8 Apr 2017 04:13:19 -0700 (PDT) In-Reply-To: <1491622618430.28210@cs.auckland.ac.nz> References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> <22749.17194.509999.470077@fireball.acr.fi> <1491481241400.6079@cs.auckland.ac.nz> <1491622618430.28210@cs.auckland.ac.nz> From: denis bider Date: Sat, 8 Apr 2017 05:13:19 -0600 Message-ID: To: Peter Gutmann Cc: Tero Kivinen , "Salz, Rich" , curdle , "Mark D. Baushke" Content-Type: multipart/alternative; boundary=94eb2c05be845d06f5054ca5d429 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Sat, 08 Apr 2017 11:13:22 -0000 --94eb2c05be845d06f5054ca5d429 Content-Type: text/plain; charset=UTF-8 This rides entirely on the assumption that if a widely known large DH group is broken, the break will be just feasible enough to be doable, and just difficult enough that repeating it two or three times is outside the budget. This is an extraordinarily contrived set of circumstances, which is probably not true even now for 1024-bit groups. Note that the argument you cite is for "one million different kinds of crypto", not "two or three different kinds of crypto". One million is 20 additional bits. This is a solid argument for dynamically generated groups, which seem to me a problem worth solving (i.e. provide a way the other party can be sure the group is good). But it does not appear to be a particularly strong argument in favor of different fixed groups in SSH vs. e.g. IKE. On Fri, Apr 7, 2017 at 9:37 PM, Peter Gutmann wrote: > denis bider writes: > > >I agree with Tero in this case. Having four keys instead of one adds 2 > bits > >of security. If one of those keys is broken, the others are most likely > too. > > I've already responded to this when someone else made the same erroneous > claim, this only holds if you can solve the DLP for (say) a 2048-bit > parameter > set in constant time. Unless you have a mechanism for mapping a solution > for > any given 2048-bit DLP to every other 2048-bit DLP in O( 1 ) time, that > claim > is fallacious. > > (Or perhaps disingenious, if you're aware of, but have omitted to mention, > that each bit of security represents 10,000 years of supercomputer time, or > whatever it takes to solve a 2048-bit DLP). > > There's a great analysis of security by diversification by "Daniel" from > Bruce > Schneier's blog, in the discussion of the Kalnya block cipher: > > The issue of efficiency vs security works both ways. Let me draw on an > example from the law. Currently, in the USA, it is well recognized that > more > than 90% of all criminal cases end with a plea bargain. Further, it is > recognized that the system has become financially dependent on this > reality. > The consequence being is that if everyone stopped pleading guilty and > instead went to trial the entire system would freeze because there is no > manpower or funding to try all the case, not even 25% of them. > > So same situation is true for crypto. Anyone who rolls their own crypto > is > at one level a fool because anyone can make a standard they themselves > cannot break. Yet imagine if the world of hurt the NSA would be in if it > had > to confront one million different kinds of crypto. Each one individually > might be trivial to break but collectively they would freeze the agency. > There simply isn't the manpower or the funding to go through a million > cases > and break each individually. > > So there is a strong argument that with crypto standards, whether they be > set by NIST or the Ukrainian government, makes individuals stronger while > making the collective weaker whereas if everyone rolled their own the > individual cyphers would be weaker but the collective would be stronger. > > Peter. --94eb2c05be845d06f5054ca5d429 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This rides entirely on the assumption that if a widely kno= wn large DH group is broken, the break will be just feasible enough to be d= oable, and just difficult enough that repeating it two or three times is ou= tside the budget.

This is an extraordinarily contrived s= et of circumstances, which is probably not true even now for 1024-bit group= s.

Note that the argument you cite is for "on= e million different kinds of crypto", not "two or three different= kinds of crypto". One million is 20 additional bits.

This is a solid argument for dynamically generated groups, which s= eem to me a problem worth solving (i.e. provide a way the other party can b= e sure the group is good). But it does not appear to be a particularly stro= ng argument in favor of different fixed groups in SSH vs. e.g. IKE.


On Fri, Ap= r 7, 2017 at 9:37 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz= > wrote:
denis= bider <denisbider.ietf@gma= il.com> writes:

>I agree with Tero in this case. Having four keys instead of one adds 2 = bits
>of security. If one of those keys is broken, the others are most likely= too.

I've already responded to this when someone else made the same e= rroneous
claim, this only holds if you can solve the DLP for (say) a 2048-bit parame= ter
set in constant time.=C2=A0 Unless you have a mechanism for mapping a solut= ion for
any given 2048-bit DLP to every other 2048-bit DLP in O( 1 ) time, that cla= im
is fallacious.

(Or perhaps disingenious, if you're aware of, but have omitted to menti= on,
that each bit of security represents 10,000 years of supercomputer time, or=
whatever it takes to solve a 2048-bit DLP).

There's a great analysis of security by diversification by "Daniel= " from Bruce
Schneier's blog, in the discussion of the Kalnya block cipher:

=C2=A0 The issue of efficiency vs security works both ways. Let me draw on = an
=C2=A0 example from the law. Currently, in the USA, it is well recognized t= hat more
=C2=A0 than 90% of all criminal cases end with a plea bargain. Further, it = is
=C2=A0 recognized that the system has become financially dependent on this = reality.
=C2=A0 The consequence being is that if everyone stopped pleading guilty an= d
=C2=A0 instead went to trial the entire system would freeze because there i= s no
=C2=A0 manpower or funding to try all the case, not even 25% of them.

=C2=A0 So same situation is true for crypto. Anyone who rolls their own cry= pto is
=C2=A0 at one level a fool because anyone can make a standard they themselv= es
=C2=A0 cannot break. Yet imagine if the world of hurt the NSA would be in i= f it had
=C2=A0 to confront one million different kinds of crypto. Each one individu= ally
=C2=A0 might be trivial to break but collectively they would freeze the age= ncy.
=C2=A0 There simply isn't the manpower or the funding to go through a m= illion cases
=C2=A0 and break each individually.

=C2=A0 So there is a strong argument that with crypto standards, whether th= ey be
=C2=A0 set by NIST or the Ukrainian government, makes individuals stronger = while
=C2=A0 making the collective weaker whereas if everyone rolled their own th= e
=C2=A0 individual cyphers would be weaker but the collective would be stron= ger.

Peter.

--94eb2c05be845d06f5054ca5d429-- From nobody Sat Apr 8 04:20:54 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 C25061287A3 for ; Sat, 8 Apr 2017 04:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 n8YAz4mmxp5x for ; Sat, 8 Apr 2017 04:20:51 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 680C6120725 for ; Sat, 8 Apr 2017 04:20:51 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id c45so35960931qtb.1 for ; Sat, 08 Apr 2017 04:20:51 -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=eYmqjCGKJgBGI5FGgj5dPiVW8e0FyoDhDjTwOYQy2mk=; b=Xqa470LgoeLcEZyl1bjnLkmT2/W/PmMCqDLytkdBB2E/K5yb6FQ+WDEFB+bgzlOojJ 1Z7Y/18VbD1/kTmNzBvMXJI7yCkGz5/Gi9Salp7NQhYb/LsZU6EXJB7sgrp/hkxDLHU0 b8hNdSvQA6L2A4jAUSI2WXnC3zfIfgMI0KDrpcLFyHNYEjH7uX687NFoZCRLgxIK9QmL eZ9nNXA1pgkMze6SvDZcg+d7UAlrpLquJTillgTP4aqRtv6oe1Myi6RsvHGtnjfrLZFu EvwjHU1UIW4TegQ9fPLkLHfrfoXpbrX27fFHoOpkMOLJu8ODCMbAhygzSBBf5b14DLHl xTjA== 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=eYmqjCGKJgBGI5FGgj5dPiVW8e0FyoDhDjTwOYQy2mk=; b=MdRjJgamUy7b8VLnD6Ws3ESyueUYRTn5rGanAWlsluWMfpUEIgmt4Q7M0uL6xcQmqJ vN58rhXS8hs1A6D4gNXhSkX/j4A0XKieE58DqwlatTUKtzLq/vATOhFiAVFgQiNs5gH4 Ex/9+3TIrq6qef+cJIfeMLheyZtsvzU5tYl0yOBxXTyriOS3GUQkhu/qFY4QdbDP4yVU IW5I2iZm22ZsQOtUM8jKQwSpO3bSFLbgYHGO6BG20h9PSytRW1BQk3bJIGhIkbi64gYc h7S4l/7Yq3lzY3fE/vqYTd1wtY/hKDikFpQs2w6m6DIsWXSyfAC9zaDlos1OFPTV7j/G ZedA== X-Gm-Message-State: AFeK/H1+ocalwXtuWOfVdutVvC7UGBa0KiKVIDYlpyP8pae1SIJILza/nufUZu9znCREPLqF8513AOw8Joyj8A== X-Received: by 10.237.59.248 with SMTP id s53mr18403822qte.177.1491650450391; Sat, 08 Apr 2017 04:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Sat, 8 Apr 2017 04:20:49 -0700 (PDT) In-Reply-To: <1491622956832.39612@cs.auckland.ac.nz> References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> <1491622956832.39612@cs.auckland.ac.nz> From: denis bider Date: Sat, 8 Apr 2017 05:20:49 -0600 Message-ID: To: Peter Gutmann Cc: Watson Ladd , Daniel Migault , "curdle@ietf.org" , Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c1914ac3987de054ca5efa1 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 08 Apr 2017 11:20:53 -0000 --94eb2c1914ac3987de054ca5efa1 Content-Type: text/plain; charset=UTF-8 I tend to agree. While it is plausible that PSS avoids providing implementers an easy way to incorrectly verify a signature, I am not in favor of banning working concepts because they've been implemented incorrectly. By that token, the most important proviso we should put in the drafts is: "Do not, under any circumstances, implement this protocol in a memory unsafe language, such as C or C++"... On Fri, Apr 7, 2017 at 9:42 PM, Peter Gutmann wrote: > Watson Ladd writes: > > >I strongly object. PKCS 1.5 signature verification has a long and > inglorious > >history of exploitation. PSS does not. > > That's because nothing uses PSS, so there's no chance to exploit it. By > that > argument we should all be using IYOPS, which not only isn't implemented but > hasn't even been defined yet, making it even more immune to exploitation. > > The problem with PKCS #1 was that people implemented it wrong in a variety > of > ways, if you follow the spec (encode-then-memcmp) then it's perfectly > sound. > Given that most PKCS #1 implementations should by now have been fixed (it's > been what, 20 years) while if we moved to PSS we'd be starting again from > scratch with everyone getting the chance to mess things up in different > ways, > PSS is at best no better than PKCS #1, at worst a lot worse. > > Peter. > --94eb2c1914ac3987de054ca5efa1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree. While it is plausible that PSS avoids pro= viding implementers an easy way to incorrectly verify a signature, I am not= in favor of banning working concepts because they've been implemented = incorrectly.

By that token, the most important proviso w= e should put in the drafts is: "Do not, under any circumstances, imple= ment this protocol in a memory unsafe language, such as C or C++"...

On Fri,= Apr 7, 2017 at 9:42 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz<= /a>> wrote:
Wa= tson Ladd <watsonbladd@gmail.co= m> writes:

>I strongly object. PKCS 1.5 signature verification has a long and inglo= rious
>history of exploitation. PSS does not.

That's because nothing uses PSS, so there's no chance to exp= loit it.=C2=A0 By that
argument we should all be using IYOPS, which not only isn't implemented= but
hasn't even been defined yet, making it even more immune to exploitatio= n.

The problem with PKCS #1 was that people implemented it wrong in a variety = of
ways, if you follow the spec (encode-then-memcmp) then it's perfectly s= ound.
Given that most PKCS #1 implementations should by now have been fixed (it&#= 39;s
been what, 20 years) while if we moved to PSS we'd be starting again fr= om
scratch with everyone getting the chance to mess things up in different way= s,
PSS is at best no better than PKCS #1, at worst a lot worse.

Peter.

--94eb2c1914ac3987de054ca5efa1-- From nobody Sat Apr 8 07:52:57 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 C2336127977 for ; Sat, 8 Apr 2017 07:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[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 fzb3cbLeGmuJ for ; Sat, 8 Apr 2017 07:52:54 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 C913A126C3D for ; Sat, 8 Apr 2017 07:52:53 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id d191so45018524ywe.2 for ; Sat, 08 Apr 2017 07:52:53 -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=JcXUj+itlQ3OEBtID1XrYYXhQGVcOZ0mC9w35nTT7Eo=; b=g2fFy4HbXo43/smXeFP2rogJjUDJconlTrc1Up9LnWm3tEg1x25tvwZMtbG/DFhOpt lnfFKUtHk+5eymKEdRlb9FuppxhdWOojkuqurDOMj0aTehMf7iHSjDk4QwdvW05H/vTr nKKpSAJ5hmnt03QA/AcL1mk4dfzkvb6g1+PIfQepnar9ULIp0nhCRsWTIe8qpUjFfj5o Oem6VxZBQx/H5XH8lLaZZzPZsk8Gl/pP/AvXgNIAzcpRCD6/EcytGUyc7C66UByQt6gj ezRE+K8zNuya91PKMkQgFCdgDeBiy99ar2gX328qgp7h2uKdqBnCQCMAknnPWlRYP76K hlYA== 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=JcXUj+itlQ3OEBtID1XrYYXhQGVcOZ0mC9w35nTT7Eo=; b=knDI0DgsUIXMOcT9JAxGNDVcENlGx+/fbh78Fb9RQ9okNT/fe2Z4l1PXLlGxI5qmSY W3I+jhwMoY3LqcpcY7NEOW13Rq4iu18SNf+KMOBHNu5PvtKbuH98XgWVgtQa7+IfLPPU Ijro+HAkPk5wYMrOvECpYU0tuSDmTuYFNu3ekfK4rv61EJNljxHCRBGSK0QVM5Rm8MUb dRO0d4nSocZL+/XxgVhKwBDkFTzPSoK7lKJv53+f2shRh7Whg67nkHshjyxLsoEHIaou v712M/cNuL3u3j9+9Ka2oinpcRvQDI7Vr5E+zyNVBT1/CXv08jCpxm42o75+gDDcVM7m DqGg== X-Gm-Message-State: AFeK/H0oGPFvFfs5NpI/4+YkmzqV3kkQ/BSKY1ULXGoDY5LXyML5qX2xfAGTF4u25ZLVpxWj//Oujyd0Y7BrYg== X-Received: by 10.129.108.214 with SMTP id h205mr30509276ywc.71.1491663173017; Sat, 08 Apr 2017 07:52:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Sat, 8 Apr 2017 07:52:12 -0700 (PDT) In-Reply-To: References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> From: Eric Rescorla Date: Sat, 8 Apr 2017 07:52:12 -0700 Message-ID: To: denis bider Cc: Peter Gutmann , curdle Content-Type: multipart/alternative; boundary=001a114e81dc8d7ef0054ca8e516 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 08 Apr 2017 14:52:57 -0000 --001a114e81dc8d7ef0054ca8e516 Content-Type: text/plain; charset=UTF-8 On Sat, Apr 8, 2017 at 3:40 AM, denis bider wrote: > Thank you for providing this link, Eric. > > What this TLS section terms Zero-RTT, and what Peter appears to imply is > 0RTT, seem to be completely different things. > > In TLS, "0RTT" data appears to be data that are sent upfront in the > client's first packet to the server, encrypted using a pre-shared key > before the handshake has derived a traffic secret. > That's more-or-less correct. You don't actually use the PSK but derive a separate key from the PSK. The security challenges mostly derive from the fact that the server doesn't have an opportunity to provide a nonce. In SSH, there is no such concept at all. This would be equivalent to > sending data encrypted with some type of pre-shared key as part of the > client's KEXINIT, which is not what is happening here. > > The EXT_INFO packet sent by the client after NEWKEYS is not Zero-RTT. It > is data sent after a full and completed key exchange. > I'm not familiar enough with SSH to have an opinion here. -Ekr > > > On Fri, Apr 7, 2017 at 9:21 AM, Eric Rescorla wrote: > >> >> >> On Thu, Apr 6, 2017 at 10:32 PM, denis bider >> wrote: >> >>> > I was thinking of the problem that it's essentially >>> > impossible to safely do n-RTT, n < 1, for TLS, which >>> > meant that doing the same thing for SSH wasn't going >>> > to be any better. I was reasoning by analogy from TLS >>> > rather than sitting down and drawing diagrams for SSH >>> > to try and figure out all the possible issues. >>> >>> OK, but I'm not familiar with the security implications of this on TLS. >>> >>> Can you link to any resources where this was discussed? Whether for TLS, >>> or in any other context? >>> >> >> Here is the section of TLS 1.3 that describes the security implications of >> 0-RTT data: >> >> https://tlswg.github.io/tls13-spec/#zero-rtt-data >> >> FWIW, it's less clear to me that these apply to SSH because at least the >> replay issues stem from the desire to have loosely coupled distributed >> servers and seamless fall back from server state or synchronization >> failure. >> >> -Ekr >> >> >>> >>> > Perhaps adding an implementation note to say that at this >>> > point the crypto hasn't been confirmed yet and so you may >>> > want to be careful about what you put into your extension >>> > data would be useful? >>> >>> I agree, if this is a threat, we should add a warning in Security >>> Considerations. But to make that warning, I have to understand the threat. >>> >>> If someone asks me about this warning, I want to be able to explain the >>> reason in detail. At this point, what I can say is, "Peter said this on the >>> list." That is, to me, insufficient backing. >>> >>> >>> > Wouldn't "true" and "false" be a better way to express a >>> > boolean? >>> >>> Yes if you could choose the type. But you can't choose the type, because >>> all extensions have to use the same type. That type is a string. >>> >>> >>> > I realise this is kinda bikeshedding, but having to look >>> > up the spec just to figure out what mysterious magic >>> > values in a boolean field specify seems a bit awkward. >>> >>> Booleans are equally mysterious. >>> >>> The third parameter to the Windows API function WaitForMultipleObjects >>> is a boolean. Suppose an application passes "TRUE". Without checking the >>> docs - what does that mean? >>> >>> If you check the docs, you know what "TRUE" in that context means. And >>> if you check the spec here, you know what "p" and "s" mean. >>> >>> Booleans are not inherently self-documenting. (In fact - when used in >>> languages with positional parameters, they are more frequently >>> self-obfuscating.) >>> >>> >>> > Given that there are a nonzero number of implementations >>> > that send a window size of ~0 to indicate no flow control, >>> > it may be useful to add an implementation note to point >>> > this out. >>> >>> OK. I added the following sub-section to my current working copy: >>> >>> >>> 3.3.1. Implementation Note: Prior "No Flow Control" Practice >>> >>> Before this extension, some applications would simply not implement >>> SSH flow control, sending an initial channel window size of 2^32 - 1. >>> Applications SHOULD NOT do this for the following reasons: >>> >>> - It is entirely within the realm of possibility to transfer more than >>> 2^32 bytes over a channel. The channel will then hang if the other >>> party implements SSH flow control according to [RFC4254]. >>> >>> - There exist implementations which cannot handle such large channel >>> window sizes, and will exhibit non-graceful behaviors, including >>> disconnection. >>> >>> >>> denis >>> >>> >>> >>> On Thu, Apr 6, 2017 at 6:04 AM, Peter Gutmann >> > wrote: >>> >>>> denis bider (Bitvise) writes: >>>> >>>> >Can you point out some of these subtle problems that could occur in >>>> this >>>> >regard in SSH? >>>> >>>> I was thinking of the problem that it's essentially impossible to >>>> safely do n- >>>> RTT, n < 1, for TLS, which meant that doing the same thing for SSH >>>> wasn't >>>> going to be any better. I was reasoning by analogy from TLS rather than >>>> sitting down and drawing diagrams for SSH to try and figure out all the >>>> possible issues. >>>> >>>> >Under the assumption that such an extension were defined, can you >>>> point out >>>> >at least one way that sending this info right after NEWKEYS can help an >>>> >attacker? >>>> >>>> It depends on the extension. Without one defined, there's no way to >>>> tell at >>>> the moment. I could invent something that works out badly, but that'd >>>> be >>>> creating a strawman... my concern is that in the future someone may >>>> define a >>>> problematic extension without realising that they're creating a problem. >>>> Perhaps adding an implementation note to say that at this point the >>>> crypto >>>> hasn't been confirmed yet and so you may want to be careful about what >>>> you put >>>> into your extension data would be useful? >>>> >>>> >But the extension value field is generically a string (it must be same >>>> type >>>> >for all extensions, so unsupported extensions can be decoded and >>>> ignored). >>>> >"p" and "s" are therefore fitting ways to express this boolean. >>>> >>>> Wouldn't "true" and "false" be a better way to express a boolean? I >>>> realise >>>> this is kinda bikeshedding, but having to look up the spec just to >>>> figure out >>>> what mysterious magic values in a boolean field specify seems a bit >>>> awkward. >>>> >>>> >Properly implemented flow control is superior. However, this extension >>>> is a >>>> >nod to that not everyone will be using an SSH library that does this >>>> right, >>>> >and "no-flow-control" is a better option if your needs are simple, and >>>> you >>>> >don't have a few years to get this right. >>>> >>>> Given that there are a nonzero number of implementations that send a >>>> window >>>> size of ~0 to indicate no flow control, it may be useful to add an >>>> implementation note to point this out. I enabled some diagnostic code >>>> to >>>> throw an exception in my code if it found this from another >>>> implementation >>>> (other than mine) and got, uh, feedback from beta-testers about it, so >>>> at >>>> least some implementations are using a pseudo-infinite window size to >>>> indicate >>>> no flow control. I'm not saying it should be adopted as an alternative >>>> to >>>> "no-flow-control", but merely to alert implementers about the practice, >>>> e.g. a >>>> certain big iron vendor whose device would crash and reboot as it tried >>>> to >>>> allocate ~0 bytes of memory to match the widow size. >>>> >>>> Peter. >>>> _______________________________________________ >>>> 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 >>> >>> >> > --001a114e81dc8d7ef0054ca8e516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Apr 8, 2017 at 3:40 AM, denis bider <denisbider.ietf@g= mail.com> wrote:
Thank you for providing this link, Eric.

What t= his TLS section terms Zero-RTT, and what Peter appears to imply is 0RTT, se= em to be completely different things.

In TLS, &quo= t;0RTT" data appears to be data that are sent upfront in the client= 9;s first packet to the server, encrypted using a pre-shared key before the= handshake has derived a traffic secret.

<= /div>
That's more-or-less correct. You don't actually use the P= SK but derive a separate key from the PSK. The security challenges mostly d= erive from the fact that the
server doesn't have an opportuni= ty to provide a nonce.




In SSH, t= here is no such concept at all. This would be equivalent to sending data en= crypted with some type of pre-shared key as part of the client's KEXINI= T, which is not what is happening here.

The EXT_IN= FO packet sent by the client after NEWKEYS is not Zero-RTT. It is data sent= after a full and completed key exchange.

=
I'm not familiar enough with SSH to have an opinion here.

-Ekr




On Fri, Apr 7, 2017 at 9:21 AM, Eric Rescorla &l= t;ekr@rtfm.com> wrote:


On Thu, Apr 6, 2017= at 10:32 PM, denis bider <denisbider.ietf@gmail.com> wrote:
= > I was thinking of the problem that it's essentially
> impossible to safely do n-RTT, n < 1, for TLS, which
> meant= that doing the same thing for SSH wasn't going
> to be an= y better.=C2=A0 I was reasoning by analogy from TLS
> rather t= han sitting down and drawing diagrams for SSH
> to try and fig= ure out all the possible issues.

OK, but I&= #39;m not familiar with the security implications of this on TLS.

Can you link to any resources where this was discussed? Whe= ther for TLS, or in any other context?

Here is the section of TLS 1.3 that describes the security i= mplications of
0-RTT data:


=
FWIW, it's less clear to me that these apply to SSH because at lea= st the
replay issues stem from the desire to have loosely coupled= distributed
servers and seamless fall back from server state or = synchronization failure.

-Ekr



> Perhaps= adding an implementation note to say that at this
> point the= crypto hasn't been confirmed yet and so you may
> want to= be careful about what you put into your extension
> data woul= d be useful?

=C2=A0I agree, if this is a th= reat, we should add a warning in Security Considerations. But to make that = warning, I have to understand the threat.

If someo= ne asks me about this warning, I want to be able to explain the reason in d= etail. At this point, what I can say is, "Peter said this on the list.= " That is, to me, insufficient backing.


> Wouldn't "true" and "false" be a better way t= o express a
> boolean?

Yes if = you could choose the type. But you can't choose the type, because all e= xtensions have to use the same type. That type is a string.


> I realise this is kinda bikeshedding, but having to lo= ok
> up the spec just to figure out what mysterious magic
> values in a boolean field specify seems a bit awkward.

Booleans are equally mysterious.

The third parameter to the Windows API function WaitForMultipleObject= s is a boolean. Suppose an application passes "TRUE". Without che= cking the docs - what does that mean?

If you check= the docs, you know what "TRUE" in that context means. And if you= check the spec here, you know what "p" and "s" mean.

Booleans are not inherently self-documenting. (In f= act - when used in languages with positional parameters, they are more freq= uently self-obfuscating.)


> Given that th= ere are a nonzero number of implementations
> that send a wind= ow size of ~0 to indicate no flow control,
> it may be useful = to add an implementation note to point
> this out.=C2=A0
=

OK. I added the following sub-section to my curr= ent working copy:


3.3.1.=C2=A0 Impl= ementation Note: Prior "No Flow Control" Practice

<= /div>
=C2=A0 Before this extension, some applications would simply not = implement
=C2=A0 SSH flow control, sending an initial channel win= dow size of 2^32 - 1.
=C2=A0 Applications SHOULD NOT do this for = the following reasons:
=C2=A0=C2=A0
=C2=A0 - It is enti= rely within the realm of possibility to transfer more than
=C2=A0= =C2=A0 2^32 bytes over a channel. The channel will then hang if the other<= /div>
=C2=A0 =C2=A0 party implements SSH flow control according to [RFC= 4254].
=C2=A0 =C2=A0=C2=A0
=C2=A0 - There exist impleme= ntations which cannot handle such large channel
=C2=A0 =C2=A0 win= dow sizes, and will exhibit non-graceful behaviors, including
=C2= =A0 =C2=A0 disconnection.

denis



On Thu, Apr 6, 2017 at 6:04 AM,= Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bider (Bitvise) &l= t;ietf-ssh3@d= enisbider.com> writes:

>Can you point out some of these subtle problems that could occur in thi= s
>regard in SSH?

I was thinking of the problem that it's essentially impossible to safel= y do n-
RTT, n < 1, for TLS, which meant that doing the same thing for SSH wasn&= #39;t
going to be any better.=C2=A0 I was reasoning by analogy from TLS rather th= an
sitting down and drawing diagrams for SSH to try and figure out all the
possible issues.

>Under the assumption that such an extension were defined, can you point= out
>at least one way that sending this info right after NEWKEYS can help an=
>attacker?

It depends on the extension.=C2=A0 Without one defined, there's no way = to tell at
the moment.=C2=A0 I could invent something that works out badly, but that&#= 39;d be
creating a strawman... my concern is that in the future someone may define = a
problematic extension without realising that they're creating a problem= .
Perhaps adding an implementation note to say that at this point the crypto<= br> hasn't been confirmed yet and so you may want to be careful about what = you put
into your extension data would be useful?

>But the extension value field is generically a string (it must be same = type
>for all extensions, so unsupported extensions can be decoded and ignore= d).
>"p" and "s" are therefore fitting ways to express t= his boolean.

Wouldn't "true" and "false" be a better way to expr= ess a boolean?=C2=A0 I realise
this is kinda bikeshedding, but having to look up the spec just to figure o= ut
what mysterious magic values in a boolean field specify seems a bit awkward= .

>Properly implemented flow control is superior. However, this extension = is a
>nod to that not everyone will be using an SSH library that does this ri= ght,
>and "no-flow-control" is a better option if your needs are si= mple, and you
>don't have a few years to get this right.

Given that there are a nonzero number of implementations that send a window=
size of ~0 to indicate no flow control, it may be useful to add an
implementation note to point this out.=C2=A0 I enabled some diagnostic code= to
throw an exception in my code if it found this from another implementation<= br> (other than mine) and got, uh, feedback from beta-testers about it, so at least some implementations are using a pseudo-infinite window size to indic= ate
no flow control.=C2=A0 I'm not saying it should be adopted as an altern= ative to
"no-flow-control", but merely to alert implementers about the pra= ctice, e.g. a
certain big iron vendor whose device would crash and reboot as it tried to<= br> allocate ~0 bytes of memory to match the widow size.

Peter.
_______________________________________________
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



--001a114e81dc8d7ef0054ca8e516-- From nobody Sat Apr 8 23:54: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 4856D129435; Sat, 8 Apr 2017 23:54:18 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149172085823.3205.5784302008166330632@ietfa.amsl.com> Date: Sat, 08 Apr 2017 23:54:18 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-05.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: Sun, 09 Apr 2017 06:54:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-05.txt Pages : 8 Date : 2017-04-08 Abstract: This memo updates [RFC4252] and [RFC4253] to define an algorithm name, public key format, and signature format 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-05 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 Sat Apr 8 23:56:42 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 806C8127071; Sat, 8 Apr 2017 23:56:40 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149172100049.3063.16223425853169462130@ietfa.amsl.com> Date: Sat, 08 Apr 2017 23:56:40 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-04.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: Sun, 09 Apr 2017 06:56:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-04.txt Pages : 10 Date : 2017-04-08 Abstract: This memo updates [RFC4252], [RFC4253], and [RFC4254] 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 9 00:05: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 18A2D127ABE for ; Sun, 9 Apr 2017 00:05:22 -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 G_zdXMW_5xnI for ; Sun, 9 Apr 2017 00:05:20 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 BE501127071 for ; Sun, 9 Apr 2017 00:05:19 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p68so63862587qke.1 for ; Sun, 09 Apr 2017 00:05:19 -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=AKpiYNTUE7Jqx/IWye3pM6ORaFBw0myRRccYEjnilzo=; b=I+YQW9IgvpJ/7NSCRL/sXSt3rzRCemy2qOeknyJavFNd80o84yuhxQno8kgTQW+XRY tkCnnM+l8yvwR3mXg8p0Tu6tbmBVAK3njTdiAEtPMP7AZ+BGXxiSusH7nKJ1GBnTsUM9 M/K0/PHkhTuOFxyPekg9QPrUb2yQzIVZoxUbRXC25ovLmLLjW/7vMNDjEYLPbTtHtvrq wJQHjiYY+S4wSqtPSFPxGoIRU5LwgT8rsSag6uf63utwnjgz5uPXbrLyrXOS2TQEMeGi R/H+dZ+w5L1rpyLp4AVyHkqDuj61ASiCzad5VIeATQC/UqkIoLChLAxJr8zjVgRzhdr6 GQ2g== 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=AKpiYNTUE7Jqx/IWye3pM6ORaFBw0myRRccYEjnilzo=; b=Dq7bZJC0xnZ7ODV+l1T5tys85ZUyDuqnRuDqpv1M1ejAclx2Z07dacVQSwaQXZqBP6 vvZ5wGsBDNuQRknhXe7XTa9g7aocSPMIoSn+VyKfWwqWWMpudeVO98fbGIfmfXoCt13u Xzb5F2FHCUvxV3B56qE7U/G3/LRyyGBw6xQK/t7xuafcv7HXjF7rdApGBrDtf+tNnfp0 uNzDGDwyNGCVPBq+AzLMCnhoEMdSpOolrB1ESYkvxee8Yhvln5Kcp/mqEl2N4/EDpRBm lGDd2nnrlGakn1YN91yH5UjtkgvIwoqedAS10I9WEPF77VYH3EWKFSXwvpLPMRA1jw7I /WcA== X-Gm-Message-State: AFeK/H2YtpxHeOKWcRxn/iAho98ZDQVBc4gCvawsrfaCLjhCW+moc0HHU7mfFtvIVQnATu1UOR1wbPjuySY39w== X-Received: by 10.55.144.6 with SMTP id s6mr43337471qkd.27.1491721518962; Sun, 09 Apr 2017 00:05:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Sun, 9 Apr 2017 00:05:18 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: denis bider Date: Sun, 9 Apr 2017 01:05:18 -0600 Message-ID: To: Daniel Migault Cc: "curdle@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0859683dde15054cb67b81 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 09 Apr 2017 07:05:22 -0000 --94eb2c0859683dde15054cb67b81 Content-Type: text/plain; charset=UTF-8 I have: - Applied these nits to the rsa-sha2 document, and submitted a new version. - Applied a few nits that appeared to be relevant also to the ext-info document, and submitted a new version. With regard to this: > -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' I have not made changes because a normative reference is appropriate here for SHA-2, and there does not appear to be an RFC that could serve as an alternative reference. Other past RFCs that address the use of SHA-2 also use the FIPS standard as a normative reference. denis On Fri, Apr 7, 2017 at 1:49 PM, Daniel Migault wrote: > In addition, I have also been requested by the IESG to add as an > informative reference the link of the IANA page. In our case the link is > the following one: > https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh- > parameters-19 > > Yours, > Daniel > > On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> In the chicago meeting [1], the consensus seems that even though pss >> would be defined, there is no plane to implement nor to use it. I am >> confirming this consensus on the mailing list. If you desagree with that, >> please raise your opinion. If not we will move the draft forward. >> >> The nits tool on the current version provides teh following output: >> >> [1] https://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00.txt >> >> >> Checking nits according to http://www.ietf.org/id-info/checklist : >> ---------------------------------------------------------------------------- >> >> -- The draft header indicates that this document updates RFC4252, but the >> abstract doesn't seem to mention this, which it should. >> >> -- The draft header indicates that this document updates RFC4253, but the >> abstract doesn't seem to mention this, which it should. >> >> -- The document seems to lack a disclaimer for pre-RFC5378 work, but may >> have content which was first submitted before 10 November 2008. If you >> have contacted all the original authors and they are all willing to grant >> the BCP78 rights to the IETF Trust, then this is fine, and you can ignore >> this comment. If not, you may need to add the pre-RFC5378 disclaimer. >> (See the Legal Provisions document at >> http://trustee.ietf.org/license-info for more information.) >> >> >> Checking references for intended status: Proposed Standard >> ---------------------------------------------------------------------------- >> >> (See RFCs 3967 and 4897 for information about using normative references >> to lower-maturity documents in RFCs) >> >> == Missing Reference: 'RFC3629' is mentioned on line 100, but not defined >> >> == Unused Reference: 'RFC4250' is defined on line 298, but no explicit >> reference was found in the text >> >> -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' >> >> ** Obsolete normative reference: RFC 3447 >> >> yours, >> >> Daniel >> >> >> On Mon, Mar 27, 2017 at 4:51 PM, denis bider >> wrote: >> >>> That is a welcome assurance. If PSS is added, it sounds like something >>> to mention in Security Considerations as a further argument against small >>> keys. >>> >>> On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara < >>> ilariliusvaara@welho.com> wrote: >>> >>>> On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote: >>>> > Whether pss variant have to be added is up to the WG to decide. That I >>>> > would be in favor is only one opinion ;-) [1] lists some advantages >>>> of PSS >>>> > vs PKCS1v1.5. Note that enabling a given key may be used by two >>>> variants >>>> > needs also some thoughts. I will raise the question during the >>>> meeting, but >>>> > discussion will be made on the mailing list. >>>> >>>> This thing came up in context of TLS 1.3. >>>> >>>> The probability PKCS#1v1.5 and PSS signature overlaps depends on key >>>> size and salt size. Where overlap is defined as encoded message that >>>> is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm >>>> and number of bits in n, but not precise value of n. >>>> >>>> TLS restricts salt length to be the same as hash length. Which makes >>>> overlaps highly unlikely with key sizes >=2048 bits and hash sizes >>>> <=512 bits. The problem being to control ~1000 bits using 512 bits. >>>> >>>> As key size decreases or salt size increases, the overlap probability >>>> increases, and eventually overlaps become almost certain, and further >>>> one gets multiple overlaps. >>>> >>>> > >>>> > [1] >>>> > https://www.emc.com/emc-plus/rsa-labs/historical/raising-sta >>>> ndard-rsa-signatures-rsa-pss.htm >>>> >>>> >>>> -Ilari >>>> >>> >>> >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>> >>> >> > --94eb2c0859683dde15054cb67b81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have:

- Applied these nits= to the rsa-sha2 document, and submitted a new version.

- Applied a few nits that appeared to be relevant also to the ext-inf= o document, and submitted a new version.

With rega= rd to this:

>=C2=A0-- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS= -180-4'

I have not made changes because= a normative reference is appropriate here for SHA-2, and there does not ap= pear to be an RFC that could serve as an alternative reference. Other past = RFCs that address the use of SHA-2 also use the FIPS standard as a normativ= e reference.

denis


On Fri, Apr 7, 2017 at 1:49 PM, Daniel = Migault <daniel.migault@ericsson.com> wrote:
= In addition, I have also been requested by the IESG to add as an informativ= e reference the link of the IANA page. In our case the link is the followin= g one:
https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters= -19

Yours,
Daniel

On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migault <da= niel.migault@ericsson.com> wrote:
Hi,

In the chicago meeti= ng [1], the consensus seems that even though pss would be defined, there is= no plane to implement nor to use it. I am confirming this consensus on the= mailing list. If you desagree with that, please raise your opinion. If not= we will move the draft forward. =C2=A0

The nits tool on the curren= t version provides teh following output:

[1] https://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00= .txt

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ---------------------------------------------------------------=
-------------

  -- The draft header indicates that this document updates RFC4252, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC4253, but the
     abstract doesn't seem to mention this, which it should.


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but =
may
     have content which was first submitted before 10 November 2008.  If yo=
u
     have contacted all the original authors and they are all willing to gr=
ant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ign=
ore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.=
=20
     (See the Legal Provisions document at
     htt=
p://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ---------------------------------------------------------------=
-------------

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  =3D=3D Missing Reference: 'RFC3629' is mentioned on line 100, but=
 not defined

  =3D=3D Unused Reference: 'RFC4250' is defined on line 298, but no=
 explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-=
4'

  ** Obsolete normative reference: RFC 3447

yours, 
Daniel

=
On Mon, Mar 27, 2017 at 4:51 = PM, denis bider <denisbider.ietf@gmail.com> wrote:
That is a welcome = assurance. If PSS is added, it sounds like something to mention in Security= Considerations as a further argument against small keys.

On Mon, Mar 27, 2017 at 1:24 AM, Ilari = Liusvaara <ilariliusvaara@welho.com> wrote:
On Sun, Mar 26, 2017 at 1= 0:50:02PM -0500, Daniel Migault wrote:
> Whether pss variant have to be added is up to the WG to decide. That I=
> would be in favor is only one opinion ;-) [1] lists some advantages of= PSS
> vs PKCS1v1.5. Note that enabling a given key may be used by two varian= ts
> needs also some thoughts. I will raise the question during the meeting= , but
> discussion will be made on the mailing list.

This thing came up in context of TLS 1.3.

The probability PKCS#1v1.5 and PSS signature overlaps depends on key
size and salt size. Where overlap is defined as encoded message that
is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
and number of bits in n, but not precise value of n.

TLS restricts salt length to be the same as hash length. Which makes
overlaps highly unlikely with key sizes >=3D2048 bits and hash sizes
<=3D512 bits. The problem being to control ~1000 bits using 512 bits.
As key size decreases or salt size increases, the overlap probability
increases, and eventually overlaps become almost certain, and further
one gets multiple overlaps.

>
> [1]
> htt= ps://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rs= a-signatures-rsa-pss.htm


-Ilari


____________________________________= ___________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle



--94eb2c0859683dde15054cb67b81-- From nobody Sun Apr 9 10:56:35 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 D8D42126D05 for ; Sun, 9 Apr 2017 10:56:33 -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 GBZu_akOOBoM for ; Sun, 9 Apr 2017 10:56:31 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971891243F6 for ; Sun, 9 Apr 2017 10:56:30 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id 75so1211298lfs.2 for ; Sun, 09 Apr 2017 10:56:30 -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=X4Trpx1JLFlPAdQmVYBYZwaZo+wdGXjSAXFt2MW8gzc=; b=CIYHveCTlCbELkeqisgO3Ttm0dy7lnrqDiocRpfJRvinUufYAuInqRs6RkO/DZpErf F/Y6Aky7h7Vj5DSmkC8zhkHUZ2IGTDUA8cwA11Jh8Kl56yr6cBibG/klMiaCh/nKhwL3 rAztSgV0BJH7gj1aNNGP+lzFEzd3XUqIsbm+V/Rdm+12wKi3yjws2m2ylxKyqKDFlF/l LY1Vs9Slt8EsBBOCX7s5PfnKNh37O5N1sxraoGsdznHNY5a34ixdNSR8rJnNfiWCg/X5 xKt1VZ/n082wjLYiWnQZcjXL+QjhrxbTBPxHooj/W42BzitrU5D8LmJbVDtNXDXL/Fw+ JWkA== 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=X4Trpx1JLFlPAdQmVYBYZwaZo+wdGXjSAXFt2MW8gzc=; b=Cf0xxmgVmby5De+hzQWkjk7/TUQeJpehGKb45m+2l8AY/DChKg/LRbQ6qn20aY0fgj leaMbxzPzlviUR7ED9xM88nsVpsnPb8S6Mz3VIi9BugY7GYmhArSSLQCzwtvaa9YpZ/v ZR6bjl9iPbWiCvniBYV2+/15Cqo2CixINDTtiPsl8NTxLtbvDNvlNaWi7svcdUyeeRMW LHjlSJbf24ZllA4iME4iEtF6RHD4LfgSY6i4aD8ZB2Kvp1Y+XoKs350+jrwaxXDbhryd B4od9IgxZAylENUzApH6Z49ryCM+sv9pGTcZSLz3WyPGzvkh3GSnlZkhIQdqMQ//GCeM s32w== X-Gm-Message-State: AN3rC/6ahFSEnnnbD3n7Cx4duqMJNm4t97B0PCU3fSDl6Wyacwk6uoac94MWbkNigmtLMa/EMHmyUDXkIHeVwQ== X-Received: by 10.25.219.91 with SMTP id s88mr660782lfg.174.1491760588816; Sun, 09 Apr 2017 10:56:28 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Sun, 9 Apr 2017 10:56:28 -0700 (PDT) In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Sun, 9 Apr 2017 13:56:28 -0400 X-Google-Sender-Auth: PYwtnrnHIYQliCJ1uFhwrnhR9BU Message-ID: To: denis bider Cc: "curdle@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05edfafc886d054cbf93be Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 09 Apr 2017 17:56:34 -0000 --94eb2c05edfafc886d054cbf93be Content-Type: text/plain; charset=UTF-8 Hi, Thanks. It looks to me we are ready to go with this version. Yours, Daniel On Sun, Apr 9, 2017 at 3:05 AM, denis bider wrote: > I have: > > - Applied these nits to the rsa-sha2 document, and submitted a new version. > > - Applied a few nits that appeared to be relevant also to the ext-info > document, and submitted a new version. > > With regard to this: > > > -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' > > I have not made changes because a normative reference is appropriate here > for SHA-2, and there does not appear to be an RFC that could serve as an > alternative reference. Other past RFCs that address the use of SHA-2 also > use the FIPS standard as a normative reference. > > denis > > > On Fri, Apr 7, 2017 at 1:49 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> In addition, I have also been requested by the IESG to add as an >> informative reference the link of the IANA page. In our case the link is >> the following one: >> https://www.iana.org/assignments/ssh-parameters/ssh- >> parameters.xhtml#ssh-parameters-19 >> >> Yours, >> Daniel >> >> On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migault < >> daniel.migault@ericsson.com> wrote: >> >>> Hi, >>> >>> In the chicago meeting [1], the consensus seems that even though pss >>> would be defined, there is no plane to implement nor to use it. I am >>> confirming this consensus on the mailing list. If you desagree with that, >>> please raise your opinion. If not we will move the draft forward. >>> >>> The nits tool on the current version provides teh following output: >>> >>> [1] https://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00.txt >>> >>> >>> Checking nits according to http://www.ietf.org/id-info/checklist : >>> ---------------------------------------------------------------------------- >>> >>> -- The draft header indicates that this document updates RFC4252, but the >>> abstract doesn't seem to mention this, which it should. >>> >>> -- The draft header indicates that this document updates RFC4253, but the >>> abstract doesn't seem to mention this, which it should. >>> >>> -- The document seems to lack a disclaimer for pre-RFC5378 work, but may >>> have content which was first submitted before 10 November 2008. If you >>> have contacted all the original authors and they are all willing to grant >>> the BCP78 rights to the IETF Trust, then this is fine, and you can ignore >>> this comment. If not, you may need to add the pre-RFC5378 disclaimer. >>> (See the Legal Provisions document at >>> http://trustee.ietf.org/license-info for more information.) >>> >>> >>> Checking references for intended status: Proposed Standard >>> ---------------------------------------------------------------------------- >>> >>> (See RFCs 3967 and 4897 for information about using normative references >>> to lower-maturity documents in RFCs) >>> >>> == Missing Reference: 'RFC3629' is mentioned on line 100, but not defined >>> >>> == Unused Reference: 'RFC4250' is defined on line 298, but no explicit >>> reference was found in the text >>> >>> -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4' >>> >>> ** Obsolete normative reference: RFC 3447 >>> >>> yours, >>> >>> Daniel >>> >>> >>> On Mon, Mar 27, 2017 at 4:51 PM, denis bider >>> wrote: >>> >>>> That is a welcome assurance. If PSS is added, it sounds like something >>>> to mention in Security Considerations as a further argument against small >>>> keys. >>>> >>>> On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara < >>>> ilariliusvaara@welho.com> wrote: >>>> >>>>> On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote: >>>>> > Whether pss variant have to be added is up to the WG to decide. That >>>>> I >>>>> > would be in favor is only one opinion ;-) [1] lists some advantages >>>>> of PSS >>>>> > vs PKCS1v1.5. Note that enabling a given key may be used by two >>>>> variants >>>>> > needs also some thoughts. I will raise the question during the >>>>> meeting, but >>>>> > discussion will be made on the mailing list. >>>>> >>>>> This thing came up in context of TLS 1.3. >>>>> >>>>> The probability PKCS#1v1.5 and PSS signature overlaps depends on key >>>>> size and salt size. Where overlap is defined as encoded message that >>>>> is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm >>>>> and number of bits in n, but not precise value of n. >>>>> >>>>> TLS restricts salt length to be the same as hash length. Which makes >>>>> overlaps highly unlikely with key sizes >=2048 bits and hash sizes >>>>> <=512 bits. The problem being to control ~1000 bits using 512 bits. >>>>> >>>>> As key size decreases or salt size increases, the overlap probability >>>>> increases, and eventually overlaps become almost certain, and further >>>>> one gets multiple overlaps. >>>>> >>>>> > >>>>> > [1] >>>>> > https://www.emc.com/emc-plus/rsa-labs/historical/raising-sta >>>>> ndard-rsa-signatures-rsa-pss.htm >>>>> >>>>> >>>>> -Ilari >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > --94eb2c05edfafc886d054cbf93be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thanks. It looks to me we= are ready to go with this version.

Yours,
Daniel

On Sun, Ap= r 9, 2017 at 3:05 AM, denis bider <denisbider.ietf@gmail.com&g= t; wrote:
I = have:

- Applied these nits to the rsa-sha2 documen= t, and submitted a new version.

- Applied a few ni= ts that appeared to be relevant also to the ext-info document, and submitte= d a new version.

With regard to this:

>=C2=A0= -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4&= #39;

I have not made changes because= a normative reference is appropriate here for SHA-2, and there does not ap= pear to be an RFC that could serve as an alternative reference. Other past = RFCs that address the use of SHA-2 also use the FIPS standard as a normativ= e reference.

<= /div>
denis


On Fri, Apr 7, 2017 at 1:49 PM= , Daniel Migault <daniel.migault@ericsson.com> wro= te:
<= div>
In addition, I have also been requested by the IESG to add as an i= nformative reference the link of the IANA page. In our case the link is the= following one:
https://www.ia= na.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parame= ters-19

Yours,
Daniel

On Fri, = Apr 7, 2017 at 2:43 PM, Daniel Migault <daniel.migault@ericsson.= com> wrote:
Hi,

In the chicago meeting [1], the consensus = seems that even though pss would be defined, there is no plane to implement= nor to use it. I am confirming this consensus on the mailing list. If you = desagree with that, please raise your opinion. If not we will move the draf= t forward. =C2=A0

The nits tool on the current version provides teh= following output:

[1] https://www.ietf.org/= proceedings/98/minutes/minutes-98-curdle-00.txt

 =
 Checking nits according to http://www.ietf.org/id-info/checklist :
  ---------------------------------------------------------------=
-------------

  -- The draft header indicates that this document updates RFC4252, but the
     abstract doesn't seem to mention this, which it should.

  -- The draft header indicates that this document updates RFC4253, but the
     abstract doesn't seem to mention this, which it should.


  -- The document seems to lack a disclaimer for pre-RFC5378 work, but =
may
     have content which was first submitted before 10 November 2008.  If yo=
u
     have contacted all the original authors and they are all willing to gr=
ant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ign=
ore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer.=
=20
     (See the Legal Provisions document at
     htt=
p://trustee.ietf.org/license-info for more information.)


  Checking references for intended status: Proposed Standard
  ---------------------------------------------------------------=
-------------

     (See RFCs 3967 and 4897 for information about using normative referenc=
es
     to lower-maturity documents in RFCs)

  =3D=3D Missing Reference: 'RFC3629' is mentioned on line 100, but=
 not defined

  =3D=3D Unused Reference: 'RFC4250' is defined on line 298, but no=
 explicit
     reference was found in the text

  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-=
4'

  ** Obsolete normative reference: RFC 3447

yours, 
Daniel

=
On Mon, = Mar 27, 2017 at 4:51 PM, denis bider <denisbider.ietf@gmail.com> wrote:

On Mon, Mar 27, 2017 at 1:24 AM= , Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Sun, Mar 26, 2= 017 at 10:50:02PM -0500, Daniel Migault wrote:
> Whether pss variant have to be added is up to the WG to decide. That I=
> would be in favor is only one opinion ;-) [1] lists some advantages of= PSS
> vs PKCS1v1.5. Note that enabling a given key may be used by two varian= ts
> needs also some thoughts. I will raise the question during the meeting= , but
> discussion will be made on the mailing list.

This thing came up in context of TLS 1.3.

The probability PKCS#1v1.5 and PSS signature overlaps depends on key
size and salt size. Where overlap is defined as encoded message that
is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
and number of bits in n, but not precise value of n.

TLS restricts salt length to be the same as hash length. Which makes
overlaps highly unlikely with key sizes >=3D2048 bits and hash sizes
<=3D512 bits. The problem being to control ~1000 bits using 512 bits.
As key size decreases or salt size increases, the overlap probability
increases, and eventually overlaps become almost certain, and further
one gets multiple overlaps.

>
> [1]
> htt= ps://www.emc.com/emc-plus/rsa-labs/historical/raising-standard-rs= a-signatures-rsa-pss.htm


-Ilari


____________________________________= ___________
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

--94eb2c05edfafc886d054cbf93be-- From nobody Sun Apr 9 11:19:20 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 192B51243F6 for ; Sun, 9 Apr 2017 11:19:19 -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 nYaJJj_Sh7Et for ; Sun, 9 Apr 2017 11:19:17 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2752A127599 for ; Sun, 9 Apr 2017 11:19:16 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id s141so25429360lfe.3 for ; Sun, 09 Apr 2017 11:19:16 -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=8V00CXQ0d2J8HO8tS9wJ3pCcotS3ISkcn+RkY6bPfQE=; b=CMGs6+g0ni5yeECdGBUjD1o+xVFBndVA16aWa3SOl7haCp2AzisSM03CkMYX0TNMeb 0a97HrbVLO0/WMhYGeEjGRBH6gL7XcTtT2zkn7wkI1Qnp0NQS4vOCVkGmPZ+AAYdX6gZ FaIy+rtloTKOfGUyMKLtKk/AO8uBonLZgUyeZpEg0Pe5uW7dd2zrLIUgFhbzf/AHMxdf 5Wn36uk92ETglU7YUdQGQQXzSg22OL9u7lSuqDAkW3dvIYAQsKnbMxj25PnEmKhm5bMH C2de9FgQ/bOA94i/ruz3QDlxEURU11hZqsh0K3qAIOQvbZ4OA9Yx7g8B8wUq+Zy+jrfY IdsQ== 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=8V00CXQ0d2J8HO8tS9wJ3pCcotS3ISkcn+RkY6bPfQE=; b=iFZ01YNVnIJ4xZzqHVfiInQubyz9jpK74Bh3tARdhNVzZHN4zo6C8N37/uODoswqy4 HwUoyjYdObcYGpkQEJMy8cpVJ6j+iT76j+ThjqZqjFQI8UTgcmvW5R1epiUPi/xoRjsb 3EXI06iJS5lan5ZOgqJn42doqpxfs6kInr10Sprst8NIyZ0CeMsRoZGTE9BtOHpPrGTh xQTbtketyh0V1/ORIakOlMufbdv1QVJe9YGLprC2r5OC+kLC7pOUYZlIEXLjClybqRb3 QlxmOea1OFBC9XBK6HvPNmEJyOvvuWFFRba8FcLDYu5vdc2+4zeWLqOBsAajws69P6NU xsXA== X-Gm-Message-State: AN3rC/7cjgNm0R4+GaaiBk8L4h3FLFlykwqKbLO4ps6vea/jpeIF4tt08spEBvmldRLouqb/W/zIOUG3W6WLBA== X-Received: by 10.25.213.12 with SMTP id m12mr2086255lfg.145.1491761955027; Sun, 09 Apr 2017 11:19:15 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Sun, 9 Apr 2017 11:19:14 -0700 (PDT) In-Reply-To: <149172100049.3063.16223425853169462130@ietfa.amsl.com> References: <149172100049.3063.16223425853169462130@ietfa.amsl.com> From: Daniel Migault Date: Sun, 9 Apr 2017 14:19:14 -0400 X-Google-Sender-Auth: j7uGEOZ2fRovnclQBYCrLztv7aw Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11412efc6b4335054cbfe502 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-04.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, 09 Apr 2017 18:19:19 -0000 --001a11412efc6b4335054cbfe502 Content-Type: text/plain; charset=UTF-8 Hi, This version seems to me ready. If you think it needs another iteration raise your concern by Wednesday April 12. Yours, Daniel On Sun, Apr 9, 2017 at 2:56 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 of the IETF. > > Title : Extension Negotiation in Secure Shell (SSH) > Author : Denis Bider > Filename : draft-ietf-curdle-ssh-ext-info-04.txt > Pages : 10 > Date : 2017-04-08 > > Abstract: > This memo updates [RFC4252], [RFC4253], and [RFC4254] 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-04 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-04 > > > 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 > --001a11412efc6b4335054cbfe502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This version seems to me ready. If y= ou think it needs another iteration raise your concern by Wednesday=C2=A0 A= pril 12.

Yours,
Daniel

On Sun, Apr 9, 2017 at 2:56 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the CURves, Deprecating and a Little more Encr= yption of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Extension Negotiation in Secure Shell (SSH)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Deni= s Bider
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-curdle-ssh-ext-info-04.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-04-08

Abstract:
=C2=A0 This memo updates [RFC4252], [RFC4253], and [RFC4254] to define a =C2=A0 mechanism for SSH clients and servers to exchange information about<= br> =C2=A0 supported protocol extensions confidentially after SSH key exchange.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-curdle-ssh-ext-info/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-= ietf-curdle-ssh-ext-info-04
https://datatracker.ietf.org/= doc/html/draft-ietf-curdle-ssh-ext-info-04

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


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

--001a11412efc6b4335054cbfe502-- From nobody Sun Apr 9 21:35: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 A8284126FB3 for ; Sun, 9 Apr 2017 21:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0BWJEi9pe5e for ; Sun, 9 Apr 2017 21:35:47 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0128.outbound.protection.outlook.com [104.47.33.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1030127775 for ; Sun, 9 Apr 2017 21:35:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qa9uW6K0Ci17I6QXLrKRrKxvASRfL0rAumJmYMbMKUg=; b=eWb5P/eVTn63FPIlG1lJTiIKxEyySmDxzcy0d886vjtCggf1MTpEPmzw+TIgwO1HfwCyNbGRDuTxLjQql1050LX9gG3KSC13DhGu+lCQ7LBDFerxQiUHcFV13cB55QdsqdvJuRhY3a/4gAeNqAzrdeuf4HBskD7EbrcZ0Pcwhfo= Received: from CO2PR05CA041.namprd05.prod.outlook.com (10.141.241.169) by CO1PR05MB539.namprd05.prod.outlook.com (10.141.73.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Mon, 10 Apr 2017 04:35:44 +0000 Received: from BY2NAM05FT043.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::202) by CO2PR05CA041.outlook.office365.com (2a01:111:e400:1429::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5 via Frontend Transport; Mon, 10 Apr 2017 04:35:45 +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 BY2NAM05FT043.mail.protection.outlook.com (10.152.100.180) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1005.5 via Frontend Transport; Mon, 10 Apr 2017 04:35:44 +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; Sun, 9 Apr 2017 21:35:33 -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 v3A4ZWdw015444; Sun, 9 Apr 2017 21:35:33 -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 02E4E11446; Sun, 9 Apr 2017 21:35:29 -0700 (PDT) To: Daniel Migault CC: curdle In-Reply-To: References: <149172100049.3063.16223425853169462130@ietfa.amsl.com> Comments: In-reply-to: Daniel Migault message dated "Sun, 09 Apr 2017 14:19:14 -0400." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU 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)(39450400003)(39860400002)(39400400002)(39850400002)(39410400002)(2980300002)(199003)(189002)(9170700003)(105596002)(53416004)(76506005)(2810700001)(7696004)(2906002)(189998001)(7126002)(5660300001)(6246003)(81166006)(8676002)(229853002)(8936002)(6916009)(2950100002)(86362001)(50226002)(5003940100001)(4326008)(6266002)(38730400002)(588024002)(230783001)(117636001)(47776003)(48376002)(50466002)(77096006)(6392003)(7846003)(50986999)(76176999)(356003)(106466001)(55016002)(305945005)(110136004)(558084003)(53936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB539; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT043; 1:Noy2CreHRe4GkvlPo93gNzUrWNddV4wmO+kaRKJZAve8CO3ipd5pj7972h/ZBtrHKTiftdKGMNAWpADmkB6BQkAvP/d8rmP8aoF8ISxPUoWxv9Wrm1trLu8Flr7hpCpk18FaMVO98gcB+HOw6tC+nt+Foe8IxwyBYMWB8szvtQg5aL+97xkIFHXaHnPFkX8xSOyV3SfT+6uiPrp5xFbSggYFp5fPFtmrLLle7rGIUAniOSzMCIQdnnSpi9bWWeqztXlttqnFwGF7sAOy5irUkBA84HVw0MNZfIianDw3B3EI1S0/ba+KFGLmEqyCJPZvW8wYBRZQ23FfJuHrANnGfhTrsxCkgY4AJ8MFDBxjcRusccXj7k8ywag1IKktJnNcNbhYfXKRcwRWfy3w6sN/aMUhaKO1U4+JNYiUxjeIEz+9On8XUr6/HZBVX8Xc1m6X6siVL7dEmDWfYcQmg2wxCZIiHVhHW5+34Hse6gofTiOLEEr1ar+y1dRyyVUhVz8rCe+j/pKD5JWF8TZbKOk6BNi1mjOxeRkdmU/XHZZ24rfsBP1JZbzXNvFVyVsQYTh74oFb/0GqzMMOjbxf5cLuIg== X-MS-Office365-Filtering-Correlation-Id: 7639971e-212f-4315-76c5-08d47fcb0d9e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 3:K2YgwtuLXpoQC1SGth+vJlxSNZFntebQKpQgpmo1q804B9vK5r9M3bfPfNgb9x+noSGFX5EkthfAzP0sP/sVuok8r8U6tvMC2HeWdVKSzuhtdHaMZnouA19eIOvOx2cg64Bzexg6dxO6bbCR1jpvdNkmX0nVae71Sa1su8fwwYvXSKcXsPqTKxk7ZidIr4I73h1bE3zVFKqxfO70GpWavSU50zRNhROmSZ6sYCbcCAAGwhccII9ZJm+x8FvpmQfyeOviOSX8r5OojoqLu7MmHhQRzYe2WAiPahKUj3LPPEDcXSOljDNgu4iL8sMUi79CFsZaY5AVFDC6JUZNuRkkz/n+yXkiGZQKm51Rg08Y5T6OgGJWWQTA6rD12WyiPyWTNC0gXKVDrv23jmt6LYY1ZXu8/YQwMTCEHyhbiuow+GmT5TvSEVh1XPYdGkp6Mainth7B1eSnSuGyfnqYDu2xJEgcH7hLglDd2jdOqzNDcRz6oA6y7thNO4xrlKAFwcaZ X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 25:ZtjElEnQkB3X1/WMIcNQjuLzBB+ujqdm3KDSgc8uiqdUyn5eHs9A4HeSseuHgt0KwDzyASSBaShlehP++lc86ub9nORrCXzWU6pEemSbjkz+SI6Em7BHcKFqrCD2YTynkJYn5loGls7Bp82l0dywPGP92GsLVrta2a8rM9EOHuR4iEagxcWpPeiEmFUf4vUSJy3paXlKzpkBQSWMPZY+MQLxA2Ze0y3G9Ra06SjhTc8m65N6fZ3IA46+KVf0G7EoLAhpyno+7qGG/GQ6AjqmfQJoSocO0rl2WjZVF7UvDmQg4Z1Z3636Rg3+5ENv31FOmAceQScEqABhG25Sj9vh8Usl1mNLCfdtLzGZVdQel8CevzsHFRR00/DV0WhEgz6ulw+PpzXSCWUMOcp+Ig/2lEZdEqriHSli7fkS6whO8CtRKQ/bh9SHHcSEJFEde8BgmC7vWKGfXWqwGpiot9TQPw==; 31:4JKyGQYe8X76vyeFmh+P3A9EJRIXL/b6S/JZcTW3VLvutolH04/yp5ldlx3Eix7XZuHvyBO1kvpVLO8484sfnMdsixLMUE0AIdBuhiYO2Ng7/QdSQ+G/+UtKyiC/EAr1yhmi3QXohocjy06zlvOUxJ87UrBwRHrNjjfpilgoqZIP4AtpAhv9BFaALUF9nMXtIKjyGRZpRY6Ic39Gy+FgdMk7s7IwcVCK9a4tkOvxJp5xMs92TErQDAnPHG+b/fcfi+jpLsfXSbJpoPOqGncMTw== X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 20:/8UxjlBtJ8FQaKumt1VX2l+fRAsG4qLqIS4Y4QezILtEvbnLqlX6/62cBDj1TSqkJZ9MGMPcyQmcffFmvbXfLXU3HozHy1oQZ4PTbrD5GzSJY6XP865/b5lEbe2Vpv3k3I8vH3kDpKYw+bwwkzUwHVQezPbY7qal6GHXtArCHETJ9YeXcR9AQYsKeRsfjkIYaDENeuUmf3K915YbaA2WgmsoQem7L4YL7787YIJrT4bqCzfozrPtOJ50yJIa8Lp9sobmGph2GLTlISRQUMXTILluKc7GJYM5gSHZYo/aX2drQTgJq+A7dHNtXoBGlc4FjLO33caUT9QhW5kctHP/z9aTCyRyhhPm3rV87QkhCgnExKoW0qzowFosYwPTk4vyWnspZOV5nNEprMfmc+nL3xBTnMdsS4uduH1oQATTHIEhh+4TChT3MjQHAvB7iuwllP44mDiHxsWU3YCw8ukcp91F1bVL8yecvqI243EKustkeJ51Rivp6zUkd6x5YJ9E X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13023025)(13024025)(8121501046)(13018025)(13015025)(13017025)(5005006)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CO1PR05MB539; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 4:9cqR2/0lrMUonI0uVccIxrHBhm0cHoW2/43DfBA6a1Zobt8Z+iPB2YIfpJLJBaoFnEQlDjF2ILQ2NNxQ5uL5S0ZXNB9n62W+jZZD6tcMgeGxdZ4sEX0vDj+L1WlvzCROAqOkM49yrfgabuu2CvlCpy0cso5pD9+CYmgF2AqnGYBIvL1U0GnngrqqxHNBXPnyZo7uW+7WOxwZc8C3KEW54JA5gogRqlxa1OmjjrQHFCYxotZFVF7TVzbIqljy1qPNrGLSsiIbUBPlwUwGJQibLdDHMjniWShFli0F5CTSAt7wSJCxbvmDpuqE2lIV8e9P8u99WCKK8tE6WBOWnfplShY7C6cqLI6aQYdoQBCY0LysHM5d0fhqv6S78sPOR2tXI95hJECski85Jl5ZiNEXq4kFFfmlhMrKpp3ugwRfVhVDhgOXE8zhe24/nUjFiImePplHzLeQAopMqe1kP8XBNpOkvps37uy4FJ8TTexw3VGRb5ope+M5m5w+2Ou9jUtxsJkBQzSWtlG4Bz3WkTFFiwqTqFLB7HMZ/bBX4BSkml5w0sWDc8bBqUHTmZ+0XDycirBJl0hv6jHRQMrATXH3uJt0+QAAV7FBXESDmu6J9Dd583UKGo8r6Tq7pvsHSMgzwJW/AJcv20aw6D/qVW7CWiegOxAGrMwEP8/IvVz/Pg/9ii7xDi0+glxW/vXwNVCUKeyDPoTDvYRCw0fx6TNnAdBOqCkKAwv+o0tqfoqSB42tcx1KsTMiphS+42l3k3uTaCOYha4BexkrqDWgsKwWtD5LMEwTDJDvzhkxsIt4pP8P2OhE3jSTbqeCEjPCylz/RKQP64HHF9X2iqCAZhI0eQ== X-Forefront-PRVS: 027367F73D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB539; 23:51KTdTzECHnzlOi3SkKU1ri6VA8C0ODr+eaIoOxxxF?= =?us-ascii?Q?fl+WgU9GdsfD4Fp//0vMgw6Tg/5OOVmliyBhZigBy9vV4Jh5dcY/aVEI/FC3?= =?us-ascii?Q?dre9/SICPNM4YuUC2+FHCCAhOrGaxfgZR9+g4mMpMwZqjIdZxvV8Qh4r6G7I?= =?us-ascii?Q?8SucKKQlm/64uw5leAuv0uOMza/qUPrnf1mS+xUV0/Fh00oMtUdqxF3NjNo8?= =?us-ascii?Q?JlesIKtsvlRF5l7FNCxJFZ1lvVA+OKrAyadSn39H9654Ax9vT9QkmzKTs0oj?= =?us-ascii?Q?+sI2woyOkUWAGATxoJuv/DejsouE5ce8xa53l8m7dI0Km7Sr89fc+2wKsDdM?= =?us-ascii?Q?lTLzMhEvdZfiherE25etfftgnhbGp0gjPtHR2+F3uRs9xR+4I6UMJf8hu5gK?= =?us-ascii?Q?xalW0O8q45MeAbAi85X4XKBEsOFD2OLD6p4Ve296VzYIaWQgkciSKXeDDToa?= =?us-ascii?Q?dnUg4xOLtHMcXsGeeftU2qTKMCNKKx4nU8t0NMMU87d4FTAtQYdzKIb38yES?= =?us-ascii?Q?VtAcP6BLWxvuzHqi9JU3R2+ZghJ8YaM1aRPn09x07WHa2lhcMS/dC8VIO2qK?= =?us-ascii?Q?c16HqWWGWsIe+deZpPptYruSBtkDFAeve85AgeUMTpXhgjxuOqa8W/DZRJ6a?= =?us-ascii?Q?rfWAUTCM07nFxaDo2+z4XbcqRBV7+XMnzVTH0Wo8Zm8JVjpnm7M/oYcZzU/D?= =?us-ascii?Q?yiZo3Nn0VQDyuwpE3hFOVzcEx6mzJ3eTkV3EfmhQ7NfhFFIPmJCMN9F1SmvG?= =?us-ascii?Q?vhmU3PInqz6c44IlsJoMoyqALeZvs6eCD9OBJ+mOEEWy/npdh5vxQ6WvrV8d?= =?us-ascii?Q?n2goGbjNmk0W+1DA0OZZIEzBOPJlVusOMCduQJkqrKYY9CqMCxgDRaPRaFzY?= =?us-ascii?Q?UQn/fVcqjV/xpyrOeZB/moeTH1ACGLJZvyKRugSdvTqGFzuURPwfAr9w5DkI?= =?us-ascii?Q?pJbBq6ylBlYG3aPXDWw9XPNivbTKdUZgPXZBUzpkwkXamNuEsGUttPbvbGt9?= =?us-ascii?Q?1buiSJus9n32XTjgWuqcdW/rCTr46iCH7ZhYxf+kFddbK1yFji9GGYImsFER?= =?us-ascii?Q?+W0PtINxmSf04IGEY43GUD6ClqIXTVTcMPbrZuw1R5umouwsYSsZVmX5Xnyw?= =?us-ascii?Q?PzFa3ZbukEHlt9ZseYbP078K/PxNaI99vykikIVgyGJKIOaIzJyUX9lNKvtT?= =?us-ascii?Q?7RZXWK5DClKlxMYnGHQN1vlvMr27YZikBi/yTquV53IOa/dlhQcvdUawyRxj?= =?us-ascii?Q?+NdS+aagkc6NMj1YQz7wsa5CEn6C8fsh0tgJ1SIXRvkt+HnSjE0I4dQjDVvw?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 6:wvTXnPds9QsWhg1kzfIoSR6TGdPio6rEtupDJU+PJz3tkvRwqKzhbZRqDoxYLZ06aneLmhI5viu+EoW+nEO5ciaW+oXyNej0YqTFyctX/O/w54VRMfFp9DdvWPOq/N2IFFIA+0F7VQY1bdpbpNItWZ3EZcAuJerptuAfl44yg0eaC13TGbPgrvnDYeAmTu77muzhzTjgTCsfhy+a2JpeUJTLgtv1AzPgMUYJmo6+ZeKKD1vH8MYLYGmvTxshtT3QGtmhH5ev2EtmzaknQVcBibrTOEhxSqnT0K4WTlS/RpKdUJuG3yX+xFlJlMasjaDqXAvEf6TzIX6NGvJD96pk+cJzk7ml+j6CTt9AP1G7PGTYE1moQsaflK1wjBI2O9Q5ohDWdZhVXlEcytbXm21DSz95VXrn4vLJ2ZgrtJr2gxiAszMqBsWXkTHsBbSgwwFpq14BKCclRsL82t3+y/79s6qoH2UWnvGy6Lq+722GP7Y=; 5:HgGmQvLvCSvZgvRLKdAW1yw9AqEed7ByS77z0bYdXdDj2PeV1JqzfVGAvu20PYCL3AswMwHvwFIZdNYqJdG0PoYqPsuI6akno/LGMzOvCMTKFvG1HrnpoV0HO1cjcwklXfuxIdTPfQVvTYGuFiBrQw==; 24:KUbJle+IUzJfC0fIKUGSzeMmB2IBOklus6NhvW8FRK7NETOLnFqa4TLVOLUQwu2gCWH5vhSwH2fM3g6rldpUMr2wlMnYeKZYuHC4gfIb940= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 7:HoiqL+eSf1GgbqzAIgbO4q6YHM3fLv73rL3uUsf/0G6LkTaZxLesZJHLuy38VZ3bSbiuatIgOz2WIOBhMG7YR36MzlwcPMvdRlQE/AOhb7Lf0gMCTfIUIqStZo1ytLWPsZ7RNidIHs6w9E/nuudpwaqU1UQGQM0CUlpqXpb9Gc6A4LFECcSh/ea92Z1rTVfEOLW+8lPoV02DzwYrIxUq6d3OYmaz3s6XNI59155EgT/4ahj1pDCqjlwqOBaUDZiCyR0C57zZRnJHUU7PIgK1+rahK7oGihT9xlqPcky7Mi9Ivp5qSP+x/89NDmT5hxLFqmG/7OdL5GVvsrPAOge/lQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2017 04:35:44.3214 (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: CO1PR05MB539 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-04.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, 10 Apr 2017 04:35:49 -0000 This version looks good to me. -- Mark From nobody Sun Apr 9 21:37: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 BD0C8129408 for ; Sun, 9 Apr 2017 21:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqGeewl__Q-W for ; Sun, 9 Apr 2017 21:37:20 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0096.outbound.protection.outlook.com [104.47.33.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8832128AB0 for ; Sun, 9 Apr 2017 21:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Url/NH/0W8esaBwhlBPU+4ru99/GiJmJMgSvFYbkwY=; b=TuFiy9Szz1bwTm/e8xl23hcyexcrs1hwSzk/pcK7U0WmhkBnd2DwDnApok34piU8vcTzeCurcKvlAlpPX3ULRFTFdBRkLSf3q/7jJLLaXNFZF+zjrFCjMZkuY7vq4N+NZhtx020EHfk/f2Xf2itXy55jGgeb0BFp3e8cqU+Mhjs= Received: from CO2PR05CA0071.namprd05.prod.outlook.com (10.166.88.167) by CO1PR05MB539.namprd05.prod.outlook.com (10.141.73.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Mon, 10 Apr 2017 04:37:15 +0000 Received: from BY2NAM05FT040.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::209) by CO2PR05CA0071.outlook.office365.com (2603:10b6:102:2::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5 via Frontend Transport; Mon, 10 Apr 2017 04:37:16 +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 BY2NAM05FT040.mail.protection.outlook.com (10.152.100.177) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1005.5 via Frontend Transport; Mon, 10 Apr 2017 04:37:15 +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; Sun, 9 Apr 2017 21:37:13 -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 v3A4bCMZ015733; Sun, 9 Apr 2017 21:37:12 -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 8BB661145A; Sun, 9 Apr 2017 21:37:12 -0700 (PDT) To: Daniel Migault CC: denis bider , "curdle@ietf.org" In-Reply-To: References: <1490575901696.39454@cs.auckland.ac.nz> <20170327072447.GA2827@LK-Perkele-V2.elisa-laajakaista.fi> Comments: In-reply-to: Daniel Migault message dated "Sun, 09 Apr 2017 13:56:28 -0400." From: "Mark D. Baushke" X-Phone: +1 408 745-2952 (Office) X-Mailer: MH-E 8.6; nmh 1.2; GNU Emacs 24.3.1 X-Face: #8D_6URD2G%vC.hzU 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)(39450400003)(39860400002)(39400400002)(39850400002)(39410400002)(2980300002)(199003)(189002)(9170700003)(105596002)(53416004)(76506005)(2810700001)(7696004)(2906002)(189998001)(7126002)(5660300001)(6246003)(81166006)(8676002)(229853002)(8936002)(6916009)(2950100002)(86362001)(39060400002)(50226002)(5003940100001)(4326008)(6266002)(38730400002)(230783001)(117636001)(93886004)(47776003)(48376002)(50466002)(77096006)(6392003)(7846003)(50986999)(76176999)(356003)(106466001)(55016002)(305945005)(110136004)(558084003)(54906002)(53936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB539; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT040; 1:v0AMMhw/8jZmXW89hgizaYA6oblWAs+/2f4EMNlLGjZqFHDwJH4TI3Pjfg5DSGVgkMl+t6oYez4AhhfLjeZ6xZUMaNS6Od8Ii39U6XCUrqL/FZw0vZSPZYwxmiFC9B/UhwTykvnpTXIMN8/wKxTDkgAjs3mLjw/8zoMkqq74XKaAi/5PNYZQhfGDzfairH0oXL+xu+3IVfqH/YQN3jpwd0aSZTXIqHF48U0U1Xk7VyN/qpSzbKCMIXL2/MkAqNY2VM4Jmrm4Vo2jyhhSNJRgQvk9D7tEoPp9FSU9jR6VM46wbwp8e8lfWV5o2wd2o99096RVvhctG7ZIXt2sUG1b1DoLTbyTU3mWU7xut5iyWAVWVObNR9DHM01+lbcgpcossrah6HUE8W7OxR95fk+MlZ8vIvweVbWow6mSOMCdeVv5EaoBxPu1WdIA5PLUtyyglWZtxCi7ZV+DtKRAD15V6cTAF02tFmwcRtwbLJpqZ6X1Txlp+TVpbWcEJcWSquj5A6Xv8VPkxgvqYhKNZ/vqv0ldPwVcgcRIKIGT+n0q1VoyJrzhZhMyOEtOV5joAGsXLKPCnAD6/xs/n3YrbWC1WA== X-MS-Office365-Filtering-Correlation-Id: 219e34ea-a2fc-4bb6-19e0-08d47fcb43e4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 3:6uv09x1KnmYi+XCzliCWCygOwiz312qu8LT2Xp/7f2n+i3GTEHNLjXqkAUPfKDfnfxHW7Fysd5VncLH8Wcir8RUVHSstYn6rYAqg/eh9KIGfKQ43L6gKEPhxenbU2+wtDh0J97lBcMSQ+470Q+seOlo4NmpXhsckuG0N6dxqXQ4hS3uG3ECUqLidEPoHh2xscjLQ+F/Ui+nkQKN1JGpf/G7KQppwTi1h4x8Ud/5HMqzG0PI4uM6Fg8jV6L8H45X7pZcAD+Fc+DlIAH0feBEJs8R7NMBGB6LF0hwyjBDZjQWp4vVGnqBOF8K50xlJmHQ9XaaKnfV+h+8Tz3NrGi+hLxc7k1lUYXzviI25Qmbj+gelNWsOr24Q0c2a9gIjPWt0veoay2rvb0yhCqRp0SfwGMJK2UJGo7CUWxgdB1TVw8WvJm0l2XFyKwrPBhp1+fwHZdwYwsFfF6O5a7TG5y1HovmYa8dra1UWKzfBD9OsJr9sDFPakwtCIp8acQNuK34J X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 25:zKnNJRuJtONChIZblOJ+16L2fGl9GeJK9/5FnAuw+mGgEBIZAg4jXGHzVSQpa6EZ3N4Ee/2L9aQc9jSupQnX76FXxVWvvjI28cWCq2e+twk6BoWfifrHQ4BiLpRrNdw+GL/jtjdoFat+keZH1lkeVB2hqTZ3uHCwWT25PqzovUVJTtkq2NqJKB9pRozssmBwYK0Dw+nFxvUMRFV1kqvMpPF6JX47uxFZb0/uLCuRmFOmK69yzummNv7YOOhVOxgd7SqvtsRG+W6QouZIw3hnHT0KiF8FLAHi937DQnaRGFKxsKIZ1kEzZikTdZPVax5sNSVHlBUXbei1Ad482etLEJ3zFwIIVVp7lFcFbYgA1ye8ng3jbI20YfbCA8tIS9K+uMJLuGiKE/vDAR1dbY58k5/DrkDmFoqiMHjHT1lOlmHYtMPMfBKRJemy0OqAtk14wXGZtZlbJn1fy4F0A6OT6w==; 31:HFM+JTo/jXSPJeYPg8eY3sYDuFY6W+h6hgyKsw+VEFSxrsufseEI/vq5FTpatTkbMyMDmh+yUFf3FyTXTaoigY9miZMO4Wpn+ofM54tgokj4x1HotO4rdKdoHz6elkV7QGh0YR3/diXzOf5fiXwlJImQZn9hAH5YCUXnClsxSFc3m2y3AziRwgNRHqULKz9wjs/p8KS4+gMq3rjylYDWTLWN0yRGOXTtrMe9vuQd+TMx8nDhRXTQzrWjIGdfYXWzZAmI7YhXJiI22IOaMidgAH/mfHR6lN0k0WRLzJbbWE8= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 20:2oA5/yeJH9S+u+hQGFI7BogD5wxLUsN/q70+oj1uakrevTYvQ/JFfhmTEMdUyE6LKkM5HmAIpF0w/LMV0KZzd0+JbB8vHRjKShT9y/iWDEKFTaGlhQnDJoi7XXqPiFRUzrHlDLjk9FFyz/93nlExNBuYETO6+kudkl3B3tKL/l4IYrIQUK6dqbHhOFhhtY2+DQ8ZZNirAzFG6UC90iuGvSLB7Xvm7kIyHHiRz0kHnYgojiXUdDLJRCMsRpKRA8ksrk3x1Tj1YjvOQOKEL5jqHGM2A8GsYghzrgfL5Dy8Fxo5oRcwLPOu5aAM+eHWbneYNFbV2uiz8rSU5o2RA51YPOSQj4MJtY2+52ClkUYaUNcHTpMUXuKD4qxKWgWgFh1FqxnpqAOvbIjtolEWdEOYhW/4GbR16ewCofIf5hRV+z0B880vRS49lI7xBqNgzcwaKhNGNXzsiGaq/E1NXsv7yL5RbI2mAGmSf8VLCJVqDXCNA+PwOD9yVn3Dj68Ovg7/ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13023025)(13024025)(8121501046)(13018025)(13015025)(13017025)(5005006)(3002001)(10201501046)(93006095)(93003095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CO1PR05MB539; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 4:ewbz7nzm4Mq4BbpLRgVYnmuO8y/vKjzvSlSsCxrU9ao4g1IvhbjWqgPhgWHRzRtQLOkzH5eKEijBEx4ZUNglsWcy9LKO8SWBwxX3rKh9u8pdB2OyuYpC+CbnAgj6zaDGAyl76x/4Sk9eCzC42IXn6aTwzewza8wmb9B/L76Rp/jgM6jx+unRfKff2uz1VgFHX4OKENzues9Wh0fyo+LkUbDiamw1t91Ek9I/hK4QRdsEAUxBFJBp2BA6j8HK3Uc55AnzaasaR9KcRawZoBJJWY48y6C3YouY79RMna77lZDBaaOyzXxKALhVYoLSYKnrEKZDroP917vcTeLBSidohyS8L1Ut4cpOFKsHc6HZeZoubR8chYRyJY/kgK3zkDt986FRNitJDIBq3fdiTzLdbeveU3aFgEBomYNnLgeFEG4YUIixY0J2A9Bl/ZTDwLyGEmqrW9gzUsx2yRgr/n43y6qUjXK9L7E4uBHpIMnSkv2ncfVaEwBI3IXWNtSlB+Yd6KBD9XXYG7JfMOZ8nMsH+vpHruW3Y85kzOFQOnYVAktnL7vY+lnymtGOGfMei+iMFv3sJCRJCuNnOYgRCrkb1kpfeelw3uU34QYm2pZcsiJG0mT4b6A9uyNO5ScpuFzIf8tN1J82soIr5Frri2j3MCl6HZWwfxGqX/h+SiK7gi0wS0OSEpatEYHQvz+eBFF9F9nfMZFGyUMikZvYH82NPsqWGWP3eJpkuDJ1thj7yDPnAfbLndPJOsq4M0K2lRZukSRqb0br3HXAA62hZPJ5alQNjkreg8SUXS6tZFSGBcv83HFc4qLb8OyLXRdGN89aW1W7Y7f20J+gQsEVojGWqA== X-Forefront-PRVS: 027367F73D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB539; 23:1gVW8um1hcJ2p26tPFx4Ht8qPl1IFVs9aYaNVma8AH?= =?us-ascii?Q?2oAL2yHZiTMerctQwEbURzWDA7vjEnbTBML7hrL1p0zuiZKY+SpcBJdTDBbD?= =?us-ascii?Q?8E6IqVSU4ejZ46QYZYtX12QGwN9Dp9lyFKA/7sjMPPZMjWMS/L5VJH7flFVJ?= =?us-ascii?Q?xBRYtpaTw0dnegolJaKzuOFcTaglCgZ6oEJ3In/X34qsWSomC9pu8Na247eU?= =?us-ascii?Q?NJ5dhu0M/YnfpySnzFoyNWucnRyXGVTh0zi14qEwcYtKOKTVJiijWWcA4Jy9?= =?us-ascii?Q?Y253Cm9UfYGBpySaCctuHLrwjv98iKtLCGO+HJqzjDvKgS129bIloSFv5Cho?= =?us-ascii?Q?oGwER6nHSO8RHz+HFI9pEeVvrtEnKoOHUtI+PpCcteV8krn8+GJwA4Bbw/ER?= =?us-ascii?Q?96umEtXThgwNva9vVZFwRs6z58BNhvxx8IoH0HfwxT7ggWRTOInX/Z9V0s8V?= =?us-ascii?Q?qdldhpj7ASIjcZ/joSVt/4Bacgwd/I9FpsPkQ0Tb8S1WNLzFtMCTKlnm/9IG?= =?us-ascii?Q?qpZVhIt/CvW02aeCaucKmUgvBUTgbvyWbUsp35N4gogJ7l0+reyw9d7wKh/q?= =?us-ascii?Q?zDjm0Jbku22AOYVHSkyEXH+6wbS00xblP/xBqqM+wX6WZfy6C1skT3pTJ323?= =?us-ascii?Q?SDaQbhwlOQpI1aPu0hZTxVDZfiDa4r7r3ktYjCyT7vwf770NDsLNGy4lBrAx?= =?us-ascii?Q?q6sUeQHyZ4j8WEFql7SLLCSlfl8L+UZsL3+3MtsldpgQzmIIlAjalkRXrQP0?= =?us-ascii?Q?U0rPZnfXDsaM33uN5iJ61v2234QBMaIt0TGbthSZ/PypB2zUT4ecGLYyMfBP?= =?us-ascii?Q?V4WH8A3Zpo1Nx0VxTajJ1iRifPMGCSzPWng4V1ay0HwY9gT77UTzhvD8edya?= =?us-ascii?Q?ojlSdIzUkZa7K6yMpZWpDcBVhl6Z4u6gXA4LVTlPXLyQhydA3+bvPaj9Eycl?= =?us-ascii?Q?8v944SDcg3L5g0RAvQFwzCGAxiK9bxpJR6JqgOQFqqaeKo+mGVSHSdoTsQcQ?= =?us-ascii?Q?Eo+KSeBs2XXdhNPo6RGyati1koOSqkEnFG2tT/+/HSuoc201nWXO52uBa2U9?= =?us-ascii?Q?PzNGAaQccjyNxdg5+OWuXwNdYFgQVAyAQMaZIHGhh9CXJ9UeMLjnoFrcGN+9?= =?us-ascii?Q?wjdrlX9sYdYS5kcKUH3pY1MsjIw/1WBXPnTzUCChM2vhoKTN0Mba1HHfmTA3?= =?us-ascii?Q?rjEtE3WHoG7GpcUMRpS+slQy3n2bXH/btmleSS0W59ByGk3ZUufdSFXv6TRF?= =?us-ascii?Q?MYkLp5h2qeWFuCGLwzTJ+K7o/C3F+0wz7KevJ5l8r6cAhX/Ol7DfQVJhIhpu?= =?us-ascii?Q?ooZ9VU11wSwPpKHEZeUAbLhh2BYRi3NuHGnb/XWjsp?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 6:HJEyC/3pT6TiG4Tj4yrPQeWufaQwuNUkzKTdSHoFyihC/DVohHgvi8lCLP9qA9mWlWO9GLRm0cdsVAU0v8hKTmKlB4X8aHb+Zfs/qpRAmTRe1b4AZltboRPFtYd4r0qy6BdP/C1QZozN9ERdV/Q9dk0425P/UCjKaSHIVe5iN/fuYPtjPYDwvRc82dXbqSkO3bs3FWY1BO6vbfCx8aPnlG5QHGvZVlwIXne1/sMDZCuL8zees59lFPyQmjUFDBPV/uJoY/rmIZcG6Kx/PTo/odJMJS6wdmranihAQwv6/PxKtaPMnJA+uElXyVY8UoqfC/ndVIGcQAMokZX8fTfg+j+dnhgGBmfxkttgIUiCI5T+jv7YPMltxOKl3+0foW9+GtPAD3qAEDvnpFoFUoZpMID0bLwYSGqU4x4/g9wDIIoGfCEwqAJogUjjCyNaLt5lMG2MCPHd3YBXWBnIynkBRQkSCngnryfD2VmCJrGKh1Q=; 5:4XUaaTUkr06h8Xppd+IzIEjzMi3/J58v87zX2DbQEPGLdJbQIwu6RpenHWBEq2AckkMewEcSQERiOzD1tSBdKAMfwWPvRcIGgSt1Vapz0hCZeHAvAjC1Q68+QF1i4jrktbCAf76Do87KFZwyvKmP2w==; 24:/EX6AqR92QThc/eqDwH/legPH/rculwKDZLAs4WKIWM4Iq1awUZwOH+9lFJS60CdkpaTquboVWU/Uj8O8oOQo8B81UixECgRUFusBGEYF+I= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 7:iASxh5LUb5SGrmP6b9THbCP95Ex/4kXZHWv0ovZQQ+I/iVL/kRzs+HMzh/zsQ/X+NRUrYLiUO+XlkJFcON7BaelLTRL0jhjAtwzzGegd9NJ0W3P41KkNjutwxugS97cNLB5cvv32HounmFCTOq9DzVGiLrDrCAgvsw6xgT0h9F3sSvS2Roma/vNGEEhXxmsWzk4x4o/33691RSITEYlDUQ6RRQMCbo7j525jPdFUkwQ6hXSNKqgMtfL3YlbHiUPCSw/l4Fh52WueG0kGPm+1v34dksezDZNqB3wV30aD+iP8FPxAS4sVts85LTTuHovhf4MckNoe1eFbgmB8nVRvmQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Apr 2017 04:37:15.3578 (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: CO1PR05MB539 Archived-At: Subject: Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.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, 10 Apr 2017 04:37:22 -0000 This version, draft-ietf-curdle-rsa-sha2-05.txt looks good to me. -- Mark From nobody Mon Apr 10 08:03: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 B1476129502 for ; Mon, 10 Apr 2017 08:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 eaDcRBfjTZXt for ; Mon, 10 Apr 2017 08:02:53 -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 17702129508 for ; Mon, 10 Apr 2017 08:02:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 6F7433004A5 for ; Mon, 10 Apr 2017 11:02:50 -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 pbHZq-L-Qsl6 for ; Mon, 10 Apr 2017 11:02:47 -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 AA12D30041B; Mon, 10 Apr 2017 11:02:47 -0400 (EDT) From: Russ Housley Message-Id: <78AB16BB-A362-4283-9A16-24278435BCC1@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A0E8DC26-125D-4B87-B85E-DFAB0C2CD39A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 11:02:57 -0400 In-Reply-To: Cc: Jim Schaad , curdle To: Daniel Migault References: <059001d2a8a0$da207680$8e616380$@augustcellars.com> <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> <05d701d2a8b6$d1895bc0$749c1340$@augustcellars.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 10 Apr 2017 15:03:06 -0000 --Apple-Mail=_A0E8DC26-125D-4B87-B85E-DFAB0C2CD39A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Daniel: Thanks for the review. > 1) nits tool > the nits tools returns the following additional error: >=20 > =3D=3D The "Author's Address" (or "Authors' Addresses") section title = is > misspelled. Fixed. > 2) section 2.1 defining KEK >=20 > OLD: > To generate a key-encryption key, generates one or more KM blocks, >=20 > NEW: > To generate a key-encryption key (KEK), KDF generates one or more KM = blocks, Okay. I made that change. > 3) section 2.2 defining HKDF >=20 > OLD: > The HKDF key derivation function is a robust construct based on a = one-way hash function described in RFC 5869 [HKDF]. >=20 > NEW: > The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a = robust construct based on a one-way hash function described in RFC 5869 = [HKDF]. Okay. I made that change. > 4) IANA section:=20 >=20 > * Wouldn't it be appropriated to mention RFC7107 section 3.3 and = section 3.6 for each allocation.=20 RFC 7107 created the registries. I do not see any reason to point to = that document for the assignment in the registries. > * I have been recommended to ask to add the IANA link hosting the = registries as an informational reference. In that case, that would be = the following one: = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smi= me-3 = Okay. I handed a reference for the module arc and a reference for the = algorithm arc. > * The presentation in the IANA section differs from the one of = RFC7107 which uses a table with Decimal , Description, Reference rather = than using the OID presentation. I used the decimal presentation because that is used in the header of = the registry by IANA. > * I am wondering whether the current draft does not update RFC7107, in = which case it should be mentioned in the header, abstract and = introduction. What do you think ?=20 No. RFC 7107 established the registry. It does not need to be updated = for every assignment that takes place in those registries. Russ --Apple-Mail=_A0E8DC26-125D-4B87-B85E-DFAB0C2CD39A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Daniel:

Thanks for the review.

1) = nits tool
the nits tools returns the following additional error:

=3D=3D The "Author's Address" (or "Authors' = Addresses") section title is
     = misspelled.
Fixed.

2) section 2.1 defining KEK

OLD:
To generate a = key-encryption key, generates one or more KM blocks,

NEW:
To generate a = key-encryption key (KEK), KDF generates one or more KM blocks,
Okay.  I made that change.

3) section = 2.2 defining HKDF

OLD:
The HKDF key derivation function is a = robust construct based on a one-way hash function described in RFC 5869 = [HKDF].

NEW:
The HMAC-based Extract-and-Expand Key = Derivation Function (HKDF) is a robust construct based on a one-way hash = function described in RFC 5869 [HKDF].
Okay.  I made that change.

4) IANA = section: 

* Wouldn't it be appropriated = to mention RFC7107 section 3.3 and section 3.6 for each allocation.

RFC 7107 created the registries.  I do not see any = reason to point to that document for the assignment in the = registries.

* I have been recommended to ask to add the = IANA link hosting the registries as an informational reference. In that = case, that would be the following one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#s= ecurity-smime-3

Okay.  I handed a reference for the module arc and = a reference for the algorithm arc.

* The presentation in the IANA section differs from  the = one of RFC7107 which uses a table with Decimal , Description, Reference = rather than using the OID presentation.

I = used the decimal presentation because that is used in the header of the = registry by IANA.

* I am wondering = whether the current draft does not update RFC7107, in which case it = should be mentioned in the header, abstract and introduction. What do = you think ?

No.  RFC 7107 established the registry.  It = does not need to be updated for every assignment that takes place in = those registries.

Russ

= --Apple-Mail=_A0E8DC26-125D-4B87-B85E-DFAB0C2CD39A-- From nobody Mon Apr 10 08:07:02 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 50E9A1275C5 for ; Mon, 10 Apr 2017 08:07:00 -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, HTML_MESSAGE=0.001, 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 mVx2aK5YVqCD for ; Mon, 10 Apr 2017 08:06:58 -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 1F0D01294F0 for ; Mon, 10 Apr 2017 08:06:58 -0700 (PDT) X-AuditID: c6180641-80136980000058cf-f6-58eb593758c6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by (Symantec Mail Security) with SMTP id 9D.DC.22735.7395BE85; Mon, 10 Apr 2017 12:06:47 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0319.002; Mon, 10 Apr 2017 11:06:56 -0400 From: Daniel Migault To: Russ Housley CC: Jim Schaad , curdle Thread-Topic: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 Thread-Index: AdKokxxO2cfh4aL8Tx2cBfTIJudH4gAQe8YAAADS2oABwVrhgACT05WAAAhQ4PA= Date: Mon, 10 Apr 2017 15:06:54 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8E@eusaamb107.ericsson.se> References: <059001d2a8a0$da207680$8e616380$@augustcellars.com> <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> <05d701d2a8b6$d1895bc0$749c1340$@augustcellars.com> <78AB16BB-A362-4283-9A16-24278435BCC1@vigilsec.com> In-Reply-To: <78AB16BB-A362-4283-9A16-24278435BCC1@vigilsec.com> 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: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8Eeusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXRPiK555OsIg4kTbSy2LpzFbPHqxU12 i9XTv7M5MHtsnDOdzWPJkp9MHqvufGENYI7isklJzcksSy3St0vgyujq2MVa8C2q4tVLgwbG Hr8uRk4OCQETid8fZjN3MXJxCAlsYJR4v+oHK4SznFFiZudvFpAqNgEjibZD/ewgtoiAusTf +RfAbGYBR4l7X24xdjFycAgLeEgcmuwAUeIp0b5mLlS5n0TrpLdsIDaLgKrEmicPWUDKeQV8 JWa9l4ZYtYJJYvO/e0wgNZwCDhKn1p1nBbEZBcQkvp9awwSxSlzi1pP5TBBHC0gs2XOeGcIW lXj5+B8rhK0k8fH3fKjT8iU+tl0Es3kFBCVOznzCMoFRZBaSUbOQlM1CUgYR15FYsPsTG4St LbFs4WtmGPvMgcdMyOILGNlXMXKUFhfk5KYbGW5iBMbTMQk2xx2Me3s9DzEKcDAq8fAuCH8d IcSaWFZcmXuIUYKDWUmEN3UGUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvu/ILEUIC6Yklqdmp qQWpRTBZJg5OqQZGpoUKN9m4CrY+fRr3Mf6At9T3SAfvw2UZZ15cSwo7E3BodnbiioQfGUrT LxVM4JgwSVjILM2Ga92uzqfTO66GB/zxZK/9+WzH3jsFlfX8B93epbnnPr/E/2xGyrP+b6qu KRHb/Nq0r0++uLvzeafm/e1rOGSexp7UmhZ1YR+DTklB5Tbdk/eVlViKMxINtZiLihMBOxwc CaMCAAA= Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 10 Apr 2017 15:07:00 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8Eeusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the registries clarification. One more question, are you aware o= f any implementation of the drafts? Yours, Daniel From: Russ Housley [mailto:housley@vigilsec.com] Sent: Monday, April 10, 2017 11:03 AM To: Daniel Migault Cc: Jim Schaad ; curdle Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 Daniel: Thanks for the review. 1) nits tool the nits tools returns the following additional error: =3D=3D The "Author's Address" (or "Authors' Addresses") section title is misspelled. Fixed. 2) section 2.1 defining KEK OLD: To generate a key-encryption key, generates one or more KM blocks, NEW: To generate a key-encryption key (KEK), KDF generates one or more KM blocks= , Okay. I made that change. 3) section 2.2 defining HKDF OLD: The HKDF key derivation function is a robust construct based on a one-way h= ash function described in RFC 5869 [HKDF]. NEW: The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a robus= t construct based on a one-way hash function described in RFC 5869 [HKDF]. Okay. I made that change. 4) IANA section: * Wouldn't it be appropriated to mention RFC7107 section 3.3 and section 3.= 6 for each allocation. RFC 7107 created the registries. I do not see any reason to point to that = document for the assignment in the registries. * I have been recommended to ask to add the IANA link hosting the registrie= s as an informational reference. In that case, that would be the following = one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security= -smime-3 Okay. I handed a reference for the module arc and a reference for the algo= rithm arc. * The presentation in the IANA section differs from the one of RFC7107 whi= ch uses a table with Decimal , Description, Reference rather than using the= OID presentation. I used the decimal presentation because that is used in the header of the r= egistry by IANA. * I am wondering whether the current draft does not update RFC7107, in whic= h case it should be mentioned in the header, abstract and introduction. Wha= t do you think ? No. RFC 7107 established the registry. It does not need to be updated for= every assignment that takes place in those registries. Russ --_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8Eeusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the registries clarification. One more q= uestion, are you aware of any implementation of the drafts?

Yours,

Daniel

 

From: Russ Housley [mailto:housley@v= igilsec.com]
Sent: Monday, April 10, 2017 11:03 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Jim Schaad <ietf@augustcellars.com>; curdle <curdle@iet= f.org>
Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curve= s-02

 

Daniel:

 

Thanks for the review.

 

1) nits tool

the nits tools returns the following additional erro= r:

=3D=3D The "Author's Address" (or "Authors' Addresses")= section title is
     misspelled.

 

Fixed.



2) section 2.1 defining KEK

 

OLD:
To generate a key-encryption key, generates one or more KM blocks,

NEW:
To generate a key-encryption key (KEK), KDF generates one or more KM blocks= ,

 

Okay.  I made that change.

 

3) section 2.2 defining HKDF

 

OLD:
The HKDF key derivation function is a robust construct based on a one-way h= ash function described in RFC 5869 [HKDF].

NEW:

The HMAC-based Extract-and-Expand Key Derivation Fun= ction (HKDF) is a robust construct based on a one-way hash function describ= ed in RFC 5869 [HKDF].

 

Okay.  I made that change.



4) IANA section: 

 

* Wouldn't it be appropriated to mention RFC7107 sec= tion 3.3 and section 3.6 for each allocation.

 

RFC 7107 created the registries.  I do not see = any reason to point to that document for the assignment in the registries.<= o:p>



* I have been recommended to ask to add the IANA lin= k hosting the registries as an informational reference. In that case, that = would be the following one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smim= e-3

 

Okay.  I handed a reference for the module arc = and a reference for the algorithm arc.



* The presentation in the IANA section differs from&= nbsp; the one of RFC7107 which uses a table with Decimal , Description, Ref= erence rather than using the OID presentation.

 

I used the decimal presentation because that is used= in the header of the registry by IANA.



* I am wondering whether the current draft does not = update RFC7107, in which case it should be mentioned in the header, abstrac= t and introduction. What do you think ?

 

No.  RFC 7107 established the registry.  I= t does not need to be updated for every assignment that takes place in thos= e registries.

 

Russ

 

--_000_2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8Eeusaamb107erics_-- From nobody Mon Apr 10 08:16:32 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 7024E1242F7 for ; Mon, 10 Apr 2017 08:16:29 -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, HTML_MESSAGE=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 fDdGkyTEL1U7 for ; Mon, 10 Apr 2017 08:16:27 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC9FC129534 for ; Mon, 10 Apr 2017 08:16:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5174D3004E6 for ; Mon, 10 Apr 2017 11:16:16 -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 0XIwhKfrlKMu for ; Mon, 10 Apr 2017 11:16:13 -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 5E3E63002D0; Mon, 10 Apr 2017 11:16:13 -0400 (EDT) From: Russ Housley Message-Id: <2D94CE32-695A-40D5-AA47-38A239A3425E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F5BB2AC9-D22A-40CD-A53C-F635497F81D6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 11:16:12 -0400 In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8E@eusaamb107.ericsson.se> Cc: Jim Schaad , curdle To: Daniel Migault References: <059001d2a8a0$da207680$8e616380$@augustcellars.com> <96562891-0B33-448B-9E07-92775A4B2A88@vigilsec.com> <05d701d2a8b6$d1895bc0$749c1340$@augustcellars.com> <78AB16BB-A362-4283-9A16-24278435BCC1@vigilsec.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BC8A8E@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-02 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, 10 Apr 2017 15:16:29 -0000 --Apple-Mail=_F5BB2AC9-D22A-40CD-A53C-F635497F81D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have had one person talk to me about implementation, but I do not know = if they have started coding yet or not. Russ > On Apr 10, 2017, at 11:06 AM, Daniel Migault = wrote: >=20 > Thanks for the registries clarification. One more question, are you = aware of any implementation of the drafts? > Yours, > Daniel > =20 > From: Russ Housley [mailto:housley@vigilsec.com = ]=20 > Sent: Monday, April 10, 2017 11:03 AM > To: Daniel Migault > > Cc: Jim Schaad >; curdle > > Subject: Re: [Curdle] Review of = draft-ietf-curdle-cms-ecdh-new-curves-02 > =20 > Daniel: > =20 > Thanks for the review. > =20 > 1) nits tool > the nits tools returns the following additional error: >=20 > =3D=3D The "Author's Address" (or "Authors' Addresses") section title = is > misspelled. > =20 > Fixed. >=20 >=20 > 2) section 2.1 defining KEK > =20 > OLD: > To generate a key-encryption key, generates one or more KM blocks, >=20 > NEW: > To generate a key-encryption key (KEK), KDF generates one or more KM = blocks, > =20 > Okay. I made that change. > =20 > 3) section 2.2 defining HKDF > =20 > OLD: > The HKDF key derivation function is a robust construct based on a = one-way hash function described in RFC 5869 [HKDF]. >=20 > NEW: > The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is a = robust construct based on a one-way hash function described in RFC 5869 = [HKDF]. > =20 > Okay. I made that change. >=20 >=20 > 4) IANA section:=20 > =20 > * Wouldn't it be appropriated to mention RFC7107 section 3.3 and = section 3.6 for each allocation. > =20 > RFC 7107 created the registries. I do not see any reason to point to = that document for the assignment in the registries. >=20 >=20 > * I have been recommended to ask to add the IANA link hosting the = registries as an informational reference. In that case, that would be = the following one: = http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#security-smi= me-3 = > =20 > Okay. I handed a reference for the module arc and a reference for the = algorithm arc. >=20 >=20 > * The presentation in the IANA section differs from the one of = RFC7107 which uses a table with Decimal , Description, Reference rather = than using the OID presentation. > =20 > I used the decimal presentation because that is used in the header of = the registry by IANA. >=20 >=20 > * I am wondering whether the current draft does not update RFC7107, in = which case it should be mentioned in the header, abstract and = introduction. What do you think ? > =20 > No. RFC 7107 established the registry. It does not need to be = updated for every assignment that takes place in those registries. > =20 > Russ --Apple-Mail=_F5BB2AC9-D22A-40CD-A53C-F635497F81D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I have had one person talk to me about implementation, but I = do not know if they have started coding yet or not.

Russ


On Apr 10, 2017, at 11:06 AM, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Thanks for the registries clarification. One = more question, are you aware of any implementation of the drafts?
Yours,
Daniel
 
From: Russ Housley [mailto:housley@vigilsec.com] 
Sent: Monday, April 10, 2017 = 11:03 AM
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Jim = Schaad <ietf@augustcellars.com>; curdle <curdle@ietf.org>
Subject: Re: [Curdle] Review of = draft-ietf-curdle-cms-ecdh-new-curves-02
 
Daniel:
 
Thanks for the review.
 
1) nits tool
the nits tools = returns the following additional error:

=3D=3D= The "Author's Address" (or "Authors' Addresses") section title is
     misspelled.
 
Fixed.


2) section 2.1 = defining KEK
 

OLD:
To generate a key-encryption key, = generates one or more KM blocks,

NEW:
To = generate a key-encryption key (KEK), KDF generates one or more KM = blocks,
 
Okay.  I made that change.
 
3) section 2.2 defining HKDF
 

OLD:
The HKDF key = derivation function is a robust construct based on a one-way hash = function described in RFC 5869 [HKDF].

NEW:
The HMAC-based Extract-and-Expand Key Derivation Function = (HKDF) is a robust construct based on a one-way hash function described = in RFC 5869 [HKDF].
 
Okay.  I made that change.


4) IANA = section: 
 
* Wouldn't it be appropriated to mention = RFC7107 section 3.3 and section 3.6 for each allocation.
 
RFC 7107 created the registries.  I do not see any = reason to point to that document for the assignment in the = registries.


* I = have been recommended to ask to add the IANA link hosting the registries = as an informational reference. In that case, that would be the following = one: http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#s= ecurity-smime-3
 
Okay.  I handed a reference for the module arc and a = reference for the algorithm arc.


* The presentation in = the IANA section differs from  the one of RFC7107 which uses a = table with Decimal , Description, Reference rather than using the OID = presentation.
 
I used the decimal presentation because that is used in the = header of the registry by IANA.


* I am wondering whether the current = draft does not update RFC7107, in which case it should be mentioned in = the header, abstract and introduction. What do you think ?
 
No.  RFC 7107 established the registry.  It does = not need to be updated for every assignment that takes place in those = registries.
 
Russ

= --Apple-Mail=_F5BB2AC9-D22A-40CD-A53C-F635497F81D6-- From nobody Mon Apr 10 08:19: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 1829812953B; Mon, 10 Apr 2017 08:19:19 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149183755906.3094.11018362726806348687@ietfa.amsl.com> Date: Mon, 10 Apr 2017 08:19:19 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-03.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, 10 Apr 2017 15:19:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of 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-03.txt Pages : 16 Date : 2017-04-10 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-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Apr 10 08:21: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 18BB2129537 for ; Mon, 10 Apr 2017 08:21:10 -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 ZO6oFBKuldQm for ; Mon, 10 Apr 2017 08:21:08 -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 A374C12783A for ; Mon, 10 Apr 2017 08:21:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1B03E30044A for ; Mon, 10 Apr 2017 11:21:07 -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 I1fDWNQSP2_i for ; Mon, 10 Apr 2017 11:21:04 -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 E8051300098 for ; Mon, 10 Apr 2017 11:21:04 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 11:21:04 -0400 References: <149183755906.3094.11018362726806348687@ietfa.amsl.com> To: curdle In-Reply-To: <149183755906.3094.11018362726806348687@ietfa.amsl.com> Message-Id: <066695CC-FEE5-4944-A55F-DA678B496573@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-03.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, 10 Apr 2017 15:21:10 -0000 I believe this update addresses all of the comments that I received = during WG Last Call. Russ > On Apr 10, 2017, at 11:19 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > 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-03.txt > Pages : 16 > Date : 2017-04-10 >=20 > 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). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-03 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-03 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 10 09:16:33 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 AD28A12949E for ; Mon, 10 Apr 2017 09:16:31 -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, HTML_MESSAGE=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 ieMCUWnGx5o9 for ; Mon, 10 Apr 2017 09:16:30 -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 7CB7212957A for ; Mon, 10 Apr 2017 09:16:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DE9C430044A for ; Mon, 10 Apr 2017 12:16:28 -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 1PR6iug--XoF for ; Mon, 10 Apr 2017 12:16:27 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 9B0FD30041B; Mon, 10 Apr 2017 12:16:27 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F5E20DAE-740D-43EF-967C-58B6F804ACF4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 12:16:27 -0400 In-Reply-To: Cc: curdle To: Daniel Migault References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA41C0@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] questions on draft-ietf-curdle-cms-eddsa-signatures-03.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, 10 Apr 2017 16:16:32 -0000 --Apple-Mail=_F5E20DAE-740D-43EF-967C-58B6F804ACF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Daniel: I will post -04 in a few minutes. > The nit tool reports the following warnings/errors: >=20 > Checking nits according to http://www.ietf.org/id-info/checklist = : > = --------------------------------------------------------------------------= -- >=20 > ** The document seems to lack an IANA Considerations section. (See = Section > 2.2 of http://www.ietf.org/id-info/checklist = for how to handle the case > when there are no actions for IANA.) >=20 I added a section to explicitly state that no IANA actions are needed. >=20 > Miscellaneous warnings: > = --------------------------------------------------------------------------= -- >=20 > =3D=3D The "Author's Address" (or "Authors' Addresses") section = title is > misspelled. Fixed. > Just for clarification, IANA registries do not register IODs outside = their arc. Am I correct ?=20 No new object identifiers need to be assigned. Russ --Apple-Mail=_F5E20DAE-740D-43EF-967C-58B6F804ACF4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Daniel:

I will post -04 in a few minutes.

The nit tool reports the following warnings/errors:

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of http://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)
I added a section to explicitly state that no IANA actions are needed.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The "Author's Address" (or "Authors' Addresses") section title is
     misspelled.
Fixed.
Just for clarification, IANA registries do not register IODs outside their arc. Am I correct ?
No new object identifiers need to be assigned.

Russ

--Apple-Mail=_F5E20DAE-740D-43EF-967C-58B6F804ACF4-- From nobody Mon Apr 10 09:20:43 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 60A4812957A; Mon, 10 Apr 2017 09:20:42 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149184124234.3055.6877308613133858245@ietfa.amsl.com> Date: Mon, 10 Apr 2017 09:20:42 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-04.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, 10 Apr 2017 16:20:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-04.txt Pages : 8 Date : 2017-04-10 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatures-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-04 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 Apr 10 09:21: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 5FF63129544 for ; Mon, 10 Apr 2017 09:21:45 -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 TmB1vVGYfV9W for ; Mon, 10 Apr 2017 09:21:43 -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 A7DEA129562 for ; Mon, 10 Apr 2017 09:21:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D921A30044A for ; Mon, 10 Apr 2017 12:21:42 -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 k80PBJ5kKV2u for ; Mon, 10 Apr 2017 12:21:41 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 89D9830042F for ; Mon, 10 Apr 2017 12:21:41 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 12:21:41 -0400 References: <149184124234.3055.6877308613133858245@ietfa.amsl.com> To: curdle In-Reply-To: <149184124234.3055.6877308613133858245@ietfa.amsl.com> Message-Id: <618E9FED-5B70-4C8F-92F3-A23950B0780A@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-04.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, 10 Apr 2017 16:21:45 -0000 I believe this resolves the comments that I received during WG Last = Call. Russ > On Apr 10, 2017, at 12:20 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-04.txt > Pages : 8 > Date : 2017-04-10 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatur= es-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 10 10:23: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 C86941296CD; Mon, 10 Apr 2017 10:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 v8xWGMpZrdZ7; Mon, 10 Apr 2017 10:23:35 -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 028BE1296B3; Mon, 10 Apr 2017 10:23:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491845011; h=from:subject:to:date:message-id; bh=SKtsACx9jZC5HEHSx5W/jNXJLbWa0mznLggpGzYuOyQ=; b=CSFBz1Tyxzwd6gNQpPPmVzkefoHPpKyWOBIhUO2/ZM1gShFhjhFNRSpDpCFhe1w+2ZN1XaKBaay qa8kJOMA5f/PeY6B+s8KaWV9EYVcn7AVWht6KFRH1L5HmutTV3LZNOBson6x/oj2FWtS1Hk/W2WvE RyR/gZDcujxWi43iQcoigBnXot3xxIJ8oJITNQiIUJb9/33IxwZ1eth835FuEoVtXah+mq3xB2YEs CiAK14NswpOnbD74r4u2f1iHgWt/Monb1bq6AicxCrkpBQedoIDSZ3XoYHKbyTUpc9btt2rnPrNHl KLf402W1V1+5skUgRwdK1A/aRL8qYxCSd3gA== 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; Mon, 10 Apr 2017 10:23:31 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 10:23:29 -0700 From: Jim Schaad To: CC: 'curdle' Date: Mon, 10 Apr 2017 10:23:28 -0700 Message-ID: <002801d2b21f$2c44ea90$84cebfb0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdKyFqav7LsDTXj9QJqFe0A7HoDUag== X-Originating-IP: [192.168.0.98] Archived-At: Subject: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-03 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, 10 Apr 2017 17:23:37 -0000 This draft is not ready to progress. Jim Section 3.2 - This section is wrong. It is using the wrong structure. idecPublicKey is wrong. These are all nice to haves, but I don't really care if they don't get done. I would prefer that the check of the all-zero output in section 2.0 be a SHOULD rather than a MAY. Section 2 last paragraph - add network order to the string on representing the number Section 2.1 - I don't know if you should say that the left most bits of the result are used. I know that is correct so I have a problem reading it any other way. From nobody Mon Apr 10 10:50: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 2B06B120227 for ; Mon, 10 Apr 2017 10:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 wNz7deQy9vdf for ; Mon, 10 Apr 2017 10:50:19 -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 3A344129A91 for ; Mon, 10 Apr 2017 10:50:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491846615; h=from:subject:to:date:message-id; bh=QlbqkbEJYdHKVymAjKUxt9rJNW0U2oEGR1Wgt5k/Bug=; b=Nst02aK0bLgk6LL/5pq1yU3KIJyp0/NiFbKK5mcNvyWiOalHa1mV5aNqFKnObKhqNEqWx3Qgrvv T5lQG0BwHdxXI4phm13+ERjtM6sR0m+HPWJD1xE7HvNIxkn9g94rZexvVunprx5kDjm+wUMh1mVC2 Ts2rPuCyn/roB0wLJSkRPHgjPj6fpcHK06TXg2e8/bXqKCHk/LDyTUl/yqDLtwelx7OudLIqVOOkB mEuZ8FrwYIz38kwtH0bmvWAWQpdDRtrDcUYcz/0KLu0/6VlYVjF5M4qS9O29/j4lb1VkNzDvqxjmw DFDTsyb4wp1gmz3a8SpTeU2DEeFvEHZmTSAw== 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; Mon, 10 Apr 2017 10:50:14 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 10:50:12 -0700 From: Jim Schaad To: 'Russ Housley' , 'curdle' References: <149184124234.3055.6877308613133858245@ietfa.amsl.com> <618E9FED-5B70-4C8F-92F3-A23950B0780A@vigilsec.com> In-Reply-To: <618E9FED-5B70-4C8F-92F3-A23950B0780A@vigilsec.com> Date: Mon, 10 Apr 2017 10:50:11 -0700 Message-ID: <002a01d2b222$e7f2ffe0$b7d8ffa0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIIZ3T73jo5NVktfa8UM6mXha/UFAJTwnNVoUDYo0A= X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-04.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, 10 Apr 2017 17:50:21 -0000 Except for the issue we discussed over dinner, which I have not seen a resolution for, I am happy with this document. Jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Monday, April 10, 2017 9:22 AM > To: curdle > Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-04.txt > > I believe this resolves the comments that I received during WG Last Call. > > Russ > > > > On Apr 10, 2017, at 12:20 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the CURves, Deprecating and a Little more > Encryption of the IETF. > > > > Title : Use of EdDSA Signatures in the Cryptographic Message > Syntax (CMS) > > Author : Russ Housley > > Filename : draft-ietf-curdle-cms-eddsa-signatures-04.txt > > Pages : 8 > > Date : 2017-04-10 > > > > 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-signature > > s/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-sign > > atures-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatur > > es-04 > > > > > > 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 > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 10 11:29: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 6BCE2129A8F for ; Mon, 10 Apr 2017 11:29:20 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxrKaBBSlQQ7 for ; Mon, 10 Apr 2017 11:29:18 -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 E9B8712951B for ; Mon, 10 Apr 2017 11:29:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 519F6300408 for ; Mon, 10 Apr 2017 14:29:17 -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 XBMIDHGrFpiy for ; Mon, 10 Apr 2017 14:29:15 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D7A94300229; Mon, 10 Apr 2017 14:29:15 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <002801d2b21f$2c44ea90$84cebfb0$@augustcellars.com> Date: Mon, 10 Apr 2017 14:29:15 -0400 Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org, curdle Content-Transfer-Encoding: quoted-printable Message-Id: <0C63B981-D52F-4788-88C0-146C0B04F17A@vigilsec.com> References: <002801d2b21f$2c44ea90$84cebfb0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-03 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, 10 Apr 2017 18:29:20 -0000 Jim: Thanks for your note. I missed these changes. I will not post an = updated draft until you confirm that this is aligned with = draft-ietf-curdle-pkix. > Section 3.2 - This section is wrong. It is using the wrong structure. > idecPublicKey is wrong. I see that this needs to align with Section 3 of draft-ietf-curdle-pkix. By the way, that section should drop the =E2=80=9C(for the four EdDSA = related OIDs)=E2=80=9D since the document now only talks about the pure = EdDSA version. I removed the discussion if id-ecPublicKey and ECParameters. That part = of Section 3.2 in my edit buffer now says: The KeyAgreeRecipientInfo originator provides three alternatives for identifying the originator's public key, and the originatorKey alternative MUST be used. The originatorKey MUST contain an ephemeral key for the originator. The originatorKey algorithm field MUST contain the id-X25519 or the id-X448 object identifier. The originator's ephemeral public key MUST be encoded as an OCTET STRING. The object identifiers for X25519 and X448 have been assigned in [ID.curdle-pkix]. They are repeated below for convenience. When using X25519, the public key contains exactly 32 octets, and the id-X25519 object identifier is used: id-X25519 OBJECT IDENTIFIER ::=3D { 1 3 101 110 } When using X448, the public key contains exactly 56 octets, and the id-X448 object identifier is used: id-X448 OBJECT IDENTIFIER ::=3D { 1 3 101 111 } > These are all nice to haves, but I don't really care if they don't get = done. >=20 > I would prefer that the check of the all-zero output in section 2.0 be = a > SHOULD rather than a MAY. I changed MAY to SHOULD. > Section 2 last paragraph - add network order to the string on = representing > the number Done. It now reads: The ECC-CMS-SharedInfo suppPubInfo field contains the length of the generated key-encryption key, in bits, represented as a 32-bit number in network byte order. For example, the key length for AES-256 [AES] would be 0x00000100. > Section 2.1 - I don't know if you should say that the left most bits = of the > result are used. I know that is correct so I have a problem reading = it any > other way. Done. It now reads: To generate a key-encryption key (KEK), the KDF generates one or more KM blocks, with the counter starting at 0x00000001, and incrementing the counter for each subsequent KM block until enough material has been generated. The 32-bit counter is represented in network byte order. The KM blocks are concatenated left to right, and then the leftmost portion of the result is used as the pairwise key-encryption key, KEK: KM(i) =3D Hash(K || INT32(counter=3Di) || DER(ECC-CMS-SharedInfo)) KEK =3D KM(counter=3D1) || KM(counter=3D2) ... Russ From nobody Mon Apr 10 12:00: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 00F9D129A96 for ; Mon, 10 Apr 2017 11:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 W6rfQycQLzbQ for ; Mon, 10 Apr 2017 11:59:57 -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 B29C7127369 for ; Mon, 10 Apr 2017 11:59:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1DE67300436 for ; Mon, 10 Apr 2017 14:59:57 -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 3UTxIfvnvym0 for ; Mon, 10 Apr 2017 14:59:55 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E106A300229; Mon, 10 Apr 2017 14:59:55 -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: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> Date: Mon, 10 Apr 2017 14:59:55 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03 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, 10 Apr 2017 18:59:59 -0000 Jim: Sorry, I flagged this message in my inbox, and then I missed it when I = made the update earlier today. > Section 3.1 - I would like to have a brief discussion on the integer = value > that is being used with the id-shake256-len OID when it is being used = as a > digest algorithm. The value of 512 means that the signature security = is > going to be the same as is currently setup for Ed25519. To have the = same > dynamic as Ed25519 does, this should be 448*2 so that after birthday = attacks > the same size of value would be provided. RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used. = Reading a bit more carefully, I see that the output is 114 octets or 912 = bits. I suggest that we align with these values. That is: When signing with Ed448, the message digest algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value. and When using the id-shake256-len algorithm identifier, the parameters MUST be present, and the parameter MUST contain 912, encoded as a positive integer value. > Section 4 - I thing that it should also be highlighted that this is a > greater problem for when using the Signed-data without signed = attributes as > the value signed is more constrained in the other case. I suggest: 4. Implementation Considerations The EdDSA specification [EDDSA] includes the following warning. It deserves highlighting, especially when signed-data is used without signed attributes and the content to be signed might be quite large: PureEdDSA requires two passes over the input. Many existing APIs, protocols, and environments assume digital signature algorithms only need one pass over the input, and may have API or bandwidth concerns supporting anything else. Russ From nobody Mon Apr 10 12:09: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 3475E129532 for ; Mon, 10 Apr 2017 12:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 f9Q5g58h9peU for ; Mon, 10 Apr 2017 12:09:35 -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 7FE7B127601 for ; Mon, 10 Apr 2017 12:09:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491851370; h=from:subject:to:date:message-id; bh=WeOWg9Xh1gwBMciPRpdB2H8nklxBliWIWV9LGVLPqnM=; b=g9dRkouSasLLtUb6kaAwHq5r9qbJm+wW01FXpjYNthDtyb0Q8Rlg3L8fDz3Fy7JV56ocw/YcVtz ZjObHt4LS0Np0ZlMWNL4DJqTlW1OKLVGvt9ZOtoV0Dd7vZ679VeJwGST/2pdwc3hda5puf+yXKZY/ J4sV0wuYMi4M/OxnDYjm1aQdNSOv8D6Z/X3z0GAQeQRExUZo0NavPOEJFdOLSI/qlpOrBQu+IaGo8 a5cagRn9xh5Tq3MXynuYpRmOqunXr5YhNWjWo2imoYcNrK1aDNR5sq8o4WUWkef+AnacbkPmiLCpS 4naHS5UFuNJgtEyL2o/dRbSb5GCaKfm9/YBQ== 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; Mon, 10 Apr 2017 12:09:30 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 12:09:28 -0700 From: Jim Schaad To: 'Russ Housley' CC: 'curdle' References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> In-Reply-To: <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> Date: Mon, 10 Apr 2017 12:09:26 -0700 Message-ID: <003e01d2b22d$fa6f8250$ef4e86f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJSzE5P3lUIm/XKUSywOQEvOhZJ9AJrO/vDoKtpBIA= X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03 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, 10 Apr 2017 19:09:38 -0000 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, April 10, 2017 12:00 PM > To: Jim Schaad > Cc: curdle > Subject: Re: Review of draft-ietf-curdle-cms-eddsa-signatures-03 > > Jim: > > Sorry, I flagged this message in my inbox, and then I missed it when I made the > update earlier today. > > > Section 3.1 - I would like to have a brief discussion on the integer > > value that is being used with the id-shake256-len OID when it is being > > used as a digest algorithm. The value of 512 means that the signature > > security is going to be the same as is currently setup for Ed25519. > > To have the same dynamic as Ed25519 does, this should be 448*2 so that > > after birthday attacks the same size of value would be provided. > > RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used. Reading > a bit more carefully, I see that the output is 114 octets or 912 bits. > > I suggest that we align with these values. That is: > > When signing with Ed448, the message digest > algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value. Yes - this is what I wanted to do. This is what Sean was supposed to run past Tanya and the question was "Did the fact that it was SHAKE256 limit the number of bits despite the added output length?" > > and > > When using the id-shake256-len algorithm identifier, the parameters > MUST be present, and the parameter MUST contain 912, encoded as a > positive integer value. > > > Section 4 - I thing that it should also be highlighted that this is a > > greater problem for when using the Signed-data without signed > > attributes as the value signed is more constrained in the other case. > > I suggest: > > 4. Implementation Considerations > > The EdDSA specification [EDDSA] includes the following warning. It > deserves highlighting, especially when signed-data is used without > signed attributes and the content to be signed might be quite large: > > PureEdDSA requires two passes over the input. Many existing APIs, > protocols, and environments assume digital signature algorithms > only need one pass over the input, and may have API or bandwidth > concerns supporting anything else. This looks good. Jim > > Russ From nobody Mon Apr 10 12:21: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 BDA12129A9C for ; Mon, 10 Apr 2017 12:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 z9zXEEGHq784 for ; Mon, 10 Apr 2017 12:21:28 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 71824129A9F for ; Mon, 10 Apr 2017 12:21:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id C41FE1F1E7; Mon, 10 Apr 2017 22:21:25 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id U4Q-2YWKZALE; Mon, 10 Apr 2017 22:21:25 +0300 (EEST) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 77B202313; Mon, 10 Apr 2017 22:21:25 +0300 (EEST) Date: Mon, 10 Apr 2017 22:21:24 +0300 From: Ilari Liusvaara To: Russ Housley Cc: Jim Schaad , curdle Message-ID: <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi> References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03 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, 10 Apr 2017 19:21:33 -0000 On Mon, Apr 10, 2017 at 02:59:55PM -0400, Russ Housley wrote: > Jim: > > Sorry, I flagged this message in my inbox, and then I missed it when I made the update earlier today. > > > Section 3.1 - I would like to have a brief discussion on the integer value > > that is being used with the id-shake256-len OID when it is being used as a > > digest algorithm. The value of 512 means that the signature security is > > going to be the same as is currently setup for Ed25519. To have the same > > dynamic as Ed25519 does, this should be 448*2 so that after birthday attacks > > the same size of value would be provided. > > RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used. Reading > a bit more carefully, I see that the output is 114 octets or 912 bits. Nitpick: Only true of no-prehash versions. The prehash itself uses SHAKE256 with 512-bit input. > I suggest that we align with these values. That is: > > When signing with Ed448, the message digest > algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value. > > and > > When using the id-shake256-len algorithm identifier, the parameters > MUST be present, and the parameter MUST contain 912, encoded as a > positive integer value. The hash algorithm is internal detail of EdDSA, unless you are talking about doing prehashing at "application" level (which certainly a valid approach). On security of using just 512-bit hash there, SHAKE256 does not promise resistance above 2^256 for any attack, which it reaches at 512-bit output (collision resistance being the limiting factor). And the security level of the curve certainly isn't above 2^256. So 512-bit hash should be entierely adequate for application-level prehash (just don't use SHA3-512, it is hilariously slow). -Ilari From nobody Mon Apr 10 12:32: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 A27F6129AD2 for ; Mon, 10 Apr 2017 12:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dmIfeaAjdunU for ; Mon, 10 Apr 2017 12:31:57 -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 8361C129AC4 for ; Mon, 10 Apr 2017 12:31:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E82D130044A for ; Mon, 10 Apr 2017 15:31: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 KhUcfFmug865 for ; Mon, 10 Apr 2017 15:31:50 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 35E48300239; Mon, 10 Apr 2017 15:31:50 -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: <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 10 Apr 2017 15:31:49 -0400 Cc: Jim Schaad , curdle Content-Transfer-Encoding: quoted-printable Message-Id: <183765B4-285D-4920-AF3E-80B0F661CEDF@vigilsec.com> References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03 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, 10 Apr 2017 19:32:00 -0000 Ilari: >>=20 >>> Section 3.1 - I would like to have a brief discussion on the integer = value >>> that is being used with the id-shake256-len OID when it is being = used as a >>> digest algorithm. The value of 512 means that the signature = security is >>> going to be the same as is currently setup for Ed25519. To have the = same >>> dynamic as Ed25519 does, this should be 448*2 so that after birthday = attacks >>> the same size of value would be provided. >>=20 >> RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used. = Reading >> a bit more carefully, I see that the output is 114 octets or 912 = bits. >=20 > Nitpick: Only true of no-prehash versions. The prehash itself uses > SHAKE256 with 512-bit input. >=20 >> I suggest that we align with these values. That is: >>=20 >> When signing with Ed448, the message digest >> algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value. >>=20 >> and >>=20 >> When using the id-shake256-len algorithm identifier, the parameters >> MUST be present, and the parameter MUST contain 912, encoded as a >> positive integer value. >=20 > The hash algorithm is internal detail of EdDSA, unless you are talking > about doing prehashing at "application" level (which certainly a valid > approach). >=20 > On security of using just 512-bit hash there, SHAKE256 does not = promise > resistance above 2^256 for any attack, which it reaches at 512-bit = output > (collision resistance being the limiting factor). And the security > level of the curve certainly isn't above 2^256. >=20 > So 512-bit hash should be entierely adequate for application-level > prehash (just don't use SHA3-512, it is hilariously slow). CMS supports signatures with and without signed attributes. In most = cases, signed attributes are present. When signed attributes are = present, the message-digest attribute MUST be one of the attributes. It = was signed to work like this: IF (signed attributes are absent) THEN md =3D Hash(content) ELSE message-digest attribute =3D Hash(content); md =3D Hash(DER(SignedAttributes)) Sign(md) So, I think you are saying that a 512-bit output was sufficient, which = is what was present in the earlier text: When using the id-shake256-len algorithm identifier, the parameters MUST be present, and the parameter MUST contain 512, encoded as a positive integer value. Russ From nobody Mon Apr 10 12:33: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 0234C129AC6 for ; Mon, 10 Apr 2017 12:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 1EUwqU8ZmcEg for ; Mon, 10 Apr 2017 12:33:38 -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 56A30129AB6 for ; Mon, 10 Apr 2017 12:33:38 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491852814; h=from:subject:to:date:message-id; bh=Ut6sujjhLWiZzSUIGQJzCWJvPOoJgbNmgnVpPpz2c9M=; b=AtQ+sUVUUSo0XSY2djnmpYsZB8TwmIEfXfnYh3nEjAMyuiS2poMBViilantTEjMSRWEeEcHEkWU Ik7OFImklYlxWzeTtVMIcGs1fRTHB2dmdwv4Tc3RuFcw0IClGybN+k6X5k8SGQFpPYy+RPiWOgdGy gBgIxBFZJTUUwYcITXSZ/Hleqo4vyfzeZc48fIl1TaLrimFCseYBUnSIxFwZT5t+SATYmwCIwOHpd cW1oCB3Yt2dXAzRjBtzhTer2TbbLVXhfA6gMo/UvKX1JpDfTMwXohOIEv+L4FYk/cLwbfq1W+jvAv gtJCB6qt+vIncW2lnjmEep3WUjBEHYZ/ZBbQ== 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; Mon, 10 Apr 2017 12:33:34 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 12:33:32 -0700 From: Jim Schaad To: , 'Russ Housley' CC: 'curdle' References: <059e01d2a8a4$270b2370$75216a50$@augustcellars.com> <22ECDDA1-CBDC-406C-B6CB-0B0BA526030F@vigilsec.com> <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170410192123.GA7092@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 10 Apr 2017 12:33:29 -0700 Message-ID: <004401d2b231$5709d710$051d8530$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJSzE5P3lUIm/XKUSywOQEvOhZJ9AJrO/vDAaQSP4ignk7ToA== X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-eddsa-signatures-03 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, 10 Apr 2017 19:33:40 -0000 > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Monday, April 10, 2017 12:21 PM > To: Russ Housley > Cc: Jim Schaad ; curdle > Subject: Re: [Curdle] Review of = draft-ietf-curdle-cms-eddsa-signatures-03 >=20 > On Mon, Apr 10, 2017 at 02:59:55PM -0400, Russ Housley wrote: > > Jim: > > > > Sorry, I flagged this message in my inbox, and then I missed it when = I made > the update earlier today. > > > > > Section 3.1 - I would like to have a brief discussion on the = integer > > > value that is being used with the id-shake256-len OID when it is > > > being used as a digest algorithm. The value of 512 means that the > > > signature security is going to be the same as is currently setup = for > > > Ed25519. To have the same dynamic as Ed25519 does, this should be > > > 448*2 so that after birthday attacks the same size of value would = be > provided. > > > > RFC 8032 uses SHAKE256(x, 114) every place that SHAKE256 is used. > > Reading a bit more carefully, I see that the output is 114 octets or = 912 bits. >=20 > Nitpick: Only true of no-prehash versions. The prehash itself uses > SHAKE256 with 512-bit input. >=20 > > I suggest that we align with these values. That is: > > > > When signing with Ed448, the message digest > > algorithm MUST be SHAKE256 [FIPS202] with a 912-bit output value. > > > > and > > > > When using the id-shake256-len algorithm identifier, the = parameters > > MUST be present, and the parameter MUST contain 912, encoded as a > > positive integer value. >=20 > The hash algorithm is internal detail of EdDSA, unless you are talking = about > doing prehashing at "application" level (which certainly a valid = approach). Yes, this is doing a version of prehashing at the "application" level. = This is feature of CMS where the content is hashed and placed in a = structure which is then signed. =20 >=20 > On security of using just 512-bit hash there, SHAKE256 does not = promise > resistance above 2^256 for any attack, which it reaches at 512-bit = output > (collision resistance being the limiting factor). And the security = level of the > curve certainly isn't above 2^256. >=20 > So 512-bit hash should be entierely adequate for application-level = prehash > (just don't use SHA3-512, it is hilariously slow). Ok - so it would make sense to limit the output to 512-bits for Ed448 = based on what you are saying. No additional security is obtained from = getting a longer output value. Jim >=20 >=20 > -Ilari From nobody Mon Apr 10 16:00:06 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 3EAFC126CD8; Mon, 10 Apr 2017 16:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 QaK9P3WGP6wX; Mon, 10 Apr 2017 16:00:02 -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 B269E12741D; Mon, 10 Apr 2017 16:00:01 -0700 (PDT) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491865196; h=from:subject:to:date:message-id; bh=3ukLQd8AFMZHY9xk3Gb8s6+lmbksmQmE2/9JYuvXR+0=; b=cUY5En45g+eUjElxDsmnrC9kJj9H6JgaL2pg5pbJCjao4P0UFq6d1en4JiKbN8vWz4Fps1CEutl rOlzYfLounTUqSA/bv5+Hfkyu4rGvFWlOfEy8Fv/PrkTmlxcSpJr2BDHqut0Xg6vEMuNtOTqGs6rP tIVzJs9qMyhbcy9CmujDQg7AhyiahDizaShY9WmY+HvYzuyMLwKo2JnDJ2hBPspr/66XRyQxhABE0 Te9r/1L5mzeO3/uFbS3GvriIZwF6PfizT1Gl61gZTgdkAB9F58JX3oO/Iabf3RibI4pYxWiLPSmMq i9UkFSpocDGZsP3k1IcWy0vVkeF90i9rqZIg== 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; Mon, 10 Apr 2017 15:59:56 -0700 Received: from hebrews (192.168.0.98) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 15:59:53 -0700 From: Jim Schaad To: 'Russ Housley' CC: , 'curdle' References: <002801d2b21f$2c44ea90$84cebfb0$@augustcellars.com> <0C63B981-D52F-4788-88C0-146C0B04F17A@vigilsec.com> In-Reply-To: <0C63B981-D52F-4788-88C0-146C0B04F17A@vigilsec.com> Date: Mon, 10 Apr 2017 15:59:52 -0700 Message-ID: <006c01d2b24e$2b89f3a0$829ddae0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFCpeujCUUTmyG6reQdNFg9MYIkTgDVNVwmotimySA= X-Originating-IP: [192.168.0.98] Archived-At: Subject: Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-03 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, 10 Apr 2017 23:00:04 -0000 That looks correct to me. > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Monday, April 10, 2017 11:29 AM > To: Jim Schaad > Cc: draft-ietf-curdle-cms-ecdh-new-curves@ietf.org; curdle > > Subject: Re: [Curdle] Review of = draft-ietf-curdle-cms-ecdh-new-curves-03 >=20 > Jim: >=20 > Thanks for your note. I missed these changes. I will not post an = updated draft > until you confirm that this is aligned with draft-ietf-curdle-pkix. >=20 >=20 > > Section 3.2 - This section is wrong. It is using the wrong = structure. > > idecPublicKey is wrong. >=20 > I see that this needs to align with Section 3 of = draft-ietf-curdle-pkix. >=20 > By the way, that section should drop the =E2=80=9C(for the four EdDSA = related OIDs)=E2=80=9D > since the document now only talks about the pure EdDSA version. >=20 > I removed the discussion if id-ecPublicKey and ECParameters. That = part of > Section 3.2 in my edit buffer now says: >=20 > The KeyAgreeRecipientInfo originator provides three alternatives = for > identifying the originator's public key, and the originatorKey > alternative MUST be used. The originatorKey MUST contain an > ephemeral key for the originator. The originatorKey algorithm = field > MUST contain the id-X25519 or the id-X448 object identifier. The > originator's ephemeral public key MUST be encoded as an OCTET = STRING. >=20 > The object identifiers for X25519 and X448 have been assigned in > [ID.curdle-pkix]. They are repeated below for convenience. >=20 > When using X25519, the public key contains exactly 32 octets, and = the > id-X25519 object identifier is used: >=20 > id-X25519 OBJECT IDENTIFIER ::=3D { 1 3 101 110 } >=20 > When using X448, the public key contains exactly 56 octets, and the > id-X448 object identifier is used: >=20 > id-X448 OBJECT IDENTIFIER ::=3D { 1 3 101 111 } >=20 >=20 > > These are all nice to haves, but I don't really care if they don't = get done. > > > > I would prefer that the check of the all-zero output in section 2.0 = be > > a SHOULD rather than a MAY. >=20 > I changed MAY to SHOULD. >=20 > > Section 2 last paragraph - add network order to the string on > > representing the number >=20 > Done. It now reads: >=20 > The ECC-CMS-SharedInfo suppPubInfo field contains the length of the > generated key-encryption key, in bits, represented as a 32-bit = number > in network byte order. For example, the key length for AES-256 = [AES] > would be 0x00000100. >=20 > > Section 2.1 - I don't know if you should say that the left most bits > > of the result are used. I know that is correct so I have a problem > > reading it any other way. >=20 > Done. It now reads: >=20 > To generate a key-encryption key (KEK), the KDF generates one or = more > KM blocks, with the counter starting at 0x00000001, and = incrementing > the counter for each subsequent KM block until enough material has > been generated. The 32-bit counter is represented in network byte > order. The KM blocks are concatenated left to right, and then the > leftmost portion of the result is used as the pairwise = key-encryption > key, KEK: >=20 > KM(i) =3D Hash(K || INT32(counter=3Di) || = DER(ECC-CMS-SharedInfo)) >=20 > KEK =3D KM(counter=3D1) || KM(counter=3D2) ... >=20 >=20 > Russ From nobody Mon Apr 10 17:11:16 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 17CC4126D05 for ; Mon, 10 Apr 2017 17:11:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF6nns91rSs5 for ; Mon, 10 Apr 2017 17:11:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F0C124C27 for ; Mon, 10 Apr 2017 17:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491869471; x=1523405471; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SY9ouhn8GIsRJ8iMKUfLKX2ozzqfVisDr+IxGluPVWg=; b=hJ8qw0kVCDUXGqvUFGV+pZG41k3QAvCY8x+iMURjqwcG1+K2ESZeOWmn GvJCrIJ5oUA7dT+HDiyGzt2t67LLmA0KuvKdGbF9KP7Oy/B45ealG8N2/ ULJiIPMJwtmmd4BvwcuIXO6h5e4bNW2YdLUjmq1mEp/nVzqCc8sxc0c8a AMWgCPigIlvXtz5l91wzC0GbnaR8IwBEjzj6Oy6XRaK16hqvwKUZ7aMfE wxyV7IwhX5dk58gf3ZVzVdJ6r42qkmd4Iwb9u3Fkr25xNPRZf3wzMsEum Xsm5wyxK+n+OIO5hPieSWxXCOwznMKncW1uw4rSwKNWt8IaFFr3blMs6q A==; X-IronPort-AV: E=Sophos;i="5.37,184,1488798000"; d="scan'208";a="149156528" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Apr 2017 12:11:07 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Apr 2017 12:11:06 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 11 Apr 2017 12:11:06 +1200 From: Peter Gutmann To: denis bider CC: curdle Thread-Topic: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info Thread-Index: AQHSn+vj75AP59wDbUy5ryRiOFPQYKGb4DhQgAWgX4CAA91Jyf//yxWAgBMy0XmAAFvPgIACNyu///+1xACABMuyxg== Date: Tue, 11 Apr 2017 00:11:06 +0000 Message-ID: <1491869463837.53839@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> <1491621835513.71448@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 11 Apr 2017 00:11:14 -0000 denis bider writes:=0A= =0A= >According to the link provided by Eric, Zero-RTT in TLS is a concept that= =0A= >does not even exist in SSH. =0A= =0A= Yeah, as I said, I was reasoning by analogy, that there were concerns in TL= S=0A= about sending data before mutual confirmation of crypto parameters had take= n=0A= place. Obviously SSH isn't TLS, but in this case it would also be sending= =0A= data before the mutual conf. had occurred, i.e. before the other side's=0A= NEWKEYS had been received.=0A= =0A= >As-is, the "no-flow-control" extension already dictates there will be no m= ore=0A= >than one concurrent channel. What do you have in mind beyond that?=0A= =0A= Hmm, but the text around it is a bit confusing, it says "MUST refuse" (=3D = MUST=0A= NOT I assume?) but then immediately follows it with SHOULD allow it, so it= =0A= doesn't really appear to say "only one channel".=0A= =0A= That text really is confusing since it contradicts itself across the two=0A= sentences. What about replacing it with:=0A= =0A= Implementations MUST NOT open more than one simultaneous channel when thi= s=0A= extension is in effect.=0A= =0A= Peter. = From nobody Mon Apr 10 17:26:54 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 8C3671267BB for ; Mon, 10 Apr 2017 17:26:52 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI9Kmbv54H-0 for ; Mon, 10 Apr 2017 17:26:51 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CD5A126D05 for ; Mon, 10 Apr 2017 17:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1491870410; x=1523406410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VSkVMKUEF0nbs9YLCGxmJQf8JQLAEsQKzJHa3oTePSw=; b=fFogdoaA1+Wq8jueEL79Gclx83mpukQjrtAVEPYWAWu+DhWR2NSwfSvm qWTOBeTiL0k1PMSzhubohiyUVT0WyKT6pSgU0E6e+ysIWSNi2keo8D+FO IQecsdOHBvv9xDyY0kMdPv/n97zh7B3NCYvDPpLZ8L2G9SuAzn3atLWiN yrRsWeKedt1tmlunPJOXgocKBYZUbGbjlIa3cG844PCfD8UspDxXolB3L 9K0lA5QKqsFtxmwwrF8NWEmn/lXYbY2s5Z28nfhelSDHQKaG5wOxY/L7W QqCI/KfTXwaLBod2E+Uab4vgbwUsWRGvGKtWkDWb8QtxLjpzNQ7wbkXnP Q==; X-IronPort-AV: E=Sophos;i="5.37,184,1488798000"; d="scan'208";a="149160061" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-b.UoA.auckland.ac.nz) ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Apr 2017 12:26:49 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Apr 2017 12:26:48 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 11 Apr 2017 12:26:48 +1200 From: Peter Gutmann To: denis bider CC: curdle Thread-Topic: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info Thread-Index: AQHSn+vj75AP59wDbUy5ryRiOFPQYKGb4DhQgAWgX4CAA91Jyf//yxWAgBMy0XmAAFvPgIACNyu///+1xACABMuyxoAABHtW Date: Tue, 11 Apr 2017 00:26:48 +0000 Message-ID: <1491870405713.23156@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> <1491621835513.71448@cs.auckland.ac.nz>, , <1491869463837.53839@cs.auckland.ac.nz> In-Reply-To: <1491869463837.53839@cs.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 11 Apr 2017 00:26:52 -0000 Peter Gutmann writes:=0A= =0A= > Implementations MUST NOT open more than one simultaneous channel when th= is=0A= > extension is in effect.=0A= =0A= Following up to this, I'm not sure that no-flow-control would restrict you = to=0A= only using one channel. You can still multiplex several channels onto the = SSH=0A= link without flow control, you just get n non-flow-controlled channels inst= ead=0A= of one.=0A= =0A= Peter.=0A= From nobody Mon Apr 10 19:03:27 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 BA1A8127241; Mon, 10 Apr 2017 19:03:26 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149187620672.15689.17592587285879785538@ietfa.amsl.com> Date: Mon, 10 Apr 2017 19:03:26 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-04.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, 11 Apr 2017 02:03:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of 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-04.txt Pages : 16 Date : 2017-04-10 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-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curves-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curves-04 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 Apr 10 19:05: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 E8BBA128CB9 for ; Mon, 10 Apr 2017 19:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Z878e7XdgQku for ; Mon, 10 Apr 2017 19:05:03 -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 2EFE8127241 for ; Mon, 10 Apr 2017 19:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 80F0430043A for ; Mon, 10 Apr 2017 22:05:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SP438j4lqbsB for ; Mon, 10 Apr 2017 22:05:01 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 535C5300239 for ; Mon, 10 Apr 2017 22:05:01 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 10 Apr 2017 22:05:02 -0400 References: <149187620672.15689.17592587285879785538@ietfa.amsl.com> To: curdle In-Reply-To: <149187620672.15689.17592587285879785538@ietfa.amsl.com> Message-Id: <0EDD261B-97FB-4AD9-896B-F254AD88E7D9@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-04.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, 11 Apr 2017 02:05:06 -0000 This resolves the concerns that Jim Schaad raised. Russ > On Apr 10, 2017, at 10:03 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > 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-04.txt > Pages : 16 > Date : 2017-04-10 >=20 > 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). >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-ecdh-new-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-ecdh-new-curves-04 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-curve= s-04 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-ecdh-new-curves-= 04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 10 20:20: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 B8AD9128B8F for ; Mon, 10 Apr 2017 20:20:28 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IlfLUO3vkJqi for ; Mon, 10 Apr 2017 20:20:25 -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 98062128B38 for ; Mon, 10 Apr 2017 20:20:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491880819; h=from:subject:to:date:message-id; bh=pDvge3FOteIXZNnvjJYKb7oxzewvuwqN0CDuosQYU3A=; b=E1uLrBLLtbGSpzYdAEZur34FrhmtyHDP4b+HR6Z8g+IbMXJbqhQ/+vIMpi3SWHBDYyz97MD4HkD v4XC03EucxSJe/TedzuaALL8cR5MKmrAzbLYj4LBwFcnm0UY9NXLY3PIgcUJAgq4n8wEzsWikCM3s dkiwxBGM5dHiurk3F4QMUzMaWlkJi2C0bd9KD8DGMLB7Bbqes9Yu8d53yp9Yvx/99dVMwOaju9MQk yDTloxoTSpLlMhWtgOUNV3FXfO2CA/aJPA/C6T7U+hc+fNDgC7zM/gb5ZAUTu7FkswzhWBCYtsLGv IO+ooBW5MG7QhdNj9SR5qPLhzhYnDGgr4rqA== 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; Mon, 10 Apr 2017 20:20:19 -0700 Received: from hebrews (24.21.96.37) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 10 Apr 2017 20:20:18 -0700 From: Jim Schaad To: 'Russ Housley' , 'curdle' References: <149187620672.15689.17592587285879785538@ietfa.amsl.com> <0EDD261B-97FB-4AD9-896B-F254AD88E7D9@vigilsec.com> In-Reply-To: <0EDD261B-97FB-4AD9-896B-F254AD88E7D9@vigilsec.com> Date: Mon, 10 Apr 2017 20:20:17 -0700 Message-ID: <007b01d2b272$8c9cae20$a5d60a60$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGXryKLNX9c5bbbgzMiTqyjqcBPOwDnslkGoi5IxwA= X-Originating-IP: [24.21.96.37] Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-04.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, 11 Apr 2017 03:20:28 -0000 This does resolve all of my current open issues. I should get another bite at the apple to re-validate the ASN.1 module and check the encodings in section 8 when the OIDs are assigned by IANA. (I am one of the experts on the registry.) Jim > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley > Sent: Monday, April 10, 2017 7:05 PM > To: curdle > Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-ecdh-new-curves-04.txt > > This resolves the concerns that Jim Schaad raised. > > Russ > > > > On Apr 10, 2017, at 10:03 PM, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the CURves, Deprecating and a Little more > Encryption 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-04.txt > > Pages : 16 > > Date : 2017-04-10 > > > > 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-04 > > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-ecdh-new-c > > urves-04 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-ecdh-new-curve > > s-04 > > > > > > 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 > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 10 22:39: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 2F719126DFB for ; Mon, 10 Apr 2017 22:39:10 -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 DJD1xCsTCYVA for ; Mon, 10 Apr 2017 22:39:08 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 68154127275 for ; Mon, 10 Apr 2017 22:39:08 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id h67so131427086qke.0 for ; Mon, 10 Apr 2017 22:39:08 -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=UJV7D+/bcZylkWNotb0yPWzduatQivFY7X1vgI0ml2M=; b=eeCS6x1x1kfo8J0sjmSpWtYvWAryUWyf1DF6nQtHeZttyPjw9qLQPP7yznf2g8YglV RUa8ovQfnEbF78V/1RTOJ1g3GcWDcx042taGzhhcLCxierEN2g9UtgoXYkJJo9rvRCwj RVditB/c8nq0OEGoM1g7ybBaAkTKBbfzMLWPnMucp20VIxg290Q6TUpTmuFIVT4RwxwI Ztoi4KfK8LVt6K/FBF/nytkOTsC+4CDmdK0VJ7H10LbBEh6h88vsQhjMO8jUVgx0jmna wUsDb93j0kNL4th88a8t5m7F3yAZtjjQW6LdaE2d7X5ISzpu/pHn/FDDDHE+D2yas1tx HF4g== 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=UJV7D+/bcZylkWNotb0yPWzduatQivFY7X1vgI0ml2M=; b=EW7hPGl3L2/MZe2gTUAH29DZ+QTj+aPseuNOsESD7djO+ggrJmZMjQ6Sppbqbq3b/Q IgCPvqYsWLBR4cxqBDMKbs/6si08CHsdxzGW7hNLexH4X0Xen4XQuR/HaaSSCaDec2VZ JJVkn+eEinjWxmjl8wxakQTf5LDP1816TwslM22/4J6osOWMemOsfVI2wvJ93kFCDpAv cm380b/IoCRsDVIAZ9CvHYlHsk9JnKhFqONZwzxmFtjDfqDaUwffJHeqV4RtHa+CIdDN tXC9UApQ39zuWb93L7DTGnF50Gs6PyY8FmkOfHMo9hwYZCJMpNAv+4k10yvwS9h94Pg2 V/Qw== X-Gm-Message-State: AN3rC/5PkW4R5PzflZ9Lf3g60B/BSlHCYv2Fjux3McsrxAc+pUjRyNc4/ZWEX1Nz5DYpGT5BKr83drzGOEzKjg== X-Received: by 10.55.77.79 with SMTP id a76mr4800172qkb.296.1491889147637; Mon, 10 Apr 2017 22:39:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Mon, 10 Apr 2017 22:39:07 -0700 (PDT) In-Reply-To: <1491869463837.53839@cs.auckland.ac.nz> References: <2DD56D786E600F45AC6BDE7DA4E8A8C118BA5A70@eusaamb107.ericsson.se> <1489827654266.43895@cs.auckland.ac.nz> <50977E6A3D174856B8DAF264C3CB81E8@Khan> <1489914378158.63423@cs.auckland.ac.nz> <74B4C5B2AFD644748A0E1B0957A22C96@Khan> <1490436136828.60577@cs.auckland.ac.nz> <76BA84F1D47F476A8DB5C8CC42AA1B57@Khan> <1491480250094.74577@cs.auckland.ac.nz> <1491621835513.71448@cs.auckland.ac.nz> <1491869463837.53839@cs.auckland.ac.nz> From: denis bider Date: Mon, 10 Apr 2017 23:39:07 -0600 Message-ID: To: Peter Gutmann Cc: curdle Content-Type: multipart/alternative; boundary=001a114a69ccb07748054cdd8284 Archived-At: Subject: Re: [Curdle] Comments on draft-ietf-curdle-ssh-ext-info 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, 11 Apr 2017 05:39:10 -0000 --001a114a69ccb07748054cdd8284 Content-Type: text/plain; charset=UTF-8 > Yeah, as I said, I was reasoning by analogy [...] At this time, I'm mentally filing this under "probable misinterpretation". I don't think this warrants further attention. > Hmm, but the text around it is a bit confusing, it says "MUST > refuse" (= MUST NOT I assume?) but then immediately follows > it with SHOULD allow it, so it doesn't really appear to say > "only one channel". The text right now is: Implementations MUST refuse to open more than one simultaneous channel when this extension is in effect. Nevertheless, server implementations SHOULD support clients opening more than one non-simultaneous channel. This seems to me unambiguous: - There MUST NOT be more than one concurrent channel in a session with "no-flow-control" enabled. - There MAY be any number of consecutive (non-simultaneous) channels. Do you propose some way to make it clearer than this? > Following up to this, I'm not sure that no-flow-control would > restrict you to only using one channel. You can still multiplex > several channels onto the SSH link without flow control, > you just get n non-flow-controlled channels instead of one. Allowing this provides the receiver with no option to pause reception on one channel without blocking the entire connection. This introduces additional complexity for any implementation that properly implements flow control, which would prefer to use the SSH flow control mechanism in this circumstance, but has to implement special measures to block the entire connection if one channel backs up. "no-flow-control" is intended for simple use cases. For multiplexing channels, we have a better solution, it is to implement flow control. denis On Mon, Apr 10, 2017 at 6:11 PM, Peter Gutmann wrote: > denis bider writes: > > >According to the link provided by Eric, Zero-RTT in TLS is a concept that > >does not even exist in SSH. > > Yeah, as I said, I was reasoning by analogy, that there were concerns in > TLS > about sending data before mutual confirmation of crypto parameters had > taken > place. Obviously SSH isn't TLS, but in this case it would also be sending > data before the mutual conf. had occurred, i.e. before the other side's > NEWKEYS had been received. > > >As-is, the "no-flow-control" extension already dictates there will be no > more > >than one concurrent channel. What do you have in mind beyond that? > > Hmm, but the text around it is a bit confusing, it says "MUST refuse" (= > MUST > NOT I assume?) but then immediately follows it with SHOULD allow it, so it > doesn't really appear to say "only one channel". > > That text really is confusing since it contradicts itself across the two > sentences. What about replacing it with: > > Implementations MUST NOT open more than one simultaneous channel when > this > extension is in effect. > > Peter. --001a114a69ccb07748054cdd8284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Yeah, as I said= , I was reasoning by analogy [...]

At this time, I&= #39;m mentally filing this under "probable misinterpretation".

I don't think this warrants further attenti= on.

<= br>
>=C2=A0Hmm, but the text around it is a bit confusing= , it says "MUST
>= refuse" (=3D MUST=C2=A0NOT I = assume?) but then immediately follows
> it with SHOULD allow it, so it=C2=A0doesn't really appear to say
> "only one channel".
<= div>
The text right now is:

=C2= =A0 Implementations MUST refuse to open more than one simultaneous channel<= /div>
=C2=A0 when this extension is in effect. Nevertheless, server imp= lementations
=C2=A0 SHOULD support clients opening more than one = non-simultaneous channel.

This seems to me unambiguous:

- There MUST NOT be more than one concurrent channel in a session wi= th "no-flow-control" enabled.

- The= re MAY be any number of consecutive (non-simultaneous) channels.

Do you = propose some way to make it clearer than this?

>=C2=A0Following up to this= , I'm not sure that no-flow-control would
> restrict you to=C2=A0only using one channel.=C2=A0 You can still multiplex
> several channels onto the SS= H=C2=A0link without flow control,= =C2=A0
> you just get = n non-flow-controlled channels instead=C2=A0of one.

Allowing this provides the receiv= er with no option to pause reception on one channel without blocking the en= tire connection. This introduces additional complexity for any implementati= on that properly implements flow control, which would prefer to use the SSH= flow control mechanism in this circumstance, but has to implement special = measures to block the entire connection if one channel backs up.

"no-flow-control" is intended for simple us= e cases. For multiplexing channels, we have a better solution, it is to imp= lement flow control.

=
denis
<= span style=3D"font-size:12.8px">


On Mon, Apr 10, 2017 at 6:11 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bider <denisbider.ietf@gmail.com> writes:

>According to the link provided by Eric, Zero-RTT in TLS is a concept th= at
>does not even exist in SSH.

Yeah, as I said, I was reasoning by analogy, that there were concern= s in TLS
about sending data before mutual confirmation of crypto parameters had take= n
place.=C2=A0 Obviously SSH isn't TLS, but in this case it would also be= sending
data before the mutual conf. had occurred, i.e. before the other side's=
NEWKEYS had been received.

>As-is, the "no-flow-control" extension already dictates there= will be no more
>than one concurrent channel. What do you have in mind beyond that?

Hmm, but the text around it is a bit confusing, it says "MUST r= efuse" (=3D MUST
NOT I assume?) but then immediately follows it with SHOULD allow it, so it<= br> doesn't really appear to say "only one channel".

That text really is confusing since it contradicts itself across the two sentences.=C2=A0 What about replacing it with:

=C2=A0 Implementations MUST NOT open more than one simultaneous channel whe= n this
=C2=A0 extension is in effect.

Peter.=C2=A0 =C2=A0

--001a114a69ccb07748054cdd8284-- From nobody Tue Apr 11 13:42: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 C576C129AC5 for ; Tue, 11 Apr 2017 13:42:27 -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 nYPJLDWF5VTm for ; Tue, 11 Apr 2017 13:42:26 -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 69A3C129A9F for ; Tue, 11 Apr 2017 13:42:25 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id t144so4571831lff.1 for ; Tue, 11 Apr 2017 13:42:25 -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=+z+WgfQbK4oLLGo/N/u/Vj0Lc3ibl46/wBFQtIsgX3A=; b=pZI8gNBIOMAvMtV6ZjBUsX9bnleO1f99aWQx5WwaTTlDDNeoiiQB/Yp7DkA8I73H7d CFGLzS++kLbzKheB1YxmqFfCBAIWqiOl8rxx1aaHQnl9grhOlyhqiQEf24OGqX8YWw+P LP95GWFsG4IBudF3hUp4/Q4AYoVOQZ4eQY3wJpG9NC3cL6khnwCkAA3Kjjb6bt1JmQwS wG0kVhfkwtfeCptqgTxcuF7BcUcyJTT8HtpK/o7B7UA+PNRokhVo8UhtZesJ/1nBhw9J //jYevJQOfs6VWxD+UsXIz13qUJJ5p5EBK+CQUwKxaNxx/tayLqhbjI8b+DsDxehyUd+ lY1A== 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=+z+WgfQbK4oLLGo/N/u/Vj0Lc3ibl46/wBFQtIsgX3A=; b=SwJLJ9qlpi/EcrAuwQbMv18WPjhhCxYBGrR0zC/nruBQcNe6kbyz5pgc/kEZUrD7Ys 8W1+8Q7gHN/MIKcuQgq+AzC9SPAIXplBv3fR8LPDmVfun37NnPmny525Ju6YWXoxMMMR YcM5qHbmmNJRH3JFEeOJin72l+PLhU2wNEThUubxQnBSc/4+1cHpo8q/5Z18zwTeA5GZ gV8P78MlLdWblsHcIxCPYdUxr/D6Dw0uAtSi9veYWrwcfkeEICNuJdAt016/jLChqWvg IM/U7+ZRYnqvUaQNCATKVn6rIl2/Hjwf67MwNCYnaq18SweNI8sLjXnu/DBKmixp+JPE j/DA== X-Gm-Message-State: AFeK/H0sN2WduM8TDMa72skZZG4ywN2YfrwHWBQoY8jtEzMk6wxLAw2ORD0BqP0SJkiNJyPQVrxiN2ryxKehsw== X-Received: by 10.25.79.15 with SMTP id d15mr17469519lfb.14.1491943343476; Tue, 11 Apr 2017 13:42:23 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Tue, 11 Apr 2017 13:42:22 -0700 (PDT) From: Daniel Migault Date: Tue, 11 Apr 2017 16:42:22 -0400 X-Google-Sender-Auth: QuY6eaCXB8ZRPhckb81zFPf_y_4 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=94eb2c1cd69a035522054cea21b3 Archived-At: Subject: [Curdle] draft-ietf-curdle-ssh-curves-01 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, 11 Apr 2017 20:42:28 -0000 --94eb2c1cd69a035522054cea21b3 Content-Type: text/plain; charset=UTF-8 Hi, Please find my comments on the current version of the draft. These are mostly nits, and I think we can move that draft forward. Yours, Daniel Abstract How to implement the Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol is described. MGLT: This document describes the conventions for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. 1. Introduction In [Curve25519], a new elliptic curve function for use in cryptographic applications was introduced. In [Ed448-Goldilocks] the Ed448-Goldilocks curve (also known as Curve448) is described. In [RFC7748], the Diffie-Hellman functions using Curve25519 and Curve448 are specified. MGLT: I think we shoudl rephrase the text above or remove it. --94eb2c1cd69a035522054cea21b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find my comments on the curr= ent version of the draft. These are mostly nits, and I think we can move th= at draft forward.

Yours,

Daniel

Abstract

=C2= =A0=C2=A0 How to implement the Curve25519 and Curve448 key exchange methods= in
=C2=A0=C2=A0 the Secure Shell (SSH) protocol is described.

MG= LT:

This document describes the conventions for using Curve25519 an= d Curve448 key exchange methods in the Secure Shell (SSH) protocol.
=C2= =A0=C2=A0

1.=C2=A0 Introduction

=C2=A0=C2=A0 In [Curve25519]= , a new elliptic curve function for use in
=C2=A0=C2=A0 cryptographic ap= plications was introduced.=C2=A0 In [Ed448-Goldilocks] the
=C2=A0=C2=A0 = Ed448-Goldilocks curve (also known as Curve448) is described.=C2=A0 In
= =C2=A0=C2=A0 [RFC7748], the Diffie-Hellman functions using Curve25519 and C= urve448
=C2=A0=C2=A0 are specified.

MGLT: I think we shoudl rephr= ase the text above or remove it.




--94eb2c1cd69a035522054cea21b3-- From nobody Tue Apr 11 14:36:28 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 1BADB129A91; Tue, 11 Apr 2017 14:36:26 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149194658605.15649.2604886928756796432@ietfa.amsl.com> Date: Tue, 11 Apr 2017 14:36:26 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-05.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, 11 Apr 2017 21:36:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-curdle-cms-eddsa-signatures-05.txt Pages : 8 Date : 2017-04-11 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatures-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatures-05 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 Apr 11 14:40: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 2CEF6129AC5 for ; Tue, 11 Apr 2017 14:40:09 -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 Ws2v6xLkNgk0 for ; Tue, 11 Apr 2017 14:40:06 -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 450B71200C5 for ; Tue, 11 Apr 2017 14:40:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9CD8A30044A for ; Tue, 11 Apr 2017 17:40:05 -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 KPTrB_-nAmXE for ; Tue, 11 Apr 2017 17:40:04 -0400 (EDT) Received: from new-host-7.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 2F5B230041B for ; Tue, 11 Apr 2017 17:40:04 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 11 Apr 2017 17:40:03 -0400 References: <149194658605.15649.2604886928756796432@ietfa.amsl.com> To: curdle In-Reply-To: <149194658605.15649.2604886928756796432@ietfa.amsl.com> Message-Id: <1FCC8833-BC65-4B48-BC07-B5E0256E3519@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-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: Tue, 11 Apr 2017 21:40:09 -0000 I believe that this resolves the issues that were raised by Jim Schaad = yesterday. When Ed448 is used, the SHAKE256 output remains a 512 bits based on the = information provided by Ilari Liusvaara. Russ > On Apr 11, 2017, at 5:36 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Use of EdDSA Signatures in the Cryptographic = Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-05.txt > Pages : 8 > Date : 2017-04-11 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-curdle-cms-eddsa-signatures/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-05 > = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-signatur= es-05 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-cms-eddsa-signatures= -05 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 From nobody Tue Apr 11 15:08: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 3A484129AC6 for ; Tue, 11 Apr 2017 15:08:24 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hfPILVIFDxJ8 for ; Tue, 11 Apr 2017 15:08:22 -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 C8C1B12947E for ; Tue, 11 Apr 2017 15:08:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1491948489; h=from:subject:to:date:message-id; bh=sC+gTzrywoF4CYopmMV5825/fRRuIYPbIQ64AsTCfTg=; b=fnJyoUeOsoqBMQv0AOe5dK3VeNFl1rLk9LHxuamoivvI4jhsscNE6Q0vpSxmdMH8S/ldZOc8lk9 FliizSwqgwZqEfJlzFK9t5PlOp6qm7ez+QFRFstboSe/xuyxbyX9EepbpGqOoE+MSfgb0Mw0a7tXb wHkWWkhg5BqMOk1b3Rls9kqSa9Is1Qc4VWP8JYMnfzM2q13V+dNgQ1fJY1BMqnPM0axmvUXa7bvQs blyHG8K6XDNYFc4EzX7rzyq0CIUQx8Z90bYj5smra6EJ/hSUlkGvOri4EIStS7QjzaXKVkc7vLMUo TE0GrFeYrGZ90iFAAhUtOuuHB7Dvay0u3X5g== 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; Tue, 11 Apr 2017 15:08:08 -0700 Received: from Hebrews (192.168.1.157) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 11 Apr 2017 15:08:09 -0700 From: Jim Schaad To: 'Russ Housley' , 'curdle' References: <149194658605.15649.2604886928756796432@ietfa.amsl.com> <1FCC8833-BC65-4B48-BC07-B5E0256E3519@vigilsec.com> In-Reply-To: <1FCC8833-BC65-4B48-BC07-B5E0256E3519@vigilsec.com> Date: Tue, 11 Apr 2017 14:58:04 -0700 Message-ID: <000401d2b30e$b3947250$1abd56f0$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGLowbtQRPR+9jqFEVmfqdyot2hwwHlxImGoj+owtA= X-Originating-IP: [192.168.1.157] Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-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: Tue, 11 Apr 2017 22:08:24 -0000 I agree that this addressed the issued that I raised. -----Original Message----- From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Russ Housley Sent: Tuesday, April 11, 2017 2:40 PM To: curdle Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-cms-eddsa-signatures-05.txt I believe that this resolves the issues that were raised by Jim Schaad yesterday. When Ed448 is used, the SHAKE256 output remains a 512 bits based on the information provided by Ilari Liusvaara. Russ > On Apr 11, 2017, at 5:36 PM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. > > Title : Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-curdle-cms-eddsa-signatures-05.txt > Pages : 8 > Date : 2017-04-11 > > 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-signature > s/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-cms-eddsa-signatures-05 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-cms-eddsa-sign > atures-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-cms-eddsa-signatur > es-05 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Tue Apr 11 16:36: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 437541286B1 for ; Tue, 11 Apr 2017 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn0SdCtEq0H1 for ; Tue, 11 Apr 2017 16:36:26 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0119.outbound.protection.outlook.com [104.47.38.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EB6126C83 for ; Tue, 11 Apr 2017 16:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Bqw7UG88s1ks5f1NUHLU/E9luAl+Z/lpc16FCIGb884=; b=OOCOMY4+dxRaKOr3UqM+uDEyk8HwymyrqMZXnwBRf/uaKdJAOApAG3Ns1PNCR3YYE7wYBItyOk0wJgoN2ePa5uKsGJFQQJTYJSnjONUz4h2c3TyFLjiCMdivdBMjBmR/C8i+sndT1DtgVwPE4Tv65IqL0hdNK76Lz+9LK3IJP5M= Received: from SN1PR0501CA0025.namprd05.prod.outlook.com (10.163.126.163) by BY2PR05MB1912.namprd05.prod.outlook.com (10.163.32.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Tue, 11 Apr 2017 23:36:22 +0000 Received: from BY2NAM05FT022.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by SN1PR0501CA0025.outlook.office365.com (2a01:111:e400:52fe::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5 via Frontend Transport; Tue, 11 Apr 2017 23:36:22 +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 BY2NAM05FT022.mail.protection.outlook.com (10.152.100.159) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1005.5 via Frontend Transport; Tue, 11 Apr 2017 23:36:20 +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; Tue, 11 Apr 2017 16:36:18 -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 v3BNaIVA016132; Tue, 11 Apr 2017 16:36:18 -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 9BEF011454; Tue, 11 Apr 2017 16:36:17 -0700 (PDT) To: Daniel Migault CC: curdle In-Reply-To: References: Comments: In-reply-to: Daniel Migault message dated "Tue, 11 Apr 2017 16:42:22 -0400." From: "Mark D. Baushke" Date: Tue, 11 Apr 2017 16:36:17 -0700 Message-ID: <90219.1491953777@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)(39400400002)(39850400002)(39450400003)(39410400002)(39860400002)(39840400002)(2980300002)(199003)(189002)(9170700003)(77096006)(5003940100001)(2950100002)(6392003)(6916009)(7696004)(7846003)(48376002)(8676002)(38730400002)(50466002)(8936002)(189998001)(4326008)(47776003)(81166006)(110136004)(55016002)(2810700001)(86362001)(5660300001)(2906002)(53936002)(6266002)(106466001)(305945005)(105596002)(229853002)(6246003)(356003)(53416004)(76506005)(230783001)(117636001)(50986999)(54356999)(7126002)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB1912; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT022; 1:PyNPvbW1qDngLtnTmCVCT39FJrwR/2pXggGlJpNIqx9RXkZr76dSSGVqQEuN1XLUkXgYVeRCUs8rOHukHZ58lFfVfA+lA8ztz2LxRrdqOUxOW9/1X3Esy4qv3ECVSApvlSStUg+0hIh9JrAM+qi3TkbsozhHK7WwgK/gvWSl04rtodX3wVEsLC/P9557s8icOiYu08OwcKvhemdxHktD+HLyAlhxUuQmYQbHskpC3sBN/fTN25aBXyV3VctVpR476HINEDdx6HN24ni71oCFkSSIUOs89SWW2eY7EIZkBw4oYxha/B6ZReyItMHEgQs0PUjEKf7qcImdNE31ACWtnMtQOOMmro3lA8bwU4s3KvffY7Yn5OjZaoCCNpT2tjn5cdGxTN65Lf2+VQGJK/MFt5CfhfAkH+s9ziRnZCIC4O2yGL3JD2MJUduMVJ6COzT2hYcHwW1M/AdsK/7hQlQGMfLaVZFUmScPUS5DrcjQNXOJnOtFaNnR0tUb4qQgC0BQuqrXTLeC/My1bNjkqVWJyqv1jZYyONHx+gP6G1X1YZPG80Dy+SFRWItHEkhcX77LYmUPZigwjYxR6IjF4u21Dw== X-MS-Office365-Filtering-Correlation-Id: e6c94172-a643-439a-3b79-08d481338f3b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BY2PR05MB1912; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1912; 3:5HSA6+ObdIdfSyyGAzBCJaIcdDR8JxuqHe3QUTRfR8vWQ6mOmKrzaWNAMHbBn+rcqv8CBbIvqAnRsHV2CAeWjZl2qRv7nSOfzKAM6DSAkIA05NAyz/UF8O9736iJDaqD9Xorg93iHSiStQgHLrnINmouHmXqRbq9UuwwPer5H+Y/0Qx7g0VL0bzaQVoYP2Ig7kL6p6a/2qJwwhxBrE4EQTWXvL7GscLmDdLcjKH+fzWSjWKH2+LttOw2Cz0624cgRZeo1MHds17NTxB0K2n4jlCXyJbRtlGu8Vm5ADmfhC6T7DsuMX5tMf7dDuBauoznqDIh2O6U93j1tjJwm33e5tTQksm+omIDgGeiEV3MC1POq5Et0QzhSv5zzax5k+4D25hcECYb/O32BAO5hFkx1ZINFXzlozk9GDqqiBPfX3KcIm1bTaJJrxqI7y2hJYt4/01ctSDIW+kHdCWgAQ81cA==; 25:Tir9awebcJuGgMoTnDdILFWGI1kJNSo84QFr2cxrI7x1qEy+dIC5gPsfsg7Fw6Q6bQywTsUfqE6HqtHokeWzxu/REbr5bz6K9FjzfIT0pxXBficqTejO2RcSJKxF6gPCLD+T0B2CwwuYh4LQOQBkUCQ6FA8Dh0kDwJBsCZCmOl3w1qFops6NEWY1/niWQ/eRPe+BgSfjfpNHn7/pcc1RM61Hq/EsKaw7Ai1FpS95tZKBU7uqpp+rCJ3s0xhd5yoRkGhvgK2/hhl4KKW89mYswIy/dQhuAO/CnO9AAcaCZNfOqpfni5e5wiiCCPliGrVMr0YQIMHGL3V769lItnPb3+MroEUgt5E+ukFIYgniU2VBepHERjYrUX01Jh7oQpDGxhq7xgmp3GRbfm8bCqpUGjOf//sXo/fD+3ShHukSlgjd9yzRzq5mg/5bBrK9TK269Wt8vrZQHun4Jpxz7XW9ig== X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1912; 31:Q8hE8DAOrW2v2aZcfSv6TuIbygO4KlircvgyGiGIDWt1ARXQB9BhSFunZOzI7t/N6SOakoPVp4C9aUcbRWIWU2SR5oGrYH9L+APNPv6dQIYBdobOo1VMMj3vrQUtxuf7bUkyDhShMD0H9yIv92HilwLuuhHUBQpoEMSlCIcGaG1knJStJRm4tAnWQDNrxeN3LvyRy10wQpS/sOclyRxK61lISREevGsFQf7KBg63Gbhch0e78bb/Ki8MwUYJxSTaA4NnhqScXub7zp/t8rQCVw==; 20:Dwe/1IrluBqwS8NyfZ+EsWExJIZ1VZGZm4aIFKK/VE1G6pGjFpLa/002bz4aB2aYBbZpK2vBc56ucj5swIqLE1XDPyxMCvsQNpv8SKQb5grHeqyZWh9QcaP65EwfBA7AUgwbT9Q+tzs+PHlIDThgTF5G6pvamaE3eHL6PXWeaQGOfTh28QyDwRsY8Eev0kB1Pfh09fpCFd6jRpgm2+NXgOSKW0fjZ7i60o1ojv6nZrejwH2OX/kOFN0mcMeHxG1zF097GQR2vS5mAsf7K+MBKwin6bh9GLdyrbujJuPpVb8TQ5Fc12FUUCS3zZ9kEgg4sZLt/XoaKt7iDyIQa//tSKqUsV5ZRdroece3Jrn4jdwKo8ym5mt1t17v68HCUb2IKwKBi5o2ulikuO+LOc7WCjQGK79IahL5DXJwHhS2l/jekI18b9U1Ip4ymyYJJmVuLHOj7D1wqSuymOHK8F1pCKWLEJNMdqPktziYQ4y0wG6TxtnBiGemIxKzQd4KZPxd X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13015025)(8121501046)(5005006)(13017025)(13018025)(13024025)(13023025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(6072148); SRVR:BY2PR05MB1912; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB1912; X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1912; 4:O4O+QaeB/t8TCo8euyx0VRaLPJr8DX/KXjTrHDxE3P3O1TjpJJMDMVXabKmqmg47XYWK4YLv1s/DqZNGi8zrvb734kra2++pD3KdljWvmiqYgVr8k3qxSk+2WK9vSHWigPo2s3IXSNrn+eq8LmyedNgyIdDnSRnfgxqXQGOYF8XRWjpvO+5RvzRJhyHjUsvkmbajlLLTmA2AWfkw3AYue48FbtwLX3d7zPb5WuB14czzUCW1G6g6a+WGLtwDZ9Bfr9nn0o7UNNW5z0xQbtAkQe2BkC+GGZHPHmx2xIfPFrwbv1xsjwVWCLbd5ewHTbtfGXSB2Xp5xTgR+cFbLOamn32qMHlgEjUw3A0jQPbtJ3MvOXD1V9q21GlelBf0YH2hbBB5b4FM1Wg7dCP58A6DVLU94rEqLebmJvXPCV1IapsdtlYPmLGsQt/EzrbaLELnHNdB4tFLf34WJGqBhOnexRvuTHshVQErt+JiaK7tKpN7cAPDb/O0vW4FpMgvrMI8aCKmv/Kbraii3c+jrOha1a8jb8e/mq6XMX4ySmHndgGsw1VT3X04swFf1RRA5Px5I2Q72wCuxOpMmH2eQS6VbOjCS37RPj1r5JjRqeVRXZhH9mlcTI4h+k4gNdpBSYoyzWaZlkbhH4xJf7rpiulUU2saVKvDJAGLBvCaG8Vq39TLX5kPiXnn1EQxdkcB0zPuDfYruvlZR/d3SuaoRTooOzVe2T2g1K3wK/aZGAjAFt82F7jTSYliH5/E8IZTrWS7/E58lro4byev3Y2rmvCMaNdN3pmab4sgeNFFXkhsBu8DgnydJX5hiGB0fWpUr7quda7HKfj0xiau8f9mQLs2383ezB5LGG1Hao0HgyKcGzPuOkmqEuNba1lVohvEGw6hVL6aX7E6drBwfBlX4FFeYIVwe1AuNjfECuVETdQB5Qf15gzxxr1Z0zuql9XkcdLx X-Forefront-PRVS: 0274272F87 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY2PR05MB1912; 23:q92buatLjP3p5SUi+lKUsH8n9iaYka+OFj8cZ3TTQ?= =?us-ascii?Q?xCc7SBvshixExrsBo/EY4uinvdFBIJqfxjZZyd4ilVf3NbLGSaBwrbyjHcT8?= =?us-ascii?Q?ZVsS2vCcJdOSR5VBhIeSmNSDd+avj1eB9r5Hm6gxi/J3VAK0d8rpTBIV3NQT?= =?us-ascii?Q?nEVmKbIt8Qd/BBTIX8+jFabHQG+Yn0msS3b/3FR3zKEiyEM8VEsfahJGQi8/?= =?us-ascii?Q?43nLqX5e9QVxiGnef85DnhcdUAXWPUDDodaLRnxe91uTWC/LV+jf85jyU7N+?= =?us-ascii?Q?sjTgEwGJNrWNJUMFDXn3NCtjptPrsTMNTudfAQ2auccwdFpMa5wuseqXm8li?= =?us-ascii?Q?UaynPl22ruuYZiZL2kLZLdGCapdEu6M5j+C7rAr+D1jQU7uoFlRj7tFx57Hf?= =?us-ascii?Q?cJAs2nMR7WTqAyNTCZBGjSK87Vuz/tLWdjCzqBoVsjGjapWd3Smg2CQ9/0MI?= =?us-ascii?Q?6FyidIeF5rFrrg/VZLv+GrL5QRI2jGIjvxo9vmDMmU0R05T0QT1GspLwIJs5?= =?us-ascii?Q?P5U4oIvwsdQOw0mbJHzaTRNie+MJLLeMrNDitVAN8DSkFNnaqku1kVnWRqnu?= =?us-ascii?Q?YvV8f44KJqlUCaBwfIAlrVN7+ektZUOt4CubCgAlVow2FtyvBYcK7amvVDTf?= =?us-ascii?Q?CnoKkTlRxTtgHUuVEJa9S5EZPzATPPcRVPkeX2FHhTJEB6BHP7i2pgJSif2u?= =?us-ascii?Q?p/LvuWkzIhD2ACnm30D869BG5zpYdl2HNFZWoYG7YB9RT4y9jkY+Rkzs2xqQ?= =?us-ascii?Q?9O3KENWcr59iSz/JlXwPBgjQhtgDSFQOWTZ3lFg18rZu4k10uX0mDzbP9TgE?= =?us-ascii?Q?nvSn4uHHuw1Cke6HizyPPwEHK0keBfe4pp0GQe0OcjO85qp4R0FfzlUhS09D?= =?us-ascii?Q?lxY3pAfT1TbFArfVvXnIffE9qpCEsuUPTkpspGEDr1+LfYdy94S1TsYZynKI?= =?us-ascii?Q?Ckow/rNDfZ3zSadUBSE3qvLqMsG0SPxMFItMtL80XJvOz6XqfcpgH7i1sbaS?= =?us-ascii?Q?U8PTcFN/52mzI8jCYz5E+xMmi7Ycj4oTR3y4XvgemKaF4QnAUBAp8wvPnOCp?= =?us-ascii?Q?7h9pcGzDhRiUhpqILV0Xba2lqtojlRhWPcq2vEtuUaVwJBbbugxMyzF0dRzy?= =?us-ascii?Q?CtOPmLg/ZV9jZaTuGywjRZ1fk05ccUzEQPr2/OarmtRdGw4xY4lYl2w5rArA?= =?us-ascii?Q?u0ZL1xI7i1PVV0YhsG4PtkeEnvd5IR3MV8J6vQq/ORVE+ObLq9MfxtCbA=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1912; 6:UQqOK4KHZAmC/ttDHsGBmwMcOR75QDOV8T3CqNZM8A+Bf3sKt0LSLr0qRCoi/HtONS41YaJMsNBb1xMJxSAYJMywShhR0FmgBmo9qAKluBoAJzM0v6VnGnnEVvPl0QB0lj8hJlnC8el2eaQWJNTPq4DkuvvVSDwRcTvo3A11qKLGA7rxmbTEH5zGooOHHMZYGb3SkMrAdhbQQ13v6Y3E9Onz4vC/lgNvQMUjONqZbHV06TXQReWkxGgihIpvgGNfmZT6ONekpOkHqXN2kTiFBSFoBqnVGFq1tMz2FiRrC4GG0xRsB40YkP+3QBDmvqWQx28Ykr+e9i+1XUovQA5jLNxhe+eQBfzMx9M4KBJNN5C6SqOyC8fNRiYnkAgQ9mb53fnvxyZpjcNTLT80wf31anI0r41TQJQJpynvGPhDgBN5dpCIMokZWi32AFEtXcFWq+QlVPCuJkux7JikuFM3fNH38g/reyarcGC6rTNZxbc=; 5:Ue4hwv+fGsH8HWIBrgtMKf8pYsUBng6HgvGufuPKJtGPCiPUHXnDjXr87AUekzD26q+SiMxXhEz0uBQk5kxe+WsGYmS9tW3R1so/RYF47XHJX0QXG2hVMqhr/0C8YHXZSILxN0EI448JPNd7PZ3icA==; 24:VIKMRVtVwACtoYlvv/kx49/ydW4+jXHTY6R6ziXZNHI15icxobKJjD/ZtUlN4xSY4D/RqwTU6smAFyJ6Gq3v0DfJhJtOF4xLE3mw6c8erg0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR05MB1912; 7:r4nUiPZXYrl4EwTt5TDc1/U7TAmG2mvpqOcbGZYByq6LOnBLBVfoySSFNXI04DdMh2zksJQ4xfAEjRLpc3p05u+/oETcr9EuqFOOiNvUx73wFpH4jzBbemA3KMwyN08ZmIYAkExkZ03Ud//kwX1PudNO1Ru95pZ0DR/xHG2RqvGT4hS6t/IUxfbXiOSf3njJtNXni9w9rTXVN7JhhWgvXRkDiDf5gFX3H2pDVwPLZiyIXqVnF1P8sCI9T7c5YjIyvLDJHKvMB6BKyQ/vJi+g/1OPMPahZBcxtQFRhTKZFoYPBXzRLLlLpY5ua39dagHLUxaZ2k+LSJLL/Tm4RmVBYw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2017 23:36:20.3970 (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: BY2PR05MB1912 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-curves-01 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, 11 Apr 2017 23:36:29 -0000 Daniel Migault writes: > Please find my comments on the current version of the draft. These are > mostly nits, and I think we can move that draft forward. > > Yours, > > Daniel > > Abstract > > How to implement the Curve25519 and Curve448 key exchange methods in > the Secure Shell (SSH) protocol is described. > > MGLT: > > This document describes the conventions for using Curve25519 and Curve448 > key exchange methods in the Secure Shell (SSH) protocol. MDB: Change adopted. > 1. Introduction > > In [Curve25519], a new elliptic curve function for use in > cryptographic applications was introduced. In [Ed448-Goldilocks] the > Ed448-Goldilocks curve (also known as Curve448) is described. In > [RFC7748], the Diffie-Hellman functions using Curve25519 and Curve448 > are specified. > > MGLT: I think we shoudl rephrase the text above or remove it. MDB: Removing the paragraph seems okay to me. The references to RFC7748 and the [Curve25519] and [Ed488-Goldilocks] will be moved into the next place they are referenced. I will also change the draft from "info" to "std" category per your previous private message. Are there any other suggested change before I publish the -02 revision? -- Mark From nobody Tue Apr 11 18:33:55 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 ADA0C12426E for ; Tue, 11 Apr 2017 18:33:54 -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 qmH0VErIJESQ for ; Tue, 11 Apr 2017 18:33:53 -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 487BE120326 for ; Tue, 11 Apr 2017 18:33:53 -0700 (PDT) X-AuditID: c6180641-417ff700000058cf-07-58ed3da44b38 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by (Symantec Mail Security) with SMTP id 4E.6E.22735.4AD3DE85; Tue, 11 Apr 2017 22:33:42 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0339.000; Tue, 11 Apr 2017 21:33:49 -0400 From: Daniel Migault To: "mdb@juniper.net" CC: curdle Thread-Topic: [Curdle] draft-ietf-curdle-ssh-curves-01 Thread-Index: AQHSsxxyfO+CoEb0eUWNml5TE3LzYaHA81+g Date: Wed, 12 Apr 2017 01:33:49 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118BCA00C@eusaamb107.ericsson.se> References: <90219.1491953777@eng-mail01.juniper.net> In-Reply-To: <90219.1491953777@eng-mail01.juniper.net> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPlO4y27cRBt+PW1lsXTiL2aLrznU2 ByaPJUt+Mnlcb7rKHsAUxWWTkpqTWZZapG+XwJUx91Mre8FTnopzX3awNzAu5upi5OSQEDCR +D1xE3MXIxeHkMAGRoljM6ayQzjLGSV+zP/IAlLFJmAk0Xaonx3EFhFQl1i67gSYzSwgI9H2 8xMTiC0sYCaxYd9ZRogac4lFj2ewQNhGEv39/8FqWARUJY7svgZm8wr4Sjy6MQGsRkigRuLE on9gMzmB5qzdsgcsziggJvH91BomiF3iEreezGeCuFpAYsme88wQtqjEy8f/WCFsJYmPv+dD 3aYjsWD3JzYIW1ti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjBylxQU5uelG hpsYgfFwTILNcQfj3l7PQ4wCHIxKPLwKK99ECLEmlhVX5h5ilOBgVhLhbXF5GyHEm5JYWZVa lB9fVJqTWnyIUZqDRUmc9135hQghgfTEktTs1NSC1CKYLBMHp1QDYxKHD990nZmZ/3sOBe7m 33emx+PXy8apy08nbUx3CZZj4joWff1GsaVeW2Nn8NJfffNd+IREeqNOv3mdctHj8kcTgf52 f6NrZzdHeG9fVK46waXxYWPRjnOFMkwPKxgOnL3659BUGbGdwZ8Y3Fk/78jPsAw6vlb1mRjD KwFP3uZFb6+bbJ4Tp8RSnJFoqMVcVJwIAIjQDuaDAgAA Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-curves-01 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, 12 Apr 2017 01:33:55 -0000 Looks fine to me.=20 Yours,=20 Daniel -----Original Message----- From: mdb@juniper.net [mailto:mdb@juniper.net]=20 Sent: Tuesday, April 11, 2017 7:36 PM To: Daniel Migault Cc: curdle Subject: Re: [Curdle] draft-ietf-curdle-ssh-curves-01=20 Daniel Migault writes: > Please find my comments on the current version of the draft. These are=20 > mostly nits, and I think we can move that draft forward. >=20 > Yours, >=20 > Daniel >=20 > Abstract >=20 > How to implement the Curve25519 and Curve448 key exchange methods in > the Secure Shell (SSH) protocol is described. >=20 > MGLT: >=20 > This document describes the conventions for using Curve25519 and=20 > Curve448 key exchange methods in the Secure Shell (SSH) protocol. MDB: Change adopted. > 1. Introduction >=20 > In [Curve25519], a new elliptic curve function for use in > cryptographic applications was introduced. In [Ed448-Goldilocks] the > Ed448-Goldilocks curve (also known as Curve448) is described. In > [RFC7748], the Diffie-Hellman functions using Curve25519 and Curve448 > are specified. >=20 > MGLT: I think we shoudl rephrase the text above or remove it. MDB: Removing the paragraph seems okay to me. The references to RFC7748 and= the [Curve25519] and [Ed488-Goldilocks] will be moved into the next place = they are referenced. I will also change the draft from "info" to "std" category per your previou= s private message. Are there any other suggested change before I publish the -02 revision? -- Mark From nobody Wed Apr 12 08:37:21 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 CD7A6129C36 for ; Wed, 12 Apr 2017 08:37:20 -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 q6Fj7IrrQsKm for ; Wed, 12 Apr 2017 08:37:18 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 79C84129C46 for ; Wed, 12 Apr 2017 08:37:17 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id s141so16364480lfe.3 for ; Wed, 12 Apr 2017 08:37:17 -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=Hu10rXT0nBkGSftvttVIcMCpmSHHov/s+Uk3kWgRkNc=; b=Kr1DAMK2qOBfirFjcSOADXAr0W0DU4tDlRKjy5kSjw7PtCnLJEcrxLU8qqPPvdkJjT uO2sJ4l9p7HHRTl8Xsc459GsDzY8cByU0NynqjJO9M7qsuuuHrOYC+uvQSXH9uswHP7s qmMekxKFve9zC866Kws4uYyxwQv7iWfovpmL1U5E4Zm6iIS0avpOfrhsCGVUhwSwjTK4 qftra5F7SjjGSw96KHqgr5ZBCyQE9LP829TKfEaodlEOqgCOGW/HwcHxGLJjZqZrQ9ib Eb5hs8aBrAdfT817zaN4FBcr2nEJ82LAetkBGgPJ9y3BxPKebqcpKpfJ9pTjtQ8PXhy0 czew== 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=Hu10rXT0nBkGSftvttVIcMCpmSHHov/s+Uk3kWgRkNc=; b=Edaw7sY3K75d1rsqXj2DHPyPCj3Go0TZjgYvz68dHpdJvCPPRdF8lXQj8seHX7pGvi Pq71TB3ommsnQJ8kyw3fSdZRVpVobO4TdTQbBqw/T0xjv3yIZFpSb8VDIHMFBXXKxSES ObXK8FLGKm6xn1n89iOfwcFI4ZYIAQXd3CtntPMuHW6HWt7mc5BZ0H9oLG7Ecau2YLZq ZipLhXl1jNauUzwRGgp+hlEWDbD5xrNaSuVVhcyBh6uCZ08f7MOuK+K3Ue1SJT57Qaom 265lMznKZXnTBGh6k9gYgGUKa/DBbmVhQs+cn9aRm0UMmrr0TLPYPO3+V9Qq40MYYJ4i yTJA== X-Gm-Message-State: AN3rC/4heWcg4jAQLAlmf0ep1EK+l4yyu0+tzOgjpyWzCEx/FFWg202JgDIpb+T5TUJUipx3ijvsbSED8wBT1w== X-Received: by 10.25.199.145 with SMTP id x139mr5990692lff.102.1492011435840; Wed, 12 Apr 2017 08:37:15 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Wed, 12 Apr 2017 08:37:14 -0700 (PDT) In-Reply-To: References: <30381.1490720068@eng-mail01.juniper.net> <6ab576118c6945f4ba888dd403cf2471@usma1ex-dag1mb1.msg.corp.akamai.com> <1490766071333.6018@cs.auckland.ac.nz> <57287.1490768257@eng-mail01.juniper.net> <1490771481840.11723@cs.auckland.ac.nz> <22747.56331.274710.114550@fireball.acr.fi> <1490844151663.13492@cs.auckland.ac.nz> <22749.17194.509999.470077@fireball.acr.fi> <1491481241400.6079@cs.auckland.ac.nz> <1491622618430.28210@cs.auckland.ac.nz> From: Daniel Migault Date: Wed, 12 Apr 2017 11:37:14 -0400 X-Google-Sender-Auth: gelQjCY5kutgQe5UCcLXbLFQ018 Message-ID: To: denis bider Cc: Peter Gutmann , "Salz, Rich" , curdle , "Mark D. Baushke" , Tero Kivinen Content-Type: multipart/alternative; boundary=94eb2c1a1732a259b8054cf9fb7a Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-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: Wed, 12 Apr 2017 15:37:21 -0000 --94eb2c1a1732a259b8054cf9fb7a Content-Type: text/plain; charset=UTF-8 Hi, Would we have any consensus considering IKE group for this draft and leave random alternatives for the future ? Yours, Daniel On Sat, Apr 8, 2017 at 7:13 AM, denis bider wrote: > This rides entirely on the assumption that if a widely known large DH > group is broken, the break will be just feasible enough to be doable, and > just difficult enough that repeating it two or three times is outside the > budget. > > This is an extraordinarily contrived set of circumstances, which is > probably not true even now for 1024-bit groups. > > Note that the argument you cite is for "one million different kinds of > crypto", not "two or three different kinds of crypto". One million is 20 > additional bits. > > This is a solid argument for dynamically generated groups, which seem to > me a problem worth solving (i.e. provide a way the other party can be sure > the group is good). But it does not appear to be a particularly strong > argument in favor of different fixed groups in SSH vs. e.g. IKE. > > > On Fri, Apr 7, 2017 at 9:37 PM, Peter Gutmann > wrote: > >> denis bider writes: >> >> >I agree with Tero in this case. Having four keys instead of one adds 2 >> bits >> >of security. If one of those keys is broken, the others are most likely >> too. >> >> I've already responded to this when someone else made the same erroneous >> claim, this only holds if you can solve the DLP for (say) a 2048-bit >> parameter >> set in constant time. Unless you have a mechanism for mapping a solution >> for >> any given 2048-bit DLP to every other 2048-bit DLP in O( 1 ) time, that >> claim >> is fallacious. >> >> (Or perhaps disingenious, if you're aware of, but have omitted to mention, >> that each bit of security represents 10,000 years of supercomputer time, >> or >> whatever it takes to solve a 2048-bit DLP). >> >> There's a great analysis of security by diversification by "Daniel" from >> Bruce >> Schneier's blog, in the discussion of the Kalnya block cipher: >> >> The issue of efficiency vs security works both ways. Let me draw on an >> example from the law. Currently, in the USA, it is well recognized that >> more >> than 90% of all criminal cases end with a plea bargain. Further, it is >> recognized that the system has become financially dependent on this >> reality. >> The consequence being is that if everyone stopped pleading guilty and >> instead went to trial the entire system would freeze because there is no >> manpower or funding to try all the case, not even 25% of them. >> >> So same situation is true for crypto. Anyone who rolls their own crypto >> is >> at one level a fool because anyone can make a standard they themselves >> cannot break. Yet imagine if the world of hurt the NSA would be in if >> it had >> to confront one million different kinds of crypto. Each one individually >> might be trivial to break but collectively they would freeze the agency. >> There simply isn't the manpower or the funding to go through a million >> cases >> and break each individually. >> >> So there is a strong argument that with crypto standards, whether they >> be >> set by NIST or the Ukrainian government, makes individuals stronger >> while >> making the collective weaker whereas if everyone rolled their own the >> individual cyphers would be weaker but the collective would be stronger. >> >> Peter. > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c1a1732a259b8054cf9fb7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Would we have any consens= us considering IKE group for this draft and leave random alternatives for t= he future ?

Yours,
Daniel

On Sat, Apr 8, 2017 at 7:13 AM, d= enis bider <denisbider.ietf@gmail.com> wrote:
This rides entirely on the ass= umption that if a widely known large DH group is broken, the break will be = just feasible enough to be doable, and just difficult enough that repeating= it two or three times is outside the budget.

This is an= extraordinarily contrived set of circumstances, which is probably not true= even now for 1024-bit groups.

Note that the argum= ent you cite is for "one million different kinds of crypto", not = "two or three different kinds of crypto". One million is 20 addit= ional bits.

This is a solid argument for dynamical= ly generated groups, which seem to me a problem worth solving (i.e. provide= a way the other party can be sure the group is good). But it does not appe= ar to be a particularly strong argument in favor of different fixed groups = in SSH vs. e.g. IKE.


On Fri, Apr 7, 2017 at 9:37 PM, Pe= ter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
denis bider <denisbider.ietf@gmail.com> wr= ites:

>I agree with Tero in this case. Having four keys instead of one adds 2 = bits
>of security. If one of those keys is broken, the others are most likely= too.

I've already responded to this when someone else made the same e= rroneous
claim, this only holds if you can solve the DLP for (say) a 2048-bit parame= ter
set in constant time.=C2=A0 Unless you have a mechanism for mapping a solut= ion for
any given 2048-bit DLP to every other 2048-bit DLP in O( 1 ) time, that cla= im
is fallacious.

(Or perhaps disingenious, if you're aware of, but have omitted to menti= on,
that each bit of security represents 10,000 years of supercomputer time, or=
whatever it takes to solve a 2048-bit DLP).

There's a great analysis of security by diversification by "Daniel= " from Bruce
Schneier's blog, in the discussion of the Kalnya block cipher:

=C2=A0 The issue of efficiency vs security works both ways. Let me draw on = an
=C2=A0 example from the law. Currently, in the USA, it is well recognized t= hat more
=C2=A0 than 90% of all criminal cases end with a plea bargain. Further, it = is
=C2=A0 recognized that the system has become financially dependent on this = reality.
=C2=A0 The consequence being is that if everyone stopped pleading guilty an= d
=C2=A0 instead went to trial the entire system would freeze because there i= s no
=C2=A0 manpower or funding to try all the case, not even 25% of them.

=C2=A0 So same situation is true for crypto. Anyone who rolls their own cry= pto is
=C2=A0 at one level a fool because anyone can make a standard they themselv= es
=C2=A0 cannot break. Yet imagine if the world of hurt the NSA would be in i= f it had
=C2=A0 to confront one million different kinds of crypto. Each one individu= ally
=C2=A0 might be trivial to break but collectively they would freeze the age= ncy.
=C2=A0 There simply isn't the manpower or the funding to go through a m= illion cases
=C2=A0 and break each individually.

=C2=A0 So there is a strong argument that with crypto standards, whether th= ey be
=C2=A0 set by NIST or the Ukrainian government, makes individuals stronger = while
=C2=A0 making the collective weaker whereas if everyone rolled their own th= e
=C2=A0 individual cyphers would be weaker but the collective would be stron= ger.

Peter.


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

--94eb2c1a1732a259b8054cf9fb7a-- From nobody Wed Apr 12 08:40:44 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 4737712E957; Wed, 12 Apr 2017 08:40: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 kgwUdloDR-wc; Wed, 12 Apr 2017 08:40:41 -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 7C72A129C71; Wed, 12 Apr 2017 08:40:41 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id s141so16417759lfe.3; Wed, 12 Apr 2017 08:40:41 -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:cc; bh=uwF42ZfgPNOz8JdoXrgSeopiDKavXJVAWcOvfeY5j3Y=; b=EElLzoQmssAeUkiLDJKrTzDczKeqCi6IkdsmWpskJv0QF5aTS3D0oOryXSqYr4Vm5Q OnGDkAJ/kkUUCxVJ9zgOo1v32K6YcFt6YWFJT9mUx5gZyHS9HlRsWwEmNTEpKazm1eU0 e6ACNEOcQe0BJ+O/nUxda6Apq3v+g60y1xIizV/aiCRuz0r03Z/SG9kKqvUyPHImqp8B xmOCkY6weQDkCqQwaY/xHz5RikjSlapo5rZuEoy3MAnpMwm3By4hEzjqdeh7JPKBk4hS yZ7IUWFVqFwgujqzFDrRx03HzxZhFjsT8n8G6KGEU5CZf+Oqx6WEwYuhbaa/A+Urk7ME baow== 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:cc; bh=uwF42ZfgPNOz8JdoXrgSeopiDKavXJVAWcOvfeY5j3Y=; b=BZAUnxe+msvNb+a7KgqVXUca8M9YswELsduuv0tzmzMmSkxw1wwhK8e/9xBvnvR7fk Cm40E7rfcv3tzCik3zTf8EoywmV8JY5EFtf1ME/aBMA2IR3wPfNWXgYZFy88Ba3Bp2m4 oZ1BiExR0DnVhIi90FoUbZqNJjBw+mfarX+USTmN99dIXvXuEHf0cWwZMd6WaG0PsUxq VRplCDpisjJ0N3V6QPmf++Lg/4FFG7ghjjtknC26xUN0LrRo0kOGS1cjSFwdfo8fuh6J hrpwEjHX+hI10WDsd0RDkT/Pcd5xLWLdUHfHVVqAyWuvN0fUKLmp9W9ScPKOnPM4WJRW PnQQ== X-Gm-Message-State: AN3rC/4mhTE1EnKiisBrBklOfDGg9ENk3SyE8dHkeZIGy82rtF6CA6/uy7isHFd7kGUYxF7TVl40/AqDaf3Big== X-Received: by 10.25.199.145 with SMTP id x139mr5997163lff.102.1492011639676; Wed, 12 Apr 2017 08:40:39 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Wed, 12 Apr 2017 08:40:39 -0700 (PDT) From: Daniel Migault Date: Wed, 12 Apr 2017 11:40:39 -0400 X-Google-Sender-Auth: iM0S5OUj30AQl3JE2kf22WGOC3M Message-ID: To: curdle Cc: curdle-chairs Content-Type: multipart/alternative; boundary=94eb2c1a1732c8a635054cfa0746 Archived-At: Subject: [Curdle] Call for adoption 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, 12 Apr 2017 15:40:43 -0000 --94eb2c1a1732c8a635054cfa0746 Content-Type: text/plain; charset=UTF-8 Hi, This mail starts a call for adoption for the two following drafts. If you have any opinion, please raise it by April 26. - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des- die-die-die-01 Yours, Daniel --94eb2c1a1732c8a635054cfa0746 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This mail starts a call f= or adoption for the two following drafts. If you have any opinion, please r= aise it by April 26.

=C2=A0=C2=A0=C2=A0 - https://www.ietf.org/id/draft-ssorce-= gss-keyex-sha2-00.txt
=C2=A0=C2=A0=C2=A0 - https://tools.ietf.org/html/draft-kaduk-= kitten-des-des-des-die-die-die-01

Yours,
Daniel
--94eb2c1a1732c8a635054cfa0746-- From nobody Wed Apr 12 08: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 A1B7112EAA1 for ; Wed, 12 Apr 2017 08:54:44 -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, HTML_MESSAGE=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 U4F_-IxdzA4Z for ; Wed, 12 Apr 2017 08:54:42 -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 C2554131739 for ; Wed, 12 Apr 2017 08:54:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1393330050A for ; Wed, 12 Apr 2017 11:54:42 -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 YcXMDXhIYAgL for ; Wed, 12 Apr 2017 11:54:40 -0400 (EDT) Received: from new-host-2.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 545A03002D0; Wed, 12 Apr 2017 11:54:40 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_92287A78-56E0-433F-AD86-D65C95D6E371" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 11:54:38 -0400 In-Reply-To: Cc: curdle , curdle-chairs To: Daniel Migault References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Call for adoption 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, 12 Apr 2017 15:54:45 -0000 --Apple-Mail=_92287A78-56E0-433F-AD86-D65C95D6E371 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Wouldn=E2=80=99t it be more appropriate for these documents to go = through the KITTEN WG? Their charter = (https://datatracker.ietf.org/wg/kitten/about/ = ) covers GSS-API and = Kerberos. That said, if the Area Director would rather this work come through the = CURDLE WG, I can live with it. Russ > On Apr 12, 2017, at 11:40 AM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > This mail starts a call for adoption for the two following drafts. If = you have any opinion, please raise it by April 26.=20 >=20 > - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt = > - = https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 = >=20 > Yours,=20 > Daniel --Apple-Mail=_92287A78-56E0-433F-AD86-D65C95D6E371 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Wouldn=E2=80=99t it be more appropriate for these documents = to go through the KITTEN WG?  Their charter (https://datatracker.ietf.org/wg/kitten/about/) covers = GSS-API and Kerberos.

That said, if the Area Director would rather this work come = through the CURDLE WG, I can live with it.

Russ


On Apr 12, 2017, at 11:40 AM, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

This mail starts a call for adoption for = the two following drafts. If you have any opinion, please raise it by = April 26.

    - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt
    - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01

Yours, =
Daniel
<= /html>= --Apple-Mail=_92287A78-56E0-433F-AD86-D65C95D6E371-- From nobody Wed Apr 12 10:39:43 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 EA20C1317B4; Wed, 12 Apr 2017 10:39:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149201878194.15734.9473036239996423617@ietfa.amsl.com> Date: Wed, 12 Apr 2017 10:39:41 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-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: Wed, 12 Apr 2017 17:39:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 Authors : Aris Adamantiadis Simon Josefsson Mark D. Baushke Filename : draft-ietf-curdle-ssh-curves-02.txt Pages : 6 Date : 2017-04-12 Abstract: This document describes the conventions for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-02 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-curves-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 Wed Apr 12 12:04:59 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 23D5412955B; Wed, 12 Apr 2017 12:04:58 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149202389811.15670.12152466574283340303@ietfa.amsl.com> Date: Wed, 12 Apr 2017 12:04:58 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-03.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: Wed, 12 Apr 2017 19:04:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 Authors : Aris Adamantiadis Simon Josefsson Mark D. Baushke Filename : draft-ietf-curdle-ssh-curves-03.txt Pages : 6 Date : 2017-04-12 Abstract: This document describes the conventions for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-03 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-curves-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 12 12:08:08 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 39D87129687 for ; Wed, 12 Apr 2017 12:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5CXQ9emURUB for ; Wed, 12 Apr 2017 12:08:04 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C69C12EB3A for ; Wed, 12 Apr 2017 12:08:03 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id v3so29998559qtd.3 for ; Wed, 12 Apr 2017 12:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Hn7597JU5yVPtRlQgCillcUfydTgJ7wFz4Yunim1DGQ=; b=DC4jaNLTAxpflZMVvlaEZ+8xjf1C50ndxPHWufLpbfB2J9Un3E0qSrfNoxq61FtFJ/ hgexGEAhIyM5sa2p0k1hcqHQCg7Ed5Qh7/1rryC4w9RB5pJZ/LAqbng2EWrtpsJN5NoU RUQx+atMFdH/8KzBcy8gLWN3eN4FdNUc8GHI4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Hn7597JU5yVPtRlQgCillcUfydTgJ7wFz4Yunim1DGQ=; b=jaNQmsXrgkNAQXfIWU6L3b6EHNbPyltMGbZ+teMikUJT6gRa0uJK+FxkdKSKzXHB9X uYO0+1Xgh6qDggu78L/gUoesyZDPTbxtExdMbzP7noCCFSinUZRAuTp+lxnnbSjfbuO+ exN1Xul9z/NUORwd2eIEYsDZpCWzA7gjXCECgVDzC0U32JlcmsNDb0+eUzhBMC3RxWI4 +gaz6FsvUG9SmEdaMxD5+n0brHn3D6k0HalBwv2AV/o7ODg5ll/dVuIG8Ku/OvLvPxMe 31Sq80kD8fhLt77vdHvDo5KXzAQCO5XIaRJH4DIthVrzAayIiFMXGvmkf3zA+F3xUUB8 /pdw== X-Gm-Message-State: AFeK/H1jktd9fRCWJlAmyesZ4gBO95WucSDh4XrCOtd4mMKrPTIKFVTxTmV8kFMj5Ly3yg== X-Received: by 10.237.51.5 with SMTP id u5mr71079581qtd.247.1492024082157; Wed, 12 Apr 2017 12:08:02 -0700 (PDT) Received: from [172.16.0.18] ([96.231.229.219]) by smtp.gmail.com with ESMTPSA id 94sm14074575qte.37.2017.04.12.12.08.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 12:08:01 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 12 Apr 2017 15:08:00 -0400 References: <149202389811.15670.12152466574283340303@ietfa.amsl.com> To: curdle In-Reply-To: <149202389811.15670.12152466574283340303@ietfa.amsl.com> Message-Id: <9B820EFB-2EEF-437E-9EA5-6D6D0606A0A9@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-03.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: Wed, 12 Apr 2017 19:08:06 -0000 Should this be referring to RFC7748 for curves 25519 and 448? spt > On Apr 12, 2017, at 15:04, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the CURves, Deprecating and a Little more = Encryption of the IETF. >=20 > Title : Secure Shell (SSH) Key Exchange Method using = Curve25519 and Curve448 > Authors : Aris Adamantiadis > Simon Josefsson > Mark D. Baushke > Filename : draft-ietf-curdle-ssh-curves-03.txt > Pages : 6 > Date : 2017-04-12 >=20 > Abstract: > This document describes the conventions for using Curve25519 and > Curve448 key exchange methods in the Secure Shell (SSH) protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-03 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-03 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-ssh-curves-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Wed Apr 12 13:47:17 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 7DE1412EB38; Wed, 12 Apr 2017 13:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaHPdGKRwXNI; Wed, 12 Apr 2017 13:47:14 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958E0129AD7; Wed, 12 Apr 2017 13:47:14 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5C917AEB6; Wed, 12 Apr 2017 20:47:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C5C917AEB6 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C5C917AEB6 Received: from ovpn-116-177.phx2.redhat.com (ovpn-116-177.phx2.redhat.com [10.3.116.177]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3B7D6171E8; Wed, 12 Apr 2017 20:47:13 +0000 (UTC) Message-ID: <1492030032.3662.174.camel@redhat.com> From: Simo Sorce To: Russ Housley Cc: Daniel Migault , curdle , curdle-chairs Date: Wed, 12 Apr 2017 16:47:12 -0400 In-Reply-To: References: Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 12 Apr 2017 20:47:14 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Call for adoption 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, 12 Apr 2017 20:47:17 -0000 On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote: > Wouldn’t it be more appropriate for these documents to go through the > KITTEN WG? Their charter > (https://datatracker.ietf.org/wg/kitten/about/ > ) covers GSS-API and > Kerberos. Mi draft is strictly related to other drafts[*] in this WG that are defining transition from SHA-1 to SHA-2 for SSH key exchange. It seemed like this WG is most appropriate to review that draft to me. I guess I should have added "SSH" somewhere in the title to make it clear. Simo. [*] https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2 > That said, if the Area Director would rather this work come through > the CURDLE WG, I can live with it. > > Russ > > > > On Apr 12, 2017, at 11:40 AM, Daniel Migault wrote: > > > > Hi, > > > > This mail starts a call for adoption for the two following drafts. If you have any opinion, please raise it by April 26. > > > > - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt > > - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 > > > > Yours, > > Daniel > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Wed Apr 12 14:14: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 9131E129AE3 for ; Wed, 12 Apr 2017 14:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohqMnBOFWwN7 for ; Wed, 12 Apr 2017 14:14:05 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0101.outbound.protection.outlook.com [104.47.40.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530E6129ACD for ; Wed, 12 Apr 2017 14:14:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4zFAOAXY2k9HrdekX2oIx9ImOyE+JqRvhyAo9MMmLyA=; b=Z/S88qNgPDYxlAcDZR/msZVFWPr8B+ULLttnnjzKH2yXNiWFrDNppSQ6NAeDYirzzX7TgRJva8MxiBjK4oBN8B0hmhdcql3XskZ4fzoEtyJN6g0OQmA/aDH0eecr2KakX9iLzKC9hrtVeLjmDGnd5Z1mvfs/YBAxbndrngCWc9Y= Received: from MWHPR05CA0024.namprd05.prod.outlook.com (10.168.242.162) by DM2PR05MB542.namprd05.prod.outlook.com (10.141.100.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1019.8; Wed, 12 Apr 2017 21:14:03 +0000 Received: from BY2NAM05FT009.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::202) by MWHPR05CA0024.outlook.office365.com (2603:10b6:300:59::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Wed, 12 Apr 2017 21:14:03 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 BY2NAM05FT009.mail.protection.outlook.com (10.152.100.146) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Wed, 12 Apr 2017 21:14:03 +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, 12 Apr 2017 14:14:02 -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 v3CLE1HV002145; Wed, 12 Apr 2017 14:14:01 -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 B54F811446; Wed, 12 Apr 2017 14:14:01 -0700 (PDT) To: Sean Turner CC: curdle In-Reply-To: <9B820EFB-2EEF-437E-9EA5-6D6D0606A0A9@sn3rd.com> References: <149202389811.15670.12152466574283340303@ietfa.amsl.com> <9B820EFB-2EEF-437E-9EA5-6D6D0606A0A9@sn3rd.com> Comments: In-reply-to: Sean Turner message dated "Wed, 12 Apr 2017 15:08:00 -0400." From: "Mark D. Baushke" Date: Wed, 12 Apr 2017 14:14:01 -0700 Message-ID: <26856.1492031641@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)(979002)(6009001)(39860400002)(39850400002)(39400400002)(39410400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(9170700003)(106466001)(48376002)(105596002)(76506005)(53416004)(50466002)(8676002)(189998001)(6306002)(356003)(2906002)(6246003)(2810700001)(110136004)(77096006)(47776003)(38730400002)(86362001)(81166006)(7846003)(229853002)(6392003)(8936002)(305945005)(4326008)(6266002)(76176999)(53936002)(5660300001)(50986999)(54356999)(7126002)(230783001)(5003940100001)(7696004)(117636001)(55016002)(2950100002)(6916009)(42262002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB542; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT009; 1:Ljlk3o2PhzJ/qZf+oaLfu0YnJJi/7qP1Hvxab1NzPU+Ht+ebo0Hoag09xz187xGaiBUpAOH67XTe7m/f2F1xae6eNrqljgJ/kbzL0IHg9pDNV9HcqBStnVylV2A5g4khJhgvUQEGTV3QV8hsAD1ub12if2DQUmg3H41zl7LL98lEJyISApX4EbqrDW1/jxvey4cC/LjeBdofOZIsEkl0FOTtoVPdTfxxYhvjuMMNp+yDiUM5ZSIpna7HHT8G44o/77Our3EKujCCS7mgcM1oKpPVawvPaL+VxV24y0GuwDjnY37KRoX4oHAkKQ1U1k160YZzib1h44oMySOonamhIWNbxN+YFpWwk4ESw5JNMdnOhh7F8B3ViGdq2FcGY1VOc6jcxeUWONU65zNoiTuHea7QF6RZrMIswZ+3XrHqnyg6c1fxfqh0nlivWj6D3NRrOa5BV/sQqxss/YDSu4Yc6TRGKzOjQUMmKInP6uOicK0zbMDtZr2ZnZFYv7SGKpDGlDged4ytYP8QJd5kx4rrUk5bsmV1hgN89CXAV3M7ZYgQYbA5O8uGKZWFEWXW+cCrrXC5JfoMMCj5h3uXkA1irtRNYBRBjqVIu4Y4a5Jah7s= X-MS-Office365-Filtering-Correlation-Id: d25f2cd3-d5a5-480c-1e62-08d481e8d8b6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:DM2PR05MB542; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB542; 3:MLtuTtQgNH+Y+X8+cflii8ij7EYZPOB1Zyy3XwFbguzkx6FLtxGCH2EXKXnfNHe67yULCVRVKvEm82HIwIFzZxt4kB//vqCH/be4GaNPvhjAsT/DC6uKTlYrKuevDoVEXaRbCinvDXQ99BW7x+0hvSRNefCm+WGmGhR9jociRcRZLk994HAbBt9kcqfPRarb1iNIi0Js7U/rKYBNWIvPIKj/whKK4oQm6VtvWDqgQKSeUz2nowUp70mjOPQWtRFIgfzH4GZQjEEojL8ZZVmeoLPS2pwd0CT+U2vVZ79c0Zol6Yg+rZcuu9jNloYkXCJHGlDv3/zew5n7DN2Rfqid19DZ3ZaANS/JxWZARJA7F1bsQJmCN+PPtXGk8n7HRb+YRbcrqbAHomcD6iFENakpHQcjgXaJNPIeb6Hu/1a05bYP55o4k8Fzc/VOozl9vYRg6k3KqjzVlnBeAxvtzS/468UP6ESHb3lBA1pklNVg27ZOMrbt5cYRL4MOiBlzy2F5 X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB542; 25:HM743NbQSl5EcME6sbd9NAiACsPUk62EMndPPEANsq4hjxSIceA1tN/0J0bDZdykoXmPn+a5K9sE0ZlEszotbbVbEut+yMRXNKeSiISTADJs33ywwH8JX1jpQhH58I8z81yoWSuK4fXoH4XF6kPFOgI+RBNTO2WqK3ePZ+HzrtThBLIZdxkTZyPqPOCXYczaW1s2Vj025NrgnD07xI4UHIcNS65iJILw/+mfrKdz/2dUHguzGz44br0O3DvhsOIV3GlDd7MH6ESQL4j63bUb1I5a1BTOxyS3vZ3zZcJQA9b/d3q1jmnTDL0n7YCX1WSGgwhLl+54vaUgXcSIDk1lnpdNOpHmDNxOJxgaW9oJEYPuQSVfongrt4fAYl8YQsSPjqcJTjmEzR5ZXweXmEDGiOtswffqzshIp4V9xWVS1A+bjgAhW+7FwRqSQaS5GHtp07NCZzvqQo72qB8Q5IfMow==; 31:jsuW/ITpayHEmWvRvf+SdOpGNt/VbXR7WJW0g3ySANOb7qmP9eNAF2Jr5wqM0uw57e8Un+ZCmOB0J0NcUxYnCkX4s8pADy2qjQrI+ZWqO50V/L7rmFP8/z1JSSydjpNd8MoLx3suSKalEBV7iGhZnwW+93F3Qdrze0i+AxHaO8USs6lwLzpUyflx/bsI4rwjbhjob6YuqZ/79tcFxlcB6hWh9Ad+O44tQSO5J8uybLB5UCc/jzVTpHIYNAq3xLxwplj0ECLHkO6Ul38Sk8ClkOvsFHm9i7oxJ6cew+qoj2Q= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB542; 20:WNgVDgaWTx8K4vJJUjCWCMfRTqhxnv2qOBf7mXypIcLNIqWXwD6K5P8oFBFsLvtMI7OoBPhWw4Nr+p3OwHGEAs01s16m5nlKDBY4UJb7Eznksmay0wX+TOJ4FgxGT3EcWc/TudNPuFE+p4ONEV9UG04SAe6WFpqa2TyIpiFxkZVFXJAcDWB28WbGGtxpLwLFmYyqXjLn36iEt5TRiCs8QlWmVjImsmLFrbLBK0iGDE+B05rpoCwrAcllPldfxtd7goBdOToa17WQ0Z+25ma3wXLqdXLLdaH6ChhabIUNAQoROydhq7j2hiC+bEU+aszpFWdtuBA50Ft9F2oHqgVCNWA4dY9Fnrd7DcchAkxKmdzpcFNHIP659N0cxtDGLjCILfuXSCraQmXZ27xP5UXvsCFK00HmnQu3GozRY9+kwGA/SS6R0VItOqdQGT8j/L5CnvCHVl6U3k6leR8839aeAUWdmjek5qhaCQaA3IfpIlErg9eAm/iAjxpeZLH0zZgE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(5005006)(8121501046)(13023025)(13024025)(13015025)(13018025)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(6072148); SRVR:DM2PR05MB542; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB542; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB542; 4:EmtLNXykxxJ2PKYH4LrHKNudQT86uf1vNr4UdGhAtzFAVPXpmGm3IG1zhJcQsMBf4EAK5jvuHELcIgIBf+zzXjL3Rdo18yVLfi0PbRxROfoLBH2QzP6wqW3mFCtV1E5HFCiNfiamBVzYHNybityHV7Yky0F0xFDk5TJQDfHxDIuuH3/2itOU5XdnF02IHCfjlsBwj43qkKCZ2JQ4HsA5fBa7gdKNSDKpUDl+z3ni6i/TCzqruqXGbJ0qbmpWPs1//IxSAoA5jJla64zCgV8q9oR5cl8M86s3fgHYhcgBK/U9Rqz7k0MC6RU7QIkSw1MMAqTafpDg86k8IW4K+G32F7XRo6i8/WTjyQy3pP2+Za7PPh7bdsQ1PjvNOIOXLGuSkGuALLpV/d2EHIh60jHxa0RLnrWD1MPOKqaDO29spPiD3j1MIwAomnp5GGk+NKUlljtpWOPSc9bmHTHMZHZA9+pki3onHmgfDW3tpSHWylFYmj3nt5gNnU+V68pBs022pej6LvY2oljPVN0orJUOtwcIQiazqV/7J5fA5L3Lh95Wz1olM3a0adotj16Mcr31q/PsmZ7irGP5z4c1v1RQbRnWVXYgzBNEZiVvOvRIf1R+XKXYZAZC9KsMiDI/nFbyGZBj1gajyKphh/S2GTgRwiQX/Q703q7jhirJjF/MSnjguPlJlxNrGvX817MGeFBfXDMfHub/oSIJv8lmgobHRwet9A6h3XlGNnJj411K/o6c3x6MHUUgf1HVzJfUOCvcpb4ski3/RR0DHeiy6Nrf0xMlmpS6ee39QtIpjZMsRR2EfyQnQ49GomXiD1AHncUHUkVO8gEbmZ963EYXgYVDRsGuEtzfish0HBDX3n70rO3c45wHnCc4s3/3F+lkMCj9 X-Forefront-PRVS: 027578BB13 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB542; 23:Wi+V+xXG9omCOiVIMpr5n7B85tZb9FbO4iRQbpkdU9?= =?us-ascii?Q?U7ErhHtHyjlEn+FuZOd8r/tE6/IK1zou24CIshMdAueZwpidD5/rN18WvBx0?= =?us-ascii?Q?fSvdlYH3QYi7TZGuM76cwTe61jT+5vrRN0boDsLFnhFBk6Ay1+D4AdkV6V6Y?= =?us-ascii?Q?QcyXDxKZNDECjX0jYk5jCF1juk/tuMFUfaieQ45zBetjD0dmFeoFFYLXhg1L?= =?us-ascii?Q?wBTN3bW4gYLtvJGEWwt9NedI9PkzYOtUVcwAle4ivQPhFNxKCwD9BnljoQNd?= =?us-ascii?Q?GZj6QJ4PmSMzte9BGjFZMlfpGYE6kjYUT0xoNWOfoOVLuunmBG2wXUFnEskF?= =?us-ascii?Q?DAAZs5Bk7tXK7sRoDhimtBnCSTUdH34GwncrNVQhvw1IZVZ51k1nDs5twmgc?= =?us-ascii?Q?bGcees90DzyU33+NrxcGOirPk7L94r1NTQggSJa1CdV1ppOkxvH5wSstvhLG?= =?us-ascii?Q?m2WKCPjfnfg4lxZ5pol32S/zN1rxMfH9+XERlhH2lqFx4gO3Bj20P4P0X/I2?= =?us-ascii?Q?zNRSXGPyPe+fM7OnHqXLd0Pxq+IJ8Zd0Qg8byRWVd27YT4rcPUrmh16+Fpvp?= =?us-ascii?Q?W+LE9x1PC/hVcQvw/IA6DpJUEjoBHvB1QcecszNEigospKtw+1AiK3zhxSvB?= =?us-ascii?Q?A7/jxSsDARfCggegQ1Okp4LI9fXNa3ZhiSz0YOnkYD6W8eBCIFHseE6CD8x3?= =?us-ascii?Q?bHzctKCKV+a7jJgveK7IQFl6xsxkQws+E2m/u/hrTYf/CSbU2pO1eJ7x0WQL?= =?us-ascii?Q?5hlUTrlIXXONiemcXogKGIffd/VQjxSfHJ9ahuiJlzhP6aE9NONtDwprKpKl?= =?us-ascii?Q?fak0eIdCvcwfSJlsyO5EQVazmHvyq9cbTHQlGvHEyTwDwxGSZSOPPudDEOlF?= =?us-ascii?Q?WVYbHT+qZNLHOSfylQpByj74/iMYVkbkVKD11HDOcrqNTxlVeXB5FGt8CyXB?= =?us-ascii?Q?VO/EgXwDNCCBfJi9nG46qlyoM274BO5fLq/m29anPWM10k2moaLMq/Y07psY?= =?us-ascii?Q?NGQWe6RTiydcwNSA6NXSSJ4R92888DD6VXxAKSk952RmoUbzKGWSuECUb9ce?= =?us-ascii?Q?oft0rnSvqvX2V3LCk7v0mpH8HX/VKOresiOeTChqOSYIR38SD6Y6xmNQFv6d?= =?us-ascii?Q?tt2WvpmBtEvAjP61y98yepXnZHbbDV7AYTU99pzS1dyH7L1nVK2Kjuzk5Uw5?= =?us-ascii?Q?h6N/FdFqVXYTPcjrjI5ISrh0oeNDndhmLM2LiGrmVyuSSPq6YCqTvQOwf1x1?= =?us-ascii?Q?GNfXFZS1khuxqHy7Am9BlWcIkgsDXGacQnP670DZIg2N/bX7+HGDQ2ObXCtF?= =?us-ascii?Q?JhM2cWHWj05zcxUrPGCUvTiBNsQTwaFhvPJvNV5+wlPHRAAAUOex9Zvdk1lW?= =?us-ascii?Q?obBA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB542; 6:odSNCdNHKNkpZC/DsgZTXIlcuAD6PkAX5P6IlDBDqPcfaSzxPXY4ho5aFvJmKFFQchDA4ykxS9ctC5D7nz3EOIHXS5jTpvhATNm56bnC7kkag38ngj1G2IDXpExU9WHXZoLVmrU4bQcXogVQcWTdZ/DHYUpiIpMtl5Bi0CiPaw8gZfWUVWlrKP2mKl5hOwNkE4pSMQnzQ/fW0QinOkGWe0mbUvW7OtMGNIAuyA3AT+O/MiOh3DDisBUawszntUajwkCUiBTxx+VVIp0Gf8M0kNUD4u+qSZgHn6kFq1byKSryxzVvzQFE4qXLtb+lfCNoiPcdD4YNCl18PHtBPCpKH84K/H03uJjE5ocsjzUVCxLHK1ixIMd1Spi5PTi0jCRWCOWMISr1GEZTvwCUA1WP9g2Yzb7c6FcIBHEt4f+xMk97RCaqynpfo7ptnd9WuZ2uq9ewRl/59TV9zmhr1ty3FbCBwQjBGKoaTK+nI8Vfvy8=; 5:zYUvX2or34b1bUD9Useuc/dO7lqppInLs7i6Vh7tHlO48izr3CddsGXyUAqUccN+JO+KFVGveCoeic2LNi59gFQicd8MtsxziTIPZDyYzbQtWaM+EwOQ6AqWtdEjnG+IqJRM5mLjDCKICcz+96WtGXZGgDTaF54W6KqmLDxoEbQ=; 24:n9k3bbmQC1c3dtnVWx+tQoK0s6h2W5cnros4sRHFhhvkgX+YOCv0DUrIgdv7P3l47tUx02AbjnikcGVPjxSIYctZsjfU0Xdpr7VaEh8bdik= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB542; 7:CYr2LnSdkWU6rYaakXYenkqrlktPaWgCxgsBcTa6kuNVXL2L8IdN1s2WQjYgXrFLBho7JPj7HRI0eF+Mk7z0qMsK/ABkTcBaS0A97paobGHq9KWjMzZxJnmBJYIIduSzaVbq9LsKJAVDNJtqi41y3ctcCWVxmzC2Zg52LZ6/B/QRLgDsiA8+WxEfmtjTqZhulOUHTXDqiXN/1mzyD+ZhasBUgvQ+cCYBUaaPlVWHbSoIM2dK2pXVjPubYvxK/3vRoLGZH5XrQbM36SXoUueLEs/JabjeqJRblzjApnXbIykRSE2G0qFwlSSmjhf3TzrEt+z2BfjpG97DH4Dyg85vhw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2017 21:14:03.2050 (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: DM2PR05MB542 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-03.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: Wed, 12 Apr 2017 21:14:08 -0000 Hi Sean, Sean Turner writes: > Should this be referring to RFC7748 for curves 25519 and 448? I think so, and I think it does in section 2. https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-03 Page 3 says: The methods are based on Curve25519 and Curve448 scalar multiplication, as described in [RFC7748]. Private and public keys are generated as described therein. Public keys are defined as strings of 32 bytes for Curve25519 and 56 bytes for Curve448. Clients and servers MUST fail the key exchange if the length of the received public keys are not the expected lengths, or if the derived shared secret only consists of zero bits. No further validation is required beyond what is discussed in [RFC7748]. The derived shared secret is 32 bytes when Curve25519 is used and 56 bytes when Curve448 is used. The encodings of all values are defined in [RFC7748]. The hash used is SHA-256 for Curve25519 and SHA-512 for Curve448. Could you be more specific as to what change(s) you are suggesting? -- Mark From nobody Wed Apr 12 15:06: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 994131270FC for ; Wed, 12 Apr 2017 15:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMY7VzirEeem for ; Wed, 12 Apr 2017 15:05:55 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 4C0AF1204DA for ; Wed, 12 Apr 2017 15:05:55 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id f133so35058395qke.2 for ; Wed, 12 Apr 2017 15:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WgH84dIAbGoNbH0WJf2pA2n4uRk4nElJ70HRxQSOlqQ=; b=Q7VQ5wLCkG39PjwGE+VC581pL6Y44Rv2nC/+pTWjiDNok+6/z/+pJw1kpyP96p5b/k WclwN3/iAuvha/K3vXKySMTKqypLjTVSS8qQf+hWC6Vd2mwmYBg8k7Pvp1rzULJZ/ax7 9mIQKdsCtOxR2WxANYSFKK3IigZrfWtybFw7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WgH84dIAbGoNbH0WJf2pA2n4uRk4nElJ70HRxQSOlqQ=; b=JqwvnPJK9OuXGIXAKRne6cnOMa5rm/g8QGkRXJJkoQwfQyqJsL4QGvLD2xE6LGzh3u 2diiE/wq/OglQ344NzRxnHpvldn+zmiRBGF37+nK3mOPAvTc32E7iYUPLoVO8JhPaEKD oNPOaWeUOulLzH5TZK1UO/GWEJCnEWmPcbaBrPLr07Jdzivu/lBwRdHUMpqckJg9u0vp 4xVxJlXpmXepQbgKuvrdeYqKcgzPDRAFz7ZyZWG3MDEEC4SO7V23fr6XCl+MT85g5WaP iett8WJxPTDfdlTZkakXwREK0aEr8YOB7Zv3dqjqtIY9Lvo+fhD482B5A98aOF6nUrl+ 7roQ== X-Gm-Message-State: AN3rC/5Z2YoBhsSnIk25mLgU181PPlvyTSp9e+VQrrBc+bJmEdnmjw+2xERhPZzezTlcpg== X-Received: by 10.55.155.7 with SMTP id d7mr26315560qke.320.1492034754494; Wed, 12 Apr 2017 15:05:54 -0700 (PDT) Received: from [172.16.0.18] ([96.231.229.219]) by smtp.gmail.com with ESMTPSA id f205sm11632443qke.19.2017.04.12.15.05.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Apr 2017 15:05:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <26856.1492031641@eng-mail01.juniper.net> Date: Wed, 12 Apr 2017 18:05:52 -0400 Cc: curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: <149202389811.15670.12152466574283340303@ietfa.amsl.com> <9B820EFB-2EEF-437E-9EA5-6D6D0606A0A9@sn3rd.com> <26856.1492031641@eng-mail01.juniper.net> To: "Mark D. Baushke" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-03.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: Wed, 12 Apr 2017 22:05:58 -0000 > On Apr 12, 2017, at 17:14, Mark D. Baushke wrote: >=20 > Hi Sean, >=20 > Sean Turner writes: >=20 >> Should this be referring to RFC7748 for curves 25519 and 448? >=20 > I think so, and I think it does in section 2. >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-03 > Page 3 says: >=20 > The methods are based on Curve25519 and Curve448 scalar > multiplication, as described in [RFC7748]. Private and public keys > are generated as described therein. Public keys are defined as > strings of 32 bytes for Curve25519 and 56 bytes for Curve448. > Clients and servers MUST fail the key exchange if the length of the > received public keys are not the expected lengths, or if the derived > shared secret only consists of zero bits. No further validation is > required beyond what is discussed in [RFC7748]. The derived shared > secret is 32 bytes when Curve25519 is used and 56 bytes when = Curve448 > is used. The encodings of all values are defined in [RFC7748]. The > hash used is SHA-256 for Curve25519 and SHA-512 for Curve448. >=20 > Could you be more specific as to what change(s) you are suggesting? >=20 > -- Mark Sorry for not being more specific. There=E2=80=99s still references to = the other specs. OLD: This document describes how to implement key exchange based on [Curve25519] and [Ed448-Goldilocks] in SSH. NEW: This document describes how to implement key exchange based on Curve25519 and Ed448-Goldilocks [RFC7748] in SSH. spt= From nobody Wed Apr 12 16:20:41 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 7B40F129AD5; Wed, 12 Apr 2017 16:20:39 -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.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149203923947.15714.99930634554185369@ietfa.amsl.com> Date: Wed, 12 Apr 2017 16:20:39 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-04.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: Wed, 12 Apr 2017 23:20:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 Authors : Aris Adamantiadis Simon Josefsson Mark D. Baushke Filename : draft-ietf-curdle-ssh-curves-04.txt Pages : 6 Date : 2017-04-12 Abstract: This document describes the conventions for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-curves-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 12 16:26:19 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 C373C127876 for ; Wed, 12 Apr 2017 16:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVgesCKsP8AR for ; Wed, 12 Apr 2017 16:26:15 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0097.outbound.protection.outlook.com [104.47.32.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7E012786A for ; Wed, 12 Apr 2017 16:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KI0zdnMM43LdoxB681sDtwaPx4jAakiW0GNJnIGKqrA=; b=X/7MkzwaunFJZFfqNMafCEWmczUgJTf+4ZGZWp44u1pmtBK5sJs92879xyWkRfh+AsESNQMadLWAcoO6Ex6+qn8x0a+YqUDp1eK9QZraLLV4f9JK+Q7LTla0m2l7JpHNVqOs+0uooRr0t16aqcvhUek14ZPROGzbXXzYo56dAH0= Received: from MWHPR05CA0023.namprd05.prod.outlook.com (10.168.242.161) by CO1PR05MB539.namprd05.prod.outlook.com (10.141.73.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5; Wed, 12 Apr 2017 23:26:14 +0000 Received: from DM3NAM05FT018.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::202) by MWHPR05CA0023.outlook.office365.com (2603:10b6:300:59::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.5 via Frontend Transport; Wed, 12 Apr 2017 23:26:13 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 DM3NAM05FT018.mail.protection.outlook.com (10.152.98.127) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Wed, 12 Apr 2017 23:26:11 +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, 12 Apr 2017 16:25:31 -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 v3CNPVeR032760; Wed, 12 Apr 2017 16:25:31 -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 8C00411446; Wed, 12 Apr 2017 16:25:30 -0700 (PDT) To: Sean Turner CC: curdle In-Reply-To: References: <149202389811.15670.12152466574283340303@ietfa.amsl.com> <9B820EFB-2EEF-437E-9EA5-6D6D0606A0A9@sn3rd.com> <26856.1492031641@eng-mail01.juniper.net> Comments: In-reply-to: Sean Turner message dated "Wed, 12 Apr 2017 18:05:52 -0400." From: "Mark D. Baushke" Date: Wed, 12 Apr 2017 16:25:30 -0700 Message-ID: <50852.1492039530@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)(39450400003)(39410400002)(39850400002)(39400400002)(2980300002)(189002)(199003)(377424004)(9170700003)(86362001)(53416004)(76506005)(229853002)(106466001)(6266002)(8676002)(53936002)(6916009)(7696004)(8936002)(105596002)(356003)(2906002)(38730400002)(7126002)(5660300001)(2810700001)(2950100002)(305945005)(110136004)(4326008)(7846003)(6306002)(77096006)(6246003)(50466002)(55016002)(93886004)(50986999)(117636001)(189998001)(54356999)(76176999)(47776003)(230783001)(5003940100001)(48376002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB539; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT018; 1:HurBk86Mv56YGaOly1AatdCfs+ljYOUp1HBUv+H0TOEkWbMRxY/RkuGZSLkXvORAnhL9ApzfzPuVzL5+1GVZ9LXfQ0JLqgqr1DfJM90uYAeY68Ss3bMoA4mk/jdFcL+QVNsM1bW5sNSNIn2pwe9cN2vC0GfvIRrnTQu/wr4e8ZxxWjaHrZhccvLSUHmGCv8eGVaPj+W0w/tWrJ6sYNsZFjjSOUdRLcPu/hky5R1JIYSl/htyl3JGdoSDUm9JXd2ZOnjOkIwjUBYJ3GJQoJED1ZDSSTMfzcxbrNJivaAgdtCvoOpCPnd5AM+e/45esaKMqZMESqxnAo6EWao2UceGjZAnwgdSP9k5xr4nu1VL/ReVH8g/lRC223eH7Vvxc9mGt5DpYblFrVRjsHe7NCBaGN0jdy/0FI3gJmjX8CoOCxB9xXu5bowYri4jl0pwO8PNwV4WdI+QbQmeec0VaOdQsO8oE8j45TTSoyW4j3JfNf+OZ9rakMwd2erLou0WQnlqHfd2ioXpVKcD4KJyzj6mcR6gsBPU//S7Zn/HT+hzMC5TAJjlatTUOSUryvX0W9j6NNFa1wuaq8dDmWuL9rYkNcl41x5P0Ip5JeePwdV4utA= X-MS-Office365-Filtering-Correlation-Id: 8e0f8428-6a90-46b5-c68e-08d481fb4fa0 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 3:xekArFfkkhFFO9ifmG8ZPjbseNSyb7l897wQdgpJeueRbat2ORaXTsdaSa4MmPHY1Ty1aJCfgI8LzSyfhGkJnEDHldoocnhE1F5Y91JfqyAmUfac8w4A5fTVJk5xMRxtXa01hnNH2OLLjyZt2kTpBI1qA7exEVffng6gXWELs8NvEQvs1FCpxw1fsbfDmNXgvxqIY9SiqRxGW0XbzvCkUsi+WepY+KXNy41Yw93m+V+KuOpnI7jktPHpIrS0QvnFdqOqE5IAHWzpkyc9czjrbHMyQmI3Ib9kecTNaHELAA0Y1CCSw0oqf0QwEiQdTSDRzIKOWBPvCCProvGkxbU2YcgVUw/wZl5tSJ2a9FJnR26ZngB/TjZiwGf/X+/qcT23ze1gH+rBbBBH0O1FpVoEQgqn6YBg0itzxMceZ+Bpngb5kjZjJ5qbLh5LVOJyoLJM9NSV08sWRefVOoCAsQVuFejaD7kQeXgzzN8y5deWbbC/NDCrI1ClLT6RQxIZbNq+ X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 25:LI/wpbdM8n4x0kuQWYJZFpJsYp/y8En3/sbhmYIz2LMOGD9c/EkudyjsuFD+wDP7sH8P90ftJ5lFw+ivt7AV/k2WH0ZK9rtx1LCUtPPiBLwuxe1MnDYalCcd3D+VpTigvFqsVhO30UYU3Dya58HjOl0Waf2whuExwZBoHz4RQyX8UXSuAdVh85AjJ+YfTcoE0D+B0WAX3/AknlfLsOoDeNXOJxfuhI2WysIDhgj/zLshckvwTBUCvFDPkLZjrFta2I+8cxgrs+uWqrssUyHEAWcjkxnHokVfzt39ZcZTgERMTxeEvTfJIuL062+514wBx5s9tqTDUV8UFX5sAWgy+kRXY4RRwv7bs4Jy9fDU4oZ7rkCU7ddjON3dFSZhT7fcZwweMW+MSA2ZuiIf1nROxHz2UP03xzcpd01PfP7w7wMZSJbI8e50hFzo7BXAf4Nwct8lfmsEmIDEEHJ+My620w==; 31:jIhDR9A4IidP4ZU8LNppvwAPfB8/hB2EQtQFOIGQ2e2NcmQGnl+eYOb1Pfqge3+kL227r5/IA1DAj7oRzin4gqTpU1hxf09n9nG6NhK1HKoRX+iCfEjB98sAVnoEqJ4QVfH1NUcs63R9E17JIqWwon3dHHMYRDzHD2rh+RheBCS7k/6o2ACUuUSaoKN7eN82E6x9Trq9kp1xzk4Lflw9LWbRfVHXk2kt/C1vvGriNy2MwIhP1MbpmZmargnUuXfoy9vC3IZFBQznaAtNn0EyfkkQIxDsXY5o/PCqKIsQaSo= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 20:wTYzOGknNLWyuBw9ZLfP0L037HqTUId1tz5ElHkl9IRVQPgAzuYHXNF01eaPiZjgc1TylsCB1tc9bxVdJYs7qy3baYG3LGIj+XahwqXoQcs4SaPdLOnTr14dhszSNxNYq8Fv6cTHkYfnT5MfRwo+5o1dB510kZRiet/nOSOEgEzD+OW25s1sMdQVQ1SjqaUtPIo+Vv/sgXOSDML/OW7fMnmhbpMPkurPOlI/6FPXEOv7QFsegxNegGXoHB5sByqBPjIv3bbbJh9XDIA20H41txMr0kgrStjJpqjzVAlXaG5Eu8PsPRHE8XPOgeNOLmOs4E/29A6rGp39Y7/wBJRZ1wp5jBffno0NbfxSshsLLyBHk2e9r0dqH+fp48WcdtG8FRoO313+V2Okne6xJD/hm3oyFN/idzvqs2LNoRYiYkEpjN18uIeiwabff6/QVpoQ82X4dKbmTlwVGEezmiGRUyP8NRBkDfj5Q8CkPqFlAUB1EFqkS9SQQmR1i73otkdR X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(13015025)(8121501046)(5005006)(13023025)(13024025)(13018025)(10201501046)(93006095)(93003095)(3002001)(6055026)(6041248)(20161123555025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:CO1PR05MB539; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB539; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 4:KDh9hYv9hKoDfdpgmQUJEf7xZpp26kygLV/mrnpCjxmbJhNT3SUU3dNDwuBtjRkYntZqi7c0wFZXVvR/9vn/f6gp1Igv+kMumyskiMY+saR5paNKX1LHIuCOf6++ff1i+VdiTtGhtEGahIcqCYJvZkOoASL5ceVdVWOF/hXvCCo/jXf/KLmarIIjctEKZdnSwdYJknItvV4C/sxgvJYimfSAxc4ddplRmTEZlpX6wlTbiTMs6qEH3jofH1NbpLVDdIUZJPfbXPK4MLRs9/2mlrM57mF5iCQsovzKwH3SwGoMIli4VQFSZCmrpA4dPSgck5CUFVBFHtZAn9XUk8CAapr+UbbkwSyDmNX6dMA/2SE3sHJeId2l3SbnY/nX4bMbNT5wItMx48A+NrsKgk67UPRuKAQezI45vvP8gOrJBZnrOhU8zlka9LiEHVfucYAfOqj/pZmFMCtWvANd8ZGtMcdrPMmpzN0JZ5u2OYU1cQYYdiwPNVGUBWWc8UM5wOYOQ8mn6aOgIhbGnL7+DwZH10KZ0EkSgzDUHxdixOTE6XJMFR+nkVsI79TWT6najjd6w2SbAAh3CezjZgAqfYDFMs72Rvtl1puFPMD+DCOl1bkTgAIpV+bLRBadq5lUdh6amSNFhgP4WyFaUwFPKL4B9Lh/ChEoKDDEI2i4Hbp34HEw0ei+h1TrVFHm7zjCeatWoiU541eWEObLB87XsXrunmcIYIOu2teRz+wp31Xagd1ewFC48/9a/+/EVDPLnQ23/O5XnCw3NnkJVLG05IzNUMew/ehYku/czS+Qwi/Oyn5QxlkK+CEmjWOPRauncbhFJwHuljuLzdta2l/sHTgTxDEpLKDT71qfkfoq+RgjioNwJxMRwg/tce+MCx2VKsV1Kj0Prwm2MRov8/MkHnJN/w== X-Forefront-PRVS: 027578BB13 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB539; 23:LNI56XgYwle6I/P+PjMUxm/D8Cd+MJ8qk+B/JDODNf?= =?us-ascii?Q?pirup1xKT3Z9O8tqN2YulB5xLDWDHJ0/IMILKP513awMbgjUG+lhznLL4q+6?= =?us-ascii?Q?GKirnI3nMoiyVdi+2wnZZsNHb3PjLaR8IdxPlZ3xpy0aYf40lnqRswniS32e?= =?us-ascii?Q?RJgZ2QmNcNOEW8IjSNIaNDefl2/lTl6IFw29Fzuh6cpIDZ3kn3OV+zrT7UZf?= =?us-ascii?Q?7+J7o+frAbf/oVkp/fxqYaW6fpkSaQACMN23JcW/PamsIUUbRGfrJ70kin9e?= =?us-ascii?Q?HXt8YpDGtV/7nr0OToYWWIfgW0BfGeduEMZJrgaQk4bRJFryPs0bA2bIZm6h?= =?us-ascii?Q?iPAC00Ogrj8y2VbVAx+9rXVEjr4vxsDmmv4658ivcjmCG60fHRg3S2X+Cwb3?= =?us-ascii?Q?iIxGl47oddNf2qSwZVsIEZMT3cax+ov7n952Tbos73r1bDs99K7TokIit8di?= =?us-ascii?Q?WVxVae2nfzXV6i79shLXXngSySmjU+ANfMyYeLpYDIQZdcQXuc5Vaof/nVZL?= =?us-ascii?Q?qRilrcGhmXG3vIj5OQkGQyhx7MmaPkor9EvjqYxKklvQIdn/acooXhywyM1K?= =?us-ascii?Q?8OHdLnn9xsa8n+fUoKuJR02/ppl3/ieA46Pls3jtoKPhWjuZaWFDpUeCKFfk?= =?us-ascii?Q?nzSJjMl7dbJnAZvcpcZNQ8cr4XsMOIGZdhSGciir6JMpobZfJGdTxuk0V+Wj?= =?us-ascii?Q?YYc61HGhNCfIlch/n++BxASjTRfa3dfWXCHisiRiZpZNyk8VVN1QkjcMcr7e?= =?us-ascii?Q?o1W7Gk6Fl09USjj2tNXq3F3PVI+L6GDadUaa61UBiEjzPsCE7dnAmFLlhfOQ?= =?us-ascii?Q?wk/aMmmNuEOIKJDSOJxxL4moru3AVTO3n3iV2tCeulBwEiLmOoxk48V9r/2R?= =?us-ascii?Q?9/zulDxk1i0SoZfl4psWHpS3AwBcoL8DkMjike87Krc79y1XozG4AzIg+WTg?= =?us-ascii?Q?EZWEraubZxPf2nNDAledMcrNTeFjoSXYCLbpWIBJvCMQNQd2wJli01zaPZ08?= =?us-ascii?Q?CHaX6aoniy6BLyE9vedeb1b2VN3mVDmdFMSuCEpvvGYxdbCFXMweIV/kno2P?= =?us-ascii?Q?rZaqPOmbrRXpbEPyx++vV4zwIBXmGHrpb1ZQE7l9wbJ98CbF46RLp6zGK0y9?= =?us-ascii?Q?bHHmi5NiBiRPLBr925KiQlk4dcIdezXyzjfX9P4EEcFivcaQYXRk09dnosOQ?= =?us-ascii?Q?pvLMqgFdg7dVtvzoPrsba8aPr5TDxVCDpfel7PyH38QYPx63qusHJW0Q=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 6:IenTqF7coKCydLUBRhQMm4wFC8Wv3HueQa/V+RXz40D9v99ZC5OgO2kGzUGoRJPMQitaTGE+K4M3N1SVhFZ9dMPNR8dn2aGGSS6SVrc9XQAGNOv3T/fsL7nWs2u91+xb3zavsCirAGxjVvNRe700zoyLF2G8/9QzA7hR/tYTcmqcXe91NkI9EETEMrcPfyl8DKybfyzYC7OQQ4jagVVh+cK6trz/TDaxv1GyKDoGL1myjqzUQ8DXi/NetdP3Tw/Pks1IjYZW2KVn6cpp2VHgFSDgX8XdRj9URGedIM7iSZXZz0MBcIOrWgkXY1NfP13952YSMXVqEtIvNu/cmF7xOqLMgOVM22F4E/bTbZLfBlgotbZmJfyHWiny+pQNw/JIWDVxNlox1A3ADuKIavuLjxLkeAFesxTF/sLFmpX4/CN7gYOfOg4rxRpJjnaryBEoJlgLWzJm1bAsrmwa3eI8gE/g4Lba912i1uOJE2TK4oA=; 5:ANcyPA9f2vOY9xvuPfHEq94GKLglU0TT4u9dZTnIzV96z7cGaOvACWOC6gsOC5YPtF8pwAG0vw2TikRslyhC4noX/Veffgy1N7OAg6Y74pGGNBsRGRvQ392l0QorAfWNOoGeEpjA8y2sCHMiNjPi4w==; 24:SDHlJZB2gBtevz+lGIdKcWvyvBikhtpQT/JjI3G1lzbSvWI6LEJeZC2Ige+Ze5lvlnt4HHRRe7o7PoC6bv4kWeoGOIEdMbmJ53q7V7JIIOk= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB539; 7:Z5YRLt/V6YMIpaaw9c+lj2T1VrA6uvmlMIVyDyJrhD2GkEfJuZoyU2Kor5Kg2tp/ALmk6U+Co8PngFRPO8RsrglHlMuAD1nb1hl1PP2z98DO1AeCSOXsuLp44ald38mw+ZeSpu6vE2ZWJ8aPpn0d1cSILixsUQ4CkG+7+RfIUmSilW88+b8hc/VX/d1IwiKWvMVmmdp8WEqR2NL4jYj5ScDn7jyuaBwALGZ9gD+KWc07WYAbw1Ob9Rsap+nOQ/T/ryPTvmEvx+tJm13LNzr+ofWDRJ52wzcVOIJG5ed8jUJa8ftrzs1bZ6DL8AUcxwnOB0q8NsjfzYy9bZj2FX95Zw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2017 23:26:11.9580 (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: CO1PR05MB539 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-curves-03.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: Wed, 12 Apr 2017 23:26:18 -0000 > A new version of I-D, draft-ietf-curdle-ssh-curves-04.txt > has been successfully submitted by Mark D. Baushke and posted to the > IETF repository. > > Name: draft-ietf-curdle-ssh-curves > Revision: 04 > Title: Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 > Document date: 2017-04-10 > Group: curdle > Pages: 6 > URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-ssh-curves-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-curves/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-ssh-curves-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves-04 > Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-curves-04 > > Abstract: > This document describes the conventions for using Curve25519 and > Curve448 key exchange methods in the Secure Shell (SSH) protocol. This revision addresses Sean Turner's comments. -- Mark From nobody Wed Apr 12 17:19: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 240491286B2; Wed, 12 Apr 2017 17:19:24 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04L8eJmDPK7d; Wed, 12 Apr 2017 17:19:22 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7B212940F; Wed, 12 Apr 2017 17:19:20 -0700 (PDT) X-AuditID: 1209190f-637ff7000000706b-41-58eec4063408 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E0.7D.28779.604CEE85; Wed, 12 Apr 2017 20:19:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v3D0JHul011538; Wed, 12 Apr 2017 20:19:18 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v3D0JCOj031347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2017 20:19:15 -0400 Date: Wed, 12 Apr 2017 19:19:12 -0500 From: Benjamin Kaduk To: Russ Housley Cc: Daniel Migault , Simo Sorce , curdle-chairs , curdle Message-ID: <20170413001912.GE30306@kduck.kaduk.org> References: <1492030032.3662.174.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1492030032.3662.174.camel@redhat.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixG6nost+5F2Ewfu9HBYzezYwW2xdOIvZ Ysr0PWwWr17cZLf4MXcRqwOrx6+vV9k8liz5yeTxfh+QterOF9YAligum5TUnMyy1CJ9uwSu jIsbG9kKngpVzDlh0MC4mr+LkZNDQsBE4vGXZpYuRi4OIYE2JomnN4+wQzgbGSWO3vvICOFc ZZI439jHDNLCIqAqMWl/BxuIzSagItHQfRksLiKgLvF3/gV2EJtZYCajxPtncV2MHBzCQPHT 2xNBTF6gbe+e6oNUCAmsZ5RYtikAxOYVEJQ4OfMJC0SnusSfeZeYQcqZBaQllv/jgAjLSzRv nQ22iFPAWOLhldtgB4gKKEs0zHjAPIFRcBaSSbOQTJqFMGkWkkkLGFlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Zro5WaW6KWmlG5iBMUApyT/DsY5Dd6HGAU4GJV4eAuk30UIsSaWFVfmHmKU 5GBSEuW9rPA2QogvKT+lMiOxOCO+qDQntfgQowQHs5II74IDQOW8KYmVValF+TApaQ4WJXFe cY3GCCGB9MSS1OzU1ILUIpisDAeHkgQvz2GgRsGi1PTUirTMnBKENBMHJ8hwHqDhIYdAhhcX JOYWZ6ZD5E8xKkqJ82qAJARAEhmleXC9oBQlkb2/5hWjONArwrzGICt4gOkNrvsV0GAmoMFr 974FGVySiJCSamBsNP/r4r7JXXV6pefx8zHFpXHXFHbJ9K6beeQRf6Lr+uXb5lULxQcHrZdb cmVm8uW/n38rxKza+b1axsKU9y6/RtA8pb8TT5eZbdp6r5VrZpbD1G02uUpinw5tblfpUuQ6 ZepnWu/0j61EcKvxZOEX+RfX+S+quHFk208tgfMlrSsP/Zuy6JK3EktxRqKhFnNRcSIAhd1w pCwDAAA= Archived-At: Subject: Re: [Curdle] Call for adoption 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, 13 Apr 2017 00:19:24 -0000 On the other hand, my draft is squarely focused on Kerberos and the GSS-API ... but I am also co-chair of the kitten WG, and my co-chair is considering being replaced, so it would be somewhat difficult for it to move forward in the kitten WG in a timely manner. It seems much more likely to advance quickly if progressing through curdle, and it does seem to be in scope, to me. -Ben On Wed, Apr 12, 2017 at 04:47:12PM -0400, Simo Sorce wrote: > On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote: > > Wouldn’t it be more appropriate for these documents to go through the > > KITTEN WG? Their charter > > (https://datatracker.ietf.org/wg/kitten/about/ > > ) covers GSS-API and > > Kerberos. > > Mi draft is strictly related to other drafts[*] in this WG that are > defining transition from SHA-1 to SHA-2 for SSH key exchange. It seemed > like this WG is most appropriate to review that draft to me. > I guess I should have added "SSH" somewhere in the title to make it > clear. > > Simo. > > [*] > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2 > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves > https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2 > > > That said, if the Area Director would rather this work come through > > the CURDLE WG, I can live with it. > > > > Russ > > > > > > > On Apr 12, 2017, at 11:40 AM, Daniel Migault wrote: > > > > > > Hi, > > > > > > This mail starts a call for adoption for the two following drafts. If you have any opinion, please raise it by April 26. > > > > > > - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt > > > - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 > > > > > > Yours, > > > Daniel > > _______________________________________________ > > Curdle mailing list > > Curdle@ietf.org > > https://www.ietf.org/mailman/listinfo/curdle > > > -- > Simo Sorce > Sr. Principal Software Engineer > Red Hat, Inc > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Thu Apr 13 06:49: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 C6EA8120724 for ; Thu, 13 Apr 2017 06:49:41 -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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5upUfUZB65oB for ; Thu, 13 Apr 2017 06:49:40 -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 00AB1129481 for ; Thu, 13 Apr 2017 06:49:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3C7B33004AA for ; Thu, 13 Apr 2017 09:49:36 -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 la--Y2BTJ8CB for ; Thu, 13 Apr 2017 09:49:32 -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 C4900300098; Thu, 13 Apr 2017 09:49:32 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: <20170413001912.GE30306@kduck.kaduk.org> Date: Thu, 13 Apr 2017 09:49:33 -0400 Cc: Daniel Migault , Simo Sorce , curdle-chairs , curdle Content-Transfer-Encoding: quoted-printable Message-Id: References: <1492030032.3662.174.camel@redhat.com> <20170413001912.GE30306@kduck.kaduk.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Call for adoption 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, 13 Apr 2017 13:49:42 -0000 Ben: Thanks for the explanation. I withdraw my concerns. Let=E2=80=99s = process these promptly. Russ > On Apr 12, 2017, at 8:19 PM, Benjamin Kaduk wrote: >=20 > On the other hand, my draft is squarely focused on Kerberos and > the GSS-API ... but I am also co-chair of the kitten WG, and my > co-chair is considering being replaced, so it would be somewhat > difficult for it to move forward in the kitten WG in a timely > manner. It seems much more likely to advance quickly if progressing > through curdle, and it does seem to be in scope, to me. >=20 > -Ben >=20 > On Wed, Apr 12, 2017 at 04:47:12PM -0400, Simo Sorce wrote: >> On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote: >>> Wouldn=E2=80=99t it be more appropriate for these documents to go = through the >>> KITTEN WG? Their charter >>> (https://datatracker.ietf.org/wg/kitten/about/ >>> ) covers GSS-API and >>> Kerberos. >>=20 >> Mi draft is strictly related to other drafts[*] in this WG that are >> defining transition from SHA-1 to SHA-2 for SSH key exchange. It = seemed >> like this WG is most appropriate to review that draft to me. >> I guess I should have added "SSH" somewhere in the title to make it >> clear. >>=20 >> Simo. >>=20 >> [*] >> = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2 >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2 >>=20 >>> That said, if the Area Director would rather this work come through >>> the CURDLE WG, I can live with it. >>>=20 >>> Russ >>>=20 >>>=20 >>>> On Apr 12, 2017, at 11:40 AM, Daniel Migault = wrote: >>>>=20 >>>> Hi,=20 >>>>=20 >>>> This mail starts a call for adoption for the two following drafts. = If you have any opinion, please raise it by April 26.=20 >>>>=20 >>>> - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt = >>>> - = https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 = >>>>=20 >>>> Yours,=20 >>>> Daniel >>> _______________________________________________ >>> Curdle mailing list >>> Curdle@ietf.org >>> https://www.ietf.org/mailman/listinfo/curdle >>=20 >>=20 >> --=20 >> Simo Sorce >> Sr. Principal Software Engineer >> Red Hat, Inc >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle From nobody Fri Apr 14 16:58:55 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 D90C2129B1E; Fri, 14 Apr 2017 16:58:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: curdle@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149221433384.15894.2426718340325647925@ietfa.amsl.com> Date: Fri, 14 Apr 2017 16:58:53 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-modp-dh-sha2-04.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, 14 Apr 2017 23:58:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : More Modular Exponential (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-modp-dh-sha2-04.txt Pages : 6 Date : 2017-04-14 Abstract: This document defines added Modular Exponential (MODP) Groups for the Secure Shell (SSH) protocol using SHA-2 hashes. This document updates RFC 4250. This document updates RFC 4253. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-ssh-modp-dh-sha2-04 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-modp-dh-sha2-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 16 08:43:03 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 89C2F126C22; Sun, 16 Apr 2017 08:43:01 -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.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149235738153.17755.18352980626323388821@ietfa.amsl.com> Date: Sun, 16 Apr 2017 08:43:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-08.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: Sun, 16 Apr 2017 15:43:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-kex-sha2-08.txt Pages : 12 Date : 2017-04-16 Abstract: This document is intended to update the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. This document updates RFC 4250. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-sha2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 16 09:04: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 833AD1292FC for ; Sun, 16 Apr 2017 09:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWzCUpwCE2Vk for ; Sun, 16 Apr 2017 09:03:57 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0123.outbound.protection.outlook.com [104.47.37.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6814C127869 for ; Sun, 16 Apr 2017 09:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/Gi9alMnkKLw+gMiQMy72/BGyLal9TUfVBgqof+E6Uc=; b=T1W2yPKMmUrbTLc1Ie87bI39y8feSS7vw7ncdnm5qwN6kLBkNeaaxtBEQxBs3cQ4EK6G8zdDzQl5hzdqMRTp3v9jbh4dqOitKNIKwVEgchmDyp0+D24VHoiaDAYqXXkzvrQZRcfzh+6L6gB69lTDIrgJq/qv1XWw5LkgwLwP7Kk= Received: from DM5PR05CA0022.namprd05.prod.outlook.com (10.173.226.32) by BN3PR05MB2449.namprd05.prod.outlook.com (10.167.3.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Sun, 16 Apr 2017 16:03:55 +0000 Received: from BY2NAM05FT063.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::201) by DM5PR05CA0022.outlook.office365.com (2603:10b6:3:d4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Sun, 16 Apr 2017 16:03:55 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 BY2NAM05FT063.mail.protection.outlook.com (10.152.100.200) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Sun, 16 Apr 2017 16:03:55 +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; Sun, 16 Apr 2017 09:03:54 -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 v3GG3seL027768; Sun, 16 Apr 2017 09:03:54 -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 D2B301144E; Sun, 16 Apr 2017 09:03:53 -0700 (PDT) To: In-Reply-To: <149235738153.17755.18352980626323388821@ietfa.amsl.com> References: <149235738153.17755.18352980626323388821@ietfa.amsl.com> Comments: In-reply-to: message dated "Sun, 16 Apr 2017 08:43:01 -0700." From: "Mark D. Baushke" Date: Sun, 16 Apr 2017 09:03:53 -0700 Message-ID: <96880.1492358633@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)(39850400002)(39410400002)(39450400003)(39840400002)(2980300002)(377424004)(189002)(199003)(9170700003)(189998001)(106466001)(50466002)(6916009)(48376002)(2950100002)(86362001)(38730400002)(117636001)(8676002)(7126002)(229853002)(230783001)(105596002)(5660300001)(2351001)(76506005)(55016002)(81166006)(356003)(47776003)(2906002)(50986999)(6306002)(6392003)(53416004)(6246003)(110136004)(7846003)(76176999)(7696004)(77096006)(8936002)(53936002)(2810700001)(6266002)(305945005)(54356999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2449; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT063; 1:EOSNm1wuRdbcHNMwLpFiESDM+G3IgQhYqK4ZHZZR4it0jVNW7ghYo8i0vBv8jVrMsh/hAeHjQrk47WsUy0c246/IrmbCY0U6QtNSEoHcnoYoQsMvcjHiFTSAcoFJLkqBq3p2t9vpzPUVh9Aow8zju74H/umae0lVB4B6eLrUn8a9CQtwxBNhjNbWU7ArXu0a9V3VY9BOwtiuNDDZK4/8ebA72GHzNjOawISol4492rHrfCrYK1EgJZ6kmrc/G0DAfRVQysDTuE+d2j8o8O5Y90wDBuuSudVLy7GwmFZeK55eY34kk/V4XYUkleMKw/jDfCaCoOIHQyRBMGnDWAUcd4Ckzfvm2Wd87nkf+WLovDE78Xgv0jCRFcmu5yw8sSKAjRpVxlUiJDGcFsgbe0PRz6An0oDKEnuYnOFxNJUX7t/bb6guH+6rg8Y9XPnLny6pSmK38IyGso6eifjLzZNhw49NEngWn1+y7og2f6WF7/6xqMxL675ShfxCW3ypVPcF1hSh45caaRr5TI5DhOWXFSWal6D6OO/4aTLaQvKdRLbjNMmg+3QCI2m5XFrO/G3R X-MS-Office365-Filtering-Correlation-Id: b0ea45fa-ae0a-4844-820e-08d484e22f18 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN3PR05MB2449; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 3:Pnph+6MYocmXHvhPrrDBk5MKM6PW2gG4qFjdLgcDyXMDUdH613Ge+r95hdUWmUOKwDt0ChC/frshqvYypTtJYQFffMGvaek7hZqhmxdbD5GdTTc9aY/S8l2XqnVwXrFyxuGTKjmTsd8fPi+ZMh2y7JyjNUI4hOVXplr6iJdCzcMdeWxWEEwByZHg0dl+x83Mi6Vy9ZaXrb5bS/x5jzMvZz5fojCS8YW/z8DETZ6sM4kypVAtK3WCHgJxTwIzS0TsVZC0o+gu0rmt+stejYNNbz/aIDjCZB9ztcBap3vGjcYWoXbosKvlM/OxrGUfyjIG1TLJyj29PsT4UBW/DEdpJ7QHTHD58aXEYErQDDOOCs081NJOtB8NHT5MPEOzib4SU5u6lRth9Zr7qVBGlNpaQ9PK7ReOBkNlSeUwgasD6VuzWUASxoeYRXsiUeSPcelliHu+6fNcu4p/7xWLVZkQ4g== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 25:YjqX2CuooZe1Clg5C8lx1mXMv9J5Y6WvY+AgJrA1yz5iZX/JkFncpYosbHmRwl+3UvGjTpWJqG9jkBAOzretBdALlsEovfHCajIIEl3/Nx0g3ErjdMfXz9IDpyskGhD4WWZeSlkov/1JUpqBq23A42mQN6PCWvSKh4PpN994LdAYn38H5lCAgwtaK111WH76ko1Rk60bg3PSn24UajX1HwERVfI+qS2kWWziPEESP2qNlArk976QgORG8RqOYcF4WNEqVJ9c7mGIES8Ibw5pY8AM7pyzI0Mq0QHJyjCC53N7BZ+RVddSX9qU7h1TK14fq33ER+sfwMvpL4X0w9l/53vtdNGEHDtkNYBmBihYMkI+WiGbns+XYfR2B08AFoYlI363piQb5zwyziVrQB+8sasdzF4+2HLB2PN/aO+rRtDBVlOrOqTObuFxt7G/z18XoqxCBwNDXixO49Nto8WXsxwzRurRlmopjFU9LiJ7TSE=; 31:KTkN4THx0vvvdQ5f2XzHvfMKci2uHx3Kz/Hn8PtM6yOryEVWowPuIXOEUyVqQJITWRUO8XpRddWY87SWaeBguU1Uj8TTyGYZVNR10aXRsttOivNb/JrruRWzL06ZMrfTidCevs7slR8lxkroWAP8mgG0g9S0wA9vklQ7B6+0HKBnJgfjCHJqCR4G8/zJ57YE5zvZFheSIX7aaWX25JPvPpYSBr+jqCo64u/dqc+r97sYX1jkkK/v79xBqJKjbHCQFETbjwF3DRuUlklcE5Zbu+fS1qIlq3V/FnW4dsr9ix8= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 20:v9UrHSBOACUHp9x08guJbeeydYRtDYQ98xSbRq5+gLaCG9NOSfbNsL+lMC3BNCOg+NxKOKX8WIRpS5PDDaqHNSorqJzsC6/DBzQcZdN8GOSYRjPvD4Ze88Ni+C99ZYS6mvwpGPV5QnhKLEu9277qrYVnCaX7uiVzSmWDjuntNx/raoOU3Tidb8cJtpR8sNiNSLZ2dBiiv7mr/6bus009k+AzH8eV38NEZe3PLKARfuTVsdG1fiAaEaiy9TNKGeHNtYjxUFydDF6brRId6PoxvYf2zNpP/NnQZjIylQ6Xbtv60kuVE9t+LFvcebfXkeg6/ifbtDxhAz2GRgGxWWj4bwP0X7yIFxs44wtYtE/9/KBV7YG4oAVdP7C0H+7jZaWMl27lSO1Rb8z8n3Df9KA/9q+1v5ycmMx547KybDKq/CeZxQeS6rCUq5vcGehRUvefJGeP/yly9tnG6EOF+kTrmSpPEeCekWUv7FjlGEsN/FEQ3GznDMrI3IrmdvInYtgz X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13015025)(13023025)(13024025)(13018025)(13017025)(5005006)(8121501046)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR05MB2449; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2449; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 4:Q+GpyGsBHKWLh1mdiMv8ue5AZ5Jt9+QG9a35m3XQDay0ncOCV9qkA8sTEbzB3JkrBECTIxALZyNda8lYDtyTGDINPmKkvKQshGcbyuduw5cxK132qlZqAaeRn9g7TCNz5pAvPR33SXS7epxER0W4+RUuPB1pSs8lzUlw4KolicfxPihnDE9z6ibL6cBQgAlSuyozfrRhTuROXCj2llSrQEaQndL8d2HPkYaziKNlWslxHnRFoJlHLAyBOeRJQV7uAmlEt63U3j3y0FBTsasjE8iVeeFL1/cY/agKrmXO8lNy3Ngwe0qOebRqeyEANlvpc1qdmf4jkXAwQKUMdG/aRuHQMC0/6Qj38HxAL0w3NnzYH5NsScCKhMK2UjPXJiSnBKGu/bSJ1muENemHdKgmh9U4uDr6Kn/mmIZs9QJLrhnmQlb/gsG4/ZTFM15gzP4eLDrayH+w/wmVE7jKD/Jn1VcRe0rsdpOddTvfBdblGhgWCAokPnXH5buonHe+DOb8G06Cean8fuZQX92Pw9H7W54os4GWgp8OsowgOUB9dFpG4B/HQBEr0XUSUoQbu4NLV0aXWhOLhH20uCQOdKM6n2ZhREkVzIBec7ZnzMQPTiGvcYvl0+f8ADalzyNZDqc+kOu4pMPGk4TJMxk2dTBb3CDw4MqWMSy1kWXM0empKU1eWqjYORD7IV5qWlfn4LYL33TqQzonXUfuaG9wnwD/TXMzSpW6FbHK/o1RKLJKj3+xHP0LuCHOOsBHqmNFFNwILkyQHp+M7CBDJFtnnGTj/xvXP6NRrrDF8UwycGKW8q6BSoMYwu42fwKhooMafpHh5xN+urPiRBCGdSrKgR0v3fmCxyDVO0dAGaG7QAmBmaj2y9z1m/6hOkdNWc8c3Oqg X-Forefront-PRVS: 0279B3DD0D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2449; 23:fVnkcgX1YQ8DnEsMgG1bSKFGX4MmCDTUWSOaz7bKj?= =?us-ascii?Q?i2ufepmZrfCtlv9jR1jHhyH+vnjrNMQlgGxOierN20d9RviLDu8hmmezwThh?= =?us-ascii?Q?Io/eqz+2wwd0dfZfvLBTbC4zmhXCUSi5sr6ThgtB4PHAyhawi29CHlu4PLxh?= =?us-ascii?Q?FSDKLrNv9GHHso5JMXkZ6j06IPipP/qaEypaA5lK3uTDpMnZqQCjSduW5IZs?= =?us-ascii?Q?AzFeCr7IpVuelwABC31ltKoPG1KU/37QHDoUcwSsU3tv7w7/yfWANPJh6Zwf?= =?us-ascii?Q?Cn1EnHHfPA4crS5l1fSiWtft/IDGageuz5E6IQ4omGC8yQOoYSd+t8Me798R?= =?us-ascii?Q?RkvMqAdXfth37sNCyDE9C5WR58BEFrmc2Bxd4bYdSOdSMcdAPc+BK9ZqUgB9?= =?us-ascii?Q?aol/jRoMdZ29CgiXfsEAHO9YhHWvNf+2bU7nhDZSIdqJ/I+TEaCEYEqmIu4x?= =?us-ascii?Q?I278BRwam8C2Y6n9fE0RoEy/UwtgNT7lx9QWFBO37CdqhvOQaDR9/3SG7NUs?= =?us-ascii?Q?aiDUyssKA3J0vV0bTd4PAccSgaU4w8e5M301LebXZ32gJO7PRViCs+cAqDiH?= =?us-ascii?Q?LWwVFjwAZ5AGPYZMyJ7Vo+1CwGM6wgLzIRQP0shM+W6pVA+3oW2z3lVST6aD?= =?us-ascii?Q?Ic6GSSo3jPaW77Cl9j+8fVes1izz+qcCpcgmw9+krH5WQ0LxZSzVSdKq/MoV?= =?us-ascii?Q?AIvDgaw3x1CKz8N/j2HHRxdCa2oKbUBdEZfDOI3nlqqLx8PeUozPob9MNkka?= =?us-ascii?Q?jPAoOWHswfKrNIYG/GYDtP/4c8P1ePmbRb80Y3VcfhIeF1FPKgoMkXk8EkWq?= =?us-ascii?Q?6hTYFyj00s86iys0e4eNPNtEiVbUEfOnorMSBt6Ue77XoUcmglcq459XxWn0?= =?us-ascii?Q?/NWy7KciGWTO5dUL6mL56P4nmGZOU6rBJlI82/c6uGuWWf+aKOwEmR+jL/1B?= =?us-ascii?Q?lotycusq7PbwxlRrq5S54JPkTw5enBKz1dn4KovRYmC9pnSksFjhKJq16mjs?= =?us-ascii?Q?DJaVguzb7cVTICq/9FiuZXZAHoAjCf1RZx0rASoDcJzZwl/eVpfkxR4CjArZ?= =?us-ascii?Q?z5333WlfCLvYse5InX0jP0RetLYoRhSiaEtLoTeOaTrO8zn0JWi7vzuFf0Tu?= =?us-ascii?Q?wWZpmebZzvoM3VHvUrWeR9zqJpYka2KBbRg5cONcaCX5FTjB8g8fEbaqqYdV?= =?us-ascii?Q?WInpr/Xdnp5QGzct2kMRmizRi4+gmXjYRQmSbXZBtaHTZLAlY541mjcFg=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 6:+9PedOfoUz7V83uGbHcWTTHavq3XGxfDt4L+Um4oGBsDxtlokt6VXaPsIMbpWjNiBdwOWMuCyBrJPK2xoa/oxtajRY4tdUjxKs99viYxFojfwIA3FtjZzcrux6Z9Rsl4SNWAd68J+SCZrK68j0IsEQW/2OCyMQQP8c5wEG0SPMnS0fqC70rSBRmmwzLXmyNe2+YT5oEXhULjI/3g6YTz4f16Am0oG4ICbqS4g39JHk0xZKS1rZ+8ZvNOeAp3ylte0JNiqQ1ElJzRYZsXnd3+uKIjmHRg+VCsF9aj/NdFhTMEB5Ctz+QjSyuxsqeWZhob/dvRjgkwEO7bUQLJQJKA7nafztR9DUlIlG7dp3Bm3umR39exQ8EoMR6U3hVoRZ0lIpJS27RtymJKPiHO5XJnzUpibbpisOWx+jKaZj9QQuIp1j24KOlNz+/d63Fn5LlhG87oN4oCYkXxz2ofRDgv5l9a8y+reTNlYGX2EBawQSE=; 5:4FL3s/X0Di8vXay/LCF11lkhMbFv7Eq57pZk97bg4p6KERG3ARMK1NAD6ghVwtvUY64giVDXbqPg8XaVGDGYSiDwUGKcOcFfeLEJ3NFLkzx+a8UG3u/exTm0NlJHaT2Y9yyybVWjnHBRRjrZUG9LOw==; 24:nQM0+WQUGPPdkb/b/aDslFKRg8pyEuAg0mpOLiCVOYVuNCTJq2CA8LTMyaIC926wcRhtjWtkz37A8TG+Zy6jXdG5KMIIV4hrKC/F7A/vt/E= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 7:ch8NDAwMrUC9JauZc79ldP7NjyUSYZyRwak4CUOrpjtIVdrAFkStAFF2nvxHbZNIGdAUEfhuuoYPM37DzP3LR/13H800UintduzHTdp6EV0Xq6k4v3i7rHwyxUfR+dIplviD/Bhi5ISIU76RTSwEvJo7iYKMvE3tBe1Cj9Hx6JwXH56zk7bn8k18Yue3UmtxoOtgHSy0eU7+vh4j/08im+SI+M4ZsQ7YgrWJtmck329qlml/t3/oCtyRdZ2m6raj3gnwVT/krDM4R2+lk/BhpLuUI/UMSb6LlCgfcq+OXXJpEb4jc9g7ImEN0f1J7dmZANqiMn6N0+3ZOLnogzMHqg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2017 16:03:55.1365 (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: BN3PR05MB2449 Archived-At: Subject: Re: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-08.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, 16 Apr 2017 16:03:59 -0000 This revision of draft-ietf-curdle-ssh-kex-sha2-08 addresses concerns that the criteria reasoning for why each key exchange was being deprecated or recommended was not clear. I have also addressed the id nits. Feedback on text changes greatfully accepted. -- Mark ------- original message ------- From: To: Date: Sun, 16 Apr 2017 08:43:01 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-kex-sha2-08.txt CC: 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 : Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH) Author : Mark D. Baushke Filename : draft-ietf-curdle-ssh-kex-sha2-08.txt Pages : 12 Date : 2017-04-16 Abstract: This document is intended to update the recommended set of key exchange methods for use in the Secure Shell (SSH) protocol to meet evolving needs for stronger security. This document updates RFC 4250. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-kex-sha2-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-kex-sha2-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Curdle mailing list Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle From nobody Sun Apr 16 17:30: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 B13071293FB for ; Sun, 16 Apr 2017 17:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 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, SPF_PASS=-0.001] 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 mdLTUCCfL_u3 for ; Sun, 16 Apr 2017 17:30:35 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 04250127601 for ; Sun, 16 Apr 2017 17:30:35 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id 75so59213694lfs.2 for ; Sun, 16 Apr 2017 17:30:34 -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=Y9Z5KGKoqx0dHvKAQ5USeRaT7rlyuF+eO5TFKM87h98=; b=NiUXDuS8e6Q5QyIYkTZcBj+72I6tLR5/cWJ4Ya2v/AeOQSUA2r70a6UouufTNLLlRY Q6O7CZeD09GH2S4PTcgMqSi1rtTMrFMXdbC/axILVYymCQ9D83AcarVs0dJ4nFNtaYgO /ZMjMvGNZzABKes3jge8D2OO7RJnM/piKAqmfkkQAfihJSUS8IxtTirguL4BZWQiqWQD gG0RfBNgmnF54+E1TRqvduJ8Sf2n1RSC/1M3i6I1P5bM3fV8f9mqbU0Y/w83ulfnLIJv t6D9sraX6SVNF9gDOG20cpCIyx54BF8e+LBMyz6LnVUhAN/moHFKUSuYmkbFkF9MqsMm XqHg== 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=Y9Z5KGKoqx0dHvKAQ5USeRaT7rlyuF+eO5TFKM87h98=; b=pO/pHwoUgqTL7axcUBcaWyotxbR4xRh3KsQHmGIfaYsRemhDd9EW7ly1EowQ8rBJTc LvI9dnoDy+X5VUD5SreEI70B4/NdueVoIY2sP3EwzXeYa9jhEiuiGt1SgAroeRdtvg9Y fBOf6nW45SKDS3w7VPOCFRrKqslh43rbex7jG8GUTSqY7vaJ2JlggoEReWPdmMlSfMnd UnMGIjnmSGiGejZZt2K9Jr1AMA/CmY1cnOv3gNbj3oGn4AGFT3wDEzrtTBCAIEg90fVW EOfcqj9nC5/3vmqEhjImlu/XcQeHDanhkgEgbPC59hQn6vCcl4b13kuOMdljGjsD5qvn KnsA== X-Gm-Message-State: AN3rC/6eRJurleg04aayHgGCYldDQ4f5FrTUE02bX/a47AGqjO/RP5uJ d1oacSFVeKj4fu5cKSbwbMdP5FXF5WCu X-Received: by 10.25.23.32 with SMTP id n32mr2038465lfi.142.1492389033187; Sun, 16 Apr 2017 17:30:33 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Sun, 16 Apr 2017 17:30:32 -0700 (PDT) From: Daniel Migault Date: Sun, 16 Apr 2017 20:30:32 -0400 X-Google-Sender-Auth: 8buc1shfX2qyEmVtzBNQwV3v__U Message-ID: To: curdle Content-Type: multipart/alternative; boundary=001a11405806309df4054d51e61a Archived-At: Subject: [Curdle] WG status 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, 17 Apr 2017 00:30:37 -0000 --001a11405806309df4054d51e61a Content-Type: text/plain; charset=UTF-8 Hi, My understanding is that the WG has reached consensus over the following drafts, and these drafts are ready to be sent to the IESG. If you have any comments, feel free to provide them as soon as possible. draft-ietf-curdle-ssh-ext-info-04 draft-ietf-curdle-ssh-modp-dh-sha2-04 draft-ietf-curdle-rsa-sha2-05 The following draft is the one the WG should be focused on. Please provide review ;-) draft-ietf-curdle-ssh-kex-sha2-08 The following drafts are on call for adoption until April 26. https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 Yours, Daniel --001a11405806309df4054d51e61a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

My understanding is = that the WG has reached consensus over the following drafts, and these draf= ts are ready to be sent to the IESG. If you have any comments, feel free to= provide them as soon as possible.

draft-ietf-curdle-ssh-ext-info= -04
draft-ietf-curdle-ssh-modp-dh-sha2-04
draft-ietf-curd= le-rsa-sha2-05


The following draft is the one the WG s= hould be focused on. Please provide review ;-)
draft-ietf-curdle-ssh-k= ex-sha2-08


The following drafts are on call for adoption unt= il April 26.
https://www.ietf.org/id/dr= aft-ssorce-gss-keyex-sha2-00.txt
https://tools.ietf.org/html/draft-kaduk-kitten-des-d= es-des-die-die-die-01


Yours,
Daniel
--001a11405806309df4054d51e61a-- From nobody Sun Apr 16 22:15: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 64A4E129486 for ; Sun, 16 Apr 2017 22:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLAflCdd-AkA for ; Sun, 16 Apr 2017 22:15:27 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0115.outbound.protection.outlook.com [104.47.41.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E6F129483 for ; Sun, 16 Apr 2017 22:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6V+fJFRCwuGxju+5J39QieFMOIcKHQG+2SESWDySjm0=; b=gMbbYHaoVZ/v/E5ZFT26iYBhD3IPKrkdKnOeIY29VWIYXbF5vYtZqvuquhvEWRDdc0xh731DgS+nMNy5Bp8o5rZV1adOaIj2GHb5smbWJfYsEKDKSVts2pzA49jjMfaxyO1zBwQK18foarhqGawwYffVDDaWvbrYSRY51awYPVU= Received: from DM5PR05CA0022.namprd05.prod.outlook.com (10.173.226.32) by BN3PR05MB2483.namprd05.prod.outlook.com (10.167.3.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 17 Apr 2017 05:15:25 +0000 Received: from CO1NAM05FT009.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e50::208) by DM5PR05CA0022.outlook.office365.com (2603:10b6:3:d4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Mon, 17 Apr 2017 05:15:25 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 CO1NAM05FT009.mail.protection.outlook.com (10.152.96.116) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Mon, 17 Apr 2017 05:15:25 +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; Sun, 16 Apr 2017 22:15:09 -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 v3H5F89c027399; Sun, 16 Apr 2017 22:15:09 -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 7CE4511446; Sun, 16 Apr 2017 22:15:08 -0700 (PDT) To: Simo Sorce , Hubert Kario CC: From: "Mark D. Baushke" Date: Sun, 16 Apr 2017 22:15:08 -0700 Message-ID: <39113.1492406108@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)(39850400002)(39400400002)(39410400002)(39450400003)(39840400002)(39860400002)(2980300002)(189002)(199003)(9170700003)(6266002)(53936002)(48376002)(6392003)(50466002)(47776003)(4326008)(7846003)(2906002)(6306002)(2810700001)(105596002)(55016002)(53416004)(76506005)(106466001)(189998001)(77096006)(5660300001)(7126002)(305945005)(356003)(229853002)(230783001)(50986999)(8676002)(8936002)(86362001)(6246003)(81166006)(7696004)(38730400002)(117636001)(54356999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2483; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CO1NAM05FT009; 1:VLDRgRfQNYO5IImCYEkoIcDFc5imFRfzeZLAC6xQlFl+VxAzzNQqpTGRatd3FnkOnteC0nmgCIL2xSZtxlxJLVhjO04qo+CGoGGMXSkdqIujc968AQccyIHqvRHBx+cA/KgF88xkuhIb0aDRwJdAcN9xu4o3nH2W1KK8S0z4/ABJ4uAczH1lDyMVZf+fVQcLLrGtChrLy/vaiAdkmXcwg7fdNu3ML/S97szVWaoEK+SOIoqf+ffntCHl2Vln65JMlgfXLQZOETHUrdLdUApAacTbcBLN3i7rGMcDusey1+3Zr/bLhtBAWgeQyX2+NKS3F1id+Plpspy1pnGEDY4MNDZUfrGtk5I55vM40+Ne/MFUu8G/EM5K2AjNDQ0wv2Btl1azEh2rPPpdyshXM7QaxyUs0gGZ9i+W5R5/sCipatyffCQr/t+cfD5mUPR1yHx1INVXbuV/ZFNTXYxaczZfTHw09PHvO3PqUfHqd1dWp5cwKuxu+ECAdAYOqt578D3BeFmyYCBPNdf/KFhLZq8ZHT8mK04M8IySkWloLeG3D/PEhpgqgvDLi3u4Rin2g6W1ood6+ZZ+DmTU7hnF952udA/YSdZfAtWrBZqrfrudsnI= X-MS-Office365-Filtering-Correlation-Id: efa3c344-1b4c-44c7-8f79-08d48550c161 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BN3PR05MB2483; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2483; 3:Rw7se3MYKv6eUAC9lKiRe5E76+NBrrVRR34rRAZF1y7tJeboozff72G4xQFCBkDm0BYYpGSLB75BGraO0f1XwdL1FvM/O45WwEoLPkRztcTQp/qbfOkVXgJC3AFl8D9jOBKvMGdMTkH3alEZTdnavPiYH9BbPyH6GojXlJQdn93sKcHQOuRTkKrIlbQ2Rp81DK+/e8+UROLwx9dcHAEPF8GB8CTd3Fzn2upRNsTT5prRdiSXor2RWnUpQqdL3PG7to3k0N3bY+BzvamSosdUCG58y7kZjFLPA696KuzYdRFhiFw1RbQCPSW4sLL6qTEn5FgNTDltZWozbKdgJM66S9jazL4cnP0kwihg0pBnfRjMLpfOlSdOgtT5q0PXuopDnBep5EN6S1jwD9oBB5aWk9KTS6TwgQZXl7HF5MTtkAB0jjLNPs45viKwfTO3vwrhFZfkyTif976mKZuQtEQayBqDXP8U4Pd/rpzwtCLUlX19gNuo0cfpc7phhGhVkWVC X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2483; 25:vBsfBxQXRP/U/L07iBPYkm/O9Tmd2Eb7U2lF4L9qPAFrZRd/UIRKIjxkpLN2/T5d88AWfI297AQciJm/yVNQ8xIyeuAgVH0niSsMmBmgCWKFnI+rgZmMLPTbsHkCVX4KqUEpnDyiB9blRJTlpaNogotl8Prxw/l2n81AHcQEdhPajv8xO8wYT9wHzbx1ROYCqSv1iCJt1dma2DzxAEpVqwn5cUiHCOEDFoa6mp1S81AZEjodAMvLF8L6dMyfh7g5Impj3Itl49W0+Zctabn2yqRZjAZ5PhOqK6a5vPShW60dRjNrz3B3EawFgH+21KnuREWzxFJ7Tcd20zmXSNWlOc98bQtJl/olV6mhNZkieB0qKZ25adh6tBQNJL3X3v51Fq9j0F4a8fuuz75LANnm26/FLyu7FtyDKQSVdgTKKA7gmwrKvlFFH5C0uoXTKkh9XIO11/v1Qni8GI/VRJPPBz7QcyV0uQX1cuNH5ARPXsk=; 31:W0VdwBmChjnZTShIolHj4r9P0/qPOrGe/BYvYhdCFCYnfVWz7VdIam+ChpkBP1BCWkvb2M/QAINi0Ot5xPwrAWTW/ujHxY5ShLDmbouoKCnqrU2kdB8FvWE9VBMJXMzA8K3N8kOTCJyBOcf9V2ld4dTKjmo8gqDJ7r1sHqwiYTVrJZYaTPWsYHjxasIFqpnsjfK9TzvTpqwa82tPqKfwu+D7iVqECCLC5gBJdTjeKlmQoeaKeuFvpitEr7r3rFPl X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2483; 20:jjUllqnJBZh06NClaFAj+W882zlAgnKDybfCqtK8VX6NamVdB/gbPfYE0EGunE3mx2SwPl1LxWIaaVG3xQIXfL6ri15IN3MMAe1o25juxPu/bdm7Z07VbLIYkKpI2N0gEeiO0xIJphhgNKWslmWjUp6Rs+T2uOqq0xn9Ev94IzibI1Wkz3C0hcs4bgaie7k9ZQ0bd4UKjeSVZgLrE4Mh24HgC8WmxbgqJg+K9JoqPiz1btVeVLbZpcdd0q9hD993zXkH5ZNUnWjx+/IxF4CryfPuWAmfPHAfQJ5RCGwYQOOYm1rmkYpGKnJXnVtOtE2U8JSl2sYczpmGIaEP12MDDyKl7/nWXesfXuQumxZqBXBtN0jAfRb1JfPiQ9iEPXItF+zstviIvnHRdJqivLJFUg9qo16nNQ3xDAfCnVsOyvkh3zTyJdmCY08ttcX1Hr+1kAbZymTfKXnWcJmst3AwzlZ0xPteD0Cd22BYf2Dwje9fapPRC60kuzBHykdgomwr X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13024025)(13023025)(13018025)(13015025)(13017025)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR05MB2483; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2483; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2483; 4:1YiedWjOzMPL1Ozr/ttBNwy1ypBj/ep1wvL+ijC/FcN40yd3kny5IPUV93F+K0MBhs1hAGxsV2v6GsrIJQ0fwBC6u9j9Ar9s3jjEgNOjv+5+hHr4xt+MAj8siDrYRJFLkLhNN5qZw3N+hzD6RWC13fAQ6dzJ72r/PpnZGIfFXm8wV6OEaopQg2rbocY9Lm3zQ9af9q07Q1c/y5X/1B55cQlhQ8OGes0nog5RCicOSYljHdLapoZlf3qMW2EZnRcMx4zT5xuF3iy8sp1enx/DRCKVfTZ4Y5rlmoyD3i/Vgcg6KNHJM06cAa7EZTYyIo/N6m51l8bOLW/hXPZeqxFFg+6XDsml2x5BXSLX7hSOP2OwOhFWLu6vJsV+5gb2+d1ePX3IDhWKXutjVFt1fZtoIEkOfBdYRMUwDV9IhbJy/QL05Pgt0NjEVWCRNTettMQPCZ0ybYtcFuGWijG4dR9NLeiW/Cxrd1GOAI3fCrXjtadXGXrQRNTg3KCHxMALczbEfQrgRDBxPUvH6L6ey029H7dPxZTprbEfjBF/79BAlC0vv7sdXbfcDqgD2aBGM2wmk6IF5Uw4ibd/ESTdQKMcAbop3A3Fsnt8w5OQrKmTkNcXZFJSEGyYSmltL2cnLskFA4oteTqb5DBh/TDexnK544/nUcsYsaaHfvT3Edluh/Bcwm0YtP9uCme/27Ynl3qP8p9ZZfVfr0nE6s/lTdq4F4h+4fc1nmyLWuxKpxTAdEJv4mjaj92HNvapBrV0fn0mtkmc1J0iYMlNfCPoc5Zg+aM8gTN2dK8cJ1KX+Zdc6Wbqn28MXzCAfQAk1QoBEq/ls6uDhneOLOxmsEfm/4qR8vbOwjfZz0eQB1G5R5eQuNAht88Wp/gNo4YXyT2EGI68 X-Forefront-PRVS: 02801ACE41 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2483; 23:FYX1lmR3xjXrhGazfphJ4h9CKtg1C14jdsvwc5cNv?= =?us-ascii?Q?1QuHuE15kw/4T8tDXpb6lHVE1QBJ09l8UWYByOGilbJKjgpKW+gO8RGcMcv0?= =?us-ascii?Q?a2h/banRUQJvpv0JBVuaCuoUU5VzxduRjijoHgSyIplCZudWFqixViE2ICbI?= =?us-ascii?Q?R7K5MznzN0RgMtmBruskHo6xG1dyOyFOBAqPBgnhJSOtt/oS1P71Xq0jw+MS?= =?us-ascii?Q?yCBtRD5hg5NgeX9n0+7XB1V7zsuBHKF7Lonhr6dFZ3vus1bmEBM/zpNTWMiC?= =?us-ascii?Q?W74GzPx5YDV3hA2uY80TOiyEQ6NlqX4UtZXAsINeLzC6Sz/siC3mC467zGF2?= =?us-ascii?Q?2oH8oCzFxWYbYwq8QTbxWbkqlF3mDN5NYIcSJ2SK0nFlq4ifV+AyCWar3Lly?= =?us-ascii?Q?wxPqfelxN+AqmJ2BjwAPRPEWf8dqE3NgC0+vGaX7ePWmav0Hw/gUhZo5RbRA?= =?us-ascii?Q?D1Qv6Jcpy3Xf4a92kWVR3iSgrKZ/Y+qE2FSt72IXRjV9vGESDzWmtA18kMkz?= =?us-ascii?Q?d78LhEkxQhEBSizulCjHzlBWOI2Wkae3YboJj1l/i5qUbzQJtuMOwPSk90Pt?= =?us-ascii?Q?SSa7Whclos5+AnCxgYO2NrFUJ8OCF13Ziiwtmh//fIyAOVgoFqyKxzxoCt0+?= =?us-ascii?Q?NNopOYW3WvM3I7QlA4dvTxRymp5R77QBaP7FQzetbJrY1IG5w4IuUol90OGO?= =?us-ascii?Q?w1YCYvvEnR/jITw0qpqvgYliGsaTdO5lGQeAZW82LG1chMLks07Y/STaFNiW?= =?us-ascii?Q?SZN8gjY0s4f5fbroYX8iGpbLgJiufhILI8Qy9CL06xThdgeXLUUjitHR6Mwl?= =?us-ascii?Q?EZJIT8jAyb2rwIHlA+BGL0t/hkGj/oSLB30sXaMbsuGwVsFspOOvObtRhKOT?= =?us-ascii?Q?KxNu7DwiA144fj6UroIP+9AlMkOCjDl8XzunvPWUfy2jZT4lNh8JTUqKklRA?= =?us-ascii?Q?boQBoig+V5D+TebJoYVkUFG4Pct8g0shgkzEMXx6wC3pujf538PrUhU2qSh6?= =?us-ascii?Q?Ql0tCxcFTITyt9vBVH+4cISO0sFjOE/Z2i7vIE6AtBdIImWmbxX1kyymG9iO?= =?us-ascii?Q?ZFXx2S9OdJmmtwxeQv0oAahj0L6J7jFN2K30WwwOk4Xamf9o7R1WG5ccmUHl?= =?us-ascii?Q?WpiATQDi7KlR/kHgDzIK71gu4T3m1T/?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2483; 6:WKSn8NCJvhLSRY13FTg0sj8VKhj2B3sfppka4gx6HzAnSQMwk6gRaD00ZZqdOvzXCuaT5oCeWGd5EZhCTS7biAdiMV67EgyrVRUXJmqoG76Ue2ZMHT0Hq9uUzXA3y4d3339FJXbag2R2anLUialujZSfDcKeDsRcnJetkGNLy0BQxETY94ErhAVqk6iACoFUts1TlmxQ7KESUDICjjrJ2/aCluxK0u2Rphy4dFsxryMUGHGGgru4RzEUrbIZT3TjIrgBe7KQWQvdr8jsM/OsPMlDuEQ8bdpKSrYn5ZU9WBNV//88bHWpc2dRDlFeiTsxJ0tBOGVKlJLWUmPDcPHULCJJ3gMZLu1qGY8Q9iaYFKJ+GpqTe+dWkbk18bwhVbnaX288ZIhS3fBDv7fXLnmzolq5lTPL37gim3CwuIm654gT7k+E0/8bSVvLpQPuWUDo2bta6k1Fk/+SuXJ2+3YRJuW4s1yLHDDQPgHNF/cdey4=; 5:ZF9023JsTy59f+1DXgBi/udPwSc8+In6WNU4/IobYlk1WAUAK7TTD86eckN0547TAKi6UjguD7bpZel9b51HsgRVZ39OtmguXTOTSBUa1jSW6JMCpXM0X2Dugja2it2qOM/lNHkalYCuW7Mwar4k0g==; 24:5v1LIoYAm3AMSUIMBG7wd1jmSTQneQWA/q6+5oSzTKy6dLu0XdzVuBw6kFGo7ReQlcwJmZUwS5wUjB1egP+GvCMJHhbwKdCfzyyrLDrOSVc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2483; 7:BCrxgFXJaoV5gg5idL91GlDgQ8EVMxWxHkKe7KCMJcWmLcRAjEGvSCAq1rA0MHSO5R6j7XyU9elLWX9p4q3ooegCtJRXVJE2PaJTpwx4HJwX2jy9PZyJMX1fdk9V5GP0gGA8tVlDAthXaAtIj22m8zeBq8oZH1z8OK2iJCS0aFCQawPw5yFjGH3xqhH0HKXXttkLxPMkXh4ZFnaa7h86MfL8U2QedYOQJDYBCsr7qVhbH3gkZaq1p/r5FqZjjLQryCwGQ4oaBYM9eSovXYy9XBI88GP5+9UV+kAlplKPYZ/H69wNHiQB4c7CCbLgIc6lO4TP+UwB5mRjdSV5C0Qbjg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2017 05:15:25.1613 (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: BN3PR05MB2483 Archived-At: Subject: Re: [Curdle] draft-ssorce-gss-keyex-sha2-00 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, 17 Apr 2017 05:15:29 -0000 Hi Simo & Hubert, Regarding your draft: https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt The reference to the -05 I-D.ietf-curdle-ssh-kex-sha2 should probably be replaced with a reference to draft-ietf-curdle-ssh-modp-dh-sha2-04 Likewise, I-D.draft-ietf-curdle-ssh-curves-00.xml should become I-D.draft-ietf-curdle-ssh-curves-04.xml for now. I am somewhat curious why the same curves identified in RFC5656 as nistp256, nistp384, and nistp521 are being called secp256r1, secp384r1, secp521r1 in your draft in section 6. Is there a good reason to select this form of the names? I will note that gss-secp384r1-sha512-* should probably be gss-secp384r1-sha384-* to be consistent with how RFC5656 felt security should be handled. I do know that there is some controversy about supporting SHA2-384 rather than SHA2-256 and SHA2-512, but it has been argued that SHA2-384 does not expose as much of its internal state as does SH2-512 and that it aligns more closely with the nistp384 curve. -- Mark From nobody Mon Apr 17 00:58: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 AFE62126C7B for ; Mon, 17 Apr 2017 00:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, 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 8eVVJiB8ST8K for ; Mon, 17 Apr 2017 00:58:49 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (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 D43E3124C27 for ; Mon, 17 Apr 2017 00:58:48 -0700 (PDT) Received: from [78.128.48.21] (port=57320 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d01Yb-003YaW-7P for curdle@ietf.org; Mon, 17 Apr 2017 10:58:45 +0300 Message-ID: <58F475B5.4090504@roumenpetrov.info> Date: Mon, 17 Apr 2017 10:58:45 +0300 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] WG status 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, 17 Apr 2017 07:58:51 -0000 Daniel Migault wrote: > Hi, > > My understanding is that the WG has reached consensus over the > following drafts, and these drafts are ready to be sent to the IESG. > If you have any comments, feel free to provide them as soon as possible. Consensus? > draft-ietf-curdle-ssh-ext-info-04 > Hmm, "server-sig-algs" is misleading . It is designed against the current rules (RFC) that design "Public Key Algorithms"! > [SNIP] > > draft-ietf-curdle-rsa-sha2-05 > Same here. In fact design is for new public key algorithm, but paragraphs state something different. > [SNIP] > > Yours, > Daniel Regards, Roumen Petrov From nobody Mon Apr 17 01:42: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 7BC3F129506 for ; Mon, 17 Apr 2017 01:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 0Hfs2vRQb6mY for ; Mon, 17 Apr 2017 01:41:56 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 CC4421294F9 for ; Mon, 17 Apr 2017 01:41:53 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id c45so96158186qtb.1 for ; Mon, 17 Apr 2017 01:41:53 -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=yUQLjPjb6o4tfLIH1nQGQiCHYbVg/GsxA5Es/dMwuQ8=; b=BCuBAVgAH76WAHWjVkv6SSCptXyiXXvP8VBDj62zDH2p5lQrh/+Kkzt++K8/SyH/qh Pn4EVCEuhC8zAbc4RZbpZ2oib0ZNC8bA8p8y5VFQxTgRYtrJ0fj5ZGhYx5lGdXL+SM8d AOUJhlzPbae9J41aHnhNrtkjLVhp0PdCtZiPhnycweFeysjVeBgYtuEjmXPTZ5LdVTbA sQmgOR2rZNGRev8RkURHOXyws8pPs/fNV8+A/8RjZx8a25W1LhQeoM5Uy3NZd6hfHUPZ S23vuJOhyFIO4U1ODNBa8mG0AsMj71/sI01nUj51uw03355fUwjPJyBOPxLxTicJApRu FACQ== 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=yUQLjPjb6o4tfLIH1nQGQiCHYbVg/GsxA5Es/dMwuQ8=; b=pBYQ7U+7ORlVjo1QQayOZrSRyCGDLv61Lf8lQ5qeTKpsWItrwxBFQmjfZj3cpEvAyL 3P7iePP0blE7WI0SeYNBpx2EVQ5iRrSY/r6rPTvD/oM8gVm4xF6UVkNJpePof3GTWkH+ krNtXv7OSBOBvpUy8rJiNGKBLNiI+hUR9PY+81ljgh3B2hGIhBRwftFtavLWAMJwY6Hn hKwgBn5j3kx9krBWRUzycsWBQWWutEVnRkC5ao7K7XITXhzugBnBXRu0o2PfDARg2Pyx TCgml+D8tTYOniKOPs3Fh7ciU6TlbsipVgMJr4VV/jx0KFNG+Et17FtxhUXUJSZbdgNJ R19g== X-Gm-Message-State: AN3rC/42nboJQgIOo2AmElCrx9YRHrYspC1Ubk6RrvUwUYFs3OC3f7Dg T+ssfJH2AoH9cSSM+PmTaA1mgyf+5hkx X-Received: by 10.200.34.77 with SMTP id p13mr7787161qtp.22.1492418512980; Mon, 17 Apr 2017 01:41:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Mon, 17 Apr 2017 01:41:52 -0700 (PDT) In-Reply-To: <58F475B5.4090504@roumenpetrov.info> References: <58F475B5.4090504@roumenpetrov.info> From: denis bider Date: Mon, 17 Apr 2017 02:41:52 -0600 Message-ID: To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= Cc: curdle Content-Type: multipart/alternative; boundary=001a113ff8b2528fab054d58c3b1 Archived-At: Subject: Re: [Curdle] WG status 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, 17 Apr 2017 08:41:58 -0000 --001a113ff8b2528fab054d58c3b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I disagree: - The terminology is not misleading. It has been made further clearer and more explicit after your feedback. - The "server-sig-algs" extension has been in use, under this name, by multiple implementations, for over a year. If the terminology were changed now, the name of the extension would have to remain. The name of the extension would conflict with the terminology you suggest. - There appears to be no benefit to your suggestion. It would confuse things by changing terminology that has already been adopted, with terminology that you personally find preferable, without changing any of the mechanics. I consider this a bikeshedding issue, and hold you personally in disregard. On Mon, Apr 17, 2017 at 1:58 AM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0= =B5=D1=82=D1=80=D0=BE=D0=B2 wrote: > Daniel Migault wrote: > >> Hi, >> >> My understanding is that the WG has reached consensus over the following >> drafts, and these drafts are ready to be sent to the IESG. If you have a= ny >> comments, feel free to provide them as soon as possible. >> > Consensus? > >> draft-ietf-curdle-ssh-ext-info-04 > doc/draft-ietf-curdle-ssh-ext-info/> >> > Hmm, > "server-sig-algs" is misleading . It is designed against the current rule= s > (RFC) that design "Public Key Algorithms"! > > > [SNIP] > -dh-sha2/> >> draft-ietf-curdle-rsa-sha2-05 > doc/draft-ietf-curdle-rsa-sha2/> >> > Same here. In fact design is for new public key algorithm, but paragraphs > state something different. > > [SNIP] >> >> Yours, >> Daniel >> > Regards, > Roumen Petrov > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113ff8b2528fab054d58c3b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I disagree:

- The terminology is not mi= sleading. It has been made further clearer and more explicit after your fee= dback.

- The "server-sig-algs" extension has b= een in use, under this name, by multiple implementations, for over a year. = If the terminology were changed now, the name of the extension would have t= o remain. The name of the extension would conflict with the terminology you= suggest.

- There appears to be no benefit t= o your suggestion. It would confuse things by changing terminology that has= already been adopted, with terminology that you personally find preferable= , without changing any of the mechanics.

I conside= r this a bikeshedding issue, and hold you personally in disregard.


On Mon, Apr 17, 2017 at 1:58 AM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0= =B5=D1=82=D1=80=D0=BE=D0=B2 <pkixssh@roumenpetrov.info> wrote:
Daniel Migaul= t wrote:
Hi,

My understanding is that the WG has reached consensus over the following dr= afts, and these drafts are ready to be sent to the IESG. If you have any co= mments, feel free to provide them as soon as possible.
 Consensus?
draft-ietf-curdle-ssh-ext-info-04 <https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/>
Hmm,
"server-sig-algs" is misleading . It is designed against the curr= ent rules (RFC) that design "Public Key Algorithms"!


[SNIP] <https://datatracker.i= etf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/>
draft-ietf-curdle-rsa-sha2-05 <https:= //datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/>
Same here. In fact design is for new public key algorithm, but paragraphs s= tate something different.

[SNIP]

Yours,
Daniel
Regards,
Roumen Petrov

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

--001a113ff8b2528fab054d58c3b1-- From nobody Mon Apr 17 02:02:04 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 53D6C129513 for ; Mon, 17 Apr 2017 02:02:03 -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 qcvxCODWnIIe for ; Mon, 17 Apr 2017 02:02:01 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FF4129AA7 for ; Mon, 17 Apr 2017 02:02:01 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id f133so100340813qke.2 for ; Mon, 17 Apr 2017 02:02:01 -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=0C34AuyWKBUGux+D6uHL7z+Lws0IGG7WREYECHbB8r4=; b=AvMNAqDW/YRxKgTDvVx7ZX030sMoKogPceHHr7XQZcBvlVhJb8iZxbzVqw2K+g4ljD IZigaybuRngLikpPRtlwnhU1QlX/uTWH6EEOuuDn7E/BrEc7D0w5qQmz99ISuEPRyhGA +hRXQzPm6pye1v5pQ0XNP7laz9wibOP2I7wbGGKzHaAcaAGa/be1ahH1CwXnMk/beBGQ dj0RzklqlI8piAfCVpKgoLhvwZfbJOga+nlyrHTtAGGHEzzuU0veEgeXCIfRruYwMzlv zFTdglQaTOf8n6/k8hF/M9jLpT61lR0xa5bwqDa62TDFRaJzxgy9s0czabg7cke9hLr9 llhg== 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=0C34AuyWKBUGux+D6uHL7z+Lws0IGG7WREYECHbB8r4=; b=CeKvhHlqK5uZSrZBDY0+BoKazjRCGJUx/d2qiVIjCt171EqDOJ7D6wfgg41BGtnGXp PVUB0HElPYs2WRwdYgohTk1EfVAibaXCBb21SU9gG7ewIHOAFfL6TpMXAzevzGWCHudA S9AA6wM71n8Y+K3uYxc8XVphH5Hd1CoUxaT7dR1260OJL2vAWpPnFrYc5jHaOABoBqS8 C6PR4P5Y25+0sdtPSdRU8hYJ1OwP5rwW6wG5AMkYSu8s6zhXJTCGzzs0LGD+9DIfqbDA gQUxJkf1TmB7X1k2cXkQa/rv4Pt9kQBUim06WnvD/mBEGZ1xdv2DmtstvHCnrasYlSwI 1wkQ== X-Gm-Message-State: AN3rC/6Y0kJ8iRf3JjVGHmuirJpUgAe4m2f+twlsB08SVqsnHIPucF5k WO4qJMDHxHxvY+p/hemNgWR9rAeKmWTVaqI= X-Received: by 10.55.24.38 with SMTP id j38mr6908724qkh.289.1492419720444; Mon, 17 Apr 2017 02:02:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Mon, 17 Apr 2017 02:02:00 -0700 (PDT) In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> From: denis bider Date: Mon, 17 Apr 2017 03:02:00 -0600 Message-ID: To: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= Cc: curdle Content-Type: multipart/alternative; boundary=001a1142e8f24b0c14054d590bdb Archived-At: Subject: Re: [Curdle] WG status 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, 17 Apr 2017 09:02:03 -0000 --001a1142e8f24b0c14054d590bdb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK, that was a bit harsh. >From my perspective, this objection is exceptionally annoying because it's a single person requesting a rework of the entire document in order to change terminology in a way that in my view does not improve clarity, and does not impact mechanics. But maybe I'm not seeing some problem that Roumen is seeing. If there's someone else seeing the same problem Roumen is seeing, I can rework the document to change this terminology. But I would really not like to do this unless it's agreed it is necessary by multiple people (and is not objected by others whose objections are stronger). On Mon, Apr 17, 2017 at 2:41 AM, denis bider wrote: > I disagree: > > - The terminology is not misleading. It has been made further clearer and > more explicit after your feedback. > > - The "server-sig-algs" extension has been in use, under this name, by > multiple implementations, for over a year. If the terminology were change= d > now, the name of the extension would have to remain. The name of the > extension would conflict with the terminology you suggest. > > - There appears to be no benefit to your suggestion. It would confuse > things by changing terminology that has already been adopted, with > terminology that you personally find preferable, without changing any of > the mechanics. > > I consider this a bikeshedding issue, and hold you personally in disregar= d. > > > On Mon, Apr 17, 2017 at 1:58 AM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0= =B5=D1=82=D1=80=D0=BE=D0=B2 > wrote: > >> Daniel Migault wrote: >> >>> Hi, >>> >>> My understanding is that the WG has reached consensus over the followin= g >>> drafts, and these drafts are ready to be sent to the IESG. If you have = any >>> comments, feel free to provide them as soon as possible. >>> >> Consensus? >> >>> draft-ietf-curdle-ssh-ext-info-04 >> doc/draft-ietf-curdle-ssh-ext-info/> >>> >> Hmm, >> "server-sig-algs" is misleading . It is designed against the current >> rules (RFC) that design "Public Key Algorithms"! >> >> >> [SNIP] >> -dh-sha2/> >>> draft-ietf-curdle-rsa-sha2-05 >> doc/draft-ietf-curdle-rsa-sha2/> >>> >> Same here. In fact design is for new public key algorithm, but paragraph= s >> state something different. >> >> [SNIP] >>> >>> Yours, >>> Daniel >>> >> Regards, >> Roumen Petrov >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> > > --001a1142e8f24b0c14054d590bdb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, that was a bit harsh.

From my persp= ective, this objection is exceptionally annoying because it's a single = person requesting a rework of the entire document in order to change termin= ology in a way that in my view does not improve clarity, and does not impac= t mechanics.

But maybe I'm not seeing some problem t= hat Roumen is seeing. If there's someone else seeing the same problem R= oumen is seeing, I can rework the document to change this terminology. But = I would really not like to do this unless it's agreed it is necessary b= y multiple people (and is not objected by others whose objections are stron= ger).


On Mon, Apr 17, 2017 at 2:41 AM, denis bider <denisbider.ietf@gmail.com> wrote:
I disagree:

- The terminology i= s not misleading. It has been made further clearer and more explicit after = your feedback.

- The "server-sig-algs" extensi= on has been in use, under this name, by multiple implementations, for over = a year. If the terminology were changed now, the name of the extension woul= d have to remain. The name of the extension would conflict with the termino= logy you suggest.

- There appears to be no b= enefit to your suggestion. It would confuse things by changing terminology = that has already been adopted, with terminology that you personally find pr= eferable, without changing any of the mechanics.

I= consider this a bikeshedding issue, and hold you personally in disregard.<= /div>


On Mon, Apr 17, 2017 at 1:= 58 AM, =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 = <pkixssh@roumenpetrov.info> wrote:
Daniel Migault wrote:
Hi,

My understanding is that the WG has reached consensus over the following dr= afts, and these drafts are ready to be sent to the IESG. If you have any co= mments, feel free to provide them as soon as possible.
 Consensus?
draft-ietf-curdle-ssh-ext-info-04 <https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-ext-info/>
Hmm,
"server-sig-algs" is misleading . It is designed against the curr= ent rules (RFC) that design "Public Key Algorithms"!


[SNIP] <https://datatracker.i= etf.org/doc/draft-ietf-curdle-ssh-modp-dh-sha2/>
draft-ietf-curdle-rsa-sha2-05 <https:= //datatracker.ietf.org/doc/draft-ietf-curdle-rsa-sha2/>
Same here. In fact design is for new public key algorithm, but paragraphs s= tate something different.

[SNIP]

Yours,
Daniel
Regards,
Roumen Petrov

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


--001a1142e8f24b0c14054d590bdb-- From nobody Mon Apr 17 02:19: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 03E5B129418 for ; Mon, 17 Apr 2017 02:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJsciWfdFLi4 for ; Mon, 17 Apr 2017 02:19:40 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (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 E64CB129BB5 for ; Mon, 17 Apr 2017 02:19:38 -0700 (PDT) Received: from [78.128.48.21] (port=57560 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d02op-000Huf-Jm for curdle@ietf.org; Mon, 17 Apr 2017 12:19:35 +0300 Message-ID: <58F488A8.8020800@roumenpetrov.info> Date: Mon, 17 Apr 2017 12:19:36 +0300 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 CC: curdle References: <58F475B5.4090504@roumenpetrov.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] WG status 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, 17 Apr 2017 09:19:42 -0000 denis bider wrote: > I disagree: > > - The terminology is not misleading. It has been made further clearer > and more explicit after your feedback. Public key algorithm is unique and 2 algorithms could share same signature (format) - see RFC 4253 , 5656 and 6187. No with updated version you go in wrong direction. The whole chapter "2. Signature Algorithm as Distinct Aspect of Public Key Algorithm" is against principles of above RFC. > - The "server-sig-algs" extension has been in use, under this name, by > multiple implementations, for over a year. If the terminology were > changed now, the name of the extension would have to remain. The name > of the extension would conflict with the terminology you suggest. It make no sense to point to that exist implementation of "server-sig-algs". Yes, I know, but it is implemented by secure shells with limited support of public key algorithms. More over in one "widely" distributed it was broken until recent release. Practically this mean that is even not distributed in real word. > - There appears to be no benefit to your suggestion. It would confuse > things by changing terminology that has already been adopted, with > terminology that you personally find preferable, without changing any > of the mechanics. You are the author that try to change existing terminology in secure shell design. If server sends signature "ecdsa-sha2-nistp256" there is no way client cannot distinguish which public key algorithms to use x509v3-ecdsa-sha2-nistp256 or ecdsa-sha2-nistp256? [SNIP] Roumen From nobody Mon Apr 17 03:02: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 5AA5512EAF6 for ; Mon, 17 Apr 2017 03:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 KgtE03DgEwrW for ; Mon, 17 Apr 2017 03:02:26 -0700 (PDT) Received: from rila.superhosting.bg (rila.superhosting.bg [91.196.125.212]) (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 CE63712EAE6 for ; Mon, 17 Apr 2017 03:02:25 -0700 (PDT) Received: from [78.128.48.21] (port=57598 helo=[192.168.0.10]) by rila.superhosting.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1d03UE-000s7B-Dl for curdle@ietf.org; Mon, 17 Apr 2017 13:02:22 +0300 Message-ID: <58F492AF.3050100@roumenpetrov.info> Date: Mon, 17 Apr 2017 13:02:23 +0300 From: =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 SeaMonkey/2.30 MIME-Version: 1.0 To: curdle References: <58F475B5.4090504@roumenpetrov.info> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - rila.superhosting.bg X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - roumenpetrov.info X-Get-Message-Sender-Via: rila.superhosting.bg: authenticated_id: master78@roumenpetrov.info X-Authenticated-Sender: rila.superhosting.bg: master78@roumenpetrov.info X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Curdle] WG status 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, 17 Apr 2017 10:02:28 -0000 denis bider wrote: > OK, that was a bit harsh. > > From my perspective, this objection is exceptionally annoying because > it's a single person requesting a rework of the entire document in > order to change terminology in a way that in my view does not improve > clarity, and does not impact mechanics. It is because few secsh implementation support extension. I know only four. Next point is that existence of one implementation is not argument for acceptance. In current case is not used locally defined name with "at-sign" and etc. It is not first time that someone say but foo is already implemented and we cannot change this. Why? First precedent is why something is implemented as public name foo instead as locally defined foo@bar? I wonder what you would like IANA to register . Lest check following rfc/chapters: - 4250 / 4.11.3. Public Key Algorithm Names Public Key Algorithm Name Reference ------------------------- --------- ssh-dss [SSH-TRANS, Section 6.6] ssh-rsa [SSH-TRANS, Section 6.6] pgp-sign-rsa [SSH-TRANS, Section 6.6] pgp-sign-dss [SSH-TRANS, Section 6.6] - 5656/ 11. IANA Considerations Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations: In the Public Key Algorithm Names registry: The family of SSH public key algorithm names beginning with "ecdsa-sha2-" and not containing the at-sign ('@'), to name the public key algorithms defined in Section 3. - 6187 / 6. IANA Considerations Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations: In the Public Key Algorithm Names registry: o The SSH public key algorithm "x509v3-ssh-dss". o The SSH public key algorithm "x509v3-ssh-rsa". o The SSH public key algorithm "x509v3-rsa2048-sha256". o The family of SSH public key algorithm names beginning with "x509v3-ecdsa-sha2-" and not containing the at-sign ('@'). There is no request for signature algorithm. Please note and "not containing the at-sign ('@')"! Good practice to implement new feature and the to ask for acceptance. Plus the fact that five "Public Key Algorithm" x509v3-ssh-* and x509v3-ecdsa-* reuse signature algorithm ... [SNIP] Regards, Roumen Petrov From nobody Mon Apr 17 05:46: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 2DB8E12EC84 for ; Mon, 17 Apr 2017 05:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 LYbF1OsYl_aI for ; Mon, 17 Apr 2017 05:46:02 -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 A8A8B12EC82 for ; Mon, 17 Apr 2017 05:46:02 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3HCamNi020620; Mon, 17 Apr 2017 13:45:59 +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=y8TT8zfi6ntrvgpN1Ysf82ocnCvqMG496WzQEMM5aDs=; b=mZBCGUb2l41riqJktAhdX39yyMs4vCeG2QCFX9DAd/Ttp11mINVigWFxhKaF4w7wohXo mnOe7lNnBaFpbhBVhofeGxNWP3tppuTUAKRllVotwbMs2T/E9hFlicc9cUKpiLY/VMBQ 65eQsU4STBF5NZ19exDMf+ace9LBfGtf0wfgNVEsxec0Fds8m87QI7t/Vnv4pqG+QSgo bOKtfeFQ2Lyw6SPO7tRRcrg81aI0SKw7qlU4gBBBY3+j5Z8DxM2grFQpD8v9s1A6K1gs m98sBzn/XxpND1mp+eaQ+OIlvQRLohwwTiG4ba6FpzmwsB2Ui5+4afW8Sjj7yJZ8PJzC 8w== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 29ubx6a44x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Apr 2017 13:45:59 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v3HCfS4m002656; Mon, 17 Apr 2017 08:45:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 29ueuv2erk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 17 Apr 2017 08:45:58 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 17 Apr 2017 07:45:57 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1178.000; Mon, 17 Apr 2017 07:45:57 -0500 From: "Salz, Rich" To: denis bider , =?utf-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= CC: curdle Thread-Topic: [Curdle] WG status Thread-Index: AQHStxHYfP90vmq6XkS1y97PjzzGY6HJho2AgAAMDACAAAWgAP//6ocQ Date: Mon, 17 Apr 2017 12:45:56 +0000 Message-ID: <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <58F475B5.4090504@roumenpetrov.info> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.20] Content-Type: multipart/alternative; boundary="_000_1778170c976e43569d34f051bba51f4custx2exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-17_11:, , 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-1702020001 definitions=main-1704170117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-17_11:, , 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-1702020001 definitions=main-1704170117 Archived-At: Subject: Re: [Curdle] WG status 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, 17 Apr 2017 12:46:04 -0000 --_000_1778170c976e43569d34f051bba51f4custx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB5b3VyIHNlY29uZCBub3RlLg0KDQpEb2VzIGFueW9uZSBlbHNlIGFncmVlIHdp dGggUm91bWVuPyAgUGxlYXNlIHBvc3QgYnkgd2l0aGluIGEgY291cGxlIG9mIGRheXMsIG90aGVy d2lzZSB3ZSB3aWxsIGNvbnNpZGVyIHRoZSBpc3N1ZSBjbG9zZWQuDQoNCi0tDQpTZW5pb3IgQXJj aGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW0NCklN OiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg0K --_000_1778170c976e43569d34f051bba51f4custx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91ciBzZWNvbmQgbm90ZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RG9lcyBhbnlvbmUgZWxzZSBhZ3JlZSB3aXRoIFJvdW1lbj8mbmJzcDsgUGxlYXNl IHBvc3QgYnkgd2l0aGluIGEgY291cGxlIG9mIGRheXMsIG90aGVyd2lzZSB3ZSB3aWxsIGNvbnNp ZGVyIHRoZSBpc3N1ZSBjbG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi0tJm5ic3A7DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbmlv ciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1lbWJlciwgT3BlblNTTCBEZXYg VGVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1778170c976e43569d34f051bba51f4custx2exdag1mb1msgcorpak_-- From nobody Mon Apr 17 09:51:44 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 6F83512922E for ; Mon, 17 Apr 2017 09:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfaYgZwbjzbg for ; Mon, 17 Apr 2017 09:51:41 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8A3131663 for ; Mon, 17 Apr 2017 09:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v+Zm7swz+cb8VFDf5HeccYGMM5kTKgGUKJD7oZ+A6R4=; b=YheYXwBbf7Q5jJS+cQJ4zSGjsb1a4b4Ei5DzFDjvmEKurbqmDHRHAxPlqjbt+MsVFpUsOeKQAF9urJnBxMVLDw/Xp6FZ65ec157OmYLcXrHlOEdkQdRG0llqdClRV2pnffioHTaKZGfflNBbORU9w4loOxakhX1Bd0egr7VavC0= Received: from SN1PR05CA0017.namprd05.prod.outlook.com (10.163.68.155) by BN3PR05MB2449.namprd05.prod.outlook.com (10.167.3.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Mon, 17 Apr 2017 16:51:38 +0000 Received: from DM3NAM05FT014.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::200) by SN1PR05CA0017.outlook.office365.com (2a01:111:e400:5197::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Mon, 17 Apr 2017 16:51:38 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 DM3NAM05FT014.mail.protection.outlook.com (10.152.98.123) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Mon, 17 Apr 2017 16:51:37 +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, 17 Apr 2017 09:51:36 -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 v3HGpZ0A008035; Mon, 17 Apr 2017 09:51:35 -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 F33C211454; Mon, 17 Apr 2017 09:51:33 -0700 (PDT) To: curdle From: "Mark D. Baushke" Date: Mon, 17 Apr 2017 09:51:33 -0700 Message-ID: <7182.1492447893@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)(39450400003)(39400400002)(39850400002)(39860400002)(2980300002)(199003)(189002)(9170700003)(8936002)(50986999)(110136004)(53416004)(2906002)(6306002)(6392003)(77096006)(47776003)(7696004)(356003)(81166006)(7846003)(6266002)(2810700001)(54356999)(305945005)(53936002)(966004)(8676002)(38730400002)(7126002)(6916009)(50466002)(106466001)(189998001)(86362001)(48376002)(117636001)(76506005)(230783001)(105596002)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2449; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT014; 1:1o4XOJnYHz7/e4nx8h5RI7yiOxnS3/YEpqvzieu/nZqRypj07Z/dSJBE9SlqsqSrtwz2vp4O9Il8nzsX3jP5pEalN6AxvQHEQ0J8682ei5WuBsRcpprHVuEiL6hzGuKF2D55KXh07vUCF+U/w/wCkK0EfjFCCTLYvVtEqSJL0aqWf1G3nuoN5aVwzw06e7eJbFW8tqNU48Vut2kr301oEUYp/5hKirKZGxDMvkApC/WlUjrB3WeP8lEYOWCXXQUqlvX9aPk3NPeUL4KOPoYFS5oOZftF0bl5aObYWIhjrc8UdljmDkBMgluak1AvXsiTVquldfRjnSy5hlWuHYuBGoOruFW0Hr3T4pD+iZBXrRy84lLxy4/4g0xs5LG00ioQj2Ut8yada72coEVFvnGQCOCRt9DxK8EevJbruHtSEX62QMonhU8d6r2U+Q5BDeOBLItyS4lO3K29HEH1Dt9h6w9LnfKkD5Uv97iQxR7mFyk5TBTlI3qRvO/8IQc3xkNYpuzcLGsQ08IzSoZ2df2S5aoETiLQi6Ru6Wgi+qtbMs++qiXN74LQtXim4ULPlOdr X-MS-Office365-Filtering-Correlation-Id: 2be46184-0ceb-4722-0b6d-08d485b203ab X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:BN3PR05MB2449; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 3:vCJI4szhWc6/rnpHpaMtvhB71xhQVd4rrzynvzqp/5hPvMbAD0UCOQPgQvfAj7copHcC0/HzKl2gSyLCgn9uNYSb+TTk7ET8V+YfpZOVQK45qjde7LOMK3eBy5ToOBy2a1BSdljHDyRzMZ9QX+CF8idYhIvFKC/iqTNEXDfng0nK5HUtxAMdNbxYtIxvs0NSNDoeZUPTUVpxunoVAt5jf87mDp0/dfQ0jK2Mi3XLFuTWyJIasgOOVaaR2Pe18NOcmOLCIEosY7ayyAp/1pWy6vfGHu6U2dB4sYDDbDMrDEs3O7flxmOhV4CDAq8RW+KvsJUN2TUK6TV3lA4tBQ1mcv1kyFPUkvwr1YHeq0d0QGZMDXbbwyytS5iBPTBqO0mjCPQjvuAmIQFXrkb7qxW3t8NYHRYCE5CugqysWmPTq7OInc5MgbWLOuj0/dQs7B6eoA0wff8Q+Azq3p2rc61Y5g== X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 25:BPoWULDvBCXaZ2khkGEMu5//XEVe868jDLKbPnLfgEexEBOFwmMPSivE97NP5wSbOZZ5K7YM2nF0NVL5iqiK6++Ub0TKNbmTmadSceKMFsR+NBbHHswmI+kLeNF4LmVVl9v7k3u8yVz4v5GdQPZwguYCmfEjaNbZFW5jg3XGe4jeggeDZWTpuQ4AGsrwlltZa0wdUkOFYXnc95aZ0SpoNc8QAwKuX5pEbf/dgua728Du+1DRHqlS4NAsxhe5givve1tXWPH5iP/gZQWAsTgQ7H2UEFsdTeRC1GGXpXccRURt9LQttOPOWN1OYXi9Wbf8M6E8lNN5NESxj4ZdYkfSFwLQfriCIKXrUPLcvpavzE6SOpsSOLqbjnTTuSbLklzKgBoTv8FElkiLMzr9St24la9ZzatpqVPT5V3Z94Bt8d4ieycsDigbyUwgNu/boEYIMD+Xqq0ZOgtjrbDOlAyJX05dNAC9B4HTDpoiSuQ4AOk=; 31:hTQEEhe6+1H/QW7xBnFuPnD9rC4LwV9WcZkAVgYMhmj5vS/nwoRR2suhV3i/Xfsdf3m06L410VQKL3bxDtFLNLsldCcwPAR5qFeV2Op5vJjNS8p0jqgHY/H056ARmyjiC7os5Hwzau5pysR4A12WQgFQbmbfK6U0zkVJXqHrRmk7kRScmBVT3Nob+C64HNZ5gnLn4UuOYRBv3FQf6ldr/7uU6PJ9TYs2sm52Q8zJOcWyelY1m1dTBv94lAynLvAoCi8XFwbetOzVIzJpNdrYF1wjI2I3+Rfw0S7aptGDRwQ= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 20:bTJddvqFn7D3QD+lLwRb4CrB26NjbC+wOFlOPgUgch8EY4Gc4q7AJO7YNyiQrH6WJj28FShRofMjtsGf0ZQN7RROvdXbtK7H8gkyFOlBEzBrLnSN5JrSWFR+9Fde4hT7c8ILzIY/+HXHdS93m/m+s6A3Zvhqe2fnrhhWEgrbb7YsORQY2oHBsai5ym2GJwEmLIKwuxojSt80RxYY23EZOLC5zlhbEtJk6o697hisPOEaXkYslHfEB1WqC/B+P6mE3Of6KREq/JTd0VzaTt/QzdNa8J5yQYWQBHKFwMNqV9C4v6kOMwZsdIdl0+CKRwZokajlXCOrr2AYnuUaq6lx6XYKbNOMJb6NEbXxShlS+kXvTxZfkQ5fjSbXF4Q45soOWz2iNoGs+E/yOQfdj9sDJkNo/jCotgEvXzKlFReV19LBo2e9fN6fRtWLT1H7P0/H04A8+jxnTrtk+TdBsUgk3CWfGH+An7ZKWixH/aRiNS263z2oAMw7GHlpsDYA+dun X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13015025)(13023025)(13024025)(13018025)(13017025)(5005006)(8121501046)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR05MB2449; BCL:0; PCL:0; RULEID:; SRVR:BN3PR05MB2449; X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 4:JbiQ5O7tjbYZjrC//auU3DyDpg779r2EUy5i6rEdL10bwDTOzvA+/OSSiZ7awL5BIUeYo1I2N60GcaYOZ6NaLNuzkzG+rAK3D0+eoRBJPDOAHumWJwbC2zF7g2fCHfh+BVUv4bOn+AyjrIKTdFaA8qaopGiTUwHY/xrR/VtuM6NBV5wXtvsO/1UnffzIIAGuPB41TuZpZKa3RWnJAdUj1QhK8KsUhYtTcYai+8VpKkWX+rI1roivM87HMlaLXq246NzRFb1qF+FeH64I24Atu8udmpS2XNpPXXDVGo9l2hxIzNsiFkzuLlc1umv+P8uXquy8tEl6GPvkPPorISt+rPVa2MihMvBzUkKnBj5SVuBe702JSKzQ/d+lqfpNQaSlQsBT7aG55KJ4LMAtLfZtAiq49vhXAwFPAdSIFKHrHtUbVaoxN7fLkVwpwsy4xzMl64ZxcA/DwslrBtMs+SsbOjqf5XsJCwxZBYlrdUUzuCJ89SBeZv4b4BMTzvkGdTWaj5cAIndc5dKxecqJYuqkJ1g5f4J57mRNLbZIkRoycr/CQPDRunqaXFMSUmJU7MLX95lqzyBxaGV78njVR2nbpCss5gIZDhgZ/9qoWMeW6P754QZOFMd9POgUznm5j8+5fSaBri5A4XXRD3+8FIKFfAA4YH8x3LEOc05UopsmXb1nTtRGcIM2r+UZKvJ+j/Cii1TlBOB0MznUGqDdmjYw5+azLlfEHcXSeMVEj/AOOi73PJMzUJzZa+1FrURxiO6Z2eDPX6rx0b3w+15xzUCr74Am9mbymyeq7ctzoc9tiG24M+YCdgaL8lJAhHVoIYfMgCKRE1xh+2KwTV9nPSzJTA== X-Forefront-PRVS: 02801ACE41 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN3PR05MB2449; 23:TDh3hoCqOO3RZSRMQS370RLBald5A6tm4yrnYBhcm?= =?us-ascii?Q?WikB0SLfAedxR43qvB0jV444iFL9RBdesoJBVNF/nmniLrqFL7+4peEYFkKN?= =?us-ascii?Q?uLAujuvY8RuG5RmroGQ06NSDHgDhlz3/cDhz+4Fvl2lfzVLScn3tl01fq/Q0?= =?us-ascii?Q?7QrQruCiYDc6DmxQ4Bfl3HpNdlOr/LaHgc+nbsmledCpC0B3waXr15ZwINu2?= =?us-ascii?Q?KDjOAJ6qHWlTA6Ysk/VSyZMmn/ssL60ceSLUD5ZUjTAngb2WSTBivKokOPfy?= =?us-ascii?Q?69r3ZvRFprBIyN19xKqyV701o3SrpOiEkIdykqPGAeOCu6iJvgDAfVqn74it?= =?us-ascii?Q?rSwe3lzprJWGcRIHz0p+Bp0lPeDtGNGNLDUoXnL9NZhVf1Lx/E2PDSb20MrB?= =?us-ascii?Q?FjSjoR+NgaXIrsy0F+yN0udcnKZ5VJ4pgMECxji1FY0CJgH1FHxSFUMUtOfn?= =?us-ascii?Q?wuueaCiusNhU9pBExGreOE9dcyLbFEcxR1PPhDFvZfCI7luqjNVeaC6jzBnM?= =?us-ascii?Q?qJgC9knfD9bwaXvtL4ZAqFClFpO688MZIVc+ALkuoOW+Iq/ZO42zZ6PXHSdw?= =?us-ascii?Q?Ov4jUaAZeAi2AeKlJYraSPicdPLjAjthVmkBpAhgBq3obeIv8Xj41AGUXJJL?= =?us-ascii?Q?tum/PS9n92wBrp/zDr7Cg5Fm9FTJCx4k0KVTwLQGCe/cOO9yIULdbn45m2wE?= =?us-ascii?Q?stcdDw4IIXPvmWyf30c4YGAHEtcBIAWxs8csI88moBJIVer4XHFloDUl6ao+?= =?us-ascii?Q?NBrMizbm3luiWU9vcRWSZ0+z0VM8xFIl6qv4ae7BjZPTLoHqUtMTAYqBLI7F?= =?us-ascii?Q?sVf3gkfbjeiaudP6mwXdpn114wbKW0UO8rBC0bYpvlHDbF6SjEr6HOrBitqM?= =?us-ascii?Q?SfoqbITq2pMM33vLHQyYsHadKpjPkuTnOsiE0JKrBUITAkkEOprIvAF1KiZc?= =?us-ascii?Q?7MsKDmliPfeJFInTiS1RYuUzMh2DbTi9UGhHzLrcaO7M/FpKBxkaEU99VBK0?= =?us-ascii?Q?8CnDQIBckghXz6Gp+saQd8GYAMLirXnrVejHo4dkHbfpaUAIVTj6p1eBrrZd?= =?us-ascii?Q?YOuFcm3lSfGSacmw3J/lavwlrNi?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 6:/2T135GmRk8J8qff7oQKdfy9u3erjIU1Nn531i4TOgfLn0J7rVC8xQIgovmpoWF0dtsFQH5PvVN3lm4ERGB1uC1tVE0H3S2LT/RsoPf9exZgB2jSt/GSCHjOwKVhIDGTT8bF6jpg7iphkj+9kvTMk4rHmG8vxM+Bt8FCDA1lAEUFcqvXxwZZXMcCD8ttM2SXzr3p3hbhNC/zOki9nP06JrVrVfwKuCdmmJ7rkseckUuMZ5IwRIifmN3YvsTGwwSEXmYv+Jjf8kMIpb0SD6SRXKYgzncuZvAOeJf/IPCMSYgTdkMyeAglqYidRab84UsPr4cIhJeWoSYMHQr4i/c2V8+hb7fdGLgJH4ObtS0XM28wxOLiB8dLSjeXyBuBa8woH7/6hNu1LpEXvUo4eRaBUfGxj5MSBbItyQS1pDcbolvOcHULMzBZNJ1XNmu+bi3raTiuvBcxbyjdmMbiQFGG3U6DP3yUxbH1sYAP2hiEYL4=; 5:wJFK3Fhm9gA7slnaQOzJux+ynnAKQ1lCvWomPYYbg01HW0YEANTE9sKxifENS4YH5/U/UDMC+LNVcL0aOZFKg7XQAXlEMBBe6EVp+lYo7za8cVW5B2YB+tOMps5xiz3TrS0DMG8v2PCuyC8B4iRhTg==; 24:/nlPbthbGn7citGMVJGU4s8ve95e14/3awe6ScY6yKEXPPPbd6Mcfo4bWvjdiqDYXc4hu1JuAEAlX4g0w0HGLmKW1Ftnf2N69REB6CQFxP0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR05MB2449; 7:QkIPkjEuZrQny3P8drkchXMu8OH1JHkZ62QMkgFB7BXIsU5QYeZqezBPTWmG8q9dv468CBMOR7FTzQAQL8+0PVxtEfmDqdXUKLNA7KddhfELOoUnwf+IE0IGLf2+gsvi7UkYQe5fy2NoIiUpL6fbR05YhJTiEqMfz+vY5rreBjA/H7Fi0U5HWr8Vcvd4rBZS+sDGP2TV0TEmwm+4DZjGDyRMYAfjECtOFnvPlLEm+GkNmYi0DVgZDwS7vHAWkxPCNO54AFUqS7Dhtgx2YjZItMC7XcD8yI63V5qnSK/RDu/Z9uR3uFYDaul/rRmecRkAHN1AYKx6ZwO6Td4FOSkPGw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2017 16:51:37.5064 (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: BN3PR05MB2449 Archived-At: Subject: [Curdle] draft-ietf-curdle-rsa-sha2-05 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, 17 Apr 2017 16:51:43 -0000 Section 5.3 discusses PKCS#1 v1.5 Padding and Signature Verification It may be desirable to add an informative reference to RFC3447 which discusses PKCS#1 v2.1 to define RSASSA-PSS vs RSASSA-PKCS1-v1_5. I know of at least one organization (sogis.org) http://www.sogis.org/uk/supporting_doc_en.html In the document: http://www.sogis.org/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.0.pdf (sections 5.1 and 5.2) which seems to want to disallow RSASSA-PKCS1-v1.5 going forward in the general case. -- Mark From nobody Wed Apr 19 05:39:20 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 B4A31129530 for ; Wed, 19 Apr 2017 05:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wJE7McGGrJD for ; Wed, 19 Apr 2017 05:39:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F8D129524 for ; Wed, 19 Apr 2017 05:39:17 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DC9977AE90; Wed, 19 Apr 2017 12:39:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com DC9977AE90 Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=hkario@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com DC9977AE90 Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C42B380F94; Wed, 19 Apr 2017 12:39:14 +0000 (UTC) From: Hubert Kario To: "Mark D. Baushke" Cc: Simo Sorce , curdle@ietf.org Date: Wed, 19 Apr 2017 14:39:08 +0200 Message-ID: <1670339.BpRFGmRBOW@pintsize.usersys.redhat.com> In-Reply-To: <39113.1492406108@eng-mail01.juniper.net> References: <39113.1492406108@eng-mail01.juniper.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15716122.d0znpfUKby"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 19 Apr 2017 12:39:17 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ssorce-gss-keyex-sha2-00 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, 19 Apr 2017 12:39:19 -0000 --nextPart15716122.d0znpfUKby Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 17 April 2017 07:15:08 CEST Mark D. Baushke wrote: > Hi Simo & Hubert, >=20 > Regarding your draft: > https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt >=20 > The reference to the -05 I-D.ietf-curdle-ssh-kex-sha2 should probably be > replaced with a reference to draft-ietf-curdle-ssh-modp-dh-sha2-04 It probably should have references to both. =20 > I am somewhat curious why the same curves identified in RFC5656 as > nistp256, nistp384, and nistp521 are being called secp256r1, secp384r1, > secp521r1 in your draft in section 6. Is there a good reason to select > this form of the names? Because I took those names from TLS curve registry. Making them consistent= =20 with other SSH names is a good idea though. Thanks! > I will note that gss-secp384r1-sha512-* should probably be > gss-secp384r1-sha384-* to be consistent with how RFC5656 > felt security should be handled. Good point. > I do know that there is some controversy about supporting SHA2-384 > rather than SHA2-256 and SHA2-512, but it has been argued that SHA2-384 > does not expose as much of its internal state as does SH2-512 and that > it aligns more closely with the nistp384 curve. how is that applicable to the KEX? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart15716122.d0znpfUKby Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJY91psAAoJEJKo0bgB0vX1g4gP/Rk69VSKXamXDT47m6nsgU9A pCsD+uyjTVitQoTUPeSPeE5cFXdvWEwUllsWWXEi60rUaICT1dfQtS6lVgrC2vWK yHlC9b6KnUsrr4V994lnVjcpJa+KkxNgWKJu3N4RYdr9Ix3kzmeBdpxTCFbNRoAx fqOjWYMkSI6E6PJKZVJd/NlRxEyueEUsiUw9lDiSS8JPQ2lGKMsKCEiOZkf8b+fv qsmu88Dz2UwnsOzgE+737V+HeX23M5w6buhHfSfb9GNBzFZOJ6xTpcDm38w73Z9L yQqWP1CbHCEy08YSH6VtiZZYAJo7GYcYHs4QQd0yTvAKF/LVdsvODS3UbKTqJtPY NN7wu0h5NV4/dQVnhb2Eqvux5DMJvf+XLTuoUxMiglozggqZARScJZBLcJK9+Zrg DwkQntkE9MvSHjkmJFEZxoo6D+t+VQqjdXSe0PvzK5LjzELOs9ajVMKBaezQ5DsZ T8QDroMPSOGi8GI7vB18F8KilPxJgb16o2ngGyfsOAncFtmKaJLxq4CfSvvxsF71 aZPu0llItCrvz62ZlMZjzt3Bjc+GX6nr+oFwgkXqgmqLnXxFtDZiZFICmtYGBMD/ rIj1JE05668jN6QNHgTmnenPeoF3JQQnidCN9WiyGK12kmAr7+NLjxEOxINhJTME 6VGFtWNtmsIieazTx3Oj =5OvA -----END PGP SIGNATURE----- --nextPart15716122.d0znpfUKby-- From nobody Wed Apr 19 06:12:24 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 74D00129431 for ; Wed, 19 Apr 2017 06:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 bHfTzWrwG-IR for ; Wed, 19 Apr 2017 06:12:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C25124BFA for ; Wed, 19 Apr 2017 06:12:21 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3JD05sC003087 for ; Wed, 19 Apr 2017 14:12:19 +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=Oi7UaoqHo/owmeGLbK9pw0yW5Rm15LI3OnIL/ma8bMc=; b=XWGya+fJEi1R3bjLkwbQYNPGZ83JSjyfvLCHfYtSlqp9y1bz20Egfz7uGbDlg9d7zFVh 3xgdglXLUaKUeguCwOxFLA6raHCs58zur6MUezA+nU4JS+BIFfsyp3lOU/9fgSkmvBmu MtFRllNc/tW7+MiR/5SBLzSLhkjiSt0+xvGK2xnBL6i6LkF37EWf2kg3s5bSfecwUVA5 4DAzo5mfYCnXpEMnzZiCFHlDeKfGmdXvdUP2+8f/ZSp2DtSbspsSoi8FyYmAiwcwxJYd ojk3J8ROnwgEmBFiDcAtBwSuAG6nEPsx25LkakSgl01afHzh59TsRHDOhAsTKrSHCn9f hg== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 29wxsa2pja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Apr 2017 14:12:18 +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 v3JDBKGA023408 for ; Wed, 19 Apr 2017 09:12:18 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 29wqn5gdpd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 19 Apr 2017 09:12:18 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Apr 2017 06:12:17 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 19 Apr 2017 09:12:17 -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, 19 Apr 2017 09:12:17 -0400 From: "Salz, Rich" To: "curdle@ietf.org" Thread-Topic: should we meet at next IETF? Thread-Index: AdK5DmFhyaKtZZBaSUCdX5RUsO48vA== Date: Wed, 19 Apr 2017 13:12:16 +0000 Message-ID: <6e92834ad9e647149bbc75ae673d9788@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.42] Content-Type: multipart/alternative; boundary="_000_6e92834ad9e647149bbc75ae673d9788usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-19_11:, , 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-1703280000 definitions=main-1704190116 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-19_11:, , 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-1703280000 definitions=main-1704190115 Archived-At: Subject: [Curdle] should we meet at next IETF? 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, 19 Apr 2017 13:12:23 -0000 --_000_6e92834ad9e647149bbc75ae673d9788usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daniel and I are thinking that we don't need to meet at the next IETF (in P= rague). Anyone with relatively strong feelings in favor of meeting? -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_6e92834ad9e647149bbc75ae673d9788usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Daniel and I are thinking that we don’t need t= o meet at the next IETF (in Prague).  Anyone with relatively strong fe= elings in favor of meeting?

 

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_6e92834ad9e647149bbc75ae673d9788usma1exdag1mb1msgcorpak_-- From nobody Wed Apr 19 08:11: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 42D8A129AF4 for ; Wed, 19 Apr 2017 08:11:06 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 hzOzcp-vJRws for ; Wed, 19 Apr 2017 08:11:00 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0095.outbound.protection.outlook.com [104.47.38.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 05ECC129ADC for ; Wed, 19 Apr 2017 08:11:00 -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=6xmvmIX1T7VbyciOxdMTSj5WPhKxiXAm8/or3oyMFSE=; b=JIRfPZV+H04Hudr+DesiDslwumrHk2Dlf7pbXztSU2uMbGaOIlyiefrYvhZsaEGH6+gVaJ7VtD2NggH6sakoSrPl8bE7ubbNJ9uFfhQtw/yuZBtNO3dcqzjCmvB72OgwCYA68kdKCmfJG/kUDnLxLUEATJolgL3B/U3QocokdeY= Received: from BLUPR05CA0075.namprd05.prod.outlook.com (10.141.20.45) by SN2PR05MB2494.namprd05.prod.outlook.com (10.166.213.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Wed, 19 Apr 2017 15:10:58 +0000 Received: from DM3NAM05FT058.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::209) by BLUPR05CA0075.outlook.office365.com (2a01:111:e400:855::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6 via Frontend Transport; Wed, 19 Apr 2017 15:10:58 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 DM3NAM05FT058.mail.protection.outlook.com (10.152.98.174) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Wed, 19 Apr 2017 15:10:58 +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, 19 Apr 2017 08:10:57 -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 v3JFAu04003303; Wed, 19 Apr 2017 08:10:56 -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 4A3B311454; Wed, 19 Apr 2017 08:10:56 -0700 (PDT) To: Hubert Kario CC: Simo Sorce , In-Reply-To: <1670339.BpRFGmRBOW@pintsize.usersys.redhat.com> References: <39113.1492406108@eng-mail01.juniper.net> <1670339.BpRFGmRBOW@pintsize.usersys.redhat.com> Comments: In-reply-to: Hubert Kario message dated "Wed, 19 Apr 2017 14:39:08 +0200." From: "Mark D. Baushke" Date: Wed, 19 Apr 2017 08:10:56 -0700 Message-ID: <44543.1492614656@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)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(2980300002)(189002)(199003)(24454002)(9170700003)(50986999)(6306002)(53936002)(229853002)(55016002)(38730400002)(6916009)(7846003)(54906002)(50466002)(110136004)(48376002)(2950100002)(54356999)(6246003)(76176999)(4326008)(77096006)(6266002)(7696004)(76506005)(5660300001)(86362001)(47776003)(2810700001)(8936002)(105596002)(117636001)(7126002)(53416004)(6392003)(8676002)(356003)(5003940100001)(81166006)(230783001)(189998001)(106466001)(2906002)(305945005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2494; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT058; 1:VR/dWGZy8tGOReGu8xBNc3pc64yFd53o5M/V2Sauf2GBXbQbOjWxS5atqPIN7yt/Ekzh6yJiGYTE+EQbAxOJOqvwVwJtHaITQBFqWAOiRzlGVRTe35ugf6t3lJNKiYjjYGYC5W0LAdCrjZuxON8jDD2iXegv3mSDfHtf+h/WX99j6D3Efkf0dZPP1H+HXZ6LZGWvRyzytpWq4+WByuZJ2CdfQUIkgjG4vMvKXdwTuYUpXW0uDbLWT7oFMnkmX59lSeHgN+jGwCGASjWxzQQSmBa8yMJmJlV3gBxSdGOSuDxiNeic9whEYkbxOS8t8pnvBeCebcRhbsZ1mnup3Pif9ZI/hXY48Hw5hVWn18WkeM7HmP6cJ4VYqv4PfpZUT7iFz6WYacOOVswYOjLTPIObd9fITJAEt75abgSlWvmFXokc8eJr9nSAqdXP/Xfh/BncrAeUmHE3Yy8rZiRSj/grQ22NNxeiBYyCzd7dbcCb3+V618fcGW4YS3c8MqqVngCTxd9sqSBeGYfVG5To/Rx7mHhx/FAENzEWZoG7a1a8XNQB8RtpM40d7LFl7EzVJ+GTCjulVrhjMilGyFKHhAFkQHonCJ/15rugSNGaJaiUVc8= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1e9bde64-5b75-44d1-d42f-08d4873648dd X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR05MB2494; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2494; 3:QDlIisyH50XkPIflEURyTzYOdq/izlPkaDsLsmLi8nSoPaWaiuDLv2W2FQ9k3ibPtoB1G+xHd7M0TINe2Iu4rCwse8Q1RduCAFVZ7wrzyVJvaLBrlAWWNaBmhqKqb6CheJa3i31ki27J5JGq5fQ1fRcofstG5AoET6kuFtD1ry0Jpl5Zipjv3uK2/W5JLWMUOKWGDr8qHzJQ/BnwOjDAx280LkQhrtwBvZbvbaFez7y3Taa7UvfHRu5RB5J481skfSSN3aSvyqF7QScthcnAgkEu5PIaCWRPbW/GBnbZwEQPH7BcIqPOSzyW/gCd7yBh0u2B10H9ZzgCRDhcQcdSRk4/D5a9rYmmu1O8ykmDGvpsGw3aePsR2CaBhGo4EWyCOx+wLigs0+A1L6mIW8oTEqEQ1JuIEPNH6JBBEbO5IEFlQbzHTynY3YBU7GlUTA1Ajixp/EZWXEkE78IZasN0VA== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2494; 25:CtkVLYaXfX2iJ+C+1Na6nP0bpfHG29ULPi3HoZzDbiNW2L0Li3gMIX+ibhXA+VOp8+Fg07xA0OuQen4/NgfpLRFkla7kfgKDLBMVdz13GiI+1SKMAnmiXRyszL1cjzMeQii8VvxjJ0c46mMJ33B+p55yhP0oW57A02r3RIhxPjaLaIhKQ0Ps8RFtzNantsYzBp+XdU3rewWYfSnzFy2oYbXC5L9pPyWrkmM5DL6i7LAHH9DhNFTxW6rFKBNPSSi0EMCbYpZqH58i0mFmGk+kB70PBNubqeWxqLfy4acYOVmVWEr4IKQ/QTQg1GKhuSchoujUjKrkogVkfsMds/U2VqQw2j+tMtPgq/MZ0IpL+xhDY0fkgSaRF2R83PbZYSbT2A542woMT7ouiU/eDGgvjUheQerVuQFTyTBP2A0ZSmXzXl9wjRIpL/s09JtBTpC9TJEeVUgQX6AFy0eWd1uLYOm39LgoeE5o7hQ0HIxqZso=; 31:2N0Mj6Q40PKr8KosbFTKdo2EIdo/6tcIzwVrx5z5yPaB6nC2GCRv+a97i98hP6E3ncEiZNMa8pKb/Odofrc2AHxUKnpjkia1WZow2j+gfuSeC6FQsXorwJDlp7uh5P/0Gz+NLGhd7/b9ziK2nh9Fi0YyxlzoFMKagox25zCP4Lb8cXY0cl7qdXip1eWuu+EOGQQQ6m+v86v9Z1q6cQ9KogtsyQqcHOAUsQEvMiom+fYn3KjIwU6ZqeNUzlZjK9et X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2494; 20:68I3+4twrnlDFuUdXA25R1hUsLj6EkllixNZ0In62BdZY9zegq4hzCtQA/ExUcaQUmG2lclyY5OoxsHHHAKLyy/UBarQVGr2tFkuD65OB0TyW2ghdH8EK+XQBCDprOB4gFQANL3ZPSclaAjZfQpIKfKZD7kjO7oT2MbeqPCIDGg+Hz86qmeNpKVEf+/fPpnpMQqKO7styAQ/QTW+DdGDs8/tz+vwO6shSIPztK05w97Tu3I5UcT1z/Tu9XusKk0uu9kGNiQGfHD6LwfCeHfqY1hTgiwklzdsN2qadF9LIUF8eqvJGVEB+HaHeWSoR+xSz4VnJ41g3dM0mFyS/kTA1GF8OZw5X/WF9XdepOt7JYa9InWyG2W8SFigalMH5MsswwgTGGpAKMz5IBzNuXXb8XIfutVd8slFJuo0ANeQ1CSVy2opFwg5uT5URpA0Co+cGnTfJIg5xIA1bq96g3cFDta12HOl2eWTQrt4klfXBqMJ7UZ87Sd+ltUsUsd38Y6F X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(5005006)(8121501046)(13015025)(13024025)(13023025)(13018025)(93006095)(93003095)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123555025)(6072148); SRVR:SN2PR05MB2494; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2494; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2494; 4:z4t3JfuK+obD8bBUIAMBiBtNpTp4cnAF5VY3zDWpklbO+hgJY/tGHTWbwY/5GHKEgO3LY6Kiwn24JGZpd+bFDXoiQhJ+/mBiwKp55ORgDwCuwOdu9aQnexKWc9u3XqBtTyTFmjxwf/Ciyzh0T7ROGgEHEOKofb5eAIVfJq26M5mFkwTVgqWKBqipyWZPehCJTdkeEgXa7qfR/EnuBHAOZpiDFW1Y3T+d4k8J3dBbRNESA81MNAVXvtPlV9Z2aZuefb0kpvYyEc+aUodILv2VnvPmwhQ5ZNqpY8MDAin8aQEaCkrNI/tJzwMJS2dJv8cjjQlpCRJ3esW3EBmD7da//vS/BD8kusOOpzfHy8cz/hUj7SfnQQXeEdjeI9om+nUt1AJ+6b9tEDChQGvtp5sMiJ14thH+0kgxxZQKer6I++l8hTsiKmQ4ARbZrPleOqsdg66AP5lmfHd7ZGFUmtiF30DAqV+h+mI14iSNLezFahr1SwzJ3KEJjBuDRuJAIq2Nt4kWnsgT8encTcA4yRJSVkp4qcMATaA4YIluRR65Sc7ddNKIOxXjJshXc5pKBZII+TZVnb4ED0FCK/qis4oQDPn2FaqRGvVNW/IZk2GRCw7zs3zUl26e7azM1tSPLbdHkM4E+0aSnFBpTUp/qn15h5xeQ6CuWvI4qlPLAWZOHWlJuSnFT4ZdNQc9lxADjPECPPAllwGpXYaes4gJMHfK7zE+ScJj9r6tWhyfatpnTfsnRyq6V5EYH61YfPRgaGCpi86+h0lS/qvQJCD0P8sWpO7dHpcdz+rHqgowUanwAXlsqIKA861CWdp4YZkxuPvihS785W+T+l7F39S56oT31xo1jC3BexPx/rQ/hsEthfFeypygH+L2Z4FVsIxy8ZDXGJuH48lpMj8O+bHklL23Fg== X-Forefront-PRVS: 028256169F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2494; 23:QOQWsc7A7y8JHCvOrMc7ik13H0o7dIk9FWBwWZP6T?= =?us-ascii?Q?b4vWf+0ReapTAFraBPEGLBswnyk/05puZgJsioZ0rlcZBYcWd+X8eLkEbotd?= =?us-ascii?Q?AQsV9nO8WGeF23X1qMpZQEb5k7efr4r/1iBxbjs7zy/RoFXbhb1QhAK1D3KN?= =?us-ascii?Q?5kbz+/ZQg7aXztV0cYKuAiyi3OM1q1yBNK7M787M+B9SY5++mabLufLm4EdB?= =?us-ascii?Q?pIME/KjCVrxahhwGEOTvr8j3myFlecGtyfapnzlBI9U7MMSkXrtd/htNxPc/?= =?us-ascii?Q?SyD+U92WasawxeN/KPLy83Nz63UBN37u9t5b82NJ6oQDcDwB04/+uu70+C5C?= =?us-ascii?Q?X9KVlxr5uRzy+16dCeXrImWmf529MerhJ0RKfMZuwLx3Qbw+b3ELWZ2V9q+P?= =?us-ascii?Q?IxAOuOBZwdqCCziGagkFne6VtkYmzsF272HtWfrG/EV0qFVBmIvKqZePcHF2?= =?us-ascii?Q?R2SUAzW3oVCTxmnN5IzFMPpmS/7GQHAd8Z0dmeYgF0Ev3quJHpObp5tirkdh?= =?us-ascii?Q?3M5Sv+/sIE05yIqgmn0Fc/KCWDeIq/Svnmn6pQQ4jNmO3IIurb+mNHzmSCrL?= =?us-ascii?Q?EiqbpuZNlb/GYSa6v8wqKbpgKMktmCwsSO+6wlHRo4+3/wVqrWEZNgz35AOr?= =?us-ascii?Q?XJIJxL0bGwF6r/kGRBk0MrNqEXDpxZmlTe9qFbplYOyK0rmWtk/QEUGjapoC?= =?us-ascii?Q?ALJEWidmP6sU7CNu7BJSiPgbjQPhB4f6RIJmmgBc6RgqIweWFMc3vDR7gHUZ?= =?us-ascii?Q?3/ZKaNzwE6afSWC/cSOSBMAvlLfDIxCkgbBBgxA7VtfqbUpAEenqKtmJ8Ot6?= =?us-ascii?Q?+2I+iW89S7J836XTwUUU/Xkina3WLEu0jDxPTzKmktrboCQeJeHelz6VBxgG?= =?us-ascii?Q?fZVlk9OfUYOiNpYltFyD/zwMNXro2N60vGdjnYWAxak8Vw564bFO2Gd79p/B?= =?us-ascii?Q?DIceYMv2OTUax0k+dBP8NTE7QqqKkvGXnHv7JAiAD48KrEDzCzBcxfi4dS1m?= =?us-ascii?Q?S3IyNSK6sBZhfFmOt+UxdfGPw0QYiNphqilBbvNClLFYaXLBbnyB8LWWi6FW?= =?us-ascii?Q?eW9WlAdP67XhQhcntUt/IMlZ5lxpRg/8/0LX7JBdqkh1z+gpBVsFkqs/VOvE?= =?us-ascii?Q?a7UIiyhps1aYmUCttxFWES4nLehvr4p7j29n1Ce7ZrDzreieyLNsLRtzEKLV?= =?us-ascii?Q?iZIzixOJ58qtfo09847+6CWf1yOgjSyN7HdqHM+Ip16VbsTjfqoBqUDxpwUy?= =?us-ascii?Q?9YXg1Eg36/ZjkRj0drYIthjYXDsQ/ZDfJCB7oCwdh/0cmEZfVJyRSYKJkHkR?= =?us-ascii?B?Zz09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2494; 6:/fWffHTXpcLGSeFhlDUA1DR5TzRdsyo220pi3/lF28XHj/My2O0+Zw6Hw7532fgXozHDK/yVdmdLfcLuF2AQ+wPyE4uF1A3q8Ezmrr2pgu0J0bbBMvdc9KXKxaFZjPtjkfEsZ4mJ909TSDKLaj/7QCNnot3H9ddEQ4SnyehEg64uLKg8/soCoz+IxtOp69MTCPSHyqviPrBePeALJ7zk4cXIx/SBbjVE6pjCO6uUReGk4e/FFIRH0En+ttbk/F4ZisyuLV7YKtU/BnE8m60zznqr1hzblM0iO2JuUMZiWCHIeqV3fNr7IACkrH3zfr3/IryywNAjOHgcmpgkGAG8ajODqqAxE7LefjlH9/Fxg8pXPyUlzPLmNBlGr9gzaRy5VQL/RA4neQOjiuvhCCpdU/mIF5+b6mqLP7Dc+/GbHTX9ntAdrsL5oLkmifSpOnYd53Tw8ACMK6uUMN7qBFARRk/DHltiBWS86hGgYAYTDZE=; 5:lb+RSzM9F2yNO8ADUtq/nkuxzEctZ4HWOobDD9fPxFEQfbN7YLkNhFN4q6qe6U2gI3ePg+g41Dt6amy+rAApuxCJ97jZ9aedxCO0XjsnbJ7t56+FWGJkO7C9W/EM5EoX75l5chq8NsIhiy1rm+Ldcg==; 24:NibmPP9iRclAbq4oSw7vrvEDzOVlfl+phXK91tQKzgwxDgPnNfNpLbryT9dzm5St/3M3xw9dFXfKVAw22KSx+jSR3GptLsiSeVSI5RtPpxE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2494; 7:VRylWDuTgPE2IF6kXsdeRvCRXXE2sGXwG31nC4JqY2c4AMOVDayN+kM/j6L+XCRY5A48kshVdd+7Q/cP27FaLSTPWFlNABAxxjhrtjBO9GPMTaWvhzedfICNharQDWoFQEH+dKpPevP3546b1lbDrZcsla6OSvAx6hNd0HeGpgwqH8eqwVVGzfOKjPvO9LQYDBXc6C+YrXrRQk7lzoVFe6z+hgpg/w4I6F3GOulP+FcLmTdt7YqRq+4k3dri4TxVdcNkKpeJNKyAmM7woQYFqbbhTfwGRVb9U6YDeBJrIyqR8p8VPj/BU1J3sbUFsf5Dvn4Y2j2n4WGDQcWJ7TL7SA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2017 15:10:58.3310 (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: SN2PR05MB2494 Archived-At: Subject: Re: [Curdle] draft-ssorce-gss-keyex-sha2-00 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, 19 Apr 2017 15:11:06 -0000 Hubert Kario writes: > On Monday, 17 April 2017 07:15:08 CEST Mark D. Baushke wrote: > > Hi Simo & Hubert, > > > > Regarding your draft: > > https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt > > > > The reference to the -05 I-D.ietf-curdle-ssh-kex-sha2 should probably be > > replaced with a reference to draft-ietf-curdle-ssh-modp-dh-sha2-04 > > It probably should have references to both. The ietf-curdle-ssh-kex-sha2-08 is referencing your draft right now. I am not sure a circular dependency is needed. > > I am somewhat curious why the same curves identified in RFC5656 as > > nistp256, nistp384, and nistp521 are being called secp256r1, secp384r1, > > secp521r1 in your draft in section 6. Is there a good reason to select > > this form of the names? > > Because I took those names from TLS curve registry. Making them consistent > with other SSH names is a good idea though. Thanks! > > > I will note that gss-secp384r1-sha512-* should probably be > > gss-secp384r1-sha384-* to be consistent with how RFC5656 > > felt security should be handled. > > Good point. > > > I do know that there is some controversy about supporting SHA2-384 > > rather than SHA2-256 and SHA2-512, but it has been argued that SHA2-384 > > does not expose as much of its internal state as does SH2-512 and that oops s/SH2/SHA2/ > > it aligns more closely with the nistp384 curve. > > how is that applicable to the KEX? I am not sure it is, but it was originally argued that ECDH and ECDSA should use the same hashing mechanisms. So, if ECDSA mandates SHA2-384 for a nistp384 curve, then using the same thing in ECDSA seems less likely to cause confusion. I only mentioned the SHA2-384 vs SHA2-512 issue if you wanted to add it to your security considerations section. I regret that I was not clear in my comment. I hope my comments have made sense. -- Mark From nobody Wed Apr 19 13:10:08 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 7CECC129AE8 for ; Wed, 19 Apr 2017 13:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Ldu4SjZKhmPv for ; Wed, 19 Apr 2017 13:10:02 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA16129AE7 for ; Wed, 19 Apr 2017 13:10:01 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id y33so29394346qta.2 for ; Wed, 19 Apr 2017 13:10:01 -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=Qqv3QVBhO5mBwgsKIbyUF3Gzt4QTBveh8HetnWzjikg=; b=FF9VVl/kXj5beAQO55yJG/DbQBag+eSYKQJZ5BhwvxKgu5jAnUGl2p70R3hnPsSn9O 4eSQeljmFEDYNn73gmafpR17rxc+G7bgmbgK1eBiBntNksa6fzvSOnT5/bRy9yvnKCgj qT9Ny0JAX24wFyoEG0w6uZdefJSBHg+FjXF7BkAyo8FBl2McTldvUv0vq59Mue0MIzSr rM4WcgkDFgCImDh/+7lJiV4OJRWKfZK3SZZakjO1BIoG9Yhq2gzd/3udWyX/efOpzzGJ BOFE2XC23SrJAtHZt+8NRVUthJJZTWFwD8rC7euqfj7e2Fnz1gzoP8xwjg+cYTpAr25b iHaw== 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=Qqv3QVBhO5mBwgsKIbyUF3Gzt4QTBveh8HetnWzjikg=; b=rRB7s5cQ9ck4Rshqi55Q5mXOoS3BBbVOx+RWcCX2FB4m0jXGnrcj7Gm01nOSLa4woQ 56AocZhhtlacT6Oix1lMi10nlWIrVvPbeKsV3UVAr6uutWcrXtFBG0Pzgn2hq8Owkwun EEBHJFsYjF9IT9hlByI8z9DbVO8F8kE+JbqXqLC496cxX+yZP3LJRY6PV1o1hZKZ77XH FYADee5nCshWMW3fPd5CzyOubjyFA6cgG/UwY/MrLcKAxvxA7x/5MZk11d2Hk+TMh7Xy uXy8+aPQ+xurTEXjyG10Qn6c0aC5LawFmjPnFrhJQ5FUz/zoBe71yzVXAUxOD3Wj0prP WPTw== X-Gm-Message-State: AN3rC/7tXdYoy/bmEqw9R00gA0IM1bTAVlFNkXavZn3011moiwt2vYgc ift7EKECW06WsCW2T1F3nqQFotiTwg== X-Received: by 10.200.43.68 with SMTP id 4mr4362230qtv.47.1492632601053; Wed, 19 Apr 2017 13:10:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Wed, 19 Apr 2017 13:10:00 -0700 (PDT) In-Reply-To: <7182.1492447893@eng-mail01.juniper.net> References: <7182.1492447893@eng-mail01.juniper.net> From: denis bider Date: Wed, 19 Apr 2017 14:10:00 -0600 Message-ID: To: "Mark D. Baushke" Cc: curdle Content-Type: multipart/alternative; boundary=001a11404f4cf74eca054d8a9b36 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-rsa-sha2-05 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, 19 Apr 2017 20:10:06 -0000 --001a11404f4cf74eca054d8a9b36 Content-Type: text/plain; charset=UTF-8 Hey Mark! RFC 3447 is obsoleted by RFC 8017, which is currently listed as a normative reference. It is normative because it's needed to implement the spec. The reference to RFC 8017 is currently made in section 3 (where the signature details are defined). Did you mean another reference should be made to this document in section 5.3? For easier lookup, perhaps? denis On Mon, Apr 17, 2017 at 10:51 AM, Mark D. Baushke wrote: > Section 5.3 discusses PKCS#1 v1.5 Padding and Signature Verification > > It may be desirable to add an informative reference to RFC3447 which > discusses PKCS#1 v2.1 to define RSASSA-PSS vs RSASSA-PKCS1-v1_5. > > I know of at least one organization (sogis.org) > > http://www.sogis.org/uk/supporting_doc_en.html > > In the document: > > http://www.sogis.org/documents/cc/crypto/SOGIS-Agreed-Cryptographic- > Mechanisms-1.0.pdf > > (sections 5.1 and 5.2) which seems to want to disallow RSASSA-PKCS1-v1.5 > going forward in the general case. > > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a11404f4cf74eca054d8a9b36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey Mark!

RFC 3447 is obsoleted by RFC = 8017, which is currently listed as a normative reference. It is normative b= ecause it's needed to implement the spec.

The = reference to RFC 8017 is currently made in section 3 (where the signature d= etails are defined). Did you mean another reference should be made to this = document in section 5.3? For easier lookup, perhaps?

denis


On Mon, Apr 17, 2017 at 10:51 AM, Mark D. Baushke <mdb@jun= iper.net> wrote:
Section = 5.3 discusses PKCS#1 v1.5 Padding and Signature Verification

It may be desirable to add an informative reference to RFC3447 which
discusses PKCS#1 v2.1 to define RSASSA-PSS vs RSASSA-PKCS1-v1_5.

I know of at least one organization (sogis.org)

http://www.sogis.org/uk/supporting_doc_en.html

In the document:

http://www.sog= is.org/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechan= isms-1.0.pdf

(sections 5.1 and 5.2) which seems to want to disallow RSASSA-PKCS1-v1.5 going forward in the general case.

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

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

--001a11404f4cf74eca054d8a9b36-- From nobody Wed Apr 19 17:29:16 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 083C112EACF for ; Wed, 19 Apr 2017 17:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 S0uIAZk-vcIZ for ; Wed, 19 Apr 2017 17:29:12 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51238129410 for ; Wed, 19 Apr 2017 17:29:12 -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=3TEKv65+5+WHW9lnkJvrVOO0F/9Tu2tIXPqXIlD0xac=; b=YEAc6xbZ7iqmQ90c5yyJPAPxnBjr2qgRol3zV9Q6YJ430Dz3RhbeM1JlFcPTRwtUGTOVRCwEwxv/5AfGFEDgmpFTMaU1/6CFnALGdOXhdUD82JX3WcKrsa0WPx9yY2B+1YN4GsSo2uoqmqRJpEC7jeRQcS8cDLMiMx74/Fk+PVY= Received: from BY2PR05CA026.namprd05.prod.outlook.com (10.141.250.16) by SN2PR05MB2493.namprd05.prod.outlook.com (10.166.213.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Thu, 20 Apr 2017 00:29:09 +0000 Received: from BY2NAM05FT029.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::203) 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.1047.6 via Frontend Transport; Thu, 20 Apr 2017 00:29:10 +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 BY2NAM05FT029.mail.protection.outlook.com (10.152.100.166) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Thu, 20 Apr 2017 00:29:09 +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, 19 Apr 2017 17:29:08 -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 v3K0T8nI022587; Wed, 19 Apr 2017 17:29:08 -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 B516811446; Wed, 19 Apr 2017 17:29:07 -0700 (PDT) To: denis bider CC: curdle In-Reply-To: References: <7182.1492447893@eng-mail01.juniper.net> Comments: In-reply-to: denis bider message dated "Wed, 19 Apr 2017 14:10:00 -0600." From: "Mark D. Baushke" Date: Wed, 19 Apr 2017 17:29:07 -0700 Message-ID: <2100.1492648147@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)(39450400003)(39400400002)(39850400002)(39840400002)(39860400002)(39410400002)(2980300002)(199003)(189002)(9170700003)(2906002)(54356999)(55016002)(77096006)(7846003)(8936002)(2810700001)(117636001)(81166006)(76176999)(8676002)(6392003)(86362001)(76506005)(105596002)(230783001)(53416004)(189998001)(6246003)(50986999)(106466001)(53936002)(5003940100001)(7126002)(4326008)(110136004)(48376002)(39060400002)(7696004)(50466002)(6266002)(38730400002)(5660300001)(229853002)(6916009)(68736007)(305945005)(2950100002)(356003)(47776003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR05MB2493; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT029; 1:aeIRYR+s8lqaqsPmfhgBXtuctpFY5I17FVq7jKNLhpuwHCJpaB0+t8dvWrWeWCYwf8BtunTxNperq9DaDkoRQIFKaPgVoqjCJsHfTRD4G75op/xgPcohIeW7iVAldYGADs3qvN77DNMyHNaDV11//wkhG2IHfH50mdgA85q1xfxahxKLhu+0/qigzDFLX88evV5pBL5NbouF+nQ3pvU5PduihuQKqfcmqY8zBf92cqPlWn8xojVig85vzw9SytehbrjN3cgJU/bliP3xeP61SW1MKBY0mtDRkW6MUvmFpIQn8fJiRkny0dUf1dn7yIEc2GPbziiVOxNrsaC87c2CkUt2XO9tIw7fAZiT8ahN0W99h23FpvNAyh6FqWiPQe4vUGvo16cpCQ9Mxf3A1Hvqkv5SwL0DwHFYHsqmDFtBEU4YOTS5NFPZMoh4WKVmAOcujqtt/VI0l28tvNteC6D924RJRKduYY59M0CIEYV+oPxWqTTOahdvm3jGUTpsofqjDuSXB9KV0IlixZhxDjcG+kloT6gtEhJfyARLSex2yLD0MWmzKyKuS0s5i0F9eM4E X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 157ecc62-3a81-4407-02a7-08d4878442f3 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR05MB2493; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 3:lq3Olpbm3qpEfIvlBPR4z58II/369tAvcf7NdVXSiZ0HGX/XpK2gpC/cO2mxMKi1fLd6hysuiYQ2Fs1VMIx/DCK1moM/tvCiIMJJrbuy9SP2FVph7mcO3VXzxSIHDjiIGyZ9wfz6grultwz/lbMydJvVUkGAZUbo2NUw74ukPEK0fAOGfEPtKKay0tC4gdmmwNkc2PBYuxy3LKPJ+ZAvsmdrIKz613Ti6eDkLe5eqU6A85+Sktd4p1alf2H600gpbW3YSC2I7DVl+Nk1res7RU3JqDEfkjZvRoDpXlzS9Qa07x/gPX6DBeNcFs+ScvpSWOduc6Cq8scNxym5i5dHaLCqrlPOQllks/945toW5plPsiu5Wk7AkkSkT3Jg1/yLlRxkA0Xuuchva98t1V8DbwernAgszBbejwvM4eyxs0Akz4199qdkHtGaYwSMk5GI2Qa6VTG9KuRTheUwK5buGw== X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 25:fP4taDCwJH6kTeJ4dLevLnAxPLqdctos3ztuLtG6fJbFmW56BIUztuMi8h8VypCpYj+Y0S7acY7icRaUhPXdlKSPbzXzm1T2HL8pJMq5MkIUYjayEAci2vUeI/O2t2owbqVlwrYSUnnIEMSTMFy79tIlWp2oq0QLew+dGw8Ch17iP/ZqhJPM6ddAl6fy5yCqfYkvjL9mdyid6irOMbF4LLzF2y6TJkKrRFMbd5tPVZ6X5Az3cScQ6ALQMfNoldGqcFAfF+dw1N6Y7++A3eV0Bh1v5Nnk7Xk/OoXYKJMwHMpTT9WRgoXTjIcTSGjbzDD+1TFdv+wObYdQs2Wh9fYBcSE+qh/mpdO0zuyKBA27YEhQfbIh7EKIcqQGX2DMPU46KcagJGd70oTb3HqhrfE1GDtBdi42GNdF70HyiVagcN46oeb66j/ipO765g9HnBaVQZQ6eZf6jHku6wTzxheT4hEnjHBGCjr8RZpNgxmCaa0=; 31:+hBcpjveLCynGmYRblKXXYAMFFk6/2rn5kSCh6RMsEVE1ecP8BZHlfR/E/C0Ei5eEmlJkA7Iz3qbbp+KN//DrGOe/UfI3ZrK/mtDzouDbdAp0+jIIQdZsViGndp2pZmxphIFhQB/2b2jM3ESto+1E6KNDYlSRwQyd5KedX/spw77HHwxQOwEWNODFZ0T32h6NQLPk+K1MBFW0ljpZ2bmIE3it262jMuKQU0YlYH+Q8ZGfpdzwFxaseA7CCMQ3GMxt5ObNK82LZY9sUQJEcAAKqCqdwHv+ZjkFMF/rqu+Ius= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 20:g2jaVEObJeQRC3xlVR2kNx2fEJeYAfr48PXKMOf5+J6BV8nXVf2tC9exHpaIdESQLmjDVIdML1rUFRftq8jIgAboTTu0xr1HknPDHrBcPq7WDzcl3PskRUejaTmLpYGfur1DqhiRbO9HYbXpopXM4ZGGxsQqSfT7Tbq+3flkQWYud0dtqadTOu3Bzf5iNKXwfSzaQ+dVKLJWECpyLgQHC+Gkt6xG+U+tEcjSM3YABv8htVnM4Xhc23B/MiBtv8uY5h3hnmvByJYEUCAv08lNEUpjP11jA2JbLep5yYjzjRqymndT9VfC7ZLfJWYPeIHVieB66EDD18hv7GAFZ2IW5JMr1rbEDANgPh8CyaM7xhj4uQngdeHIxTkWtC6e82qKYW83iNSa+IuL9tme5C3xoaxQNQ++wdz1BJ2gsKhVYRu689gZv/sNsqQWtcsC8jTfzkiBrmhKvlELUSCCjt6vFYtSfWyw7kRC3eX95CZv/OCaoabnK4yDhrhPjdeEgtqP X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(5005006)(8121501046)(13015025)(13024025)(13023025)(13018025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201703011903075)(201702281528075)(201703061421075)(20161123560025)(20161123555025)(6072148); SRVR:SN2PR05MB2493; BCL:0; PCL:0; RULEID:; SRVR:SN2PR05MB2493; X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 4:8odnFkQlrJy0U5d9XM/+fjiSjdjyIBUo/8PLth70Qiw0Jdfgd2g36AIAURqB2VPGa/RZQnOmXyKGLEE6DIwIH720VY3kGMs4yH6rt3ZH/S2c+im0gfU7JiDFRBGnEocRpZH02dcvQzM2mGMef+ZieqBCoe1XeRVUDMVKn3LLgAuguHskvButeGhvW3CcyPQWg/dzQmhNeJrxezJOTW13E54fRkDB02VmaanIRaZJ8Z/KIrTN52Ee6r2F8CqBDZ55UH5RtT8xrOxUf2gHAEWQAN4xMJ7DBqPf/KmCyHgpfr/hViuE1jy83Fb2VV8cY8VwtCjJETSMyVpfCOU4wzTeQ3uZp70iKdd5FpoY72uIgxMnCTlJsqJ4B4YD0aYnDBgcRkE9S+6zOTysPNOmXWR3TksLdfJF41lnv9fqmxusHQx/IZfbtpm1H5bku+HKUAf45z/xJT4M/LGzt9I0NS3u5SANPDkSFNV/tsiCXdenmUBjjrKqQ5vcmEcSWJz5v8nwrY+HjkB6uToErU4vlCByMIl/rzVKBAKukca5Rvj74GW8xzIOljmTC3IguhIiHIJZkcuBsn2WdkHAUsM/U2AX/kKTsIrGlIchSx+tJ3Hrg3CPbx8pQvir26+S789Ddm4Q6b9rO+OwCVho3cnAK8Q/5OWGtVeMK1rxyWE3hpgyjV2OZ3nDSGoXrvWRK73swUjpcP42aGyApFVAW6RnJnPGDsEDFPkq6iqE0OonGRAgd90ohBKCVOXxjd91j0XOA3iGFd9++udNncgKH5DEcxSFtTWGliBPbQ/4RL0yvaTYmm2gqcAX7/Eb8gZGUmIpeM8jmpqR+vcRvI7+GU1nBE8oEDTMsPcqQN+RfZHJLR1k8lI= X-Forefront-PRVS: 02830F0362 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR05MB2493; 23:p5acto5KMOiI/1fjaHkSZXDuNMWlcCYO7fzCxHp/8?= =?us-ascii?Q?slI+NzAoqXPnSX7afmfjKiTRzO4DPqk6ux9nJ/hcsAWMdVmHSy/zKMsjmkL0?= =?us-ascii?Q?fXad9dlCO2Djynn+Re4gtMmYD7GX/m42DJeBVICrSgUYPKrTRSjKRHx5p6xH?= =?us-ascii?Q?C9LvSy2X8V5rzrZS14Hf1d+BwU9oQYkvu3DDFBAiXKnF1ExR1R7EZ0NWb50v?= =?us-ascii?Q?IyCtuiWT0bLQfK6teXafDkusERQig6zd5ZCKcLGULTAu6bEOODtszfksMjMB?= =?us-ascii?Q?hCSQ4t6vRHzKKSjphaW6mQhbO4GfFRJqAa8cy6aSz1cS8RGNudQObWYjcbJ3?= =?us-ascii?Q?ZdRlAcMO3QYMkFYL67TCaX0RXM4o65l+GmA3CcyGsSQdcoveq84N3IUXb+xK?= =?us-ascii?Q?ykpcWuTlx7tyQLG6/63X0751kekQvusgicSH6skfnhC8XhZxXIIbte48BgVr?= =?us-ascii?Q?fbbqHUN7GiUJpp5YbiZ83LB4I91fYoS8/apF9Va+fKlOF2l57NoyLBQFBS+o?= =?us-ascii?Q?M1bN75tZ4sOa9tOhxh+xqxcBNcCqeqW9CZH1w9AWE/eMFC4xKuV93fluk8rd?= =?us-ascii?Q?GxcuawoGL8p3ZTrQVuxZgIxrVVNMvE1FQiXCDKZ5uklnjGBm8Tuxdf8xDtJk?= =?us-ascii?Q?A7FlQoNgdLRgbT9/UZhfPMBpyRiR93wUXLDpCbCnYCMWdWH+TLiOJOc1uSBc?= =?us-ascii?Q?EVnK3ODFx8MZnTOXLjWfxpqhYWHTueTOV3rYoOQ4OLFr4QZKAwbkEim5oI5w?= =?us-ascii?Q?TLBQfiFs7oTome8DxK+pt9TgYeIqxu5LtTOhdMNxCfQcxu3dn1iAZWgdBHbn?= =?us-ascii?Q?f6vm7BInE80xv2iRMtZyNzsNaN/TOrEGldPLHLXDWi8OaYG7xhG83UeRhtvI?= =?us-ascii?Q?D+bONB+/D1YT098htChuosk3BpjPUeYI56+KrBAv+maooKFJLWehZk0qkZD9?= =?us-ascii?Q?ss6hMl2fEiECyePqq+b71vpg1sBLdtURjz/P0dWyHX5piqgmBhF/ccVMxNpF?= =?us-ascii?Q?mVRYNf6KStpAxQbm17Fiz3SzbSGmFIRxBJctW1CZJMbzyvLZJdjpuJ1NahHN?= =?us-ascii?Q?Jb3j5JhKIb1ooT5uP45ry1vt5kzk4wMYEkk0P7Hs6vDQoukt7kvzf6t9Myjh?= =?us-ascii?Q?PRRfW85tOCPhiZaLCCN1tefE8lu+Ka72H3Zx3hpMEySspB17g0C9oY7ucwf8?= =?us-ascii?Q?vjJB8yQfTDfuZT1P0ZvLYRIDPXOtgSBq15SPWSVRX0V6L7sdg6hlY2tnEvDY?= =?us-ascii?Q?c/ffGXyKpuol3HZJpWgNNiTiBW7lKaVihJmurfC9QiNSJeIMUtxbjEW1nRPF?= =?us-ascii?B?dz09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 6:V4XkyYFIX/PczrEvto3MkhL1MVhB+cLGtGVKE/SBMum0H6Ocy+Ds+Drx7X4VGOPJqAkhSBEjnJ2p+nB+D2xlU2j+eXz44OZZjeVnbaPn/MamNsJaVapE4LLogQHbaN9VBRHV+e/ZHqfYb0N6qCEoDsF0R+QI4IevN0XKOlr7OQPbLzCGqhkKDSK/kg9NbXy3bZL5UhPTOwK6KQJG29bqFgZLPqDK5FadAy7KbZBCa5eFbInu8ASSuxJgjXxnSx+avqFtubhbGH8f/M/IzoNkZWHiHOerHa32Tce8Y2CjS0rLBJkSRQYel+oPPD51OpRCo5wS30FzMpn1uI3iC9BSvGUuDBmCfjl/WMwb2jw1FfFwqAt+hcRdHrB2lP5OcLtumbWZqE8vjqqhfHWuc4Cz2Xai1tX3xsx4U8LsRVpv/PP3m2ocmR8SnwFJanLSP4W5Z/61zf43lIZgqgeCIrqe71ZUhHewtc+5yCBB5oEXcxA=; 5:y59W17smkH6eVdR7EzSTQiqJnfwO3c6dbcXOYLGggF0f9iROrYaw2B4TFsCqYgmnGMWD7C8ZS426Mk7XXruqD8/6gFVoj28so+6uyxM6ySOYM6lXVC8iYTjl24k3c0uYZYOrxI0LLTqRexie88i8bA==; 24:XlT5osM8JQJZNozosbWpXpOUK7CgNAitlq8WIiBJHtyGRJQXzu0ZjN/ccLAz5qRKLh/PwB6m4uYiSBgPHFviUwsbvQz6z3SPRKvMrYtqY/A= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR05MB2493; 7:lESYY9YDBAphS7q1pZFjvEv1/h3NBulDyptSUm+TYkrZNsnFKbik/ign07HvHZsfzLwjwagYoWYt4qzZqmA59LJJNR+BvRb2TtpZY1VHpDiGCxK9kGU3jO7DW041+AeEynqPy5MDRVHHW4aFdrwj4j1uRsKBzcE1Dqab0QD6frVIbwVLKRceBnBQYyqplOGNVDN/ilHDE1X2GIaD2+bxQkrC11V1Iml3YjTZXNTkXPiAYl/DCv+hagG5DYdJsddFNj+AEsFMtAf11d8IkETTaO0Wdeh2i2u6RiJsgzrbkiaucfIEU6i6w86IDv10nKkLLj2mGdN+XRBzAGT3Qhw7cQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2017 00:29:09.2381 (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: SN2PR05MB2493 Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-rsa-sha2-05 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, 20 Apr 2017 00:29:14 -0000 denis bider writes: > RFC 3447 is obsoleted by RFC 8017, which is currently listed as a > normative reference. It is normative because it's needed to implement > the spec. Oops. Mea Culpa. You are correct. > The reference to RFC 8017 is currently made in section 3 (where the > signature details are defined). Did you mean another reference should be > made to this document in section 5.3? For easier lookup, perhaps? My issue is that PSS is ambiguous in Section 5.3, 'PSS' is also known as RSASSA-PSS (RFC 8017 Section 8.1) which is not to be confused with EMSA-PSS (RFC 8017 section 9.1). -- Mark From nobody Fri Apr 21 05:48: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 3610A129432 for ; Fri, 21 Apr 2017 05:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3abbvaP9SVHj for ; Fri, 21 Apr 2017 05:48:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2EC124234 for ; Fri, 21 Apr 2017 05:48:06 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2D8F2691BD; Fri, 21 Apr 2017 12:48:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2D8F2691BD Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2D8F2691BD Received: from ovpn-116-177.phx2.redhat.com (ovpn-116-177.phx2.redhat.com [10.3.116.177]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79B0789F6C; Fri, 21 Apr 2017 12:48:03 +0000 (UTC) Message-ID: <1492778882.3662.221.camel@redhat.com> From: Simo Sorce To: "Mark D. Baushke" Cc: Hubert Kario , curdle@ietf.org Date: Fri, 21 Apr 2017 08:48:02 -0400 In-Reply-To: <44543.1492614656@eng-mail01.juniper.net> References: <39113.1492406108@eng-mail01.juniper.net> <1670339.BpRFGmRBOW@pintsize.usersys.redhat.com> <44543.1492614656@eng-mail01.juniper.net> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Fri, 21 Apr 2017 12:48:06 +0000 (UTC) Archived-At: Subject: Re: [Curdle] draft-ssorce-gss-keyex-sha2-00 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, 21 Apr 2017 12:48:08 -0000 On Wed, 2017-04-19 at 08:10 -0700, Mark D. Baushke wrote: > Hubert Kario writes: > > > On Monday, 17 April 2017 07:15:08 CEST Mark D. Baushke wrote: > > > Hi Simo & Hubert, > > > > > > Regarding your draft: > > > https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt > > > > > > The reference to the -05 I-D.ietf-curdle-ssh-kex-sha2 should probably be > > > replaced with a reference to draft-ietf-curdle-ssh-modp-dh-sha2-04 > > > > It probably should have references to both. > > The ietf-curdle-ssh-kex-sha2-08 is referencing your draft right now. I > am not sure a circular dependency is needed. > > > > I am somewhat curious why the same curves identified in RFC5656 as > > > nistp256, nistp384, and nistp521 are being called secp256r1, secp384r1, > > > secp521r1 in your draft in section 6. Is there a good reason to select > > > this form of the names? > > > > Because I took those names from TLS curve registry. Making them consistent > > with other SSH names is a good idea though. Thanks! > > > > > I will note that gss-secp384r1-sha512-* should probably be > > > gss-secp384r1-sha384-* to be consistent with how RFC5656 > > > felt security should be handled. > > > > Good point. > > > > > I do know that there is some controversy about supporting SHA2-384 > > > rather than SHA2-256 and SHA2-512, but it has been argued that SHA2-384 > > > does not expose as much of its internal state as does SH2-512 and that > > oops s/SH2/SHA2/ > > > > it aligns more closely with the nistp384 curve. > > > > how is that applicable to the KEX? > > I am not sure it is, but it was originally argued that ECDH and ECDSA > should use the same hashing mechanisms. So, if ECDSA mandates SHA2-384 > for a nistp384 curve, then using the same thing in ECDSA seems less > likely to cause confusion. > > I only mentioned the SHA2-384 vs SHA2-512 issue if you wanted to add it > to your security considerations section. I regret that I was not clear > in my comment. > > I hope my comments have made sense. Thank you Mark, sorry for not commenting, I was on vacation, I will take on your changes and release a new draft asap. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Fri Apr 21 22:09:54 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 483E8129409 for ; Fri, 21 Apr 2017 22:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=usaa.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTi-dxfyrPEj for ; Fri, 21 Apr 2017 22:09:50 -0700 (PDT) Received: from prodomx102l.usaa.com (prodomx102l.usaa.com [167.24.25.117]) (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 E4FB81293FF for ; Fri, 21 Apr 2017 22:09:49 -0700 (PDT) Received: from pps.filterd (prodomx102l.usaa.com [127.0.0.1]) by prodomx102l.usaa.com (8.16.0.20/8.16.0.20) with SMTP id v3M554pS031029; Sat, 22 Apr 2017 00:09:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=usaa.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=201408; bh=QggnxcIRwoz0hjjwUFsky3pYDN8BpIPyaoBc6EuUloo=; b=sxtz6EJRT3WnIn4QmkYkmDJh2vXPwNvmxO8v1JRa+RsmLhvlmZlDnwXaqksy9CngS8Tb lrqKE9JIdkHdbGugBbNmWtfcyIPsFplftT8wiR2fExk/FeLAK8Oa3JAT4p+KZ+2h2bKW /whLKxBAKEQS2liFCuwxbANBgpy0IZtk5deduRe+oWR/65SU45T46uqSMEBI4ygx1zWw HWmnX3nWo6UQgR27Z0puKaxLeRNOnClgD6tLWRRR2L6etDgZBIh1BJ77RUw5n78NEo/I 82hHTr9R36mgLmmjjCxVu6FXkvZuhr+xpdC691Po/8HPNq2LT8PFIWr006IJh/TD24M8 mA== Received: from prodexch04w.eagle.usaa.com (prodexch04w.usaa.com [10.170.40.30]) by prodomx102l.usaa.com with ESMTP id 29wqpmfppf-1; Sat, 22 Apr 2017 00:09:39 -0500 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.128]) by PRODEXCH04W.eagle.usaa.com ([10.170.40.30]) with mapi id 14.03.0210.002; Sat, 22 Apr 2017 00:09:38 -0500 From: "Mehner, Carl" To: Daniel Migault , Jim Schaad , "curdle@ietf.org" Thread-Topic: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt Thread-Index: AQHSqBTg9f9yyAbn5EewWy5f2aNhkaHQ5Nqw Date: Sat, 22 Apr 2017 05:09:37 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D41FA7720C@PRODEXMB01W.eagle.usaa.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01D2BAFC.BA531E20" MIME-Version: 1.0 Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 22 Apr 2017 05:09:52 -0000 ------=_NextPart_000_0007_01D2BAFC.BA531E20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Migault > Hi, > > Thank you Jim for the update. Here is the version resulting from the > discussion we had during the WG meeting yesterday. Please review the > document and provide your feed backs by April 4 so we can move the draft > to the IESG. It is a bit past April 4, and I apologize, but I just ran into this... Should the "kaa-X488 KEY-AGREE ::= {" in the ASN.1 module in section 9 instead be "kaa-X448 KEY-AGREE ::= {" ? Also, in section 13, I believe it is Hellman with 2 l's. > Yours, > Daniel > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, March 28, 2017 4:40 PM > To: curdle@ietf.org > Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix- > 04.txt > > Here is the promised updated draft. > > Changes: > 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign > bit in public key.) 2. Remove all of the pre-hash text except to note that it > does exist. > 3. No changes to the OID arc being used despite the agreement during the > meeting. After the meeting, Russ, the chairs and I had a short talk and > decided that this did not need to occur. The problem was only with getting > new values assigned not with the current values which were already > assigned. > > That should be the final issues in the draft > > Jim > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Tuesday, March 28, 2017 4:31 PM > > To: Jim Schaad ; Simon Josefsson > > > > Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt > > > > > > A new version of I-D, draft-ietf-curdle-pkix-04.txt has been > > successfully submitted by Jim Schaad and posted to the IETF repository. > > > > Name: draft-ietf-curdle-pkix > > Revision: 04 > > Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 > for > > use in the Internet X.509 Public Key Infrastructure > > Document date: 2017-03-28 > > Group: curdle > > Pages: 15 > > URL: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dcurdle-2Dpkix- > 2D04.txt&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0 > f1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSy > h8nYxBD-rwM&s=wcttUJysVcLmWQ7svq2t0Nb41NgIbfjIjSeBfaduLDI&e= > > Status: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle- > 2Dpkix_&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f > 1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSy > h8nYxBD-rwM&s=A8_G31FWl2kykg3GSF6HdI-2ScdRpyZUQGbtm1EGXtE&e= > > Htmlized: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__tools.ietf.org_html_draft-2Dietf-2Dcurdle-2Dpkix- > 2D04&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1h > EhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8 > nYxBD-rwM&s=sZ2jebdsB7X7grNhRfcOW5E4q4_hNA5PUh9hakL3MIc&e= > > Htmlized: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dcurdle-2Dpkix- > 2D04&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1h > EhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8 > nYxBD-rwM&s=UhQ7p4MbELlnuap0ja0gIWlTuwzpH9h7QDzxz-1wkg8&e= > > Diff: https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dcurdle-2Dpkix- > 2D04&d=DwICAg&c=4VfW4Y7UDKzr0jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1h > EhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8 > nYxBD-rwM&s=8Le8SB-M-UikBklTudIyLmY350YCLZcMS-xBwHhK3Ic&e= > > > > Abstract: > > This document specifies algorithm identifiers and ASN.1 encoding > > formats for Elliptic Curve constructs using the Curve25519 and > > Curve448 curves. The signature algorithms covered are Ed25519 and > > Ed448. The key agreement algorithm covered are X25519 and X448. The > > encoding for Public Key, Private Key and EdDSA digital signature > > structures is provided. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_curdle&d=DwICAg&c=4VfW4Y7UDKzr0 > jHM1Tk29w&r=7jcwf_nHftJUeeRf0f1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsy > wb3tVWXtWhbKQaG2UsB1UqsdOSyh8nYxBD-rwM&s=- > QGwR6ZMLxm7fInDxqNaE6ufW9_LkeZQjADdOHyYoVM&e= > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=4VfW4Y7UDKzr0jHM > 1Tk29w&r=7jcwf_nHftJUeeRf0f1hEhoYPns7FKYpnjAfuly83Yc&m=2Amsywb3t > VWXtWhbKQaG2UsB1UqsdOSyh8nYxBD-rwM&s=y_nDnvAU07Nn8Pnxx- > SOP_Hqm0ZBXlyYa9-eO-LGnZQ&e= ------=_NextPart_000_0007_01D2BAFC.BA531E20 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILxTCCA1Qw ggI8oAMCAQICAwI0VjANBgkqhkiG9w0BAQUFADBCMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNR2Vv VHJ1c3QgSW5jLjEbMBkGA1UEAxMSR2VvVHJ1c3QgR2xvYmFsIENBMB4XDTAyMDUyMTA0MDAwMFoX DTIyMDUyMTA0MDAwMFowQjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdlb1RydXN0IEluYy4xGzAZ BgNVBAMTEkdlb1RydXN0IEdsb2JhbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ANrMGGMw/fQXIxpWflvfPGw45HG3eJHUvKHYTPioQ7YD6U0hBwiI2lgvZjkpvQV4i5046AW3an5x pObEYKaw74DkiSgPniXW7YPzraaRx5jJQhg1FJ2tmEaSLk/K8YdDwRaVVy1Q74ktgHpXrfLuX2vS AI25FPgUFTXZwEaje3LIkb/JVSvN0Jc+nCZkzN/Ogxlxyk7m1NV7qRnNVd7I7NJeOFPlXE+MLf5Q Izb8ZubLjqQ5GQC3lQI5kQsO/jgu0R0FmvZNPm8PBx2vLB6PYDni+jZTEznUXiYr2z2oFL0y6xgD KFIEceWrMz3hOLsHNoRinHnqFjD0X8Ar6HFr5PkCAwEAAaNTMFEwDwYDVR0TAQH/BAUwAwEB/zAd BgNVHQ4EFgQUwHqYaI2J+6sFZAwRfap9ZbjKzE4wHwYDVR0jBBgwFoAUwHqYaI2J+6sFZAwRfap9 ZbjKzE4wDQYJKoZIhvcNAQEFBQADggEBADXjKWrlL11UjilQlJ+ZGhTkj3gqYpSiJ2ee0M8aXkfp wbKkz91BGgVOm0vuSm9VUrMkoTcK62R2Ki4s8/07dZC/+nHYxz030rUFlWK5pt6JPTZ7OHdIl6ym II8upskMwrKZRQDHzhFRIiLgpeq2FUgJZOpeT3T3BT7HilIM2xW0vW2b5caxVGip42mQtpqlD7i5 PyB9rkq1uJzkHbar5pSlwceDrdv1J4cOBGzV/92gXe2HUrcrFQKuOaZqdOnaxOe8TTQeqVxNM1+S CS+IZl13l8cddhOp1eXxFgkRNdWs2yRxcCyYVgvZF7TR41ErXnXo1dDcTzTtwgVmgKHL5jMwggPo MIIC0KADAgECAgMCOmEwDQYJKoZIhvcNAQEFBQAwQjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDUdl b1RydXN0IEluYy4xGzAZBgNVBAMTEkdlb1RydXN0IEdsb2JhbCBDQTAeFw0xMjA4MjIyMTI3NTFa Fw0yMjA1MjEwNDAwMDBaME8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEn MCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAzMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAqAJcfEGa/1UyJzScC2fwCgPcESB0lLNSpGkM5yoN1eFg/4tTVj4oA3kD Isy8/LBMKsIIHRJcEeqh+XtFC9e5p8Yx37QzHAewkih0KixHMQRCycevj93B4Yj64UWJOsnBKzvL Nk9XapnFjX0i+Yxt96NqI945E93doeQ/+zMq6hN8LMhaVZ0YBHs9w/KwuzmdHOsmRLcrm8Cu9bDk dPYsu+4C/OlSWTlrcK4cWbaczu2Q9ZHysJOJPJfA6cizTXrgEVlWJbV+pjUMydZf9z1x8jlLYg/I kA5OTdAuCMa3ZFRk6egdLC+BKD/4c67nVbPGpQLHkHggyi+RFqoZdInG4QIDAQABo4HZMIHWMB8G A1UdIwQYMBaAFMB6mGiNifurBWQMEX2qfWW4ysxOMB0GA1UdDgQWBBRXYNBfXB729Z/KiXWdncNq 68WyvjASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjA6BgNVHR8EMzAxMC+gLaAr hilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL2d0Z2xvYmFsLmNybDA0BggrBgEFBQcBAQQo MCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmdlb3RydXN0LmNvbTANBgkqhkiG9w0BAQUFAAOC AQEAaPCiTJzstaNFLQ/pn+2wxwo4qyhhhEfvozJR7Q0id+DPtbJlFT6GR8LnZp7qMBNBciNbHB2q YPQoMU1w6bdscSu0WmEhctwIOpPC2JLVwCrrPhBDGRPHoPuWqDvHb5YQt8KVVPlD+KAvbqzXQbLq RJe8mA6upzt7jV4+F9jucQ1LI0a2/wUsoH5xYbTLvcUwprcmTksjkDfVfIfoPYPV7z7+te+ZkniB awlba/xxEQTcAl/KTSo64AdeA7xVnCtEhL8thwukiO3lNDaetR5RooJKOIiZDmpytOZZQMcEhrWd lCXLnU2oS5ShxHkhrDjDpH8T0IbVrEKBQem1SvSopTCCBH0wggNloAMCAQICAgdRMA0GCSqGSIb3 DQEBBQUAME8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEnMCUGA1UEAxMe R2VvVHJ1c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAzMB4XDTE3MDMxMjAzMTg1NloXDTE4MDMxNDEy MTIzMVowgYkxCzAJBgNVBAYTAlVTMQ4wDAYDVQQIEwVUZXhhczEvMC0GA1UEChMmVW5pdGVkIFNl cnZpY2VzIEF1dG9tb2JpbGUgQXNzb2NpYXRpb24xFDASBgNVBAMTC0NhcmwgTWVobmVyMSMwIQYJ KoZIhvcNAQkBFhRjYXJsLm1laG5lckB1c2FhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMY8xkzTZz8M5PCnt7VBgJuhkk/6IyRCuFMDh4wQ9nrhMFShA631ufTxIU/7l/MKpsos hglh9B7jlplhhlfSbK8Dda2RVkklDAumfwHf4XOd/hrWN5rH9YUD9f3NuV4bbVCGszg9xqdyv3Zx FGtpzRziMBGTvxLWW+8ZsRtki1iy9mG9qqXTWHlWYtR7Vu2YkOkLhgNp4Mvbrf2RrCB9lV14jJop 09UUqycySdUQbiZuTlwPDGB0VLvnVTl3iI609Ae2ZanwMfvYywy+/g7hsTZJ9E2sY5tx3NqJSaNR DwLMCxRTmZyRh/UZ+E8amhDUrQd8kqQ9t7vnKM3kofEBxWcCAwEAAaOCASYwggEiMB8GA1UdIwQY MBaAFFdg0F9cHvb1n8qJdZ2dw2rrxbK+MD0GCCsGAQUFBwEBBDEwLzAtBggrBgEFBQcwAYYhaHR0 cDovL2dlb3RjY2EzLW9jc3AuZ2VvdHJ1c3QuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU BggrBgEFBQcDAgYIKwYBBQUHAwQwHwYDVR0RBBgwFoEUY2FybC5tZWhuZXJAdXNhYS5jb20wQwYD VR0fBDwwOjA4oDagNIYyaHR0cDovL2dlb3RjY2EzLWNybC5nZW90cnVzdC5jb20vY3Jscy9nZW90 Y2NhMy5jcmwwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUdnoSh18BEsVfacMM1JrKdEQlu5kwDQYJ KoZIhvcNAQEFBQADggEBAFEq5qWe8sd7aI6dswZDnl+OX09MrxBOjzmTlRfs5xeeUDQKOmddkyQZ 80hZCGO62AK+xVgkmXegVttae9lcjD+eJ60M8hWqLtoqErZJZ/3NpmN3NqXvpmToU0j8gk3oWT4n WwBpngJbRWA13XNoTbdBIETiQzlyVdgmkWejt2uHaZKp6AVdOFP3iTcDNT6phIkRqkAjVgMjdRiA Voy+p8IgmtQHH83cppzl3iandA+UG1gNSbpD8wzJGjwUPRYzYxv7IpJG1ct2btOHKOpETPOKnRHT ee9FbUJc5rR4Q9NYEyQyIs66F0nYQcdCvuKNLcOhUZbhpINUUt5YlQ6pwNQxggNBMIIDPQIBATBV ME8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1 c3QgVHJ1ZSBDcmVkZW50aWFscyBDQSAzAgIHUTAJBgUrDgMCGgUAoIIBwTAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA0MjIwNTA5MzZaMCMGCSqGSIb3DQEJBDEW BBT/RM4QYkwcjs1ew4pE084PubXBljBkBgkrBgEEAYI3EAQxVzBVME8xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5HZW9UcnVzdCwgSW5jLjEnMCUGA1UEAxMeR2VvVHJ1c3QgVHJ1ZSBDcmVkZW50aWFs cyBDQSAzAgIHUTBmBgsqhkiG9w0BCRACCzFXoFUwTzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDkdl b1RydXN0LCBJbmMuMScwJQYDVQQDEx5HZW9UcnVzdCBUcnVlIENyZWRlbnRpYWxzIENBIDMCAgdR MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAF1D IYUtyZgM/TlTY+p/K+XbWZ9cJ6CMVdGoXJfVXITG/czjZyeoGzEwsPY4S0eiq8gPhUSfas9Stuv5 bVPOG0mNTS36EdlftQfDB72A3T/RHAzr7VhCLTk1nSOi1yUxFlNo5kgkH+WW7ngbfa+TvGsrT8VV Q0SYpl9ZSf1g7LhCGd8HhEjArbi7L4kuYwMsdh6oDs/UGmMCJjLmHbLdbWBHmwVBWNvh/UZFNyqR nNuebd9BLzZkcFl0ac5PubouUP+4SzcwiJnnEdmtB6TH0N7WOktmSxP52b6TWzDjRb+9g4ac4d+9 Whjm66oCcTVQFW6ahLRBFFtR22UJYLPnLwQAAAAAAAA= ------=_NextPart_000_0007_01D2BAFC.BA531E20-- From nobody Sun Apr 23 08:46:24 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 EF980129466 for ; Sun, 23 Apr 2017 08:46:22 -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 z4L9cdt2YJw1 for ; Sun, 23 Apr 2017 08:46:20 -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 606D1124217 for ; Sun, 23 Apr 2017 08:46:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8D6FA30042C for ; Sun, 23 Apr 2017 11:46:19 -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 dLLJ57ayzeoS for ; Sun, 23 Apr 2017 11:46:17 -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 CE9F4300256; Sun, 23 Apr 2017 11:46:16 -0400 (EDT) From: Russ Housley Message-Id: <774A627B-12DD-40E5-B18E-B294BF53ABDB@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_7C179F39-95EA-4583-8BEC-90C30D41F786"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 23 Apr 2017 11:46:13 -0400 In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41FA7720C@PRODEXMB01W.eagle.usaa.com> Cc: Daniel Migault , Jim Schaad , "curdle@ietf.org" To: "Mehner, Carl" References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> <19075EB00EA7FE49AFF87E5818D673D41FA7720C@PRODEXMB01W.eagle.usaa.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 23 Apr 2017 15:46:23 -0000 --Apple-Mail=_7C179F39-95EA-4583-8BEC-90C30D41F786 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That looks like a typo to me, I=E2=80=99m glad we have time to correct = it. Russ > On Apr 22, 2017, at 1:09 AM, Mehner, Carl = wrote: >=20 >> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Migault >> Hi, >>=20 >> Thank you Jim for the update. Here is the version resulting from the >> discussion we had during the WG meeting yesterday. Please review the >> document and provide your feed backs by April 4 so we can move the = draft >> to the IESG. >=20 > It is a bit past April 4, and I apologize, but I just ran into this... >=20 > Should the "kaa-X488 KEY-AGREE ::=3D {" in the ASN.1 module in = section 9 > instead be "kaa-X448 KEY-AGREE ::=3D {" ? >=20 > Also, in section 13, I believe it is Hellman with 2 l's. >=20 >=20 >> Yours, >> Daniel >>=20 >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Tuesday, March 28, 2017 4:40 PM >> To: curdle@ietf.org >> Subject: [Curdle] FW: New Version Notification for = draft-ietf-curdle-pkix- >> 04.txt >>=20 >> Here is the promised updated draft. >>=20 >> Changes: >> 1. Fixed an example that David Benjamin found was wrong. (Incorrect = sign >> bit in public key.) 2. Remove all of the pre-hash text except to = note > that it >> does exist. >> 3. No changes to the OID arc being used despite the agreement during = the >> meeting. After the meeting, Russ, the chairs and I had a short talk = and >> decided that this did not need to occur. The problem was only with > getting >> new values assigned not with the current values which were already >> assigned. >>=20 >> That should be the final issues in the draft >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, March 28, 2017 4:31 PM >>> To: Jim Schaad ; Simon Josefsson >>> >>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >>>=20 >>>=20 >>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >>> successfully submitted by Jim Schaad and posted to the IETF = repository. >>>=20 >>> Name: draft-ietf-curdle-pkix >>> Revision: 04 >>> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 = and > X448 >> for >>> use in the Internet X.509 Public Key Infrastructure >>> Document date: 2017-03-28 >>> Group: curdle >>> Pages: 15 >>> URL: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_internet-2Ddrafts_draft-2Dietf-2Dcurdle-2Dpkix- >> 2D04.txt&d=3DDwICAg&c=3D4VfW4Y7UDKzr0jHM1Tk29w&r=3D7jcwf_nHftJUeeRf0 >> f1hEhoYPns7FKYpnjAfuly83Yc&m=3D2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSy >> h8nYxBD-rwM&s=3DwcttUJysVcLmWQ7svq2t0Nb41NgIbfjIjSeBfaduLDI&e=3D >>> Status: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dcurdle- >> 2Dpkix_&d=3DDwICAg&c=3D4VfW4Y7UDKzr0jHM1Tk29w&r=3D7jcwf_nHftJUeeRf0f >> 1hEhoYPns7FKYpnjAfuly83Yc&m=3D2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSy >> h8nYxBD-rwM&s=3DA8_G31FWl2kykg3GSF6HdI-2ScdRpyZUQGbtm1EGXtE&e=3D >>> Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__tools.ietf.org_html_draft-2Dietf-2Dcurdle-2Dpkix- >> 2D04&d=3DDwICAg&c=3D4VfW4Y7UDKzr0jHM1Tk29w&r=3D7jcwf_nHftJUeeRf0f1h >> EhoYPns7FKYpnjAfuly83Yc&m=3D2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8 >> nYxBD-rwM&s=3DsZ2jebdsB7X7grNhRfcOW5E4q4_hNA5PUh9hakL3MIc&e=3D >>> Htmlized: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Dcurdle-2Dpkix- >> 2D04&d=3DDwICAg&c=3D4VfW4Y7UDKzr0jHM1Tk29w&r=3D7jcwf_nHftJUeeRf0f1h >> EhoYPns7FKYpnjAfuly83Yc&m=3D2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8 >> nYxBD-rwM&s=3DUhQ7p4MbELlnuap0ja0gIWlTuwzpH9h7QDzxz-1wkg8&e=3D >>> Diff: https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Dcurdle-2Dpkix- >> 2D04&d=3DDwICAg&c=3D4VfW4Y7UDKzr0jHM1Tk29w&r=3D7jcwf_nHftJUeeRf0f1h >> EhoYPns7FKYpnjAfuly83Yc&m=3D2Amsywb3tVWXtWhbKQaG2UsB1UqsdOSyh8 >> nYxBD-rwM&s=3D8Le8SB-M-UikBklTudIyLmY350YCLZcMS-xBwHhK3Ic&e=3D >>>=20 >>> Abstract: >>> This document specifies algorithm identifiers and ASN.1 encoding >>> formats for Elliptic Curve constructs using the Curve25519 and >>> Curve448 curves. The signature algorithms covered are Ed25519 and >>> Ed448. The key agreement algorithm covered are X25519 and X448. = The >>> encoding for Public Key, Private Key and EdDSA digital signature >>> structures is provided. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission until the htmlized version and diff are available at > tools.ietf.org. >>>=20 >>> The IETF Secretariat >>=20 >>=20 >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_curdle&d=3DDwICAg&c=3D4VfW4Y7UDKzr0 >> jHM1Tk29w&r=3D7jcwf_nHftJUeeRf0f1hEhoYPns7FKYpnjAfuly83Yc&m=3D2Amsy >> wb3tVWXtWhbKQaG2UsB1UqsdOSyh8nYxBD-rwM&s=3D- >> QGwR6ZMLxm7fInDxqNaE6ufW9_LkeZQjADdOHyYoVM&e=3D >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_tls&d=3DDwICAg&c=3D4VfW4Y7UDKzr0jHM >> 1Tk29w&r=3D7jcwf_nHftJUeeRf0f1hEhoYPns7FKYpnjAfuly83Yc&m=3D2Amsywb3t >> VWXtWhbKQaG2UsB1UqsdOSyh8nYxBD-rwM&s=3Dy_nDnvAU07Nn8Pnxx- >> SOP_Hqm0ZBXlyYa9-eO-LGnZQ&e=3D > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_7C179F39-95EA-4583-8BEC-90C30D41F786 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlj8zEgACgkQiuTu0PWcEcsOhgCfe53SJyZeH5sL8b7ohuXveyva KLgAn1925EyTetdpH5dx23/k7NQbkWDq =Emf+ -----END PGP SIGNATURE----- --Apple-Mail=_7C179F39-95EA-4583-8BEC-90C30D41F786-- From nobody Mon Apr 24 13:54: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 441621294CF for ; Mon, 24 Apr 2017 13:54: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 0aKwMUIUJBAi for ; Mon, 24 Apr 2017 13:54:27 -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 2D6C8129502 for ; Mon, 24 Apr 2017 13:54:27 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 88so80741136lfr.0 for ; Mon, 24 Apr 2017 13:54: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=RY1JfEUU6ptWyO73PlIKl7OBqjiBkbEknixMF6SVrHg=; b=qUBbZ1UhOETdL1GAWxSspTbDX4/m6aHUWJd9nfe5bOvjPGNovBkGF02KAcIwf7bkNQ xvoeatFLKAmwFpw6oCAQ8IB4NO69nFlIpgourd/JXpHJC7ZyCmVGP+UWH/RnxCphl34d uF3MGKJi9mC5Ns8owSCsCiJYhiuaunbovdpL6ST3mYWKTDZkVu0lxgUN3PTJqxyoIAEg CI70hHhn4oIHspu1s8Muh1zwD8pxC/5EqyjqibJ+TUsIz08bKoo7Yxoq/ZUaUzbFJ6Yl 8U14PTIyNcK7nZtyvlm2BMgP5W8b7njU8byqAsNn0f3spmKtvepi2fRMSy3v+ZTnZsbA vsdQ== 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=RY1JfEUU6ptWyO73PlIKl7OBqjiBkbEknixMF6SVrHg=; b=KjjxCRksyApSptKujL9rWGF022iGuqPgHCbwiYh5qSrFwFdF3tTkQQ1UERbJ+0T3B/ A67/METl5ZlUNJXuQBMmuKzV5Rxh9Nu/6eiBsVn6b2ChbU/gR/V4G7Q66ljbB91oyNDo qNn5TPxr1RExJMAQ+/zfYtzUeVu7EF8zI8rsNsPwzKnL0cxvOzYwptVH+ati23+tQNAF 031mkp2xmsUpqF6ZIB01/heh6uz/jAt9RzmkMsEd2Q0J2zyW1YgEBM5v+O6d1VDP7HTI OCsf4LJ227hsAg0pkj36FcFRf/CZF80JKt42D6pGCm3L/lv4x0abdqtNFbyjgue3h/Wj lOOA== X-Gm-Message-State: AN3rC/5sez/1CxJrGIiLYAfPuplGwOSUUog3gIwJCngh+PRRtApO6obE nLX29+jQHuumwP5v5aG1DRFZAuGflg== X-Received: by 10.46.83.22 with SMTP id h22mr1422873ljb.17.1493067265473; Mon, 24 Apr 2017 13:54:25 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Mon, 24 Apr 2017 13:54:24 -0700 (PDT) In-Reply-To: <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Mon, 24 Apr 2017 16:54:24 -0400 X-Google-Sender-Auth: W8YqbE8wDeT1go7igzxS0z4ljWg Message-ID: To: "Salz, Rich" Cc: denis bider , =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , curdle Content-Type: multipart/alternative; boundary=94eb2c1ce9c4fc053c054defcf1c Archived-At: Subject: Re: [Curdle] WG status 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, 24 Apr 2017 20:54:29 -0000 --94eb2c1ce9c4fc053c054defcf1c Content-Type: text/plain; charset=UTF-8 Hi everyone, We need some feed back to make sure we take the correct decision. Please continue the discussion. Yours, Daniel On Mon, Apr 17, 2017 at 8:45 AM, Salz, Rich wrote: > Thanks for your second note. > > > > Does anyone else agree with Roumen? Please post by within a couple of > days, otherwise we will consider the issue closed. > > > > -- > > Senior Architect, Akamai Technologies > > Member, OpenSSL Dev Team > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > --94eb2c1ce9c4fc053c054defcf1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

We need some fee= d back to make sure we take the correct decision. Please continue the discu= ssion.=C2=A0

Yours,
Daniel

On Mon, Apr 17, 2017 at 8:45 AM,= Salz, Rich <rsalz@akamai.com> wrote:

Thanks for your second note.

=C2=A0

Does anyone else agree with Roumen?=C2=A0 Please po= st by within a couple of days, otherwise we will consider the issue closed.= =

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies=

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


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

--94eb2c1ce9c4fc053c054defcf1c-- From nobody Mon Apr 24 14:09:38 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 0531A1294E0; Mon, 24 Apr 2017 14:09:37 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149306817698.25786.2876923976717959584@ietfa.amsl.com> Date: Mon, 24 Apr 2017 14:09:37 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-ssh-ext-info-05.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, 24 Apr 2017 21:09:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Extension Negotiation in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-ssh-ext-info-05.txt Pages : 10 Date : 2017-04-24 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-ext-info-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-ssh-ext-info-05 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 Apr 24 14:10:36 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 3FD5613153A; Mon, 24 Apr 2017 14:10:34 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149306823422.25873.10405639427882134053@ietfa.amsl.com> Date: Mon, 24 Apr 2017 14:10:34 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-rsa-sha2-06.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, 24 Apr 2017 21:10:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH) Author : Denis Bider Filename : draft-ietf-curdle-rsa-sha2-06.txt Pages : 8 Date : 2017-04-24 Abstract: This memo updates RFC 4252 and RFC 4253 to define an algorithm name, public key format, and signature format 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-rsa-sha2-06 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 Apr 24 14:31: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 D169F13193D for ; Mon, 24 Apr 2017 14:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 ix4O6VfXiwpj for ; Mon, 24 Apr 2017 14:31:33 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 7BF701294A6 for ; Mon, 24 Apr 2017 14:31:33 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id y33so125594355qta.2 for ; Mon, 24 Apr 2017 14:31:33 -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=JX7+R10W51xRa1jcR0dAuk8c2rR9ILIutrotW2TX8tE=; b=IEjLzdzkEqncN9qrXt5bovpCAOhZ/snjIVD8LAjDvVH65f1mSmsk2fJGEqLh6o5pCY RWTEtVBjmzVCrpJ8bwXXBNHVspzAaZVCezYysH0zcgtqc8G2v5KDXfJTVI8vPR4dcjtZ Lqo/E8XLIVUB2j0YLCPDD99BUYtvh+80BMw2OGs26NDWXKZo52JuZCHAXrCn7W8jlkNE mnO3SW3hZIDf2GESXrOun1JjlJNo36pHHpYIbirVQtGE1ZrCSBRI6o+uIuOmAJWP4gdY XxmdPuZ00RQzqo64mfOzjDuwLCVXgcFr+ZiOzoFLHPZ6nbdKqA+hHF6QZKthwV+czIrM 3OJQ== 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=JX7+R10W51xRa1jcR0dAuk8c2rR9ILIutrotW2TX8tE=; b=DO1m6BQzKkYpm9cO8l9aRlXyMip3EE1xywmFgjeud6zRhyTlGMllbPclzu7wkNczKU KWzCRt2PNp0rATh78BC9cGjZ3hlJa6CrrKkx0HV8YWfXGyVFBVrygs2sCKFIO3O43d7w 4qGKDGQdfL+dQoLcYDsU6l/kVO1wOMBeIY7jfB78z5t300/SH/09BZ7zD1tie+lWYv8j PyyefU7GWpxLuWBvL9Rn+Xx4++BfgjVR9Fi0kGmxWufZ69QNN8w5e2+zdjCaW3dERhBq Nyn+4AjMHSOUIDhA4oBOSAbG43ZYPHIyyAiKV0g3pbXZhdos8P9J72LNg0pV4OVdrVU+ UzcA== X-Gm-Message-State: AN3rC/7qpCHWMqaD+5lXzKclqKpO8lDbiYT96jrSfixtGDx4sKDxdQEM MsrwuAh33rW3Rbfzb2BSYpCK1raA2g== X-Received: by 10.237.52.5 with SMTP id w5mr17864579qtd.22.1493069492718; Mon, 24 Apr 2017 14:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Mon, 24 Apr 2017 14:31:32 -0700 (PDT) In-Reply-To: <2100.1492648147@eng-mail01.juniper.net> References: <7182.1492447893@eng-mail01.juniper.net> <2100.1492648147@eng-mail01.juniper.net> From: denis bider Date: Mon, 24 Apr 2017 15:31:32 -0600 Message-ID: To: "Mark D. Baushke" Cc: curdle Content-Type: multipart/alternative; boundary=94eb2c0b6d8ebd17a5054df0542a Archived-At: Subject: Re: [Curdle] draft-ietf-curdle-rsa-sha2-05 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, 24 Apr 2017 21:31:35 -0000 --94eb2c0b6d8ebd17a5054df0542a Content-Type: text/plain; charset=UTF-8 Thanks. :-) I have clarified this in today's updated version, which also addresses some nits. On Wed, Apr 19, 2017 at 6:29 PM, Mark D. Baushke wrote: > denis bider writes: > > > RFC 3447 is obsoleted by RFC 8017, which is currently listed as a > > normative reference. It is normative because it's needed to implement > > the spec. > > Oops. Mea Culpa. You are correct. > > > The reference to RFC 8017 is currently made in section 3 (where the > > signature details are defined). Did you mean another reference should be > > made to this document in section 5.3? For easier lookup, perhaps? > > My issue is that PSS is ambiguous in Section 5.3, 'PSS' is also known as > RSASSA-PSS (RFC 8017 Section 8.1) which is not to be confused with > EMSA-PSS (RFC 8017 section 9.1). > > -- Mark > > --94eb2c0b6d8ebd17a5054df0542a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. :-)

I have clarified this in to= day's updated version, which also addresses some nits.

On Wed, Apr 19, 2017 a= t 6:29 PM, Mark D. Baushke <mdb@juniper.net> wrote:
denis bider <denisbider.ietf@gmail.com> writes:

> RFC 3447 is obsoleted by RFC 8017, which is currently listed as a
> normative reference. It is normative because it's needed to implem= ent
> the spec.

Oops. Mea Culpa. You are correct.

> The reference to RFC 8017 is currently made in section 3 (where the > signature details are defined). Did you mean another reference should = be
> made to this document in section 5.3? For easier lookup, perhaps?

My issue is that PSS is ambiguous in Section 5.3, 'PSS' is a= lso known as
RSASSA-PSS (RFC 8017 Section 8.1) which is not to be confused with
EMSA-PSS (RFC 8017 section 9.1).

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


--94eb2c0b6d8ebd17a5054df0542a-- From nobody Mon Apr 24 21:39: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 C258D1316B1 for ; Mon, 24 Apr 2017 21:39:44 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 x5n9QF7pJHuH for ; Mon, 24 Apr 2017 21:39:42 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0132.outbound.protection.outlook.com [104.47.41.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D8A120326 for ; Mon, 24 Apr 2017 21:39:42 -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=ajpumCC5d9xjiqBPTNKyluc3plUuDKGA66AtlT2e0FU=; b=PAYfIB1avMgHWq4ePR8kZAVp4AvBSE5AXUrBELSKZxrnc9NCtZbKmJq1ZL2TuOGxM+oJQgWuZNDfcb5E4A4SCvgLAzWVUYZzhQbxcEDRrlbz5pn4J8h1LgOgK+Cu3cPXvLOJfEMz4PKJxOhu/sHMF+rTdpF3U06NhamEYONZtbs= Received: from DM5PR05CA0017.namprd05.prod.outlook.com (10.173.226.27) by DM2PR05MB733.namprd05.prod.outlook.com (10.141.178.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Tue, 25 Apr 2017 04:39:41 +0000 Received: from DM3NAM05FT025.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::206) by DM5PR05CA0017.outlook.office365.com (2603:10b6:3:d4::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6 via Frontend Transport; Tue, 25 Apr 2017 04:39:41 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; 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 DM3NAM05FT025.mail.protection.outlook.com (10.152.98.135) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Tue, 25 Apr 2017 04:39:40 +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, 24 Apr 2017 21:39:39 -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 v3P4dcmW022864; Mon, 24 Apr 2017 21:39:38 -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 5FBA71145A; Mon, 24 Apr 2017 21:39:37 -0700 (PDT) To: CC: From: "Mark D. Baushke" Date: Mon, 24 Apr 2017 21:39:37 -0700 Message-ID: <53117.1493095177@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)(39400400002)(39860400002)(39410400002)(39840400002)(39450400003)(39850400002)(2980300002)(199003)(189002)(9170700003)(2906002)(8936002)(76506005)(86362001)(356003)(81166006)(2810700001)(106466001)(2351001)(110136004)(54356999)(53416004)(105596002)(7696004)(8676002)(5660300001)(48376002)(50986999)(4326008)(38730400002)(50466002)(77096006)(7126002)(117636001)(966004)(47776003)(6916009)(19273905006)(189998001)(5003940100001)(53936002)(6392003)(55016002)(6266002)(6306002)(305945005)(42262002)(562404015)(563064011); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB733; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT025; 1:/RcStLfBQm+g71QYoDc4zsk43JpkhafxPDPOY0lD3iG6D6c62adPwa1+vAkXuQf98DPXxPQZOCwh6HsW+oqavXBFHOqIE0A3zXP0jjTJ0RyznLve8tgSrgX8uqf1gIpNRf0pZWsQpC53HtRP3u6j0+PXQEL6FykB0tAfBU+0cqjlC5b5mRHRFXoDOZuHHH+qvjHF+IK57QxXJ2gUfReBRl+2TJaEFFs0et6WVcWirDi7/twbPB9T09cCaf3pp3+pb1TTle4gZ6Fw8UQMNBxWZhd2z1JLwwId6FEVYUZNeAiHJshrwZLPWbZChnAfuv9l0aidTeVARpubBDQd7CskIY4ohOAX8kTdEbWdruQy+1B3d9XCNOJ8y6Femkd+ZC+cniKhm4bABXw3fB1UVxmzqWb6ZZzgMPGvwf5Pckmfudoh16dJAz1+RG1ZsyG5u71aT0HW49eulfyjYthE5p/huFCzxglBq100qHeBe8oOfBQLHd0uNQIClDdJFnv6UGkLyRYeRqjI/Gi/G+0q6Sc86AY+F1O6RKkRnGT1kkTiQp6cwK1pov7gNwGrbHXmpYORi4JHLOFiVLBSbQ+OZOywte7xCPOoqoc3nsdaeYzFDO0= X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 64e55013-b485-4084-ceaf-08d48b951634 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM2PR05MB733; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 3:aVddYUuSh5mDhlfD6580QI/FSpgZUNsc0xlnr7Tt2cDex5ilDYpm4BT+rW8pYFN7l4ZfVc0ECWD7j8i11d5OW6PLCbr/5NHoGmtKSSHrqz1zLcQyPrksTtei1lsG1Nhm8pk9j7abC9oIORqJgLLd40tnt5LvEZBdCrwoqNdL8FfY3N43zhUKSIlJIB4dnTAGznPBrMjpxZF9y90G/ZeVXP1/n/5er0PUE3Al51fMYZ29qNHdnS/mhT0ztZw/7bHphBuXPAKR/aGQChmwE82Wgn+jBKura3fEq6zBl5BAkE4K9Z/AWbC1rG+OOXOWCkxUWiickPctycKuvukgjlfDlHSf5vVj9rCr9wuoRMnT70dnrSJ8nevY9D4t6jogXGv79+2kq5bGgtH+6rhgAFMDqliqQeA5j/H1SBRenh5iocji4dWgrBYu9QO/h9YGF3YUnTlPHRJedV1BtaXBuxJXAA== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 25:5ojcJysFHyWpnT+aAii1OQ1QIY1dBWW7tK1WvU+L5zIeRjIDoOQ+YoLj6a1iSDP6l50qs7d34eNljyqL+FBR+zydL9XMDJknjO5a6NB7ekWr9Mu6gGjhmXqwApR+gKNxLN8XViTP2g0uAzVur5WcrKDRxQzu38MJUvwR3AntRMx1ycFG0yxC52n9izh5fFT1SN+ItrPssYEl7fCL5XJUHWhNL99CrsusiCaI4h4FwWoZuDvk+bDu9KvVu6v56QvquRDdEzfvhSTaPGcAd5CySM4a5YAdz3s7gaVUm+9Hve9YywuXZglz24OONYeCS3PKVSOmV5BHMF66vfthRH8P8NswTerbmW3uzh789peFfLwXiKRC5GmLYxlWF9Fo+Rp68dRd8sUzUPHAFNKIgRPp9d5vj2dEQTtvMkDDfAr+ugTjdBve11ec9ln0BEC/5NaJRu9W3tvQah9gqTeQF2j4nW07ZjUGhkHB0kjTlxujMFA=; 31:isk/TdP+IpGJLXKSKleucITIUKsZuuqDbakRGiIn9QFXr4TcfdrNqwElUl6xTMO9zrXBxgk88Dyua3Va6wkp7oKv22ptl+HO+V44lFAgtX1VkSvXPh1BZyrgNS2ymPyDwdcwdH3Mzm/0U3WPiP2cxwoTWOP+0X7G19WzN07T64PcOw1dMGrFwqM8iu5DCoPqA7hF+S8g7QL3/AEH0g/KD6YvDwO0c7geZ1DxoAE8iomWPnSDXUBFLiHeNeYma0Mp X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 20:QDJPHAdt5dqlr2rN/kUTl4vgXr5ByaYZOL+eccfU+eWswcvDPfhelurOXd2U3WlpkkzSqatQOQTXsVMVB+LWeTD7lXQWpOvtVL63sitTbhEUE6ZOnNlsifNM+sC32DQUFG87P9P+pjZmxmt2WLiQbBpZLlOsRIFqd7Bl0nLjYcmjuE9Mk6OeHclTo78Jt0Otd+ukLj/4o08BvbYS3CpR3Al9HaI+fJGxkW3hoRABT8nqR26Jgtg9GG7qUYE/SoXE94DAT+mB0VmcSpfKSQF/IqzBjEFzJQS+7UOhOlmc72RG+tzahpQtSPzuM3r7X4PVCWzn07MObZIx1vlDv/UdSJl5GbEH43AcsP4Zzm8B17RiIHwBpEYdgmbeNcoY8yPUIgy9G9vOTShDfFlypyawAJp7UFu7kXMDAW0FtQqwgqMqXpduXCpAcI04Pm0Mwq0Vx6i8MHahSb9PMP3AtzKl7Mj1Uqo1yFtr7HaxSS/c0NFpRHrKGh4wXxwoBAN5P5vC X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(1591387915157); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(13015025)(5005006)(13017025)(13023025)(13024025)(13018025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DM2PR05MB733; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB733; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 4:f3+35M+kzKPGnE9YrazRcl9gIq8LNHraExsofGvXiBGziNJtMwNff+QitIJO8F/lkXq4sr72rd1nsZVOlKhP3jaZdUUBsKBaW1z+mJx45TT7JiNzIGFS6mX5SZ1kE5cUiuz9IInUioheEwbBXcD9sU/BiDFJ14t8rW6ARC2EFNkcXVZ+OiPAvVQGA7FA/L1T2s6TmnS9ygEkZaNF1HhCbO7JSzBkngFsGNZ9GC9+ytjKeeSH5XRlVVmOI2N1mymsIs66cxjw7ilkzn0TVGScB6I+stflXBfptKGCPWsIGN71rQZ5QyOz8YAWGhnaHfxG6KbUpTj/MriO1FG+EIXNHtgRCmVjPmseiX2mUX+DNZii0HYnwV2rlPSiUWSSp6GEs33x/vd6NOCn8sMNo78veSMf7EnWbX/I/Q21HusgGzViA9UPH9MzsKzJEy6qG2hQ3pqd/XNJIjPrpP92J8J4BxV1VzIVmIEdWAsUlAV4Fgw05N3tmp6Uf1PAL6nE8eb2gdNbQIcndCLBHwinO4DnA1bL6VBptmIKsUHJ2lwqbueT7Ow9JahPwigBMInFhDbUV866kZhg5HuivL9FMF2HxgtU7+jPCdWsC+MNNUy2VUlWZCmdwSR/vrb4F7aZTZjrntBIvQgZlsTUzUI5rS2B5HJkHG3QalTuJRYRByOUbYxJvJr5exoRKleCfn3VjirvdDMqi9srqC9h0GGqA9gLtNQ4c0FFPFfpOgyKld53ReFOXSJMy3inOVPpXJLrrxkijQrQLW/93mfe/jTCVfZ0rmwxwWb31+oT7Zzc2bFcleAtFIVBo45lkvgrGWVjICVfphfir+zXIOx3XpqiYtf80czViG5XgfwsHLmLAW2Oc29qDrOC0Nvjs8MYL3FOodvc X-Forefront-PRVS: 0288CD37D9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR05MB733; 23:uVPFgbchl4LvHglqjHYsk3/5CsCsfh8ZPJbqVOvurc?= =?us-ascii?Q?PHL9hANvpQ2Gv/reXuFgYbzIxR8AHYqkKvl5tlZFyMNhlIPtusl09lVRCHj5?= =?us-ascii?Q?MSLUAlvan6LABI+xHV1jYANxXzQFa7MeCBIb7cVPbFem2vMm55eKDcn3M/MS?= =?us-ascii?Q?gQXWZ6R0cqagdEEAJ71E845seJII1+LBquqvztQ4/G5SS9XdjsHMz9OmBi3v?= =?us-ascii?Q?C5uSc7qRdFSg6bBEMoABDPc1RYle55fZAhL9ZD7QMrePYahU06ahIfJRpVg5?= =?us-ascii?Q?X9kOBY17X+UuiVmsSerZvbm3n83CmYm7gnTdvo1RkyCJcyzTFSz6dY0bLGx1?= =?us-ascii?Q?WiL4XUEp/Bf/815Dk9om5GM2ns9rnAc2tEfgc2TO/qpOLOf8+AsYU3CYwfyI?= =?us-ascii?Q?Xz1cKdjUStvaGwaBGL8uj9xWdvjrIH61CCJYaA+yanbuugWaJdwPrLkbKimZ?= =?us-ascii?Q?CyfLdPQ3gKzOA4DcDKtsXonbSrrC6FUHP3YJVxATdhPwwuRvaMeIALnNuprW?= =?us-ascii?Q?kdVzfc1i6trdnzq6aQhK4lv6EcuubMhVIJl+nC46B2Q0khnkj/bCqCmonSBS?= =?us-ascii?Q?yzQw6JFYIWZM2iOr7q0AUGbTe1F8H5f+D4dFhZxW18FChpEumfQmrCNuP265?= =?us-ascii?Q?XJXdrYwe7E699OIGMG0GICxv8W6Zjf2oqVdKYW4PMOVn3ITuuTMZFlmmXuur?= =?us-ascii?Q?UxfjEW5UAqw4l7S77G45FvO0656scK5TpkoCXqCJdavIbVskd3zDa0Cm25Dn?= =?us-ascii?Q?pVTZ+K2KcPuzOoBuwKv2C4drwd77RDrB+sMcJSHbIT9KgvGbiGU1YkLwGREK?= =?us-ascii?Q?R/2NPawZUzKqcl9g6SOz1THRQkdJThEYmeacNvJVzuWORYfkG+T9eJ7j/153?= =?us-ascii?Q?+6a05Oujpv05OfLLUarHonG6KgoH6Bsf6E2QaeSBvcif6MnYeumUdRFO8WTe?= =?us-ascii?Q?pKV1MkiOqefaCXaN2cZrIX8AHn7pocKh+JxPSzJUID7hsxT86raIdeI0pVBA?= =?us-ascii?Q?8CCWQJN3gNOf8BNIY/fo9vunS1trV/9OOVEc+TfWg8w2Axm0h3vfisYQDmC+?= =?us-ascii?Q?3+PNe3lppN/EF+1brXjT7xR2MUtTQZ/F/maiP0MgMJuoMjpGIkeAjwyCPW0c?= =?us-ascii?Q?8M5nxq0dYFgCFcy9RgLQXt5nm6MxBXaA6LqjegF6fg4to1cyXoVc0Iic5Hk0?= =?us-ascii?Q?lmiqSFbaZMEcjb9+N30D0JP1IThbLW61XWVG50UPiObuJjVljlmul2kg=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 6:4Gp0BPEzKRlcL2GrKtGto5e/BKS66oUpPiKw3gdY3fY2ITdH1st8dpaIulH/DQdu6gnpEzlIm+XqTqwTh4U07O16xAPWpjB5kcxD8y+22VBkI8oiPw3yGDhsZr8KR4/YwNCPOMD9SmQXkoLbYTOdrtwH6ITpiBpd7hL2qFGFK+KYte/nQXXDJav22tC7yry6/yhizoglyb3XWI5Y3CCb7EN6UbX73frd1RsnJzLs2gxAwXiI5Ieq9m1vf8HxAjGAJ5nydYDDoybeZ3mvt01oKa1wk9SrBWqvxHNCICW2btTK7c2TuT+klCxDyK0He2FwKXM00/pCHfagr/2oSkkvBMUrVMtugSLCwK8U7rdgw9Z3Aw4aDvYmTSg395sKLouXOXHhP9MB8xKNyYV5Uc5D+dVzn8pnw4MpyF1Q92ER9gj9EAotSE4Iyco1U9duEe4yBx4P+9vPET6t6EoXCxvrSr3Plnkpn9OTcw49xZB7c3BThpMWu5BtT1oQ72AqxV02w+Z8YYkuXVTWCHYBiKl2eSQTxjQM1kSKeE8p6H79RLE=; 5:Llwi+3gIH+OtOYI6pIXh+QZxepAJE80nTSIei0ZXSVIjVeG4fbcWQbOmEEkBA1bnX14a7Ln9BqLMG8ugWYAenIfxgPGNHUxeajgsO74+Sk9hG5cEIpDnS91wyRTc2Q48s8tCEtlJPcmS3GoxAXsVew==; 24:nvRU2YjXLeBvGWShkHe1c6oMHrygEe+3ku0pYSq33KrsPQ5vztgQN/6kyZy/paJtj4uuadRW35kuiZ1BMoBdeDjM3js5BgQ8tRMH1Vu9LKc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB733; 7:JNfycSsHY5Yti3MqF/z33MfkH88bJERAnSVYTRrkNSOdQNeCbMZSIzSzZI40Yb5kAQYXb3iOsK7a2TPnUw3Fkd28oDxqq+GGgKWVth6XabC7LyNMNxZLErKBcOL38HxNLGXICHcSVCWznhMPvUzTMu7dUM93obn2FFRv69tA5spjSZMtBH8xT7CXvQf5lliQH9rBwrFPRFFqBVLYT3t4i6TkyU50vYfx73ItbUwJi/HxPLQX7EUH3oiDfS5dFS5746lzK056afkKg41BiYv5MOQOLC0RqommGeSbzYWdO65DPIMnfO4v/mMUITb3bO9x7lExerDeSpRu/xGoEiIlWg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2017 04:39:40.3408 (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: DM2PR05MB733 Archived-At: Subject: [Curdle] eddsa25519 & eddsa448 for use with SSH 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, 25 Apr 2017 04:39:45 -0000 Hi Folks, Looking at RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA) I am curious to know if there is a desire to create public key algorithm names for SSH using it? http://ssh-comparison.quendi.de/comparison/hostkey.html shows 11 implementations of ssh-ed25519 and 3 implementations of ssh-ed25519-cert-v01@openssh.com. I have not yet compared the RFC against the SSH implementations of ssh-ed25519. I do know that the use of the SHAKE256 as a hash function for Ed448 would be the first SHA-3 family function used in the SSH protocol. If they are the same, then it would be good to writeup something to add ssh-ed25519 to the IANA https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-19 -- Mark From nobody Mon Apr 24 22:20: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 820671319BA for ; Mon, 24 Apr 2017 22:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 mgcLxVxAf_ey for ; Mon, 24 Apr 2017 22:19:59 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 47D2F126C25 for ; Mon, 24 Apr 2017 22:19:59 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id c45so131169929qtb.1 for ; Mon, 24 Apr 2017 22:19:59 -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=XXck/aA6jYLms1CeiM/oDKO19Fjck+2kQA0kCDHx6aM=; b=OMakthKyqiCodswCBAN5pcSgIQg+OilRW0p8lTBCqUXFcHUxMzlk5DcwKStgqISUV1 ogNwGiu7hwDttQB2iQgRvEtu5Bh2wnmnUzuxMdORA7XW34iIrhuqD43MOgh9FguqLOqp m9b14tIeNs2lC9nBfZJ7lQYR03EzwCviTXADQELUoafOUC4r4A2YrxZGyfrWMasJAYKt lOytxs8C1ChakEvqt4tAGTRT/ycKgl8/p4pxZr+KJVIW3PngBVTW+YgOcdikXNomlLm3 /b180h2JR1nfKw6MwJsYZAYQt8X/9d7/qqwdbtg/DUyc0Jo4kZB8U5PJEEpKVkBnhFPw 5qQQ== 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=XXck/aA6jYLms1CeiM/oDKO19Fjck+2kQA0kCDHx6aM=; b=LTo2rl1vlprLcPJgoESHI19Ut3eMJxXw7DHSI0yCUR5ZTn1MLji2MOeo2ztWIOQ61A h20t6PIpPppO+aWKFaUisLAl0qujjgpuNVGgLWjC0NZF22SELx3JOZZjg/65abjwEKrn wgdcYr171wG4GTF7Lmojm5qhRa4BnOjUoUnhDH9RQU2HFapreOc9tvhy7J7UQ8+ADTKQ 2tbLunRDAXmjLAibg+z+stvRwNDj1+OGqYJ3+49H7XwZmu45XFAqaihg5Ra5WFxOamQx UR87XZFmqpurg0VvqdlAEZZzW5BsnvJq5YidDng6ryGIEktDNtd8K8e72DRfKFslgxLE 5mSA== X-Gm-Message-State: AN3rC/4+M1tsEYIbVpOnggZrzl83uNaHZkR9fRWF9pllJT/yDX1vtwuK wja121PDctb7L+DI78qVEE90ee/NeQ== X-Received: by 10.200.54.7 with SMTP id m7mr28774023qtb.177.1493097598492; Mon, 24 Apr 2017 22:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.138.239 with HTTP; Mon, 24 Apr 2017 22:19:57 -0700 (PDT) In-Reply-To: <53117.1493095177@eng-mail01.juniper.net> References: <53117.1493095177@eng-mail01.juniper.net> From: denis bider Date: Mon, 24 Apr 2017 23:19:57 -0600 Message-ID: To: "Mark D. Baushke" Cc: ietf-ssh@netbsd.org, curdle Content-Type: multipart/alternative; boundary=001a113e43d2f923f2054df6df9e Archived-At: Subject: Re: [Curdle] eddsa25519 & eddsa448 for use with SSH 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, 25 Apr 2017 05:20:01 -0000 --001a113e43d2f923f2054df6df9e Content-Type: text/plain; charset=UTF-8 I believe the spec for ssh-ed25519 is already an active draft under the purview of Curdle: https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-00 On Mon, Apr 24, 2017 at 10:39 PM, Mark D. Baushke wrote: > Hi Folks, > > Looking at > > RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA) > > I am curious to know if there is a desire to create public key algorithm > names for SSH using it? > > http://ssh-comparison.quendi.de/comparison/hostkey.html > shows 11 implementations of ssh-ed25519 and 3 implementations of > ssh-ed25519-cert-v01@openssh.com. > > I have not yet compared the RFC against the SSH implementations of > ssh-ed25519. > > I do know that the use of the SHAKE256 as a hash function for Ed448 > would be the first SHA-3 family function used in the SSH protocol. > > If they are the same, then it would be good to writeup something > to add ssh-ed25519 to the IANA > https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh- > parameters-19 > > -- Mark > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > --001a113e43d2f923f2054df6df9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I believe the spec for ssh-ed25519 is already an active dr= aft under the purview of Curdle:


On Mon, Apr 24, 2017 at 10:39 PM, Mar= k D. Baushke <mdb@juniper.net> wrote:
Hi Folks,

Looking at

=C2=A0 RFC 8032 - Edwards-Curve Digital Signature Algorithm (EdDSA)

I am curious to know if there is a desire to create public key algorithm names for SSH using it?

http://ssh-comparison.quendi.de/comparis= on/hostkey.html
shows 11 implementations of ssh-ed25519 and 3 implementations of
ssh-ed25519-cert-v01@op= enssh.com.

I have not yet compared the RFC against the SSH implementations of
ssh-ed25519.

I do know that the use of the SHAKE256 as a hash function for Ed448
would be the first SHA-3 family function used in the SSH protocol.

If they are the same, then it would be good to writeup something
to add ssh-ed25519 to the IANA
https://www.ia= na.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-p= arameters-19

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

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

--001a113e43d2f923f2054df6df9e-- From nobody Tue Apr 25 15:31:17 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 7655C12785F for ; Tue, 25 Apr 2017 15:31:15 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 VnYXxUqwV-B5 for ; Tue, 25 Apr 2017 15:31:13 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0092.outbound.protection.outlook.com [104.47.34.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60BE91205F0 for ; Tue, 25 Apr 2017 15:31:07 -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=eO+0pvHOsenrLu2aIUvNN/k5kIK/eDcZoA7wSJUFbEc=; b=JeOE/OZckfRQme8bY7/u2Pe+DSyJR765Rs34tBzSf4ElFM1W+xfbEikcrkCVcovxu0trTpcCpDAEKVlYxys1cpd7EZl8C9pBlXvA58imC+obhmtoUsOD9CWgUepUpTgs0FgnvIQCuukUExmEIzjH2iDhXPILc2duAUnTgNMyrE0= Received: from BLUPR05CA0072.namprd05.prod.outlook.com (10.141.20.42) by BLUPR05MB037.namprd05.prod.outlook.com (10.255.210.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 22:31:05 +0000 Received: from DM3NAM05FT050.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by BLUPR05CA0072.outlook.office365.com (2a01:111:e400:855::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6 via Frontend Transport; Tue, 25 Apr 2017 22:31:05 +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 DM3NAM05FT050.mail.protection.outlook.com (10.152.98.164) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Tue, 25 Apr 2017 22:31:05 +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; Tue, 25 Apr 2017 15:31: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 v3PMUxhe006164; Tue, 25 Apr 2017 15:31: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 35B4D11446; Tue, 25 Apr 2017 15:30:59 -0700 (PDT) To: denis bider , Ben Harris CC: , curdle In-Reply-To: References: <53117.1493095177@eng-mail01.juniper.net> Comments: In-reply-to: denis bider message dated "Mon, 24 Apr 2017 23:19:57 -0600." From: "Mark D. Baushke" Date: Tue, 25 Apr 2017 15:30:59 -0700 Message-ID: <17136.1493159459@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)(39410400002)(39850400002)(39450400003)(39840400002)(39400400002)(39860400002)(2980300002)(54094003)(199003)(189002)(9170700003)(2950100002)(7696004)(54356999)(38730400002)(50986999)(76176999)(76506005)(229853002)(6306002)(86362001)(4326008)(53416004)(117636001)(2906002)(2810700001)(5660300001)(50466002)(39060400002)(6246003)(77096006)(55016002)(356003)(5003940100001)(6392003)(7846003)(106466001)(6266002)(47776003)(7126002)(8936002)(48376002)(54906002)(81166006)(305945005)(105596002)(8676002)(53936002)(189998001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB037; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT050; 1:Bft8weHrFwfl8EJyFTDRVb75JTkMVeSbm69Z+//C2ioAJVAacWJF3O8oc/nF5eUt0FDmbkaI99gRBDa1Blb8tZiVd+h83mel46lqjdcm2POTNIsuZc4goiSrtoHmYlxJc4c1D0Dkn+dNzehrgp5WedatoKFSsvwqajI13g7Jx/mBZLO0J8eylrzlIbc3KqxxgKt9FGPAlS1GX0Pjmx6L0wf1fsLkHR3Q9E71HlZtwTWWHupsbC32af6vrILrxWGTS4Xv/aCeHJkj9ctfMJIYZv4l75KpPbEftP6jJDJWTCQvgYHiYQ3GE4UNiOtpuLEobVJouJFAFFqa09c35NBHnfVAuuUQ6ggokgtV+Sdrx5EfdG9m3aGT6bR9krzgOXJCDoeO9dQ1WWQ5AAo0N/edwu2QxKK2otefpuAqt7t+55L5fdcsl3fog/CDNHPcraQgvuRkHwyNTxcf0aZyQrjmtADypSDdeowH3n3E9nnORELFkKAcfiexONfX0curnNYWEgWurwf7+YrsBi7TMzkWoUnzP8DJc6W0oIUAIrfMpAW0oS0/527obxavgNqKMJ8A X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 06c00d13-74bc-4cb8-ef07-08d48c2ac2ff X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR05MB037; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB037; 3:P2CL9JdN7yFJe8lQYNA77UI4QcOWxTtIZWHXLSAWHUWCkEynTXTXAxYH+gSNc3RSuF3GbemGTdLFC85gWkRux4tGxrZafEcKJ3BqkhXZVGeWtPISSE6UX2/ZBDtXUy+YybVrxvhXLGNc3W4xVOUL9QWqXRMtxqYm4o5if1rBmJ3LDwHKNetL0T/aMvQDhHgfiunp1toODhwKIKzDeEpmxMbFDawngWnmuHEmfsGWPZ8PVTg4twgb9CXkgbu9TDLyGn9YqCRlk/nVBpG5zw6UKGEsH+I7yqRhefQpxidULUL3uMYARQxX4yXDcY+Gofp1UrfZsr43n6d5l6knLS+57dgr9f3fVcqSuQWlgcK4yflVbJosRifSTfbQkt3O+jewZKCY0xqwQXy2x96Qnj1gdRrbldC6IgIIS/cjpUUTaXlYRNRVckQK9xOV/aXY8RZBdq2aLsjwV+6aNI0MApTXFDDvtZ31VBDc94oRgxktKm7aky9vHDAxLML2YH+2Bcm3 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB037; 25:iY2ybhCr7gVNUzSNiqsVWjZFwtPUpvuMIciBNkI5EFpH63a7ZyjxpQBRPpawggU8AHRLsgrvKw+ht71HxWzJYpwk5jCbgbaeq1/yE4nAcrOLPqFyvQIZKj1RuPxQ8GbEahSOc4ruTBsUDwBHbXYPjHSU+P9fitpUkTVvLlTVaUfjdoXC3I8hFKGst7gFjNmGigaIcMJjHDKbHr2tEc9b27TkfzSPTXO3CPzm5cwuKnvw4F45NoFEwLNFiu8VslcsP/+QQSsVia339U8polEoUeraku2BNEIFclupwkssOm+n3qAIDT0oHV2anHy7I1RjM8HEE6vn21YSZH1HXmCVDjTvaBJeVH4aD8SVThd0kJ1aaQtc2e0o8JvC71pujOVDMMSjdGxLOB3EGYOi3dYw4a9CXujU1F7jGRW+KruOf7dPDoqKSRtILDdZGPc2cLO0ge2TP+CuDhDXWXMScSWePdWnw+yF6NYiwMFsXUytmbM=; 31:HMbk5mC4HM0NhrLc7K8Z3Dstx52tUmbTvg8NmbAYGSweSfV1PgRi/8UYGTTYHox5mjfA3UQ6n3K+p0g5KvtBmQByFlna2B74C5FJuQXZVl3daVyAOA/ty6p409U6cxXOM6IoDJ7dDXjPdPcYNiqX/PNMf6nDFqzcEVssULpMGH9PNNT8/bw/4MeGTUCgSKcXuSGVlddHis0XFPShwk1nnuGfghnioFJS3BwiEu9Zw0/du2xUmRAi2A7NiWFKply0Z4Voti08FXmWUsgeR9izblPQZOGedbB1++v0gy+LqGo= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB037; 20:I8UxpD8P1+Mpl7xzY5n6wfRImjT29judV4ZvTr3dRSUdqvoTSZCv62LZOFL7GerAW2BTPdzyhK2U8pa0EfcO4xxDs34syV6qKixJ7KUiBSNt0xNumyXFXOgUOwnNF7RVWLHcvhObN7Vpffvfe8XY1GcchywziLhPA7oNNHjmhaN79HJ6VboFc89a2rX/IJqjjWAbbLp68mKf2/AAiUXUebADXKVYxwGjP0B3GL1Mo21UfDKn0C+YeI+61Ph6MjETVW3zy9H6bVDs2GWagZbxOGXHthFl4co/blsmegAgAAMQVBwdRoNX35jmR1Mq4GM1cKKJmdWwyIufaV5Q5Ltqem07i9Q1eR8pECCa5OuHnCo7P34PSfXVbM5Mou7dLaTcxt9ir8/pDdE+sY5TcbCx6bmwsGhoAuY19CWjb9+g4nCZXmUWWtcfj53Z7C7A+9kODNiWL4Q1eWFsgBcj2oFCT44DgpRk5r7oDDpJdOmYCLmCw4FSVz5+reKmZf7UqgyW X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(5005006)(8121501046)(13015025)(13023025)(13024025)(13018025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(6072148); SRVR:BLUPR05MB037; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB037; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB037; 4:/GqEVMnmmJtqHdhNPgzhM33K+EIBXxh8ukUQp2sjF7cfaH3BealXc3JP0qY/mGpCDH2kZVz4wDXHcIuG94WDsNQUJl+mVax2m2+a1Z74RqUzym6/df62liW/Wn9qZ7cl0m5w5ooAUnzTYjgxuLZarluaFcw/1Ebp4uf+tjR8i8U4RBIp6O97GNuUmXBwOgNbBY8cJ75aJbex01JoTPclBpt1QfkcEaCdZi43I+R5S39n4lDBgnZCKg0KvzawCz42a3z7kouS5cZzL8398uN+/XKZx7x7mCb2j4yuLMVmkw+uVEhfmhiRRIaCPByf3DdMso5RPOHWIbD0Dq0Uj6i/0WVzQH+KRBTcnlXESs3RrjfjiKdkTs87uKtze5rC35nhSvlK8dbWSpbe9J5U0ZjxdPCCSi0jtITb8Dwqvgz3NGznHktsaPk0ea3HVkmCLx2d8TzkVruNvmeSIZ8LSIBvYR7gbjXvcc+DcswwrP49wpdx/I2mMDqXVH2sMlcQPkOMG+g5PClcRKOxkqSkdz/dqsmtJdJLvPGvqlsPq9toE5tCkHyCW/PVlKC8lBTtefsLfHfRbUbcDbo2SnerboPrdeasiW43yYhKAO323CccCkaAhpVR/eIXOQ0HZ/NIPkY/EioIV5/aW7cU7L7Cz7aOaT8tO9t8++WDcQzJQ9jLc4Lm6uglmSb+0elfAJELL+Xh58OhaM+HMnIVv1OqTiCJo8NXqNsnG6qDBCOHmSc1V9Pzije36TM9y+vKBO6PfTNM8RrkhcxbuIRur8rKaeZ0aM2iG68ZzTKRqsRczml+s1KzPSmEiRZJnxT7xwmvnyTIZ9nC6wYN6WQ5SyG7DmxCiN/UZwOCRBNMIrrzfrhuxgghP1djI4aXnOjPRiFM7eh2f4PY9EqRJXP/zrpr0wppgg== X-Forefront-PRVS: 0288CD37D9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB037; 23:xGPLeQxdZHUpOaRBNgMypqD7rRJj5LEUuDxdxNrNEz?= =?us-ascii?Q?KZDwIkDu9lKeIV8wORlOvfbJnYsrejyr2YhU7hUyTPLNSHQjlNCKiXEwEpNl?= =?us-ascii?Q?u6pXLJMiip7XvFuMe3BjI5yb/kSUeX/13KtNv5uMxA1g8GO7tzwi9sc0pzVW?= =?us-ascii?Q?vl/88RCLIyF+YWsOn7OSFtoFAMn+QMKmvCXlnoEXPTMYu1JSw/p9Yt900HzK?= =?us-ascii?Q?AA0RhwVTKuE+mHE57YDUXPU+XM5z9VZ6vaPOOavR6EoYD8ZSucu6aon9BEnt?= =?us-ascii?Q?Yz+BsL+51m3Aci0bagFiwcj0smWZ5H+c/l9/q0/262IAb3DkKDubEUUQndCd?= =?us-ascii?Q?+NAUQqFCaffvlO/S6+KAp3B88rBmcyUZMwf4DJXTl3A90xanPv/zN1Y2ztOT?= =?us-ascii?Q?Xk4A/XlSqWi84qZUrCB8patikOQliNQKeZ4H7mQllfdxL885ZeV4u9t/ZNPJ?= =?us-ascii?Q?9hFpFRUVpKcmlCNcqMHeu8jBXa/Rm61znJNo2KUk6c2BjfWZehTt0aN7PS/q?= =?us-ascii?Q?IOLEMDGeVrbP15hQo7RbTm9i/SIhog4jnFz2hyrrWJcpfly/A9OgjCG4LvfX?= =?us-ascii?Q?0DwSn8zcM2/EFzXwMXIBbJzuV7fODN6gnpbXsJoIjLludTvReMVK8hk30+if?= =?us-ascii?Q?wDtR4RIgfnX06dsBj/2q0TiTgf9zPXadSQFUDWP+Ucq7cCJhzGL7gtl/BqqE?= =?us-ascii?Q?asNAma/QImqXw/IVNE83GH65W4eknjCH87aJBba9S/QfOZQ2GOyaTI5n8HmM?= =?us-ascii?Q?d230a11lATZBbaJKwHY0YP/f+64l72UQv1YHrfVBW9Xwf6BImhddVP8+yztJ?= =?us-ascii?Q?oGOcWb12IcQmGhHoKzJtLl1U0eAtqxWKB2/AKYOB4pQtC4VOAa4rweBi4yz/?= =?us-ascii?Q?gq/y27Js2x57hTCzMDCCn6ZlWiRcE3mIyBkRFVuUvfPlZ8saI+9n3xpwcfkl?= =?us-ascii?Q?rpkWDPr9aYV3lng+Souo7eA2HQPj0i7eJFixkzfmCiUWYRZbZcJyrJETC6FL?= =?us-ascii?Q?y9+byYO6T9Mc+29OeRHeydCNU5ORCk1g6n+h2zWix+PUYieVoVYrsFLr6CUA?= =?us-ascii?Q?PlQPYJP5J51J48Ea3d6W5+3g5W13QyWdmzCbCbIBb01X9EwnuiiebrbF5OeD?= =?us-ascii?Q?h05pP1BsFE+Kcxk1HfZ2CLDNinFrA5KODna7X261F5lzBGrI9NnTmAwwgbqR?= =?us-ascii?Q?WPRa31revrbuXEa5GrWXe3P8whf/9j+b3YdhYJezoSrvy7+PMRLKDkCCf1VO?= =?us-ascii?Q?EVh0D9jAG7vuAyQYuH08HO2xK1kvkpYp79GIvO?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB037; 6:cCGEkaOp6ZcRt0hgyJ4PtOm2/q3Ln7Gq7Ms/BWPy2H9LjzW2ClxqZMRqw5UCO7vVKBu71xIqNo8Dc+bJuH9U6By9/x4Y89uXu7f5ayHCaXZe3gLIP9qTaLGKqWB+MntCG9+WNbeKN2NqrGZ7OYhfYCywI0UFyygVd9DfUhedujwpefp42UItE1b/InqouG4Hz4wlIY6FJYecOXM++JtigrWHZwSyfsEGFF7T9QgZuTIG2+0Ng2BLp6KQzCXDRFBZG7bLN/kqJLWqLAvSO1v0yr3mk+LPL6Z8tiPRmx/qK6mz1RZ0ppAsp4Ze4KE74EGYjd3Q0sOnchVvP5pVeG/hyVt/wPO5SOQwiNmNZYl4NNOBPVSOlnZFhU8+nQklpFhuNQv36fjswjJ59+3rirWxnhmwVkPNJjmVpLqYKleKy81Wpog5aj5LaHLhWuKmTgC7E0bzmwUbuRx3Nl5lWnm5k0qWPsiWiCzyp2ZH+490pPeNgdTwCwPdv77h1D5jrprDpsBkbvihJqjhcgdBwZVbCnN4Om2phUNfQrw4j3w8V7c=; 5:Vc/jCq3ZzoYi2QRY43cr/S+LBC61ZYdkz6ELZQa21WiCnVfp32ufypnrmk6CZbVfHgTNYfEd5JYD4a+krH738X8zlVeGO7ovgBgcv6DdUtHxW6S+H4/dVyuBDEyUcpAIDrFsKEmc7unj0nLu7f1h4w==; 24:7DQELB/0MkVftweNiDjaBhJ11BPIPjjMSEfSsavJTssUfFjpp0cajdD+hw+lVknM1/m4kkiUTEtUTuXfH/1t4/Zfa5oU606nGmn1T0ppV64= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB037; 7:vbbGKESFxFFko5cnLUGg9MBxxkyCZ34JzOG/PUzs5jor5DrFYwPjR2EM1ggFefwm0ss6uo0cIMlZ00Yzs2bg1/ANj6QHPsjpkCfk6DlV76sO7/qk9JCEGHKPgRiNn5kXlwrDnwLhKI9whOc7hZZO4VINFEL+RIP1fnC26ZSoMklf2ex7Zvbcvtg9u3zqdNpImlGe/UcBcl1iJDjP+J1E1yPwiI3ezxcaizmGGqc4K2Snn5jbSKaAKmpDJTGk6qzmTybV/eCdQea/U+Qg0qRxghtR/depTm4O9+hQCrKYR42oILele7MkfcH722e6I9L0WRZVhvpw7WxlsQXfj0nkhw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2017 22:31:05.1646 (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: BLUPR05MB037 Archived-At: Subject: Re: [Curdle] eddsa25519 & eddsa448 for use with SSH 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, 25 Apr 2017 22:31:15 -0000 denis bider writes: > I believe the spec for ssh-ed25519 is already an active draft under > the purview of Curdle: > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-00 You are correct. This one is expired. I wonder if Ben Harris is likely to resubmit it? -- Mark From nobody Tue Apr 25 15:31:27 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 8A6321205F0 for ; Tue, 25 Apr 2017 15:31:16 -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_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 1E2FcG3uBuSH for ; Tue, 25 Apr 2017 15:31:15 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0105.outbound.protection.outlook.com [104.47.40.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 546F61294D3 for ; Tue, 25 Apr 2017 15:31:10 -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=eO+0pvHOsenrLu2aIUvNN/k5kIK/eDcZoA7wSJUFbEc=; b=JeOE/OZckfRQme8bY7/u2Pe+DSyJR765Rs34tBzSf4ElFM1W+xfbEikcrkCVcovxu0trTpcCpDAEKVlYxys1cpd7EZl8C9pBlXvA58imC+obhmtoUsOD9CWgUepUpTgs0FgnvIQCuukUExmEIzjH2iDhXPILc2duAUnTgNMyrE0= Received: from BL2PR05MB035.namprd05.prod.outlook.com (10.255.228.154) by BL2PR05MB035.namprd05.prod.outlook.com (10.255.228.154) with ShadowRedundancy id 15.1.1061.6; Tue, 25 Apr 2017 22:31:08 +0000 Received: from BLUPR05MB037.namprd05.prod.outlook.com (10.255.210.145) by BL2PR05MB035.namprd05.prod.outlook.com (10.255.228.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6; Tue, 25 Apr 2017 22:31:06 +0000 Received: from DM3NAM05FT050.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by BLUPR05CA0072.outlook.office365.com (2a01:111:e400:855::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.6 via Frontend Transport; Tue, 25 Apr 2017 22:31:05 +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 DM3NAM05FT050.mail.protection.outlook.com (10.152.98.164) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.1019.24 via Frontend Transport; Tue, 25 Apr 2017 22:31:05 +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; Tue, 25 Apr 2017 15:31: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 v3PMUxhe006164; Tue, 25 Apr 2017 15:31: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 35B4D11446; Tue, 25 Apr 2017 15:30:59 -0700 (PDT) To: denis bider , Ben Harris CC: , curdle In-Reply-To: References: <53117.1493095177@eng-mail01.juniper.net> Comments: In-reply-to: denis bider message dated "Mon, 24 Apr 2017 23:19:57 -0600." From: "Mark D. Baushke" Date: Tue, 25 Apr 2017 15:30:59 -0700 Message-ID: <17136.1493159459@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)(39450400003)(39400400002)(39860400002)(39410400002)(39850400002)(2980300002)(54094003)(199003)(189002)(189998001)(229853002)(7126002)(6306002)(4326008)(2810700001)(305945005)(7696004)(2906002)(39060400002)(48376002)(50466002)(86362001)(5660300001)(117636001)(2950100002)(77096006)(6246003)(38730400002)(6436002)(6266002)(105596002)(7846003)(55016002)(106466001)(53416004)(76506005)(53936002)(8936002)(5003940100001)(50986999)(54906002)(6392003)(54356999)(8676002)(81166006)(47776003)(76176999)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB035; H:BLUPR05MB037.namprd05.prod.outlook.com; FPR:; SPF:SoftFail; MLV:ovrnspm; A:1; MX:1; PTR:InfoDomainNonexistent; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT050; 1:Bft8weHrFwfl8EJyFTDRVb75JTkMVeSbm69Z+//C2ioAJVAacWJF3O8oc/nF5eUt0FDmbkaI99gRBDa1Blb8tZiVd+h83mel46lqjdcm2POTNIsuZc4goiSrtoHmYlxJc4c1D0Dkn+dNzehrgp5WedatoKFSsvwqajI13g7Jx/mBZLO0J8eylrzlIbc3KqxxgKt9FGPAlS1GX0Pjmx6L0wf1fsLkHR3Q9E71HlZtwTWWHupsbC32af6vrILrxWGTS4Xv/aCeHJkj9ctfMJIYZv4l75KpPbEftP6jJDJWTCQvgYHiYQ3GE4UNiOtpuLEobVJouJFAFFqa09c35NBHnfVAuuUQ6ggokgtV+Sdrx5EfdG9m3aGT6bR9krzgOXJCDoeO9dQ1WWQ5AAo0N/edwu2QxKK2otefpuAqt7t+55L5fdcsl3fog/CDNHPcraQgvuRkHwyNTxcf0aZyQrjmtADypSDdeowH3n3E9nnORELFkKAcfiexONfX0curnNYWEgWurwf7+YrsBi7TMzkWoUnzP8DJc6W0oIUAIrfMpAW0oS0/527obxavgNqKMJ8A X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 06c00d13-74bc-4cb8-ef07-08d48c2ac2ff X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:BL2PR05MB035; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB035; 3:OjaJp1VYZ7ikUz6z7+QB1eEvkl80kwvHUViDXXrR2zuNe2TlZJP3kG70922dg0cz4g+lws9SpLGehd4P8yscaY5KaEl0AbKQNKjf9bm5lSwTwofMIxhEOKPtrCGC55mr1Y0sAXsWkw/l2J/g7FP9HZN75uvzfhKVj+1YQ7njXheRKCcqMyINZpVZYzcct6p7+OBmBtvZquwcOSNMdxpieHj2PKR5ybu85zOGxqeN2SaF82sxZhFKNV8/h1rl/k5/bZksOmWpBchQf+UlubzbP3s6cVE1vaFjilHJ1te0PBokmApkBqeoNlrxatMFYWE6bxf20It79wifTipiURio73umPXXH8N4edp5kaiYFqYy3eM4P6xp2O1ILte7wpP98UNaxBRqmouoWWgsh82ptID5hnd9DVYwVaZpNOCiNBaQjSW3Kyvkik+BVu7zE8xh22iZUV7ev/xEBDY+E1ui3A7GbBywjrISYhYx/PsGXKOKn2D7h1CGoOeHVAdUGqWkH X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB035; 25:FVaO0z+1yqgSwk/U6YgKomh801q+GNvy6pgHStnMgwFUE36oG4yiSwzp3Gi5FOi3OAZQyxOCMphOEWE7GXcAdyQq8BxDh4b+rq9/+ZXJeW9dRKQgIjGrf03foklYBlJIRssurIb9l8XptTmzkEGouARWSe4OfeiFd5Esf+bof4QEpMEfJUbkGPpXMBr15M1x/1RaZ+Vn03/A730UzfpbA4r+EXFXKEAI4WipghAK/KLydWCYbtxwmm3WO/YseRctP9SntDOMn9u51166hSYirttZVeYwWbfM+zO/GUMZLDNTS3WgmNN8ip6n5+hMmljFInj5s5lt7ORxc8/5kVHCjF3x2PgTmwZSQT91NEHTd5MVTbgwn3RSLf8784572f7C7VNg28/7I/iq8qkSS8SzRWP8Z2of+WflNDymq9nSrGJl7uIftOtFwpvBOSXa0DVZFDCfNtxlKETS1elSuznbulihlG509kyGltyCFlo6GSk=; 31:C5Ct8DqBJeAUtGdpp+hW7cNdKgeiSSJKsI4HvTqK7QijXkiNOIYdfVwXzBNSYC/gROCyHYLybbx+RqpOpYGOsHdIX2aasv9RNBJ3fpl3o1RLUm/fTfQsosmbCDiYOGHRSlJ8J18ed/FytSMRWWBofnAu5mjIn27VdPR/+E+EsKFN9yRLl1SAxMOwY3QTxmrr0HI0n6lmU8oLw0D6hxCVPdfefCL2/dzfczx+CVLcSpVfamGocky6HzGkzx7DF0N/ZthKY0zUwIL1ga7NTb+iIHRYgxvlCiJQKO/MIJSxOTc= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB035; 20:/meTFCDN0BdrADFv92Lm5CkZUZFIl/ZnpwXqSmtM4WExezwDPVdcAZK/5TGFm1Bar5fcr1/Soktzp29VkmW+S/yWwpzmG7NvmQsWj/XrARm1cgKaJ7s+pnsDPHT0DCc4NL+h98/+6CIPa3IxWxWoaaE7XLyLtUdKmFgELb/HZWumflR7pyqtBEj2wh7g23w4+rh3DM7fyLlzlpnsn7qCx/vmrJpSqrGpZ8O/hw2hJycHmKP/bkFNe9owiYLvnwqUkooeM84S47A9eVvg1u0b6GzXHZpPTDJtZoFj/N/LBRzreO8/7WD+OXcuPjQM6edd0VE2yvxV9TTp4uMp0Z99h+Po6fXRrXlQdrbGeQ9NICtLmWhZ6AWAAEMy3ev9mIl1f+9TTpIse36rdu5OUo3qZY9N2ls9zHHuJbKmgaaol5+WFUS+Ku2tBnXnVH/14S/Q/dsOAXn6syIna8wbiKKw2VTvvGa6BcfjZiUsyYptvopSBbof4fBQJezfj0pr1vSq X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(13017025)(13015025)(5005006)(8121501046)(13024025)(13023025)(13018025)(10201501046)(3002001)(93006095)(93003095)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:BL2PR05MB035; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB035; X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB035; 4:LCPeU3ozwA6EEJWMCU+xHVcRXEpmW0wItdJ1pZ3EUdohYP2OhEROoLAlfDHusXmYVHUGQN+YXjtUn99aFkDU/TjVsyf7T3LgAiw+Xpskxj5WZK1EOJ62yeRCipU1EvxlpjwjsN6e338eSiXpaWshxrrPiUThvrShz25fkXO6CK7Hv6gBiU8irOj1QZw71jf4wOH9SerXJkS3e1Zs0PMfaNkAoDocZO/Sgc2167dbXVLrL6IQs93JXm84+Ek1DwAI5BwxUcEJQCCXuPLccsBAi1JTGeyC/tkJ0giZRd6FefnMccfQiUbFHqyfkvQ9pdLxyTjZf36hD9h6tcKrJPaypqx/ZfToDuIjSX+Rl+5I+y491s0qWmLD4Futmgh4i2ZbBK2UNBozpRaMrotnmTaE7bGnTt8U9Gbjbd6jjmv7urUHqTBRZ6gHvZyD5feSAq++M2p9pcOdjlmH7mXTJCte+Yj5lpM2THXssrsfaL13arC4xUYSRwO4cARE2uReYL4SuKG0rWa5LLBtjKRsYnv5AQYypmPHlO2iYDYY17OAoQcbJRpDPszE2pV3874LexRPt7JqPoLpJp5G+ZJbLhj0B2dZiLIbwwBmJDG+rUmg+epYHNoGFpMdVzSmiLK3RaQTVBPeZ2KlMk8Q2XZ0oyq3DNKsvw33u45/cBVF55JqYZZ4OtZjcBD4HF9Am7mUXh8CsyCxjGMtxJgt6sJwaQLEkDJpa5roR8JcP9kYzO2b3JzMsMPueilsa3mwx9JKjc5NCLEg38PtapgLEUzyfwnX1ADY/H6DQT0yRTs7ZT5e+GAn5snRRtfBaTiHFUy0Dn3zWGZDmT7E0bM9MDPBNf7pbwL2qw1gOmhurWDTeBH6DuccF85CJAnsqXj/+xfWloPIg7GjswrnV+iMNW4Xa1hIEw== X-Forefront-PRVS: 0288CD37D9 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR05MB035; 23:nDasmtmk9DoVqzu+Uz+xCgZdDo366jXRQPlzeLY1Yl?= =?us-ascii?Q?kENvACRwP1dWdra05WeZFRMvRtr5ROVKe39ljYFe25qXi3qBoy1okJFhIrnw?= =?us-ascii?Q?PVtAO8AJmhspkm6IYQNaSuKgXMpoXSsi9CoBCde/KS25hvXqpxtDV/cxt90P?= =?us-ascii?Q?m98+Kwck7xjRVnv2pMdAZrGumgmotEIglnFSEeQbNf67f5nIbZzePNZQ/Fml?= =?us-ascii?Q?hJ6HPsBGl3JUNJhbrMwgY0jPSkyIlCdceTx+dqdkdIQLrfmeEEsw6SyRI1jj?= =?us-ascii?Q?V6eY6ig6L3d4MMg7XHy7m157JhVKe8ZQn2v9az/OCj3xPcz7kMeXMQD7fcZ6?= =?us-ascii?Q?NFaknBuDwOJNE1Wntnox/eMCfJLvh4geY3FeII8skd27kMkMsxwHSYcFGGhK?= =?us-ascii?Q?QOdobQfkBdG/qiorT4WS8ZwXqSGEx7oEhSGzi3REBofNuBHPtQxqDzXD4T1L?= =?us-ascii?Q?KN8/GCigkIV09KHBUBvYJ+1+ZD5N8LJOH3oEq+b99wtBuHbxk1uTNP8DDhB0?= =?us-ascii?Q?wDHiZyxrYtOsZj+pE4hb/FJhkA2e+FmVlPEC8vjNTdilHIqwH/ZaBJC2Hy8R?= =?us-ascii?Q?QrkSkKO9nEF2Vb2r096jdUlcWPyxw16unXgjTxQNQy5iX8v+82c3tQu/vrcq?= =?us-ascii?Q?6A7Fxvb20TmhwY8wPoKT/DuMci/FggFg0bbH8csjv6qq8GUiLXmKw7/hPR2u?= =?us-ascii?Q?OWmvI6sEF95PWhrtbbwvjKiNX9UCCE/IvxFA7zfZFGb2RYoqQL2PoID9RTmF?= =?us-ascii?Q?fXDaYdz0OyvucDC+M51UJqXdzYeh7LYpU67KRRVxsW2p0PQcverBFEc17ZFX?= =?us-ascii?Q?j4rdgQm1JByPIEYxkS/v77M7QOuUynsHh0IoxUlukMMGxc3DDCu/S5XcooVo?= =?us-ascii?Q?iVG3FXbThVmpLR4ZV/66Hox7puLy1t2cNMxlFXfQ4YAEqCt70pBzN10omTOH?= =?us-ascii?Q?0GFofehAPs6oUFLcsUteMumWKo09/lSZxgvmTB1Vcl+1/1CtuImIUQP5tgzL?= =?us-ascii?Q?gul+ny9/95DFYN7raAifK5K8ghJRrwMOKVvy5vQ8+xnTuBZ3QVWZVtyoESe6?= =?us-ascii?Q?mZACG8BQqRbKZ/dP5+0wF3tX4ERSIBSQlqGc6hXP6KgY58LgVUfzPbRY7XfK?= =?us-ascii?Q?KpXHDlctpndEryxBtDwtiS8/3S9NBlGFrHGPLQeDgVjbis+hnWZowpPmZPth?= =?us-ascii?Q?KwzqPml7OmBaE7KaBN+KOuS9+3kOIeMTf5X4lcEd38h+uHkzPhpiypiw=3D?= =?us-ascii?Q?=3D?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB035; 6:rbK2rfQJfNAYSH1bdBpRtAC7u7LuQP9bfeCBum0ZFhW1qqvyKcqt9Fx4eOhCqPfSZ8Dh1Uf8Lh5rh2wmUH7nHWGRx1TnW74m0qf4MPIERViSiTiDJtOuRhWoportsYSXnDruiUsft1y791LBXlbL6/j3oVhnVMN4wYJMbqCI6v5MoriBgeDwyvbNVLoeLSjiQqlWfX37Gb8kaZP+P/2Zk8BC6lfM465cqTZvUCTu8YoVTtiTmhjPYZsERykT7pqKgeyRwvdXnmD5HUxXEcZ0g6qrJ9T2KiEgSmfysxs52oY9P8AemC3C6pICatAjRzt5qNVBnXFyVDd4JIz40kFAp25cF6FtysHsZMORgr2A+0tEzk9V5gM6/IAnMXwtB/Et7yhyj/thqeEiSjuxNQREb45lVti+VtZmnEkQcHzCwQ8kOf8l91yJimylIvWfYNeT6FdeJtzOAJM2AmudYTdTW+wuVwm/P2UqlgQwpzGgxjIljWS7E8iZ53ribluzJoHAII4gznqPwuA39feeKTsYhsXj5Q5+P6fgXuuodyurYSY=; 5:bxkeADjy+feLwT1awJJXrCX6tMh7dWXgJs9rxU0FRuRybuvjkQxAAoLoXEvQqeEQ09I8kXmm8OPu6IQS3GkMicHwRCq75RmYyV9C24setdV/Hw7k0zfutZQtgp36WMJpluwHMezlZa/tu9xZi8zCHw==; 24:NQ8KO9Yj9O2KLQUWgWKJ+1LPEPC4lxeYefKqLrdIVIwWpbBmbi+wZS+9l3Pi51pJNfJC+gd36BbmdyOYeTnT14PyNyOzuvIkU9raomaH0X4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BL2PR05MB035; 7:eTO4oBClcr7uz4/H40UnUYUoWLH3ryFH+SqL+2UJqdfsL7L+VrK+VByEi15Siujn3aormnDt+EM3/l7uj69ahOVG+RowABJ+9iC4SSmvu5VIaCZRxcTHdhugI4Q3V66bJ9VLeKaAdpz3kuD18mRwcvbbfPG2us4TW6yDyPnsfApO10ZH+TeGmvITm9eNE+9cuTNETfkbh+7mGwrauROXkwBA/YxNyw8eP3NT7Py31yhLF/MTxuAFtQsBktsvvJ+CSo6P3ivYpSCN6NJSg2NoMZsYQuidvRu4vRlsCJ1aJm5TYTsYJdVFKIYkbMwqxh66BsDif0KUTOitFj9YbXyx8w== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2017 22:31:05.1646 (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-Transport-CrossTenantHeadersStamped: BL2PR05MB035 Archived-At: Subject: Re: [Curdle] eddsa25519 & eddsa448 for use with SSH 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, 25 Apr 2017 22:31:16 -0000 denis bider writes: > I believe the spec for ssh-ed25519 is already an active draft under > the purview of Curdle: > > https://tools.ietf.org/html/draft-ietf-curdle-ssh-ed25519-00 You are correct. This one is expired. I wonder if Ben Harris is likely to resubmit it? -- Mark From nobody Thu Apr 27 11:05: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 62F66129454; Thu, 27 Apr 2017 11:05:15 -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 PokRYMtM7szr; Thu, 27 Apr 2017 11:05:12 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 BA435129462; Thu, 27 Apr 2017 11:02:15 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id t144so21943070lff.1; Thu, 27 Apr 2017 11:02:15 -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=gKkxH2WBivs3msi/6jfWzlqDjgEHiLiHXiblodzNUjY=; b=BiIPPnLzKuThTLXD5ys3z9ZMapp/cqlLx4VuDhsRYaG15EaH6ClNqs1U0mpCkTyjWI gL0hACo3zLAEnz6fnES2IvIChUZdMPzKqPEIHSyloOZbZ/2i22rAvk5MGbRN43hvIsJY xVfM7vRzGlpoiDymcyF2OIpcDFSx63Pftr/nvB8lXdrJ6kBceOlox9RJ6f/PJX4DbzYT +6qIApa0trj1UQKy9S7/9owmpfoc83/meIxRZPD8nY1eMTZ6XinGUfHhywhmk5lk94Ka jlplXqwx9WKQS5eL+MDxirpzTprIzHX8YLrryI1ZEBJpdCyHL92Y5QP/Gyy6LH97jwhH osGQ== 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=gKkxH2WBivs3msi/6jfWzlqDjgEHiLiHXiblodzNUjY=; b=e9CYBPysaiy7sov4Be5ALv0NDqWLMCFCyGpCd6IrQwcLxyUG4sxJvDRIFpeeKuAlX7 NXzLev67WwyKu4oo6ZVpm4PiRlYMnuZWJcVt5orqf5QG4I1qGa5IRjf+A3aIKVHQky5J fuy6kJ9l2ehXKy3Vvvi0YG02L+fhJEJM+6aSufapW7AwCKn+/LLXvSBtxrxgbILa8k72 20RTiIpPgJhPdGa8lMMOd7Mk3oIIrpMlBLkrvplz+mMTQKmKgzp+fDLPq1NtTweXTknp LDjyN29cHpnm+QG6nTMesOHL3qFpe+q9+nd6yuKCX2831Z3Es79lYIqTkR3QLc+psDeA mrdg== X-Gm-Message-State: AN3rC/5dyghccqoL1MuS6yj7dFESfsB7iLKOsL7dWO0U9hHNUHIUCaIk shLMBrV0qKk42mXtSJNtcDtm1wkqzg== X-Received: by 10.46.33.135 with SMTP id h7mr2759819lji.96.1493316134052; Thu, 27 Apr 2017 11:02:14 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Thu, 27 Apr 2017 11:02:13 -0700 (PDT) In-Reply-To: References: <1492030032.3662.174.camel@redhat.com> <20170413001912.GE30306@kduck.kaduk.org> From: Daniel Migault Date: Thu, 27 Apr 2017 14:02:13 -0400 X-Google-Sender-Auth: e8035QGPyzFp0g8xJog24V-CVE4 Message-ID: To: Russ Housley Cc: Benjamin Kaduk , curdle-chairs , curdle , Simo Sorce Content-Type: multipart/alternative; boundary=001a1142b632b52aec054e29c17d Archived-At: Subject: Re: [Curdle] Call for adoption 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, 27 Apr 2017 18:05:15 -0000 --001a1142b632b52aec054e29c17d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Regarding the feed backs we received the two drafts are accepted as WG documents. Benjamin and Simo, please upload your documents as WG documents that is as draft-ietf-curdle-gss-keyex-sha2-00 draft-ietf-curdle-des-des-des-die-die-die-00 or equivalent. Yours, Daniel On Thu, Apr 13, 2017 at 9:49 AM, Russ Housley wrote: > Ben: > > Thanks for the explanation. I withdraw my concerns. Let=E2=80=99s proce= ss these > promptly. > > Russ > > > > On Apr 12, 2017, at 8:19 PM, Benjamin Kaduk wrote: > > > > On the other hand, my draft is squarely focused on Kerberos and > > the GSS-API ... but I am also co-chair of the kitten WG, and my > > co-chair is considering being replaced, so it would be somewhat > > difficult for it to move forward in the kitten WG in a timely > > manner. It seems much more likely to advance quickly if progressing > > through curdle, and it does seem to be in scope, to me. > > > > -Ben > > > > On Wed, Apr 12, 2017 at 04:47:12PM -0400, Simo Sorce wrote: > >> On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote: > >>> Wouldn=E2=80=99t it be more appropriate for these documents to go thr= ough the > >>> KITTEN WG? Their charter > >>> (https://datatracker.ietf.org/wg/kitten/about/ > >>> ) covers GSS-API and > >>> Kerberos. > >> > >> Mi draft is strictly related to other drafts[*] in this WG that are > >> defining transition from SHA-1 to SHA-2 for SSH key exchange. It seeme= d > >> like this WG is most appropriate to review that draft to me. > >> I guess I should have added "SSH" somewhere in the title to make it > >> clear. > >> > >> Simo. > >> > >> [*] > >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle- > ssh-modp-dh-sha2 > >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves > >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2 > >> > >>> That said, if the Area Director would rather this work come through > >>> the CURDLE WG, I can live with it. > >>> > >>> Russ > >>> > >>> > >>>> On Apr 12, 2017, at 11:40 AM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >>>> > >>>> Hi, > >>>> > >>>> This mail starts a call for adoption for the two following drafts. I= f > you have any opinion, please raise it by April 26. > >>>> > >>>> - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt < > https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt> > >>>> - https://tools.ietf.org/html/draft-kaduk-kitten-des-des- > des-die-die-die-01 draft-kaduk-kitten-des-des-des-die-die-die-01> > >>>> > >>>> Yours, > >>>> Daniel > >>> _______________________________________________ > >>> Curdle mailing list > >>> Curdle@ietf.org > >>> https://www.ietf.org/mailman/listinfo/curdle > >> > >> > >> -- > >> Simo Sorce > >> Sr. Principal Software Engineer > >> Red Hat, Inc > >> > >> > >> _______________________________________________ > >> 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 > --001a1142b632b52aec054e29c17d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Regarding the feed backs we received= the two drafts are accepted as WG documents. Benjamin and Simo, please upl= oad your documents as WG documents that is as=C2=A0 draft-ietf-curdle-gss-k= eyex-sha2-00 draft-ietf-curdle-des-des-des-die-die-die-00 or equivalent.
Yours,
Daniel
On Thu, Apr 13, 2017 at 9:49 AM, Russ Housley <= span dir=3D"ltr"><housley@vigilsec.com> wrote:
Ben:

Thanks for the explanation.=C2=A0 I withdraw my concerns.=C2=A0 Let=E2=80= =99s process these promptly.

Russ


> On Apr 12, 2017, at 8:19 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> On the other hand, my draft is squarely focused on Kerberos and
> the GSS-API ... but I am also co-chair of the kitten WG, and my
> co-chair is considering being replaced, so it would be somewhat
> difficult for it to move forward in the kitten WG in a timely
> manner.=C2=A0 It seems much more likely to advance quickly if progress= ing
> through curdle, and it does seem to be in scope, to me.
>
> -Ben
>
> On Wed, Apr 12, 2017 at 04:47:12PM -0400, Simo Sorce wrote:
>> On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote:
>>> Wouldn=E2=80=99t it be more appropriate for these documents to= go through the
>>> KITTEN WG?=C2=A0 Their charter
>>> (https://datatracker.ietf.org/wg/kitt= en/about/
>>> <https://datatracker.ietf.org/wg/k= itten/about/>) covers GSS-API and
>>> Kerberos.
>>
>> Mi draft is strictly related to other drafts[*] in this WG that ar= e
>> defining transition from SHA-1 to SHA-2 for SSH key exchange. It s= eemed
>> like this WG is most appropriate to review that draft to me.
>> I guess I should have added "SSH" somewhere in the title= to make it
>> clear.
>>
>> Simo.
>>
>> [*]
>> https://datatracker= .ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2
>> https://datatracker.ietf.= org/doc/html/draft-ietf-curdle-ssh-curves
>> https://datatracker.ietf.or= g/doc/html/draft-ietf-curdle-rsa-sha2
>>
>>> That said, if the Area Director would rather this work come th= rough
>>> the CURDLE WG, I can live with it.
>>>
>>> Russ
>>>
>>>
>>>> On Apr 12, 2017, at 11:40 AM, Daniel Migault <daniel.migault@ericsson.com>= wrote:
>>>>
>>>> Hi,
>>>>
>>>> This mail starts a call for adoption for the two following= drafts. If you have any opinion, please raise it by April 26.
>>>>
>>>>=C2=A0 =C2=A0 - https://ww= w.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt <https://www.ietf.org/id/draft-ssorce-gss-keyex-sha= 2-00.txt>
>>>>=C2=A0 =C2=A0 - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-d= ie-die-die-01 <https= ://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die= -01>
>>>>
>>>> Yours,
>>>> Daniel
>>> _______________________________________________
>>> Curdle mailing list
>>> Curdle@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/curdle
>>
>>
>> --
>> Simo Sorce
>> Sr. Principal Software Engineer
>> Red Hat, Inc
>>
>>
>> _______________________________________________
>> Curdle mailing list
>> Curdle@ietf.org
>> https://www.ietf.org/mailman/listinfo/curd= le

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

--001a1142b632b52aec054e29c17d-- From nobody Thu Apr 27 12:52:44 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 EE721129B60; Thu, 27 Apr 2017 12:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 dnQiPZroNYkj; Thu, 27 Apr 2017 12:52:42 -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 17C2E129C04; Thu, 27 Apr 2017 12:49:19 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v3RJkcYv002177; Thu, 27 Apr 2017 20:49: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-transfer-encoding : mime-version; s=jan2016.eng; bh=Be+877PnxgCcH1pImwV7ONuTiA0MdZmoVNOKNjYEZpE=; b=OpqZJi9P66pOpmaFawo90aZymem//hgorPU1Ipgr0uPPKvq8/ama7NL3hSCcWIrBeBvA pK00qGhRv8iOPppLTvTS168nV8zq5yYzUo6PJcH2gNO0IHtlAVgxeCM2LKfvfWvO+tCO rpeZ2lDtU9y9aIWoJ1p4I7O0aGAf2TbiTdYSu6z93JtW0tfPgX7T7lZYRdK4K1Lt9z1N bIg5CVmwngF5rIDhmoUUeSBrEanRoiAhCKuImmFiS4hzZTyMCLgLVNkfUStS3tnYDZvT OQLGF3qG1sA6bChLlEuwFKssMrEB5hpoewz3hi16Sle0CvJdD3nO7SkMUjfHo61Adcy+ dw== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2a3bmav1mm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 20:49:16 +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 v3RJkAM5013672; Thu, 27 Apr 2017 15:49:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a02gv1j59-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Apr 2017 15:49:15 -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; Thu, 27 Apr 2017 15:49: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; Thu, 27 Apr 2017 15:49:14 -0400 From: "Salz, Rich" To: "curdle@ietf.org" CC: "dcrup-chairs@ietf.org" Thread-Topic: Welcome to the "Dcrup" mailing list Thread-Index: AQHSv1jTwT5pX7lxPUmKyYgD3xeWy6HZntKw Date: Thu, 27 Apr 2017 19:49:14 +0000 Message-ID: <9beed427024849208d05370752c18365@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.206] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_16:, , 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-1703280000 definitions=main-1704270323 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-27_16:, , 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-1703280000 definitions=main-1704270323 Archived-At: Subject: [Curdle] FW: Welcome to the "Dcrup" mailing list 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, 27 Apr 2017 19:52:44 -0000 DCRUP is a new proposed WG. It would be great if a couple of folks from th= is WG could help with the crypto. Link: https://datatracker.ietf.org/wg/dcrup/about/ Charter: The DKIM Crypto Update (DCRUP) Working Group is chartered to update DomainKeys Identified Mail (DKIM, RFC 6376) to handle more modern cryptogra= phic algorithms and key sizes. DKIM (RFC 6376) signatures include a tag that identifies the hash algorithm and signing algorithm used in the signature. The only current algorithm is RSA, with advice that signing keys should be between 1024 and 2048 bits. While 1024 bit signatures are common, longer signatures are not because bugs in DNS provisioning software prevent publishing longer keys as DNS TXT records= . DCRUP will consider three types of changes to DKIM: additional signing algorithms such as those based on elliptic curves, changes to key strength advice and requirements, and new public key forms, such as putting the public key in the signature and a hash of the key in the DNS to bypass bugs in DNS provisioning software that prevent publishing longer keys as DNS TXT records. It will limit itself to existing implemented algorithms and key forms. Other changes to DKIM, such as new message canonicalization schemes, are out of scope. The WG will as far as possible avoid changes incompatible with deployed DKIM signers and verifier= s. From nobody Thu Apr 27 14:51: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 7DA2C129514 for ; Thu, 27 Apr 2017 14:51:27 -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 EZ8AS7xXfhS4 for ; Thu, 27 Apr 2017 14:51:26 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 D1DC6127873 for ; Thu, 27 Apr 2017 14:48:06 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id 75so24624920lfs.2 for ; Thu, 27 Apr 2017 14:48:06 -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=9tb8nGH52HYI3DM+O7lR8CAiUcqa89Bl3N2sZyDuwuo=; b=rwn5yWVCNaLZuo8IubQxLbZwyFpQyXwqLfc963gYlAgg3XDlDRV/PW07Jb8o7kaCSI kjYqW+lnZkUv2Uo4f132ITJD70FWt5jb5YSSCPRnmVGWSWXb6OVL8WVbpS2EE8PXBiVJ bG60HQxBMObdInHuG4dUyqn6OwLNoYamgJVNBU2NZ11eFXr5+JWNWsW1OFebfzmo9kw3 M1epFADZknKwz3ilbddbhuAYSs6tLQJbwqFQ2KGP0+O7nHTA6x6BTN5PxRYH6wf/q4S7 SDecu35kpykq7rJORDEJLN4touPhQlHhiEX1QGfH1e/OuafvZjuRZ8B0NSii0xDLfjKb /L8A== 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=9tb8nGH52HYI3DM+O7lR8CAiUcqa89Bl3N2sZyDuwuo=; b=jrQHJACgN0mSFd2Y/n8+QO3DCjpclWItfPdQpt13tu3BSX0PZIWy9XUtkJbW6V2Xfu LGB6j+tob2PQ9tNTZ6eZ1Sc7nb+/P0EVES2wBsGVGzyHYCDE6kFtfA3RVZiKaeC/O45h gkwxqGdQ6DJRm2w1uoMGXdHNuxQuUR1x9YWRngumWq13ItRZMvi1CI8tam2sGd/DMjT/ TWZ8QVhaA+r9WXqSURknhYJYR+l05DE4wnOVKvSbvJUc9WCtQzA8WM7IPyDNa4rBh8kG 2Id5g1S2VGOCY39rNPL+MyqzaFk4Ja6FrwgiQ635LFnQZ4/c6k8el8n/v/m+SOHFTUbp JsmA== X-Gm-Message-State: AN3rC/54FrMoiRPIGgh16WkmWi4xBy8I6XHU78SV4xb3ez0CNJAZRo89 mfvQKfPooVeuT9AOZTMqmzEhsWki0936 X-Received: by 10.25.190.79 with SMTP id o76mr2884262lff.111.1493329684947; Thu, 27 Apr 2017 14:48:04 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.85 with HTTP; Thu, 27 Apr 2017 14:48:04 -0700 (PDT) From: Daniel Migault Date: Thu, 27 Apr 2017 17:48:04 -0400 X-Google-Sender-Auth: aDQkmRMBDWOaGV9sbru8E8mOqe0 Message-ID: To: curdle Content-Type: multipart/alternative; boundary=94eb2c1a1b7e6767ae054e2ce903 Archived-At: Subject: [Curdle] Call for adoption draft-lvelvindron-curdle-dh-group-exchange 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, 27 Apr 2017 21:51:27 -0000 --94eb2c1a1b7e6767ae054e2ce903 Content-Type: text/plain; charset=UTF-8 Hi, This email starts a call for adoption for the following draft. - draft-lvelvindron-curdle-dh-group-exchange [1] Please provide feed backs by May 11. Yours, Daniel [1] https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchange/ --94eb2c1a1b7e6767ae054e2ce903 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This email starts a call for a= doption for the following draft.
=C2=A0=C2=A0=C2=A0 - draft-lvelvindron= -curdle-dh-group-exchange [1]
=C2=A0=C2=A0
Please provide feed backs= by May 11.

Yours,

Daniel
--94eb2c1a1b7e6767ae054e2ce903-- From nobody Thu Apr 27 14:58:24 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 8D01312944A for ; Thu, 27 Apr 2017 14:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zEiT38HfDgmi for ; Thu, 27 Apr 2017 14:58:18 -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 AC8DA129B95 for ; Thu, 27 Apr 2017 14:55:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 131B430042C for ; Thu, 27 Apr 2017 17:55:35 -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 id8VdvtQxkKe for ; Thu, 27 Apr 2017 17:55:33 -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 8F575300239; Thu, 27 Apr 2017 17:55:33 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_30E79EE4-2ECB-4642-B25D-E92EFEDB6536" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 27 Apr 2017 17:55:33 -0400 In-Reply-To: Cc: curdle To: Daniel Migault References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Curdle] Call for adoption draft-lvelvindron-curdle-dh-group-exchange 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, 27 Apr 2017 21:58:22 -0000 --Apple-Mail=_30E79EE4-2ECB-4642-B25D-E92EFEDB6536 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please change the Title and the file name to include SSH if this one is = adopted. I have no objection to adopting it, but please change the = document title and the file name to include SSH if this one is adopted. Russ > On Apr 27, 2017, at 5:48 PM, Daniel Migault = wrote: >=20 > Hi,=20 >=20 > This email starts a call for adoption for the following draft.=20 > - draft-lvelvindron-curdle-dh-group-exchange [1] > =20 > Please provide feed backs by May 11.=20 >=20 > Yours,=20 >=20 > Daniel >=20 > [1] = https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-group-exchang= e/ = >=20 > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Apple-Mail=_30E79EE4-2ECB-4642-B25D-E92EFEDB6536 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Please change the Title and the file name to include SSH if = this one is adopted.  I have no objection to adopting it, but = please change the document title and the file name to include SSH if = this one is adopted.

Russ


On Apr 27, 2017, at 5:48 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi,

This email starts a call for adoption for the following = draft.
    - = draft-lvelvindron-curdle-dh-group-exchange [1]
   =
Please provide feed backs by May 11.

Yours,

Daniel

[1] https://datatracker.ietf.org/doc/draft-lvelvindron-curdle-dh-gr= oup-exchange/

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

= --Apple-Mail=_30E79EE4-2ECB-4642-B25D-E92EFEDB6536-- From nobody Fri Apr 28 12:33:33 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 E8392129535; Fri, 28 Apr 2017 12:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m887oVbzLgpC; Fri, 28 Apr 2017 12:33:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCAF912950B; Fri, 28 Apr 2017 12:32:46 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E60DFA3411; Fri, 28 Apr 2017 19:32:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E60DFA3411 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=simo@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E60DFA3411 Received: from rhino.ipa.ssimo.org (ovpn-116-165.phx2.redhat.com [10.3.116.165]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4643E7D544; Fri, 28 Apr 2017 19:32:44 +0000 (UTC) Message-ID: <1493407961.8926.35.camel@redhat.com> From: Simo Sorce To: Daniel Migault , Russ Housley Cc: curdle , curdle-chairs , Benjamin Kaduk Date: Fri, 28 Apr 2017 15:32:41 -0400 In-Reply-To: References: <1492030032.3662.174.camel@redhat.com> <20170413001912.GE30306@kduck.kaduk.org> Content-Type: multipart/alternative; boundary="=-pNZZZEZ/HXuWiv5GNmC9" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 28 Apr 2017 19:32:46 +0000 (UTC) Archived-At: Subject: Re: [Curdle] Call for adoption 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, 28 Apr 2017 19:33:32 -0000 --=-pNZZZEZ/HXuWiv5GNmC9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Thank you Daniel,I renamed and uploaded the draft which includes the fedback already received from Mark and others. Simo. On Thu, 2017-04-27 at 14:02 -0400, Daniel Migault wrote: > Hi,  > > Regarding the feed backs we received the two drafts are accepted as > WG documents. Benjamin and Simo, please upload your documents as WG > documents that is as  draft-ietf-curdle-gss-keyex-sha2-00 draft-ietf- > curdle-des-des-des-die-die-die-00 or equivalent. > > Yours,  > Daniel  > > On Thu, Apr 13, 2017 at 9:49 AM, Russ Housley > wrote: > > Ben: > > > > > > > > Thanks for the explanation.  I withdraw my concerns.  Let’s process > > these promptly. > > > > > > > > Russ > > > > > > > > > > > > > On Apr 12, 2017, at 8:19 PM, Benjamin Kaduk > > wrote: > > > > > > > > > > On the other hand, my draft is squarely focused on Kerberos and > > > > > the GSS-API ... but I am also co-chair of the kitten WG, and my > > > > > co-chair is considering being replaced, so it would be somewhat > > > > > difficult for it to move forward in the kitten WG in a timely > > > > > manner.  It seems much more likely to advance quickly if > > progressing > > > > > through curdle, and it does seem to be in scope, to me. > > > > > > > > > > -Ben > > > > > > > > > > On Wed, Apr 12, 2017 at 04:47:12PM -0400, Simo Sorce wrote: > > > > >> On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote: > > > > >>> Wouldn’t it be more appropriate for these documents to go > > through the > > > > >>> KITTEN WG?  Their charter > > > > >>> (https://datatracker.ietf.org/wg/kitten/about/ > > > > >>> ) covers GSS-API > > and > > > > >>> Kerberos. > > > > >> > > > > >> Mi draft is strictly related to other drafts[*] in this WG that > > are > > > > >> defining transition from SHA-1 to SHA-2 for SSH key exchange. It > > seemed > > > > >> like this WG is most appropriate to review that draft to me. > > > > >> I guess I should have added "SSH" somewhere in the title to make > > it > > > > >> clear. > > > > >> > > > > >> Simo. > > > > >> > > > > >> [*] > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp > > -dh-sha2 > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curv > > es > > > > >> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2 > > > > >> > > > > >>> That said, if the Area Director would rather this work come > > through > > > > >>> the CURDLE WG, I can live with it. > > > > >>> > > > > >>> Russ > > > > >>> > > > > >>> > > > > >>>> On Apr 12, 2017, at 11:40 AM, Daniel Migault > ricsson.com> wrote: > > > > >>>> > > > > >>>> Hi, > > > > >>>> > > > > >>>> This mail starts a call for adoption for the two following > > drafts. If you have any opinion, please raise it by April 26. > > > > >>>> > > > > >>>>    - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.tx > > t > > > > >>>>    - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-de > > s-die-die-die-01 > des-des-des-die-die-die-01> > > > > >>>> > > > > >>>> Yours, > > > > >>>> Daniel > > > > >>> _______________________________________________ > > > > >>> Curdle mailing list > > > > >>> Curdle@ietf.org > > > > >>> https://www.ietf.org/mailman/listinfo/curdle > > > > >> > > > > >> > > > > >> -- > > > > >> Simo Sorce > > > > >> Sr. Principal Software Engineer > > > > >> Red Hat, Inc > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> 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 > > > > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --=-pNZZZEZ/HXuWiv5GNmC9 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit
Thank you Daniel,
I renamed and uploaded the draft which includes the fedback already received from Mark and others.

Simo.

On Thu, 2017-04-27 at 14:02 -0400, Daniel Migault wrote:
Hi,

Regarding the feed backs we received the two drafts are accepted as WG documents. Benjamin and Simo, please upload your documents as WG documents that is as  draft-ietf-curdle-gss-keyex-sha2-00 draft-ietf-curdle-des-des-des-die-die-die-00 or equivalent.

Yours,
Daniel

On Thu, Apr 13, 2017 at 9:49 AM, Russ Housley <housley@vigilsec.com> wrote:
Ben:

Thanks for the explanation.  I withdraw my concerns.  Let’s process these promptly.

Russ


> On Apr 12, 2017, at 8:19 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
>
> On the other hand, my draft is squarely focused on Kerberos and
> the GSS-API ... but I am also co-chair of the kitten WG, and my
> co-chair is considering being replaced, so it would be somewhat
> difficult for it to move forward in the kitten WG in a timely
> manner.  It seems much more likely to advance quickly if progressing
> through curdle, and it does seem to be in scope, to me.
>
> -Ben
>
> On Wed, Apr 12, 2017 at 04:47:12PM -0400, Simo Sorce wrote:
>> On Wed, 2017-04-12 at 11:54 -0400, Russ Housley wrote:
>>> Wouldn’t it be more appropriate for these documents to go through the
>>> KITTEN WG?  Their charter
>>> (https://datatracker.ietf.org/wg/kitten/about/
>>> <https://datatracker.ietf.org/wg/kitten/about/>) covers GSS-API and
>>> Kerberos.
>>
>> Mi draft is strictly related to other drafts[*] in this WG that are
>> defining transition from SHA-1 to SHA-2 for SSH key exchange. It seemed
>> like this WG is most appropriate to review that draft to me.
>> I guess I should have added "SSH" somewhere in the title to make it
>> clear.
>>
>> Simo.
>>
>> [*]
>> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-modp-dh-sha2
>> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-ssh-curves
>> https://datatracker.ietf.org/doc/html/draft-ietf-curdle-rsa-sha2
>>
>>> That said, if the Area Director would rather this work come through
>>> the CURDLE WG, I can live with it.
>>>
>>> Russ
>>>
>>>
>>>> On Apr 12, 2017, at 11:40 AM, Daniel Migault <daniel.migault@ericsson.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> This mail starts a call for adoption for the two following drafts. If you have any opinion, please raise it by April 26.
>>>>
>>>>    - https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt <https://www.ietf.org/id/draft-ssorce-gss-keyex-sha2-00.txt>
>>>>    - https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01 <https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-01>
>>>>
>>>> Yours,
>>>> Daniel
>>> _______________________________________________
>>> Curdle mailing list
>>> Curdle@ietf.org
>>> https://www.ietf.org/mailman/listinfo/curdle
>>
>>
>> --
>> Simo Sorce
>> Sr. Principal Software Engineer
>> Red Hat, Inc
>>
>>
>> _______________________________________________
>> 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


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle
--=-pNZZZEZ/HXuWiv5GNmC9-- From nobody Sat Apr 29 06:28:46 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 A58061294F7; Sat, 29 Apr 2017 06:28:43 -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.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149347252355.2923.13177496291079730679@ietfa.amsl.com> Date: Sat, 29 Apr 2017 06:28:43 -0700 Archived-At: Subject: [Curdle] I-D Action: draft-ietf-curdle-gss-keyex-sha2-00.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: Sat, 29 Apr 2017 13:28:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the CURves, Deprecating and a Little more Encryption of the IETF. Title : GSS-API Key Exchange with SHA2 Authors : Simo Sorce Hubert Kario Filename : draft-ietf-curdle-gss-keyex-sha2-00.txt Pages : 16 Date : 2017-04-28 Abstract: This document specifies additions and amendments to SSH GSS-API Methods [RFC4462]. It defines a new key exchange method that uses SHA-2 for integrity and deprecates weak DH groups. The purpose of this specification is to modernize the cryptographic primitives used by GSS Key Exchanges. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-curdle-gss-keyex-sha2-00 https://datatracker.ietf.org/doc/html/draft-ietf-curdle-gss-keyex-sha2-00 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 Sat Apr 29 18:33: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 8E7F1128B38 for ; Sat, 29 Apr 2017 18:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-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=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDVReczQQi_L for ; Sat, 29 Apr 2017 18:33:32 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 43680129458 for ; Sat, 29 Apr 2017 18:31:20 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id p80so89401454iop.3 for ; Sat, 29 Apr 2017 18:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QZSTUHCrRpnj1H7AueeH/Ni0rGKT5NHJ5+J1hu5RUP0=; b=OcqpngnAE/OYeRE0WajeslO1o7MNZAGDv6hJ2s9U70bUe1w7UQFsm1ZLsOhSQwFKLB PcXF7tBD6AdL3sEQKXluAewGgXLyOqhkptKNJ3gswGeaAjZ1inluPc8l0N4Fngd3hc95 ulqEZEvSl2Zpb9J15KpO958HiocaoAY8RtLItuj67cfa/7nIU9/PBgZUIeZLUnBBIWYP 9svCdOdzSXRgN0JiKWV9JKx0BMfZuVXsCLd/tgOod16VXTOx1iKp/ffUDnA94iY2+LnX 9DnCZalwRQhl3iW/KLX9KFFz7aILOMjP/cErLJCG+DqaWTsg/GfKGzV8QZMhavvWuKG8 CkpA== 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=QZSTUHCrRpnj1H7AueeH/Ni0rGKT5NHJ5+J1hu5RUP0=; b=gcKihqRLTeJpK26tQZmL1001fc1kkQGdObWEiItFULHFpOtMOuRM2eXnlwoci7FKhI 7LP4Tg0mrcT/WCqw7ztk97Tfng0BAKeauZzIwvTCEX+3hHGpiRpK3c+gWN8Y12keeuAM Ns1I68zeqVOFMbbmArRQRRJSF+3vPoKJJlr+WamIHIVYHuRRqO7pj46uUIu+TC2oEoex l1WF0urDMHGwdkqXms9aAhFsDDv5k/EehLsysrvTibThHI4Ig4mz5XKOkuj2xAi6g//r ppVN+pqAAfoVQPiVkB5HgC8Nre+ldKhYL/W5BqxeUGcCdpUAJeLSFlbsfr2FiCeQZEpK 5u7Q== X-Gm-Message-State: AN3rC/7AjvfwxY9sUwI/ZVWz0K+b19jt6HP7vLCoG2NU24vEo/BCZYpW PQSL4p3wFI+IIGxWWEvQowBU6wJqEPfi X-Received: by 10.107.52.202 with SMTP id b193mr17292599ioa.150.1493515879379; Sat, 29 Apr 2017 18:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Sat, 29 Apr 2017 18:31:18 -0700 (PDT) In-Reply-To: <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> From: Brian Smith Date: Sat, 29 Apr 2017 15:31:18 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: multipart/alternative; boundary=001a114415d2754c35054e5843f8 Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 30 Apr 2017 01:33:35 -0000 --001a114415d2754c35054e5843f8 Content-Type: text/plain; charset=UTF-8 Jim Schaad wrote: > Here is the promised updated draft. > > URL: https://www.ietf.org/internet- > drafts/draft-ietf-curdle-pkix-04.txt > > Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > > Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle- > pkix-04 > > Diff: https://www.ietf.org/rfcdiff? > url2=draft-ietf-curdle-pkix-04 I started implementing this this weekend and I noticed that this is the only private key format for which it is impossible to implement a useful pairwise consistency check. In one sense, a consistency check isn't necessary because the public key is computed from the private key, so there's no room for inconsistency. On the other hand, there's no way to detect corruption of the private key like you can with RSA and ecPublicKey keys, when the key is stored in the unencrypted form. I think this is really unfortunate. It is possible to use a v2 PKCS#8 encoding that adds the publicKey component, in which case one can then implement an integrity check. However, unless this is documented in the draft one way or another as a MUST accept or a MUST NOT generate, I think it will be an interop nightmare. In particular, we should avoid the situation where some implementations produce v2 keys so they can add the publicKey field, and where other implementations reject v2 keys because they only parse v1, where the publicKey field isn't allowed. In particular, it is important for the spec to include v2 PKCS#8 examples with the publicKey field, if such encoding is allowed. I also found that, if the publicKey field is included, and one tries to do pairwise validation of the private key and public key, there are a few special cases that should be documented as test vectors. Cheers, Brian --001a114415d2754c35054e5843f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jim = Schaad <ietf@augustcellars.com> wrote:
Here is the promised updated draft.
> URL:=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.t= xt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //tools.ietf.org/html/draft-ietf-curdle-pkix-04
> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-= 04
> Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix= -04

I started implementing this this we= ekend and I noticed that this is the only private key format for which it i= s impossible to implement a useful pairwise consistency check. In one sense= , a consistency check isn't necessary because the public key is compute= d from the private key, so there's no room for inconsistency. On the ot= her hand, there's no way to detect corruption of the private key like y= ou can with RSA and ecPublicKey keys, when the key is stored in the unencry= pted form. I think this is really unfortunate.

It = is possible to use a v2 PKCS#8 encoding that adds the publicKey component, = in which case one can then implement an integrity check.

However, unless this is documented in the draft one way or another a= s a MUST accept or a MUST NOT generate, I think it will be an interop night= mare. In particular, we should avoid the situation where some implementatio= ns produce v2 keys so they can add the publicKey field, and where other imp= lementations reject v2 keys because they only parse v1, where the publicKey= field isn't allowed.

In particular, it is imp= ortant for the spec to include v2 PKCS#8 examples with the publicKey field,= if such encoding is allowed.

I also found that, i= f the publicKey field is included, and one tries to do pairwise validation = of the private key and public key, there are a few special cases that shoul= d be documented as test vectors.

Cheers,
Brian

--001a114415d2754c35054e5843f8-- From nobody Sun Apr 30 02:30:40 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 AF366129413 for ; Sun, 30 Apr 2017 02:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 7bQ2Ymea0mSy for ; Sun, 30 Apr 2017 02:30:37 -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 932E31293F9 for ; Sun, 30 Apr 2017 02:28:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01D2C1A4.D2258FC0" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493544509; h=from:subject:to:date:message-id; bh=OyM0RKs68dV59op891ei5pGcz0mBR2qlchyRIw7W2zk=; b=GrQ5gM7JLL5am2M5hG9wb8JGTZ22sFR3KgtQEqcfw9SqI6El4kDJhcKkADUi8ajg7YqejtfVJF+ x6yV/NVQAO38suV+vTY1WQsDvXhUapn5j9khTl6qG2i+nlhXREu27tXn6ZhXqvpKvtW4or9Y0Ftk4 aDKNGbnCGMryO593dWVRQ7W8/p1wMjBA7AYTpWelL07Meh/PlwM7pbmg3ut2553zulqTblmakYNCd nUJV1SkRjDU1XlazWGxYC4OdKj8LwQWC1q9/3AMvDKhSDroS04xgzpci3extxDw+61c8/cGGLXkkx WCuP/1zRluyF+c65aKB7G5VyQWnRBA3Krzhg== 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; Sun, 30 Apr 2017 02:28:28 -0700 Received: from Hebrews (134.157.25.154) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 30 Apr 2017 02:28:21 -0700 From: Jim Schaad To: 'Brian Smith' CC: 'curdle' References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> In-Reply-To: Date: Sun, 30 Apr 2017 11:27:55 +0200 Message-ID: <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEf37CDGDDCSU9BXbxVbCIypDLQdwJ1Iy/iAhSOZKujHw7JsA== X-Originating-IP: [134.157.25.154] Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 30 Apr 2017 09:30:39 -0000 ------=_NextPart_000_006E_01D2C1A4.D2258FC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Brian Smith [mailto:brian@briansmith.org]=20 Sent: Sunday, April 30, 2017 3:31 AM To: Jim Schaad Cc: curdle Subject: Re: [Curdle] FW: New Version Notification for = draft-ietf-curdle-pkix-04.txt =20 Jim Schaad > = wrote: Here is the promised updated draft. > URL: = https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ > Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-04 =20 I started implementing this this weekend and I noticed that this is the = only private key format for which it is impossible to implement a useful = pairwise consistency check. In one sense, a consistency check isn't = necessary because the public key is computed from the private key, so = there's no room for inconsistency. On the other hand, there's no way to = detect corruption of the private key like you can with RSA and = ecPublicKey keys, when the key is stored in the unencrypted form. I = think this is really unfortunate. =20 [JLS] It is true that RSA has this as a built in feature, however it is = not true for all of the key formats that are in common use today. The = same structure is used here as is used for traditional DH keys. The = ability to do check that the public and private keys match is something = that is possible, but is frequently not done even for RSA keys. = Additionally, there are cases where it is less expensive to re-compute = the public key than to transport it. It is not always possible to = detect corruption when you store in an unencrypted form. It would also = not be possible to know if it was the private key or the public key that = has been corrupted, just that the two values do not match. =20 It is possible to use a v2 PKCS#8 encoding that adds the publicKey = component, in which case one can then implement an integrity check. =20 However, unless this is documented in the draft one way or another as a = MUST accept or a MUST NOT generate, I think it will be an interop = nightmare. In particular, we should avoid the situation where some = implementations produce v2 keys so they can add the publicKey field, and = where other implementations reject v2 keys because they only parse v1, = where the publicKey field isn't allowed. =20 [JLS] I have not heard that this is an issue today with DH keys. This = makes me think that this is not going to be a big issue. I expect that = most implementations would all for parsing v2 keys even if they then = ignore the public key field. =20 In particular, it is important for the spec to include v2 PKCS#8 = examples with the publicKey field, if such encoding is allowed. =20 [JLS] This is a reasonable request. I will look at adding this as part = of the IETF last call comments. =20 I also found that, if the publicKey field is included, and one tries to = do pairwise validation of the private key and public key, there are a = few special cases that should be documented as test vectors. =20 [JLS] Please be more explicit on what you believe are the special cases = that need to be highlighted. The cases that immediately come to mind = for me are the question of correct form for the values, but that is not = an encoding problem but an issue with the library being used. Are there = others that you have in mind? =20 Jim =20 =20 Cheers, Brian =20 ------=_NextPart_000_006E_01D2C1A4.D2258FC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:<= /b> = Brian Smith [mailto:brian@briansmith.org]
Sent: Sunday, April = 30, 2017 3:31 AM
To: Jim Schaad = <ietf@augustcellars.com>
Cc: curdle = <curdle@ietf.org>
Subject: Re: [Curdle] FW: New Version = Notification for draft-ietf-curdle-pkix-04.txt

 

Jim Schaad <ietf@augustcellars.com> = wrote:

Here is = the promised updated draft.
> URL:        =     https://www.ietf.org/internet-drafts/draft-ietf-curdle-= pkix-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix= /
> Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle= -pkix-04
> Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-p= kix-04

 

I = started implementing this this weekend and I noticed that this is the = only private key format for which it is impossible to implement a useful = pairwise consistency check. In one sense, a consistency check isn't = necessary because the public key is computed from the private key, so = there's no room for inconsistency. On the other hand, there's no way to = detect corruption of the private key like you can with RSA and = ecPublicKey keys, when the key is stored in the unencrypted form. I = think this is really unfortunate.

 

[JLS] It is true that RSA has this as a built in feature, however it is = not true for all of the key formats that are in common use today.=C2=A0 = The same structure is used here as is used for traditional DH = keys.=C2=A0 The ability to do check that the public and private keys = match is something that is possible, but is frequently not done even for = RSA keys.=C2=A0 Additionally, there are cases where it is less expensive = to re-compute the public key than to transport it.=C2=A0 It is not = always possible to detect corruption when you store in an unencrypted = form.=C2=A0 It would also not be possible to know if it was the private = key or the public key that has been corrupted, just that the two values = do not match.

 

It is possible to use a v2 PKCS#8 encoding that adds = the publicKey component, in which case one can then implement an = integrity check.

 

However, unless this is documented in the draft one = way or another as a MUST accept or a MUST NOT generate, I think it will = be an interop nightmare. In particular, we should avoid the situation = where some implementations produce v2 keys so they can add the publicKey = field, and where other implementations reject v2 keys because they only = parse v1, where the publicKey field isn't allowed.

 

[JLS]=C2=A0 I have not heard that this is an issue today with DH = keys.=C2=A0 This makes me think that this is not going to be a big = issue.=C2=A0 I expect that most implementations would all for parsing v2 = keys even if they then ignore the public key = field.

 

In particular, it is important for the spec to include = v2 PKCS#8 examples with the publicKey field, if such encoding is = allowed.

 

[JLS] This is a reasonable request.=C2=A0 I will look at adding this as = part of the IETF last call comments.

 

I = also found that, if the publicKey field is included, and one tries to do = pairwise validation of the private key and public key, there are a few = special cases that should be documented as test = vectors.

 

[JLS] Please be more explicit on what you believe are the special cases = that need to be highlighted.=C2=A0 The cases that immediately come to = mind for me are the question of correct form for the values, but that is = not an encoding problem but an issue with the library being used.=C2=A0 = Are there others that you have in mind?

 

Jim

 

 

Cheers,

Brian

 

------=_NextPart_000_006E_01D2C1A4.D2258FC0-- From nobody Sun Apr 30 11:10: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 9AC191294EC for ; Sun, 30 Apr 2017 11:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 OoUXqP1GepL6 for ; Sun, 30 Apr 2017 11:10:32 -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 1BB3E129540 for ; Sun, 30 Apr 2017 11:08:40 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id 88so53635275lfr.0 for ; Sun, 30 Apr 2017 11:08:40 -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=L74H5sNtf1C7FGF0tfespAApeMSAILllRVuy4yryoo4=; b=JE6Doyddmw8di+oQkksMLhaj12ZUtUgc6Hc0ax4yt61Pprc0SMwt1sNTkwFC5a8i83 XY/zA32guUUxb7r1cZ5F30Cd5tV4CZXaUVwvqaN93Evvpt3g07sSOdEgjsHEVIiIPMA1 MSiAnU4xBq13g8mCtiD9nzEtJWlx6pI7CFq6uhV1wy39srHu9ELRoQGhB3KUZPV4ohC1 SZfWeQhQr4uuodr9t/LGrkIbz/I9hydKh4aYlTO/XzEm6+3TZ0EZCDS3pG+QdIRyn48t h+mg575o5rnWU3fMsDq3viZitXDLHvh9qgXKl9Cyvyqn2HcTklCH2PWoZkePOT3ngBaR XocA== 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=L74H5sNtf1C7FGF0tfespAApeMSAILllRVuy4yryoo4=; b=Jr31L44ArKJAjJL+Q13MVSIWAULUfgCe5517+xSqp/UHHurKpgh8rwz/R5lgMBLCYs nwG9kaBi3Ms8LGt9T9K+LFMIgLy9ehTifTE3nCZsSitbbqLmLh77Rr3cs9Sno7i2ua+F y3WDAv4eXKDwyt66uFLsci/1aOM3UchnCaNahAu5hnh3SxYFaE98f6zZ/95wHFBYRY/V Jkj9PaoEfYvt0xQ0vXKMV8lIlxyDEDaEem1rKyfg44WVzIr2RXAr9oO3u0yC3HoGP+lW M85htOC8TN2YFAWAKwwBuN/Ha/URx/7FPKFMcVNBTbHzUa2dZkLFHHpDmRJZfrf98A1q zTTw== X-Gm-Message-State: AN3rC/4OwMXpbau4cd+7qZF/Gk0yxmHQZtpuNqX5kJPP7wfraHR6N/UO tATcGNBwxiyWsGqSxlegDWPlrx0h3w== X-Received: by 10.46.8.26 with SMTP id 26mr7652881lji.128.1493575718402; Sun, 30 Apr 2017 11:08:38 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.69.212 with HTTP; Sun, 30 Apr 2017 11:08:37 -0700 (PDT) In-Reply-To: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Daniel Migault Date: Sun, 30 Apr 2017 14:08:37 -0400 X-Google-Sender-Auth: VKRr0KkpVpymMhMggTGbmAws1Lo Message-ID: To: "Salz, Rich" Cc: denis bider , =?UTF-8?B?0KDRg9C80LXQvSDQn9C10YLRgNC+0LI=?= , curdle Content-Type: multipart/alternative; boundary=f403045ec2da240237054e663271 Archived-At: Subject: Re: [Curdle] WG status 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, 30 Apr 2017 18:10:35 -0000 --f403045ec2da240237054e663271 Content-Type: text/plain; charset=UTF-8 Hi, So far we have not received many inputs and I would like to make sure we understand Romen's concern. My understanding of the concerned raised by Romen is that specifying signature algorithms may complexity the ways Public Key Algorithm registries are designated. However it looks to me one reason is that we are moving from implicit signature scheme to explicit ones. Romen please re-state your issues with the draft, clearly expose the issues as well as the alternate you would fine acceptable. Yours, Daniel On Mon, Apr 24, 2017 at 4:54 PM, Daniel Migault wrote: > Hi everyone, > > We need some feed back to make sure we take the correct decision. Please > continue the discussion. > > Yours, > Daniel > > On Mon, Apr 17, 2017 at 8:45 AM, Salz, Rich wrote: > >> Thanks for your second note. >> >> >> >> Does anyone else agree with Roumen? Please post by within a couple of >> days, otherwise we will consider the issue closed. >> >> >> >> -- >> >> Senior Architect, Akamai Technologies >> >> Member, OpenSSL Dev Team >> >> IM: richsalz@jabber.at Twitter: RichSalz >> >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> > --f403045ec2da240237054e663271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

So far we have not r= eceived many inputs and I would like to make sure we understand Romen's= concern. My understanding of the concerned raised by Romen is that specify= ing signature algorithms may complexity the ways Public Key Algorithm regis= tries are designated.=C2=A0 However it looks to me one reason is that we ar= e moving from implicit signature scheme to explicit ones.

Rom= en please re-state your issues with the draft, clearly expose the issues as= well as the alternate you would fine acceptable.

Yours,
<= /div>Daniel

On Mon, Apr 24, 2017 at 4:54 PM, Daniel Migault <= daniel.mig= ault@ericsson.com> wrote:
<= div dir=3D"ltr">
Hi everyone,

We need some feed= back to make sure we take the correct decision. Please continue the discus= sion.=C2=A0

Yours,
Daniel

On Mon, Ap= r 17, 2017 at 8:45 AM, Salz, Rich <rsalz@akamai.com> wrote:

Thanks for your second note.

=C2=A0

Does anyone else agree with Roumen?=C2=A0 Please po= st by within a couple of days, otherwise we will consider the issue closed.=

=C2=A0

--=C2=A0

Senior Architect, Akamai Technologies=

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

=C2=A0


_____________________________________= __________
Curdle mailing list
Curdle@ietf.org https://www.ietf.org/mailman/listinfo/curdle


--f403045ec2da240237054e663271-- From nobody Sun Apr 30 12:57:57 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 60D88127866 for ; Sun, 30 Apr 2017 12:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 5csKop6hWHpJ for ; Sun, 30 Apr 2017 12:57:52 -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 0FE7C1286CA for ; Sun, 30 Apr 2017 12:55:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01D2C1FC.7560E750" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1493582152; h=from:subject:to:date:message-id; bh=NU5HT5DG5fiMBa8iPds7CfhmF0i8SQQQ88oeC7M52nM=; b=OP/D1IQpzw00nXh9B6msJGjU/gHLyGbbMN6CxvlFrjzkaEz/GdbiIgfGKp7x4iYPU4yV1OhxcF5 In/13s8Iybs4L2IVq62qE+X44bx9m1A0mjomkCY0sQgq4XXeQwgsaSJTRYMxlr/BberxOuLwHpYKc OT6HSaiZjzhKC05of3It28VGa/AW9OuIPdN8cGRDyxmjekSIRUGD0kwvJ9yPaf/x/6S4ZO2i8G+CZ 7vkh/8SC0a0tjrJtOfM4fIkjYtLtPVIDZ7eHV17JWys6yo7VSfrymmSJBlHMgqeY+VpxDumYi9Cnz 0PnY0ZsxrUDLSbdZmmhAiKy2VABZaUpY7Rng== 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; Sun, 30 Apr 2017 12:55:52 -0700 Received: from Hebrews (193.253.56.155) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 30 Apr 2017 12:55:41 -0700 From: Jim Schaad To: 'Daniel Migault' , "'Salz, Rich'" CC: 'curdle' , 'denis bider' , =?utf-8?B?J9Cg0YPQvNC10L0g0J/QtdGC0YDQvtCyJw==?= References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Date: Sun, 30 Apr 2017 21:55:15 +0200 Message-ID: <008601d2c1eb$b1d4e300$157ea900$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGTZ0fUgGkQr1IPWvip/Y8+bed1eQMIyCQpAX2S/R8CnsWL0wKDMDIzApe8sdgCseilSqHleOMw X-Originating-IP: [193.253.56.155] Archived-At: Subject: Re: [Curdle] WG status 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, 30 Apr 2017 19:57:55 -0000 ------=_NextPart_000_0087_01D2C1FC.7560E750 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Given that we are talking about ssh =E2=80=93 I do not have any opinion = at this time. I have never implemented nor really used ssh w/o an = intermediary =20 Jim =20 =20 From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault Sent: Sunday, April 30, 2017 8:09 PM To: Salz, Rich Cc: curdle ; denis bider ; = =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 = Subject: Re: [Curdle] WG status =20 Hi,=20 So far we have not received many inputs and I would like to make sure we = understand Romen's concern. My understanding of the concerned raised by = Romen is that specifying signature algorithms may complexity the ways = Public Key Algorithm registries are designated. However it looks to me = one reason is that we are moving from implicit signature scheme to = explicit ones.=20 Romen please re-state your issues with the draft, clearly expose the = issues as well as the alternate you would fine acceptable. Yours,=20 Daniel=20 =20 On Mon, Apr 24, 2017 at 4:54 PM, Daniel Migault = > = wrote: Hi everyone,=20 We need some feed back to make sure we take the correct decision. Please = continue the discussion. =20 Yours,=20 Daniel =20 On Mon, Apr 17, 2017 at 8:45 AM, Salz, Rich > wrote: Thanks for your second note. =20 Does anyone else agree with Roumen? Please post by within a couple of = days, otherwise we will consider the issue closed. =20 -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz =20 =20 _______________________________________________ Curdle mailing list Curdle@ietf.org =20 https://www.ietf.org/mailman/listinfo/curdle =20 =20 ------=_NextPart_000_0087_01D2C1FC.7560E750 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Given that = we are talking about ssh =E2=80=93 I do not have any opinion at this = time.=C2=A0 I have never implemented nor really used ssh w/o an = intermediary

 

Jim

 

 

From:<= /b> = Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Daniel = Migault
Sent: Sunday, April 30, 2017 8:09 PM
To: = Salz, Rich <rsalz@akamai.com>
Cc: curdle = <curdle@ietf.org>; denis bider <denisbider.ietf@gmail.com>; = =D0=A0=D1=83=D0=BC=D0=B5=D0=BD =D0=9F=D0=B5=D1=82=D1=80=D0=BE=D0=B2 = <pkixssh@roumenpetrov.info>
Subject: Re: [Curdle] WG = status

 

Hi, =

So far we have not received many inputs = and I would like to make sure we understand Romen's concern. My = understanding of the concerned raised by Romen is that specifying = signature algorithms may complexity the ways Public Key Algorithm = registries are designated.  However it looks to me one reason is = that we are moving from implicit signature scheme to explicit ones. =

Romen please re-state your issues with = the draft, clearly expose the issues as well as the alternate you would = fine acceptable.

Yours, =

Daniel =

 

On Mon, = Apr 24, 2017 at 4:54 PM, Daniel Migault <daniel.migault@ericsson.com> = wrote:

Hi everyone, =

We need some feed back to make sure we = take the correct decision. Please continue the discussion.  =

Yours,

Daniel

 

On Mon, Apr 17, 2017 at 8:45 AM, Salz, Rich <rsalz@akamai.com> = wrote:

Thanks for = your second note.

 =

Does anyone = else agree with Roumen?  Please post by within a couple of days, = otherwise we will consider the issue closed.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz

 

 

__________________________________________= _____
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

 

 

------=_NextPart_000_0087_01D2C1FC.7560E750-- From nobody Sun Apr 30 17:17:44 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 537971279EB for ; Sun, 30 Apr 2017 17:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4_aWRNOXDxQ for ; Sun, 30 Apr 2017 17:17:41 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 E33FF129488 for ; Sun, 30 Apr 2017 17:15:57 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id k87so102494780ioi.0 for ; Sun, 30 Apr 2017 17:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=omBajCcS/67teSbtHkKKa/1YAU6n7oGdd/U8sFZBlvQ=; b=myrcUWlRI4zB2RKZnKhhRbiglS6C9q6d4qs7C02g9GLPA0YTZUZ+Z7tkRtsDZbidLo P6/UTVfRF0poihpvGo4P0davWHHwRBAQIThDv5V5FT8j/PpWDMyD3mEEK8gI5Od05QSU jbJrfu71z3ahBg+riqudh2z9ClUs3lI+BFFimR5wlBNNfrBZhCmfEF+XbIcoXTf7zMtV 4bmJVdWJfPlz1uwGrlv5WeRqYwlkOT3I7n2B+j67+DhaM0hL2EjRMHkA4CuKd5NhbbfX SDtLd+Isvwzc/cwvcSV4/4TV2jqKfwpZzS5IzPgav8zp3e57CoEqUiAtRB3Pqrp7khED CpiA== 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=omBajCcS/67teSbtHkKKa/1YAU6n7oGdd/U8sFZBlvQ=; b=T58PburRcgAtAphpZ1EgnljA/hX6TOHuxUXJxzbOXpEA1rae9fQFRcTm6bGAbVNLB/ v9JSA7KKdUGh5DjwBgkJSjt5r1bOhFWR76PVzJ4niMf6UUwW6vO2JvYO0JgqA7mXtDDW unr3TTo0rwtEkMFo9XBOV/RF55dnO1Kkcq8vSh4hjCreb2KNaGFL5y+44F/CBRPL/ZST WTMzvBAL3torRfWBL4Q4azaPGu1d82d76pI4cJ8lFLwo4e07CGBA6EINgJCWx8YdAtgl Bj++1/1SaAjLUO5g5TuXOlzl25P+ibm2VYy+bVIeYS8gSB6gVXRlyiF5Dyd1uHnP32gp n+Ww== X-Gm-Message-State: AN3rC/51ti3NHdZuDJ4L+T6ucNByRj89HwtzaTvFBen1hfw1fIrhAiaD R11nzL3ESrttugs7G1QZM8ISdgd26Tx9oho= X-Received: by 10.107.50.136 with SMTP id y130mr24520929ioy.152.1493597757131; Sun, 30 Apr 2017 17:15:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.77.84 with HTTP; Sun, 30 Apr 2017 17:15:56 -0700 (PDT) In-Reply-To: <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <006d01d2c194$0e99b280$2bcd1780$@augustcellars.com> From: Brian Smith Date: Sun, 30 Apr 2017 14:15:56 -1000 Message-ID: To: Jim Schaad Cc: curdle Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.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, 01 May 2017 00:17:43 -0000 Jim Schaad wrote: > Brian Smith wrote: > > I started implementing this this weekend and I noticed that this is > > the only private key format for which it is impossible to implement > > a useful pairwise consistency check. In one sense, a consistency > > check isn't necessary because the public key is computed from > > the private key, so there's no room for inconsistency. On the > > other hand, there's no way to detect corruption of the private key > > like you can with RSA and ecPublicKey keys, when the key is > > stored in the unencrypted form. I think this is really unfortunate. > > [JLS] It is true that RSA has this as a built in feature, however it > is not true for all of the key formats that are in common use today. > The same structure is used here as is used for traditional DH keys. It seems to me that traditional DH keys are exceptional in this respect. ECPrivateKey (for ECDSA and ECDH) is required to contain the public key. RSAPrivateKey contains everything needed to validate it. > The ability to do check that the public and private keys match is something that is possible, but is frequently not done even for RSA keys. Additionally, there are cases where it is less expensive to re-compute the public key than to transport it. Doing the consistency check vs. saving space is a safety trade-off. > It is not always possible to detect corruption when you store in an unencrypted form. What kind of corruption would we not be able to detect? It is possible that somehow the private key could get corrupted and that there could be a corresponding corruption to the public key such that they match again, but this seems extremely unlikely unless somebody simply replaced the key pair with another key pair. > It would also not be possible to know if it was the private key or the public key that has been corrupted, just that the two values do not match. This is the case with any kind of cryptographic check, including HMAC or whatnot. > > However, unless this is documented in the draft one way or > another as a MUST accept or a MUST NOT generate, I think > it will be an interop nightmare. In particular, we should avoid > the situation where some implementations produce v2 keys > so they can add the publicKey field, and where other > implementations reject v2 keys because they only parse v1, > where the publicKey field isn't allowed. > > I have not heard that this is an issue today with DH keys. This > makes me think that this is not going to be a big issue. I expect > that most implementations would all for parsing v2 keys even if > they then ignore the public key field. If that's the expectation then let's enshrine that in the spec by saying that implementations MUST accept v2 keys for these types of keys. In particular, I have seen PKCS#8 implementations that reject any v2 PKCS#8 file instead of ignoring the extra fields. > > In particular, it is important for the spec to include v2 PKCS#8 > > examples with the publicKey field, if such encoding is allowed. > > This is a reasonable request. I will look at adding this as part of the IETF last call comments. Thanks. > I also found that, if the publicKey field is included, and one tries to > do pairwise validation of the private key and public key, there are > a few special cases that should be documented as test vectors. > [JLS] Please be more explicit on what you believe are the special > cases that need to be highlighted. The cases that immediately > come to mind for me are the question of correct form for the values, > but that is not an encoding problem but an issue with the library > being used. Are there others that you have in mind? I'll use X25519 as an example. RFC 7748 says: > When receiving such an array, implementations of X25519 (but > not X448) MUST mask the most significant bit in the final byte." Thus for every X25519 key, there will be at least two possible encodings of the public key. We should have test vectors such that both encodings of the same public key (for the same private key) are included as separate vectors, to ensure that any implementation that does do a pairwise consistency check includes the masking step in the comparison. Similarly, for ~19 X25519 keys, there are twice as many (4) possible encodings of the public key: 1. High bit is 0, fully reduced. 2. High bit is 1, not fully reduced. 3. High bit is 0, fully reduced. 4. High bit is 0, not fully reduced. We should have test vectors for all four cases, to ensure that any implementation that does the pairwise consistency check does the comparison on the fully-reduced value of the given and calculated public key, instead of just doing a bytewise comparison. (Though, do we know any of the these 19 private keys that could use to produce a test vector?) Cheers, Brian -- https://briansmith.org/ From nobody Sun Apr 30 21:02:32 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 D1562127275 for ; Sun, 30 Apr 2017 21:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRIan8ja2gNF for ; Sun, 30 Apr 2017 21:02:28 -0700 (PDT) Received: from newmailhub.uq.edu.au (mailhub2.soe.uq.edu.au [130.102.132.209]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB88129473 for ; Sun, 30 Apr 2017 20:59:56 -0700 (PDT) Received: from smtp1.soe.uq.edu.au (smtp1.soe.uq.edu.au [10.138.113.40]) by newmailhub.uq.edu.au (8.14.5/8.14.5) with ESMTP id v413xkFY014651; Mon, 1 May 2017 13:59:46 +1000 Received: from mailhub.eait.uq.edu.au (hazel.eait.uq.edu.au [130.102.60.17]) by smtp1.soe.uq.edu.au (8.14.5/8.14.5) with ESMTP id v413xjtC010943 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 1 May 2017 13:59:45 +1000 Received: from natsu.mindrot.org (natsu.mindrot.org [130.102.96.2]) by mailhub.eait.uq.edu.au (8.15.1/8.15.1) with ESMTPS id v413xib7017949 (version=TLSv1.2 cipher=DHE-RSA-CHACHA20-POLY1305 bits=256 verify=NO); Mon, 1 May 2017 13:59:44 +1000 (AEST) Received: by natsu.mindrot.org (Postfix, from userid 1000) id 6A65FA4F39; Mon, 1 May 2017 13:59:44 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 69A51A4F38; Mon, 1 May 2017 13:59:44 +1000 (AEST) Date: Mon, 1 May 2017 13:59:44 +1000 (AEST) From: Damien Miller To: Daniel Migault cc: "Salz, Rich" , curdle , denis bider , =?KOI8-R?B?8tXNxc4g8MXU0s/X?= In-Reply-To: Message-ID: References: <58F475B5.4090504@roumenpetrov.info> <1778170c976e43569d34f051bba51f4c@ustx2ex-dag1mb1.msg.corp.akamai.com> User-Agent: Alpine 2.20 (BSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-857715075-1493611184=:2134" X-Scanned-By: MIMEDefang 2.73 on UQ Mailhub X-Scanned-By: MIMEDefang 2.75 on 130.102.60.17 X-UQ-FilterTime: 1493611187 Archived-At: Subject: Re: [Curdle] WG status 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, 01 May 2017 04:02:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-857715075-1493611184=:2134 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Sun, 30 Apr 2017, Daniel Migault wrote: > Hi, > > So far we have not received many inputs and I would like to make sure we > understand Romen's concern. My understanding of the concerned raised by > Romen is that specifying signature algorithms may complexity the ways Public > Key Algorithm registries are designated.  However it looks to me one reason > is that we are moving from implicit signature scheme to explicit ones. > > Romen please re-state your issues with the draft, clearly expose the issues > as well as the alternate you would fine acceptable. Speaking as a maintainer of one of the implementations (OpenSSH) that has support for the draft, I don't think the draft needs changing. In particular, altering the "server-sig-algs" message on the wire has zero implications for registries and will only break working implementations. -d --0-857715075-1493611184=:2134--