On 9/25/2015 7:42 PM, Simone Bordet wrote:
> Hi,
>
> On Fri, Sep 25, 2015 at 11:47 AM, Xuelei Fan <xuelei....@oracle.com> wrote:
>> Here is the question to answer, which preference should be respected
>> firstly between cipher suite and application protocol? If application
>> protocol are preferred at first, of course, application preference
>> should be respected at first; otherwise, cipher suite preference should
>> be respected at first.
>
> The answer to this question has been decided when the algorithm has
> been chosen to be:
>
> for each cipher
> for each application protocol
> end
> end
>
> All the rest being equal, ciphers dominate application protocol selection.
>
> Are you suggesting to change this to:
>
> for each application protocol
> for each cipher
> end
> end
>
> ?
>
No, I would prefer the first approach. Good, we are at the same page at
this point, I think.
> It's in the hands of the role that configures application protocols
> and ciphers to decide whether it's more important to prefer a protocol
> or a cipher.
>
> Put it in a different way:
>
> If the role prefers application protocols, it has to sort the ciphers
> to influence that.
> If the role prefers ciphers, it has to sort the ciphers.
>
I did not catch the idea. if the tole prefers ciphers, why still need
to sort the ciphers? Sort for what?
> No matter what, it has to sort the ciphers.
>
I did not get your ideas. Who would sort the preferences? and when the
preferences should be sorted?
Maybe, we are not on the same page, I think.
>From the viewpoint of application or library, if an administrator had
made his decision about the preference of application protocols and
cipher suites, applications and OpenJDK may be better to respect the
decision.
// the customers' decision //(1)
String[] cipherSuites = {....}; // customer preference, sorted.
List<ApplicationProtocol> appProtocols =
{...}; // customer preference, sorted.
// configure the parameters // (2)
//
// customer preferences should be respected.
sslParameters.setCipherSuites(cipherSuites);
sslParameters.setApplicationProtocols(appProtocols);
There might be concerns, customers preference may be not right and need
to adjusted. Maybe, a re-order tool is needed before (not after) the
configuration of the parameters.
// the customers' decision // (1)
String[] cipherSuites = {....}; // customer preference
List<ApplicationProtocol> appProtocols =
{...}; // customer preference
+
+ // reorde the cipher suites // (1.1)
+ cipherSuites = ... // the actual customer preference
+
+ // reorder application protocols preference
+ appProtocols = ... // the actual customer preference
// configure the parameters // (2)
//
// customer preferences should be respected.
sslParameters.setCipherSuites(cipherSuites);
sslParameters.setApplicationProtocols(appProtocols);
>> Therefore, personally, I think application may want a handy tool to sort
>> the cipher suite for the strength for general purpose, but not for
>> application protocol.
>
> Because HTTP/2 would probably be popular given the success of its
> predecessor, it would be handy to have a HTTP/2 comparator to
> influence the selection of the HTTP/2 protocol.
>
> Nothing forbids to offer a comparator by cipher strength too.
>
I think a general cipher strength comparator is sufficient for HTTP/2
preference too. What do you think?
Maybe, need no extra comparator for HTTP2. Extra comparator would make
behaviors pretty complicated and hard to get expected, as I described in
the previous mail.
Xuelei
