Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

On 23 September 2014 03:29, Eric Rescorla <ekr@rtfm.com> wrote:

> I think we're talking past each other here.


Indeed that appears to be a problem when discussing complex issues such as
TLS.
Different opinions or levels of understanding can exist and that may result
in different implementations or at least different adoption rates.
When presented with that situation we should have a spec that will degrade
gracefully rather than just fail?   While I favour dropping 9.2.2 I have
suggested many other options that will avoid communication failure. Surely
those that think we should be making additional crypto requirements need to
come up with a proposal that does not result in communication failures?


Note that it may be true that the TLS implementation has full knowledge if
a cipher it is using is AEAD or not, but that does not mean that the h2
protocol above it can access that knowledge.     You suggest that in the
offloaded case, it is the TLS implementation itself that will have to know
h2's requirements for ciphers.  Isn't that entirely inverted logic?  Also
h2 might just be a carrier for yet another protocol (via a connect pipe),
if that protocol follows the precedent set here, the the TLS layer is going
to have to know the crypto requirements of protocols within protocols.

I think it is unworkable.... but let's follow our charter to determine if
it really is.  Our charter says that we should be coordinating the TLS
working group and let's see if they are happy to insist that TLS police
application protocol crypto requirements.

regards





-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.