Re: 9.2.2, Rough Consensus, and Working Code

On 6 November 2014 14:28, Mark Nottingham <mnot@mnot.net> wrote:

> Dare I say MAY?


You MAY say MAY,  but increased flexibility with the interpretation of
9.2.2 requirements just makes it all the more important to have a robust
handshake.

Let's consider the original interoperability problem that raised this issue
and consider how MAY would help or hinder.

I ran Jetty's http2 server on Java-7, which has no ciphers that are
satisfactory with regards to 9.2.2.    FF offered a connection with a
cipher set that included both 9.2.2 acceptable and non acceptable
ciphers.    Jetty's http2 implementation did not implement 9.2.2 and choose
to accept whatever cipher was negotiated based on what the client offered
and how the JVM had been configured (as a recently released and still
supported JVM, it had no known weak ciphers), together with h2.       FF
then applied it's 9.2.2 implementation and rejected the connection.
Thus we failed to communicate even though both client and server spoke h1
and h2, and both were configured with recently updated black/white lists of
acceptable ciphers.    All we did was turn on h2 support and this caused a
server from being able to communicate with a client.  Turning off h2
support in either the client or the server allowed connections to succeed.

In the current draft, the fault for this interoperability failure was with
Jetty, as we did not implement 9.2.2.        I looked into implementing
9.2.2 and discovered that not only are unable to affect cipher negotiation,
but that we have no API with which to query cipher properties.     The only
implementations of 9.2.2 that are available to use are basically regex
and/or name white/black lists, so that this would leave our interpretation
of 9.2.2 subject to configuration and future changes to cipher naming
conventions.  If we are ever configured with a different interpretation of
9.2.2 than our clients, then connections can fail even if there are
mutually acceptable ciphers/protocols.    Thus was born the fragile
handshake issue.

If we replace MUST with MAY, this make the handshake fragility a much
greater interoperability problem.   If the server MAY respond with
INADEQUATE_SECURITY, then it also MAY NOT.   Jetty's deferral of cipher
selection to the TLS layer will now be spec compliant and the failure to
connect even though there were shared ciphers and protocols because a real
problem today rather than a possible problem when faces with hypothetical
future cipher names.  This makes the handshake broken rather than fragile.

I know I sound like a scratched record - but we MUST have a robust
handshake that does not rely on how we "think" ciphers will evolve.

regards












-- 
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.