Re: #612: 9.2.2 and ALPN

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 think there is any scenario in which INADEQUATE_SECURITY
needs to be sent.  A server that wanted to send it would have refused
the TLS handshake (i.e., no good ciphers offered).  A server that doesn't
want to send it isn't going to.  A client that does want to send it
doesn't need to -- just drop the connection.  A client that doesn't want
to send it is just going to make use of the completed connection, either
to send an HTTP/1 request or to ignore 9.2.2 and send h2.

....Roy