- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 24 Sep 2014 02:52:58 -0700
- To: Simone Bordet <simone.bordet@gmail.com>
- Cc: Eric Rescorla <ekr@rtfm.com>, Roland Zink <roland@zinks.de>, HTTP Working Group <ietf-http-wg@w3.org>
On 24 September 2014 02:39, Simone Bordet <simone.bordet@gmail.com> wrote: > Are you suggesting that every h2 client must be modified (and > recompiled if it needs to) every time a new cipher is provided by TLS, > or I totally misunderstood you (sorry if it is so) ? The software that enables a new cipher suite has to know if it is acceptable to h2 or not before it offers it in a handshake that might result in h2. The acceptability test will depend on implementations. Some TLS stacks don't let you interrogate a cipher suite to determine if it is acceptable, others do. For those that permit querying suite metadata (see ekr's post about NSS), then all that is needed is logic like so: h2acceptable = !isStream && !isBlock && isFsCapable If that is not possible for some reason (c.f., Java) then you will need to revise the implementation to ensure that new suites don't materialize. The easiest way to do that is to list the suites you know are OK and include a list of those. That means respinning your code to take advantage of new ciphers. What you want to avoid is the new cipher being like this one I've heard about: TLS_ECDHE_RSA_ROT13_CRC32
Received on Wednesday, 24 September 2014 09:53:25 UTC