- From: Michael Sweet <msweet@apple.com>
- Date: Wed, 24 Sep 2014 06:22:47 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Simone Bordet <simone.bordet@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
Martin, HTTP implementations that use the OS supplied TLS libraries don't have the same close integration that a browser using its own TLS library has. CUPS works with three different TLS libraries [1] (used to be four, but we dropped OpenSSL support) and all of them have vastly different interfaces and capabilities from the standpoint of cipher suite selection and classification. None of them directly allow selection based on the kind of classification that is specified in 9.2.2 and it isn't clear to me yet whether I can even specify the kind of priority ordering that is being touted as a solution for interop problems. The reason is that these general purpose TLS libraries are themselves enforcing best practices and site policy with their defaults, and discourage developers from straying unless they are experts and know what they are doing. 9.2.2 is forcing HTTP developers to act as TLS experts... [1] For CUPS 2.0 we support GNU TLS, SecureTransport (OSX), and SSPI (Windows). Sent from my iPad > On Sep 24, 2014, at 2:14 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > >> On 24 September 2014 02:08, Simone Bordet <simone.bordet@gmail.com> wrote: >> Old h2 clients that are dynamically linked to a new TLS implementation >> will have X but not know that is acceptable. > > Implementations shouldn't be enabling cipher suites that they don't understand. >
Received on Wednesday, 24 September 2014 13:23:17 UTC