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