On 15/02/2019 03:55, Jakob Bohm via openssl-users wrote: > These comments are on the version of the specification released on > Monday 2019-02-11 at https://www.openssl.org/docs/OpenSSL300Design.html > > General notes on this release: > > - The release was not announced on the openssl-users and > openssl-announce mailing lists. A related blog post was > announced two days later. Well the blog post was intended to *be* the announcement. > > - The related strategy document is at > https://www.openssl.org/docs/OpenSSLStrategicArchitecture.html > (This link is broken on the www.openssl.org front page). Fixed - thanks. > > - The draft does not link to anywhere that the public can > inspect archived or version tracked document versions. These documents have only just reached the point where they were stable enough to make public and go into version control. Any future updates will go through the normal review process for the web repo and be version controlled. The raw markdown versions are here: https://github.com/openssl/web/blob/master/docs/OpenSSL300Design.md https://github.com/openssl/web/blob/master/docs/OpenSSLStrategicArchitecture.md Pull requests and issues can be made via github in the normal way: https://github.com/openssl/web/pulls https://github.com/openssl/web/issues Other comments inserted below where I have an opinion or something to say. I'm hoping others will chip in on your other points: > Non-FIPS architecture issues: > > - The identifiers for predefined parameters and values (such as > "fips", "on", "off", "aes-128-cbc" should be binary values that > cannot be easily searched in larger program files (by attackers). > This rules out both text strings, UUID values and ASN OID values. > Something similar to the function ids would be ideal. Note that > to make this effective, the string names of these should not > appear in linked binaries. > (The context of this is linking libcrypto and/or libssl into > closed source binary programs, since open source binaries cannot > hide their internal structure anyway). > > - It should be possible for applications to configure OpenSSL to > load provider DLLs and config files from their own directories > rather than the global well-known directory (isolation from > system wide changes). I believe this is the intention. > > - It should be possible for providers (possibly not the FIPS > provider) to be linked directly into programs that link > statically to libcrypto. This implies the absence of > conflicting identifiers, a public API to pass the address of > a |OSSL_provider_init|function, all bundled providers provided > as static libraries in static library builds, and a higher > level init function that initializes both libcrypto and the > default provider. The plan is that Providers may choose to be linked against libcrypto or not as they see fit (the FIPS Provider will not be). They can be built entirely without using any libcrypto symbols at all. They just need to have the well known entry point. Any functions from the Core that the Provider may need to call are passed as callback function pointers. I can't think of a reason why there should be an issue with providers statically linking with libcrypto if they so wish. > - Static library forms of the default provider should not > force callers to include every algorithm just because they > are referenced from the default dispatch tables. For example, > it should be easy to link a static application that uses only > AES-256-CBC and SHA-256, and contains little else. Such limited > feature applications would obviously have to forego using the > all-inclusive high level init function. > > - For use with engine-like providers (such as hardware providers > and the PKCS#11 provider), it should be possible for a provider > to provide algorithms like RSA at multiple abstraction levels. > For example, some PKCS#11 hardware provides the raw RSA > algorithm (bignum in, bignum out) while others provide specific > forms such as PKCS#1.5 signature. There are even some that > provide the PKCS#1.5 form with some hashes and the RSA form > as a general fallback. I think this should be possible with the design as it stands. Providers make implementations of algorithms available to the core. I don't see any reason why they can't provide multiple implementations of the same algorithm (presumably distinguished by some properties) > > - Similarly, some providers will provide both ends of an > asymmetric algorithm, while others only provide the private > key operation, leaving the public key operation to other > providers (selected by core in the general way). Again I believe this should be possible with the current design. We split algorithm implementations into different "operations". I don't think there is any reason to require a provider to implement all operations that an algorithm is capable of (in fact I think that was the design intent). It might be worth making the ability to do this more explicit in the document. > > - The general bignum library should be exposed via an API, either > the legacy OpenSSL bignum API or a replacement API with an overlap > of at least one major version with both APIs available. There are no plans to remove access to bignum. > > - Provider algorithm implementations should carry > description/selection parameters indicating limits to access: > "key-readable=yes/no", "key-writable=yes/no", "data-internal=yes/no", > "data-external=yes/no" and "iv-internal=yes/no". For example, > a smartcard-like provider may have "key-readable=no" and > "key-writable=yes" for RSA keys, while another card may have > "key-writable=no" (meaning that externally generated keys cannot > be imported to the card. "data-internal" refers to the > ability to process (encrypt, hash etc.) data internal to the > provider, such as other keys, while "data-external" refers to > the ability to process arbitrary application data. We expect Provider authors to be able to define their own properties as they see fit. We plan to create a central repository (outside the main source code) of "common" names. So I think all of the above should be possible. > > - Variable key length algorithm implementations should carry > description/selection parameters indicating maximum and minimum > key lengths (Some will refuse to process short keys, others will > refuse long keys, some will require the key length to be a > multiple of some number). > > - The current EVP interface abuses the general (re)init operations > with omitted arguments as the main interface to update rapidly > changing algorithm parameters such as IVs and/or keys. With the > removal of legacy APIs, the need to provide parameter changing > as explicit calls in the EVP API and provider has become more > obvious. Agreed that we will need to review the EVP interface to ensure that everything you can do in the low-level interface is still possible (within reason). Note though that in 3.0.0 we are only deprecating the low-level APIs not removing them. The Strategic Architecture document (which has a view beyond 3.0.0) sees us moving them to a libcrypto-legacy library (so they would still be available).* If you do use the low-level APIs in 3.0.0 then they won't go via the Core/Providers. (* I just spotted an error in the strategy document. The packaging diagram doesn't match up with the text and doesn't show libcrypto-legacy on it - althogh the text does talk about it. I need to investigate that) > - A provider property valuable to some callers (and already a known > property of some legacy APIs) is to declare that certain simple > operations will always succeed, such as passing additional data > bytes to a hash/mac (the rare cases of hardware disconnect and/or > exceeding the algorithm maximums can be deferred to "finish" > operations). A name for this property of an algorithm > implementation could be "nofail=yes", and the list of non-failing > operations defined for each type of algorithm should be publicly > specified (a nofail hash would have a different list than a > no-fail symmetric encryption). That's an interesting idea. Again Provider can define their own properties as they see fit. We can certainly give consideration to any other properties that we would like to have a "common" definition. > > - Providers that are really bridges to another multi-provider API > (ENGINE, PKCS#11, MS CAPI 1, MS CNG) should be explicitly allowed > to load/init separately for each underlying provider. For example, > it would be bad for an application talking to one PKCS#11 module to > run, load or block all other PKCS#11 modules on the system. The design allows for providers to make algorithm implementations available/not-available over time. So I think this addresses what you are saying here? > > - Under normal file system layout conventions, /usr/share/ (and > below) is for architecture-independent files such as man pages, > trusted root certificates and platform-independent include files. > Architecture specific files such as "openssl/providers/foo.so" > and opensslconf.h belong in /usr/ or /usr/local/ . I don't believe we've got as far as specifying the installation file system layout - but this is useful input. > > > FIPS-specific issues: > > - The checksum of the FIPS DLL should be compiled into the FIPS- > capable OpenSSL library, since a checksum stored in its own file > on the end user system is too easily replaced by attackers. This > also implies that each FIPS DLL version will need its own file name > in case different applications are linked to different libcrypto > versions (because they were started before an upgrade of the shared > libcrypto or because they use their own copy of libcrypto). This is not an attack that we are seeking to defend against in 3.0.0. We consider the checksum to be an integrity check to protect against accidental changes to the module. > - If possible, the core or a libcrypto-provided FIPS-wrapper should > check the hash of the opensslfips-3.x.x.so DLL before running any > of its code (including on-load stubs), secondly, the DLL can > recheck itself using its internal implementation of the chosen MAC > algorithm, if this is required by the CMVP. This is to protect the > application if a totally unrelated malicious file is dropped in > place of the DLL. As above - this is not an attack we are seeking to defend against. > - The document seems to consistently only mentions the > shortest/weakest key lengths, such as AES-128. Hopefully the > actual release will have no such limitation. No - there is no such restriction. The full list of what we are planning to support is in Appendix 3. Although I note that we explicitly mention key lengths for some algorithms/modes but not others. We should probably update that to be consistent. > > - The well-known slowness of FIPS validations will in practice > require the FIPS module compiled from a source change to be > released (much) later than the same change in the default > provider. The draft method of submitting FIPS validation > updates just before any FIPS-affecting OpenSSL release seems > overly optimistic. > > - Similarly, due to the slowness of FIPS validation updates, > it may often be prudent to provide a root-cause fix in the > default provider and a less-effective change in the FIPS > provider, possibly involving FIPS-frozen workaround code in > libcrypto, either in core or in a separate FIPS-wrapper > component. > > - The mechanisms for dealing with cannot-export-the-private-key > hardware providers could also be used to let the FIPS provider > offer algorithm variants where the crypto officer (application > writer/installer) specify that some keys remain inside the > FIPS blob, inaccessible to the user role (application code). > For example, TLS PFS (EC)DHE keys and CMS per message keys > could by default remain inside the provider. Extending this > to TLS session keys and server private key would be a future > option. > > - In future versions, it should be possible to combine the > bundled FIPS provider with providers for FIPS-validated hardware, > such as FIPS validated PIV smart cards for TLS client > certificates. The OpenSSL FIPS provider will provide algorithm implementations matching "fips=yes". I see no reason why other providers can't do the same - so the above should be possible. > > - Support for generating and validating (EC)DH and (EC)DSA > group parameters using the FIPS-specified algorithms should > be available in addition to the fixed sets of well-known > group parameters. In FIPS 800-56A rev 3, these are the > DH primes specified using a SEED value. Other versions of > SP 800-56A, and/or supplemental NIST documents may allow > other such group parameters. > > - If permitted by the CMVP rules, allow an option for > application provided (additional) entropy input to the RNG > from outside the module boundary. Thanks for the input and all of the suggestions. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
