[Info-vax] OpenSSL CSWS-2.2-1

[Stephen Hoffman]

On 2019-06-03 23:21:18 +0000, Dave Froble said:

> First, I agree that the latest TLS/SSL should be provided.
> 
> I also feel that the interface to the product should be somehow 
> compatable rather than needing re-coding to use the newer stuff.  Not 
> sure how easy that might be.

This goes well past TLS, too. There's a whole pile of drudge work here, 
and developers are increasingly being provided with frameworks for 
these tasks.

For not the first time, yes, it is possible to do all of this in 
bespoke app code—and variously either incompletely, or with errors—but 
that's not where we're headed.

> But, I'm going to ask, why remove older capabilities?  Sure, it would 
> be best to not use them.  But there will be some users that do not have 
> a choice, if they want to continue communicating with existing trading 
> partners.  So, whynot some type of configuration tool that can set 
> flags as to which protocols should be allowed?  Default it to TLS3, but 
> allow when necessary for older protocols to be allowed.

For various of these cases both involving OpenSSL and those beyond 
OpenSSL, and in no particular order...

... all code has support costs, whether that code is used or supported 
or not. Building, packaging, storage, kitting, installations, testing, 
etc.
... unsupported code still has bugs.  Unsupported security code has known bugs.
... folks that are not maintaining and are not updating their code are 
the wrong end of the market.  The folks that are not integrating with 
and not networking with other systems is getting ever smaller.
... old and unsupported code can have API problems and constraints and 
incompatibilities, and can constrain updates.
... more than a few OpenVMS sites have no idea what's secure and what's 
not, and look to the folks maintaining "the most secure operating 
system on the planet" for guidance and suggestions.
... economics. VSI can't do everything for everybody.  Where there are 
problems, start by creating and then migrating folks to better APIs.  
Deprecate and eventually remove the worst and most problematic.

For this particular case, folks using old releases and old features can 
lock in and hope it'll all keep working and as many (most?) do, or they 
can fix and maintain their code if they want or need current versions 
and support and they can then install a free OpenSSL kit and maintain 
it themselves, or possibly use an add-on and extra-cost OpenSSL kit.

Why deprecate and eventually remove?  Various reasons around the older 
OpenSSL TLS bits: the older approaches are insecure.  They're 
fundamentally broken.  More than a few users don't know this or don't 
recognize this, and it's incumbent on VSI to guide OpenVMS developers 
and end-users forward as part of the VSI "the most secure operating 
system on the planet" marketing efforts.  Preserving the older 
approaches and older APIs variously also limit the range and scope of 
enhancements and upgrades possible.

I really like compatibility.  In theory.  But that compatibility can be 
far more costly and far more constraining than many realize.  And it's 
just not possible to fit sixteen or thirty-two bytes into an eight byte 
buffer.    I'd prefer the development focus on newer bits and newer 
updates than on preserving APIs and designs for code that isn't being 
maintained.

In practice, complete upward-compatibility is increasingly incompatible 
with the future sales and future usefulness of a product, and 
incompatible with the level of development effort that can be expended 
and where and what, and with what the folks that are keeping current 
and are maintaining their products need and want.  Some old APIs have 
to be retired and removed, preferably with migration paths and/or with 
better replacements available.

I'd hope that VSI would prefer to steer user expectations away from 
some of the more problematic DEC ideas.  VSI and OpenVMS users can 
either have a focus on better APIs and features and retiring what's 
known problematic, or a focus on existing and old apps and on 
increasingly convoluted APIs and increasingly hostile designs and 
absurd defaults.  DEC focused on the latter—on compatibility—at the 
expense of the former—on usability, clear APIs, good defaults, current 
tooling, etc.  Based on what I've seen if it, the latter approach is 
also a long-term declining market, too.

There's no right answer here, and there are always trade-offs.  If 
y'all have a can't-ever-upgrade-something or 
can't-ever-change-something installation, have at.  Again, I've heard 
just about every reason for that too, and I really don't care what 
constraints or evaluations or other requirements you've gotten tangled 
with.  Figure out how to do that.  Go do it.  Whatever.  But please 
don't expect the rest of us using OpenVMS to want to cater to your 
requirements, nor to want our maintenance and our new work and our new 
apps and our development costs to be more expensive so that your 
existing and old installations can make fewer or no changes.  Or the 
new apps and new deployments increasingly go elsewhere, and the whole 
dealing-with-upgrade problems become moot.






-- 
Pure Personal Opinion | HoffmanLabs LLC