Conceptual feedback on new ECC JEP

[Adam Petcher]

See inline below.

It also occurred to me that we could use Provider properties here. We 
have the "ImplementedIn" property, and we can similarly add a standard 
"Branchless" property. I think my preferred solution is still to use 
separate providers, and perhaps use a read-only "Branchless" property to 
aid in provider selection. That is, JCA client code that supports the 
branchless API (that is, no BigInteger) could loop through the providers 
until it finds one with the "Branchless" property set. This same 
mechanism could be used to select a provider that allows branching in an 
environment where the highest-priority provider is branchless.

We may also be able to set the "Branchless" property at runtime to 
influence the behavior of a single provider. But this would introduce a 
lot of complication, and I think it is starting to get away from the 
intended use of these properties.

On 9/7/2018 7:07 PM, Anthony Scarpino wrote:

>> On Sep 7, 2018, at 12:08 PM, Adam Petcher <adam.petcher at oracle.com> wrote:
>>
>> This is a good suggestion. I don't have particularly strong feelings about using separate providers vs a property in a single provider. I think the fundamental issues are the same, and this choice mostly affects API details.
>>
>> Do you think this should be a system property, security property, or something else? Should it be modifiable at any time?
> I would say a security property
>
>> Perhaps it has to be in order to address Mike's desire to put the provider in "import/export mode". Would the property affect existing keys? Again, I think it would have to, so you can generate a key, turn off branchless mode, and then export it.
> My thought was the property would allow the branchless import/export for that java instance.   Not turning it on and off during operations.  I think the value of the branchless operation is in the usage of the algorithms. If an app wants to use a pure branchless provider the property can be set or never use the APIs with BigInteger in them.
>
> One could avoid the property completely by just documenting clearly the interfaces that branched and then leave it to the app developer, but from the email discussion with Mike it sounded like you preferred strong controls on the provider.

The issues related to branching are too subtle, and I don't think we 
should expose any of it to the developer except "use this 
provider/property/algorithm to indicate that branching on secrets is 
unacceptable." Moreover, I'm intimately familiar with all of these 
issue, and yet I still don't have confidence in my own ability to switch 
SunJSSE over to using a branchless ECC implementation, unless I have 
strong enforcement in the provider. It would be too easy for me to 
simply miss an existing call to getS() or a use of ECPrivateKeySpec.

If we only have a single provider, and a security property that has been 
set to indicate that branching is unacceptable in that provider, then I 
think that means that there is no way to change the value of the 
property and use private keys as BigInteger in that JVM process without 
using some other (third party) provider. Though maybe I'm 
misunderstanding something about your proposal.

>
>> What about curves other than P256, P384, and P521? We can't do branchless operations in those curves, so any attempt to use them when this property is enabled would result in an exception.
> I wasn’t going to propose anything further than your existing curves, but it would be nice if branchful curves could be added to eventual replace SunEC.  I know that isn’t the intent of this JEP and depends if you want to expand it.

Sure, but for this JEP, we need to be concerned about how the API can be 
misused, and a branching implementation is obtained when a branchless 
one is expected. The developer shouldn't be expected to know that three 
of the curves have branchless implementations, and using any other curve 
will result in branching. So any global "don't branch" property would 
need to cause the use of any other curve to fail.