Re: null ciphers in 9.2.2

On Tue, Oct 7, 2014 at 3:14 PM, Greg Wilkins <gregw@intalio.com> wrote:

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

No. I am saying that people who are doing testing can configure their
software in noncompliant ways, which may cause bustage.

-Ekr


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