Re: #612: 9.2.2 and ALPN

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.

If the h2 server was able to control this exchange, then they wouldn't
allow a bad cipher to be selected.

....Roy