Subject: HPACK padding

From: RUELLAN Herve <[email-masked]>
Date: Fri, 7 Feb 2014 15:43:13 +0000

For solving issue #346, HPACK padding, Roberto proposed to extend the padding mechanism for DATA frames to HEADER and CONTINUATION frames.

I think that makes sense : we have only one padding mechanism. As such, we have one central location for deciding whether padding is necessary in regards of all the available information.

Any though?

Hervé.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Feb 2014 09:42:58 -0800

I'm going to do this.  If I hear screams, I have the power to back out
the relevant commits.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 07 Feb 2014 14:18:49 -0500

+1

> I think that makes sense : we have only one padding mechanism. As such, we have one central location for deciding whether padding is necessary in regards of all the available information.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 7 Feb 2014 11:23:10 -0800

+1

On Fri, Feb 7, 2014 at 11:18 AM, Michael Sweet <[email-masked]> wrote:

> > For solving issue #346, HPACK padding, Roberto proposed to extend the
> padding mechanism for DATA frames to HEADER and CONTINUATION frames.
> >
> > I think that makes sense : we have only one padding mechanism. As such,
> we have one central location for deciding whether padding is necessary in
> regards of all the available information.
> >
> > Any though?
> >
> > Hervé.
> >
> >
> >
> >
>

---

From: Osama Mazahir <[email-masked]>
Date: Fri, 7 Feb 2014 20:05:07 +0000

Wouldn't it be easier just to have a separate PADDING frame instead of having flags, and associated logic, in HEADERS, CONTINUATION and DATA frames?

The objective is not to obfuscate the frames, but to allow varying the resultant ciphertext size. 

It seems easier to code such that you construct your frames normally as is today.  And then append a discrete PADDING frame, if desired.  And then go through the standard TLS code.  On the final receiver, you just add a switch-case for the PADDING frame type and drop it on the floor.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, February 7, 2014 9:43 AM
To: RUELLAN Herve
Cc: [email-masked]
Subject: Re: HPACK padding

I'm going to do this.  If I hear screams, I have the power to back out the relevant commits.

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Fri, 7 Feb 2014 20:27:31 +0000

+1

---

From: Hasan Khalil <[email-masked]>
Date: Fri, 07 Feb 2014 21:30:28 +0000

As previously discussed, padding granularity should be at the byte level,
with a minimum nonzero pad amount of one byte. If we simply have a PADDING
frame, the minimum nonzero pad amount is eight bytes.

On Fri Feb 07 2014 at 3:09:11 PM, Osama Mazahir <[email-masked]>
wrote:

> Wouldn't it be easier just to have a separate PADDING frame instead of
> having flags, and associated logic, in HEADERS, CONTINUATION and DATA
> frames?
>
> It seems easier to code such that you construct your frames normally as is
> today.  And then append a discrete PADDING frame, if desired.  And then go
> through the standard TLS code.  On the final receiver, you just add a
> switch-case for the PADDING frame type and drop it on the floor.
>

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 7 Feb 2014 15:43:08 -0800

Another thing would be needing to describe how PADDING and flow control are
related.

On Fri, Feb 7, 2014 at 1:30 PM, Hasan Khalil <[email-masked]>wrote:

>> It seems easier to code such that you construct your frames normally as
>> is today.  And then append a discrete PADDING frame, if desired.  And then
>> go through the standard TLS code.  On the final receiver, you just add a

---

From: Roberto Peon <[email-masked]>
Date: Fri, 7 Feb 2014 15:47:31 -0800

Yup, which is "as per the frame type's usual disposition" (though I don't
suggest that text).
-=R

On Fri, Feb 7, 2014 at 3:43 PM, Jeff Pinner <[email-masked]> wrote:

> Another thing would be needing to describe how PADDING and flow control
> are related.
>
>
>>> > I think that makes sense : we have only one padding mechanism. As
>>> such, we have one central location for deciding whether padding is
>>> necessary in regards of all the available information.
>>> >
>>> > Any though?
>>> >
>>> > Hervé.
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>

---

From: Jeff Pinner <[email-masked]>
Date: Fri, 7 Feb 2014 15:49:18 -0800

I meant that we would need to if we defined a new frame type.

On Fri, Feb 7, 2014 at 3:47 PM, Roberto Peon <[email-masked]> wrote:

>> On Fri, Feb 7, 2014 at 1:30 PM, Hasan Khalil <[email-masked]
>> > wrote:
>>
>>> As previously discussed, padding granularity should be at the byte
>>> level, with a minimum nonzero pad amount of one byte. If we simply have a
>>> PADDING frame, the minimum nonzero pad amount is eight bytes.
>>>
>>>

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 8 Feb 2014 10:03:09 +0900

> I'm going to do this.  If I hear screams, I have the power to back out

How about put pad_high and pad_low right after frame header for HEADERS
frame? The padding is to a frame and this arrangement is common to other
frames.

Best regards,
Tatsuhiro Tsujikawa

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Sat, 8 Feb 2014 12:42:08 +0900

> frame? The padding is to a frame and this arrangement is common to other

I mean this: https://github.com/http2/http2-spec/pull/380

Best regards,

Tatsuhiro Tsujikawa