svn commit: r335402 - head/sbin/veriexecctl

[Ian Lepore]

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 <sjg at juniper.net>
> wrote:
> > 
> > Benjamin Kaduk <bjkfbsd at gmail.com> 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.
> >