- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 16 Oct 2015 12:31:18 -0700
- To: Stefan Eissing <stefan.eissing@greenbytes.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
The solution that NSS supports is similar to what we do for other extensions that affect cipher suite selection. For ECC the named_curves extension lists some curves. If you don't support any of the listed curves, you can't select an ECC-based cipher suite (either ECDHE or ECDSA). Thus, in the extension handler, the stack checks for a good curve, and if it doesn't find one, it disables all of the affected cipher suites. Here, the callback can select a protocol as normal. If it is h2, then it can disable all the blacklisted ciphers. On 16 October 2015 at 04:28, Stefan Eissing <stefan.eissing@greenbytes.de> wrote: > A question regarding interworking and ALPN + ciphers: > > During ALPN callbacks by popular SSL libs such as openssl, the cipher has/may not have been selected. This is a potential interworking problem when h2 is proposed, only to have the connection shutdown with INADEQUATE_SECURITY afterwards. > > I am not certain if this is depending on the order TLS extensions appear in the client hello or the particular openssl implementation. Potentially, I could try to change the cipher list during the ALPN callback, but if that will influence things, is probably also not well defined. This you get, when you mix layers, I assume. > > I am not sure what is the best way to address this. Limiting the cipher list to only highest grade is often not an option for a server. Any advice appreciated. > > //Stefan
Received on Friday, 16 October 2015 19:31:46 UTC