Subject: Re: h2 padding

From: Patrick McManus <[email-masked]>
Date: Tue, 2 Sep 2014 16:45:31 -0400

On Sat, Aug 30, 2014 at 3:14 PM, Roy T. Fielding <[email-masked]> wrote:

> here is no
> need for padding within a frame.  The security need is for padding to be
> allowed after a frame when both are enveloped within an opaque stream.
>

Hi Roy -

Nobody has mentioned this yet in this thread so I will. The existing
design, which I think is universally regarded as awkward, meets the
requirement for 1 byte minimum pads which is rooted in Thai Duong's comment
here: https://github.com/http2/http2-spec/issues/344  .. a new frame would
either need a non standard frame header as Greg mentions (also awkward in a
different way!) or be too big.

-Patrick

---

From: Guille -bisho- <[email-masked]>
Date: Tue, 2 Sep 2014 13:58:17 -0700

Padding should be accomplish on the TLS layer, there is no point in having
size randomization on HTTP/2 framing when we also want to support cleartext.

-- 
Guille -ℬḭṩḩø- <[email-masked]>
:wq

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Sep 2014 14:51:28 -0700

On 30 August 2014 12:14, Roy T. Fielding <[email-masked]> wrote:
>
> I think that is a mistake.  Forcing padding to zero makes it less random
> and causes it to be compressed to nothing if a higher layer compresses
> the stream.  A requirement on senders cannot prevent bad actors from
> sending non-zeros (assuming this is to prevent smuggling of data).

This was entirely intentional.  And this is less about bad actors than
it is about reducing the likelihood that a bad implementation escapes
detection.  I personally consider the idea that we might prevent
somehow smuggling in HTTP to be laughable.

Note that these zero bytes cannot be compressed.  We're requiring no
compression in TLS, consistent with its eventual removal in 1.3.

[...]

> I think there is a misunderstanding here.  Padding is used to allow an
> opaque stream to not reveal its size.  Frames are not opaque.  There is no
> Naturally, this is best accomplished with a padding frame type.

The basic property that we're looking for is that the set of frames
that comprise for a given communication pattern are indistinguishable
from the frames for a different communication pattern.  When Thai says
"padding should have 1-byte increments", it might look like we took
the most aggressive interpretation of that.  We interpreted that
padding needed to be in the range [0,n), when [d,n+d) is good enough
to meet that requirement alone.

If an implementation wanted to pad frames between 120 bytes and 143
bytes out to be indistinguishable, the current scheme permits no
additional overhead for the 143 byte sequence, and allows a minimal 23
byte pad for the smallest.  However, with a new frame type, the
overhead of a frame boundary would reveal a 142 byte sequence, and any
scheme would have to allow for the sudden appearance of a frame
boundary.  That means that you need to include a padding frame for all
of the frames.

That alone wouldn't be sufficient cause to build a scheme like what we
have, which is definitely ugly.  Being strictly parsimonious with
bytes while you pad is oxymoronic.

The main reason for the ugly is that we're attempting to avoid other
side channels at the same time.  There are more avenues for leakage
than simply length.  The ugly scheme ensures that padding of payloads
is flow controlled, ensuring that padding is covered by flow control.
This avoids having WINDOW_UPDATE timing inadvertently revealing
length.

We did discuss moving the padding to the start of the frame so that
you don't leak timing, but it's not clear that we can prevent
finer-grained timing based attacks anyway, so we decided not to.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 2 Sep 2014 15:38:45 -0700

On Sep 2, 2014, at 1:45 PM, Patrick McManus wrote:

> Nobody has mentioned this yet in this thread so I will. The existing design, which I think is universally regarded as awkward, meets the requirement for 1 byte minimum pads which is rooted in Thai Duong's comment here: https://github.com/http2/http2-spec/issues/344  .. a new frame would either need a non standard frame header as Greg mentions (also awkward in a different way!) or be too big.

Hi Patrick,

Thanks for the useful information and pointer.  Unfortunately, it seems
the WG misunderstood the fairly generic advice that was given by the
Google team.  In particular, where they said "The padding should have
1-byte increments" what they meant is that padding should be able to
expand or reduce by a single byte so that it can mask single byte
changes to the content (and not look statistically odd).

The right way to do this (if it is done at all in the application layer)
is to always send the padding frame, for responses from a given resource
that needs padding for some reason, and only vary the amount of padding
sent each time (even if it is zero).  Deciding whether or not to write
the padding frame/length, at run time, would be revealing on its own.
Hence, the minimum padding under my proposal would be 64bits (the price
of a padding frame type) but the padding itself is in 1-byte increments
when compared to other traffic within the needs-to-be-padded space.

That said, I should clarify that I agree with their other advice as well.
Padding for cryptographic reasons should be handled at other layers.
However, sometimes it isn't, and in those cases it can only be handled
where one has control. The extremely rare cases in which we would want
to do padding in h2 (as opposed to within TLS or within the content)
are adequately covered by a padding frame, which adds no complexity to
the rest of the protocol.  In contrast, having optional fields at the
beginning of every Headers, Data, and Push_Promise frame is adding
complexity on every single interaction via h2, even if those fields
are never used in practice.  I think that's a bad trade-off.

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 2 Sep 2014 16:24:03 -0700

> somehow smuggling in HTTP to be laughable.

I was trying to be nice.  Sending zeros for padding is a bad implementation.

> compression in TLS, consistent with its eventual removal in 1.3.

I am not going to limit use of HTTP to TLS.  Making design assumptions
based on its presence is a mistake.  There are a significant number of
HTTP implementations that don't even use a network, and a significant
number of secure networks that don't require the vulnerability of TLS
certificate authorities.  Let's not assume they do.

BTW, the same is true of the way "TCP" is used in the spec.  Assuming
that all connections are TCP isn't even remotely true in practice,
including when they are actually TLS.

....Roy

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Sep 2014 08:36:58 +0300

On 30 Aug 2014, at 10:14 pm, Roy T. Fielding <[email-masked]> wrote:

> This comment is in reference to sections 6.1, 6.2, 6.6 of
> 
> http://tools.ietf.org/id/draft-ietf-httpbis-http2-14.txt
> 
>> 6.1.  DATA
>> 
>>   DATA frames (type=0x0) convey arbitrary, variable-length sequences of
>>   octets associated with a stream.  One or more DATA frames are used,
>>   for instance, to carry HTTP request or response payloads.
>> 
>>   DATA frames MAY also contain arbitrary padding.  Padding can be added
>>   to DATA frames to obscure the size of messages.
>> 
>>     0                   1                   2                   3
>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |Pad Length? (8)|
>>    +---------------+-----------------------------------------------+
>>    |                            Data (*)                         ...
>>    +---------------------------------------------------------------+
>>    |                           Padding (*)                       ...
>>    +---------------------------------------------------------------+
>> 
>>                            DATA Frame Payload
>> 
>>   The DATA frame contains the following fields:
>> 
>>   Pad Length:  An 8-bit field containing the length of the frame
>>      padding in units of octets.  This field is optional and is only
>>      present if the PADDED flag is set.
>> 
>>   Data:  Application data.  The amount of data is the remainder of the
>>      frame payload after subtracting the length of the other fields
>>      that are present.
>> 
>>   Padding:  Padding octets that contain no application semantic value.
>>      Padding octets MUST be set to zero when sending and ignored when
>>      receiving.
> 

Raised as <https://github.com/http2/http2-spec/issues/602>.

> 
>>   The DATA frame defines the following flags:
>> 
>>   END_STREAM (0x1):  Bit 1 being set indicates that this frame is the
>>      last that the endpoint will send for the identified stream.
>>      Setting this flag causes the stream to enter one of the "half
>>      closed" states or the "closed" state (Section 5.1).
>> 
>>   PADDED (0x8):  Bit 4 being set indicates that the Pad Length field is
>>      present.
>> 
>>   DATA frames MUST be associated with a stream.  If a DATA frame is
>>   received whose stream identifier field is 0x0, the recipient MUST
>>   respond with a connection error (Section 5.4.1) of type
>>   PROTOCOL_ERROR.
>> 
>>   DATA frames are subject to flow control and can only be sent when a
>>   stream is in the "open" or "half closed (remote)" states.  The entire
>>   DATA frame payload is included in flow control, including Pad Length
>>   and Padding fields if present.  If a DATA frame is received whose
>>   stream is not in "open" or "half closed (local)" state, the recipient
>>   MUST respond with a stream error (Section 5.4.2) of type
>>   STREAM_CLOSED.
>> 
>>   The total number of padding octets is determined by the value of the
>>   Pad Length field.  If the length of the padding is greater than the
>>   length of the remainder of the frame payload, the recipient MUST
>>   treat this as a connection error (Section 5.4.1) of type
>>   PROTOCOL_ERROR.
>> 
>>   Note:  A frame can be increased in size by one octet by including a
>>      Pad Length field with a value of zero.
>> 
>>   Use of padding is a security feature; as such, its use demands some
>>   care, see Section 10.7.
> 
> As you can see, almost half of the description of this frame is devoted
> to the optional padding.  The same is true of 6.2 and 6.6.
> By moving padding to a frame type, we can then remove the optional
> pad length and half the complexity for each of the types that currently
> allow padding within their frames.

This doesn’t appear to affect interoperability or security; you’re basically saying “I wouldn’t have done it that way.”

We can certainly still change the way padding is done, but I need to see consensus in the WG that doing so is necessary. 

What do people think of Roy’s subsequent proposal to have a separate padding frame and always send it? Please be aware that changing the padding scheme would necessitate another round of security review.

I’m assuming that by “always send it”, you mean that a padding frame should be sent every time a potentially paddable frame is sent, correct? Note that this would effectively double the overhead of the frame header.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Brian Smith <[email-masked]>
Date: Tue, 2 Sep 2014 23:07:44 -0700

> What do people think of Roy’s subsequent proposal to have a separate padding frame and always send it? Please be aware that changing the padding scheme would necessitate another round of security r…

Consider an implementation that sends every frame in its own TCP
packet, perhaps with a 1 minute delay between frames. Such an
implementation would conform to Roy's suggestion, but it would
partially or completely defeat the purpose of the padding. To make the
change that Roy suggested safe(r), there would have to be the
additional restriction that a padding frame and the frame it is
associated with are not split this way. This seems like a difficult
thing to formulate. More importantly, it seems extremely error-prone
and thus it would be a counterproductive change in terms of security.

Note that the current draft doesn't prohibit an implementation from
sending the padding part of a DATA frame in one packet and the actual
data part in a separate packet, with our without delays between them.
Similarly, it seems like a proxy is allowed to split a DATA frame into
two DATA frames and/or coalesce them together. The draft needs to be
updated to prohibit any such special processing of the padding
distinctly from the actual data. Regardless, this should be easier to
formulate for the current single-frame situation than it would be with
Roy's separate-frame proposal.

It would also be more difficult to reformulate the requirement "All
implementations MUST be capable of receiving and minimally processing
frames up to 2^14 octets in length, plus the 9 octet frame header
(Section 4.1)" to work with a separate padding frame. (I hope the
reason is obvious; if not, I can explain more.)

I actually think it is worth evaluating whether the padding mechanism
is practically useful as a security mechanism as specified and with
the above issues addressed. Has anybody actually used frame padding to
solve a real-world problem yet? Has anybody tried to write a
terrible-but-conforming implementation that effectively undoes all the
protection that padding is supposed to offer? It seems likely that the
answer to both questions is "no."

tl;dr: The more the specification treats the padding bytes as being
equivalent and indistinguishable from the actual frame payload, the
more secure the padding mechanism will be. Putting the padding in a
separate frame is completely at odds with this. There are problems
with how padding is specified, but the padding being in the same frame
as the data is not one.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Tue, 2 Sep 2014 23:15:08 -0700

> answer to both questions is "no."

Also, what is a HTTP1.1 <-> HTTP/2 proxy supposed to do with padding?
It seems it can do nothing but drop it. But, if the padding is
security-critical then it isn't safe to drop it. It seems like padding
either belongs at the transport layer or within the application (e.g.
within the HTML content), not in the HTTP layer. But, perhaps this
concern has already been addressed in ways that are not obvious to me;
if so, sorry for the noise.

Cheers,
Brian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Sep 2014 06:28:39 +0000

--------
In message <CAFewVt74NYqEFNUFnhYcWdaYpZpsEj4zWb4eG7O29=[email-masked]>

>It seems like padding either belongs at the transport layer or within the
>application (e.g. within the HTML content), not in the HTTP layer.

Agreed.

There's an old article about this called "End-to-end arguments in
system design".

The transport layer can pad traffic to look all alike, but this is
incredibly inefficient, basically it must fill all packets and
stuff random bogo-packets in to mask any timing.

The application layer knows both what is important to mask and how
to best best mask it, and that is where security padding should happen.

Hoping that a random layer in the middle can stuff in some padding
without insight into the context and magically secure all the
web-apps which should have thought about it is not based on sound thinking.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Sep 2014 06:34:35 +0000

--------
In message <CAFewVt4K3oWXVO-0=M+iCVp8KEiutJ3zDM7YoUO=[email-masked]>
, Brian Smith writes:
>> What do people think of Roy=E2=80=99s subsequent proposal to have a separ=
>ate padding frame and always send it? Please be aware that changing the pad=
>ding scheme would necessitate another round of security review.
>
>packet, perhaps with a 1 minute delay between frames. [...]

If this was a joke, you forgot the smiley.

If it wasn't, please explain why we should even think about entertaining
the convenience of such an implementation, when 3/4 of the browsers
cannot even think of a reason to support non-TLS traffic.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 03 Sep 2014 23:27:21 +1200

On 3/09/2014 6:34 p.m., Poul-Henning Kamp wrote:
> -------- In message
> <CAFewVt4K3oWXVO-0=M+iCVp8KEiutJ3zDM7YoUO=[email-masked]>
>
> 
, Brian Smith writes:
>> ate padding frame and always send it? Please be aware that
>> changing the pad= ding scheme would necessitate another round of
>> security review.
>> 
> If it wasn't, please explain why we should even think about
> entertaining the convenience of such an implementation, when 3/4 of
> the browsers cannot even think of a reason to support non-TLS
> traffic.
> 

HTTP/2 over DTLS.

Amos

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 03 Sep 2014 23:33:26 +1200

On 3/09/2014 6:15 p.m., Brian Smith wrote:
> On Tue, Sep 2, 2014 at 11:07 PM, Brian Smith wrote:
>> I actually think it is worth evaluating whether the padding
>> mechanism is practically useful as a security mechanism as
>> specified and with the above issues addressed. Has anybody
>> actually used frame padding to solve a real-world problem yet?
>> Has anybody tried to write a terrible-but-conforming
>> implementation that effectively undoes all the protection that
>> padding is supposed to offer? It seems likely that the answer to
>> both questions is "no."
> 

Gateway itself and 1.1 representation is a non-issue. Chunked encoding
trailers are available to relay padding after each DATA chunk.

What happens *inside* the 1.1-only hops is the big issue. The gateway
may need to use a CONNECT tunnel to communicate directly to the server
over 1.1 hop(s).

Amos

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Sep 2014 11:38:04 +0000

--------

>>> packet, perhaps with a 1 minute delay between frames. [...]

Yes ?

Last I looked DTLS didnt use TCP but UDP ?

Disregarding that:  How does the HTTP/2 layer know that the TLS
layer will in fact put everything in the frame into a single packet ?

The only way you can pad in HTTP/2 in that situation is so that all
frames have the exact same size.

The TLS layer should do that, if that is desired.

---

From: Guille -bisho- <[email-masked]>
Date: Wed, 3 Sep 2014 09:41:05 -0700

I would prefer adding a (non-compressible?) http header (with a random
data/length string) rather than supporting padding in the framing
layer. This will probably has less overhead, and If the application
has control over the HTTP/2 protocol to the level of specifying
padding, should be also capable of controlling the TLS layer. If the
application does not control TLS, would probably neither control
HTTP/2 details, so better implement the padding as a header, with
regular HTTP semantics.

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Sep 2014 12:00:35 -0700

On Tue, Sep 2, 2014 at 11:34 PM, Poul-Henning Kamp <[email-masked]> wrote:
> Brian Smith writes:
> the convenience of such an implementation,

Pretty sure I am being trolled here, but in case I'm not: It is common
for "security people" to give an exaggerated example to make a
vulnerability obvious, in order to save time debating things like "is
a millisecond too small to matter?" You can replace "1 minute" with "1
second" or virtual any other non-zero period of time and you still
have the same problem. Similarly, the problem still holds even if
every frame isn't in its own TCP packet, as long as any frame gets
split according to some function of the length of the padding of a
frame.

> when 3/4 of the browsers

I agree that what the Google Chrome team is doing here is amazing and
commendable, and that all the other browsers should do similar.

Cheers,
Brian

---

From: Jason Greene <[email-masked]>
Date: Wed, 3 Sep 2014 14:22:29 -0500

> split according to some function of the length of the padding of a

I guess I don’t see how this makes a difference? If an implementation has the ability to fit a frame and its payload on one packet, doesn’t it have the ability to fit two frames on the same packet? Further, there is really no guarantee that an H2 frame will not be split in a way that defeats padding in the first place.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Sep 2014 12:33:24 -0700

On Wed, Sep 3, 2014 at 12:22 PM, Jason Greene <[email-masked]> wrote:
> I guess I don’t see how this makes a difference? If an implementation has the ability to fit a frame and its payload on one packet, doesn’t it have the ability to fit two frames on the same packet?

That isn't the issue. The issue is with an implementation, such as a
proxy, that does something like "split the padding into its own frame
and put the data in another frame," and/or putting those split frames
in separate TLS records and/or TCP packets, which is currently allowed
(AFAICT) in draft 14.

> Further, there is really no guarantee that an H2 frame will not be split in a way that defeats padding in the first place.

Right. I mentioned that in my initial email. draft 14 needs additional
work to fix the definition of padding in order to make it secure. But,
putting the padding into its own frame will make the current problems
worse, not better.

Cheers,
Brian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Sep 2014 19:49:39 +0000

--------
In message <[email-masked]>

>commendable, and that all the other browsers should do similar.

Last I heard it was Microsoft who had chosen to support H2/plaintext
while Chrome was in the "TLS only" camp, has that changed ?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Sep 2014 13:12:33 -0700

On Sep 2, 2014, at 11:07 PM, Brian Smith wrote:

> partially or completely defeat the purpose of the padding.

Perhaps it will help if we clarify the assumptions here.  The first is
that the application is adding padding for a reason and not simply because
it is cool.  The second is that the rate at which they send data is under
their control, along with how that data is arranged in h2 padded form.
Deliberately sending h2 padding in a form that defeats its purpose is not
a design consideration.

> To make the

No.  There is no need to require that cars be unable to change lanes
just because some driver might be drunk at the wheel. Absolute security is
not a design goal.  It is sufficient to design a protocol that can be used
for a given purpose when that purpose is understood.

> Roy's separate-frame proposal.

Not at all.  And, no, the draft does not need to forbid bad implementations
of padding.  Warning against them is okay.

> reason is obvious; if not, I can explain more.)

No, it makes no difference whatsoever.  If the requirement was that they
only be able to process exactly 2^14 octets and you assume that an attacker
can inject 2^14 octets into the data without being detected, then something
might break somewhere.  However, there is nothing to suggest that the
break would have anything to do with a frame boundary.  For both the
current spec and any suggested changes, padding only works if both
the data and padding are written to the network in the same way, without
any difference at the padding boundaries, and they are both subject to
flow control in the same way.  An application with enough control over
h2 to generate h2 padding will also be capable of managing the amount
of data placed in each h2 frame.

> with how padding is specified, but the padding being in the same frame

I think you are assuming there is some magic boundary between frames
other than the length delimitation.  There is none.  An application can
write two frames just as easily as it can write one frame with optional
pad length and optional padding at the end.  The only difference is
where the overhead occurs.

If I thought that anyone would use padding on a regular basis, then
I would make the pad-length part of a fixed frame header that everyone
has to send.  My suggestion to use separate padding frames is partly
because I don't think it will be used at all, or at least only under
very specific circumstances that can justify the overhead.

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 03 Sep 2014 20:20:54 +0000

--------
In message <[email-masked]>, "Roy T. Fielding" w

>very specific circumstances that can justify the overhead.

Not to mention that padding makes absolutely no sense for plaintext...

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 4 Sep 2014 08:22:34 +1000

> in separate TLS records and/or TCP packets, which is currently allowed

Which is precisely why telling the framing layer about security padding is
a self defeating exercise.   TCP packet boundaries are just one potential
artefact that an observer can use to guess payload sizes, handling time is
another and I'm sure somebody could even observe CPU and/or power drain if
they really wanted to get spooky about it.

If we want security padding to be truly indistinguishable from real
payload, then don't tell the framing layer that it is padding.

Better to have no security than false security.

-- 
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: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 15:29:26 -0700

On 3 September 2014 15:22, Greg Wilkins <[email-masked]> wrote:
> If we want security padding to be truly indistinguishable from real payload,
> then don't tell the framing layer that it is padding.

The same is true here.  You've assumed that the TCP layer is getting
whole frames and then mapping that into segments.  That might be
likely, but it's not necessary.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Sep 2014 15:30:55 -0700

Truthfully, many folks who write applications will not think about this
kind of thing, and providing something which does handle this for them
automatically is likely quite a bit better than nothing.

Sometimes (reverse) proxies are called into the picture to help out with
some of these issues.
In such cases, having a mechanism that allows a proxy to manipulate the
data on the wire (likely with simple settings/rules for that
application/product/endpoint) with a guarantee that it is not affecting an
accidental semantic change is useful.

-=R

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Sep 2014 15:31:41 -0700

> their control, along with how that data is arranged in h2 padded form.

In order for padding to be a useful security feature, it must provide
end-to-end protection. That is, when the origin server sends
data||padding, that data||padding needs to be preserved and processed
as a single unit through all hops (i.e. by any/all proxies). But,
draft 14 doesn't say that. Therefore, the assumption that "how that
data is arranged in h2 padded form" is under the applications' control
is violated with in draft 14.

> Deliberately sending h2 padding in a form that defeats its purpose is not

I agree. But, *accidentally* defeating the purpose of padding *is* a
valid, and important, design consideration. My points are (1) the
current draft doesn't give enough advice about how to process padding
in a way that makes it useful, and (2) separating the padding into its
own frame makes such accidental defeat of the purpose of padding more
likely.

> for a given purpose when that purpose is understood.

In general, it is unreasonable to expect implementations to correctly
implement this security feature when the way to correctly implement it
is unspecified. The correct processing of padding, in particular, is
extremely non-obvious.

> of padding.  Warning against them is okay.

Then the resulting padding mechanism would not be useful to anybody.
If you can't rely on a specification-compliant implementation to
preserve the security properties of your padding, then you can't rely
on padding solving the security problems it was intended to solve, and
you need to find an alternative. But, if everybody needs to find an
alternative to HTTP/2 padding because its security properties are
unreliable, then there's no reason to specify padding in HTTP/2, and
it should just be removed from the spec.

> break would have anything to do with a frame boundary.

Currently, implementations are allowed to break up the data stream
into TLS records and/or TCP packets or whatever, in whatever way they
want. So, we have to assume some implementations will choose to split
the data stream at the frame boundary.

>  For both the
> flow control in the same way.

That is exactly my point. Since the padding and the data the padding
is protecting need to be treated as a single unit, and we have to
assume that at least some implementations will split the data stream
at the frame boundary, then it is safer and less error-prone to keep
the padding together with the data in one frame.

> An application with enough control over

Again, the data||padding sequence needs to be preserved end-to-end in
order for padding to be useful to any endpoint. We could try to figure
out if it is true that every endpoint has the level of control you are
assuming over its own networking stack, but it is obvious that the
endpoint cannot control what intermediaries do. That is why the
specification needs to minimize the risk that intermediaries will mess
up the padding, and that is why the current less-error-prone
padding-within-data-frame mechanism is better than padding in a
separate frame.

> where the overhead occurs.

Again, the data||padding must be preserved intact end-to-end in order
for it to be useful for an endpoint. What each individual endpoint is
capable of doing is not the issue; the issue is what intermediaries
are allowed to do.

> very specific circumstances that can justify the overhead.

I support the first part of your proposal, to remove the padding from
data frames. But, I am firmly against the second part of your
proposal, which is to add a new frame for padding, because the
specification of the secure and efficient use of separate padding
frames would be much more complicated, and that complication would
make the padding mechanism more error-prone.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Sep 2014 15:40:56 -0700

On Wed, Sep 3, 2014 at 3:30 PM, Roberto Peon <[email-masked]> wrote:
> Truthfully, many folks who write applications will not think about this kind
> of thing, and providing something which does handle this for them
> In such cases, having a mechanism that allows a proxy to manipulate the data
> on the wire (likely with simple settings/rules for that

Roberto, I agree with everything that you said. However, in practice
almost every application has to deal with HTTP/1.1 clients and/or
HTTP/1.1 proxies, so it seems like they need to find a solution above
or below the HTTP layer for these problems, for the foreseeable
future.

Process-wise, are there any interoperable implementations of the
padding feature that actually do something useful (i.e. using it for
real security), even as a proof of concept? I think there may be a
real gap between the theoretical benefits of having a padding
construct in HTTP/2 vs. the practical uselessness of it and/or its
unproven safety properties

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 15:45:59 -0700

On 3 September 2014 15:31, Brian Smith <[email-masked]> wrote:
> But, draft 14 doesn't say that.

Woah nelly, we don't mandate that for a number of reasons.

Firstly, because of what Roberto said.  Sometimes padding is added for
the purposes of enhancement.  For instance, we might have two backends
that might perform their own padding, but there might be resources
from each of those that we want to ensure are indistinguishable.  A
reverse proxy can add padding to ensure that.  That sort of additive
padding only increases the size of the anonymity set, which can't be
worse (though it may not be better, certainly.)

Similarly, a proxy serving many clients might want to prevent
length-based correlation between client-side and origin-server-side
exchanges by adding padding.

We don't want to prohibit those cases.  Generally speaking, the people
making the changes know better than we do.  Therefore, we use a SHOULD
and recommend that intermediaries not remove padding.

> So, we have to assume some implementations will choose to split

Let us be very careful to distinguish between potentially more secure
because we are providing the necessary tools and more secure even when
people do the wrong thing.  We're not aiming for the latter here.

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Sep 2014 15:47:33 -0700

On Wed, Sep 3, 2014 at 3:31 PM, Brian Smith <[email-masked]> wrote:
> as a single unit through all hops (i.e. by any/all proxies).

Sorry, allow me to correct myself here: It isn't true that the
data||padding needs to be preserved and processed as a single unit;
that is stricter than necessary. Instead, the padding needs to be
preserved, and if the data||padding is chopped up into smaller pieces,
that must be done independently of the boundary between the data and
the padding. But, note that the proposal to put padding in a separate
frame actually *encourages* chopping the data between the data and the
padding, and probably also encourages dropping the padding, which are
exactly the two things one must not do.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Wed, 3 Sep 2014 15:59:26 -0700

> and recommend that intermediaries not remove padding.

Draft 14 says:

   Padding can be used to obscure the exact size of frame content, and
   is provided to mitigate specific attacks within HTTP.  For example,
   attacks where compressed content includes both attacker-controlled
   plaintext and secret data (see for example, [BREACH]).

My comments are directed at the use of padding as a mitigation against
attacks like BREACH--i.e. the attacks for which the padding mechanism
"is provided to migitate." It seems like, with the way padding is
currently specified, no endpoint can rely on it to mitigate
BREACH-type attacks, for the reasons I gave. If that is intended, then
the security considerations section of the draft should be fixed to
indicate that, as right now it is very misleading.

The other text in the security considerations seems intended to
discourage the other possible uses of padding that you mention in your
email above. If that isn't intended then it should be clarified too.

> people do the wrong thing.  We're not aiming for the latter here.

Splitting at the frame boundary is not specified as the wrong thing
anywhere in the draft. And, isn't it very likely that many or even
most implementations will try to do that? In particular, it seems like
a good performance optimization to size TLS records to reduce or
minimize the number of split frames in a record, at least for some
endpoints, which would be the wrong thing to do with separate padding
frames.

Cheers,
Brian

---

From: <[email-masked]>
Date: Wed, 3 Sep 2014 23:16:37 +0000

Roberto-

Is there any reason a reverse proxy couldn't add padding at the TLS level?

-Keith

On Sep 4, 2014, at 0:35, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

Truthfully, many folks who write applications will not think about this kind of thing, and providing something which does handle this for them automatically is likely quite a bit better than nothing.

Sometimes (reverse) proxies are called into the picture to help out with some of these issues.
In such cases, having a mechanism that allows a proxy to manipulate the data on the wire (likely with simple settings/rules for that application/product/endpoint) with a guarantee that it is not affecting an accidental semantic change is useful.

-=R

On Wed, Sep 3, 2014 at 3:22 PM, Greg Wilkins <[email-masked]<mailto:[email-masked]>> wrote:

On 4 September 2014 05:33, Brian Smith <[email-masked]<mailto:[email-masked]>> wrote:

Which is precisely why telling the framing layer about security padding is a self defeating exercise.   TCP packet boundaries are just one potential artefact that an observer can use to guess payload sizes, handling time is another and I'm sure somebody could even observe CPU and/or power drain if they really wanted to get spooky about it.

If we want security padding to be truly indistinguishable from real payload, then don't tell the framing layer that it is 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.

This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Sep 2014 16:33:17 -0700

That would require far more surgery that I'd expect to want to see for a
reasonable proxy.
While it could be done at the TLS (or DTLS) or application layer, that is
not the layer with which most proxy writers are familiar.
It also means that one would have to re-do padding for any other encryption
mechanism/tunnel, which would be problematic sometimes.

Padding is still relevant for HTTP (without TLS) if you know you might be
traversing the internet via a VPN, for instance..
-=R

On Wed, Sep 3, 2014 at 4:16 PM, <[email-masked]> wrote:

> On Sep 4, 2014, at 0:35, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>> wrote:
>
> This email message is intended only for the use of the named recipient.
> Information contained in this email message and its attachments may be
> privileged, confidential and protected from disclosure. If you are not the
> intended recipient, please do not read, copy, use or disclose this
> communication to others. Also please notify the sender by replying to this
> message and then delete it from your system.
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 3 Sep 2014 16:51:34 -0700

> is violated with in draft 14.

We are talking about padding added within a secure e2e connection
(from the PoV of the client -- it might actually be a connection to
a gateway like Roberto described).  The upper layers (hopefully) have
no idea where the frames are because they are encapsulated by TLS
or some other encryption.

If we also have secure personal proxies in the mix that are doing
something weird with the data after decoding the encrypted traffic
and then reframing it and re-encrypting it to transport as an
intermediary to some distant user agent and NOT taking care to
transmit the data in a way that is independent of the raw content
of that data, then all bets are off.  I have no interest, whatsoever,
in designing to that scenario.

We already have a paragraph somewhere that says padding should
not be removed by an intermediary.  I have no problem with it also
saying that secure intermediaries shouldn't reveal patterns within
the content by writing them as distinct units when there is no need
to do so, though I'd think such a thing would be defined by TLS itself.

....Roy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 3 Sep 2014 17:25:36 -0700

On 3 September 2014 15:59, Brian Smith <[email-masked]> wrote:
> It seems like, with the way padding is
> BREACH-type attacks, for the reasons I gave.

If you use TLS end-to-end, without intermediation, I see no reason
that this can't be used to mitigate BREACH (or CRIME) attacks and
their ilk.  Certainly in cases where translation to HTTP/1.1 occurs,
that might not be true.

> anywhere in the draft.

Nor is sticking your head out of a moving subway carriage.

There is probably a line somewhere between that makes sense.  If you
are willing to provide text, I'm quite likely to accept it.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 4 Sep 2014 10:30:40 +1000

> automatically is likely quite a bit better than nothing.

I completely agree that applications often don't think about this sort of
thing.  As an infrastructure provider I like nothing more than providing a
service my users didn't even know that they needed.

But in this case the draft does not say that automatic padding is a bit
better than nothing.  In fact it says that padding without knowledge of the
data may be *counterproductive* and *easily defeated.*

So without guidance of how to generate padding in productive way, my
implementation will simply never generate padding and will discard any
padding received (because there are no channels available to pass it to
layers above).  Hhmmm I think Brian said this better:

> is unspecified. The correct processing of padding, in particular, is

+1

If there is a recommended way to improve security by generating padding,
then I will happily implement it.   But if there is not a recommended
general approach to padding then we are not going to magically create
secure automatic padding simply by saying that implementations may pad for
security.

cheers

---

From: Roberto Peon <[email-masked]>
Date: Wed, 3 Sep 2014 17:36:47 -0700

> data may be *counterproductive* and *easily defeated.*

I also said something about rules/configuration... :)
-=R

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 04 Sep 2014 14:20:23 +1200

On 4/09/2014 12:25 p.m., Martin Thomson wrote:
> On 3 September 2014 15:59, Brian Smith wrote:
>> It seems like, with the way padding is currently specified, no
>> endpoint can rely on it to mitigate BREACH-type attacks, for the
>> reasons I gave.
> 
> their ilk.  Certainly in cases where translation to HTTP/1.1
> occurs, that might not be true.

Assuming the BREACH (or CRIME) vulnerability exists in the TLS. The
use of TLS with the vulnerability is forbidden elsewhere in h2.

The multiplexing itself can potentially be a far more effective
discouragement against timing and power consumption attacks, since any
particular data or CPU fluctuation could be from any stream with
arbitrary DATA payload slicings.

Essentially streams 1 through n-1 and streams n+1 through 2^31-1, all
perform the same duty as random padding on stream n when the
connection is tunneled *in any way* (including TLS wrapped). Only they
do so with non-zero octets and random amounts of work to generate the
unrelated framing, which itself is better protection than padding
using nil octets could ever be.

On a related note, this muxing-vs-nil-padding benefit is gained most
prominently when a proxy is used since the streams there are also
muxed across origins. Padding has the upper hand on single-hop
connections, muxing on shared proxy connections.
 The mandate on proxies to keep padded traffic as a special case just
to preserve padding effectively forces a special connection and code
paths to be used for it, which potentially isolates and highlights it
for the observing attacker.

> 
>>>> So, we have to assume some implementations will choose to
>>>> split the data stream at the frame boundary.
>>> 
>>> Let us be very careful to distinguish between potentially more
>>> secure because we are providing the necessary tools and more
>>> secure even when people do the wrong thing.  We're not aiming
>>> for the latter here.
>> 
>> Splitting at the frame boundary is not specified as the wrong
>> thing anywhere in the draft.
> 

Except on subways where it is relevant.

The discussion was about splitting of DATA frames. How to split a
frame with DATA+padding ? ... drop the padding and split is the
obvious option, both simple and fast code. With no reasons speciying
otherwise that is what will be widely implemented.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 4 Sep 2014 08:25:07 +0200

On Wed, Sep 03, 2014 at 02:22:29PM -0500, Jason Greene wrote:
> I guess I don?t see how this makes a difference? If an implementation has the
> ability to fit a frame and its payload on one packet, doesn?t it have the
> ability to fit two frames on the same packet? Further, there is really no
> guarantee that an H2 frame will not be split in a way that defeats padding in
> the first place.

There are many unoptimized implementations of many protocols which do :

    write(socket, frame, length)

with TCP_NODELAY set, resulting in exactly one packet + PUSH flag sent for
each frame.

You can even see this with some HTTP servers sending headers in multiple
packets. I think this is the case Brian cares about.

Willy

---

From: Guille -bisho- <[email-masked]>
Date: Thu, 4 Sep 2014 00:30:40 -0700

I still don't see the benefits of supporting padding at the framing
layer. The padding can be equally controlled from application by
adding a random-length, random-content http header, with similar
effectiveness, and with the side benefit that it's backwards
compatible. If a browser starts detecting a ton of requests against
similar url can enable and add this header with little impact to
compatibility. And we will get rid of a lot of complexity in the
HTTP/2 spec.

Non browsers are much less susceptible to BREACH/CRIME attacks, can't
be controlled that easily, so having padding at framing doesn't
translate into a critical benefit in security for client http2 library
implementations.

On top of that:
- padding doesn't make sense for plain-text http2, is a waste having
it taking space on all frame headers. TLS should protect against
BREACH/CRIME on its own.
- when using VPNs (as suggested use-case), better have that vpn handle
this properly at that layer, or any usage of HTTP/1 will make them
still vulnerable.
- for protecting against client traffic matching when using
intermediate parties, timing will be probably so easy to exploit that
the use-case is minimal IMHO.

And finally, as discussed, the padding at http/2 framing level is hard
to do it right with the non-obvious relation between frame lengths and
actual network packets, the interaction with intermediate parties and
so on.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 04 Sep 2014 07:50:07 +0000

--------
In message <[email-masked]>

>as a single unit through all hops (i.e. by any/all proxies).

It's not that simple once you start to think about it.

We have two padding issues:  header-sets and content.

For header-sets the standard mandates modifications along the path,
Connection: and (X-)Forwarded-For being the primary examples.

The effects of HPACK and available compression states also
adds to our trouble here.

There is simply no way the browser or PHP code can gain any insight
into what amount of padding would be needed mask these changes,
so padding header-sets seems like it must be hop-by-hop.

That doesn't make it easier though.

A client proxy has no insight into how large any individual web-apps
header-set can be, so the only truly safe algorithm would be:

	receive(request)
	strip_padding(request)
	if size(request) > cur_max:
		cur_max = size(request) + random(N...M)
	pad(request, cur_max)
	send(request)

cur_max will eventually be determined by the most silly PHP programmers
use of :query arguments and the most ridiculous cookies on the
entire web.

Or worse: this algorithm is also a trival way to make clients DoS themselves.

A clear no-go in my mind.

A more robust but less secure algorithm would be to merely randomize
the size of the header-set:

	receive(request)
	strip_padding(request)		// XXX: or not ?
	pad(request, random(N...M))
	send(request)

This will only be OK from a security point of view if the
browser and application developers understand that masking
depends on them always using roughly same-size header-sets.

Most web-shops do not do this today:  It is utterly trivial to tell
browsing wares from adding wares to shopping basket from paying and
checking out, simply based on packet-cluster sizes.

The most practical way to pad header-sets would be to define a Pad:
header.

Proxies not actively participating in Padding should treat it as
end-to-end, which existing HTTP/1 proxies automatically will do.

"Padding-aware" proxies should treat it as hop-by-hop.

HPACK would spit out Pad: as the last header in verbatim mode, only
then can the necessary length be calculated.

All in all, it is not obvious to me that all that complexity would
add significant security value over the true and KISS end-to-end
solution:  Browsers emit a random sized "Junk:" header on all TLS
requests, and servers respond in kind.

For content proxies are generally hands off, but we are not quite
in the clear yet:

For instance this is going to happen a lot:

	A website is implemented across a number of webservers
	using the well known static/images/database/... pattern.

	These webservers most likely talk plaintext-HTTP.

	A proxy or load-balancer wraps all the traffic up,
	adding HTTP/2 and/or TLS.

So the proxy has to add the content padding ?

Based on what ?

Configured how ?

That's not going to happen...

And how does the padding survive further HTTP/1.1 <-> HTTP/2.0
conversions ?

It seems to me that padding the content can only happen at the
application level, not necessarily by the application, it could be
done by "middleware", CMS or web-server, but it should happen where
the content type is authoritatively known so the content itself can
be padded.  (ie: adding comments to HTML/CSS/JS etc.)

There is whole level of pain in form-submission here, where the
web-app should inform the client how much it should pad the
returned form-data, but I think that would be W3C territory ?

It is not at all obvious to me where the responsibility for padding
should be placed, and the unintended interactions of too many
players, application, middleware, HTTP/2 and TLS, all having their
laddle in the pot worries me, both wrt. security and performance.

But nowhere in this picture do I see padding inside the HTTP/2.0
frames being part of the solution.

In particular because 50%+ of all HTTP traffic is plain-text with
no privacy-concerns which doesn't want and needs neither TLS nor
padding.

I think we should remove padding from the HTTP/2 frames.

On the other hand, I think there is good value in Roys proposal for
a hop-to-hop "NO-OP" frame type, if nothing else for debugging.

Specific implementations which know they have full and true end-to-end
visibility can obviously use that to implement hop-by-hop padding.

---

From: <[email-masked]>
Date: Thu, 4 Sep 2014 09:22:07 +0000

+1

> All in all, it is not obvious to me that all that complexity would add significant security value over the true and KISS end-to-end
> solution:  Browsers emit a random sized "Junk:" header on all TLS requests, and servers respond in kind.

+1

> On the other hand, I think there is good value in Roys proposal for a hop-to-hop "NO-OP" frame type, if nothing else for debugging.
> Specific implementations which know they have full and true end-to-end visibility can obviously use that to implement hop-by-hop padding.

+1

---

From: Jason Greene <[email-masked]>
Date: Thu, 4 Sep 2014 11:15:24 -0500

> with TCP_NODELAY set, resulting in exactly one packet + PUSH flag sent for

Sure but my point was that an implementation that uses padding has to be aware of and have control of the transport layer to ensure that padded data (whether it be a field or another frame) is always included with the payload (e.g. writev, cork, etc). Even then its still not perfect since small MSS/MTU could fragment a payload from its padding.
> packets. I think this is the case Brian cares about.

Right, and such servers are not likely to use padding correctly.

---

From: Brian Smith <[email-masked]>
Date: Thu, 4 Sep 2014 10:23:13 -0700

> or some other encryption.

The gateway like Roberto described may be a normal HTTPS proxy. For
example, consider a website that is directly exposed to public web
traffic. Then that site that starts getting DoSed, and the website
administrator decides to throw CloudFlare in front of the site. If the
site was using the HTTP/2 padding mechanism to mitigate BREACH, like
the draft 14 suggests, then it would be bad if adding CloudFlare to
the mix resulted in the BREACH mitigation being stripped out. So, it
is useful to specify how a proxy like CloudFlare can preserve the
BREACH mitigation properties of padding.

(Again, it doesn't seem like a good idea to rely on HTTP/2 padding to
mitigate BREACH anyway, because you still have to deal with HTTP/1.1
proxies. But, that is what draft 14 says HTTP/2 padding is for!)

> in designing to that scenario.

Proxies that speak HTTP over TLS across the open internet to an origin
service, and then relay they traffic to end users as HTTP over TLS are
becoming increasingly common. That's a major part of CloudFlare's
business, for example. Personal proxies of this form are also common
and probably becoming more so, so I don't think they should be
discounted either.

> to do so,

Adding such text is necessary, if the spec is going to continue to
claim that padding is a way to mitigate BREACH. Basically, the spec
should say that intermediaries must not do any splitting of DATA
frames (at the TCP layer, TLS layer, or HTTP layer) as a function of
the data/padding boundary, because such splitting would likely leak
how much padding was used, defeating the purpose of the padding.

Again, this would be more complicated to specify if padding were a
separate frame, e.g. because frames can be reordered and/or have other
frames inserted between them, and you'd have to write additional text
to prohibit such things in the case of a separate padding frame. It
would be a lot of work, that adds real risk, for not much benefit. It
makes more sense to stick with what is already in draft 14, if HTTP/2
is going to have any padding mechanism at all.

Cheers,
Brian

---

From: Guille -bisho- <[email-masked]>
Date: Thu, 4 Sep 2014 10:59:24 -0700

+1

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 08:48:49 +1000

> to do so, though I'd think such a thing would be defined by TLS itself.

I do have a problem with any text like this.  Writing scalable asynchronous
robust code is really difficult.  Adding in requirements that writing
patterns
must not reveal anything about the content is an escalation in complexity
that I do not think is justified or even achievable.  Next we'll be
requiring
constant time comparisons and other aspects.

It is just not reasonable to expect every HTTP2 implementation to be
hardened against these kind of issues.     They have enough difficult
concerns
to create scalable robust http infrastructure without needing to meta
analyse
every algorithm to ensure that it does not reveal sizes or frame boundaries
in some fashion.

I cannot see how we are going to test that applications actually implement
such requirements anyway.  Do you fail a test if a TCP frame boundary
happens
to fall on a h2 boundary?  Or is it a statistical test?       Without wide
testing,
there is no certainty that such recommendations will be well implemented,
so
applications that care about this will have to implement their own solution
at
another layer.

regards

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Sep 2014 16:10:01 -0700

On 4 September 2014 15:48, Greg Wilkins <[email-masked]> wrote:
> such requirements anyway.

Don't set the perfect as the enemy of the good.  Many security
decisions are - at first assessment - difficult to test on these
grounds, but please don't extrapolate from seemingly hard to
impossible.

Rather than contemplate the infinite and byzantine complexity that
might arise, perhaps it would help to demonstrate how a feature like
this could provide security.  As has been discussed, Twitter pad
profile images so that it is hard for a passive observer to use
traffic analysis to determine which profile has been accessed by a
given user.  I don't know the specifics, but the idea being that you
might reveal that you are accessing a profile, but individual requests
don't leak details because they now enjoy k-anonymity with a very
large k.  The same process has been used in other places to avoid
side-channel leaks like that.

Now, it's true that Twitter are probably just padding the images
themselves, exploiting the fact that lossy compression can be made
arbitrarily un-lossy.  But that general technique might not apply to
other types of resource.  And expanding the file size has negative
effects on the space that resources use in caches and other things.
It's marginally more efficient to pad at the protocol layer.  TLS
padding is an option, but it's more limited in scope and it might not
be accessible.

Determining the set of resources that you want to provide anonymity
within is easy.  Determining the range of sizes over which you need to
operate is easy.  Padding to the maximum size of that set is easy.
Determining that this is the thing you need to protect in order to
ensure that you haven't leaked critical information...well...

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 10:22:37 +1000

On 5 September 2014 09:10, Martin Thomson <[email-masked]> wrote:

> given user.

I'm not disputing that padding can be used to improve security.

Your example is indeed a good example of security padding.   But I
just don't see how that example could be translated to an example that
automatically applies padding at the framing layer.

The framing code that segments the profile image into h2 frames
will not that that it is a profile image, it probably wont even know it is
an
image or that it is sending it over TLS.    More over, the padding in this
case does not need to be frame by frame and adding padding to the
end of the stream would be sufficient.    Also, as this example clearly
shows, applications that care can already pad without help from the
framing layer and in this case any padding automatically applied by h2 will
just be wasted bandwidth.

Are there any examples of security padding that can be applied by the
framing layer?     When is it that a framing layer can make up for lack of
caring about security by an application?

I do not dispute that padding can be a good security measure, nor that
there are some use-cases that care about side channel leakage from
frame boundaries, processor timing, power consumption, CPU cycles
etc.

What I am disputing is that providing padding within the h2
framing layer can help those use-cases in any meaningful way?

If we are considering adding restriction on how padding can be rendered
into TCP frames, then my dislike of padding is escalated to can't live with
it.

regards

---

From: Martin Thomson <[email-masked]>
Date: Thu, 4 Sep 2014 18:36:36 -0700

On 4 September 2014 17:22, Greg Wilkins <[email-masked]> wrote:
> framing layer?

Oh, that, and the word "automatic" suggest that you are asking for
something that is simply not possible.  You need information to pass
from the application to the framing layer in order to enact any
sensible changes.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 11:43:38 +1000

> from the application to the framing layer in order to enact any

So the supplementary question is, what applications care enough about
security
padding but cannot pad by any other means than tunnelling that care down to
the
framing layer of a specific protocol?

Do we have any security use-cases that are enabled by the availability of
padding
in the framing layer?   Automatic padding had been suggested by others, but
I agree
with you: that is an impossible use-case?

cheers