From tomas at openssl.org Thu Apr 1 16:27:16 2021 From: tomas at openssl.org (Tomas Mraz) Date: Thu, 01 Apr 2021 18:27:16 +0200 Subject: Monthly Status Report (March 2021) Message-ID: <9d1ec884a4ef2acce97e5286f1614de938d36814.camel@openssl.org> My key activities this month were: - triage of newly reported issues and responding to questions - participation on the meetings - participated on the openssl-1.1.1k security release by reviewing and doing the CVE-2021-3450 fix - reviews of various PRs: - I've reviewed about 90 PRs this month - Major PRs reviewed: - Stop using EVP_PKEY in encoders and decoders #14314 - Make 'tests' depend on a generated 'providers/fipsmodule.cnf' #14320 - Add testing for non-default library context into evp_extra_test #14478 - ESS for TSP and CAdES-BES: Correct logic of ts_check_signing_certs() relating cert IDs to chain members #14503 - KDF life-cycle documentation #14522 - Fix Coverity resource leaks #14596 - Fix DER reading from stdin for BIO_f_readbuffer #14599 - HTTP: Fix method_POST param by moving it to OSSL_HTTP_REQ_CTX_set_request_line() #14699 - submitted 31 PRs: - In particular: - TODO cleanups in test, ssl, and providers directories #14367 - Another set of TODO 3.0 cleanups - this time mostly in crypto #14404 - CI: add job with external tests (temporarily krb5 and gost_engine only) #14416 - Change default algorithms in PKCS12_create() and PKCS12_set_mac() #14450 - Do not call RAND_get0_public from within the FIPS provider initialization #14497 - Make EVP_PKEY_missing_parameters work properly on provided RSA keys #14511 - Added functions for printing EVP_PKEYs to FILE * #14577 - Implement EVP_PKEY_dup() function #14624 - EVP_PKCS82PKEY: Create provided keys if possible #14659 - Cleanups related to legacy nid support #14703 - Add "save-parameters" encoder parameter #14746 - Provider side decoder API documentation #14756 -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From matt at openssl.org Wed Apr 7 14:33:19 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Apr 2021 15:33:19 +0100 Subject: Monthly Status Report (March) Message-ID: As well as normal reviews, responding to user queries, wiki user requests, OMC business, support customer issues, CLA submissions, handling security reports, etc., key activities this month: - Provided support to a number of support customers - Fixed an error in evp_extra_test - Significant work on getting the 1.1.1 tests to run against master. Noted numerous issues as a result and report written about the results - Completed and merged PR to cache legacy keys instead of downgrading them - Fixed the check for suitable groups being available for TLSv1.3 - Added numerous missing entries in CHANGES.md - Fixed a crash when using a "pkeyopt" without a ":" - Performed the alpha13 release - Addressed some TODO(3.0) comments in the code - Updated the README-FIPS.md document with 3.0 information - Fixed an issue where thread handlers were not being deregistered in the event that the provider init fails - Co-ordinated the response to CVE-2021-3449 and provided numerous related code updates - Added missing RUN_ONCE calls in rand_lib.c - Did some investigation work for CVE-2021-3450 - Co-ordinated and performed the release of 1.1.1k - Fixed an issue where too many symbols were copied into both libcrypto and legacy.so - Wrote a libcrypto overview man page - Took part in numerous planning meetings for 3.0 - Provided an improved implementation of X509_STORE_CTX_get1_issuer() (later superceded by work by Tomas) - Fixed an inadvertent behaviour change of the ctrl EVP_PKEY_CTRL_RSA_KEYGEN_BITS Matt From matt at openssl.org Thu Apr 8 09:08:57 2021 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Apr 2021 10:08:57 +0100 Subject: Final alpha release Message-ID: <7ad114cc-7cdc-2d72-7c56-cbd96e6303e7@openssl.org> The OMC are currently planning that the final alpha release of OpenSSL 3.0 will be made available on 20th May 2021. Anyone wanting new features, APIs or breaking changes to be included in 3.0 should aim to get their PRs submitted, approved and merged by this date. Thanks Matt From openssl at openssl.org Thu Apr 8 12:39:33 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 8 Apr 2021 12:39:33 +0000 Subject: OpenSSL version 3.0.0-alpha14 published Message-ID: <20210408123933.GA27472@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 14 released ===================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 14 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha14.tar.gz Size: 14392548 SHA1 checksum: 255708727c8772f930d1058d723341d68d6ed005 SHA256 checksum: 78a935e1d314d66cccaa68931702a52d42015b47c3c44bec631de9f5705cb6c0 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha14.tar.gz openssl sha256 openssl-3.0.0-alpha14.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmBu8/oACgkQ2cTSbQ5g RJHWPAf/QqZmFy8ukDYogNnOYb6dJIccXM2603+RU587PBN2hb7yFXo0T/ODs2q/ LgU4xRd2leks1IkEPlBn6XeJPwyLVKGXieRHvZzoZFSML+R+ZcwvZc9c7tdHcACn dsrOTvJkFcawI++BErtZdE03VHq0dxDfTCBHPgm7rvzkBPFPMBqoO7cwcu9z09SJ mv9wK45uDP6jNdxkTrLv4YRa9AYW7Ya8wfZvxxSLMji8L5yUpZoezo7vvzOim4A0 CwMUoIFJnkfS2aYGm15LDbMzh2x0qQ1WQNxL0zWByz6BGp+EfvC/sXOnNZC3lOdb TMpJgX9Jdhrl6SNfARp1Fou/j6uDcg== =2FSP -----END PGP SIGNATURE----- From nic.tuv at gmail.com Thu Apr 8 17:02:04 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Thu, 8 Apr 2021 20:02:04 +0300 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) Message-ID: Background ========== [PR#14759](https://github.com/openssl/openssl/pull/14759) (Set blinding=yes property on some algorithm implementations) is a fix for [Issue#14654](https://github.com/openssl/openssl/issues/14654) which itself is a spin-off of [Issue#14616](https://github.com/openssl/openssl/issues/14616). The original issue is about _Deprecated low level key API's that have no replacements_, among which the following received special attention and were issued a dedicated issue during an OTC meeting: ~~~c // RSA functions on RSA_FLAG_* void RSA_clear_flags(RSA *r, int flags); int RSA_test_flags(const RSA *r, int flags); void RSA_set_flags(RSA *r, int flags); // RSA_FLAG_* about blinding #define RSA_FLAG_BLINDING #define RSA_FLAG_NO_BLINDING // RSA functions directly on blinding int RSA_blinding_on(RSA *rsa, BN_CTX *ctx); void RSA_blinding_off(RSA *rsa); BN_BLINDING *RSA_setup_blinding(RSA *rsa, BN_CTX *ctx); ~~~ The decision the sprung Issue#14616 and PR#14759 was to use the propquery mechanism to let providers advertise algorithms as `blinding=yes` to select secure implementations if there are insecure ones present as well. Similarly it was discussed the potential `consttime=yes` property that would work in a similar way: if applied properly for our current implementations that are not fully constant time it would allow a user/sysadmin/developer to prefer a third party implementation for the same algorithm with better security guarantees. In some contexts the consttime implementation might be seriously penalizing in terms of performance and in the contexts where const time is not required this would allow to select accordingly. Definition for the blinding property ------------------------------------ The current definition of the `blinding` property applies to provider-native algorithm implementations for the `asym_cipher` and `signature` operations: ```pod =head2 Properties The following property is set by some of the OpenSSL signature algorithms. =over 4 =item "blinding" This boolean property is set to "yes" if the implementation performs blinding to prevent some side-channel attacks. ``` Rationale ========= Property queries are our decision making process for implementation selection, and has been part of the design for 3.0 since the Brisbane design meetings: I am not opposing the use of the property query mechanism to select algorithms here, but the semantics of the properties we decide to adopt (and thus endorse and encourage also for use by 3rd parties). In particular I see the following issues with choices like `blinding=yes` or `consttime=yes`. Design promotes insecure by default ----------------------------------- This design is a slippery slope into patterns that go against the "secure by default" best practices. Users/administrators/developers should not have to opt-in for the safer implementation, but the other way around: the opt-in should be for the less safe but more performant implementations after evaluating the consequences of such a choice in specific contexts. We shouldn't have users having to query for `consttime=yes` algorithms but rather for `consttime=no` explicitly in specific conditions. So if this was the only issue with PR#14759 my recommendation would be to rather flag the non-blinding implementations as such rather than the other way around as is currently done. The scenario in which 3rd party providers offer insecure algorithms not flagged as such with `consttime=no` or `blinding=no` IMO would then fall under the "know your providers" umbrella: if you are installing provider X you should be well aware that you are trusting X's authors "to do the right thing". The project history showed us how the risk for insecure-by-default designs and its consequences are not just an hypothetical matter of debate: for example, `BN_FLG_CONSTTIME` has been with us since version 0.9.8f (and even before that under the `BN_FLG_EXP_CONSTTIME` name), well over 14 years, in which the decision of having the flag off by default and requiring to manually enabling it when desired has been the cause of many vulnerabilities and fixes, that are still a concern today, as we fixed yet another instance of forgetting to set it just some weeks ago (PR#13889). In this case, though, I expect that just flipping the default is not enough to accept this PR: the problem of going with the negative versions of these flags is that such design can't be made future proof as we wish to do: we can't know in advance all possible properties that should be declared as `=no` by an algorithm released today as part of our providers when new relevant properties might be defined in the future. E.g., what if after 3.0 is released a ECCKiila provider was released and opted to tag its implementations as `formally_verified`? They could add `formally_verified=yes` but then they would fall into the "insecure by default" pattern: users would need to opt-in for the safer version instead of getting it by default, but there is no other option given that our and others' providers' offerings were not preemptively flagged with `formally_verified=no`. Scope of propquery semantics ---------------------------- This follows directly from the previous example. The design of the propquery mechanism seems (IMO) to be limited to provide __well-defined__ semantics for the properties only within the scope of a single provider (and a single provider version at that). If a given provider offered at runtime for the same algorithm two or more versions, one flagged as `consttime=no` and one with consttime guarantees, then it could provide documentation to its userbase on how to setup default propqueries in the configuration file at installation time or to application developers to embed them in their code depending on the use case, to select the `consttime=no` offering when such a thing is perceived as desirable for whatever (ill-guided :P) reason. But doing this across providers does not really work, because other provider authors might have not flagged their insecure implementations with `consttime=no`, or because there might be very different opinions on what qualifies as "fully consttime" (that evolve over time with different threat models and attacker capabilities): provX's `consttime=yes` might be "more consttime" than provY's `consttime=yes`. For example provX is similar to our default provider, and offers an EC algorithm built on top of a generic BIGNUM module so its generic implementation supports any valid EC curve named or custom and orgX made sure that the ECDH/ECDSA and ECmath layers of the implementation follow state-of-the-art practices regarding secret-dependant code execution or data access so they flag their EC implementation as `consttime=yes`, even though the underlying BIGNUM module has limited consttime guarantees, so in certain circumstances a dynamic `realloc` or some other seemingly minor thing could leak a few secret bits to a motivated attacker. provY is similar to our default provider, and provides an EC algorithm, but instead of having a generic codepath they only support a subset of named curves (e.g. only P256 and P521) each with a dedicated implementation that removes the need for a generic BIGNUM layer and instead embeds its specific consttime field arithmetic in each curve implementation (e.g. they provide our `ecp_nistz256.c` and `ecp_nistp521.c` implementations only). provY's ECDH/ECDSA, ECmath and FFmath layers all follow best consttime practices so they flag as `consttime=yes` their EC offering. Now `constime=yes` is not well-defined anymore across providers, making it quite useless for users and providers to use `consttime=yes` or `consttime=no` to pick among offerings from different providers. The same would be true within the same organization and provider, across provider versions. Let's say tomorrow we were to merge a PR that made all of BIGNUM resistant against all currently known timing side-channel techniques. Coincidentally we decided to mark all our pubkey providers as `consttime=yes` after verifying that all the layers above BIGNUM are also timing-resistant to current techniques. Fast-forward a year and a new CPU design flaw is discovered, giving a remote attacker a side-channel with unprecedented resolution and SNR: our previous `consttime=yes` semantic would not stand the test of time and the disruption of semantics could have ripple-effects within our providers and to the stack of applications that embedded `consttime=yes` as a selection mechanism to pick among offerings from various provider versions with now ill-defined qualifiers. If we can agree, even just on some level or some specific cases like these, that the definitions of properties in propqueries have their scope limited to the single provider version, what is the point of exposing `blinding=*` to our users, given that at runtime we don't offer alternative implementations for the same algorithm with different properties? (I mean, yes we have alternative choices at runtime in some cases, but not at the algorithm level in the provider API, they are buried well within each algorithm implementation that offers such choices) Too vague/coarse semantics -------------------------- Elaborating further from the examples above, there is also a conceptual issue at the base of the OTC discussion that led to PR#14759, namely that "blinding is a property of an algorithm: either an implementation does blinding or it doesn't". But this is not entirely true: blinding is applied to individual operations at various levels. RSA is a special case that has the luxury of resting its security on basically a single mathematical operation (modular exponentiation) over a single mathematical layer of abstraction (finite field math provided by BIGNUM): so it is enough to apply blinding to the modular exponentiation to say "this algorithm implementations does blinding". That is not true anymore already for DSA signing (that relies on the same single finite field math abstraction provided by BIGNUM, but already rests on two operation, exponentiation and modular inversion) and one more layer deep with ECDH/ECDSA where you have two operations (scalar multiplication and modular inversion), of which the first is composed of math operations coming from the EC arithmetic layer of abstraction, and each of those operation themselves are built as the composition of many operations from the same FF arithmetic layer from BIGNUM. The number of levels of abstraction involved in an implementation keeps rising steeply when we move into the realm of upcoming post-quantum algorithms. When you have multiple operations from multiple layers, applying binding efficiently is non-trivial, one maybe blinds only the EC scalarmul but not the FF modinv, because the first takes the bulk of the computation time and common consensus at some point in time is that there is little point in blinding the modinv if its SNR is deemed too low to be exploitable. But what happens when this does not hold anymore? What is the meaning of `blinding=yes` for an EC implementation that applied blinding only to scalarmul and not to modinv because that was the best practice at the time it was written? What if blinding is applied to the scalarmul but the FF operation to perform the blinding already leaks a small amount because BIGNUM? A small leakage might not be considered a problem with 2048+ RSA keys (shared opinion might be that 1 or 3 bits of knowledge wouldn't give the attacker a noticeable boost compared to other tools in their arsenal) but the same few bits have been proven sufficient to break even P384 or P521 keys (which are above the security level of RSA 2048) with limited effort and costs: what is the meaning of `blinding=yes` in the case where the blinding implementation itself reveals information on the secret it should protect? What if the blinding operation itself is not leaking a single bit by itself, but it magnifies some effect from the underlying level of abstraction (e.g., blinding scalarmul could make the nonce bigger than the prime order subgroup size `n`, and the specific scalarmul implementation must guarantee that its scalar input is less than `n` to compute correctly, so it has a special branch to be robust and handle bigger scalars coming from blinding, creating a magnifying lens for an attacker when the branch is taken, as that says something on the probability of the high order bits of the scalar being set)? This might seem as having nothing to do with the semantics of `blinding=yes`, but it does for providers like ours where we apply blinding at top abstraction layer (and in the case of certain paths also in strategic points in the second layer) but then have a number of different sub-algorithm implementations that behave very differently: depending on the curve name (and encoding format when parsing a key) you might end up in the generic prime/binary curves implementation, or in one of the specific ones like nistz256 or nistp521. Applying `blinding=yes` like this: ```c {"ECDSA","provider=default,blinding=yes",ossl_ecdsa_signature_functions} ``` is already making the semantics of the `blinding` property ill-defined, and affecting its effectiveness/purpose as a decision mechanism to be exposed to users: we have different codepaths under the same umbrella flagged as applying blinding, but even within it that blinding has very different shades of "yes". As @t8m said "Security is not a boolean value" and my point here is that neither is `blinding` or `consttime` and similar: they come in shades (even the `formally_verified` one: maybe the EC layer is formally verified by tools, but the underlying FF module might come with different guarantees, etc.) and the threshold by which SOTA deems the quality to become "yes*" or "no*" changes over time (e.g., it was fine to only blind scalarmul yesterday, so implementation X was considered as a blinding implementation, but today also modinv blinding is required so the same implementation X is now deemed non-blinding). Alternative ----------- Support for the specific `RSA_FLAG_BLINDING`&co functionality could instead just be dropped. My understanding is that its usefulness is already limited to legacy compatibility with engines which anyway would not play nicely with the new provider/core architecture. More in general, as a mechanism to select secure implementations if there are insecure ones present as well, the problem can already be solved applying the "know your providers" mantra in combination with the use of the `provider=default`, `provider=provX` properties to pick across the offerings of multiple providers. This wouldn't cover the use case (is this even supported/tested right now?) of a single provider registering the same algorithm twice with different alternative implementations and properties: in this case though it would be possible to use a property definition local to the specific provider version, and its documentation would inform the users of how to use propquery to select what and the related conditions and caveats. Luckily this last case does not affect our implementations, as we don't offer competing algorithms at the provider level. Although I wouldn't propose to do it, if we really really wanted to retain the functionality of `RSA_FLAG_BLINDING` and have algorithms exposing knobs with the capability of turning on/off (or 1000/500/0) whatever degree of blinding they support, we could achieve this with existing ctrls/params as we do for many other tunable knobs. Using ctrls/params over doing this on a propquery level has the advantage that the definition/semantics can be scoped with more granularity than offered at the provider level. As a user/sysadmin, if I have done the evaluation of the specific context that could lead me to responsibly decide to pick no-blinding, no-consttime, no-secure or similar hazardous choices, I would expect to be anyway in a situation where I have so much control over my system, software and environment that patching the code to pass a param or call a ctrl function deeply inside my application shouldn't be a blocker at all. Summary ------- I am opposed to merging PR#14759 for several reasons: - it lends itself to insecure-by-default patterns, repeating mistakes from the past - the validity scope for similar properties is somewhat limited to a single provider version, so its effectiveness against its purpose of being a selection mechanism for users to pick among competing algorithms offered by different providers is limited (and has the potential to hunt us back in the future) - its definition and semantics are vague, its applicability as an algorithm property too coarse to be well-defined even inside our own providers - `secure`, `blinding`, `consttime`, etc. are not boolean properties of algorithms (even if I really wish they could be) - it's one more vague concept for everyone to understand, and one more item with not-too-clear logic for the project to handle and maintain for the foreseeable future - we have already established alternatives in the form of per-implementation params or ctrls to tune some security parameters that can alter the execution flow of our implementations Also, from a more generic usability perspective and thinking of supporting those in our Community developing 3rd party providers, I think we should also - [in the vote] take a position on what are good/bad ideas when devising provider-specific properties, and have some official guidelines in the documentation about it by the time final 3.0.0 is release, and - [not in the vote, could be a separate discussion] document what mechanisms we plan to put in place to coordinate efforts which will allow for some carefully evaluated properties to have well-defined semantics (with versioning?) across providers/vendors (some form of registry of properties, with well-defined criteria for maintaining it?) Proposed vote text ================== Do not merge PR#14759, prevent declaring properties similar to `blinding=yes` or `consttime=yes` in our implementations and discourage 3rd parties from adopting similar designs. Please provide feedback on the vote text, I would like to open the vote on Monday and have some public debate about its points via the list rather then compress it on the OTC meeting which already has enough items in agenda! Thanks, Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjh at cryptsoft.com Thu Apr 8 22:50:03 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Fri, 9 Apr 2021 08:50:03 +1000 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: Message-ID: Nicola, you are (in my view) conflating multiple items. For the provider and property design approach it is rather simple. - Algorithm implementations can vary. - Selection between algorithm implementations when multiple providers are available is performed by properties Algorithm implementations should declare whatever set of properties they feel is appropriate for their implementation. Applications (and in this context most likely directly by end-user configuration) should be able to select which properties are considered most important for their context. That decision capability must be left to the end user as only the end user knows the security context in which they are operating - we don't know that ourselves. The vast majority of your lengthy email below is actually focused on one issue - what should the default behaviour be for selection of implementations - and your viewpoint that we should not mark different properties at all that might impact security. I don't think that position is supportable - in that you are basically arguing that we should never declare anything about properties of implementations and should never select between different implementations except at a "provider level" approach. Your approach is that all implementations should be considered equal and that pretty much defies logic in my view. Different implementations have different characteristics. Even looking at something like constant time - not all of our implementations are constant time. Your statement that the approach of declaring properties "promotes insecure by default" is simply flawed logic - and following the same logic I could state that your approach "promotes ignorance by default" as it effectively states that users shouldn't know the properties of the implementation in a manner that allows selection to be performed. Not all implementations are the same and different implementations can implement different mitigations. Properties allow us to declare those mitigations and allow users to make different decisions on the basis of the properties that providers declare for algorithms. Having that information available has to be a better thing than having nothing available - as with nothing available then no selection between alternatives is possible. Separately arguing about what the default set of properties should be (i.e. what mitigations should we configure as required by default) would make sense to do so - but arguing that the information for making such decisions shouldn't be present simply makes no sense. Tim. On Fri, Apr 9, 2021 at 3:02 AM Nicola Tuveri wrote: > Background > ========== > > [PR#14759](https://github.com/openssl/openssl/pull/14759) (Set > blinding=yes property on some algorithm implementations) is a fix for > [Issue#14654](https://github.com/openssl/openssl/issues/14654) which > itself is a spin-off of > [Issue#14616](https://github.com/openssl/openssl/issues/14616). > > The original issue is about _Deprecated low level key API's that have no > replacements_, among which the following received special attention and > were issued a dedicated issue during an OTC meeting: > > ~~~c > // RSA functions on RSA_FLAG_* > void RSA_clear_flags(RSA *r, int flags); > int RSA_test_flags(const RSA *r, int flags); > void RSA_set_flags(RSA *r, int flags); > > // RSA_FLAG_* about blinding > #define RSA_FLAG_BLINDING > #define RSA_FLAG_NO_BLINDING > > // RSA functions directly on blinding > int RSA_blinding_on(RSA *rsa, BN_CTX *ctx); > void RSA_blinding_off(RSA *rsa); > BN_BLINDING *RSA_setup_blinding(RSA *rsa, BN_CTX *ctx); > ~~~ > > The decision the sprung Issue#14616 and PR#14759 was to use the > propquery mechanism to let providers advertise algorithms as > `blinding=yes` to select secure implementations if there are insecure > ones present as well. > > Similarly it was discussed the potential `consttime=yes` property that > would work in a similar way: if applied properly for our current > implementations that are not fully constant time it would allow a > user/sysadmin/developer to prefer a third party implementation for the > same algorithm with better security guarantees. > In some contexts the consttime implementation might be seriously > penalizing in terms of performance and in the contexts where const time > is not required this would allow to select accordingly. > > Definition for the blinding property > ------------------------------------ > > The current definition of the `blinding` property applies to > provider-native algorithm implementations for the `asym_cipher` and > `signature` operations: > > ```pod > =head2 Properties > > The following property is set by some of the OpenSSL signature > algorithms. > > =over 4 > > =item "blinding" > > This boolean property is set to "yes" if the implementation performs > blinding to prevent some side-channel attacks. > ``` > > Rationale > ========= > > Property queries are our decision making process for implementation > selection, and has been part of the design for 3.0 since the Brisbane > design meetings: I am not opposing the use of the property query > mechanism to select algorithms here, but the semantics of the properties > we decide to adopt (and thus endorse and encourage also for use by 3rd > parties). > In particular I see the following issues with choices like > `blinding=yes` or `consttime=yes`. > > Design promotes insecure by default > ----------------------------------- > > This design is a slippery slope into patterns that go against the > "secure by default" best practices. > Users/administrators/developers should not have to opt-in for the safer > implementation, but the other way around: the opt-in should be for the > less safe but more performant implementations after evaluating the > consequences of such a choice in specific contexts. > We shouldn't have users having to query for `consttime=yes` algorithms > but rather for `consttime=no` explicitly in specific conditions. > So if this was the only issue with PR#14759 my recommendation would be > to rather flag the non-blinding implementations as such rather than the > other way around as is currently done. > > The scenario in which 3rd party providers offer insecure algorithms not > flagged as such with `consttime=no` or `blinding=no` IMO would then fall > under the "know your providers" umbrella: if you are installing provider > X you should be well aware that you are trusting X's authors "to do the > right thing". > > The project history showed us how the risk for insecure-by-default > designs and its consequences are not just an hypothetical matter of > debate: for example, `BN_FLG_CONSTTIME` has been with us since version > 0.9.8f (and even before that under the `BN_FLG_EXP_CONSTTIME` name), > well over 14 years, in which the decision of having the flag off by > default and requiring to manually enabling it when desired has been the > cause of many vulnerabilities and fixes, that are still a concern today, > as we fixed yet another instance of forgetting to set it just some weeks > ago (PR#13889). > > In this case, though, I expect that just flipping the default is not > enough to accept this PR: the problem of going with the negative > versions of these flags is that such design can't be made future proof > as we wish to do: we can't know in advance all possible properties that > should be declared as `=no` by an algorithm released today as part of > our providers when new relevant properties might be defined in the > future. > E.g., what if after 3.0 is released a ECCKiila provider was released and > opted to tag its implementations as `formally_verified`? > They could add `formally_verified=yes` but then they would fall into the > "insecure by default" pattern: users would need to opt-in for the safer > version instead of getting it by default, but there is no other option > given that our and others' providers' offerings were not preemptively > flagged with `formally_verified=no`. > > Scope of propquery semantics > ---------------------------- > > This follows directly from the previous example. The design of the > propquery mechanism seems (IMO) to be limited to provide > __well-defined__ semantics for the properties only within the scope of a > single provider (and a single provider version at that). > > If a given provider offered at runtime for the same algorithm two or > more versions, one flagged as `consttime=no` and one with > consttime guarantees, then it could provide documentation to its > userbase on how to setup default propqueries in the configuration file > at installation time or to application developers to embed them in their > code depending on the use case, to select the `consttime=no` offering > when such a thing is perceived as desirable for whatever (ill-guided :P) > reason. > > But doing this across providers does not really work, because other > provider authors might have not flagged their insecure implementations > with `consttime=no`, or because there might be very different opinions > on what qualifies as "fully consttime" (that evolve over time with > different threat models and attacker capabilities): > provX's `consttime=yes` might be "more consttime" than provY's > `consttime=yes`. > For example provX is similar to our default provider, and > offers an EC algorithm built on top of a generic BIGNUM module so its > generic implementation supports any valid EC curve named or custom and > orgX made sure that the ECDH/ECDSA and ECmath layers of the > implementation follow state-of-the-art practices regarding > secret-dependant code execution or data access so they flag their > EC implementation as `consttime=yes`, even though the underlying BIGNUM > module has limited consttime guarantees, so in certain circumstances a > dynamic `realloc` or some other seemingly minor thing could leak a few > secret bits to a motivated attacker. > provY is similar to our default provider, and provides an EC algorithm, > but instead of having a generic codepath they only support a subset of > named curves (e.g. only P256 and P521) each with a dedicated > implementation that removes the need for a generic BIGNUM layer and > instead embeds its specific consttime field arithmetic in each curve > implementation (e.g. they provide our `ecp_nistz256.c` and > `ecp_nistp521.c` implementations only). provY's ECDH/ECDSA, ECmath and > FFmath layers all follow best consttime practices so they flag as > `consttime=yes` their EC offering. > Now `constime=yes` is not well-defined anymore across providers, making > it quite useless for users and providers to use `consttime=yes` or > `consttime=no` to pick among offerings from different providers. > > The same would be true within the same organization and provider, across > provider versions. Let's say tomorrow we were to merge a PR that made > all of BIGNUM resistant against all currently known timing side-channel > techniques. Coincidentally we decided to mark all our pubkey providers > as `consttime=yes` after verifying that all the layers above BIGNUM are > also timing-resistant to current techniques. > Fast-forward a year and a new CPU design flaw is discovered, giving a > remote attacker a side-channel with unprecedented resolution and > SNR: our previous `consttime=yes` semantic would not stand the > test of time and the disruption of semantics could have ripple-effects > within our providers and to the stack of applications that embedded > `consttime=yes` as a selection mechanism to pick among offerings from > various provider versions with now ill-defined qualifiers. > > If we can agree, even just on some level or some specific cases like > these, that the definitions of properties in propqueries have their > scope limited to the single provider version, what is the point of > exposing `blinding=*` to our users, given that at runtime we don't offer > alternative implementations for the same algorithm with different > properties? > (I mean, yes we have alternative choices at runtime in some cases, but > not at the algorithm level in the provider API, they are buried well > within each algorithm implementation that offers such choices) > > Too vague/coarse semantics > -------------------------- > > Elaborating further from the examples above, there is also a conceptual > issue at the base of the OTC discussion that led to PR#14759, namely > that "blinding is a property of an algorithm: either an implementation > does blinding or it doesn't". > > But this is not entirely true: blinding is applied to individual > operations at various levels. > RSA is a special case that has the luxury of resting its security on > basically a single mathematical operation (modular exponentiation) over > a single mathematical layer of abstraction (finite field math provided > by BIGNUM): so it is enough to apply blinding to the modular > exponentiation to say "this algorithm implementations does blinding". > That is not true anymore already for DSA signing (that relies on the > same single finite field math abstraction provided by BIGNUM, but > already rests on two operation, exponentiation and modular inversion) > and one more layer deep with ECDH/ECDSA where you have two operations > (scalar multiplication and modular inversion), of which the first > is composed of math operations coming from the EC arithmetic layer of > abstraction, and each of those operation themselves are built as the > composition of many operations from the same FF arithmetic layer from > BIGNUM. > The number of levels of abstraction involved in an implementation keeps > rising steeply when we move into the realm of upcoming post-quantum > algorithms. > When you have multiple operations from multiple layers, applying binding > efficiently is non-trivial, one maybe blinds only the EC scalarmul but > not the FF modinv, because the first takes the bulk of the computation > time and common consensus at some point in time is that there is little > point in blinding the modinv if its SNR is deemed too low to be > exploitable. But what happens when this does not hold anymore? What is > the meaning of `blinding=yes` for an EC implementation that applied > blinding only to scalarmul and not to modinv because that was the best > practice at the time it was written? > What if blinding is applied to the scalarmul but the FF operation to > perform the blinding already leaks a small amount because BIGNUM? > A small leakage might not be considered a problem with 2048+ RSA > keys (shared opinion might be that 1 or 3 bits of knowledge wouldn't > give the attacker a noticeable boost compared to other tools in their > arsenal) but the same few bits have been proven sufficient to break even > P384 or P521 keys (which are above the security level of RSA 2048) with > limited effort and costs: what is the meaning of `blinding=yes` in the > case where the blinding implementation itself reveals information on the > secret it should protect? > > What if the blinding operation itself is not leaking a single bit by > itself, but it magnifies some effect from the underlying level of > abstraction (e.g., blinding scalarmul could make the nonce bigger than > the prime order subgroup size `n`, and the specific scalarmul > implementation must guarantee that its scalar input is less than `n` to > compute correctly, so it has a special branch to be robust and handle > bigger scalars coming from blinding, creating a magnifying lens for an > attacker when the branch is taken, as that says something on the > probability of the high order bits of the scalar being set)? > This might seem as having nothing to do with the semantics of > `blinding=yes`, but it does for providers like ours where we apply > blinding at top abstraction layer (and in the case of certain paths also > in strategic points in the second layer) but then have a number of > different sub-algorithm implementations that behave very differently: > depending on the curve name (and encoding format when parsing a key) you > might end up in the generic prime/binary curves implementation, or in > one of the specific ones like nistz256 or nistp521. > > Applying `blinding=yes` like this: > > ```c > {"ECDSA","provider=default,blinding=yes",ossl_ecdsa_signature_functions} > ``` > > is already making the semantics of the `blinding` property ill-defined, > and affecting its effectiveness/purpose as a decision mechanism to be > exposed to users: we have different codepaths under the same umbrella > flagged as applying blinding, but even within it that blinding has very > different shades of "yes". > > As @t8m said "Security is not a boolean value" and my point here is that > neither is `blinding` or `consttime` and similar: they come in shades > (even the `formally_verified` one: maybe the EC layer is formally > verified by tools, but the underlying FF module might come with > different guarantees, etc.) and the threshold by which SOTA deems the > quality to become "yes*" or "no*" changes over time (e.g., it was fine > to only blind scalarmul yesterday, so implementation X was considered as > a blinding implementation, but today also modinv blinding is required so > the same implementation X is now deemed non-blinding). > > Alternative > ----------- > > Support for the specific `RSA_FLAG_BLINDING`&co functionality could > instead just be dropped. > My understanding is that its usefulness is already limited to legacy > compatibility with engines which anyway would not play nicely with the > new provider/core architecture. > > More in general, as a mechanism to select secure implementations if > there are insecure ones present as well, the problem can already be > solved applying the "know your providers" mantra in combination with the > use of the `provider=default`, `provider=provX` properties to pick > across the offerings of multiple providers. > > This wouldn't cover the use case (is this even supported/tested right > now?) of a single provider registering the same algorithm twice with > different alternative implementations and properties: in this case > though it would be possible to use a property definition local to the > specific provider version, and its documentation would inform the users > of how to use propquery to select what and the related conditions and > caveats. Luckily this last case does not affect our implementations, as > we don't offer competing algorithms at the provider level. > > Although I wouldn't propose to do it, if we really really wanted to > retain the functionality of `RSA_FLAG_BLINDING` and have > algorithms exposing knobs with the capability of turning on/off (or > 1000/500/0) whatever degree of blinding they support, we could achieve > this with existing ctrls/params as we do for many other tunable knobs. > Using ctrls/params over doing this on a propquery level has the > advantage that the definition/semantics can be scoped with more > granularity than offered at the provider level. > As a user/sysadmin, if I have done the evaluation of the specific > context that could lead me to responsibly decide to pick no-blinding, > no-consttime, no-secure or similar hazardous choices, I would expect to > be anyway in a situation where I have so much control over my > system, software and environment that patching the code to pass a param > or call a ctrl function deeply inside my application shouldn't be a > blocker at all. > > Summary > ------- > > I am opposed to merging PR#14759 for several reasons: > > - it lends itself to insecure-by-default patterns, repeating mistakes > from the past > - the validity scope for similar properties is somewhat limited to a > single provider version, so its effectiveness against its purpose of > being a selection mechanism for users to pick among competing > algorithms offered by different providers is limited (and has the > potential to hunt us back in the future) > - its definition and semantics are vague, its applicability as an > algorithm property too coarse to be well-defined even inside our own > providers > - `secure`, `blinding`, `consttime`, etc. are not boolean properties of > algorithms (even if I really wish they could be) > - it's one more vague concept for everyone to understand, and one more > item with not-too-clear logic for the project to handle and maintain > for the foreseeable future > - we have already established alternatives in the form of > per-implementation params or ctrls to tune some security parameters > that can alter the execution flow of our implementations > > Also, from a more generic usability perspective and thinking of > supporting those in our Community developing 3rd party providers, I > think we should also > > - [in the vote] take a position on what are good/bad ideas when devising > provider-specific properties, and have some official guidelines in the > documentation about it by the time final 3.0.0 is release, and > - [not in the vote, could be a separate discussion] document what > mechanisms we plan to put in place to coordinate efforts > which will allow for some carefully evaluated properties to have > well-defined semantics (with versioning?) across providers/vendors > (some form of registry of properties, with well-defined criteria for > maintaining it?) > > Proposed vote text > ================== > > Do not merge PR#14759, prevent declaring properties similar to > `blinding=yes` or `consttime=yes` in our implementations and > discourage 3rd parties from adopting similar designs. > > > > > Please provide feedback on the vote text, I would like to open the vote > on Monday and have some public debate about its points via the list > rather then compress it on the OTC meeting which already has enough > items in agenda! > > Thanks, > > Nicola > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Thu Apr 8 23:48:14 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 9 Apr 2021 02:48:14 +0300 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: Message-ID: Thanks for the feedback Tim! I see your points and I value the discussion. Reading your message I realized that probably I got carried away in some of the details in the lengthy email, and lost focus on part of the message I wanted to convey. Setting aside the matter of secure by default designs, I don't oppose having a property system to let users select whatever implementation from a menu of available implementations. But when these are boolean properties as proposed in the PR, they should be objective properties with a universally clear definition that is immutable over time and clear cut between yes/no. This is not the case for blinding=yes because it is not a boolean property. In most cases a blinding implementation does "some" blinding at some level, but does not blind every single computation. Moreover the "amount" of blinding that qualifies an implementation as performing the minimum required blinding changes over time, over threat models, different standardizing bodies/different subjective considerations: it's not an objective property of an algorithm implementation. blinding=no has better semantics because you could define it as "this implementation intentionally avoids any kind of blinding", and that would be an objective, universal, and immutable definition. Same applies for consttime=yes vs consttime=no. Then I went on blabbing about the downsides of the =no variants of this, because they are cases that don't admit a well defined =yes counterpart. I included that to justify why I don't believe that flipping the flag logic here would be enough to make the PR acceptable (IMO). I would not oppose this PR if it was defining a property string to mark another objective quality of the implementation: e.g. supports_cofactor_ecdh=yes vs =no, or compressed_format=yes, batching=yes, multiprime=yes, padding=this_or_that_padding_standard as I don't argue about having the provider=whatever that qualifies the origin of an implementation, or labvalidated=cert_program_xyz, ISOxxxxx_score=3.14 and similar things. Those properties have clear definitions and could be perfectly useful for apps and end-users to choose among a rich menu of alternatives. No objection there. You make another point with which I tend to disagree strongly: some actionable information must be better than no information at all. I agree with it when it is stated like that, but I believe that is not the case if the "some information" has a high risk of being actually "disinformation". In such cases the extra information can actually do more harm than good, e.g. false sense of security, misled choices, risks of ossification, technical debt, maintenance burden, etc. What leads me to qualify blinding=yes as a property string with high risks of quickly degrading into disinformation? The fact that it has ill-defined semantics as I verbosely tried to argument. The bits about the scope of well-definedness (apologies I fail to phrase this in a better way) are both to support the above argument and to start a discussion on how to establish criteria that would allow coordination among the project and our community (incouding different provider authors and the end-users) so that there is process to create well-defined shared property strings for those qualities that cannot be reduced to definitions given by some existing standardization body. In such a propquery program, I am of the opinion that "applies countermeasures to prevent some side-channel attacks" should be deemed unacceptable because of the reasons stated above, and rejected. Thanks again for you feedback, I hope this time I did a better job of separating the concerns I have about the semantics of the proposed property string and on the need to establish some guidance to have some degree of coherence in the definition of property strings. I see it already as a problem that in this and the previous email a lot of my arguments had to be prefixed with "in my opinion" because we lack a framework to guide our own choices. Nicola P.S. aside from the main topic, I understand provider authors are free to define and use properties as they see fit, and we are not limiting that freedom in my proposal. But we need a framework to guide our decisions in soundly designing and defining our own properties, and also a system to allow coordinated properties when desirable (which is relevant here because blinding=yes is an attempt at establishing a shared property definition for end-users and 3rd party providers, given that its only purpose is to let end-users decide among some of our implementations or some yet to come 3rd party implementation). On Fri, Apr 9, 2021, 01:50 Tim Hudson wrote: > Nicola, you are (in my view) conflating multiple items. > > For the provider and property design approach it is rather simple. > - Algorithm implementations can vary. > - Selection between algorithm implementations when multiple providers are > available is performed by properties > > Algorithm implementations should declare whatever set of properties they > feel is appropriate for their implementation. > Applications (and in this context most likely directly by end-user > configuration) should be able to select which properties are considered > most important for their context. > That decision capability must be left to the end user as only the end user > knows the security context in which they are operating - we don't know that > ourselves. > > The vast majority of your lengthy email below is actually focused on one > issue - what should the default behaviour be for selection of > implementations - and your viewpoint that we should not mark different > properties at all that might impact security. I don't think that position > is supportable - in that you are basically arguing that we should never > declare anything about properties of implementations and should never > select between different implementations except at a "provider level" > approach. Your approach is that all implementations should be considered > equal and that pretty much defies logic in my view. > > Different implementations have different characteristics. Even looking at > something like constant time - not all of our implementations are constant > time. > > Your statement that the approach of declaring properties "promotes > insecure by default" is simply flawed logic - and following the same logic > I could state that your approach "promotes ignorance by default" as it > effectively states that users shouldn't know the properties of the > implementation in a manner that allows selection to be performed. > > Not all implementations are the same and different implementations can > implement different mitigations. Properties allow us to declare those > mitigations and allow users to make different decisions on the basis of the > properties that providers declare for algorithms. Having that information > available has to be a better thing than having nothing available - as with > nothing available then no selection between alternatives is possible. > > Separately arguing about what the default set of properties should be > (i.e. what mitigations should we configure as required by default) would > make sense to do so - but arguing that the information for making such > decisions shouldn't be present simply makes no sense. > > Tim. > > > On Fri, Apr 9, 2021 at 3:02 AM Nicola Tuveri wrote: > >> Background >> ========== >> >> [PR#14759](https://github.com/openssl/openssl/pull/14759) (Set >> blinding=yes property on some algorithm implementations) is a fix for >> [Issue#14654](https://github.com/openssl/openssl/issues/14654) which >> itself is a spin-off of >> [Issue#14616](https://github.com/openssl/openssl/issues/14616). >> >> The original issue is about _Deprecated low level key API's that have no >> replacements_, among which the following received special attention and >> were issued a dedicated issue during an OTC meeting: >> >> ~~~c >> // RSA functions on RSA_FLAG_* >> void RSA_clear_flags(RSA *r, int flags); >> int RSA_test_flags(const RSA *r, int flags); >> void RSA_set_flags(RSA *r, int flags); >> >> // RSA_FLAG_* about blinding >> #define RSA_FLAG_BLINDING >> #define RSA_FLAG_NO_BLINDING >> >> // RSA functions directly on blinding >> int RSA_blinding_on(RSA *rsa, BN_CTX *ctx); >> void RSA_blinding_off(RSA *rsa); >> BN_BLINDING *RSA_setup_blinding(RSA *rsa, BN_CTX *ctx); >> ~~~ >> >> The decision the sprung Issue#14616 and PR#14759 was to use the >> propquery mechanism to let providers advertise algorithms as >> `blinding=yes` to select secure implementations if there are insecure >> ones present as well. >> >> Similarly it was discussed the potential `consttime=yes` property that >> would work in a similar way: if applied properly for our current >> implementations that are not fully constant time it would allow a >> user/sysadmin/developer to prefer a third party implementation for the >> same algorithm with better security guarantees. >> In some contexts the consttime implementation might be seriously >> penalizing in terms of performance and in the contexts where const time >> is not required this would allow to select accordingly. >> >> Definition for the blinding property >> ------------------------------------ >> >> The current definition of the `blinding` property applies to >> provider-native algorithm implementations for the `asym_cipher` and >> `signature` operations: >> >> ```pod >> =head2 Properties >> >> The following property is set by some of the OpenSSL signature >> algorithms. >> >> =over 4 >> >> =item "blinding" >> >> This boolean property is set to "yes" if the implementation performs >> blinding to prevent some side-channel attacks. >> ``` >> >> Rationale >> ========= >> >> Property queries are our decision making process for implementation >> selection, and has been part of the design for 3.0 since the Brisbane >> design meetings: I am not opposing the use of the property query >> mechanism to select algorithms here, but the semantics of the properties >> we decide to adopt (and thus endorse and encourage also for use by 3rd >> parties). >> In particular I see the following issues with choices like >> `blinding=yes` or `consttime=yes`. >> >> Design promotes insecure by default >> ----------------------------------- >> >> This design is a slippery slope into patterns that go against the >> "secure by default" best practices. >> Users/administrators/developers should not have to opt-in for the safer >> implementation, but the other way around: the opt-in should be for the >> less safe but more performant implementations after evaluating the >> consequences of such a choice in specific contexts. >> We shouldn't have users having to query for `consttime=yes` algorithms >> but rather for `consttime=no` explicitly in specific conditions. >> So if this was the only issue with PR#14759 my recommendation would be >> to rather flag the non-blinding implementations as such rather than the >> other way around as is currently done. >> >> The scenario in which 3rd party providers offer insecure algorithms not >> flagged as such with `consttime=no` or `blinding=no` IMO would then fall >> under the "know your providers" umbrella: if you are installing provider >> X you should be well aware that you are trusting X's authors "to do the >> right thing". >> >> The project history showed us how the risk for insecure-by-default >> designs and its consequences are not just an hypothetical matter of >> debate: for example, `BN_FLG_CONSTTIME` has been with us since version >> 0.9.8f (and even before that under the `BN_FLG_EXP_CONSTTIME` name), >> well over 14 years, in which the decision of having the flag off by >> default and requiring to manually enabling it when desired has been the >> cause of many vulnerabilities and fixes, that are still a concern today, >> as we fixed yet another instance of forgetting to set it just some weeks >> ago (PR#13889). >> >> In this case, though, I expect that just flipping the default is not >> enough to accept this PR: the problem of going with the negative >> versions of these flags is that such design can't be made future proof >> as we wish to do: we can't know in advance all possible properties that >> should be declared as `=no` by an algorithm released today as part of >> our providers when new relevant properties might be defined in the >> future. >> E.g., what if after 3.0 is released a ECCKiila provider was released and >> opted to tag its implementations as `formally_verified`? >> They could add `formally_verified=yes` but then they would fall into the >> "insecure by default" pattern: users would need to opt-in for the safer >> version instead of getting it by default, but there is no other option >> given that our and others' providers' offerings were not preemptively >> flagged with `formally_verified=no`. >> >> Scope of propquery semantics >> ---------------------------- >> >> This follows directly from the previous example. The design of the >> propquery mechanism seems (IMO) to be limited to provide >> __well-defined__ semantics for the properties only within the scope of a >> single provider (and a single provider version at that). >> >> If a given provider offered at runtime for the same algorithm two or >> more versions, one flagged as `consttime=no` and one with >> consttime guarantees, then it could provide documentation to its >> userbase on how to setup default propqueries in the configuration file >> at installation time or to application developers to embed them in their >> code depending on the use case, to select the `consttime=no` offering >> when such a thing is perceived as desirable for whatever (ill-guided :P) >> reason. >> >> But doing this across providers does not really work, because other >> provider authors might have not flagged their insecure implementations >> with `consttime=no`, or because there might be very different opinions >> on what qualifies as "fully consttime" (that evolve over time with >> different threat models and attacker capabilities): >> provX's `consttime=yes` might be "more consttime" than provY's >> `consttime=yes`. >> For example provX is similar to our default provider, and >> offers an EC algorithm built on top of a generic BIGNUM module so its >> generic implementation supports any valid EC curve named or custom and >> orgX made sure that the ECDH/ECDSA and ECmath layers of the >> implementation follow state-of-the-art practices regarding >> secret-dependant code execution or data access so they flag their >> EC implementation as `consttime=yes`, even though the underlying BIGNUM >> module has limited consttime guarantees, so in certain circumstances a >> dynamic `realloc` or some other seemingly minor thing could leak a few >> secret bits to a motivated attacker. >> provY is similar to our default provider, and provides an EC algorithm, >> but instead of having a generic codepath they only support a subset of >> named curves (e.g. only P256 and P521) each with a dedicated >> implementation that removes the need for a generic BIGNUM layer and >> instead embeds its specific consttime field arithmetic in each curve >> implementation (e.g. they provide our `ecp_nistz256.c` and >> `ecp_nistp521.c` implementations only). provY's ECDH/ECDSA, ECmath and >> FFmath layers all follow best consttime practices so they flag as >> `consttime=yes` their EC offering. >> Now `constime=yes` is not well-defined anymore across providers, making >> it quite useless for users and providers to use `consttime=yes` or >> `consttime=no` to pick among offerings from different providers. >> >> The same would be true within the same organization and provider, across >> provider versions. Let's say tomorrow we were to merge a PR that made >> all of BIGNUM resistant against all currently known timing side-channel >> techniques. Coincidentally we decided to mark all our pubkey providers >> as `consttime=yes` after verifying that all the layers above BIGNUM are >> also timing-resistant to current techniques. >> Fast-forward a year and a new CPU design flaw is discovered, giving a >> remote attacker a side-channel with unprecedented resolution and >> SNR: our previous `consttime=yes` semantic would not stand the >> test of time and the disruption of semantics could have ripple-effects >> within our providers and to the stack of applications that embedded >> `consttime=yes` as a selection mechanism to pick among offerings from >> various provider versions with now ill-defined qualifiers. >> >> If we can agree, even just on some level or some specific cases like >> these, that the definitions of properties in propqueries have their >> scope limited to the single provider version, what is the point of >> exposing `blinding=*` to our users, given that at runtime we don't offer >> alternative implementations for the same algorithm with different >> properties? >> (I mean, yes we have alternative choices at runtime in some cases, but >> not at the algorithm level in the provider API, they are buried well >> within each algorithm implementation that offers such choices) >> >> Too vague/coarse semantics >> -------------------------- >> >> Elaborating further from the examples above, there is also a conceptual >> issue at the base of the OTC discussion that led to PR#14759, namely >> that "blinding is a property of an algorithm: either an implementation >> does blinding or it doesn't". >> >> But this is not entirely true: blinding is applied to individual >> operations at various levels. >> RSA is a special case that has the luxury of resting its security on >> basically a single mathematical operation (modular exponentiation) over >> a single mathematical layer of abstraction (finite field math provided >> by BIGNUM): so it is enough to apply blinding to the modular >> exponentiation to say "this algorithm implementations does blinding". >> That is not true anymore already for DSA signing (that relies on the >> same single finite field math abstraction provided by BIGNUM, but >> already rests on two operation, exponentiation and modular inversion) >> and one more layer deep with ECDH/ECDSA where you have two operations >> (scalar multiplication and modular inversion), of which the first >> is composed of math operations coming from the EC arithmetic layer of >> abstraction, and each of those operation themselves are built as the >> composition of many operations from the same FF arithmetic layer from >> BIGNUM. >> The number of levels of abstraction involved in an implementation keeps >> rising steeply when we move into the realm of upcoming post-quantum >> algorithms. >> When you have multiple operations from multiple layers, applying binding >> efficiently is non-trivial, one maybe blinds only the EC scalarmul but >> not the FF modinv, because the first takes the bulk of the computation >> time and common consensus at some point in time is that there is little >> point in blinding the modinv if its SNR is deemed too low to be >> exploitable. But what happens when this does not hold anymore? What is >> the meaning of `blinding=yes` for an EC implementation that applied >> blinding only to scalarmul and not to modinv because that was the best >> practice at the time it was written? >> What if blinding is applied to the scalarmul but the FF operation to >> perform the blinding already leaks a small amount because BIGNUM? >> A small leakage might not be considered a problem with 2048+ RSA >> keys (shared opinion might be that 1 or 3 bits of knowledge wouldn't >> give the attacker a noticeable boost compared to other tools in their >> arsenal) but the same few bits have been proven sufficient to break even >> P384 or P521 keys (which are above the security level of RSA 2048) with >> limited effort and costs: what is the meaning of `blinding=yes` in the >> case where the blinding implementation itself reveals information on the >> secret it should protect? >> >> What if the blinding operation itself is not leaking a single bit by >> itself, but it magnifies some effect from the underlying level of >> abstraction (e.g., blinding scalarmul could make the nonce bigger than >> the prime order subgroup size `n`, and the specific scalarmul >> implementation must guarantee that its scalar input is less than `n` to >> compute correctly, so it has a special branch to be robust and handle >> bigger scalars coming from blinding, creating a magnifying lens for an >> attacker when the branch is taken, as that says something on the >> probability of the high order bits of the scalar being set)? >> This might seem as having nothing to do with the semantics of >> `blinding=yes`, but it does for providers like ours where we apply >> blinding at top abstraction layer (and in the case of certain paths also >> in strategic points in the second layer) but then have a number of >> different sub-algorithm implementations that behave very differently: >> depending on the curve name (and encoding format when parsing a key) you >> might end up in the generic prime/binary curves implementation, or in >> one of the specific ones like nistz256 or nistp521. >> >> Applying `blinding=yes` like this: >> >> ```c >> {"ECDSA","provider=default,blinding=yes",ossl_ecdsa_signature_functions} >> ``` >> >> is already making the semantics of the `blinding` property ill-defined, >> and affecting its effectiveness/purpose as a decision mechanism to be >> exposed to users: we have different codepaths under the same umbrella >> flagged as applying blinding, but even within it that blinding has very >> different shades of "yes". >> >> As @t8m said "Security is not a boolean value" and my point here is that >> neither is `blinding` or `consttime` and similar: they come in shades >> (even the `formally_verified` one: maybe the EC layer is formally >> verified by tools, but the underlying FF module might come with >> different guarantees, etc.) and the threshold by which SOTA deems the >> quality to become "yes*" or "no*" changes over time (e.g., it was fine >> to only blind scalarmul yesterday, so implementation X was considered as >> a blinding implementation, but today also modinv blinding is required so >> the same implementation X is now deemed non-blinding). >> >> Alternative >> ----------- >> >> Support for the specific `RSA_FLAG_BLINDING`&co functionality could >> instead just be dropped. >> My understanding is that its usefulness is already limited to legacy >> compatibility with engines which anyway would not play nicely with the >> new provider/core architecture. >> >> More in general, as a mechanism to select secure implementations if >> there are insecure ones present as well, the problem can already be >> solved applying the "know your providers" mantra in combination with the >> use of the `provider=default`, `provider=provX` properties to pick >> across the offerings of multiple providers. >> >> This wouldn't cover the use case (is this even supported/tested right >> now?) of a single provider registering the same algorithm twice with >> different alternative implementations and properties: in this case >> though it would be possible to use a property definition local to the >> specific provider version, and its documentation would inform the users >> of how to use propquery to select what and the related conditions and >> caveats. Luckily this last case does not affect our implementations, as >> we don't offer competing algorithms at the provider level. >> >> Although I wouldn't propose to do it, if we really really wanted to >> retain the functionality of `RSA_FLAG_BLINDING` and have >> algorithms exposing knobs with the capability of turning on/off (or >> 1000/500/0) whatever degree of blinding they support, we could achieve >> this with existing ctrls/params as we do for many other tunable knobs. >> Using ctrls/params over doing this on a propquery level has the >> advantage that the definition/semantics can be scoped with more >> granularity than offered at the provider level. >> As a user/sysadmin, if I have done the evaluation of the specific >> context that could lead me to responsibly decide to pick no-blinding, >> no-consttime, no-secure or similar hazardous choices, I would expect to >> be anyway in a situation where I have so much control over my >> system, software and environment that patching the code to pass a param >> or call a ctrl function deeply inside my application shouldn't be a >> blocker at all. >> >> Summary >> ------- >> >> I am opposed to merging PR#14759 for several reasons: >> >> - it lends itself to insecure-by-default patterns, repeating mistakes >> from the past >> - the validity scope for similar properties is somewhat limited to a >> single provider version, so its effectiveness against its purpose of >> being a selection mechanism for users to pick among competing >> algorithms offered by different providers is limited (and has the >> potential to hunt us back in the future) >> - its definition and semantics are vague, its applicability as an >> algorithm property too coarse to be well-defined even inside our own >> providers >> - `secure`, `blinding`, `consttime`, etc. are not boolean properties of >> algorithms (even if I really wish they could be) >> - it's one more vague concept for everyone to understand, and one more >> item with not-too-clear logic for the project to handle and maintain >> for the foreseeable future >> - we have already established alternatives in the form of >> per-implementation params or ctrls to tune some security parameters >> that can alter the execution flow of our implementations >> >> Also, from a more generic usability perspective and thinking of >> supporting those in our Community developing 3rd party providers, I >> think we should also >> >> - [in the vote] take a position on what are good/bad ideas when devising >> provider-specific properties, and have some official guidelines in the >> documentation about it by the time final 3.0.0 is release, and >> - [not in the vote, could be a separate discussion] document what >> mechanisms we plan to put in place to coordinate efforts >> which will allow for some carefully evaluated properties to have >> well-defined semantics (with versioning?) across providers/vendors >> (some form of registry of properties, with well-defined criteria for >> maintaining it?) >> >> Proposed vote text >> ================== >> >> Do not merge PR#14759, prevent declaring properties similar to >> `blinding=yes` or `consttime=yes` in our implementations and >> discourage 3rd parties from adopting similar designs. >> >> >> >> >> Please provide feedback on the vote text, I would like to open the vote >> on Monday and have some public debate about its points via the list >> rather then compress it on the OTC meeting which already has enough >> items in agenda! >> >> Thanks, >> >> Nicola >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane.lontis at oracle.com Thu Apr 8 23:51:23 2021 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Fri, 9 Apr 2021 09:51:23 +1000 Subject: [External] : Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: Message-ID: <6AEAF3DB-48D9-42F1-B512-144B7A1FE9C2@oracle.com> Nicola we already have a interface that sets blinding to on or off.. > On 9 Apr 2021, at 9:48 am, Nicola Tuveri wrote: > > Thanks for the feedback Tim! > I see your points and I value the discussion. > > Reading your message I realized that probably I got carried away in some of the details in the lengthy email, and lost focus on part of the message I wanted to convey. > > Setting aside the matter of secure by default designs, > I don't oppose having a property system to let users select whatever implementation from a menu of available implementations. > But when these are boolean properties as proposed in the PR, they should be objective properties with a universally clear definition that is immutable over time and clear cut between yes/no. > > This is not the case for blinding=yes because it is not a boolean property. In most cases a blinding implementation does "some" blinding at some level, but does not blind every single computation. > Moreover the "amount" of blinding that qualifies an implementation as performing the minimum required blinding changes over time, over threat models, different standardizing bodies/different subjective considerations: it's not an objective property of an algorithm implementation. > blinding=no has better semantics because you could define it as "this implementation intentionally avoids any kind of blinding", and that would be an objective, universal, and immutable definition. > Same applies for consttime=yes vs consttime=no. > Then I went on blabbing about the downsides of the =no variants of this, because they are cases that don't admit a well defined =yes counterpart. I included that to justify why I don't believe that flipping the flag logic here would be enough to make the PR acceptable (IMO). > > I would not oppose this PR if it was defining a property string to mark another objective quality of the implementation: e.g. supports_cofactor_ecdh=yes vs =no, or compressed_format=yes, batching=yes, multiprime=yes, padding=this_or_that_padding_standard as I don't argue about having the provider=whatever that qualifies the origin of an implementation, or labvalidated=cert_program_xyz, ISOxxxxx_score=3.14 and similar things. > Those properties have clear definitions and could be perfectly useful for apps and end-users to choose among a rich menu of alternatives. No objection there. > > You make another point with which I tend to disagree strongly: some actionable information must be better than no information at all. > > I agree with it when it is stated like that, but I believe that is not the case if the "some information" has a high risk of being actually "disinformation". > In such cases the extra information can actually do more harm than good, e.g. false sense of security, misled choices, risks of ossification, technical debt, maintenance burden, etc. > > What leads me to qualify blinding=yes as a property string with high risks of quickly degrading into disinformation? The fact that it has ill-defined semantics as I verbosely tried to argument. > > The bits about the scope of well-definedness (apologies I fail to phrase this in a better way) are both to support the above argument and to start a discussion on how to establish criteria that would allow coordination among the project and our community (incouding different provider authors and the end-users) so that there is process to create well-defined shared property strings for those qualities that cannot be reduced to definitions given by some existing standardization body. > In such a propquery program, I am of the opinion that "applies countermeasures to prevent some side-channel attacks" should be deemed unacceptable because of the reasons stated above, and rejected. > > > > Thanks again for you feedback, I hope this time I did a better job of separating the concerns I have about the semantics of the proposed property string and on the need to establish some guidance to have some degree of coherence in the definition of property strings. > I see it already as a problem that in this and the previous email a lot of my arguments had to be prefixed with "in my opinion" because we lack a framework to guide our own choices. > > > Nicola > > > P.S. aside from the main topic, I understand provider authors are free to define and use properties as they see fit, and we are not limiting that freedom in my proposal. But we need a framework to guide our decisions in soundly designing and defining our own properties, and also a system to allow coordinated properties when desirable (which is relevant here because blinding=yes is an attempt at establishing a shared property definition for end-users and 3rd party providers, given that its only purpose is to let end-users decide among some of our implementations or some yet to come 3rd party implementation). > > On Fri, Apr 9, 2021, 01:50 Tim Hudson > wrote: > Nicola, you are (in my view) conflating multiple items. > > For the provider and property design approach it is rather simple. > - Algorithm implementations can vary. > - Selection between algorithm implementations when multiple providers are available is performed by properties > > Algorithm implementations should declare whatever set of properties they feel is appropriate for their implementation. > Applications (and in this context most likely directly by end-user configuration) should be able to select which properties are considered most important for their context. > That decision capability must be left to the end user as only the end user knows the security context in which they are operating - we don't know that ourselves. > > The vast majority of your lengthy email below is actually focused on one issue - what should the default behaviour be for selection of implementations - and your viewpoint that we should not mark different properties at all that might impact security. I don't think that position is supportable - in that you are basically arguing that we should never declare anything about properties of implementations and should never select between different implementations except at a "provider level" approach. Your approach is that all implementations should be considered equal and that pretty much defies logic in my view. > > Different implementations have different characteristics. Even looking at something like constant time - not all of our implementations are constant time. > > Your statement that the approach of declaring properties "promotes insecure by default" is simply flawed logic - and following the same logic I could state that your approach "promotes ignorance by default" as it effectively states that users shouldn't know the properties of the implementation in a manner that allows selection to be performed. > > Not all implementations are the same and different implementations can implement different mitigations. Properties allow us to declare those mitigations and allow users to make different decisions on the basis of the properties that providers declare for algorithms. Having that information available has to be a better thing than having nothing available - as with nothing available then no selection between alternatives is possible. > > Separately arguing about what the default set of properties should be (i.e. what mitigations should we configure as required by default) would make sense to do so - but arguing that the information for making such decisions shouldn't be present simply makes no sense. > > Tim. > > > On Fri, Apr 9, 2021 at 3:02 AM Nicola Tuveri > wrote: > Background > ========== > > [PR#14759](https://github.com/openssl/openssl/pull/14759 ) (Set > blinding=yes property on some algorithm implementations) is a fix for > [Issue#14654](https://github.com/openssl/openssl/issues/14654 ) which > itself is a spin-off of > [Issue#14616](https://github.com/openssl/openssl/issues/14616 ). > > The original issue is about _Deprecated low level key API's that have no > replacements_, among which the following received special attention and > were issued a dedicated issue during an OTC meeting: > > ~~~c > // RSA functions on RSA_FLAG_* > void RSA_clear_flags(RSA *r, int flags); > int RSA_test_flags(const RSA *r, int flags); > void RSA_set_flags(RSA *r, int flags); > > // RSA_FLAG_* about blinding > #define RSA_FLAG_BLINDING > #define RSA_FLAG_NO_BLINDING > > // RSA functions directly on blinding > int RSA_blinding_on(RSA *rsa, BN_CTX *ctx); > void RSA_blinding_off(RSA *rsa); > BN_BLINDING *RSA_setup_blinding(RSA *rsa, BN_CTX *ctx); > ~~~ > > The decision the sprung Issue#14616 and PR#14759 was to use the > propquery mechanism to let providers advertise algorithms as > `blinding=yes` to select secure implementations if there are insecure > ones present as well. > > Similarly it was discussed the potential `consttime=yes` property that > would work in a similar way: if applied properly for our current > implementations that are not fully constant time it would allow a > user/sysadmin/developer to prefer a third party implementation for the > same algorithm with better security guarantees. > In some contexts the consttime implementation might be seriously > penalizing in terms of performance and in the contexts where const time > is not required this would allow to select accordingly. > > Definition for the blinding property > ------------------------------------ > > The current definition of the `blinding` property applies to > provider-native algorithm implementations for the `asym_cipher` and > `signature` operations: > > ```pod > =head2 Properties > > The following property is set by some of the OpenSSL signature > algorithms. > > =over 4 > > =item "blinding" > > This boolean property is set to "yes" if the implementation performs > blinding to prevent some side-channel attacks. > ``` > > Rationale > ========= > > Property queries are our decision making process for implementation > selection, and has been part of the design for 3.0 since the Brisbane > design meetings: I am not opposing the use of the property query > mechanism to select algorithms here, but the semantics of the properties > we decide to adopt (and thus endorse and encourage also for use by 3rd > parties). > In particular I see the following issues with choices like > `blinding=yes` or `consttime=yes`. > > Design promotes insecure by default > ----------------------------------- > > This design is a slippery slope into patterns that go against the > "secure by default" best practices. > Users/administrators/developers should not have to opt-in for the safer > implementation, but the other way around: the opt-in should be for the > less safe but more performant implementations after evaluating the > consequences of such a choice in specific contexts. > We shouldn't have users having to query for `consttime=yes` algorithms > but rather for `consttime=no` explicitly in specific conditions. > So if this was the only issue with PR#14759 my recommendation would be > to rather flag the non-blinding implementations as such rather than the > other way around as is currently done. > > The scenario in which 3rd party providers offer insecure algorithms not > flagged as such with `consttime=no` or `blinding=no` IMO would then fall > under the "know your providers" umbrella: if you are installing provider > X you should be well aware that you are trusting X's authors "to do the > right thing". > > The project history showed us how the risk for insecure-by-default > designs and its consequences are not just an hypothetical matter of > debate: for example, `BN_FLG_CONSTTIME` has been with us since version > 0.9.8f (and even before that under the `BN_FLG_EXP_CONSTTIME` name), > well over 14 years, in which the decision of having the flag off by > default and requiring to manually enabling it when desired has been the > cause of many vulnerabilities and fixes, that are still a concern today, > as we fixed yet another instance of forgetting to set it just some weeks > ago (PR#13889). > > In this case, though, I expect that just flipping the default is not > enough to accept this PR: the problem of going with the negative > versions of these flags is that such design can't be made future proof > as we wish to do: we can't know in advance all possible properties that > should be declared as `=no` by an algorithm released today as part of > our providers when new relevant properties might be defined in the > future. > E.g., what if after 3.0 is released a ECCKiila provider was released and > opted to tag its implementations as `formally_verified`? > They could add `formally_verified=yes` but then they would fall into the > "insecure by default" pattern: users would need to opt-in for the safer > version instead of getting it by default, but there is no other option > given that our and others' providers' offerings were not preemptively > flagged with `formally_verified=no`. > > Scope of propquery semantics > ---------------------------- > > This follows directly from the previous example. The design of the > propquery mechanism seems (IMO) to be limited to provide > __well-defined__ semantics for the properties only within the scope of a > single provider (and a single provider version at that). > > If a given provider offered at runtime for the same algorithm two or > more versions, one flagged as `consttime=no` and one with > consttime guarantees, then it could provide documentation to its > userbase on how to setup default propqueries in the configuration file > at installation time or to application developers to embed them in their > code depending on the use case, to select the `consttime=no` offering > when such a thing is perceived as desirable for whatever (ill-guided :P) > reason. > > But doing this across providers does not really work, because other > provider authors might have not flagged their insecure implementations > with `consttime=no`, or because there might be very different opinions > on what qualifies as "fully consttime" (that evolve over time with > different threat models and attacker capabilities): > provX's `consttime=yes` might be "more consttime" than provY's > `consttime=yes`. > For example provX is similar to our default provider, and > offers an EC algorithm built on top of a generic BIGNUM module so its > generic implementation supports any valid EC curve named or custom and > orgX made sure that the ECDH/ECDSA and ECmath layers of the > implementation follow state-of-the-art practices regarding > secret-dependant code execution or data access so they flag their > EC implementation as `consttime=yes`, even though the underlying BIGNUM > module has limited consttime guarantees, so in certain circumstances a > dynamic `realloc` or some other seemingly minor thing could leak a few > secret bits to a motivated attacker. > provY is similar to our default provider, and provides an EC algorithm, > but instead of having a generic codepath they only support a subset of > named curves (e.g. only P256 and P521) each with a dedicated > implementation that removes the need for a generic BIGNUM layer and > instead embeds its specific consttime field arithmetic in each curve > implementation (e.g. they provide our `ecp_nistz256.c` and > `ecp_nistp521.c` implementations only). provY's ECDH/ECDSA, ECmath and > FFmath layers all follow best consttime practices so they flag as > `consttime=yes` their EC offering. > Now `constime=yes` is not well-defined anymore across providers, making > it quite useless for users and providers to use `consttime=yes` or > `consttime=no` to pick among offerings from different providers. > > The same would be true within the same organization and provider, across > provider versions. Let's say tomorrow we were to merge a PR that made > all of BIGNUM resistant against all currently known timing side-channel > techniques. Coincidentally we decided to mark all our pubkey providers > as `consttime=yes` after verifying that all the layers above BIGNUM are > also timing-resistant to current techniques. > Fast-forward a year and a new CPU design flaw is discovered, giving a > remote attacker a side-channel with unprecedented resolution and > SNR: our previous `consttime=yes` semantic would not stand the > test of time and the disruption of semantics could have ripple-effects > within our providers and to the stack of applications that embedded > `consttime=yes` as a selection mechanism to pick among offerings from > various provider versions with now ill-defined qualifiers. > > If we can agree, even just on some level or some specific cases like > these, that the definitions of properties in propqueries have their > scope limited to the single provider version, what is the point of > exposing `blinding=*` to our users, given that at runtime we don't offer > alternative implementations for the same algorithm with different > properties? > (I mean, yes we have alternative choices at runtime in some cases, but > not at the algorithm level in the provider API, they are buried well > within each algorithm implementation that offers such choices) > > Too vague/coarse semantics > -------------------------- > > Elaborating further from the examples above, there is also a conceptual > issue at the base of the OTC discussion that led to PR#14759, namely > that "blinding is a property of an algorithm: either an implementation > does blinding or it doesn't". > > But this is not entirely true: blinding is applied to individual > operations at various levels. > RSA is a special case that has the luxury of resting its security on > basically a single mathematical operation (modular exponentiation) over > a single mathematical layer of abstraction (finite field math provided > by BIGNUM): so it is enough to apply blinding to the modular > exponentiation to say "this algorithm implementations does blinding". > That is not true anymore already for DSA signing (that relies on the > same single finite field math abstraction provided by BIGNUM, but > already rests on two operation, exponentiation and modular inversion) > and one more layer deep with ECDH/ECDSA where you have two operations > (scalar multiplication and modular inversion), of which the first > is composed of math operations coming from the EC arithmetic layer of > abstraction, and each of those operation themselves are built as the > composition of many operations from the same FF arithmetic layer from > BIGNUM. > The number of levels of abstraction involved in an implementation keeps > rising steeply when we move into the realm of upcoming post-quantum > algorithms. > When you have multiple operations from multiple layers, applying binding > efficiently is non-trivial, one maybe blinds only the EC scalarmul but > not the FF modinv, because the first takes the bulk of the computation > time and common consensus at some point in time is that there is little > point in blinding the modinv if its SNR is deemed too low to be > exploitable. But what happens when this does not hold anymore? What is > the meaning of `blinding=yes` for an EC implementation that applied > blinding only to scalarmul and not to modinv because that was the best > practice at the time it was written? > What if blinding is applied to the scalarmul but the FF operation to > perform the blinding already leaks a small amount because BIGNUM? > A small leakage might not be considered a problem with 2048+ RSA > keys (shared opinion might be that 1 or 3 bits of knowledge wouldn't > give the attacker a noticeable boost compared to other tools in their > arsenal) but the same few bits have been proven sufficient to break even > P384 or P521 keys (which are above the security level of RSA 2048) with > limited effort and costs: what is the meaning of `blinding=yes` in the > case where the blinding implementation itself reveals information on the > secret it should protect? > > What if the blinding operation itself is not leaking a single bit by > itself, but it magnifies some effect from the underlying level of > abstraction (e.g., blinding scalarmul could make the nonce bigger than > the prime order subgroup size `n`, and the specific scalarmul > implementation must guarantee that its scalar input is less than `n` to > compute correctly, so it has a special branch to be robust and handle > bigger scalars coming from blinding, creating a magnifying lens for an > attacker when the branch is taken, as that says something on the > probability of the high order bits of the scalar being set)? > This might seem as having nothing to do with the semantics of > `blinding=yes`, but it does for providers like ours where we apply > blinding at top abstraction layer (and in the case of certain paths also > in strategic points in the second layer) but then have a number of > different sub-algorithm implementations that behave very differently: > depending on the curve name (and encoding format when parsing a key) you > might end up in the generic prime/binary curves implementation, or in > one of the specific ones like nistz256 or nistp521. > > Applying `blinding=yes` like this: > > ```c > {"ECDSA","provider=default,blinding=yes",ossl_ecdsa_signature_functions} > ``` > > is already making the semantics of the `blinding` property ill-defined, > and affecting its effectiveness/purpose as a decision mechanism to be > exposed to users: we have different codepaths under the same umbrella > flagged as applying blinding, but even within it that blinding has very > different shades of "yes". > > As @t8m said "Security is not a boolean value" and my point here is that > neither is `blinding` or `consttime` and similar: they come in shades > (even the `formally_verified` one: maybe the EC layer is formally > verified by tools, but the underlying FF module might come with > different guarantees, etc.) and the threshold by which SOTA deems the > quality to become "yes*" or "no*" changes over time (e.g., it was fine > to only blind scalarmul yesterday, so implementation X was considered as > a blinding implementation, but today also modinv blinding is required so > the same implementation X is now deemed non-blinding). > > Alternative > ----------- > > Support for the specific `RSA_FLAG_BLINDING`&co functionality could > instead just be dropped. > My understanding is that its usefulness is already limited to legacy > compatibility with engines which anyway would not play nicely with the > new provider/core architecture. > > More in general, as a mechanism to select secure implementations if > there are insecure ones present as well, the problem can already be > solved applying the "know your providers" mantra in combination with the > use of the `provider=default`, `provider=provX` properties to pick > across the offerings of multiple providers. > > This wouldn't cover the use case (is this even supported/tested right > now?) of a single provider registering the same algorithm twice with > different alternative implementations and properties: in this case > though it would be possible to use a property definition local to the > specific provider version, and its documentation would inform the users > of how to use propquery to select what and the related conditions and > caveats. Luckily this last case does not affect our implementations, as > we don't offer competing algorithms at the provider level. > > Although I wouldn't propose to do it, if we really really wanted to > retain the functionality of `RSA_FLAG_BLINDING` and have > algorithms exposing knobs with the capability of turning on/off (or > 1000/500/0) whatever degree of blinding they support, we could achieve > this with existing ctrls/params as we do for many other tunable knobs. > Using ctrls/params over doing this on a propquery level has the > advantage that the definition/semantics can be scoped with more > granularity than offered at the provider level. > As a user/sysadmin, if I have done the evaluation of the specific > context that could lead me to responsibly decide to pick no-blinding, > no-consttime, no-secure or similar hazardous choices, I would expect to > be anyway in a situation where I have so much control over my > system, software and environment that patching the code to pass a param > or call a ctrl function deeply inside my application shouldn't be a > blocker at all. > > Summary > ------- > > I am opposed to merging PR#14759 for several reasons: > > - it lends itself to insecure-by-default patterns, repeating mistakes > from the past > - the validity scope for similar properties is somewhat limited to a > single provider version, so its effectiveness against its purpose of > being a selection mechanism for users to pick among competing > algorithms offered by different providers is limited (and has the > potential to hunt us back in the future) > - its definition and semantics are vague, its applicability as an > algorithm property too coarse to be well-defined even inside our own > providers > - `secure`, `blinding`, `consttime`, etc. are not boolean properties of > algorithms (even if I really wish they could be) > - it's one more vague concept for everyone to understand, and one more > item with not-too-clear logic for the project to handle and maintain > for the foreseeable future > - we have already established alternatives in the form of > per-implementation params or ctrls to tune some security parameters > that can alter the execution flow of our implementations > > Also, from a more generic usability perspective and thinking of > supporting those in our Community developing 3rd party providers, I > think we should also > > - [in the vote] take a position on what are good/bad ideas when devising > provider-specific properties, and have some official guidelines in the > documentation about it by the time final 3.0.0 is release, and > - [not in the vote, could be a separate discussion] document what > mechanisms we plan to put in place to coordinate efforts > which will allow for some carefully evaluated properties to have > well-defined semantics (with versioning?) across providers/vendors > (some form of registry of properties, with well-defined criteria for > maintaining it?) > > Proposed vote text > ================== > > Do not merge PR#14759, prevent declaring properties similar to > `blinding=yes` or `consttime=yes` in our implementations and > discourage 3rd parties from adopting similar designs. > > > > > Please provide feedback on the vote text, I would like to open the vote > on Monday and have some public debate about its points via the list > rather then compress it on the OTC meeting which already has enough > items in agenda! > > Thanks, > > Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Apr 9 07:44:25 2021 From: matt at openssl.org (Matt Caswell) Date: Fri, 9 Apr 2021 08:44:25 +0100 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: Message-ID: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> On 08/04/2021 18:02, Nicola Tuveri wrote: > Proposed vote text > ================== > > ? ? Do not merge PR#14759, prevent declaring properties similar to > ? ? `blinding=yes` or `consttime=yes` in our implementations and > ? ? discourage 3rd parties from adopting similar designs. I think this vote tries to cover too much ground in a single vote. I would prefer to see a simple vote of "Do not merge PR#14759" *possibly* followed up by separate votes on what our own policies should be for provider implementations, and what we should or should not encourage 3rd parties to do. Matt From tomas at openssl.org Fri Apr 9 07:53:37 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 09 Apr 2021 09:53:37 +0200 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> References: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> Message-ID: On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > Proposed vote text > > ================== > > > > Do not merge PR#14759, prevent declaring properties similar to > > `blinding=yes` or `consttime=yes` in our implementations and > > discourage 3rd parties from adopting similar designs. > > I think this vote tries to cover too much ground in a single vote. I > would prefer to see a simple vote of "Do not merge PR#14759" > *possibly* > followed up by separate votes on what our own policies should be for > provider implementations, and what we should or should not encourage > 3rd > parties to do. I disagree partially. IMO we should primarily have a policy vote and the closing or merging of PR#14759 should come out of it naturally. -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From nic.tuv at gmail.com Fri Apr 9 11:24:13 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 9 Apr 2021 14:24:13 +0300 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> Message-ID: I agree with what Tom?? said, and that is the reason why I convoluted them in a single vote: we need to merge or reject the PR based on a policy, but if we do 2 separate votes we risk to create delays in the already quite loaded development cycles left! Nicola On Fri, Apr 9, 2021, 10:53 Tomas Mraz wrote: > On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > > Proposed vote text > > > ================== > > > > > > Do not merge PR#14759, prevent declaring properties similar to > > > `blinding=yes` or `consttime=yes` in our implementations and > > > discourage 3rd parties from adopting similar designs. > > > > I think this vote tries to cover too much ground in a single vote. I > > would prefer to see a simple vote of "Do not merge PR#14759" > > *possibly* > > followed up by separate votes on what our own policies should be for > > provider implementations, and what we should or should not encourage > > 3rd > > parties to do. > > I disagree partially. IMO we should primarily have a policy vote and > the closing or merging of PR#14759 should come out of it naturally. > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Fri Apr 9 11:27:07 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Fri, 9 Apr 2021 14:27:07 +0300 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> Message-ID: But I am not opposed to separate the 2 votes if that is perceived as better and we are ready to deal with the possible delays introduced in the development. I am not entirely sure if this PR can be retriaged by OTC as not-blocking for the beta release, but that could also be an option to buy more time while we define a policy and then vote to accept or reject based on that. Nicola On Fri, Apr 9, 2021, 14:24 Nicola Tuveri wrote: > I agree with what Tom?? said, and that is the reason why I convoluted them > in a single vote: we need to merge or reject the PR based on a policy, but > if we do 2 separate votes we risk to create delays in the already quite > loaded development cycles left! > > Nicola > > On Fri, Apr 9, 2021, 10:53 Tomas Mraz wrote: > >> On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: >> > >> > On 08/04/2021 18:02, Nicola Tuveri wrote: >> > > Proposed vote text >> > > ================== >> > > >> > > Do not merge PR#14759, prevent declaring properties similar to >> > > `blinding=yes` or `consttime=yes` in our implementations and >> > > discourage 3rd parties from adopting similar designs. >> > >> > I think this vote tries to cover too much ground in a single vote. I >> > would prefer to see a simple vote of "Do not merge PR#14759" >> > *possibly* >> > followed up by separate votes on what our own policies should be for >> > provider implementations, and what we should or should not encourage >> > 3rd >> > parties to do. >> >> I disagree partially. IMO we should primarily have a policy vote and >> the closing or merging of PR#14759 should come out of it naturally. >> >> -- >> Tom?? Mr?z >> No matter how far down the wrong road you've gone, turn back. >> Turkish proverb >> [You'll know whether the road is wrong if you carefully listen to your >> conscience.] >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pauli at openssl.org Fri Apr 9 11:52:44 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Fri, 9 Apr 2021 21:52:44 +1000 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> Message-ID: We don't need a vote on the PR. If we make the policy vote, it would be against policy to include it. Pauli On 9/4/21 9:24 pm, Nicola Tuveri wrote: > I agree with what Tom?? said, and that is the reason why I convoluted > them in a single vote: we need to merge or reject the PR based on a > policy, but if we do 2 separate votes we risk to create delays in the > already quite loaded development cycles left! > > Nicola > > On Fri, Apr 9, 2021, 10:53 Tomas Mraz > wrote: > > On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > > Proposed vote text > > > ================== > > > > > >? ? ? Do not merge PR#14759, prevent declaring properties > similar to > > >? ? ? `blinding=yes` or `consttime=yes` in our implementations and > > >? ? ? discourage 3rd parties from adopting similar designs. > > > > I think this vote tries to cover too much ground in a single > vote. I > > would prefer to see a simple vote of "Do not merge PR#14759" > > *possibly* > > followed up by separate votes on what our own policies should be > for > > provider implementations, and what we should or should not encourage > > 3rd > > parties to do. > > I disagree partially. IMO we should primarily have a policy vote and > the closing or merging of PR#14759 should come out of it naturally. > > -- > Tom?? Mr?z > No matter how far down the wrong road you've gone, turn back. > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Fri Apr 9 14:32:18 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 09 Apr 2021 16:32:18 +0200 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> Message-ID: <36f3ca34a51012de1f772c03911ce905342896d7.camel@openssl.org> I do not think we should retriage this. There needs to be just a policy vote. Depending on the policy vote outcome the PR will have to be either: - merged if the policy vote does not pass or passes and the PR does not conflict with it - dropped if the policy vote passes and says that we do not want any information on blinding in form of a property - adjusted and merged if the policy vote passes and says that we want some information on blinding in form of a property but it needs to be done differently (such as having no-blinding property or whatever) The policy vote should happen before beta1. The eventual rework should not take much time so I do not worry about that. Implicitly, if the vote passes and says we do not want blinding property in any form, the original issue as triaged by OTC will be closed. There is no need for extra decision making process on that. Tomas On Fri, 2021-04-09 at 14:27 +0300, Nicola Tuveri wrote: > But I am not opposed to separate the 2 votes if that is perceived as > better and we are ready to deal with the possible delays introduced > in the development. > > I am not entirely sure if this PR can be retriaged by OTC as not- > blocking for the beta release, but that could also be an option to > buy more time while we define a policy and then vote to accept or > reject based on that. > > Nicola > > On Fri, Apr 9, 2021, 14:24 Nicola Tuveri wrote: > > I agree with what Tom?? said, and that is the reason why I > > convoluted them in a single vote: we need to merge or reject the PR > > based on a policy, but if we do 2 separate votes we risk to create > > delays in the already quite loaded development cycles left! > > > > Nicola > > > > On Fri, Apr 9, 2021, 10:53 Tomas Mraz wrote: > > > On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > > > > > > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > > > > Proposed vote text > > > > > ================== > > > > > > > > > > Do not merge PR#14759, prevent declaring properties > > > similar to > > > > > `blinding=yes` or `consttime=yes` in our implementations > > > and > > > > > discourage 3rd parties from adopting similar designs. > > > > > > > > I think this vote tries to cover too much ground in a single > > > vote. I > > > > would prefer to see a simple vote of "Do not merge PR#14759" > > > > *possibly* > > > > followed up by separate votes on what our own policies should > > > be for > > > > provider implementations, and what we should or should not > > > encourage > > > > 3rd > > > > parties to do. > > > > > > I disagree partially. IMO we should primarily have a policy vote > > > and > > > the closing or merging of PR#14759 should come out of it > > > naturally. > > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tomas at openssl.org Fri Apr 9 14:33:51 2021 From: tomas at openssl.org (Tomas Mraz) Date: Fri, 09 Apr 2021 16:33:51 +0200 Subject: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties) In-Reply-To: References: <5bef5836-b36f-70fc-e32a-2b6d719af63c@openssl.org> Message-ID: <6f5ed82c875526840664e90f7cdcf49371cbc8db.camel@openssl.org> There is no need to have 2 votes. We'll just vote on the policy and the PR close/rework/whatever comes out of the policy vote. On Fri, 2021-04-09 at 14:24 +0300, Nicola Tuveri wrote: > I agree with what Tom?? said, and that is the reason why I convoluted > them in a single vote: we need to merge or reject the PR based on a > policy, but if we do 2 separate votes we risk to create delays in the > already quite loaded development cycles left! > > Nicola > > On Fri, Apr 9, 2021, 10:53 Tomas Mraz wrote: > > On Fri, 2021-04-09 at 08:44 +0100, Matt Caswell wrote: > > > > > > On 08/04/2021 18:02, Nicola Tuveri wrote: > > > > Proposed vote text > > > > ================== > > > > > > > > Do not merge PR#14759, prevent declaring properties > > similar to > > > > `blinding=yes` or `consttime=yes` in our implementations > > and > > > > discourage 3rd parties from adopting similar designs. > > > > > > I think this vote tries to cover too much ground in a single > > vote. I > > > would prefer to see a simple vote of "Do not merge PR#14759" > > > *possibly* > > > followed up by separate votes on what our own policies should be > > for > > > provider implementations, and what we should or should not > > encourage > > > 3rd > > > parties to do. > > > > I disagree partially. IMO we should primarily have a policy vote > > and > > the closing or merging of PR#14759 should come out of it naturally. > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From tomas at openssl.org Tue Apr 20 10:15:19 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 20 Apr 2021 12:15:19 +0200 Subject: OTC VOTE: Set issue 11164 milestone to Post 3.0 Message-ID: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> topic: Set issue 11164 milestone to Post 3.0 Proposed by Tim Hudson Public: yes opened: 2021-04-20 closed: 2021-04-20 accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) Matt [+1] Mark [ ] Pauli [ ] Viktor [ ] Tim [+1] Richard [+1] Shane [+1] Tomas [+1] Kurt [ ] Matthias [+1] Nicola [-1] From tomas at openssl.org Tue Apr 20 10:17:17 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 20 Apr 2021 12:17:17 +0200 Subject: OTC VOTE: Set PR 13817 milestone to Post 3.0 Message-ID: <6c96e71b0ceb9a60701e63b940cb4271dfff0dea.camel@openssl.org> topic: Set PR 13817 milestone to Post 3.0 Proposed by Tim Hudson Public: yes opened: 2021-04-20 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ 0] Mark [ ] Pauli [ ] Viktor [ ] Tim [+1] Richard [ 0] Shane [+1] Tomas [ 0] Kurt [ ] Matthias [ 0] Nicola [ 0] From tomas at openssl.org Tue Apr 20 10:17:57 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 20 Apr 2021 12:17:57 +0200 Subject: OTC VOTE: Set issue 11164 milestone to Post 3.0 In-Reply-To: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> References: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> Message-ID: <7c114f6a716e640fde40e02d1531ca9df0285485.camel@openssl.org> The vote has been closed already during the meeting. On Tue, 2021-04-20 at 12:15 +0200, Tomas Mraz wrote: > topic: Set issue 11164 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-04-20 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [+1] > Nicola [-1] > > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From nic.tuv at gmail.com Tue Apr 20 10:23:56 2021 From: nic.tuv at gmail.com (Nicola Tuveri) Date: Tue, 20 Apr 2021 13:23:56 +0300 Subject: OTC VOTE: Reject PR#14759 Message-ID: Following up on https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html we had a discussion on this during last week OTC meeting, and opened a vote limited exclusively to the matter of rejecting PR#14759. We lost the record of the votes collected during the call, so opening it officially today with a clean slate. ---------------- topic: Reject PR#14759 Proposed by Nicola Tuveri Public: yes opened: 2021-04-20 closed: 2021-mm-dd accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) Matt [ ] Mark [ ] Pauli [ ] Viktor [ ] Tim [ ] Richard [ ] Shane [ ] Tomas [ ] Kurt [ ] Matthias [ ] Nicola [+1] -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomas at openssl.org Tue Apr 20 10:47:52 2021 From: tomas at openssl.org (Tomas Mraz) Date: Tue, 20 Apr 2021 12:47:52 +0200 Subject: OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: <7067e593d9cbe1f12957d6e1dea3110c743b4007.camel@openssl.org> -1 On Tue, 2021-04-20 at 13:23 +0300, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html > we had a discussion on this during last week OTC meeting, and opened > a vote limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening > it officially today with a clean slate. > -- Tom?? Mr?z No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.] From pauli at openssl.org Tue Apr 20 23:05:01 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 21 Apr 2021 09:05:01 +1000 Subject: OTC VOTE: Set PR 13817 milestone to Post 3.0 In-Reply-To: <6c96e71b0ceb9a60701e63b940cb4271dfff0dea.camel@openssl.org> References: <6c96e71b0ceb9a60701e63b940cb4271dfff0dea.camel@openssl.org> Message-ID: +0 On 20/4/21 8:17 pm, Tomas Mraz wrote: > topic: Set PR 13817 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ 0] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [+1] > Richard [ 0] > Shane [+1] > Tomas [ 0] > Kurt [ ] > Matthias [ 0] > Nicola [ 0] > > From pauli at openssl.org Tue Apr 20 23:05:14 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 21 Apr 2021 09:05:14 +1000 Subject: OTC VOTE: Set issue 11164 milestone to Post 3.0 In-Reply-To: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> References: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> Message-ID: +1 On 20/4/21 8:15 pm, Tomas Mraz wrote: > topic: Set issue 11164 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-04-20 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) > > Matt [+1] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [+1] > Richard [+1] > Shane [+1] > Tomas [+1] > Kurt [ ] > Matthias [+1] > Nicola [-1] > > From pauli at openssl.org Tue Apr 20 23:06:52 2021 From: pauli at openssl.org (Dr Paul Dale) Date: Wed, 21 Apr 2021 09:06:52 +1000 Subject: OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: -0 Pauli On 20/4/21 8:23 pm, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html > > we had a discussion on this during last week OTC meeting, and opened a > vote limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening > it officially today with a clean slate. > > > ---------------- > topic: Reject PR#14759 > Proposed by Nicola Tuveri > Public: yes > opened: 2021-04-20 > closed: 2021-mm-dd > accepted: ?yes/no ?(for: X, against: Y, abstained: Z, not voted: T) > ? Matt ? ? ? [ ?] > ? Mark ? ? ? [ ?] > ? Pauli ? ? ?[ ?] > ? Viktor ? ? [ ?] > ? Tim ? ? ? ?[ ?] > ? Richard ? ?[ ?] > ? Shane ? ? ?[ ?] > ? Tomas ? ? ?[ ?] > ? Kurt ? ? ? [ ?] > ? Matthias ? [ ?] > ? Nicola ? ? [+1] > > From tjh at cryptsoft.com Tue Apr 20 23:17:05 2021 From: tjh at cryptsoft.com (Tim Hudson) Date: Wed, 21 Apr 2021 09:17:05 +1000 Subject: OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: On the call the votes were very clear to accept the PR (not reject it). So I'm again rejecting the request to reject the PR - it would be better to express such votes in positive terms. -1 Tim. On Wed, Apr 21, 2021 at 9:06 AM Dr Paul Dale wrote: > -0 > > Pauli > > On 20/4/21 8:23 pm, Nicola Tuveri wrote: > > Following up on > > https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html > > > > > we had a discussion on this during last week OTC meeting, and opened a > > vote limited exclusively to the matter of rejecting PR#14759. > > > > We lost the record of the votes collected during the call, so opening > > it officially today with a clean slate. > > > > > > ---------------- > > topic: Reject PR#14759 > > Proposed by Nicola Tuveri > > Public: yes > > opened: 2021-04-20 > > closed: 2021-mm-dd > > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > > Matt [ ] > > Mark [ ] > > Pauli [ ] > > Viktor [ ] > > Tim [ ] > > Richard [ ] > > Shane [ ] > > Tomas [ ] > > Kurt [ ] > > Matthias [ ] > > Nicola [+1] > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Apr 21 09:46:36 2021 From: matt at openssl.org (Matt Caswell) Date: Wed, 21 Apr 2021 10:46:36 +0100 Subject: OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: <78e508d2-7ad0-a30d-f901-f15355962238@openssl.org> 0 On 20/04/2021 11:23, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html > > we had a discussion on this during last week OTC meeting, and opened a > vote limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it > officially today with a clean slate. > > > ---------------- > topic: Reject PR#14759 > Proposed by Nicola Tuveri > Public: yes > opened: 2021-04-20 > closed: 2021-mm-dd > accepted: ?yes/no ?(for: X, against: Y, abstained: Z, not voted: T) > ? Matt ? ? ? [ ?] > ? Mark ? ? ? [ ?] > ? Pauli ? ? ?[ ?] > ? Viktor ? ? [ ?] > ? Tim ? ? ? ?[ ?] > ? Richard ? ?[ ?] > ? Shane ? ? ?[ ?] > ? Tomas ? ? ?[ ?] > ? Kurt ? ? ? [ ?] > ? Matthias ? [ ?] > ? Nicola ? ? [+1] > > From shane.lontis at oracle.com Wed Apr 21 10:01:25 2021 From: shane.lontis at oracle.com (SHANE LONTIS) Date: Wed, 21 Apr 2021 20:01:25 +1000 Subject: [External] : OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: <36892421-EA3C-4E1E-AA0B-0F1E95FFA491@oracle.com> +1 Shane > On 20 Apr 2021, at 8:23 pm, Nicola Tuveri wrote: > > Following up on https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html we had a discussion on this during last week OTC meeting, and opened a vote limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it officially today with a clean slate. > > > ---------------- > topic: Reject PR#14759 > Proposed by Nicola Tuveri > Public: yes > opened: 2021-04-20 > closed: 2021-mm-dd > accepted: yes/no (for: X, against: Y, abstained: Z, not voted: T) > Matt [ ] > Mark [ ] > Pauli [ ] > Viktor [ ] > Tim [ ] > Richard [ ] > Shane [ ] > Tomas [ ] > Kurt [ ] > Matthias [ ] > Nicola [+1] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Apr 22 14:03:29 2021 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Apr 2021 14:03:29 +0000 Subject: OpenSSL version 3.0.0-alpha15 published Message-ID: <20210422140329.GA25386@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 3.0 alpha 15 released ===================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 3.0 is currently in alpha. OpenSSL 3.0 alpha 15 has now been made available. Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. Specific notes on upgrading to OpenSSL 3.0 from previous versions, as well as known issues are available on the OpenSSL Wiki, here: https://wiki.openssl.org/index.php/OpenSSL_3.0 The alpha release is available for download via HTTPS and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-3.0.0-alpha15.tar.gz Size: 14423249 SHA1 checksum: 57be66515f808b77d5b163a55474801f8bd764f4 SHA256 checksum: 7ebc12910a19d94c13ce589024c5ab655a81152823fe37a3b5753436f3706831 The checksums were calculated using the following commands: openssl sha1 openssl-3.0.0-alpha15.tar.gz openssl sha256 openssl-3.0.0-alpha15.tar.gz Please download and check this alpha release as soon as possible. To report a bug, open an issue on GitHub: https://github.com/openssl/openssl/issues Please check the release notes and mailing lists to avoid duplicate reports of known issues. (Of course, the source is also available on GitHub.) Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmCBfbIACgkQ2cTSbQ5g RJEHcAf+MXdyMT9BzBSoEjQdcXfwWDjl7r8R6dXinaI9BIvN80qf1HHGEy5thMc7 lu5IPLF4iz61B1s8h37WtqksZpC+Ydjbw++LyUDVUfJBWYE0XRGuK+FljN+vESmX +yqnv/Ll3lSce6HCFlWQDMp16Os8sCWl4DqaUOqsCo1Pi0ArLigNIwf1lmp0/FC8 d7vCp9jSTq9fvG33L0tbIZ6X6YdD9tiWh+Ae8IDMDli4BVTixgrf6Mqa8vrC6JZu PWhlTuq/KZq4TjLdVPWsVC55MBItesGgYIDCOcefwSWaWfVk1WZF/ojbMBkpBWc1 BprBrZjgnoqQrtsqVVTD7dgfY5atRA== =0woP -----END PGP SIGNATURE----- From kurt at roeckx.be Thu Apr 22 21:27:16 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 22 Apr 2021 23:27:16 +0200 Subject: OTC VOTE: Set issue 11164 milestone to Post 3.0 In-Reply-To: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> References: <99c3e5023838fee510ac850e7676d33cdfc7fa5b.camel@openssl.org> Message-ID: On Tue, Apr 20, 2021 at 12:15:19PM +0200, Tomas Mraz wrote: > topic: Set issue 11164 milestone to Post 3.0 > Proposed by Tim Hudson > Public: yes > opened: 2021-04-20 > closed: 2021-04-20 > accepted: yes (for: 6, against: 1, abstained: 0, not voted: 4) -1 Kurt From kurt at roeckx.be Thu Apr 22 21:28:53 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 22 Apr 2021 23:28:53 +0200 Subject: OTC VOTE: Set PR 13817 milestone to Post 3.0 In-Reply-To: <6c96e71b0ceb9a60701e63b940cb4271dfff0dea.camel@openssl.org> References: <6c96e71b0ceb9a60701e63b940cb4271dfff0dea.camel@openssl.org> Message-ID: On Tue, Apr 20, 2021 at 12:17:17PM +0200, Tomas Mraz wrote: > topic: Set PR 13817 milestone to Post 3.0 0 Kurt From kurt at roeckx.be Thu Apr 22 21:30:10 2021 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 22 Apr 2021 23:30:10 +0200 Subject: OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: On Tue, Apr 20, 2021 at 01:23:56PM +0300, Nicola Tuveri wrote: > Following up on > https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html we > had a discussion on this during last week OTC meeting, and opened a vote > limited exclusively to the matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it > officially today with a clean slate. > > > ---------------- > topic: Reject PR#14759 +1 Kurt From levitte at openssl.org Tue Apr 27 08:22:32 2021 From: levitte at openssl.org (Richard Levitte) Date: Tue, 27 Apr 2021 10:22:32 +0200 Subject: OTC VOTE: Reject PR#14759 In-Reply-To: References: Message-ID: <87a6pknnlj.wl-levitte@openssl.org> 0 On Tue, 20 Apr 2021 12:23:56 +0200, Nicola Tuveri wrote: > > Following up on?https://www.mail-archive.com/openssl-project at openssl.org/msg02407.html we had a > discussion on this during last week OTC meeting, and opened a vote limited exclusively to the > matter of rejecting PR#14759. > > We lost the record of the votes collected during the call, so opening it officially today with a > clean slate. > > ---------------- > topic: Reject PR#14759 > Proposed by Nicola Tuveri > Public: yes > opened: 2021-04-20 > closed: 2021-mm-dd > accepted: ?yes/no ?(for: X, against: Y, abstained: Z, not voted: T) > ? Matt ? ? ? [ ?] > ? Mark ? ? ? [ ?] > ? Pauli ? ? ?[ ?] > ? Viktor ? ? [ ?] > ? Tim ? ? ? ?[ ?] > ? Richard ? ?[ ?] > ? Shane ? ? ?[ ?] > ? Tomas ? ? ?[ ?] > ? Kurt ? ? ? [ ?] > ? Matthias ? [ ?] > ? Nicola ? ? [+1] > > -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/