- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 12 Nov 2014 23:46:33 -0600
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, Greg Wilkins <gregw@intalio.com>, Ryan Hamilton <rch@google.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
> On Nov 12, 2014, at 9: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. > > If the h2 server was able to control this exchange, then they wouldn't > allow a bad cipher to be selected. The other possibility is that if the ALPN implementation provides access to the TLS stack’s intended chosen cipher (or alternatively the list of ciphers in the ClientHello, which can be used to derive the chosen cipher), the h2 stack can select H1, preventing the connection from failing. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Thursday, 13 November 2014 05:47:15 UTC