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

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 05 Jan 2022 14:53:55 -0800

John Scudder has entered the following ballot position for
draft-ietf-httpbis-http2bis-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this eminently readable document.

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.”

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 06 Jan 2022 11:55:45 +1100

> 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.

> 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.