Re: #612: 9.2.2 and ALPN

On Wed, Nov 12, 2014 at 5:12 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> On Nov 12, 2014, at 4:41 PM, Eric Rescorla wrote:
>
> On Wed, Nov 12, 2014 at 4:20 PM, Roy T. Fielding <fielding@gbiv.com>
> wrote:
>
>> On Nov 12, 2014, at 12:40 PM, Eric Rescorla wrote:
>>
>> On Wed, Nov 12, 2014 at 11:50 AM, Greg Wilkins <gregw@intalio.com> wrote:
>>
>> So I'm trying to clarify what I server should do if it's TLS layer
>>> negotiates a cipher on the BAD list.
>>>
>>
>> I assume you mean that it negotiates h2 and also negotiates a BAD cipher?
>> Since
>> if it's h1, it can just proceed with the handshake and everything should
>> be fine.
>>
>>
>>>   The text that Mark proposes says that it MAY send INADEQUATE_SECURITY,
>>> which means that it may not.   In the case that it does not send it, I'm
>>> assuming that is for the h1 fallback case and think that needs to be called
>>> out in the text.
>>>
>>
>> Well, it certainly send INADEQUATE_SECURITY, but I think that that
>> MAY is primarily about the client. The bottom line here is that if a
>> server
>> selects h2 and a BAD cipher suite, it is exposing itself to undefined
>> behavior from the client in the form of the client terminating the
>> connection with INADEQUATE_SECURITY.
>>
>>
>> Yes, though I don't see why that would be considered exposing itself.
>> The client can close the connection at any time.  Since the client is
>> the party that doesn't like the chosen cipher, it is free to
>> make another connection attempt using only good ciphers.
>>
>
> I don't believe that either Chrome or Firefox intends to do this, in which
> case servers which behaved in this way will simply not be able to talk
> to those browsers.
>
>
> No, the servers will be able to talk just fine.  The client will just
> not receive the response, which is true of a fairly significant
> percentage of client requests regardless.
>

I think we may be talking past each other. A server that behaves this way
will
simply appear as broken to every user of every client which behaves
as I indicated above. I suspect that may not be what they wanted.

-Ekr