Subject: Frame Length Restrictions

From: Jeff Pinner <[email-masked]>
Date: Wed, 16 Apr 2014 17:34:35 -0700

I put together a pull request to replace the frame length restriction with
an HTTP application layer restriction that I would like the working group
to consider.

https://github.com/http2/http2-spec/pull/456

Of particular note is that this is in contrast to a previous decision made
by the working group (albeit by coin toss in Seattle) which can be found

https://github.com/http2/http2-spec/issues/260

With the addition of padding to the framing layer, I believe it is
preferable to implement the frame length requirement at the HTTP layer to
allow intermediaries to pad frames without running into frame length
restrictions.

Thanks!
- Jeff

---

From: Roberto Peon <[email-masked]>
Date: Wed, 16 Apr 2014 18:24:27 -0700

Makes sense to me.
-=R

---

From: David Krauss <[email-masked]>
Date: Thu, 17 Apr 2014 09:50:41 +0800

On 2014–04–17, at 8:34 AM, Jeff Pinner <[email-masked]> wrote:

> With the addition of padding to the framing layer, I believe it is preferable to implement the frame length requirement at the HTTP layer to allow intermediaries to pad frames without running into frame length restrictions.

Is there a particular reason to add back both bits as opposed to just one? A 64K frame with 16K of information is quite a lot of padding.

Also, an intermediary can already maximize available padding with a policy of preferring to send empty padding frames. There’s no limit on the ratio of incoming padding to data, so an intermediary which simply preserves incoming padding must already be prepared to send anything.

In any case, it sounds like you’re solving a specific problem which maybe should be mentioned in the RFC. Other than that though, I have no real objection… it’s a coin-toss issue.

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 16 Apr 2014 20:24:12 -0700

One of the requirements for the padding design was to be able to pad the
data by only a single byte. Using a separate padding frame was rejected
because it only allowed padding by a minimum of 8 bytes. Receiving and
trying to pad a full 16K of data with the current spec requires splitting
the frame, which of course requires a minimum of 8 bytes of padding.

We originally dropped the length from 64K to 16K in order to do two things:

1) Increase the likelihood that we force implementations to have to use
continuation frames.
2) Prevent implementations from sending so much data in a single frame that
they cannot respond to incoming re-prioritization information quickly.

Moving the 16K requirement to the HTTP layer still meets those two goals,
and increasing the length frame allows increasing the padding length by a
single byte, even if the full 16K is sent in a frame.

On Wed, Apr 16, 2014 at 6:50 PM, David Krauss <[email-masked]> wrote:

>
> On 2014-04-17, at 8:34 AM, Jeff Pinner <[email-masked]> wrote:
>
> Is there a particular reason to add back both bits as opposed to just one?
> A 64K frame with 16K of information is quite a lot of padding.
>
> Also, an intermediary can already maximize available padding with a policy
> of preferring to send empty padding frames. There's no limit on the ratio
> of incoming padding to data, so an intermediary which simply preserves
> incoming padding must already be prepared to send anything.
>
> In any case, it sounds like you're solving a specific problem which maybe
> should be mentioned in the RFC. Other than that though, I have no real
> objection... it's a coin-toss issue.
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Apr 2014 10:05:25 -0700

> allow intermediaries to pad frames without running into frame length

The natural follow-on question is: if we allow 64K frames, why not let
a header block fill the entire thing?  It's not like the smaller frame
size has a flow control advantage.  The only advantage is in ensuring
that padding space is available.  But limiting the length to 32K would
work adequately for that too.

---

From: Jeff Pinner <[email-masked]>
Date: Thu, 17 Apr 2014 10:35:29 -0700

> work adequately for that too.

The header length limit was meant to force implementations to implement and
test continuation frames and these become more likely with a 16K limit than
a 32K limit.

Personally I feel that this is unnecessary, and that the same could be
achieved with a comprehensive test suite rather than with a MUST in the
protocol, but that wasn't the consensus at the San Francisco interop
meeting.

---

From: David Krauss <[email-masked]>
Date: Fri, 18 Apr 2014 14:54:16 +0800

On 2014–04–17, at 11:24 AM, Jeff Pinner <[email-masked]> wrote:

> 2) Prevent implementations from sending so much data in a single frame that they cannot respond to incoming re-prioritization information quickly.
> 
> Moving the 16K requirement to the HTTP layer still meets those two goals, and increasing the length frame allows increasing the padding length by a single byte, even if the full 16K is sent in a frame.

Actually, allowing 64K of actual padding does make such head-of-line blocking of a PRIORITY frame possible. There would be no really good reason for it to happen, but an implementation which minimizes the number of padding blocks by maximizing their size is conceivable.

Another way to allow fine-grained padding would be to cap the frame length sans padding at 16K – 7 bytes (16377 bytes). To add a single byte to a full frame, you would remove the 6 bytes of padding and 1 byte of PAD_LOW field, and add an 8-byte empty data frame.

Architecturally, quadrupling the frame capacity to get 7 extra bytes is a little odd. Doubling to 32K would also do the job.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 19 Apr 2014 16:36:34 +1000

Hi Jeff,

We need to show strong consensus on-list to overturn that, despite being a coin toss. If we want to get this into the next implementation draft, it needs to be demonstrated in the next ~2 days.

I.e., if there's a number of folks who feel this is a no-brainer, great; otherwise, probably not.

Who supports this, and does anyone have a problem with doing it? 

Cheers,

On 17 Apr 2014, at 10:34 am, Jeff Pinner <[email-masked]> wrote:

> I put together a pull request to replace the frame length restriction with an HTTP application layer restriction that I would like the working group to consider.
> 
> Of particular note is that this is in contrast to a previous decision made by the working group (albeit by coin toss in Seattle) which can be found
> 

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 18 Apr 2014 23:40:24 -0700

No-brainer, yes.
-=R

On Fri, Apr 18, 2014 at 11:36 PM, Mark Nottingham <[email-masked]> wrote:

> Hi Jeff,
>
> We need to show strong consensus on-list to overturn that, despite being a
> coin toss. If we want to get this into the next implementation draft, it
> needs to be demonstrated in the next ~2 days.
>
> > I put together a pull request to replace the frame length restriction
> with an HTTP application layer restriction that I would like the working
> group to consider.
> >
> > Of particular note is that this is in contrast to a previous decision
> made by the working group (albeit by coin toss in Seattle) which can be
> found
> >

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 19 Apr 2014 19:08:02 +1200

> -=R

I'd like to know why the padding of under 8 bytes is required on frames
already so large that they do not fit into a single TCP Ethernet packet
to begin with.

Perhapse 16K-8 should be palced as the HTTP layer limitation?

Amos

---

From: <[email-masked]>
Date: Sat, 19 Apr 2014 19:08:29 +0000

Regarding this part of the pull request...

The application data in DATA frames ... MUST NOT exceed 2^14-1 (16,383) octets in length. An endpoint MUST treat the receipt of a larger frame as a FRAME_SIZE_ERROR error ...

...and the pending pending re-introduction of gzip compression at the frame layer [1].

Is the size limit for application data _before_ or _after_ compression (specifically transfer layer compression)?

If the size limit is _before_ compression, it would kill the compression factor.  The only way to get a reasonable compression factor with frame-by-frame compression is to fill each frame with as much compressed data as possible (see [2]).

On a related note, if you're adding back the two bits, why not let application data use at least 32K?  Using at least 15 bits has advantages for the frame-by-frame compression factor - the max gzip "window bits" is 15 and so is better suited to 32K frames.

-keith

[1] See the thread "Transfer-codings, mandatory content-coding support and intermediaries"

[2] http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0156.html

________________________________________
From: [email-masked] [[email-masked]]
Sent: 19 April 2014 08:36
To: Jeff Pinner
Cc: HTTP Working Group
Subject: Re: Frame Length Restrictions

Hi Jeff,

Cheers,

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: Patrick McManus <[email-masked]>
Date: Sat, 19 Apr 2014 18:07:52 -0400

On Sat, Apr 19, 2014 at 3:08 PM, <[email-masked]> wrote:

> The application data in DATA frames ... MUST NOT exceed 2^14-1 (16,383)
> octets in length. An endpoint MUST treat the receipt of a larger frame as a
> FRAME_SIZE_ERROR error ...
>
> Is the size limit for application data _before_ or _after_ compression
> (specifically transfer layer compression)?
>
>
>
The size of the DATA frame is capped  at 16KB in order to facilitate
effective multiplexing and prioritization - it only the on-the-wire size
that matters.

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 20 Apr 2014 18:07:27 +1200

On 20/04/2014 10:07 a.m., Patrick McManus wrote:
> On Sat, Apr 19, 2014 at 3:08 PM, K.Morgan wrote:
> 

There is also a trade-off here between good compression factor and
reducing memory overheads in the recipient to keep in mind here.
 An abuser can send far less (exponentially less?) payload in compressed
16K chunk than they can in a 32K chunk.

Maybe the 14-bit/15-bit compression difference is an added bonus on
protecting against these kinds of abuses.

Amos

---

From: Adrian Cole <[email-masked]>
Date: Sun, 20 Apr 2014 09:25:53 -0700

I'm fine with this.

-A

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 11:16:39 -0700

On 19 April 2014 15:07, Patrick McManus <[email-masked]> wrote:
> it only the on-the-wire size that matters.

This is, I think, the reason that this change makes me uncomfortable.
We have a small frame for a good reason; and allowing padding to
greater than that size is in direct opposition to that.

(I briefly thought that this proposed change wouldn't cause issues in
this regard, because the padding could be easily discarded.  But
that's a great way to negate any benefit gained by padding.)

---

From: Johnny Graettinger <[email-masked]>
Date: Mon, 21 Apr 2014 14:55:14 -0400

Also, to date HTTP/2 hasn't made it particularly easy for intermediaries to
'forward' frames without deeply understanding stream state. It does seem
odd to make moves in this direction now, and I'd appreciate an explanation
of what this is buying. Eg, unless you're running an intermediary tunneling
1:1 connections, including all settings affecting compression state, you'll
still have to decode & re-compress headers with an entirely different
compression context anyway. Compared to that, the complexity overhead of
re-framing DATA seems pretty small.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 21 Apr 2014 13:20:21 -0700

A few comments below:

On Mon, Apr 21, 2014 at 11:55 AM, Johnny Graettinger <
[email-masked]> wrote:

> Also, to date HTTP/2 hasn't made it particularly easy for intermediaries
> to 'forward' frames without deeply understanding stream state. It does seem

Padding as a security mechanism is not designed with the intent of
minimizing frame size, but rather increasing it to obscure the true size of
the data. Nor is it intended to be simple to proxy (for example, adding or
removing padding affects stream flow control and thus back-pressure across
proxies, even though it has nothing to do with the size of the resources
allocated to a stream).

In particular, attempting to add padding without revealing information is
also not trivial.

In the current implementation, an intermediary that attempts to add padding
to a data frame cannot pad a 16K frame using less than 8 bytes of padding.
If adding a minimum of 8 bytes of padding is acceptable, there we can get
away with using a PADDING frame and removing per-frame padding entirely,
greatly simplifying the spec. If it is not acceptable, then we need to
either make frames bigger or make the allowable application data smaller.

>> greater than that size is in direct opposition to that.

We have a small frame size in an attempted to protected against
non-adoption due to anticipated performance/correctness problems with
yet-to-be-written implementations.

For example, the small data frame size was an attempt to prevent
implementations from feeling "non-responsive" to changes in priority and
thus prevent people from adopting HTTP/2 because it felt slower. There is
nothing in the protocol, however, that prevents sending 8k or less data
frames, just as there is nothing in HTTP/1.1 that prevents sending small
chunk sizes. In fact, if the HTTP/2 connection is only used to transfer a
single resource, the additional overhead of small data frames is completely
unnecessary.

Similarly, the small header block size was chosen to make sure
implementations exercised continuation frames so that they would detect
implementations bugs early.

A small frame size is not however a prerequisite to, nor necessarily a
hinderance of, adoption. SPDY has a 16MB frame size for example.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 14:06:08 -0700

On 21 April 2014 13:20, Jeff Pinner <[email-masked]> wrote:
[lots]

I was there :)

I guess that I just don't find the problem particularly appealing.  I
understand the mathematics; if an originating server or client fills
packets precisely, there is no space to use for padding and the only
option is an 8 byte chunk.  It's probably more due to a reluctance to
accept the premise.

The part of the premise that is most problematic is the one where you
assume the intermediary cannot re-frame packets.

A sender that knows that it might want to pad can easily frame to in
16376 byte chunks.  And then any amount of padding is available to
them.  And that option is available to every sender, intermediary or
otherwise.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 21 Apr 2014 17:03:34 -0400

> hinderance of, adoption. SPDY has a 16MB frame size for example.
Even though I'm not opposed to your change, I think you're mis representing
the genesis of the 14 bit data length.

The smaller frame size requirement comes directly from experience with SPDY
that shows implementations using content length as frame size for
convenience and then having quality of implementation issues around
priority. (at one point I tested 4 in a row that all did that.) So that's
not speculative.

Of course they could and should use smaller values, but the protocol is
stronger if it leads them to do the right thing automatically. That's the
reason for the change - I thought it should be smaller than 16KB myself but
that's where we ended up.

Your change leaves the 14 bit length restriction in place for http data, it
just opens the door for it to be obviated by padding. I'm not worried about
that, it would take a deliberate design to do that and there are plenty of
other ways to deliberately not honor priority if that's what you're trying
to do :) We still steer implementers in the right direction.

[for clarity I would tweak your change to call out the 14 bit restriction
more strongly inline than just "see xref"]

-P

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 21 Apr 2014 14:07:54 -0700

> On 21 April 2014 13:20, Jeff Pinner <[email-masked]> wrote:
Best quoting ever :)

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 21 Apr 2014 14:56:51 -0700

Alternatively, and equally acceptable to me, would be to leave the 14-bit
length field and further restrict the HTTP layer to only use 2^14 - 9 bytes
(to allow for 8 bytes of padding).

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 21 Apr 2014 14:58:46 -0700

I'm just going to chime in because I think Mark wants voices to assess
consensus at least.

Like back at the SF interim, I don't care too much about this. I think
re-framing is not a big deal. But if vendors want to avoid reframing, I
don't mind enabling them to do that. That said, I don't see that it's
necessary to move the application data/headers length check to the HTTP
layer, rather than the framing layer. The information is all there in the
framing layer. I think the main reason to move it to the HTTP layer is if
we want a HTTP/2 framing layer intermediary not to have to do this length
check. I understand that Roberto thinks this is desirable. It was not clear
to me if Jeff did too. I don't feel too strongly about this either, but
mostly just wanted to call it out.

Again, I basically don't really care :) As long as we still have the checks
somewhere and we still have that 14 bit data length check, then I'm fine
with this.

Cheers.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 15:22:17 -0700

> (to allow for 8 bytes of padding).

I think perhaps you need to speak a little more about why reframing
doesn't work for you.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 21 Apr 2014 15:57:59 -0700

> I think perhaps you need to speak a little more about why reframing

The goals here are:

1) achieve a desired (to-be-provided) frame length distribution
2) achieve this with the minimum amount of padding
3) achieve the desired distribution regardless of the input data stream

The intend is not to avoid reframing, it's to avoid a discontinuity in the
output distribution.

With the current draft, I have to pad assuming that at some point I will
receive a frame with the maximum application data size. This frame cannot
be padded arbitrarily, it must have a minimum 8 bytes of padding since any
padding requires splitting and so I must add a frame header.

Now, if I operate under the assumption that an adversary can force my
server to produce full size frames, then at any point the adversary can
force my implementation to add at least 8 bytes of padding, revealing
information about the targeted distribution. To prevent this, any padding
distribution must pad by at least 8 bytes.

Now, if this is acceptable, then it must be acceptable to always pad by at
least 8 bytes. In which case the current padding implementation is overly
complicated and we should just be padding via a PADDING frame (or perhaps
two, one subject to flow control and one not).

If this is not acceptable, then either the frame size has to increase or
the allowable application size decrease.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 16:16:21 -0700

> The intend is not to avoid reframing, it's to avoid a discontinuity in the

Then those goals can be achieved without changing anything.
Re-packaging frames into smaller chunks allows you to meet those
goals.

I can understand if there are END_SEGMENT flags in place that this
complicates things.  But completely-full frames with END_SEGMENT
should be a pathological case.

> Now, if I operate under the assumption that an adversary can force my server
> to produce full size frames, [...]

This is where we have the disconnect.  If an adversary has that much
control over your code, I don't trust *anything* you are sending me.
What's padding going to do to help then?

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 21 Apr 2014 17:01:47 -0700

> server

My assumption here, is similar to BREACH, user input can be reflected in
HTTP response bodies, which the upstream servers naively split into 16K
data frames using whatever HTTP/2 library they have chosen.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 17:10:44 -0700

On 21 April 2014 17:01, Jeff Pinner <[email-masked]> wrote:
> HTTP response bodies, which the upstream servers naively split into 16K data
> frames using whatever HTTP/2 library they have chosen.

Presumably you could take those 16K frames and split them into 16K-9
frames before adding padding.  You could even ask the upstream servers
not to produce 16K frames.  You could even ask the upstream servers to
pad properly.

---

From: Jeff Pinner <[email-masked]>
Date: Mon, 21 Apr 2014 17:30:01 -0700

> not to produce 16K frames.  You could even ask the upstream servers to

I could only split frames if I always split frames, otherwise I would leak
the original message size. If I always split frames than this is equivalent
to having an 8-byte minimum on padding. In this case we should just use a
specific padding frame instead of adding padding fields to every data frame
based on flags. Especially since that removes the need to check if the
padding length exceeds the frame length.

So let me ask that question then: Why is an 8-byte minimum on padding
unacceptable?

---

From: Roberto Peon <[email-masked]>
Date: Mon, 21 Apr 2014 19:06:24 -0700

I don't have a working attack in hand, but essentially it leaks info:
With an 8 byte minimum, it becomes easier to defeat the purpose of
padding-- one constructs a test which looks for an 8-byte jump in output
size to determine the actual output size.
-=R

---

From: David Krauss <[email-masked]>
Date: Tue, 22 Apr 2014 10:44:18 +0800

I don’t see what an 8-byte minimum, or dedicated pad frames, would change at all. Such an implementation is already conforming, just not of utmost quality. Checking padding length against frame length is just one simple input validation step among many others.

The way to always allow 1 extra padding byte, without bigger frames, is to require the content of any frame to leave at least 7 bytes for potential padding (6 bytes plus the PAD_LOW field). 8 bytes exactly can always be added by a frame split. The cost imposed on unpadded data transfer is 7/16383 = 0.04%.

On the other hand, if an origin or client isn’t using padding, there’s no reason for any such restrictions for the preservation of padding that doesn’t exist. Padding is strictly optional in the first place.

So, why not just mention that 7 bytes of slack are required in every frame, *if* the sender wants to allow intermediaries good flexibility in re-padding the stream. No matter what we do, some endpoints and intermediaries are going to ignore security, and getting a perfect end-to-end connection will take some alignment of the stars.

On 2014–04–22, at 10:06 AM, Roberto Peon <[email-masked]> wrote:

> With an 8 byte minimum, it becomes easier to defeat the purpose of padding-- one constructs a test which looks for an 8-byte jump in output size to determine the actual output size.
> -=R
> 
> 
> I could only split frames if I always split frames, otherwise I would leak the original message size. If I always split frames than this is equivalent to having an 8-byte minimum on padding. In this case we should just use a specific padding frame instead of adding padding fields to every data frame based on flags. Especially since that removes the need to check if the padding length exceeds the frame length.
> 
> So let me ask that question then: Why is an 8-byte minimum on padding unacceptable?
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Apr 2014 21:03:43 -0700

> padding length exceeds the frame length.

Not so.

Rather than 8 bytes of overhead every 2^14-1 bytes, you have 8 bytes
of overhead every 2^14-9 (or 8, which is be sufficient).  If that's a
problem, then any sort of framing overhead is a problem.

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 22 Apr 2014 00:48:37 -0700

> problem, then any sort of framing overhead is a problem.

I don't think I follow. Are you saying that the overhead of always
splitting frames is negligible so it's ok to always split frames in order
to not have a discontinuity in padding?

That seems to be saying that implementations that don't always split frames
could have an issue but they should just "do the right thing" instead of
forcing it by calling out the restriction in the protocol itself.

If that is the argument (and I'm not saying it is) then it seems antithesis
to restricting the frame length in the first place. Arguably
implementations that care about responsiveness should "do the right thing"
and restrict the data payloads instead of having the protocol force them to
do so at the expense of applications that either do not multiplex or do not
care about interactivity.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Apr 2014 17:54:58 +1000

Hey Jeff,

It feels like this conversation isn't done yet, and we're very much overdue for the next implementation draft. So, let's continue, but not block on it, OK?

Thanks,

On 22 Apr 2014, at 5:48 pm, Jeff Pinner <[email-masked]> wrote:

> On Mon, Apr 21, 2014 at 9:03 PM, Martin Thomson <[email-masked]> wrote:
> 
> Not so.
> 
> I don't think I follow. Are you saying that the overhead of always splitting frames is negligible so it's ok to always split frames in order to not have a discontinuity in padding?
> 
> That seems to be saying that implementations that don't always split frames could have an issue but they should just "do the right thing" instead of forcing it by calling out the restriction in the protocol itself.
> 
> If that is the argument (and I'm not saying it is) then it seems antithesis to restricting the frame length in the first place. Arguably implementations that care about responsiveness should "do the right thing" and restrict the data payloads instead of having the protocol force them to do so at the expense of applications that either do not multiplex or do not care about interactivity.
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 22 Apr 2014 19:20:02 +1000

Hey Jeff,

Thanks,

---

From: Jeff Pinner <[email-masked]>
Date: Tue, 22 Apr 2014 07:49:22 -0700

On Tue, Apr 22, 2014 at 12:54 AM, Mark Nottingham <[email-masked]> wrote:

> Hey Jeff,
>
> It feels like this conversation isn't done yet, and we're very much
> overdue for the next implementation draft. So, let's continue, but not
> block on it, OK?
>
> Thanks,
>
>
Definitely.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 23 Apr 2014 03:39:28 +1200

> should be a pathological case.

My expectation is that we can cut these frames into two and place the
END_SEGMENT only on the second frame.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Apr 2014 09:51:03 -0700

> END_SEGMENT only on the second frame.

Exactly.

But if you have a 16383 byte frame with END_SEGMENT, then your choices
for length on the wire are ==16391 or >=16399. There's no way to put
16392 octets on the wire.  I don't think that this is a major issue,
since you can be consistent and have both a 16376 byte limit and a new
frame for every END_SEGMENT byte.  Then the only leakage occurs when
END_SEGMENT is used selectively, based on whether there is content
that is sensitive/secret/etc...

---

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Apr 2014 09:54:56 -0700

On 22 April 2014 00:48, Jeff Pinner <[email-masked]> wrote:
> I don't think I follow. Are you saying that the overhead of always splitting
> frames is negligible so it's ok to always split frames in order to not have
> a discontinuity in padding?

No.  I'm saying that if you can't break an arbitrary payload up into
2^14-7 byte chunks (plus 8 bytes) without leaking information about
the length, then 2^14-1 is no different.

> forcing it by calling out the restriction in the protocol itself.

Nothing of the sort.  The point was that if you want to pad perfectly
(whatever that means), then it is possible.  You seem to be claiming
that it is impossible.