Subject: Éric Vyncke's No Objection on draft-ietf-httpbis-http2bis-06: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 05 Jan 2022 04:07:32 -0800

Éric Vyncke 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:
----------------------------------------------------------------------

Thank you for the work put into this document. As a side note, I am impressed
that the WG only needed 6 revisions for such a major document! The introduction
section is also crystal clear and to the points.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Mark Nottingham for the (short) shepherd's write-up including
the section about the WG consensus (even if very terse).

I hope that this helps to improve the document,

Regards,

-éric

-- Section 3.1 --
Beside the history associated to "h2c", I really wonder why it is described in
the document (just out of curiosity).

-- Section 5.1.1 --
In "The identifier of a newly established stream MUST be numerically greater",
is the increment interval 1 or can it be any positive non-nul integer ?

-- Section 5.2.1 --
In the bullet 1. in "Both types of flow control", it is unclear to me what
"both" refers to especially after reading the previous "allow a variety of
flow-control algorithms", which hints to several (and not 2) mechanisms. Or is
it per direction ?

-- Section 6.1 --
The SEC AD will obviously have the final word on this but wouldn't random
padding be more secure (at the expense of later compression of course) ?

-- Section 6.7 --
In figure 9, suggest to indicate that the Length is 8 octets.

-- Section 9.1 --
In "Clients SHOULD NOT open more than one HTTP/2 connection", should some words
be added when the client has multiple interfaces (e.g., Wi-Fi & mobile) ? I
understand that this is probably beyond HTTP...

-- Appendix A --
Some justifications (beyond the note at the end of the appendix) would be
welcome.

Should a pointer to section 9.2.2 be added ?

---

From: Cory Benfield <[email-masked]>
Date: Thu, 6 Jan 2022 14:17:26 +0000

> https://datatracker.ietf.org/doc/draft-ietf-httpbis-http2bis/

Enough description was given to explain what it is, but a note about
its deprecation was provided. In principle we could just delete the
first two paragraphs and leave only the note that it is no longer
defined.

> is the increment interval 1 or can it be any positive non-nul integer ?

It can be any even positive non-zero integer. The fact that the
increment must be even derives from the first paragraph in the
section:

> Streams initiated by a client MUST use odd-numbered stream identifiers;
> those initiated by the server MUST use even-numbered stream identifiers.

> flow-control algorithms", which hints to several (and not 2) mechanisms. Or is

The "both types" here applies to per-stream and per-connection flow
control, but I agree that it reads weirdly. We should reword it.

> padding be more secure (at the expense of later compression of course) ?

I'm not really qualified to draw a conclusion here, but my layperson
view is that padding is only useful within an encrypted tunnel
provided by TLS, so the specifics of what the padding bytes _are_
should not matter: the TLS stream cipher should make their specific
byte value entirely unobservable. And it's way cheaper to assemble
zero bytes than it is to assemble random ones. You can also verify
that padding has been done correctly if you use zero bytes (though
probably you shouldn't, lest you anger Daniel Bleichenbacher).

> understand that this is probably beyond HTTP...

I'm inclined to suggest that this is beyond HTTP/2.

> Some justifications (beyond the note at the end of the appendix) would be

I don't know that there are any justifications beyond the note at the
end of the appendix. Would you prefer that we formalised that note?

> Should a pointer to section 9.2.2 be added ?

Thanks for the feedback! Please find some changes here:
https://github.com/httpwg/http2-spec/pull/1010.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Jan 2022 14:29:09 -0800

> probably you shouldn't, lest you anger Daniel Bleichenbacher).

Since a SEC AD was summoned, I'll confirm that this reasoning is basically
sound.  Using random rather than constant padding would interact
differently with compression techniques, but we already warn against
compression and for good reason, so the distinction is mostly irrelevant.

-Ben

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 07 Jan 2022 13:24:50 +1100

> compression and for good reason, so the distinction is mostly irrelevant.

To round this out more: there is a concern that random values will cause endpoints to expose too much of the state of their random number generators.  This might make them vulnerable to attack from endpoints that can predict what they will generate.  To be clear, I don't share this concern, even if it has some reasonable basis.

Probably more relevant: randomness is more expensive to generate than zero.