Re: #612: 9.2.2 and ALPN

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.

-Ekr