Stephen Farrell wrote:
On 03/06/15 22:03, Tony Hain wrote:
Stephen Farrell wrote:
I would assert that the existence of the dprive WG is good evidence
that the IETF does not consider data-integrity as the only real
concern for public data.
And I would assert that it shows a group-think knee-jerk overreaction
to threats that hypothetically could be applied in broader contexts
than history documents. We are both free to express our own
assertions.
Disagreeing is of course fine but does not require that those with whom one
disagrees are stuck in a group-think knee-jerk mixed metaphor;-)
Looking at the actual text of the statement though [1] I could agree that the
3rd paragraph is maybe more justified on security grounds, so maybe
s/privacy/security&privacy/ would be better there.
No, more below.
That said, there is a real threat to privacy (cf. tempora) when it is
credible to
assume that any of our traffic that transits undersea cables is recorded, and
traffic to the IETF is a part of that even if it's quite unlikely, by itself,
to be
privacy sensitive.
I never argued that there is not a general threat to privacy due to recording,
just that it does not apply here. My point was that the IETF does not have a
general technical REQUIREMENT for privacy. There are many that WANT privacy in
everything they do, but that does not equate to a real requirement for the
public content of an open organization. Substituting security&pirvacy only
makes a bad choice of words worse. The IETF has no business case for either,
and if there was a case something would have been done about it long before
now.
It is clear that a solution has been chosen and language is being collected to
justify that solution. Again, I am not opposed to the solution, just the
unnecessary method being used to justify it. All you need to do is state the
clearly justifiable requirement for data integrity. The fact that the chosen
implementation goes beyond the requirement is a bonus for those who want the
privacy.
Put another way; if the IESG believes it has the excess time to make clearly
political statements (rather than focus on the justifiable technical
requirement), maybe we need to revisit the workload on the NomCom and reduce
the number of ADs...
Tony
(Someone else already pointed out that it'd be worth noting that HTTPS isn't
perfect in the face of traffic analysis, so adding text on that would also
make
sense just so's we're clear that we're not claiming that there's a panacea
hereabouts, and is worth a mention here too.)
S.
[1] https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere