From nobody Wed Dec 9 10:00:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ADD1A0033 for ; Wed, 9 Dec 2015 10:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qej4t9e2LJpD for ; Wed, 9 Dec 2015 10:00:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7BE1A0020 for ; Wed, 9 Dec 2015 10:00:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BACE9BE5B for ; Wed, 9 Dec 2015 18:00:21 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chZB3Uz-eWBM for ; Wed, 9 Dec 2015 18:00:19 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D0418BDCC for ; Wed, 9 Dec 2015 18:00:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449684019; bh=z8Vkx1hmQNiyPvTqqpoeHQshE2+axHeVeKEDtV+I3l8=; h=To:From:Subject:Date:From; b=fmTYGhmRv+F/xzqCulHOlxA4tmcbJj245il4UdXUeunCLN016y+vlOsGiAtAWzR5s KhjekOWhJzhHnR3je2e3La0IRumAxe0g5TnHr55W50fJWXQXbgazN2tFcSlK6NdM68 Cj8O4aj7QuU9QvIccDYEMK6RxueFoWz3OKpsuBK4= To: saag@ietf.org From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56686C32.6090400@cs.tcd.ie> Date: Wed, 9 Dec 2015 18:00:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 18:00:26 -0000 Hiya, The brainpool folks have written an I-D [1] that they are pushing through the rfc editor's independent stream. [2] That I-D wants to register code points for using their curves for DNSSEC. For documents that come through the independent stream, the IESG does an RFC 5742 [3] conflict review. The purpose of that review is to check that the RFC doesn't conflict with ongoing work in the IETF. If you have thoughts on this, please let me know before Dec 17th. I'll forward this to the dnsop, cfrg and curdle mailing lists to check there too. Apologies if you get >1 copy of this. Please try follow up on the saag list if you can. Thanks, Stephen. [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec [2] https://www.rfc-editor.org/pubprocess/ [3] https://tools.ietf.org/html/rfc5742 From nobody Wed Dec 9 10:10:24 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B411A0204 for ; Wed, 9 Dec 2015 10:10:23 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_u_cinEa9K9 for ; Wed, 9 Dec 2015 10:10:21 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50001B2B9F for ; Wed, 9 Dec 2015 10:10:05 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CFDDA284E35; Wed, 9 Dec 2015 18:10:04 +0000 (UTC) Date: Wed, 9 Dec 2015 18:10:04 +0000 From: Viktor Dukhovni To: Stephen Farrell Message-ID: <20151209181004.GC11836@mournblade.imrryr.org> References: <56686C32.6090400@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56686C32.6090400@cs.tcd.ie> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: saag@ietf.org Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 18:10:23 -0000 On Wed, Dec 09, 2015 at 06:00:18PM +0000, Stephen Farrell wrote: > The brainpool folks have written an I-D [1] that they are pushing > through the rfc editor's independent stream. [2] > > That I-D wants to register code points for using their curves for > DNSSEC. I am strongly opposed. DNSSEC has no opportunity to "negotiate" algorithms. For DNSSEC, we do need strong algorithms, but the *fewer* the better. Fragmenting the DNS by algorithm would be a very poor outcome, as would forcing every domain to publish "kitchen-sink" DNSKEY RRsets. IMHO we already have too many DNSSEC algorithm ids (some of which are not that strong and should be deprecated), however once the CFRG curves are standardized, these IMHO should be the *only* ones to get new DNSSEC algorithm ids, and some of the older ones need to start being phased out. https://www.ietf.org/mail-archive/web/saag/current/msg06808.html -- Viktor. From nobody Wed Dec 9 12:23:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7CA1A1B30 for ; Wed, 9 Dec 2015 12:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 ybxQw3KrmmCL for ; Wed, 9 Dec 2015 12:23:21 -0800 (PST) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 76D201A1B2B for ; Wed, 9 Dec 2015 12:23:21 -0800 (PST) Received: from latte.josefsson.org ([155.4.17.2]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id tB9KN0Zq020431 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 9 Dec 2015 21:23:01 +0100 From: Simon Josefsson To: Stephen Farrell References: <56686C32.6090400@cs.tcd.ie> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:151209:stephen.farrell@cs.tcd.ie::H4YT8qqKNBRftqRZ:7N7/ X-Hashcash: 1:22:151209:saag@ietf.org::8mFygnSKa5aAcB91:zUGF Date: Wed, 09 Dec 2015 21:22:59 +0100 In-Reply-To: <56686C32.6090400@cs.tcd.ie> (Stephen Farrell's message of "Wed, 9 Dec 2015 18:00:18 +0000") Message-ID: <87poyfmkws.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: saag@ietf.org Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 20:23:24 -0000 --=-=-= Content-Type: text/plain Stephen Farrell writes: > Hiya, > > The brainpool folks have written an I-D [1] that they are pushing > through the rfc editor's independent stream. [2] > > That I-D wants to register code points for using their curves for > DNSSEC. Interesting that unimplemented state-sponsored crypto is pushed through while widely deployed academic crypto is delayed year after year. Allow me to suggest that draft-schmidt-brainpool-dnssec is at least not published before the EdDSA-based DNSSEC documents are published, as doing so would conflict with the ongoing IETF-process around setting up the Curdle WG and getting the DNSSEC EdDSA documents published. /Simon > For documents that come through the independent stream, the IESG > does an RFC 5742 [3] conflict review. The purpose of that review > is to check that the RFC doesn't conflict with ongoing work in > the IETF. > > If you have thoughts on this, please let me know before Dec 17th. > I'll forward this to the dnsop, cfrg and curdle mailing lists > to check there too. Apologies if you get >1 copy of this. Please > try follow up on the saag list if you can. > > Thanks, > Stephen. > > > [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec > [2] https://www.rfc-editor.org/pubprocess/ > [3] https://tools.ietf.org/html/rfc5742 > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWaI2jAAoJEIYLf7sy+BGdRpEH/35DPNuJD4gw3N1ZpW73yYhz yDJyAq3FplsHXpJkk74PJ2BrPAYeLVOdzmBKzwoAbfS6xLIB4kDD+3IbcNkEAK6b gEtzxCGgqPJaUzqVm1Xrd21pvOtAbJs3Q/Z9e+rizpHnCOR1QHpO+q1kG/6/fHzq V5VP6DlGNZUNlsLHLVmXUTErH6wcPsgOG00ae/YnD1GbphiXrgQgaPIM1ymx3F69 QjJm94JNlhhvPle+/TKXsu2uEh6knVynk/z9/yeFQ8XCjf/u8yAuO4iNzftj/Xsa m8C2fZHoOG7GMVH8vmVFOr9t+jju911dXk3qvNcA6XmF01T1ZulSOJGOvVPVwpA= =mlQz -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Dec 9 12:31:27 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D241A2119 for ; Wed, 9 Dec 2015 12:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 biDhIvexWMPU for ; Wed, 9 Dec 2015 12:31:17 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 89E2D1A1B85 for ; Wed, 9 Dec 2015 12:31:16 -0800 (PST) Received: by obbww6 with SMTP id ww6so44567337obb.0 for ; Wed, 09 Dec 2015 12:31:16 -0800 (PST) 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:date:message-id:subject:from:to :cc:content-type; bh=HzWxoWDxpJSunrDd6zlL+igOoJWwSf7jBXx91OENvqM=; b=Nf9E01fwFgMRChB4/0fD8Web7G3mIAEha9X8CI3TwKy8zXJ7NbHiKBDBxQshOic02u 26Gdc+mFR4G8RObQoa7hRsG011HcwmJo+/qA2czt0rQYGWY+F76ZytN3UbYueoofEitA aj9HhMW4J3OUotXc6+6m5f7VtxMFzuC39n6xCR+ROXlGnOonOO2JDXTcS6UI1pEOs5gZ k6NRJYQT1bZEXUBtho84wx8A0B6q3KvXkzOOpqVcH5BFTrn+nNzUglA7YIUjXTagHk26 gq+Gn8rRRaPMawsU4eiICzLAXkXTjOBsA8RH4JOvCdCmO7WgIMSZEVbGt+sDBtRSQmLP vGfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HzWxoWDxpJSunrDd6zlL+igOoJWwSf7jBXx91OENvqM=; b=USNKwWJ9PI3yH0QKMfpunwQGNlq3ALc/fuHYDsHz+5JDu+6TFYCLwi4LOhDrVuFyBq E3EYoutiQ5Ic68/dAMqV1y/A/TuzglAOrLSDRRKVtD1DI09iz8ljCu4hehIEhfwkbr9H 68P9H4JmEyUKin7WeTR2XvRKqUiyzRgvyeA1Q206My3xtf/8y/djtuvjrxdsBogOOMZt aZ0ObonvbMpj6qf77ySF6RIDP+3217ZuTfvXjER06fuHEvAyvUk+hb2Wfv8eePK9mqWt iIpDO4JaDmNrSZjgtD0Dy8whjsGI+PhJ2Eb669zGo6268NTbFWvYIJPB2nIdp7ZVQHsZ I3eQ== X-Gm-Message-State: ALoCoQlapj/qYI7EETXnI0kGMumqR3TSxvqKIsL2UhqQmtbNsKWieXOJBrPXv7HcFHfwl7HRjBbOsAn+8Cy2yhz5A9CY3/h+UQ== MIME-Version: 1.0 X-Received: by 10.182.214.40 with SMTP id nx8mr6376608obc.20.1449693075955; Wed, 09 Dec 2015 12:31:15 -0800 (PST) Received: by 10.76.109.78 with HTTP; Wed, 9 Dec 2015 12:31:15 -0800 (PST) In-Reply-To: <56686C32.6090400@cs.tcd.ie> References: <56686C32.6090400@cs.tcd.ie> Date: Wed, 9 Dec 2015 10:31:15 -1000 Message-ID: From: Brian Smith To: Stephen Farrell Content-Type: multipart/alternative; boundary=e89a8ff1c01ed3861305267cf8c5 Archived-At: Cc: saag@ietf.org Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 20:31:19 -0000 --e89a8ff1c01ed3861305267cf8c5 Content-Type: text/plain; charset=UTF-8 Stephen Farrell wrote: > > Hiya, > > The brainpool folks have written an I-D [1] that they are pushing > through the rfc editor's independent stream. [2] > > That I-D wants to register code points for using their curves for > DNSSEC. Perhaps first we should establish some consensus regarding the concerns raised in http://bada55.cr.yp.to/brainpool.html. In particular, the authors of that web page have convinced me the whole principle behind Brainpool-using randomness to remove doubt on the trustworthiness of the curve parameters--is at odds with the actual results. Cheers, Brian -- https://briansmith.org/ --e89a8ff1c01ed3861305267cf8c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Step= hen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

The brainpool folks have written an I-D [1] that they are pushing
through the rfc editor's independent stream. [2]

That I-D wants to register code points for using their curves for
DNSSEC.

Perhaps first we should establish s= ome consensus regarding the concerns raised in=C2=A0http://bada55.cr.yp.to/brainpool.html. In pa= rticular, the authors of that web page have convinced me the whole principl= e behind Brainpool-using randomness to remove doubt on the trustworthiness = of the curve parameters--is at odds with the actual results.
Cheers,
Brian
--
--e89a8ff1c01ed3861305267cf8c5-- From nobody Wed Dec 9 13:06:14 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877741B2D22 for ; Wed, 9 Dec 2015 13:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlg1RxSZRsYD for ; Wed, 9 Dec 2015 13:06:12 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c: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 A40311A1B12 for ; Wed, 9 Dec 2015 13:06:11 -0800 (PST) Received: by wmww144 with SMTP id w144so239767688wmw.1 for ; Wed, 09 Dec 2015 13:06:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aArJSyU63r935U/ENyJpPGzsV2Dw2ibU3/Lwies5Eh0=; b=sjAbllxLfHxOYA7fB0yqKgC0LDTC8hWZgv0mWIVRu2s0vHRC+vNIpNTpVIGqERhzL6 nzudebt7dZhWcYjaGIlaRl439oAduBAN1KdN5jbfHCL9mBOxH44tDNLLLBR1RjJ2lH6f Eo4sGf/A34+gJDh1BHV4+hd30KryYOOCPf6AQQlDupeeoGwh0TvgwzvhZBiisyK/rZGf FWMQYnlOU3WFp5BR1DriMptwzPV71nXzS1mKHnVk16vUPvHXs2FMrcyivvHWiBo87DW7 BzfWwUv/lYKx1q1xtaeT92NXlB3bGWRb/OOllioN/cfUqKqgWIfTjyRQCXpvSw+Ldtvb hXLA== X-Received: by 10.194.117.163 with SMTP id kf3mr8332751wjb.139.1449695170282; Wed, 09 Dec 2015 13:06:10 -0800 (PST) Received: from [192.168.1.14] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id t3sm8979081wjz.11.2015.12.09.13.06.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Dec 2015 13:06:08 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <87poyfmkws.fsf@latte.josefsson.org> Date: Wed, 9 Dec 2015 23:06:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4CE2A655-89EA-4CD8-BF80-ED8951B5E3D4@gmail.com> References: <56686C32.6090400@cs.tcd.ie> <87poyfmkws.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Security Area Advisory Group Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 21:06:13 -0000 Hi, Simon > On 9 Dec 2015, at 10:22 PM, Simon Josefsson = wrote: >=20 > Stephen Farrell writes: >=20 >> Hiya, >>=20 >> The brainpool folks have written an I-D [1] that they are pushing >> through the rfc editor's independent stream. [2] >>=20 >> That I-D wants to register code points for using their curves for >> DNSSEC. >=20 > Interesting that unimplemented state-sponsored crypto is pushed = through > while widely deployed academic crypto is delayed year after year. Nothing is getting pushed through here, unlike the GOST case. You, me = and anyone can write a draft for DNSSEC signatures by XOR-ing the RR = with the string =E2=80=9CROT-13=E2=80=9D repeated as many times as = necessary and submit it to the RFC editor just as the Brainpool people = did. We would get the same result: the document would be sent to the = IESG for conflict review. Publishing this draft does not hinder us from publishing an EdDSA draft. = There are, however, several good arguments against this: 1. Victor=E2=80=99s argument: having too many algorithms means that = either your resolver supports all of them, or there are some domains = that you can=E2=80=99t verify. We don=E2=80=99t want to fragment the = secure DNS as that would diminish its value and hurt interoperability, = forcing resolvers to revert to the insecure DNS. This hurts the mission = of the IETF to make the Internet better. 2. The IANA registry is 8-bit, making this a scarce resource. It should = not be wasted on algorithms that are not likely to see a lot of use. 3. The Brainpool curves do not offer any advantages over existing = signature schemes unless you believe that the NIST curves are = back-doored. I haven=E2=80=99t heard any reasonable claim that this is = so. EdDSA will provide a performance advantage Brainpool? Not so much. While I believe, like you and Victor that having DNSSEC signatures using = Brainpool is a bad idea, I am not sure if blocking this RFC is the right = way for the IETF to discourage this. The goal, though, is laudable. Yoav From nobody Wed Dec 9 13:34:40 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E45D51B2DAA for ; Wed, 9 Dec 2015 13:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9q7a1HTnjtW for ; Wed, 9 Dec 2015 13:34:38 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8101A8706 for ; Wed, 9 Dec 2015 13:34:38 -0800 (PST) Received: by lbbcs9 with SMTP id cs9so38300881lbb.1 for ; Wed, 09 Dec 2015 13:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Y94MQNY+wejEMQvYD0CCQj+rfEcF/I9Hpb2ao9+Dyqo=; b=KAWckb0tx6fqBWOgMLOcuNAz2uiS0pol49AyIDNc1ACx4aKf9MPAY2pH6349Hde/WK KyznJtbNwQtKvFwgzoNb85onI4AyX8RKH6L3oPNihGaFkGl4YgBOvbXeWh6u4D0TbTWo oeFpLQZ5mgOWhtj4oNzWnAS7mWlM0b/oOyv3s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Y94MQNY+wejEMQvYD0CCQj+rfEcF/I9Hpb2ao9+Dyqo=; b=e9XhNjYNxtc++SPQMhf3ew46z0Orm04Xu9rr0Xi0y+9uyl0xEI2Hzd/MUjYOoE2gFz 8WmmqYZobqVAebJroGs5gRLJTbHtzvBHqMH+BYVKnLjf3MwGpVLy1EyUqYRoZRp7u2Hb FLo8uV1LQ4jJaRao/bBeCNpiGcVe8OMKD/pMaIyNX9vRxyTpcWAnEYM6SBeJOB1feAVx PX7CvjKgGtd1lCW561s2G0t4wTmAG4NXh8t/OTxCT2n8oI1EAG4fNiCT1RN0wjx4ietE c7H1IzXbNRM1Bzm0ihblL4vynFv1XX3UZ8UbGh6RcJnXYYSL2IiNyTWcD9AkXBNl03vL f9hg== X-Gm-Message-State: ALoCoQmx3Wd5uJS/kVxdDf4tqOAfONDj8keXQsrQSYDZ42RwcNbBrVT4TYqICRHio+MZkK5RsZEbPjExoc6ZS1k7gp2L0QDMsQ== X-Received: by 10.112.54.193 with SMTP id l1mr3543919lbp.58.1449696876207; Wed, 09 Dec 2015 13:34:36 -0800 (PST) Received: from [192.168.1.100] ([41.232.114.92]) by smtp.gmail.com with ESMTPSA id a18sm1770381lfb.37.2015.12.09.13.34.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Dec 2015 13:34:34 -0800 (PST) Message-ID: <56689E64.7010808@azet.org> Date: Wed, 09 Dec 2015 22:34:28 +0100 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Stephen Farrell , saag@ietf.org References: <56686C32.6090400@cs.tcd.ie> <20151209181004.GC11836@mournblade.imrryr.org> In-Reply-To: <20151209181004.GC11836@mournblade.imrryr.org> X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCF1B39086256C4AB134B47F9" Archived-At: Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 21:34:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCF1B39086256C4AB134B47F9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Viktor Dukhovni wrote: > I am strongly opposed. DNSSEC has no opportunity to "negotiate" > algorithms. For DNSSEC, we do need strong algorithms, but the > *fewer* the better. Fragmenting the DNS by algorithm would be a > very poor outcome, as would forcing every domain to publish > "kitchen-sink" DNSKEY RRsets. >=20 > IMHO we already have too many DNSSEC algorithm ids (some of which > are not that strong and should be deprecated), however once the > CFRG curves are standardized, these IMHO should be the *only* ones > to get new DNSSEC algorithm ids, and some of the older ones need > to start being phased out. >=20 > https://www.ietf.org/mail-archive/web/saag/current/msg06808.html >=20 I unequivocally agree. See also concerns raised by Simon Josefsson. Aaron --------------enigCF1B39086256C4AB134B47F9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWaJ5lAAoJEOTbZJL9ubXVT48P/2F3LSRpuGzWq2njH+V8rS4M 9VALZr6G69BxlS7Y7yqpVXrVbuV10rJ8O1c4R8ZqubUQdh8gPhIJFwlGhbp1D7z0 YvWSzBr8YKP/AaNxVg1MKg1NoMQJhCAxjLJLPBnLSOc8OAJ8kOSOzKx1lcwY64Gv M/aQv4WNwMv40H5cinDwlfIk1b600vswbu8i7z/JEE849GYZcqtJaCH4KuMrY13X PEOOBpPwMtwxPObQC7OJBpLYHgWG0aR8n6/H7O1RnvCbKrj3t5vqAVWCi+P46pBL u17yCEPPsa0e5WqCjj+agF+zjdTLWafBeoe20naOipGZkr+QTffjmV7QPYuMg6vO YtuJrculTVqGqOeEXM5ydqmCHAimwl66PEhQ0U1k1+0DG10MnZsebDFJOZMHsUcV km+LoLfgiaC55woXFB0/E/fE5Q96K98w2gzIFYlVWgbc3AuXND2exgF3/887ZBLd XywkuBVHbuAlUHXFLr27YhYnb7RD4RkOWOEel7lBubv1Ed+6xaI1u2h5vA7txZfk WVLefRFIaly88NzVCyaf9MIm3u7xgArlZoJfEisE6C79+Q1D66LHCujqVIE+qiLq wX+ijqw6nnReSjxcuEGb5GmsZVgeLKddDsX1176uolIS+MK7cmw4RPTlNX26Tse3 MZ/zd9+g8fzFbAxmqhjv =oL+7 -----END PGP SIGNATURE----- --------------enigCF1B39086256C4AB134B47F9-- From nobody Wed Dec 9 13:42:06 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD8F1B2E18; Wed, 9 Dec 2015 13:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 YYx9eLQgr5iF; Wed, 9 Dec 2015 13:42:02 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 9FE2E1B2E1B; Wed, 9 Dec 2015 13:42:01 -0800 (PST) Received: by lbpu9 with SMTP id u9so38288690lbp.2; Wed, 09 Dec 2015 13:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=1XKaVUIvW0jvU0X8xFgIC4Fk9AKBggDj8DHgCtUNHww=; b=ayXMOzp+FuSNEw8402UmbtBSCaVq6qNxI2Uqdu4LRYsuJ/055s0EY/CJwoL6qHJGcy ZtPCLcHzsnM+xz0pSh8NW2f3af2UbNgiYU9Y8eB9QneMeYk2Bg0nr6FtCKNS3/zQnnTK kIvInLTMyiYdpQdHexmbEblCKgrWMeM8wfiiG4jmj6zxSqrEB3cCGttqDu8squazcBwc ohUUrLZ6byuoPjSaQJFX33oOd5NAvF6XOnRTCLu6ovyEVr7quEEhir0Y4Bxwp20ouS7T GVL9yFoy2dgNeVx05BPzT5gp1wWfFCu3RvY1kkq8dnP1oe7MPtPi/KioDkwdmJVVvGvq vviQ== MIME-Version: 1.0 X-Received: by 10.112.182.8 with SMTP id ea8mr3551829lbc.114.1449697319726; Wed, 09 Dec 2015 13:41:59 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.227 with HTTP; Wed, 9 Dec 2015 13:41:59 -0800 (PST) In-Reply-To: <56686C32.6090400@cs.tcd.ie> References: <56686C32.6090400@cs.tcd.ie> Date: Wed, 9 Dec 2015 16:41:59 -0500 X-Google-Sender-Auth: IzXVcHPLh7qbKiA86bqRa-2g8y4 Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell , "dnsop@ietf.org" , curdle@ietf.org Content-Type: multipart/alternative; boundary=001a11c37320c6392d05267df5ea Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 21:42:04 -0000 --001a11c37320c6392d05267df5ea Content-Type: text/plain; charset=UTF-8 Objections so far * The approach is dated (not fast prime rigid) and the randomness isn't established to be rigid. * DNSSEC requires a single algorithm for interop * The code points are 8 bit and thus scarce * We should do Curdle first. I am opposed to Brainpool for all the above and in addition, I am opposed because the biggest problem with ECC has been too many choices. If people are given one choice, they will do it. If they have two then they will probably do both. With ECC we were given 16 choices by NIST and then the same again from Brainpool and a few other folks. So what a lot of people did was to conclude ECC wasn't mature enough to implement right now and adopted a wait-and-see approach. Brainpool was a good idea at the time it was proposed but the world moved on and the effort is counterproductive now. Since ACME and Lets Encrypt have been proposed, we can hopefully get away from the bogus idea that the mission of DNSSEC was 'free' certs. The utility of DNSSEC lies in being able to sign and distribute security policy information so that applications can achieve 'secure on first contact' security rather than 'secure after first contact'. For that to work, DNSSEC has to be using the same set of algorithms that the applications are using. The other area we might potentially leverage DNSSEC is to allow encryption of the initial exchange in a TLS/2 by putting a 'host key' in the DNS. This would allow the SNI and certificate exchanges to be encrypted. For this to be practical, DNSSEC and TLS have to converge on the same algorithm and curve. --001a11c37320c6392d05267df5ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Objections so far

* The approach is d= ated (not fast prime rigid) and the randomness isn't established to be = rigid.
* DNSSEC requires a single algorithm= for interop
* The code points are 8 bit an= d thus scarce
* We should do Curdle first.<= /div>

I am o= pposed to Brainpool for all the above and in addition, I am opposed because= the biggest problem with ECC has been too many choices. If people are give= n one choice, they will do it. If they have two then they will probably do = both.=C2=A0

With ECC we were given 16 choices by NIST and then the same again fro= m Brainpool and a few other folks. So what a lot of people did was to concl= ude ECC wasn't mature enough to implement right now and adopted a wait-= and-see approach.

Brainpool was a good idea at the time it was proposed but the w= orld moved on and the effort is counterproductive now.


Since ACME and Lets Encrypt have been proposed, we can hopefully= get away from the bogus idea that the mission of DNSSEC was 'free'= certs. The utility of DNSSEC lies in being able to sign and distribute sec= urity policy information so that applications can achieve 'secure on fi= rst contact' security rather than 'secure after first contact'.= For that to work, DNSSEC has to be using the same set of algorithms that t= he applications are using.

The other area we might potentially leverage DNSSEC is= to allow encryption of the initial exchange in a TLS/2 by putting a 'h= ost key' in the DNS. This would allow the SNI and certificate exchanges= to be encrypted. For this to be practical, DNSSEC and TLS have to converge= on the same algorithm and curve.

--001a11c37320c6392d05267df5ea-- From nobody Wed Dec 9 17:16:39 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1621A802D for ; Wed, 9 Dec 2015 17:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh6zPcLJkm0n for ; Wed, 9 Dec 2015 17:16:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B50C1A8029 for ; Wed, 9 Dec 2015 17:16:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40741BE5C for ; Thu, 10 Dec 2015 01:16:34 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxfIIg9Y4yQL for ; Thu, 10 Dec 2015 01:16:32 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CAE71BE5B for ; Thu, 10 Dec 2015 01:16:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449710192; bh=IS15ywMqIfRHLWKv4c+fut0qoA0x8w7jIJFrMapd7tc=; h=To:From:Subject:Date:From; b=rAks8BRPAL6E/kFJ50feK9myGMKl+pkE45yjDlqrcYtscEuFIEBvXctWR4Gro6f3b x3pqc5B22hkrm2B8rnDZM4xz++jRyZXGcpkobPsYptSjp5y0IVXjjKpt3h2yjCwN1T S8ij3X3Lrv+ZCnNmlpYmXLRWheByBGXREyTZz5qA= To: "saag@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5668D26F.2020200@cs.tcd.ie> Date: Thu, 10 Dec 2015 01:16:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 01:16:38 -0000 Hiya, On Dec17, the IESG will also be doing the conflict review for a draft [1] that documents some more about using GOST algorithms. Since we've typically handled national algorithms in this manner (basic alg details are documented as independent submission stream RFCs) I think this one does not represent a conflict with ongoing IETF work or process. But if I'm wrong, please do let me know. Should someone want code points for using these algorithms in IETF protocols, that'd of course go through the normal consensus process. See RFC 5742 [2] for details of what this bit of process is about. If you have comments on the draft content then please send those to the authors and cc the independent submissions editor, Nevil Brownlee (rfc-ise@rfc-editor.org). Cheers, S. [1] https://datatracker.ietf.org/doc/draft-smyshlyaev-gost-usage/ [2] https://tools.ietf.org/html/rfc5742 From nobody Wed Dec 9 22:27:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363051A8F49 for ; Wed, 9 Dec 2015 22:27:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpsTzFkmDXPR for ; Wed, 9 Dec 2015 22:27:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DDF31A8F43 for ; Wed, 9 Dec 2015 22:27:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1a6uhU-00063B-Qr; Thu, 10 Dec 2015 06:27:37 +0000 Date: Thu, 10 Dec 2015 15:27:35 +0900 Message-ID: From: Randy Bush To: Stephen Farrell In-Reply-To: <56686C32.6090400@cs.tcd.ie> References: <56686C32.6090400@cs.tcd.ie> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: saag@ietf.org Subject: Re: [saag] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 06:27:40 -0000 > The brainpool folks have written an I-D [1] that they are pushing > through the rfc editor's independent stream. [2] > > That I-D wants to register code points for using their curves for > DNSSEC. > > For documents that come through the independent stream, the IESG > does an RFC 5742 [3] conflict review. The purpose of that review > is to check that the RFC doesn't conflict with ongoing work in > the IETF. > > If you have thoughts on this, please let me know before Dec 17th. > I'll forward this to the dnsop, cfrg and curdle mailing lists > to check there too. Apologies if you get >1 copy of this. Please > try follow up on the saag list if you can. does the ietf have a chutzpah award? what viktor said randy From nobody Thu Dec 10 01:15:57 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51B1A8793; Thu, 10 Dec 2015 01:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 SSYg_XLEOTGW; Thu, 10 Dec 2015 01:15:54 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F283B1A878B; Thu, 10 Dec 2015 01:15:53 -0800 (PST) Received: from [77.72.227.183] (dyn-fg142.sth.netnod.se [77.72.226.142]) by mail.frobbit.se (Postfix) with ESMTPSA id 3B3491FD73; Thu, 10 Dec 2015 10:15:52 +0100 (CET) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "=?utf-8?b?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?=" Date: Thu, 10 Dec 2015 10:15:51 +0100 Message-ID: In-Reply-To: References: <56686C32.6090400@cs.tcd.ie> <56686C47.3070305@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_375136D8-ADDD-41DE-BF52-6FC34777D066_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: dnsop , saag@ietf.org Subject: Re: [saag] [DNSOP] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 09:15:55 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_375136D8-ADDD-41DE-BF52-6FC34777D066_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have nothing to add to what =C3=93lafur wrote below. I agree with his s= tatement. Patrik On 10 Dec 2015, at 1:33, =C3=93lafur Gu=C3=B0mundsson wrote: > Stephen, > > Sorry for being so blunt below. > > The document totally content free as to why this makes any sense in an = operational context. > DNSSEC algorithms should not be given out lightly as there is a signifi= cant COST to deploy support for each additional algorithm. > > While I strongly support having better ECC algorithm that the currently= specified curves, adding a new ones SHOULD take place via a performance = oriented process. > Thus I strongly advocate that this publication be held up until we can = compare this curve with other curves being proposed. > > Background I'm currently fighting an multifaceted battle to have variou= s entities adding support for ECDSAP256, specified over 3 years ago. > > Adding and deploying a new DNSKEY algorithm does not just require chang= es to > -- DNS servers, libraries and resolvers. > > That is just the top of the iceberg, but also to > - DNS provisioning systems, DNSSEC signing systems, DNS testing tools,= - user interfaces for registrars, hosting providers, third party DNS ope= rators, CDN's, etc. > - TLD and ccTLD policy documents, EPP implementations, plus in some cas= es security evaluations, > - not to mention firewalls, network monitoring tools .... > and number of other things I had no idea existed and majority of which = is not maintained anymore. > > There are only so many times that one can get everyone's attention to u= pgrade DNS stuff, thus requiring the change process to be run should not = be taken lightly. > If on the other hand if the editors are only interested in vanity algor= ithm assignment without any deployment then ........... > > Olafur > > > On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell > wrote: > >> >> >> >> -------- Forwarded Message -------- >> Subject: code points for brainpool curves for DNSSEC >> Date: Wed, 9 Dec 2015 18:00:18 +0000 >> From: Stephen Farrell >> To: saag@ietf.org >> >> >> Hiya, >> >> The brainpool folks have written an I-D [1] that they are pushing >> through the rfc editor's independent stream. [2] >> >> That I-D wants to register code points for using their curves for >> DNSSEC. >> >> For documents that come through the independent stream, the IESG >> does an RFC 5742 [3] conflict review. The purpose of that review >> is to check that the RFC doesn't conflict with ongoing work in >> the IETF. >> >> If you have thoughts on this, please let me know before Dec 17th. >> I'll forward this to the dnsop, cfrg and curdle mailing lists >> to check there too. Apologies if you get >1 copy of this. Please >> try follow up on the saag list if you can. >> >> Thanks, >> Stephen. >> >> >> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec >> [2] https://www.rfc-editor.org/pubprocess/ >> [3] https://tools.ietf.org/html/rfc5742 >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=_MailMate_375136D8-ADDD-41DE-BF52-6FC34777D066_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlZpQscACgkQrMabGguI182+YACfQovytyHW8sRaVdsmKzZRVUVE ilUAoIvFL8Yp92/HwhCa3nMpuZXd/wgg =WS72 -----END PGP SIGNATURE----- --=_MailMate_375136D8-ADDD-41DE-BF52-6FC34777D066_=-- From nobody Thu Dec 10 01:39:30 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB161A8795 for ; Thu, 10 Dec 2015 01:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 851b9svYnqBB for ; Thu, 10 Dec 2015 01:39:26 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A187E1A8850 for ; Thu, 10 Dec 2015 01:39:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24D39BE64 for ; Thu, 10 Dec 2015 09:39:24 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_PHWTtnoL3v for ; Thu, 10 Dec 2015 09:39:22 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F322BE54 for ; Thu, 10 Dec 2015 09:39:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449740362; bh=VmzVygr84QDpt7UezNbAy030IlZp5q7oYeKmhhqngw8=; h=Subject:References:From:To:Date:In-Reply-To:From; b=Zv9h7Bi8+hEDHwamN6xOY7gSWUWhGIX388pwLU/BNm4I8fD2JFBf1XmzsUtB/1OFM 0VOhwsUOmDaRPX2zAKuFzj8qRSqGuu68S7A4EsjJPVHSQq2s77kKEGryKllHN3zkG2 dy52yCnmO2BmgZYnn4TEXg3Nwd91c6wFFgEaBoXM= References: <56686C32.6090400@cs.tcd.ie> <56686C47.3070305@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Enigmail-Draft-Status: N1110 To: saag@ietf.org Message-ID: <56694845.4000102@cs.tcd.ie> Date: Thu, 10 Dec 2015 09:39:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="roUW840Co5imrWkEoWJv4HWT8reA2t5Sx" Archived-At: Subject: Re: [saag] [DNSOP] code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 09:39:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --roUW840Co5imrWkEoWJv4HWT8reA2t5Sx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks all, that's sufficient feedback for me to propose to the IESG that we return a "potentially disrupts, so please do not publish now" 5742 response so I have proposed that to the IESG. Additional discussion of reasons to not do this allocation now may therefore be redundant. Discussion of what to do in future is still welcome, and if that doesn't happen I at least will raise the issue on the list for the in-formation curdle WG. [1] The text I've proposed is at [2], feel free to suggest edits, but that can be done offlist. Cheers, S. [1] https://datatracker.ietf.org/doc/charter-ietf-curdle/ [2] https://datatracker.ietf.org/doc/conflict-review-schmidt-brainpool-dnssec= / On 10/12/15 09:15, Patrik F=C3=A4ltstr=C3=B6m wrote: > I have nothing to add to what =C3=93lafur wrote below. I agree with his= statement. >=20 > Patrik >=20 > On 10 Dec 2015, at 1:33, =C3=93lafur Gu=C3=B0mundsson wrote: >=20 >> Stephen, >> >> Sorry for being so blunt below. >> >> The document totally content free as to why this makes any sense in an= operational context. >> DNSSEC algorithms should not be given out lightly as there is a signif= icant COST to deploy support for each additional algorithm. >> >> While I strongly support having better ECC algorithm that the currentl= y specified curves, adding a new ones SHOULD take place via a performance= oriented process. >> Thus I strongly advocate that this publication be held up until we can= compare this curve with other curves being proposed. >> >> Background I'm currently fighting an multifaceted battle to have vario= us entities adding support for ECDSAP256, specified over 3 years ago. >> >> Adding and deploying a new DNSKEY algorithm does not just require chan= ges to >> -- DNS servers, libraries and resolvers. >> >> That is just the top of the iceberg, but also to >> - DNS provisioning systems, DNSSEC signing systems, DNS testing tools= , - user interfaces for registrars, hosting providers, third party DNS op= erators, CDN's, etc. >> - TLD and ccTLD policy documents, EPP implementations, plus in some ca= ses security evaluations, >> - not to mention firewalls, network monitoring tools .... >> and number of other things I had no idea existed and majority of which= is not maintained anymore. >> >> There are only so many times that one can get everyone's attention to = upgrade DNS stuff, thus requiring the change process to be run should not= be taken lightly. >> If on the other hand if the editors are only interested in vanity algo= rithm assignment without any deployment then ........... >> >> Olafur >> >> >> On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell >> wrote: >> >>> >>> >>> >>> -------- Forwarded Message -------- >>> Subject: code points for brainpool curves for DNSSEC >>> Date: Wed, 9 Dec 2015 18:00:18 +0000 >>> From: Stephen Farrell >>> To: saag@ietf.org >>> >>> >>> Hiya, >>> >>> The brainpool folks have written an I-D [1] that they are pushing >>> through the rfc editor's independent stream. [2] >>> >>> That I-D wants to register code points for using their curves for >>> DNSSEC. >>> >>> For documents that come through the independent stream, the IESG >>> does an RFC 5742 [3] conflict review. The purpose of that review >>> is to check that the RFC doesn't conflict with ongoing work in >>> the IETF. >>> >>> If you have thoughts on this, please let me know before Dec 17th. >>> I'll forward this to the dnsop, cfrg and curdle mailing lists >>> to check there too. Apologies if you get >1 copy of this. Please >>> try follow up on the saag list if you can. >>> >>> Thanks, >>> Stephen. >>> >>> >>> [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec >>> [2] https://www.rfc-editor.org/pubprocess/ >>> [3] https://tools.ietf.org/html/rfc5742 >>> >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop --roUW840Co5imrWkEoWJv4HWT8reA2t5Sx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWaUhJAAoJEC88hzaAX42ifykH/Rvf4tsL6DT/21zxvYZwwhbC oiVB2y3ejsIApKIYbF8k/l7s7BvBbAmstCxTcd+/4wy2R3bZRXvQiRH2JKIeHoAH igowMqi8zMN+boiIGLVCWjrKz1DJbmTuPk2cxKY7d8eYj6zjtAh4jd8tFwTSlZsZ wCp4blTsyFiengbRkF1d+Sj9W/yI/mV2HuC6VeIp4xNjTANRLv9VFDj5ETYHF6sy b3y4mdNyQ9xjn3TpuDjc9lYPoJYbN/n/bL2fmPxrWj4aUF9gyI2ephNSkpoPeGSe PCfmrMuXM4ajyteS7BDrXaEOPpWLmLq0mGXA5fjJDR7vAsK9kbdSikAeIHz56VI= =3qef -----END PGP SIGNATURE----- --roUW840Co5imrWkEoWJv4HWT8reA2t5Sx-- From nobody Thu Dec 10 06:32:03 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D027A1B3290 for ; Thu, 10 Dec 2015 06:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 oxJ3Rms_Sq6X for ; Thu, 10 Dec 2015 06:32:00 -0800 (PST) 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 37FA51B3291 for ; Thu, 10 Dec 2015 06:31:56 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBAEVqVD009361 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 Dec 2015 16:31:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBAEVq2W015494; Thu, 10 Dec 2015 16:31:52 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22121.36056.8625.417621@fireball.acr.fi> Date: Thu, 10 Dec 2015 16:31:52 +0200 From: Tero Kivinen To: Stephen Farrell In-Reply-To: <5668D26F.2020200@cs.tcd.ie> References: <5668D26F.2020200@cs.tcd.ie> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Cc: "saag@ietf.org" Subject: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 14:32:02 -0000 Stephen Farrell writes: > On Dec17, the IESG will also be doing the conflict review for a > draft [1] that documents some more about using GOST algorithms. > > Since we've typically handled national algorithms in this manner > (basic alg details are documented as independent submission > stream RFCs) I think this one does not represent a conflict with > ongoing IETF work or process. But if I'm wrong, please do let me > know. I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? It does not allocate any IANA numbers for them, so there is no way of using them, so why include those sections in this draft at all. I think it would be better to have those in the draft that allocates the numbers which allows these to be used? Also specifying anything for the obsoleted IKEv1 protocol is bad idea... > If you have comments on the draft content then please send those > to the authors and cc the independent submissions editor, Nevil > Brownlee (rfc-ise@rfc-editor.org). -- kivinen@iki.fi From nobody Thu Dec 10 06:38:10 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235581AC408 for ; Thu, 10 Dec 2015 06:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuiO2ixVsW8P for ; Thu, 10 Dec 2015 06:38:07 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00811AC3B7 for ; Thu, 10 Dec 2015 06:38:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E8834BE39; Thu, 10 Dec 2015 14:38:04 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeghUjOTHn54; Thu, 10 Dec 2015 14:38:02 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 398A3BE5B; Thu, 10 Dec 2015 14:38:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449758282; bh=kMcNLX3vBK2ncM4tR67no9IvyiFiCtz8AFsX8mYpDkE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=oCl7DaokQj89WDXx/50yAzMPHhpZnIj4tBUevXUaiHQjl6IAvAnuP3bspfhXf7y5A 8tp9QAV6C56hl8MxyLYsUxJ11s0IRHWoJLOkRGw0thdFZpa3wrmhsOr9IN3y9VR0yn dAezRnQI6u3jl0Uy+Q61ChA3WHZhSabefhGMjOf8= To: Tero Kivinen References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56698E48.8030104@cs.tcd.ie> Date: Thu, 10 Dec 2015 14:38:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <22121.36056.8625.417621@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" , Nevil Brownlee Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 14:38:09 -0000 On 10/12/15 14:31, Tero Kivinen wrote: > Stephen Farrell writes: >> On Dec17, the IESG will also be doing the conflict review for a >> draft [1] that documents some more about using GOST algorithms. >> >> Since we've typically handled national algorithms in this manner >> (basic alg details are documented as independent submission >> stream RFCs) I think this one does not represent a conflict with >> ongoing IETF work or process. But if I'm wrong, please do let me >> know. > > I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? It > does not allocate any IANA numbers for them, so there is no way of > using them, so why include those sections in this draft at all. I > think it would be better to have those in the draft that allocates the > numbers which allows these to be used? I agree, but figured that wasn't a sufficient deal to consider it a reason for the IESG to ask the ISE to not publish. > > Also specifying anything for the obsoleted IKEv1 protocol is bad > idea... Also true. If folks think having additional stuff defined for OBSOLETEd protocols like IKEv1 is so bad an idea that we ought ask the ISE to not do that, please say so. I'm sure we'd push back on that if someone wanted to do it via an IETF stream document (though I think I vaguely recall that we may have done exactly that - anyone remember?) Ta, S. > >> If you have comments on the draft content then please send those >> to the authors and cc the independent submissions editor, Nevil >> Brownlee (rfc-ise@rfc-editor.org). From nobody Thu Dec 10 07:34:43 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49A1A0021 for ; Thu, 10 Dec 2015 07:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 kkNWa6TrIzMk for ; Thu, 10 Dec 2015 07:34:40 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 8229D1A0019 for ; Thu, 10 Dec 2015 07:34:40 -0800 (PST) Received: by obcse5 with SMTP id se5so61874631obc.3 for ; Thu, 10 Dec 2015 07:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AkiNyJFnfDFdeiX+eFrExdNJ/C9cbxIQq8SuBSfaKw4=; b=z1nmkKkUaW2pxe8wYANA2fGHAgcBuuhLVuGDt86LsD2b0i1BvKTzYpti4WrqDgFwIZ RVjkSXrtRXtEcn8uzxuHT9JlaphavuVpyeymuA1B9ghz+XdpCeiTMGiS5osHHraq7QUA 9RDsdwOUeumyKBPlQHEO7mu5KrT/9QDhHst6Jv3TxwtOF5M0hprqpY/4fJ2y7MspLgDF ViZH5oJD6ArdnPOerm/Pe5pBC1dPgCj7LsiJVtGENL4QjcfVsBZQk2fKtOnsnm2PVm/s nhR6jwZuh0lPTXVvtWTAY/t+Ms3a4lxTlbra+ren+AQJ/slGTgIiz7xqa5tSq0Qt/kum tj0Q== X-Received: by 10.60.137.137 with SMTP id qi9mr10118392oeb.56.1449761679901; Thu, 10 Dec 2015 07:34:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.19.102 with HTTP; Thu, 10 Dec 2015 07:34:24 -0800 (PST) In-Reply-To: <56698E48.8030104@cs.tcd.ie> References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> <56698E48.8030104@cs.tcd.ie> From: Donald Eastlake Date: Thu, 10 Dec 2015 10:34:24 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Nevil Brownlee , "saag@ietf.org" , Tero Kivinen Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:34:41 -0000 On Thu, Dec 10, 2015 at 9:38 AM, Stephen Farrell wrote: > On 10/12/15 14:31, Tero Kivinen wrote: >> ... >> >> Also specifying anything for the obsoleted IKEv1 protocol is bad >> idea... > > Also true. > > If folks think having additional stuff defined for OBSOLETEd protocols > like IKEv1 is so bad an idea that we ought ask the ISE to not do that, > please say so. I'm sure we'd push back on that if someone wanted to > do it via an IETF stream document (though I think I vaguely recall > that we may have done exactly that - anyone remember?) I believe you are talking about the case where algorithms were added for "IKEv1" because the IKEv1 table of algorithms was being used by another protocol that is part of IEEE 802.11. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com > Ta, > S. From nobody Thu Dec 10 07:36:26 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20B11A0049 for ; Thu, 10 Dec 2015 07:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeqbPmKXAJxW for ; Thu, 10 Dec 2015 07:36:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF3D1A0047 for ; Thu, 10 Dec 2015 07:36:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B0E1BBE80; Thu, 10 Dec 2015 15:36:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdcyevFDG4kt; Thu, 10 Dec 2015 15:36:18 +0000 (GMT) Received: from [10.0.10.19] (unknown [212.76.224.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB8C3BE7B; Thu, 10 Dec 2015 15:36:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449761778; bh=DnUF3az8sVZbwbq2U1qmGBYL3RhSgGAy5xkIGGh4Dok=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=J+R0klrudtVpUUfb3Dcz1gJlnvCVwniCNxbdhNKQNt2EWdA2aQjMfxcnfz62kZwjj mqKIfT9FvIRo0WmCiOy7L7nkLv8QRonEE7kNTz9gOvuvv8nKgKjtc0rdmg5Unalxoc t7WHkep7r6jQK7MfGG7DZL9yqiYMRHPkh6ZhJVV4= To: Donald Eastlake References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> <56698E48.8030104@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56699BF1.4030801@cs.tcd.ie> Date: Thu, 10 Dec 2015 15:36:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Nevil Brownlee , "saag@ietf.org" , Tero Kivinen Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:36:24 -0000 On 10/12/15 15:34, Donald Eastlake wrote: > On Thu, Dec 10, 2015 at 9:38 AM, Stephen Farrell > wrote: >> On 10/12/15 14:31, Tero Kivinen wrote: >>> ... >>> >>> Also specifying anything for the obsoleted IKEv1 protocol is bad >>> idea... >> >> Also true. >> >> If folks think having additional stuff defined for OBSOLETEd protocols >> like IKEv1 is so bad an idea that we ought ask the ISE to not do that, >> please say so. I'm sure we'd push back on that if someone wanted to >> do it via an IETF stream document (though I think I vaguely recall >> that we may have done exactly that - anyone remember?) > > I believe you are talking about the case where algorithms were added > for "IKEv1" because the IKEv1 table of algorithms was being used by > another protocol that is part of IEEE 802.11. That's the one, thanks Donald. S. > > Thanks, > Donald > ============================= > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com > >> Ta, >> S. > From nobody Thu Dec 10 22:24:31 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991E21A907F for ; Thu, 10 Dec 2015 22:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocSH0c19AfUz for ; Thu, 10 Dec 2015 22:24:28 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 541391A908C for ; Thu, 10 Dec 2015 22:24:28 -0800 (PST) Received: by lbblt2 with SMTP id lt2so64922601lbb.3 for ; Thu, 10 Dec 2015 22:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=deEFwCiLbrZ/tTNgxgubuHqloIOn+W4rI53e1My6ac8=; b=VWY+Rwv/gKtMuQua7MXwqVTIJfxfAF2+8zh3hg/YnTpve+6w8GgQ+s3iZHhU9lsPGU BILaApof5eQ6L1HO9/6DLU1hqzTQS6DB7LZPc88CbOuB/fiRJsUf0VlYLkiY7+q/fc3l U3gwEy6kK0FEqXTK+A39h13NDoEsfsynnmNqB+aE3b7JCFh6vR5N75yqihzBWfLUit3t w3yZY56dtWmv54DlSyvZ0jyyYk6Pqd+unruFB0hAHSR5RLfPnSSl3nnJOrY2ulSAdKFC 65usPR4+cBKiRS05BthmZdgTE8xVihp1Q8EN7EGzWWJyFQ84nr1in2lHSfb7APWhkoCw ocsA== MIME-Version: 1.0 X-Received: by 10.112.211.136 with SMTP id nc8mr340306lbc.54.1449815066457; Thu, 10 Dec 2015 22:24:26 -0800 (PST) Received: by 10.25.16.31 with HTTP; Thu, 10 Dec 2015 22:24:26 -0800 (PST) In-Reply-To: <22121.36056.8625.417621@fireball.acr.fi> References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> Date: Fri, 11 Dec 2015 09:24:26 +0300 Message-ID: From: Dmitry Belyavsky To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11c3c70006bb430526996079 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 06:24:30 -0000 --001a11c3c70006bb430526996079 Content-Type: text/plain; charset=UTF-8 Dear Tero, On Thu, Dec 10, 2015 at 5:31 PM, Tero Kivinen wrote: > Stephen Farrell writes: > > On Dec17, the IESG will also be doing the conflict review for a > > draft [1] that documents some more about using GOST algorithms. > > > > Since we've typically handled national algorithms in this manner > > (basic alg details are documented as independent submission > > stream RFCs) I think this one does not represent a conflict with > > ongoing IETF work or process. But if I'm wrong, please do let me > > know. > > I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? It > does not allocate any IANA numbers for them, so there is no way of > using them, so why include those sections in this draft at all. I > think it would be better to have those in the draft that allocates the > numbers which allows these to be used? > > Also specifying anything for the obsoleted IKEv1 protocol is bad > idea... > The draft [1] describes the current usage of the Russian GOST message digest and signature algorithms. As the algorithms themselves were described in RFCs [2], [3], we now need to specify some details describing how to use them. The draft does not specify any locally invented non-standard constructions but uses the standard ones for HMAC, PRFs and KDFs. Also, there seems to be no IANA registry at least for PRFs for TLS [4] [1] https://tools.ietf.org/html/draft-smyshlyaev-gost-usage-17 [2] https://tools.ietf.org/html/rfc6986 [3] https://tools.ietf.org/html/rfc7091 [4] http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml Thank you! -- SY, Dmitry Belyavsky --001a11c3c70006bb430526996079 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Tero,

On Thu, Dec 10, 2015 at 5:31 PM, Tero Kivinen &= lt;kivinen@iki.fi&g= t; wrote:
Stephen Farrell write= s:
> On Dec17, the IESG will also be doing the conflict review for a
> draft [1] that documents some more about using GOST algorithms.
>
> Since we've typically handled national algorithms in this manner > (basic alg details are documented as independent submission
> stream RFCs) I think this one does not represent a conflict with
> ongoing IETF work or process. But if I'm wrong, please do let me > know.

I wonder why this draft do specify PRFs for TLS, IKEv1 and IKEv2? It=
does not allocate any IANA numbers for them, so there is no way of
using them, so why include those sections in this draft at all. I
think it would be better to have those in the draft that allocates the
numbers which allows these to be used?

Also specifying anything for the obsoleted IKEv1 protocol is bad
idea...

The draft [1] describes the cur= rent usage of the Russian GOST message digest and signature algorithms.=C2= =A0
As the algorithms themselves were described in RFCs [2], [3],= we now need to specify some details describing how to use them.
=
The draft does not specify any locally invented non-standard= constructions but uses the standard ones for HMAC, PRFs and KDFs.

Also, there seems to be no IANA registry at least for PRFs= for TLS [4]


Thank you!

--
SY, Dmitry Bel= yavsky
--001a11c3c70006bb430526996079-- From nobody Fri Dec 11 03:30:15 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73541A893C for ; Fri, 11 Dec 2015 03:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=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 Ajj0zgcBxJ5R for ; Fri, 11 Dec 2015 03:30:09 -0800 (PST) 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 6570C1A8930 for ; Fri, 11 Dec 2015 03:30:09 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id tBBBTwYk012790 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Dec 2015 13:29:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id tBBBTwlN011589; Fri, 11 Dec 2015 13:29:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22122.46006.525597.693993@fireball.acr.fi> Date: Fri, 11 Dec 2015 13:29:58 +0200 From: Tero Kivinen To: Dmitry Belyavsky In-Reply-To: References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 27 min X-Total-Time: 39 min Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:30:13 -0000 Dmitry Belyavsky writes: > The draft [1] describes the current usage of the Russian GOST > message digest and signature algorithms.=A0 That draft is not enough to specify how them are used in the interoperable manner, as it does not allocate IANA numbers for them. Of course if you have some other document specifying how to use private use numbers for those algorithms then you could use those algorithms, but then I think it would be better to move sections 4.2.2 to that document.=20 > As the algorithms themselves were described in RFCs [2], [3], we now > need to specify some details describing how to use them. So if the algorithms are already specified in earlier RFCs, this document tries to specify how to use them, but does not do that as it does not even try to do IANA allocations, I do fail to see the meaning of this document. I.e. is this document trying to make GOST so that it can be used in the IPsec or not. If yes, are you expecting to do IANA allocations based on this document later, or what=3F > The draft does not specify any locally invented non-standard > constructions but uses the standard ones for HMAC, PRFs and KDFs. >=20 > Also, there seems to be no IANA registry at least for PRFs for TLS [4= ] I am mostly concerned about the IPsec, not TLS, as I happen to be IANA expert for reviewing the IKEv2 assignments. >From that point of view the IKEv2 section of the draft (4.2.2.2) is not enough. The section 4.2.2.2 says that for this document specifies HMAC=5FGOST3411=5F2012=5F256 and HMAC=5FGOST3411=5F2012=5F512 for PRFs = for IKEv2, but this document does not specify those at all. There is HMAC=5FGOSTR3411=5F2012=5F256 and HMAC=5FGOSTR3411=5F2012=5F512, but I = am not sure whether they are actually same (GOST vs GOSTR), i.e. is this just typo on one of those sections or something else=3F The section 4.1.1 defining HMAC=5FGOSTR3411=5F2012=5F256 says that it "= uses H=5F256 as a hash function for HMAC", but does not specify what H=5F256= actually means. I assume it means n =3D 256 bits hash function from the= RFC6986, but that is not exactly clear. Anyways if you ever plan to do IANA allocations for IKEv2 that might mean that the information in this document is not enough, thus you might still need to make yet another draft to provide the missing details (I have not reviewed the draft yet to see what else is missing except those things I found with just quick check). Also text in this document only covers using those GOST as PRF, there is not enough specification to use them as AUTH algorithm, or to use the digital signatures in the IKEv2 authentication. -- As for the IKEv1, we had long discussion [1] on the ipsec list when we had this issue with brainpool IKEv1 curves, and they were added to the IKEv1 registry with note saying "Not for RFC 2409." [2] meaning they are not for the IPsec use. They are only there for the 802.11 use. There was strong objections in the discussion for adding any new algorithms for IKEv1 use, so specifying how this is used in the IKEv1 does not really help, as there will be strong objections for getting IANA numbers for IKEv1 use. [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg07925.html Start of discussion thread [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08216.html Summary from the WG --=20 kivinen@iki.fi From nobody Fri Dec 11 05:06:46 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1130F1A8F4E for ; Fri, 11 Dec 2015 05:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMJJZez9KO-N for ; Fri, 11 Dec 2015 05:06:42 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7DD1A8BC1 for ; Fri, 11 Dec 2015 05:06:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27919BE56; Fri, 11 Dec 2015 13:06:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00u71f5KPofB; Fri, 11 Dec 2015 13:06:38 +0000 (GMT) Received: from [10.87.48.91] (unknown [86.46.18.60]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D236BE73; Fri, 11 Dec 2015 13:06:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1449839198; bh=sMaNj4GP1jctPPhzrPdvYw8Byd/OWp7FYZyIPktoCH4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=HxdDRLK2STk1lwHqXFB4FZpUa1+IuTju48le7iFcul1TP3U7qv/d7lbV/cFlTPeIV SxkBZvdvCfaEpEVJ0hAbi8MyoWANufTq9BlGoYquWxLFoBVWbaXJwtnFRZ5QcB+szC 4DewHVYiSbXcpEqzsHRzMsswfwWNErA9/hxr9yXQ= To: Tero Kivinen , Dmitry Belyavsky References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> <22122.46006.525597.693993@fireball.acr.fi> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <566ACA5C.2080200@cs.tcd.ie> Date: Fri, 11 Dec 2015 13:06:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <22122.46006.525597.693993@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 13:06:45 -0000 Yes, Tero's correct, and I'd forgotten about that, sorry. I think there was then a consensus to not define new things for IKEv1 and the IEEE stuff was considered very much an exception. I think the least that requires is that the IESG return a 5742 result to the ISE saying that this extends an IETF protocol in a way that requires IETF consideration. Regardless of whether or not we think doing what's asked is ok, and regardless of whether or not the IEEE case sets a precedent, I think it's correct that the IETF and not ISE should get to decide whether or not to extend an OBSOLETEd protocol via a last call. I have changed the ballot thusly. [1] And sorry again for not spotting this before, Cheers, S. [1] https://datatracker.ietf.org/doc/conflict-review-smyshlyaev-gost-usage/ On 11/12/15 11:29, Tero Kivinen wrote: > As for the IKEv1, we had long discussion [1] on the ipsec list when we > had this issue with brainpool IKEv1 curves, and they were added to the > IKEv1 registry with note saying "Not for RFC 2409." [2] meaning they > are not for the IPsec use. They are only there for the 802.11 use. > > There was strong objections in the discussion for adding any new > algorithms for IKEv1 use, so specifying how this is used in the IKEv1 > does not really help, as there will be strong objections for getting > IANA numbers for IKEv1 use. > > [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg07925.html > Start of discussion thread > > [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08216.html > Summary from the WG From nobody Fri Dec 11 08:10:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3622C1A3B9F for ; Wed, 9 Dec 2015 16:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 sLcEpG178KR4 for ; Wed, 9 Dec 2015 16:33:09 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9990E1A21C7 for ; Wed, 9 Dec 2015 16:33:09 -0800 (PST) Received: by qgcc31 with SMTP id c31so110598092qgc.3 for ; Wed, 09 Dec 2015 16:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p9pbXC4qp8/++ze0GtL8BwIcmLTbdVkx7CBxrfAqG0c=; b=YQm2rvmQoM9aBbeSyXd+90+SCof+KmWU0hpFU2dmvldrmkKHQZQL4oDbmD0DZAzwiv AwenhSzY6rgj1czyN0Jo4F8tLBeSbJPHjlRyLKKQOfokZUka9F+uEsNQUfMWZ3CFnqHw a3EF+/yu+wi7HI5QqeAq4O77CnOOAtsaBp51s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p9pbXC4qp8/++ze0GtL8BwIcmLTbdVkx7CBxrfAqG0c=; b=lHAKOGhFtSTcLvjVX/8xcsK1R9x2zuLq9SsIO6756cmvjWzB9PLqQw+xWVCokiBUt3 wwavZVwq1Eq76IhS6IejDIzeOJTiZ9pxewi16s93VswUEgVTpABTsOsTZ3u+86Qs4eLq oAY6alfFLARtt8XakVvdzh5INInYdRYF9CeJDU5Kf5bVZlIK74NOsIAl2bs4D6XBzWju RDIJ4Tew9ADYbrJdUWTix/k7HD2dG4s7L/68ZnY4Sq2L83XGcG7OA2BCH+Uq7lzgRZW/ ErnPuwrkVbEUPgmrq/1mfWtA1ZoXv0EhHZ/3e1v7Wq+a3YcZv1efiPmuZl3SeLho46s2 6Txw== X-Gm-Message-State: ALoCoQn+esETFrg/MoSppUOSO6gDHAhd4fBgtX1mGqMnXUkbdEx9OeGVd0836YQIgPcQ7Yf5fm6tNSQFgrvmrkH13G7Ucl2HBHzAxQcrp4kMNqzbmlIcV8k= MIME-Version: 1.0 X-Received: by 10.129.110.132 with SMTP id j126mr2836191ywc.172.1449707588794; Wed, 09 Dec 2015 16:33:08 -0800 (PST) Received: by 10.37.88.8 with HTTP; Wed, 9 Dec 2015 16:33:08 -0800 (PST) In-Reply-To: <56686C47.3070305@cs.tcd.ie> References: <56686C32.6090400@cs.tcd.ie> <56686C47.3070305@cs.tcd.ie> Date: Wed, 9 Dec 2015 22:33:08 -0200 Message-ID: From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a11490c62dbe5dd05268059f6 Archived-At: X-Mailman-Approved-At: Fri, 11 Dec 2015 08:10:09 -0800 Cc: dnsop , saag@ietf.org Subject: Re: [saag] [DNSOP] Fwd: code points for brainpool curves for DNSSEC X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 00:33:12 -0000 --001a11490c62dbe5dd05268059f6 Content-Type: text/plain; charset=UTF-8 Stephen, Sorry for being so blunt below. The document totally content free as to why this makes any sense in an operational context. DNSSEC algorithms should not be given out lightly as there is a significant COST to deploy support for each additional algorithm. While I strongly support having better ECC algorithm that the currently specified curves, adding a new ones SHOULD take place via a performance oriented process. Thus I strongly advocate that this publication be held up until we can compare this curve with other curves being proposed. Background I'm currently fighting an multifaceted battle to have various entities adding support for ECDSAP256, specified over 3 years ago. Adding and deploying a new DNSKEY algorithm does not just require changes to -- DNS servers, libraries and resolvers. That is just the top of the iceberg, but also to - DNS provisioning systems, DNSSEC signing systems, DNS testing tools, - user interfaces for registrars, hosting providers, third party DNS operators, CDN's, etc. - TLD and ccTLD policy documents, EPP implementations, plus in some cases security evaluations, - not to mention firewalls, network monitoring tools .... and number of other things I had no idea existed and majority of which is not maintained anymore. There are only so many times that one can get everyone's attention to upgrade DNS stuff, thus requiring the change process to be run should not be taken lightly. If on the other hand if the editors are only interested in vanity algorithm assignment without any deployment then ........... Olafur On Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell wrote: > > > > -------- Forwarded Message -------- > Subject: code points for brainpool curves for DNSSEC > Date: Wed, 9 Dec 2015 18:00:18 +0000 > From: Stephen Farrell > To: saag@ietf.org > > > Hiya, > > The brainpool folks have written an I-D [1] that they are pushing > through the rfc editor's independent stream. [2] > > That I-D wants to register code points for using their curves for > DNSSEC. > > For documents that come through the independent stream, the IESG > does an RFC 5742 [3] conflict review. The purpose of that review > is to check that the RFC doesn't conflict with ongoing work in > the IETF. > > If you have thoughts on this, please let me know before Dec 17th. > I'll forward this to the dnsop, cfrg and curdle mailing lists > to check there too. Apologies if you get >1 copy of this. Please > try follow up on the saag list if you can. > > Thanks, > Stephen. > > > [1] https://tools.ietf.org/html/draft-schmidt-brainpool-dnssec > [2] https://www.rfc-editor.org/pubprocess/ > [3] https://tools.ietf.org/html/rfc5742 > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11490c62dbe5dd05268059f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stephen,=C2=A0

Sorry for being so blunt= below.=C2=A0

The document totally content free as= to why this makes any sense in an operational context.=C2=A0
DNS= SEC algorithms should not be given out lightly as there is a significant CO= ST to deploy support for each additional algorithm.

While I strongly support having better ECC algorithm that the currently s= pecified curves, adding a new ones SHOULD take place via a performance orie= nted process.=C2=A0
Thus I strongly advocate that this publicatio= n be held up until we can compare this curve with other curves being propos= ed.=C2=A0

Background I'm currently fighting an= multifaceted battle to have various entities adding support for ECDSAP256,= specified over 3 years ago.=C2=A0

Adding and depl= oying a new DNSKEY algorithm does not just require changes to=C2=A0
-- DNS servers, libraries and resolvers.=C2=A0

= That is just the top of the iceberg, =C2=A0but also to=C2=A0
- = =C2=A0DNS provisioning systems, DNSSEC signing systems, DNS testing tools,= =C2=A0
=C2=A0- user interfaces for registrars, hosting providers,= third party DNS operators, CDN's, =C2=A0etc.
=C2=A0- TLD and= ccTLD policy documents, EPP implementations, plus in some cases security e= valuations,=C2=A0
=C2=A0- not to mention firewalls, network monit= oring tools ....=C2=A0
=C2=A0and number of other things I had no = idea existed and majority of which is not maintained anymore.=C2=A0

There are only so many times that one can get everyone= 9;s attention to upgrade DNS stuff, thus requiring the change process to be= run should not be taken lightly.=C2=A0
If on the other hand if t= he editors are only interested in vanity algorithm assignment without any d= eployment then ...........=C2=A0

Olafur
=

O= n Wed, Dec 9, 2015 at 4:00 PM, Stephen Farrell <stephen.farrell@cs= .tcd.ie> wrote:



-------- Forwarded Message --------
Subject: code points for brainpool curves for DNSSEC
Date: Wed, 9 Dec 2015 18:00:18 +0000
From: Stephen Farrell <step= hen.farrell@cs.tcd.ie>
To: saag@ietf.org


Hiya,

The brainpool folks have written an I-D [1] that they are pushing
through the rfc editor's independent stream. [2]

That I-D wants to register code points for using their curves for
DNSSEC.

For documents that come through the independent stream, the IESG
does an RFC 5742 [3] conflict review. The purpose of that review
is to check that the RFC doesn't conflict with ongoing work in
the IETF.

If you have thoughts on this, please let me know before Dec 17th.
I'll forward this to the dnsop, cfrg and curdle mailing lists
to check there too. Apologies if you get >1 copy of this. Please
try follow up on the saag list if you can.

Thanks,
Stephen.


[1] https://tools.ietf.org/html/draft-schm= idt-brainpool-dnssec
[2] https://www.rfc-editor.org/pubprocess/
[3] https://tools.ietf.org/html/rfc5742



_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a11490c62dbe5dd05268059f6-- From nobody Fri Dec 11 08:10:13 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B7B1A89F2 for ; Fri, 11 Dec 2015 03:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYfM7fpUuElf for ; Fri, 11 Dec 2015 03:54:11 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BFF1A89ED for ; Fri, 11 Dec 2015 03:54:10 -0800 (PST) Received: by vkca188 with SMTP id a188so114740431vkc.0 for ; Fri, 11 Dec 2015 03:54:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Eix/Ylm0Ir9NAkpGOT4Zh8holWOyoi64W0FwWeBDa4w=; b=UP2/1C5lGWYhhFoDh4BFEcjb0+OfSVdAz31lXbDJuxA2CqwPe2YMggA5dMNUKGr/FA ZKc3V0DQ57INhasBuYnN9ujC6a6rfs09eKJA2q2iIhXOqODrJo1VVD9ywvTMNGUO76Ne 0q0l29DHkrOZbg5EtWjP0uLL4AbXBxPeVtwVSvOAXrx4eDza2UQBfk4FxMHdmSCxhSrH NLMUf0Rikfuf+sn4qK7BxeOVrdCyWil5DjidIUtTncCDYB+afSAoi5uYPdV298Do9HEl 2gUO6GOWDY9sgMi3spHbz6JIccT9xntVx1a8CjHwJC6eS4+sr55Q0BC3mvX4r0+idhKW 73+g== MIME-Version: 1.0 X-Received: by 10.31.2.17 with SMTP id 17mr12696934vkc.130.1449834850020; Fri, 11 Dec 2015 03:54:10 -0800 (PST) Received: by 10.31.63.78 with HTTP; Fri, 11 Dec 2015 03:54:09 -0800 (PST) Date: Fri, 11 Dec 2015 14:54:09 +0300 Message-ID: From: "Stanislav V. Smyshlyaev" To: kivinen@iki.fi, stephen.farrell@cs.tcd.ie, saag@ietf.org Content-Type: multipart/alternative; boundary=001a113dadd637f32805269dfbb0 Archived-At: X-Mailman-Approved-At: Fri, 11 Dec 2015 08:10:09 -0800 Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:54:13 -0000 --001a113dadd637f32805269dfbb0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, Tero! >>That draft is not enough to specify how them are used in the >>interoperable manner, as it does not allocate IANA numbers for them. >>Of course if you have some other document specifying how to use >>private use numbers for those algorithms then you could use those >>algorithms, but then I think it would be better to move sections >>4.2.2 to that document. >>So if the algorithms are already specified in earlier RFCs, this >>document tries to specify how to use them, but does not do that as it >>does not even try to do IANA allocations, I do fail to see the meaning >>of this document. >>I.e. is this document trying to make GOST so that it can be used in >>the IPsec or not. If yes, are you expecting to do IANA allocations >>based on this document later, or what? Let me clarify this. We don=E2=80=99t want any IANA allocations based on th= is document. We fix algorithms for usage in protocols (IKEv1, TLS) =E2=80=93 t= o cite the document with algorithms, not describing protocols there. We don=E2=80= =99t think that this approach contradicts anything. This RFC is, in fact, an international version of Russian standardization system document of Technical Committee on Cryptography (TC 26) =E2=80=93 that has been officia= lly approved and is currently used. All protocol definitions will be made (for IKEv2 and TLS) independently in other RFCs. >>From that point of view the IKEv2 section of the draft (4.2.2.2) is >>not enough. The section 4.2.2.2 says that for this document specifies >>HMAC_GOST3411_2012_256 and HMAC_GOST3411_2012_512 for PRFs for IKEv2, >>but this document does not specify those at all. There is >>HMAC_GOSTR3411_2012_256 and HMAC_GOSTR3411_2012_512, but I am not sure >>whether they are actually same (GOST vs GOSTR), i.e. is this just typo >>on one of those sections or something else? Yes, this is a misprint. HMAC_GOSTR3411_2012_256 and HMAC_GOSTR3411_2012_512 must be there. We=E2=80=99ll correct it in the fina= l revision, thank you very much. >>The section 4.1.1 defining HMAC_GOSTR3411_2012_256 says that it "uses >>H_256 as a hash function for HMAC", but does not specify what H_256 >>actually means. I assume it means n =3D 256 bits hash function from the >>RFC6986, but that is not exactly clear. H_256 is defined in the section =C2=ABabbreviations and symbols=C2=BB at pa= ge 4: H_256 | GOST R 34.11-2012 hash function with 256-bit output | >>Also text in this document only covers using those GOST as PRF, there >>is not enough specification to use them as AUTH algorithm, or to use >>the digital signatures in the IKEv2 authentication. Yes, we know. If we make specifications of GOST usage in IKEv2, we=E2=80=99= ll prepare a specification for it. Best regards, Stanislav --001a113dadd637f32805269dfbb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

Hello, Tero!


>>That draft is not enough to specify how them are used in the
>>interoperable manner, as it does not allocate IANA numbers for them.
>>Of course if you have some other document specifying how to use
>>private use numbers for those algorithms then you could use those
>>algorithms, but then I think it would be better to move sections
>>4.2.2 to that document.

= >>So if the algorithms are already specif= ied in earlier RFCs, this
>>document tries to specify how to use them, but does not do that as it
>>does not even try to do IANA allocations, I do fail to see the meaning
>>of this document.

>>I.e. is this document trying to make GOST so that it can be used in
>>the IPsec or not. If yes, are you expecting to do IANA allocations
>>based on this document later, or what?=

=C2=A0

=C2=A0


Let me clarify this. We don=E2=80=99t = want any IANA allocations based on this document. We fix algorithms for usage in protocols (IKEv1, TLS) =E2=80=93 to cite the document with algorithms, not = describing protocols there. We don=E2=80=99t think that this approach contradicts anyt= hing. This RFC is, in fact, an international version of Russian standardization system document of Technical Committee on Cryptography (TC 26) =E2=80=93 that has = been officially approved and is currently used. All protocol definitions will be= made (for IKEv2 and TLS) independently in other RFCs.

=C2=A0



>>From that point of view the IKEv2 section of the draft (4.2.2.2) is
>>not enough. The section 4.2.2.2 says that for this document specifies
>>HMAC_GOST3411_2012_256 and HMAC_GOST3411_2012_512 for PRFs for IKEv2,
>>but this document does not specify those at all. There is
>>HMAC_GOSTR3411_2012_256 and HMAC_GOSTR3411_2012_512, but I am not sure
>>whether they are actually same (GOST vs GOSTR), i.e. is this just typo
>>on one of those sections or something else?

=C2=A0

Yes, this is a misprint. HMAC= _GOSTR3411_2012_256 and HMAC_GOSTR3411_2012_512 must be there. We=E2=80=99ll correct it in the = final revision, thank you very much.



>>The section 4.1.1 defining HMAC_GOSTR3411_2012_256 says that it "uses
>>H_256 as a hash function for HMAC", but does not specify what H_256
>>actually means. I assume it means n =3D 256 bits hash function from the
>>RFC6986, but that is not exactly clear.

=C2=A0

H_256 is defined in the secti= on =C2=ABabbreviations and symbols=C2=BB at page 4:

H_256 | GOST R 34.11-2012 hash function with 256-bit output |



>>Also text in this document only covers using those GOST as PRF, there
>>is not enough specification to use them as AUTH algorithm, or to use
>>the digital signatures in the IKEv2 authentication.

=C2=A0

Yes, we know. If we make spec= ifications of GOST usage in IKEv2, we=E2=80=99ll prepare a specification for it.


Best regards,

= Stanislav

--001a113dadd637f32805269dfbb0-- From nobody Fri Dec 11 10:17:50 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6D1A026A for ; Fri, 11 Dec 2015 10:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxPRdQKpB6vY for ; Fri, 11 Dec 2015 10:17:47 -0800 (PST) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 202141A90F3 for ; Fri, 11 Dec 2015 10:17:47 -0800 (PST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id tBBIENaY003196; Fri, 11 Dec 2015 10:17:42 -0800 Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 1yqfytb7f5-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2015 10:17:42 -0800 Received: from SC-EXCH03.marvell.com (10.93.176.83) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 11 Dec 2015 10:17:41 -0800 Received: from SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6]) by SC-EXCH03.marvell.com ([fe80::6cb0:4dfa:f3f3:b8b6%21]) with mapi id 15.00.1044.021; Fri, 11 Dec 2015 10:17:41 -0800 From: Paul Lambert To: Stephen Farrell , Tero Kivinen , Dmitry Belyavsky Thread-Topic: [saag] another conflict review of some GOST stuff Thread-Index: AQHRM9yb+NFI8+RN+02oKcSV5KPEpJ7GLOoAgAAbAAD//9DIAA== Date: Fri, 11 Dec 2015 18:17:41 +0000 Message-ID: References: <5668D26F.2020200@cs.tcd.ie> <22121.36056.8625.417621@fireball.acr.fi> <22122.46006.525597.693993@fireball.acr.fi> <566ACA5C.2080200@cs.tcd.ie> In-Reply-To: <566ACA5C.2080200@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.94.250.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-12-11_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1507310007 definitions=main-1512110327 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 18:17:48 -0000 > >Yes, Tero's correct, and I'd forgotten about that, sorry. I >think there was then a consensus to not define new things for >IKEv1 and the IEEE stuff was considered very much an exception. The IEEE stuff has one mechanism (SAE) that references IKEv1 with text in less than a dozen locations of the total 3,701 pages. Primary text is: =09 =09 =09 =09 =09 =09 =09 =09 Groups are negotiated using an identifying number from a repository maintained by IANA as =B3Group Description=B2 attributes for IETF RFC 2409 (IKE) [B17][B29]. The repository maps an identifying number to a complete set of domain parameters for the particular group. For the purpose of interoperability, a conformant STA shall support group nineteen (19), an ECC group defined over a 256-bit prime order field. =09 =09 =09 =09 If there was a better reference for "group nineteen=B2, the IEEE specification could be changed if this would help in this process. Paul > >I think the least that requires is that the IESG return a >5742 result to the ISE saying that this extends an IETF protocol >in a way that requires IETF consideration. Regardless of >whether or not we think doing what's asked is ok, and regardless >of whether or not the IEEE case sets a precedent, I think it's >correct that the IETF and not ISE should get to decide whether >or not to extend an OBSOLETEd protocol via a last call. > >I have changed the ballot thusly. [1] > >And sorry again for not spotting this before, >Cheers, >S. > >[1]=20 >https://datatracker.ietf.org/doc/conflict-review-smyshlyaev-gost-usage/ > >On 11/12/15 11:29, Tero Kivinen wrote: >> As for the IKEv1, we had long discussion [1] on the ipsec list when we >> had this issue with brainpool IKEv1 curves, and they were added to the >> IKEv1 registry with note saying "Not for RFC 2409." [2] meaning they >> are not for the IPsec use. They are only there for the 802.11 use. >>=20 >> There was strong objections in the discussion for adding any new >> algorithms for IKEv1 use, so specifying how this is used in the IKEv1 >> does not really help, as there will be strong objections for getting >> IANA numbers for IKEv1 use. >>=20 >> [1] https://www.ietf.org/mail-archive/web/ipsec/current/msg07925.html >> Start of discussion thread >>=20 >> [2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08216.html >> Summary from the WG > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Tue Dec 22 13:43:41 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876581A9090 for ; Tue, 22 Dec 2015 13:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 9qYnLuzV8FPE for ; Tue, 22 Dec 2015 13:43:39 -0800 (PST) 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 576B01A908D for ; Tue, 22 Dec 2015 13:43:39 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id l133so136421187lfd.2 for ; Tue, 22 Dec 2015 13:43:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hS2HgvZ4xrFF2R9GQKfer8W34ALgQwQtLmeTs3xjzEg=; b=spshqFf/8cWdSJrFdrZOgjvZFhWWSqJpYVzI9l4CN0ZU6XJkJBoJKiKZ48geSuncOf IHGtdypQjcvlo7vYBf7Y/uQZSaLGgI5itwuTGLHedBuYXWHwb1xhEAsyY0bmbG85VWLU EUBPUDPHMIpaq+DvHLPZXbDQHfivpr4y4P7mt8ZojUWSEophFBfHaNdXXI1/3qk+cPA9 IilbV/HolPnHCg8GapnShioBvgu5aD3Z55F1ywz+0sISlK6AtQ9CQv7MKsMw+5hNNgL4 cZJ5Hiz9GeAQydkVllbv2skj32bqKcCps5qoUuyiM65O5HFjCctXXf1zlmUBjka0paUj dfQg== MIME-Version: 1.0 X-Received: by 10.25.42.208 with SMTP id q199mr9520391lfq.67.1450820617470; Tue, 22 Dec 2015 13:43:37 -0800 (PST) Sender: hallam@gmail.com Received: by 10.112.1.33 with HTTP; Tue, 22 Dec 2015 13:43:37 -0800 (PST) In-Reply-To: <5668D26F.2020200@cs.tcd.ie> References: <5668D26F.2020200@cs.tcd.ie> Date: Tue, 22 Dec 2015 16:43:37 -0500 X-Google-Sender-Auth: c7rgBTn8FH8vvtT6eZqdtUMWOug Message-ID: From: Phillip Hallam-Baker To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "saag@ietf.org" Subject: Re: [saag] another conflict review of some GOST stuff X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 21:43:40 -0000 I did actually come up with a use case for these: Encrypt data under AES, Encrypt the result under GOST using a different key. The chance that the NSA and GRU would cooperate to share their NOBUS keys is very small. From nobody Thu Dec 24 12:24:11 2015 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C551A044F for ; Thu, 24 Dec 2015 12:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.967 X-Spam-Level: X-Spam-Status: No, score=-98.967 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 mohDu8wDZJ52 for ; Thu, 24 Dec 2015 12:24:07 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 421B91A0419 for ; Thu, 24 Dec 2015 12:24:07 -0800 (PST) Received: (qmail 8649 invoked by uid 0); 24 Dec 2015 20:24:04 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 24 Dec 2015 20:24:04 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id xYQ01r00e2UhLwi01YQ3e8; Thu, 24 Dec 2015 13:24:03 -0700 X-Authority-Analysis: v=2.1 cv=Zc6OaKlA c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=wUQvQvOEmiQA:10 a=SSmOFEACAAAA:8 a=48vgC7mUAAAA:8 a=XBN1b0Ix3eHCJyhZi3gA:9 a=t3LMbDO27dYnwulH:21 a=9MS3ZDb_eN3Rx6ln:21 a=QEXdDO2ut3YA:10 a=LCBQModgGQ0A:10 a=zRoS4ZPEz50A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=E6tYnixhQ+ad6yBg4WUSB45lhrZ5dzWKA61ztK9otyI=; b=U6CFQht9poxz3+TR7em76Pzxpsze3tOwJc0nakhSwWzK6ZsgROCjwQJPeWk7Gyo7CrG3xUEL6NKW/wBMSfRjCwCxT40au8nmmKQhsqDnQ41Nvpks1Iums+nFymdcTrll; Received: from [73.202.80.238] (port=39456 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aCCQb-0002Ge-JW for saag@ietf.org; Thu, 24 Dec 2015 13:24:01 -0700 To: IETF Security Area Advisory Group From: =JeffH Message-ID: <567C545E.3030406@KingsMountain.com> Date: Thu, 24 Dec 2015 12:23:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [saag] fyi: [new-work] Proposed W3C Charter: Web Authentication Working Group (until 2016-01-25) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2015 20:24:09 -0000 of possible interest.. Subject: [new-work] Proposed W3C Charter: Web Authentication Working Group (until 2016-01-25) From: "Coralie Mercier" Date: Fri, 18 Dec 2015 21:30:00 +0100 To: new-work@ietf.org Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Web Authentication Working Group: http://www.w3.org/2015/12/web-authentication-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2016-01-25 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Wendy Seltzer, Technology & Society Domain Lead , or Harry Halpin . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - http://www.w3.org mailto:coralie@w3.org +336 4322 0001 http://www.w3.org/People/CMercier/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work