TLS ALPN Proposal v5

Xuelei Fan xuelei.fan at oracle.com
Fri Sep 25 09:47:34 UTC 2015


On 9/25/2015 4:11 PM, Simone Bordet wrote:
> Hi,
> 
> On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan <xuelei.fan at oracle.com> wrote:
>> For example, a client wants to negotiate  {HTTP2,  HTTP1.1} or {HTTP1.1,
>> HTTP2} and {TLS_RSA_WITH_AES_128_CBC_SHA,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384}.
>> HTTP1.1/TLS_RSA_WITH_AES_128_CBC_SHA should be negotiated per the TLS
>> and HTTP2 specification.  If the cipher suites are sorted,
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 would be negotiated, this is not
>> what the customer really expected.  The customer preference should be
>> respected.
>>
>> I don't think we really need to re-order the cipher suites.
> 
> "We" as in the OpenJDK implementation *must not* reorder the cipher suites.
Yes. I agree with this point, OpenJDK MUST NOT reorder the cipher suites.

> "We" as in an application that wants to use HTTP/2 *must* reorder the
> cipher suites.
In an application, the cipher suites preference MUST be used properly,
but the "reorder" behavior may be not the application expected order.
For some reasons, applications (or customers) may want the preference of
{TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384},
rather than reordered to {TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_RSA_WITH_AES_128_CBC_SHA}.  Customers preference should be
respected,  application and OpenJDK MUST NOT reorder the cipher suites.

If there are three roles, OpenJDK, application, customers, there are
three result:
1. OpenJDK MUST NOT reorder the cipher suites if no application request.
2. Applications MUST NOT reorder the cipher suites if no customer request.
3. Customers can set the cipher suites order according to they requirements.

> The comparator provided is only a help to the application to perform
> this reordering.
> 
>> Let's consider the following client requests (prefer cipher suite more
>> than application protocol; blacklisted_CS are HTTP2 blacklisted cipher
>> suite):
>>
>> 1. {HTTP2, HTTP1.1} {strong_cipher_site, blacklisted_CS}
>> HTTP2 and strong_cipher_site should be negotiated.  Need not to re-order
>> cipher suites.
>>
>> 2. {HTTP1.1, HTTP2} {strong_cipher_site, blacklisted_CS}
>> HTTP1.1 and strong_cipher_site should be negotiated. Need not to
>> re-order cipher suites.
>>
>> 3. {HTTP2, HTTP1.1} {blacklisted_CS, strong_cipher_site}
>> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
>> cipher suites.
> 
> Of course you need to re-order in this case.
> The application has just provided a preference for HTTP/2 in the
> application protocol list, it actually happens that HTTP/2 could be
> negotiated because strong ciphers are present, but instead HTTP/1.1 is
> chosen.
> 
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.

Let's re-write the example, among {application_protocol_1,
application_protocol_2} and {cipher_suite_for_AP2,
cipher_suite_for_AP1}.  If application protocol preference get
respected, application_protocol_1/cipher_suite_for_AP1 would be
negotiated;  If cipher suite preference get respected,
application_protocol_2/cipher_suite_for_AP2 should be negotiated.

>From my understand, cipher suite preference should be preferred over
application protocols.

>> 4. {HTTP1.1, HTTP2} {blacklisted_CS, strong_cipher_site}
>> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
>> cipher suites.
>>
>> 5. {HTTP2} {strong_cipher_site, blacklisted_CS}
>> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
>> cipher suites.
>>
>> 6. {HTTP1.1} {strong_cipher_site, blacklisted_CS}
>> HTTP1.1 and strong_cipher_site should be negotiated. Need not to
>> re-order cipher suites.
>>
>> 7. {HTTP2} {blacklisted_CS, strong_cipher_site}
>> blacklisted_CS would be filtered out as it does not appy to HTTP2.  Only
>> strong_cipher_site presents in ClientHello message.
>>
>> HTTP2 and strong_cipher_site should be negotiated. Need not to re-order
>> cipher suites.
>>
>> 8. {HTTP1.1} {blacklisted_CS, strong_cipher_site}
>> HTTP1.1 and blacklisted_CS should be negotiated. Need not to re-order
>> cipher suites.
>>
>> One concern may be that, the customer is not intent to negotiate HTTP2
>> blacklisted cipher suite.  The customer just don't know which are the
>> strong cipher suites among many cipher suites.  I think we may need a
>> handy tool to order the cipher suites before configuration.
>>
>>     // there are a few cipher suites are available
>>     String[] cipherSuites = ...  // a array of cipher suites.
>>
>>     // Q: Don't know the strength of them
>>     // A: OK, there is a handy tool
>>     cipherSuites = cipherSuiteReorder.sort(cipherSuites);
> 
> Or, with the comparator:
> 
> cipherSuites = Arrays.sort(cipherSuites,
> ApplicationProtocol.H2.CIPHER_COMPARATOR);
> 
> The comparator is the handy tool.
> 
>>     // configure the cipher suites
>>     SSLParameters.setCipherSuites(cipherSuites);
>>
>> The order also apply to the normally cipher suites configuration, not
>> only to application protocols.  The re-order should be called by
>> customers explicitly.  JSSE would better not sort them automatically.
>>
>> I think, the handy sort tool cannot be simply bind to application
>> protocol.  For example, HTTP2 has a blacklisted cipher suites.  OK,
>> ApplicationProtocol.H2BLACKLISTCOMPARATOR is expected to make the sort.
>>  If, in the future, a new application protocol (AP_NEW) has a different
>> blacklist cipher suites, a new
>> ApplicationProtocol.APNEWBLACKLISTCOMPARATOR would be defined.  If both
>> {HTTP2, AP_NEW} would be requested, which comparator for the sorting
>> would be used?  None of them can sort the cipher suite properly.  The
>> comparator design will not work any more.
> 
> Sure it does.
> 
> Because you explicitly set a preference in the order of the
> application protocol, you only sort to favour the best protocol.
> 
> In case you have [HTTP/2, AP_NEW, HTTP/1.1], then you can simply
> compose the comparators to sort first with the H2.CIPHER_COMPARATOR,
> then with AP_NEW.CIPHER_COMPARATOR.
> 
> cipherSuites = Arrays.sort(cipherSuites,
> ApplicationProtocol.H2.CIPHER_COMPARATOR.thenComparing(AP_NEW.CIPHER_COMPARATOR));
> 
Let's look at an example.  application_protocol_1 prefer cipher_suite_1,
and application_protocol_1 prefer cipher_suite_2.

The comparator for application_protocol_1 would set the preference as
{cipher_suite_1, cipher_suite_2}.  and the comparator for
application_protocol_2} would set the preference as {cipher_suite_2,
cipher_suite_1}.

The result to sort 1 and then 2, and the result to sort 2 and then 1 are
different.

The call sequence to the comparators, and the call to each comparator
would result in difference result.  That's may be not the expected behavior.

I think, application protocol should not impact the cipher suite
strength.  Stronger cipher suite should be applicable for the
application protocol.  Otherwise, the application protocol should
blacklist the cipher suite.

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.

Xuelei



More information about the security-dev mailing list