On Jun 5, 2014 9:10 PM, "Greg Wilkins" <gregw@intalio.com> wrote: > > Having the padding in the spec is not that much of an intrusion, but I just don't see what good it does. If an application wants to pad it's data for security reason, then it does not need a transport mechanism for that. > If it only wants to pad the data during transport, then the padding is a transport mechanism. Otherwise you need a higher-level padding mechanism which both ends understand. Whitespace as a security feature sounds... interesting... > The only reason the transport needs to be aware of padding is if the transport is expected to do something with it - ie like generate it. > Well, yeah. Generate at one end, and strip at the other. Why would my application code ever want to touch a buffer full of 17000 null bytes? Especially at the receiving end? > But as the warnings in the draft clearly make out, generating padding is apparently non trivial and should only be done by experts with detailed knowledge of the actual payload. > Generating is trivial; knowing when to generate isn't. > > So if the transport is not going to generate the padding, not handle the padding, etc. then why does the transport even need to know about the padding? > Because the transport does generate it, but more importantly the transport strips it at the other end. The receiving application never need know how much padding was involved -- but if it does want to know, a simple int will suffice, no point feeding it a huge chunk of allocated memory with no semantic value whatsoever. > To me it is setting false expectation that the implementation of h2 will be safe from leaking information about their meta data and payloads. > Apparently so, but I suspect that comes from our different readings of the spec. HTTP has lots of features that can help with security, if used correctly, that are completely optional. It also contains cookies. I think padding is just one of the former.
Received on Thursday, 5 June 2014 22:27:05 UTC