Hello, Just want to mention that with explicite http/https URLs users and applications are somewhat used to select the application protocol first. In fact if I have a H2 client I would expect it to try H2 first (especially given the fact that no weak ciphers could be negotiated anyway). So basically cipher order would select if you want strong but fast or very strong but slower crypto for H2. You could only mess that up by prefering blacklisted ciphers. But even then the serrver can still pick H2 and skip all blacklisted preferences, right?
Gruss Bernd -- http://bernd.eckenfels.net -----Original Message----- From: Xuelei Fan <xuelei....@oracle.com> To: Simone Bordet <sbor...@webtide.com> Cc: OpenJDK Dev list <security-dev@openjdk.java.net>, "net-...@openjdk.java.net >> OpenJDK Network Dev list" <net-...@openjdk.java.net> Sent: Fr., 25 Sep. 2015 11:48 Subject: Re: TLS ALPN Proposal v5 On 9/25/2015 4:11 PM, Simone Bordet wrote: > Hi, > > On Fri, Sep 25, 2015 at 3:44 AM, Xuelei Fan <xuelei....@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
