Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Tomas Mraz]

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.]

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Tomas Mraz]

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.]

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Dr Paul Dale]

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.]

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Nicola Tuveri]

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.]
>>
>>
>>

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Nicola Tuveri]

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.]
>
>
>

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Tomas Mraz]

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.]

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Matt Caswell]

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

Re: [External] : Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[SHANE LONTIS]

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, ISOx_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 

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Nicola Tuveri]

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, ISOx_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 

Re: [OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Tim Hudson]

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 

[OTC VOTE PROPOSAL] Don't merge PR#14759 (blinding=yes and similar properties)

[Nicola Tuveri]

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,