Re: null ciphers in 9.2.2

On Oct 1, 2014, at 6:49 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Tue, Sep 30, 2014 at 9:38 PM, Jason Greene <jason.greene@redhat.com> wrote:
> 
> On Sep 30, 2014, at 10:27 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
>>> How is that possible?  I'm not saying that my understanding is
>>> perfect, but I believe that's impossible.
> 
>> So the current TLS 1.3 draft allows a TLS 1.3 server to accept connections for anything from SSL 3 to 1.3. A TLS 1.2 client can specify a block cipher like AES256-CBC, and that will be accepted by the TLS stack (unless of course the TLS implementation has been operationally configured not to allow it).
> 
> Yes, and no.
> 
> TLS 1.3 servers can concurrently implement multiple versions of TLS. Thus,
> if a TLS 1.3 server implement TLS 1.2, it would respond to the ClientHello
> you indicate by negotiating 1.2 and selecting the cipher suite. A *pure*
> TLS 1.3 server [either because it had been implemented that way or because
> it had been configured that way] would, however, fail to negotiate with such a
> client.

Exactly the TLS protocol allows it, leaving it to implementors and site operators to decide, whereas the http protocol disallows it, leaving it to the HTTP WG to decide. 

HTTP/2 has no real need to specify cipher restrictions (it’s usable over the clear), its just being used as a hostage.

I disagree with that choice, but I can live with being a hostage taker *IF* we do it in a way that doesn’t break abstractions (leading to unnecessary complexity and potential interop problems).  

This can be accomplished by simply having HTTP/2 mandate connections use TLS 1.3.  Every TLS impl I have used has a facility to check the negotiated version, no additional cipher introspection APIs are necessary. Further an H2 impl doesn’t have to bother with specifying ciphers (and potentially getting it wrong). Interop with legacy implementations is easy because the TLS version and cipher suite selection are part of the handshake/negotiation. A client never sends “legacy” ciphers unless the server falls back, which is all handled gracefully in the TLS protocol.

If we can’t wait for TLS 1.3 (which seems, we should be willing to do, since we apparently want everything that’s in it) then we should change the restriction to a deployment recommendation.

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

Received on Wednesday, 1 October 2014 16:50:18 UTC