Joe Hildebrand wrote:
On 4 Jun 2015, at 9:37, Tony Hain wrote:
My overall concern here is that statements like this undermine the
integrity of the organization. I understand people wanting to improve
overall privacy, but this step does not do that in any meaningful way.
Encrypting the channel does provide some small amount of privacy for the
*request*, which is not public information. Browser capabilities,
cookies, etc.
benefit from not being easily-correlated with other information.
The set of possible requests is inherently public information. Pairing a
request length with the possible set of return lengths seriously reduces the
set, and that is before you factor in who is being watched and what they
might be looking for.
It would be interesting to define an HTTP header of "Padding" into which
the
client would put some random noise to pad the request to a well-known
size, in
order to make traffic analysis of the request slightly more difficult.
This is the
sort of thing that comes up when we talk about doing more encryption for
the
IETF's data, which shows the IESG's suggested approach to be completely
rational.
On the contrary, it only further exposes how much of an irrational
knee-jerk this effort is. If you have to define something new, then get it
deployed, it is not ready for prime-time and therefore this effort is
premature at best. A more rational thing that could be part of the tooling
effort without much delay would be to define a random COMMENT padding which
would vary the length of the returned stream.
Again, I am not objecting to encrypting the content. I am concerned that the
IESG is "out of scope" by making a political statement, particularly when it
is not necessary. It is completely rational and within scope for the IESG to
be concerned about data-integrity, and stating they are turning on https by
default to accomplish that. There is no need for the word 'privacy' to occur
within the statement, and is blatantly misleading without taking more steps
than are being outlined here.
Tony