Re: Updated 9.2

On 11 October 2014 04:41, Martin Thomson <martin.thomson@gmail.com> wrote:

> I haven't taken Greg's suggestion to limit fallback to the case where
> clients offer legacy suites for HTTP/1.1 servers.  As Ilari notes,
> this doesn't help if you have independent TLS stacks that are using
> suites that you don't understand.  Instead, this is a blanket
> permission: if you see INADEQUATE_SECURITY, either from the server, or
> you are forced to generate it, then you MAY fallback.
>

So it does not address my concerns about a fragile handshake.     We need a
handshake that when presented ciphers/protocol combinations will always
successfully negotiate IFF there is a cipher/protocol pair that is
acceptable
to both endpoints - regardless of the presence of "surprise ciphers" that
may be understood differently by either endpoint.

Saying MAY retry is equivalent to say that the handshake MAY fail, even
when there are mutually acceptable protocol/cipher pairs.   It is also
saying that when this situation occurs, both end-points can point their
fingers at the other and say they MAY act to make the handshake work.

I fully understand that if we say MUST retry that there will be some impl's
that do not, just as there are going to be implementations that do not
fully enforce 9.2.2.   But by using the stronger MUST language the spec
will give help resolve these situations as it will indicate actions that an
endpoint MUST do to make the handshake succeed.

There is just no excuse for a newly designed protocol to have a fragile
handshake that relies on no-surprise ciphers to succeed.  As you have seen
from my multiple proposals, I don't really mind how a robust handshake is
achieve, just so long as we have one!

So still can't live with 9.2 and still wont be implementing it.

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.