I wouldn't call it a requirement for blacklisting ciphers and more of a suggestion because of the "MAY" usage. However, it is a good feature to have.
Appendix A <https://tools.ietf.org/html/rfc7540#appendix-A>. TLS 1.2 Cipher Suite Black List An HTTP/2 implementation MAY treat the negotiation of any of the following cipher suites with TLS 1.2 as a connection error (Section 5.4.1 <https://tools.ietf.org/html/rfc7540#section-5.4.1>) of type INADEQUATE_SECURITY: On Mon, Nov 9, 2015 at 11:26 AM, Leif Hedstrom <zw...@apache.org> wrote: > > > On Nov 9, 2015, at 11:46 AM, Susan Hinrichs < > shinr...@network-geographics.com> wrote: > > > > Hi All, > > > > I'm organizing a discussion of SSL issues in ATS since we last met. > Please let me know if you have been working on SSL issues that you feel > should be discussed. > > > One thing that’s indirectly SSL related is more control over ALPN > negotiations. In particular, what I’d like to see is finer granular control > of which domains / certificate contexts that negotiate what ALPN protocols > (e.g. H2 or not). > > Sudheer said there’s a plugin controlling this per SNI? But maybe it’s > about time we rethink about how we’ll configure TLS, ALPN, SNI and cipher > suites in general? For example, H2 has requirements for blacklisting > certain cipher suites (i.e. you should negotiate H2 with certain cipher > suites). > > Cheers, > > — Leif > >
