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

[Greg Wilkins <[e-mail]>]

On 19 September 2014 00:03, Patrick McManus <[e-mail]> wrote:

> This thread is suffering a bit from wall-of-text syndrome for me. Is this
> the main point below?
>

Sorry - my bad.   I understand that verbose repetition is not an adequate
response to perceived insufficient consideration of a concern.  Yet my
concern remains and it is a very significant one.    I believe that
deployment of 9.2.2  will hurt h2 adoption, hinder future good cipher
maintenance and will result in widespread future connection failures.



> The scenario as I understand it is:...
> I would say that's an implementation bug in the client.
>

I would agree with you if 9.2.2 was written in precise language so that any
two implementations could be reasonable expected to arrive at the same
result now or into the future.  Currently I can find no definitive list of
acceptable AEAD modes. Wikipeadia lists : CCM
<http://en.wikipedia.org/wiki/CCM_mode>, GCM
<http://en.wikipedia.org/wiki/GCM_mode>, CWC
<http://en.wikipedia.org/wiki/CWC_mode>, EAX
<http://en.wikipedia.org/wiki/EAX_mode>, IAPM
<http://en.wikipedia.org/wiki/IAPM_mode>, and OCB
<http://en.wikipedia.org/wiki/OCB_mode>, but I don't think wikipeadia is a
sutiable reference for such things.    But even if such a list was
obtainable and even if we discount the possibility of AEAD being superseded
in the life of h2,   it is not clear if a h2 implementation is should
enforce this list with some form of name matching, or should it delegate
the decision to it's TLS layer via some isAE() API (and there is no
guarantee that such API will exist, specially for offloaded TLS).

But even if we call differing implementations of 9.2.2 a bug, it is a bug
that is very likely to occur and very likely to be repeated whenever
ciphers evolve. It a bug that has bad consequences.


> I read this as you've had some interop problems because of buggy pioneer
> implementations and evolving draft requirements -
>

I understand that the problem at this stage is both expected and due to
jetty not yet implementing 9.2.2.  However, I raised this example as it
shows the consequence of differing interpretations of 9.2.2 is
communication failure rather than falling back to h1 or weaker ciphers.

If we make communication failure a likely consequence of differing/updating
security policies, then we are introducing significant disincentives for
good cipher maintenance in the future.

The reason for my wall of words is that unless somebody can point out the
flaw in my argument, the introduction of a new AEAD mode or the superseding
of AEAD itself is going to result in widespread communication failures
and/or fallback to h1

There are multiple possible solutions to address this concern in full or
part:

   - drop 9.2.2
   - rewrite 9.2.2 in more precise language (no 'such as')
   - have an IANA registry of 9.2.2 appropriate keys and a requirement to
   keep current
   - enhance ALPN that that is communicates acceptable ciphers for each
   protocol choice
   - have a fallback requirement so that connections are retried
   - require clients that offer h2 to only offer h2 acceptable ciphers
   - move 9.2.2 requirements to a document that applies to h1 and h2
   - show the flaw in my logic/scenarios

I prefer dropping 9.2.2 but would be happy to discuss other alternatives.
Instead I've mostly just been given programming advise as to how to make my
server pick the right cipher/protocol today so that the underlying issue of
differing implementations of 9.2.2 can be ignored.


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