Subject: Why do DATA frames have padding?

From: Greg Wilkins <[email-masked]>
Date: Wed, 7 May 2014 16:45:35 +0200

I understand the security issue of obscuring data length so that an
attacker cannot send crafted data with a known compression algorithm to
help search for encryption keys.

But why does the padding data created to protect against that have to be
within the data frame?  This appears to a be a needless complication as the
extra data can be sent either in ping frames or even in an additional
stream.

Either the attacker can see frame boundaries, in which case in frame
padding is no good because the attacker can see the headers - OR they
can't, in which case sending some extra random length data can be done in
pings and/or alternate streams and the attacker will not be the wisers.

There might be an issue with frames being sent in different packets, but
that is easy for the sender to ensure simply by prepending and random size
ping to any buffer used to construct a data frame.

regards

PS.  I can already imagine the abusive uses of the protocol that will start
putting "hidden" meta data into the padding!

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 7 May 2014 16:48:42 +0000

PING requires a response, which is superfluous.  There was a proposal for PADDING frames which would be discarded upon receipt, but some folks expressed concern that this imposed a minimum padding increment (the size of the frame headers).  I’m still a little dubious of the value in the distinction, personally, but I’m not a security expert.

From: Greg Wilkins [mailto:[email-masked]]
Sent: Wednesday, May 7, 2014 7:46 AM
To: HTTP Working Group
Subject: Why do DATA frames have padding?

I understand the security issue of obscuring data length so that an attacker cannot send crafted data with a known compression algorithm to help search for encryption keys.
But why does the padding data created to protect against that have to be within the data frame?  This appears to a be a needless complication as the extra data can be sent either in ping frames or even in an additional stream.
Either the attacker can see frame boundaries, in which case in frame padding is no good because the attacker can see the headers - OR they can't, in which case sending some extra random length data can be done in pings and/or alternate streams and the attacker will not be the wisers.
There might be an issue with frames being sent in different packets, but that is easy for the sender to ensure simply by prepending and random size ping to any buffer used to construct a data frame.
regards
PS.  I can already imagine the abusive uses of the protocol that will start putting "hidden" meta data into the padding!

--
Greg Wilkins <[email-masked]<mailto:[email-masked]>>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 May 2014 11:10:47 -0700

> extra data can be sent either in ping frames or even in an additional

Two concerns meant that early proposals to add a PADDING frame were
not successful:

The first is with respect to the size of padding.  Whole frames are,
at a minimum, 8 octets.  You can't pad by smaller increments.  That
was considered to be counter to the goal.

The second is with the creation of side channels.  Information on
other streams or in other frames will not generate flow control
indicates, which generates a potential method of inferring the true
size.  Information that is easily discarded might create timing
channels.

> PS.  I can already imagine the abusive uses of the protocol [...]

I'm certain that this protocol will be abused roughly in proportion to
how successful it is.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 May 2014 11:11:41 -0700

On 7 May 2014 09:48, Mike Bishop <[email-masked]> wrote:
> PING requires a response, which is superfluous.

Just set the PONG bit :)  ...or ACK for those sticklers.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 7 May 2014 19:51:05 +0000

Heh -- sending a PING response without having gotten a PING in the first place (or yet, if it's in flight) has the potential to mess with many state machines....  That's an interesting attack.