On Thursday, June 4, 2015 9:54 AM, 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.
What Joe says. Encrypting data is just one component of providing privacy, but
it is a very useful component. Clear text headers leak various kinds of
"meta-data," which facilitate correlation and traffic analysis. For example, if
people access the IETF from a public Wi-Fi and manages to leak meta-data on
that hot spot, their traffic will be very hard to analyze and correlate with
their identity. Of course, that takes more than just encrypting the end-to-end
application traffic, but encryption is definitely a key component of the
solution.
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.
Yes.
-- Christian Huitema