- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Wed, 22 Jul 2015 10:30:55 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Bradford Wetmore <bradford.wetmore@oracle.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNp7wHAfKrf4LXbPGeTNYPQzOP3ppKSBEzY1VCBYn2kfJw@mail.gmail.com>
On Wed, Jul 22, 2015 at 9:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > > On 21 July 2015 at 17:52, Bradford Wetmore <bradford.wetmore@oracle.com> > wrote: > > > 2. Are you expecting clients/server to try non-blacklisted ciphersuites > > first? e.g. select H2 for ALPN, prioritize H2-appropriate suites first, > > select a suite and hope for the best? > > The client, by virtue of making the offer, will sometimes offer a set of things that cannot be arbitrarily combined. It is on the server, making the selection, to only select a compliant combination. So a client could send (indeed probably will send) a client hello for tls 1.2 (which implies 1.2 or 1.0 are acceptable), and alpn offer of h1 and h2, and both aes-gcm and rsa-rc4. There are totally legal responses that could include all of those things, but not all combinations are legal responses. It would be, minimally, impolite of a client to send things in the hello that cannot be used in any combination - e.g. a 1.0 client hello with a h2 alpn.. I'm not sure if it would technically be a violation of h2 though if h2 were never negotiated. That starts to get into whether or trees falling in the forest make a sound.. > > > 3. If a ALPN of H2 is received along with a blacklisted suite, are > clients > > expected to provide their own fallback by opening a second connection > with > > H2 not in the ALPN list? > > I believe that Firefox will not do this. It's a hard failure. > > right. If the server selects h2 it needs to speak h2. That means not using the black listed suites among many other requirements of 7540.
Received on Wednesday, 22 July 2015 08:31:25 UTC