Subject: About Padding in PUSH_PROMISE/HEADERS

From: Raullen Chai <[email-masked]>
Date: Tue, 7 Oct 2014 15:00:19 -0700

Hi all,

The spec says padding of PUSH_PROMISE/HEADERS should be done in this way
<http://http2.github.io/http2-spec/#HEADERS>, which makes sense in normal
circumstances. However, when "Header Block Fragment" gets bigger and gets
splitted/transmitted in the following CONTINUATION frames, the way of doing
padding is unspecified.

Talked with Michaela LaVan and there are two obvious options:
1. pad the leading PUSH_PROMISE/HEADERS frame and defer the transmission of
data payload to the next CONTINUATION frame. This is consistent with the
current spec but seemingly violates the design rationale that all data
payload should be transmitted at first, e.g., transmitting padding payload
first introduces latency.
2. set the PADDED flag and Pad Length in the leading PUSH_PROMISE/HEADERS
and put the actual padding payload in the last CONTINUATION frame which
seems to be more consistent with the design rationale. However, this
behavior is unspecified and adds some complexity.

Any thoughts?

Thanks
Raullen Chai

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 15:15:22 -0700

> behavior is unspecified and adds some complexity.

I think that the logic is simple.  You determine the size of the
header block.  Then determine how much padding is needed.  If
length[block] + length[pad] > remaining, add the padding to the
initial HEADERS/PUSH_PROMISE, add whatever payload fits in the
remaining HEADERS/PP space, then add CONTINUATION frames for any left
over.

I don't think that this is complicated.  It's just limited.  You can
only add <= 256 bytes of padding to any header block.

---

From: Raullen Chai <[email-masked]>
Date: Tue, 7 Oct 2014 15:30:28 -0700

Yes, this is the specified way. Is the latency introduced by transmitting
the padding payload before transmitting the remaining data payload a
concern?

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 15:39:41 -0700

> the padding payload before transmitting the remaining data payload a

Actually, it's probably better.  You don't risk opening a timing
side-channel by having the receiver complete processing prior to
receiving the entire block.

---

From: Raullen Chai <[email-masked]>
Date: Tue, 7 Oct 2014 16:29:10 -0700

Latency is indeed a good way to get rid of side-channel attacks. Thanks for
the input, Martin!