Re: Concluding discussion on #612 (9.2.2)

Ilari,

I'll take your comments out of order:


On 9 October 2014 21:36, Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
wrote:

>
> How does this handle version skew (and "surprise" ciphers), both at client
> and
> server?


Both proposals handle surprise ciphers by having a strong handshake that
will not fail to connect if
an end point decides that an unknown cipher is h2 acceptable.   If both end
points decide that
a new cipher is h2 acceptable then it may be used for h2 - regardless if it
fits the 9.2.2
compliance or not.    But most importantly, the strong handshake allows one
end-point to take that
step without risking connection failure.

The entire point of having a robust handshake is to handle the unexpected
development in ciphers.
It is the current handshake that is fragile when presented with surprise
ciphers.



> One can get ciphersuites that are UNKNOWN if those are 9.2.2-compliant
> (without TLS introspection APIs, that one presumably can't assume present).
>

As it has been said many times here, an end point can choose to be 9.2.2
non compliant.
This proposal allows that to happen without risk of connection failure.
Note that it does
not mean that an end-point can expect or demand that the other end also be
9.2.2
compliant.    Each end-point is ultimately responsive for the ciphers it
will accept.

Why did you assume that PFS is the same as DHE/ECDHE key exchange? That's
> not
> true even in current TLS.
>

I didn't assume.      I looked for an definition of "ephemeral key", but
could not
find anything more rigorous than wikipedia.  So I instead simply white
listed the ciphers that
were given as "such as" examples in the original text.    If there are more
key exchanges that
need to be white listed, then we can add them.  Unknown surprise mechanism
will be covered
by the robust handshake above.    If there is a good standard definition of
what ciphers have
ephemeral keys, then I'm happy to reference that.


> Disabling any ciphers as response to TLS handshake abort (which is
> completely unauthenticated[2]!) is a VERY bad idea (the proposal does not
> say to do it, but neither it says to not do it)[3].
>

Neither proposal implies disabling ciphers in response to a handshake abort.
The first proposal adds ciphers and removes h2 from a retry.  The second
proposal
just removes h2 from a retry.




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