[Info-vax] OpenSSL CSWS-2.2-1

[Dave Froble]

On 6/4/2019 7:31 PM, Stephen Hoffman wrote:
> 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.


You're missing the point.  If a significant part of some companies 
business is with a trading partner who will not upgrade their SSL 
capabilities, and you have no way to get them to change, then, you do 
what you have to do to stay in business.

Most of your arguments are good, but, when the alternatives are "stay in 
business" or "go out of business", the choice is easy, at least for me.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486