Re: John Scudder's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)

On Thu, Jan 6, 2022, at 09:53, John Scudder via Datatracker wrote:
> I do have one piffling little question. Appendix A ends with
>       |  Note: This list was assembled from the set of registered TLS
>       |  cipher suites when [RFC7540] was developed.  This list includes
>       |  those cipher suites that do not offer an ephemeral key exchange
>       |  and those that are based on the TLS null, stream, or block
>       |  cipher type (as defined in Section 6.2.3 of [TLS12]).
>       |  Additional cipher suites with these properties could be
>       |  defined; these would not be explicitly prohibited.
> This text leaves me with the strong impression that the authors think it would
> be in exceedingly poor taste to make use of additional cipher suites with these
> properties, even if you can’t a priori forbid them. Then again you haven’t even
> explicitly prohibited the ones you do list, just said that implementations MAY
> reject them.
> What I’m getting around to here, is the question of whether you can and should
> be a little more concrete about the “in exceedingly poor taste” thing if indeed
> that is what you intend. E.g., something like “although future cipher suites
> can’t be explicitly listed here for obvious reasons, implementations may wish
> to consider giving such future suites equivalent treatment.”

Hi John,

You inferred correctly.  At some level, this is conveying the subtext that these properties are bad, but I think it's better to just read this as a less nuanced statement: 

  "This is just how we decided on the contents of the list.  We can't change the list."

The first part is mostly just unactionable context, though you can maybe use that information if you are (very) careful. The second part is key and sometimes overlooked.

> The language about “explicitly prohibited” also makes me wonder if you believe
> you’ve explicitly prohibited the suites you list. As mentioned above, you
> haven’t, strictly speaking.

Yeah, we use a "MAY" with respect to enforcement, so it's not that firm.  Functionally, we have though.  Any client that enforces this list (and many do) effectively guarantees that all servers they routinely talk to comply.  Same in converse.  That process took a couple of weeks during initial deployment (back in 2015) to shake out, but the effect is that you can't use those cipher suites with HTTP/2 unless you are comfortable with most connections failing.

Received on Thursday, 6 January 2022 00:56:20 UTC