- From: Jason Greene <jason.greene@redhat.com>
- Date: Tue, 23 Sep 2014 13:26:28 -0500
- To: Andrei Popov <Andrei.Popov@microsoft.com>
- 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>
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