openssh unix dev - Apr 2023 - FIPS compliance efforts in Fedora and RHEL

Dear Damien,

On Wed, Apr 19, 2023 at 7:13?AM Damien Miller <djm at mindrot.org>
wrote:
>
> On Tue, 18 Apr 2023, Norbert Pocs wrote:
>
> > Hi OpenSSH mailing list,
> >
> > I would like to announce the newly introduced patch in Fedora rawhide
[0]
> > for
> >
> > FIPS compliance efforts. The change will be introduced in an upcoming
RHEL 9
> >
> > version.
> >
> > The patch targets OpenSSL support of OpenSSH, specifically the usage
of
> >
> > old low level API. The new OpenSSL version 3.0 introduces a FIPS
> >
> > module (going through FIPS 140-2 validation and to be FIPS 140-3
validated)
> >
> > which can be used with the new EVP API to state OpenSSH being FIPS
> >
> > compliant (using OpenSSL). The problem is, the old API does not use
the FIPS
> >
> > module, therefore the change is needed for the new API.
>
> While I'm sure this is good for RHEL/rawhide users who care about FIPS,
> Portable OpenSSH won't be able to merge this. We explictly aim to
support
> LibreSSL's libcrypto as well as openssl-1.1.x and neither supports the
> OSSL_PARAM_BLD API (neither does BoringSSL, though our support for that
> I'd describe as "best effort").
>
> If this changes we can look again.
Yes, we understand and respect your choice.
Would it be acceptable in any form being wrapped in necessary #ifdefs ?

-- 
Dmitry Belyavskiy

On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote:
> > While I'm sure this is good for RHEL/rawhide users who care about
FIPS,
> > Portable OpenSSH won't be able to merge this. We explictly aim to
support
> > LibreSSL's libcrypto as well as openssl-1.1.x and neither supports
the
> > OSSL_PARAM_BLD API (neither does BoringSSL, though our support for
that
> > I'd describe as "best effort").
> >
> > If this changes we can look again.
> 
> Yes, we understand and respect your choice.
> Would it be acceptable in any form being wrapped in necessary #ifdefs ?
No, I think it would be too intrusive.

IMO if we have to support both the new API and the libressl/1.1.1 API
then the only likely acceptable way would be to reimplement the new
API using the old, similar to what we did when moving to the OpenSSL
1.1.x opaque structs while still supporting the 1.0.x API.

I have no idea whether this is even possible, and we wouldn't have the
luxury of being able to use OpenSSL code to do it (as we did last time)
as the license has changed to one that we don't want to accept in the
OpenSSH codebase.

-d