[Info-vax] OpenSSL CSWS-2.2-1

[Stephen Hoffman]

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.

-- 
Pure Personal Opinion | HoffmanLabs LLC