RFD: Security Providers Filter (JEP)

[Sean Mullan]

Hi Martin,

 > We reviewed the full text and found no other changes to be made for now.
 > We are working in splitting the PR into two, so the refactoring for
 > class Provider and bug fixes can make their way first.

I think this is a good plan. Do you plan to decouple the refactoring 
from the JEP and propose it under a different issue? I think that would 
make the most sense as long as the refactoring has no direct 
dependencies on the JEP.

 > Any other comments about the JEP?

We have been very busy with JDK 24 deliverables. Let's sync up again on 
the JEP after RDP1.

--Sean

On 11/26/24 5:52 PM, Martin Balao wrote:
> Hello Sean,
> 
> We've made the following adjustments to the JEP [1]:
> 
> 1) Paragraphs starting with "When a security provider is installed..." 
> and "The filter applies to services..." replaced with paragraphs 
> starting with "The filter applies to services..." and "Each service is 
> evaluated by...". The purpose of this change was to better describe the 
> multi-layer filtering strategy. We fixed a minor error in the description.
> 
> 2) In Non-Goals, we clarified that characters are reserved in the syntax 
> (i.e. ":" and ",") with the purpose of extending the filter in the 
> future to provide more granularity in services selection: "(...) With 
> that said, extensions to this proposal may be explored in the future and 
> characters such as `:` and `,` will be reserved in the filter syntax for 
> this purpose.".
> 
> 3) Sub-section "Filtering at the ::getInstance API level only" added to 
> the Alternatives discussion.
> 
> 4) Sub-section "Leveraging on the existing 
> java.security.Provider::configure API to configure security providers" 
> added to the Alternatives discussion.
> 
> We reviewed the full text and found no other changes to be made for now. 
> We are working in splitting the PR into two, so the refactoring for 
> class Provider and bug fixes can make their way first.
> 
> Any other comments about the JEP?
> 
> Thanks,
> Martin.-
> 
> -- 
> [1] - https://bugs.openjdk.org/browse/JDK-8325511
> 
> 
> 
> On 10/18/24 14:55, Martin Balao wrote:
>> Hello Sean,
>>
>> On 9/19/24 12:00, Sean Mullan wrote:
>>> Hi Martin,
>>>
>>> Our team at Oracle has done another review of the proposed feature 
>>> and we have some questions that we would like to discuss below.
>>>
>>> This is a significant effort that would add some valuable features to 
>>> the Security Provider mechanism. However, this is also modifying an 
>>> important core function used by all JCA/JCE APIs to locate 
>>> implementations, so we want to make sure we spend the time to review 
>>> all aspects of the proposal thoroughly.
>>>
>>
>> Thanks for reviewing our proposal. We totally understand and are happy 
>> to have such a thorough review. It is in the best interest of the 
>> whole community and us to get this right.
>>
>>> - The current implementation introduces behavior changes in the 
>>> Provider API which we believe would need to be specified in the 
>>> specification. For example, if an application registers a service 
>>> that is restricted by   the filter using the Provider API, then that 
>>> service won't be returned by methods such as Provider.getServices(). 
>>> This is a behavior change in the API. I don't think it could be 
>>> specified as an implementation note, since it changes the specified 
>>> behavior of these methods.
>>>
>>> Adding specification changes will make any backport much more 
>>> difficult, if that was one of your goals.
>>
>> We agree that our proposal affects the behavior of 
>> Provider::getService(s) APIs and that a specification change is 
>> required. We are aware of this extra complexity but, in the interest 
>> of having the best solution possible for the long term, are willing to 
>> have the discussion. Our expectation is to have the Filter included in 
>> JDK 25 and have no plans for backports to earlier releases. With that 
>> said, if it takes longer to integrate the Filter into JDK main line, 
>> we will still be interested in a backport to JDK 25.
>>
>>>
>>> - Did you consider implementing the filtering mechanism at a higher 
>>> layer, in the getInstance methods? This could possibly avoid the 
>>> specification concerns above, as the behavior could potentially be 
>>> added as implementation notes in the getInstance methods, similar to 
>>> the implementation note for the jdk.security.provider.preferred 
>>> Security property.
>>
>> Yes, we considered that option. We just noticed that it is not in the 
>> Alternatives segment of the JEP. We will add it in the coming days. 
>> Being ::getInstance a public API and the Filter altering its behavior 
>> in terms of what is returned, we'd rather handle this alternative as a 
>> specification change as well. In any case, the main reason why we 
>> opted for filtering at the Service level is to handle any service type 
>> in a uniform and consistent way, including service types defined by 
>> 3rd-party applications/libraries/providers. Having taken 
>> the ::getInstance path, we would have had to either not support 3rd- 
>> party service types or create a new public API in the Filter to query 
>> whether a service is allowed or denied. This approach would have 
>> opened the door for flaws or inconsistencies in how 3rd-party 
>> implementations handle Filter decisions. Besides this, we thought that 
>> obtaining a service instance with Provider::getService(s) that cannot 
>> be obtained and used by ::getInstance could introduce some confusion. 
>> This would have had an impact not only programmatically but in - 
>> XshowSettings:security:providers.
>>
>>>
>>> - The syntax doesn't currently support key size constraints, or 
>>> algorithm constraints that are not specified in algorithm names, such 
>>> as the parameters used with the RSASSA-PSS algorithm. How would you 
>>> add support for these in the future?
>>>
>>
>> We reserved the colon (:) and comma (,) characters in the syntax for 
>> this purpose. As these characters must be escaped, we can extend the 
>> syntax in the future to allow further constraints (e.g. key size, 
>> algorithm constraints) in a backward-compatible way.
>>
>> We added the following reference in the JEP:
>>
>> "In addition, identifying services with a granularity finer than an 
>> algorithm name or alias (e.g. based on key size or other algorithm 
>> parameters) is not under the scope at this time. With that said, 
>> extensions to this proposal may be explored in the future and 
>> characters will be reserved in the filter syntax for this purpose."
>>
>> We also mentioned the full list of reserved characters:
>>
>> "The following characters, when part of one of the listed levels, must 
>> be escaped by prepending a '\' character: '!', '*', ' ' (white space), 
>> '.', ';', '\', ':' and ','."
>>
>> We did not connect the two references by matching the concept of finer 
>> granularity with the reserved characters for that purpose. We can add 
>> a loose connection. However, we prefer not to prescribe the exact 
>> syntax now as it is a non-goal and would require further analysis and 
>> to explore implementations.
>>
>> One thing to consider here is that the use of one of the reserved 
>> characters (e.g. ':') can open the door for an extension of the syntax 
>> with new reserved tokens and characters. For example: 
>> SunJCE.Cipher.AES : keySize > 128. In this case, '>' does not need to 
>> be reserved for the provider name, service type or algorithm. For the 
>> algorithm constraint, 'keySize' and '>' are assigned a specific meaning.
>>
>>> - Does the filtering work for providers that are not registered, and 
>>> just passed into the getInstance methods?
>>>
>>
>> Yes, it does. For most providers, filtering occurs when they invoke 
>> Provider::putService/put APIs. In very rare cases, a Provider may not 
>> invoke Provider::putService/put APIs and still return a Service 
>> overriding Provider::getService(s). In that situation, we filter when 
>> Service::newInstance is invoked. In theory, it is possible that a 
>> Service subclass overrides Service::newInstance. In such extreme 
>> circumstances, we filter at the ::getInstance level. The last case 
>> will not apply to 3rd-party service types, but should be extremely 
>> unlikely.
>>
>>> - Did you consider implementing this as a Provider.configure option? 
>>> There are pros/cons to doing that, but given that the configure 
>>> method is designed to configure providers, we think it should be
>>> considered and described in the Alternatives section.
>>>
>>
>> We did not consider Provider::configure. We will add it to the 
>> Alternatives section if you deem it important. I personally see more 
>> cons than pros but if someone has a different opinion and wants to 
>> advocate for it, we're happy to have a discussion.
>>
>>> -  Would early initialization of the filter inadvertently triggered 
>>> by a cryptographic operation (for example, when verifying a signed 
>>> JAR on the classpath) cause subsequent settings of the filter by an 
>>> application at runtime to be ignored? If so, this is something that 
>>> could easily go undetected, as the filter could be silently ignored 
>>> and thus restrictions not enforced as expected - it may be worth 
>>> considering throwing an exception if you can detect that the property 
>>> has already been set and processed. The logging and debugging 
>>> mechanisms are helpful but I view them as being more useful when 
>>> testing the filter or later debugging of issues.
>>
>> Our understanding is that in such an event the Filter would be 
>> initialized when the ClassLoader does JAR verification. If this is the 
>> case, programmatically defining a Filter in the signed JAR should not 
>> work. @Francisco will create a proof-of-concept to confirm this 
>> hypothesis in the coming days.
>>
>> We agree that throwing an exception in such a case would be ideal. 
>> However, this type of change —as we see it— involves a specification 
>> change in System::setProperty/Security::setProperty as that's the only 
>> interface to set a Filter value programmatically. We are open to 
>> having this discussion.
>>
>> Another alternative would be to reserve the property in 
>> System::setProperty/Security::setProperty and throw an exception 
>> irrespective of the Filter status. We think that setting the Filter 
>> programmatically should not be recommended for general use. However, 
>> this would prevent advanced users that know how things are initialized 
>> from benefiting.
>>
>>>
>>> - Does the additional searching for Cipher transformations cause 
>>> significant performance issues?
>>>
>>
>> We don't think so. When providers register the full "alg/mode/padding" 
>> as algorithm name, transformation queries against the filter are done 
>> at registration time (Provider::putService/put invocation) and cached 
>> in the Service instance. It's true that queries may be done at run 
>> time to explore different transformation combinations 
>> (e.g. ::getInstance of "alg/mode/padding" may explore services that 
>> registered "alg/mode", "alg//padding" and "alg" as algorithm name). 
>> However, these transformation queries are cached per Service instance 
>> after the Filter decision is made. In the worst case —extremely 
>> unlikely—, a provider may register 4 services relevant for the 
>> transformation (e.g. alg/mode/padding, alg/mode, alg//padding and alg) 
>> and the Filter blocks the transformation —if the Filter allows the 
>> transformation, the first service will be used and the others won't be 
>> queried because it is a lazy mechanism—. This case would require 3 
>> queries against the filter —the "alg/mode/padding" decision is read 
>> from the Service's cache— when they are not in the transformations 
>> cache. The reason why the transformation cache is per service and not 
>> per provider is because we include service aliases as part of the query.
>>
>> Regards,
>> Martin and Francisco.-
>