- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Sat, 11 Oct 2014 11:53:34 +0300
- To: Greg Wilkins <gregw@intalio.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Oct 11, 2014 at 05:54:08PM +1100, Greg Wilkins wrote: > On 11 October 2014 08:44, Martin Thomson <martin.thomson@gmail.com> wrote: > > > You won't settle for anything short of MUST retry, > > > > In the environment that Jetty is implemented, any support of 9.2.2 is only > going to be approximate at best. We mostly will ony have access to the > cipher name and will have to do some regex matching on it to implement > 9.2.2 - but we will be subject to configuration and surprise ciphers. Thus > I just know that in reality our 9.2.2 implementation will only be > approximate. This would be OK and we would make the effort - IFF we had a > non-fragile handshake. AFAIK, 9.2.2 with proposed modifications plus server operating on blacklist instead of whitelist is not fragile. The client can operate on whitelist without causing fragility if it can either fall back or not advertize any ciphers it doesn't think are acceptable. The server can realistically do neither. Either it would need solution to "variant ALPN" problem or disabling non h2-ciphers even for h1 (a non- starter). And if you have cipher names or even partial introspection capabilities (not enough for full compliance) that blacklist might cover more than just presently known TLS ciphers. E.g: - Ban anything starting with 'TLS_RSA_WITH_' or TLS stack says has KX type of RSA. - Ban anything containing '_WITH_NULL_' or TLS stack saying has cipher type of NULL. - Ban anything containing '_WITH_RC4_128_' or TLS stack saying has cipher type of ARCFOUR_128. -Ilari
Received on Saturday, 11 October 2014 08:53:58 UTC