Re: null ciphers in 9.2.2

Eric,

You are saying that we will be OK if endpoints "just comply with 9.2.2",
yet that "clients and servers routinely have hidden switches to override
specification requirements".     Thus you are saying we will routinely be
exposed to a fragile handshake that might not work.

9.2.2 interpretation is and will be subject to configuration.  Initially
the configuration might be made non compliant only for testing or for niche
deployments.  But in future, who know how ciphers will evolve and how that
configuration will be changed in real deployments.

We need a robust handshake that will not fail if there is some deviation
from strict 9.2.2 compliance in configuration.       We need to allow "h2
acceptability" to be evolve by experts and experience without the risk of
connection failure when there are mutually acceptable protocol/cipher
pairs.

See other thread for the start of a concrete proposal for this.

cheers




On 7 October 2014 15:06, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Mon, Oct 6, 2014 at 4:55 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>> Nicholas,
>>
>> I was not implying that FF has done anything wrong and it is good to know
>> that there is a configuration to turn off 9.2.2 checking.
>>
>> But my point remains. if 9.2.2 is configurable, then a server cannot know
>> on what basis a cipher is offered - is it a h1 fallback cipher or a
>> configured weak cipher.  If the server guesses wrong communication failure
>> results even though the pair might have protocol/cipher choices that are
>> acceptable.
>>
>
> I don't understand this argument. The server doesn't have to guess, it
> just complies
> with with 9.2.2 and things should work regardless of whether the client is
> configured to accept non-AEAD ciphers for h2 or not.
>
> More generally, clients and servers routinely have hidden switches to
> override
> specification requirements for testing purposes: to take a non-HTTP
> example,
> the getUserMedia() specification explicitly requires the user to be
> prompted
> before granting camera and microphone access, but Firefox has a pref in
> about:config to let you override that. When you flip that preference,
> Firefox
> becomes nonconformant. There are reasons to do that for testing, but if you
> do it, you're on your own. I don't see the situation here as being any
> different.
>
> -Ekr
>
>
>


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