Slashdot Mirror
RFC 7258: Pervasive Monitoring Is an Attack
An anonymous reader writes with news that the IETF has adopted a policy of designing new protocols taking into account the need to mitigate pervasive monitoring of all traffic. From the article: "...RFC 7258, also known as BCP 188 (where BCP stands for 'Best Common Practice'); it represents Internet Engineering Task Force consensus on the fact that many powerful well-funded entities feel it is appropriate to monitor people's use of the Net, without telling those people. The consensus is: This monitoring is an attack and designers of Internet protocols must work to mitigate it."
The NSA will try to infiltrate the IETF.
Some people may mod this as Funny, but I take it as completely serious.
Even if it isn't the NSA, do you really think other state actors won't try to exert their influence?
Expect lot of FUD around security issues by direct paid shills, or just "grass-roots" opposition indirectly fomented by various state security agencies.
Natural != (nontoxic || beneficial)
Open source community: this is excellent and we welcome the opportunity to enhance common protocols like smtp and http with this new mandate.
Microsoft: we havent met an RFC we cant mangle. Exchange is so broken as to be unusable, Internet Explorer is more exploit than browser, and we hold patents on sharps and plusses for a clone of every major programming language in existence. dont expect this one to go anywhere fellas.
Google: we'll add an option in chrome that you can click to disable monitoring. Clicking this option will cause a checkmark to appear. This checkmark will make the user feel feelings, and should probably do something with google plus. its a clickable option for google plus really. buy some of our neat glasses too.
NSA: you realize Russ Housley and Brian Carpenter, both IETF former chairs, have worked with companies that rolled over when we asked for them to spy on you without telling anyone. Jari Arkko has only been around for a year, and we have enough IETF members in our pocket to keep it that way if we want. Go back to sleep, vote the two parties, and buy magnetic bumper ribbons during the next war to support what we tell you.
Good people go to bed earlier.
The NSA will try to infiltrate the IETF.
The NSA has already been participating in many standards bodies overtly and covertly. But that doesn't really matter. IETF protocols are designed in public, so backroom attempts to subvert them don't work. The only thing the NSA et al can do is to try to get the standards weakened in subtle, non-obvious ways they can exploit. But being able to do that effectively requires being significantly smarter than everyone else who is looking at and commenting on the designs so they can design and insert weaknesses which no one realizes are weaknesses.
One ploy they can use that doesn't require super genius insight is to try to promote complexity in new standards. Complexity makes implementation harder and increases the probability of exploitable mistakes, in both design and implementation. That won't give them any guaranteed avenues of attack, but it will increase the odds of exploitable weaknesses. So we need to guard against excessive complexity in standards... but that's always been the case anyway.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
A third way is to control positions responsible for communicating with other groups, which gives them more opportunities to influence the discussion or misrepresent consensus.
See Trevor Perrin's request to remove NSA employee Kevin Igoe from the position as co-chair of the Crypto Forum Research Group:
Reasons for requesting Kevin's removal
----
1) Kevin has provided the *ONLY* positive feedback for Dragonfly that
can be found on the CFRG mailing list or meeting minutes. The
contrast between Kevin's enthusiasm and the group's skepticism is
striking [CFRG_SUMMARY]. It's unclear what this enthusiasm is based
on. There's no record of Kevin making any effort to understand
Dragonfly's unusual structure, compare it to alternatives, consider
possible use cases, or construct a formal security analysis.
2) Twice Kevin suggested a technique for deriving the Dragonfly
password-based element which would make the protocol easy to break
[IGOE_1, IGOE_2]. He also endorsed an ineffective attempt to avoid
timing attacks by adding extra iterations to one of the loops [IGOE_3,
IGOE_4]. These are surprising mistakes from an experienced
cryptographer.
3) Kevin's approval of Dragonfly to the TLS WG misrepresented CFRG
consensus, which was skeptical of Dragonfly [CFRG_SUMMARY].
4) Kevin's NSA affiliation raises unpleasant but unavoidable
questions regarding these actions. It's entirely possible these are
just mistakes by a novice chair who lacks experience in a particular
sort of protocol and is being pressured by IETF participants to
endorse something. But it's hard to escape an impression of
carelessness and unseriousness in Kevin's work. One wonders whether
the NSA is happy to preside over this sort of sloppy crypto design.
While that's of course speculation, it remains baffling that an
experienced cryptographer would champion such a shoddy protocol. The
CFRG chairs have been silent for months, and haven't responded to
attempts to clarify this.
The request was reviewed and denied, so the crypto research group is still co-chaired by a NSA employee.