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

On Mon, Sep 22, 2014 at 3:05 PM, Greg Wilkins <gregw@intalio.com> wrote:

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

I want to reemphasize at this point that I don't much care one way or the
other
whether HTTP2 requires AEAD. So, I'm trying to confine myself to discussing
the technical issues around the use of TLS.

With that said, I think there are two different situations here:

- People who misread the specification with the result that there are
interop
  failures.
- It not being in principle possible to avoid interop failures.

Based on your comments and whatever knowledge I currently have, I don't
believe that it's not possible to avoid interop failures. As I said,
implementations
can at least in principle distinguish which algorithms are acceptable and
which
are not and as long as we take some care not to change the rules
retroactively
I don't see why there should be an unsovlable interop problem.

It could well be the case that implementors will screw this up or are for
some
other reason unable to comply with 9.2.2, but that seems like a different
question.
Is that your sole concern or do you still believe that this will cause
interop problems
regardless of implementation correctness?



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

Sorry, I'm not following. My point was merely that if you have an offload
device, it
is the place where the ALPN negotiation happens for HTTP2, so I'm not
following
why it can't do the conditional cipher suite negotiation at the same time.
What am I missing?


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

Yes, if that protocol were negotiated via ALPN I think that would be true.

-Ekr