From owner-svn-src-head@freebsd.org Wed Jun 20 15:58:22 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 991EB1020EF8 for ; Wed, 20 Jun 2018 15:58:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1FED781590 for ; Wed, 20 Jun 2018 15:58:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: c07792fc-74a2-11e8-8837-614b7c574d04 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id c07792fc-74a2-11e8-8837-614b7c574d04; Wed, 20 Jun 2018 15:58:20 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5KFwJdH082031; Wed, 20 Jun 2018 09:58:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529510299.24573.5.camel@freebsd.org> Subject: Re: svn commit: r335402 - head/sbin/veriexecctl From: Ian Lepore To: cem@freebsd.org, "Simon J. Gerraty" Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , "Stephen J. Kiernan" Date: Wed, 20 Jun 2018 09:58:19 -0600 In-Reply-To: References: <201806200108.w5K18sIR050132@repo.freebsd.org> <96021.1529475664@kaos.jnpr.net> <17033.1529508519@kaos.jnpr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:58:22 -0000 On Wed, 2018-06-20 at 08:45 -0700, Conrad Meyer wrote: > You can keep these poor security modes in your downstream product if > you want, but don't put them in the tree. > And I request exactly the opposite: reject the complaining of people who think all the world is a 256-core 5ghz server and leave in the option to use faster algorithms on real-world hardware used by real- world vendors who need some option other than "rev your hardware every 18 months to keep up with the software or get out of the business." Stronger algorithm options, yes. Even making stronger options the default, yes. But removing viable options which are endorsed by the people who actually set the standards, no. - Ian > On Wed, Jun 20, 2018 at 8:28 AM, Simon J. Gerraty > wrote: > > > > Benjamin Kaduk wrote: > > > > > > With all due respect, NIST is hardly the sole authority on this > > > topic. > > True, unless of course you sell to US govt. > > > > > > > > With my IETF Security Area Director hat on, any greenfield > > > proposal coming > > > in > > > to the IESG that included sha1 support would get extremely strong > > > pushback, > > > and I don't expect that "reducing boot time" would be seen as > > > sufficiently > > > compelling. > > Well that's unfortunate, because reality (and sales teams) can be a > > pain.   The number of customers who would trade boot time for > > improved > > security is depressingly small. > >