Re: 9.2.2, Rough Consensus, and Working Code

On 6 November 2014 16:40, Mark Nottingham <mnot@mnot.net> wrote:

>
> > On 6 Nov 2014, at 4:15 pm, Greg Wilkins <gregw@intalio.com> wrote:
> >
> > I ran Jetty's http2 server on Java-7, which has no ciphers that are
> satisfactory with regards to 9.2.2.
>
> Then it's not conformant to 9.2.2. This is not an interop problem -- it's
> a failure to conform.
>

That is exactly what I said.  But if you change to a MAY rather than a MUST
it is a broken rather than fragile handshake.
Even as a MUST implementations of 9.2.2 will be sufficiently mutable (see
your point about configurable white/black lists below), that it is likely
that differences will be experience and interop problems will result.

Most servers have exposed the black/white lists as configuration metadata,
> and presumably will give guidance / good defaults to the admin to assure
> that it will be 9.2.2-conformant. Why is this not adequate, until you have
> appropriate APIs in place?
>

Again exactly my point.  Not only will servers use configurable black/white
lists, but so will many non browser clients.

Enter the proverbial new XYZ cipher and we now have our interop problem.
Servers will start to see XYZ ciphers offered, but because of the fragile
handshake they have no idea if XYZ is being offered for h2 or not.

So if a server then adds XYZ to it's h2 white list, it will not be able to
talk to those clients that have allowed XYZ to be added to their TLS
ciphers, but have not yet added it to their h2 white list.    If the server
does not add it to their white list, then they may not be able to use an
important new cipher that is needed to avert some security threat.

We all appear to accept that TLS and h2 cipher acceptability will be
configurable via white/black lists, so at best 9.2.2 can only be considered
a recommendation for the default values of the h2 black list.
Fundamentally it is configuration and we cannot put servers in the position
where they have the choice between talking to new strong ciphers vs losing
connection with clients that have not yet h2 white listed the new strong
cipher.

Well, it makes it a conformance issue at runtime, one that will be very
> evident once the admin points Firefox or Chrome at the server. AIUI the
> idea is that they'll self-correct (quickly).


I think this indicates you are missing the fundamental aspect of my
concern.  Sure an admin can configure the server correctly to talk to 1
particular clients configuration.  But they cannot configure it to connect
to all legal clients configurations at the same time.    The client
population is going to lag and you are asking servers to disconnect from
populations during the process of introducing new ciphers.

This is a likely issue if 9.2.2 is a MUST.  This is a broken spec if 9.2.2
is a MAY.

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.