[Info-vax] OpenSSL CSWS-2.2-1

[Dave Froble]

On 6/3/2019 12:13 PM, Stephen Hoffman wrote:
> On 2019-05-30 18:47:12 +0000, Craig A. Berry said:
>
>> Oh well, I tried.  They just released it and the product name is
>> indeedSSL111.  So eventually we'll be going cross-eyed over things
>> like version V1.1-2C of a product named SSL111.
> ...
>> I'm revising this advice slightly (not that it's any more likely to be
>> followed than my advice above) based on the fact that beginning with
>> OpenSSL 3.0.0, all versions sharing a major version number will be
>> binary compatible.  So a product name of SSL03 would be sufficient for
>> everything in the 3.x.x series.
>
> Multiple parallel kits works better when the goal is to minimal changes
> with some possibility of coexistence and incremental migration.  This is
> what I've previously suggested, too.
>
> But I've rethought what I was suggesting here a while back, too.  Ship a
> TLS patch kit with all of the latest of the currently-supported TLS
> versions—the two or three or whatever that are actively seeing OpenSSL
> patches—and that removes the unsupported versions, and whatever
> TLS-related changes are needed in the OpenVMS-specific TLS framework
> that abstracts the changes in the OpenSSL APIs.
>
> This as part of integrating IP networking and security, integrate
> certificates, replacing and deprecating CDSA, etc.  And part of keeping
> that security current, particularly since OpenVMS claims to be "the most
> secure operating system on the planet".
>
> An omnibus kit that also deprecates and eventually removes the
> unsupported OpenSSL releases will cause some grief for some app
> developers and some sites.  The TLS API provides a path for some of
> those to migrate, and better handling around encryption, and around
> writing a network server without having to deal (as much) with IPv4 and
> IPv6 and certificates and DNS and the rest. The rest of the folks want
> or need to be insecure and down-revision and for whatever reason, and
> can find and integrate their own OpenSSL kits.
>
> Down-revision and backward-compatibility?  I really don't care why those
> of y'all want or need to run down-revision and variously fossil
> software, y'all have your reasons. I've heard most of those reasons too,
> and you're probably not special.  Whether you've accepted or ignored or
> mitigated the associated risks, your down-revision needs should not
> degrade the security of the rest of the folks and of those developers
> that are keeping apps current.  There's no transparent upgrade path here
> short of the addition of a TLS API, and there'll be folks that can't or
> won't upgrade to and migrate to that, and for whatever reason.  We're on
> a treadmill of upgrades, whether any of us wants to be.  But I digress.
>
> This all assumes there's to be more of an investment in security and of
> keeping SSL current, and around adding (better) support for calls from
> the descriptor-oriented programming languages.  Otherwise, we get what
> we have: parallel OpenSSL kits for three and potentially more releases.
> In a yet better world, OpenVMS logs first-use and then periodic
> (monthly?) message about apps using deprecated and insecure APIs, too.
> There are a number of folks that just don't know or don't realize
> they're using insecure constructs.
>
> But....
>
> If the associated investment around security is to continue to be
> delegated to the apps and the ISVs as is currently the case, then
> parallel kits.  Craig's proposed naming seems reasonable for that.
> Though this current approach is going to be yet another round of
> permutations and complexity; of kicking the costs to the system
> administration ("manager") and to the ISVs and developers.
>

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.

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.

It's an imperfect world, but it's the one we must live in.

I could also mention that needed support, or lack thereof, would play 
some part in selection or rejection of VMS for new users.

-- 
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