- From: Greg Wilkins <gregw@intalio.com>
- Date: Fri, 7 Nov 2014 08:16:17 +1100
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 7 November 2014 06:31, Jason Greene <jason.greene@redhat.com> wrote: > since the client is also required to provide at lest TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, there will always be at least one intersection (when both ends are compliant). While I think most server implementations will strive to be compliant, at least with there default settings, I expect there are always going to be situations where a deployment is configured differently (see Roy's email) and is not compliant with 9.2.2 requirements, thus I do not think we can assume that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 will always be present. Thus I think a handshake that relies on the presence of any particular cipher is fragile. If that cipher is ever cracked and removed from deployment, then we are going to expose the web to an unknown set of behaviours as implementations have an assumption they relied on removed. cheers -- Greg Wilkins <gregw@intalio.com> @ Webtide - an Intalio subsidiary http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Thursday, 6 November 2014 21:16:45 UTC