Re: 9.2.2, Rough Consensus, and Working Code

> On Nov 6, 2014, at 3:16 PM, Greg Wilkins <gregw@intalio.com> wrote:
> 
> 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.

I hear you. My first preference is by far to completely remove 9.2.2, as it limits usage of the protocol, and ironically promotes H1. My second preference is to completely remove 9.2.2, as it is essentially an attempt dictate to TLS implementations without a TLS spec. My third preference is to replace 9.2.2 with a requirement on TLS 1.3, and hold off until its released. Extra time typically means a better protocol. My final preference is to at least get text for 9.2.2 that can actually be implemented.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Thursday, 6 November 2014 21:43:53 UTC