- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 3 Sep 2014 12:33:24 -0700
- To: Jason Greene <jason.greene@redhat.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Roy Fielding <fielding@gbiv.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Sep 3, 2014 at 12:22 PM, Jason Greene <jason.greene@redhat.com> 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
Received on Wednesday, 3 September 2014 19:33:51 UTC