Re: 9.2.2, Rough Consensus, and Working Code

On 6 November 2014 09:32, Mark Nottingham <mnot@mnot.net> wrote:
>
> Also, it seems like this is orthogonal to Martin's proposal:
>   https://github.com/http2/http2-spec/pull/615
>
> What do people (including you, Mike) think about combining them (perhaps
without the change above, unless we can motivate it)?


I'm generally +1 on the changes in /pull/615, with the caveat that it still
has a fragile handshake.  I like that it adds the text:

 + A client that generates or receives an
<x:ref>INADEQUATE_SECURITY</x:ref> connection error
 + MAY choose to disable HTTP/2 and attempt to reconnect with the same peer
using an
 + alternative protocol, such as HTTP/1.1. Note that this entails a risk of
downgrade attack
 + if the client does not properly validate that the TLS handshake has been
completed; this
 + is especially likely if clients support <xref
target="TLS-FALSE-START">TLS false
 + start</xref>.

that provides a fallback mechanism for clients that wish to talk to old
servers with weak ciphers.   So with that text, we no longer need the
current fallback mechanism that is causing the fragile handshake.   We
don't need two fallback mechanisms, so let's remove:

 - Clients MAY advertise support of cipher suites that are prohibited by
 - the above restrictions in order to allow for connection to servers
 - that do not support HTTP/2.  This enables a fallback to protocols
 - without these constraints without the additional latency imposed by
 - using a separate connection for fallback.

Then we don't have a fragile handshake and we better follow the feedback
from the Area Director and other IETF leadership, that we should not
support weak ciphers.    This fragile handshake has always been the
sticking point for me.  With a robust handshake, Jetty can and will make
best effort attempt to implement recommendations without risk of handshake
failures.

With regards to /pull/641 It has similar retry text to 615.

 + Due to implementation
 + limitations, it might not be possible to fail TLS negotiation. A client
MAY
 + immediately terminate an HTTP/2 connection that does not meet its TLS
requirements
 + with a <xref target="ConnectionErrorHandler">connection error</xref> of
type
 + <x:ref>INADEQUATE_SECURITY</x:ref> before retrying with a different TLS
configuration.

I think 615's version is probably a little bit better, although 641 does
suggest that a retry can be done on a TLS failure as well as an
INADEQUATE_SECURITY.   But either approach is fine with me, or a merge of
the two.

I'm also fine with the detuning of MUST to SHOULD, as I think that will
represent how this is implemented anyway.  Deployers will make best efforts
to comply, but there will always be exceptions.


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.