- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 12 Nov 2014 23:27:41 -0600
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Greg Wilkins <gregw@intalio.com>, Ryan Hamilton <rch@google.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> On Nov 12, 2014, at 4:40 PM, Eric Rescorla <ekr@rtfm.com> wrote: > >> On Tue, Nov 11, 2014 at 8:58 PM, Greg Wilkins <gregw@intalio.com> wrote: >> >> I think it is a downgrade attack vector, but what I think this WG is trying to say is that it is an acceptable one. If either peer wants to avoid it, they simple need to not offer the bad ciphers. >> > Can you please explain how this downgrade attack works? In order to deal with servers which, perhaps mistakenly, accept non-h2 compliant ciphers, a client has to choose between failing the connection entirely (when H1 would have worked fine), or opening a new connection. If that new connection offers a weaker selection of ciphers (perhaps some kind of fallback to an old code path) it becomes a potential target. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 13 November 2014 05:28:18 UTC