[Info-vax] VSI has released 9.2-1

[Dan Cross]

In article <u84k26$k8rl$1 at dont-email.me>,
Arne Vajhøj  <arne at vajhoej.dk> wrote:
>On 7/5/2023 2:23 PM, Simon Clubley wrote:
>> On 2023-07-04, Arne Vajhøj <arne at vajhoej.dk> wrote:
>>> But it is all very generic and it does not require and special
>>> HW or OS functionality. Traditional SYS$GETJPIW seems fine
>>> (assuming all the documentation and test is done, but that is
>>> also a requirement for HW or OS provided functionality).
>> 
>> At this point Arne, I don't know if you are trolling or if you really
>> believe that because your use of highly-abstracted languages and
>> associated APIs means you have lost touch with how those highly-abstracted
>> languages and APIs are implemented.
>
>I don't think my preference for programming languages are particular
>relevant for whether your claims of:
>
>#                                                        VMS systems
># _WILL_ be dropped in many areas if they are regarded as no longer being
># secure by today's standards.
>
># To put this another way, the previous solutions for generating entropy
># within user mode that I am aware of were not suitable by today's 
>standards.
>
>are correct or not.
>
>> Every single OS vendor I am aware of, including now VSI, implements
>> this stuff using a kernel module to supply the required level of quality
>> to user programs.
>> 
>> No vendor I am aware of, including even Microsoft, does entropy generation
>> for security purposes in purely user mode.
>
>Using HW/OS is definitely what is being done for new OS versions.
>
>But there is a difference from that and the old way not being
>acceptable.
>
>> Question: If SYS$GETJPIW was good enough, why didn't VSI just use that
>> instead of going straight to designing and implementing an entropy engine,
>> with all the work that involves ?
>
>The question was not whether using HW/OS is good. I think everybody
>agrees it is.
>
>The question was whether not using HW/OS would cost VMS sales now
>due to being not compliant.

I rather thought it was whether existing customers would ditch
VMS due to their old versions not being up to snuff with the
latest best-practices.  If they would, and Simon seems to
believe that they will and I believe him, then it stands to
reason that if VSI wants to retain customers it must provide a
path forward to a system that uses those best-practices, which
is what they are doing.

>It is hardly surprising that VSI is implementing new functionality
>looking forward instead of backwards.
>
>> They have not implemented many things that have been asked for due to
>> resource limitations, but they have spent time implementing this because
>> they clearly consider it to be vital.
>> 
>>  From https://docs.vmssoftware.com/docs/VSI_Webinar_March_2022.pdf in the
>> OpenSSL section:
>> 
>> |Working on new entropy engine that will work with OpenSSL 3.0 to help
>> |facilitate FIPS 140-x compliance
>> 
>> |SSL3 is also a key component of VSI's security roadmap to ensure that the
>> |OpenVMS operating system and applications running on OpenVMS are able meet
>> |relevant security requirements by supporting specific features such as FIPS.
>
>That is actually interesting.
>
>Per:
>
>https://www.openssl.org/docs/fips.html
>https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282
>
>then OpenSSL is FIPS 140-2 certified on:
>
><quote>
>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) with PAA
>     Debian 11.5 running on Dell Inspiron 7591 with Intel i7(x86) 
>without PAA
>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>     FreeBSD 13.1 running on Dell Inspiron 7591 with Intel i7(x64) 
>without PAA
>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) with PAA
>     macOS 11.5.2 running on Apple i7 Mac Mini with Intel i7(x64) 
>without PAA
>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 with PAA
>     macOS 11.5.2 running on Apple M1 Mac Mini with M1 without PAA 
>(single-user mode)
>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel 
>i7(x64) with PAA
>     Ubuntu Linux 22.04.1 LTS running on Dell Inspiron 7591 with Intel 
>i7(x64) without PAA
>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) with PAA
>     Windows 10 running on Dell Inspiron 7591 with Intel i7(x64) without PAA
></quote>
>
>Maybe VSI want VMS on that list.
>
>But that list is not the server market.
>
>>> The relevant parts are actually quite easy to follow.
>>>
>>> They just don't say that current VMS methodology is unacceptable.
>>>
>> 
>> Standards generally don't say that using "1234" as a combination or
>> "password" as a password are unacceptable either. They instead focus
>> on explaining _what_ is acceptable.
>
>Yes.
>
>But old practices seems to match the description of what is acceptable.
>
>I actually copied the text in. You just omitted it when replying.
>
>>> But this was about your claim that VMS could be dropped because
>>> it was considered not secure by todays standards.
>>>
>>> #                                                        VMS systems
>>> # _WILL_ be dropped in many areas if they are regarded as no longer being
>>> # secure by today's standards.
>>>
>>> # To put this another way, the previous solutions for generating entropy
>>> # within user mode that I am aware of were not suitable by today's
>>> standards.
>>>
>>> I want to know where those standards are.
>>>
>>> It is certainly not the NIST 800-90A/B/C quoted above.
>> 
>> Are you sure about that ?
>
>I quoted the text. You tell me what lines old OpenSSL does not match.

I don't know if the "old" OpenSSL has much to do with it; it
seems like it used some kind of system facility to get entropy.
The question then is about how one gets that entropy.  Earlier,
in the same message where you quoted text from the NIST standard
you wrote:

> But it is all very generic and it does not require and special
> HW or OS functionality. Traditional SYS$GETJPIW seems fine
> (assuming all the documentation and test is done, but that is
> also a requirement for HW or OS provided functionality).
(from https://groups.google.com/g/comp.os.vms/c/01BdjALzsWQ/m/VggQH86-AQAJ)

But note that part of the NIST document that you copied and
pasted said the following:

|4. The noise source state shall be protected from adversarial
|   knowledge or influence to the greatest extent possible. The
|   methods used for this shall be documented, including a
|   description of the (conceptual) security boundary's role in
|   protecting the noise source from adversarial observation or
|   influence.

And

|5. Although the noise source is not required to produce
|   unbiased and independent outputs, it shall exhibit random
|   behavior; i.e., the output shall not be definable by any
|   known algorithmic rule.  Documentation shall indicate
|   whether the noise source produces IID data or non-IID
|   data. This claim will be used in determining the test path
|   followed during validation. If the submitter makes an IID
|   claim, documentation shall include rationale for the claim.

Given how the `SYS$GETJPIW` interface is defined at e.g.,
https://wiki.vmssoftware.com/$GETJPI, I don't know why anyone
would believe it meets these criteria.  In particular, pretty
much everything that can be returned from GETJPI is discoverable
outside of the process, violating the "shall be protected from
adversarial knowledge to the greatest extent possible" criteria
in (4), and most of it is also "definable by known algorithmic
rules", as prohibited by (5).

Furthermore, none of the documentaton criteria specified by NIST
seem to be fulfilled.

>>> It is certainly not that Redhat article.
>>>
>>> Did you just make it up????
>> 
>> VSI consider certifying VMS against FIPS to be important and they consider
>> a kernel-based entropy engine to be a vital part of that. Are you saying
>> VSI are wrong ?
>
>If VSI believe they need FIPS certification and that they need the new
>better entropy to get that, then it all makes sense.
>
>But if you check the list above then FIPS certification does not
>seem to be a requirements to sell servers today.

Sure.  But if you have customers that you value that are making
noise about moving from your platform because of issues like
this, and you want to retain those customers, then, well, you
probably address issues like this.

	- Dan C.