W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

From: Jason Greene <jason.greene@redhat.com>
Date: Tue, 23 Sep 2014 13:26:28 -0500
Cc: Martin Thomson <martin.thomson@gmail.com>, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>, Roland Zink <roland@zinks.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <80311159-C463-4D43-8810-F8D29FFF82AD@redhat.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>

On Sep 23, 2014, at 1:00 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

> I am in full agreement: it is hard to get the world to disable weak ciphers and old TLS versions. Right now addressing a new TLS vulnerability involves:
> 1. Updating TLS RFCs;
> 2. Patching TLS stacks;
> 3. Getting patched TLS stacks deployed. 
> 
> Requiring certain TLS versions and cipher suites in HTTP RFCs means that now we also need to:
> 4. Update HTTP RFCs when TLS vulnerabilities are discovered;
> 5. Patch HTTP stacks for TLS vulnerabilities;
> 6. Get patched HTTP stacks deployed.
> 
> So it seems that instead of keeping the problem encapsulated at the TLS layer and figuring out how to better solve it there, we're spreading it to the application layer. I think this would be counter-productive.

Indeed. Why not go with a gentler social hack that accomplishes a similar result? If user agents start warning about weaker ciphers, in a similar (yet gentler) way to certificate warnings, then server administrators will be motivated to update and/or configure their TLS stacks. This type of social hack would benefit all web protocols, not just http/2.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
Received on Tuesday, 23 September 2014 18:27:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC