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."

Comments

Next step:

[SuricouRaven]

The NSA will try to infiltrate the IETF.

Re:Next step:

[StripedCow]

Other option: they already have. It's a trick!

Re:Next step:

[rabtech]

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.

Re:Next step:

[swillden]

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.

Re:Next step:

[wonkey_monkey]

It's a tarp!

No, wait...

Re:Next step:

[Anonymous Coward]

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.

Re:Next step:

[ArmoredDragon]

We've already seen this kind of FUD from foreign governments who want authority over ICANN and IANA. Basically they argue that by these being under the US Department of Commerce, which itself is technically run by Congress, the NSA can somehow spy on the world. Complete nonsense (regardless of who holds the keys, the NSA can always do what they do.)

The real reason they want control over this is because it makes censorship a lot easier. Russia and China want to stop free speech, whereas Europe wants to kill anything they believe is "hate speech" (which technically almost anything can be called hate speech.) I distrust the feds as much as anybody, but IMO the US is the best holder of that because it doesn't do either.

But it's "meta" monitoring.

[Anonymous Coward]

The "pen register" part of the Smith v. Maryland makes their monitoring legal in this meta way. Even Hayden says they've killed people based on metadata alone.

I don't see how you're going to "mitigate" anything until you get the 9 robed activists to pull heads out.

Best Current Practice

[id est]

Not "Best Common Practice".

Re:/. Poll: Worst offenders

[Bob9113]

I think your question calls for a multi-context response:

Greatest combined offensiveness and pervasiveness today: NSA, though GCHQ gets a solid nod for being more offensive and nearly as pervasive (especially if you count cooperation with NSA, but that cuts both ways).
Most pervasive today / greatest potential psy-ops threat: US corporations (Google and Facebook so far out in front that it doesn't even look like a competition)
Most offensive monitoring program today: Corporations monitoring public school students.
Most scary if I thought they posed a credible threat: North Korea
Most scary based on capability and recent offensive behavior: Russian government.
Most scary based on capability and mid-term offensive behavior: Chinese government.
Most scary based on capability and long-term offensive behavior: Russian government.

I echo your sentiment about the difficulty of separating Chinese and Russian thugs/corporations/government.

Attacks Cannot Be Distinguished by Motivation

[Bob9113]

From the RFC, so delicious it must be fattening:

In particular, the term "attack", used technically, implies nothing about the motivation of the actor mounting the attack. The motivation for PM can range from non-targeted nation-state surveillance, to legal but privacy-unfriendly purposes by commercial enterprises, to illegal actions by criminals. The same techniques to achieve PM can be used regardless of motivation. Thus, we cannot defend against the most nefarious actors while allowing monitoring by other actors no matter how benevolent some might consider them to be, since the actions required of the attacker are indistinguishable from other attacks. The motivation for PM is, therefore, not relevant for how PM is mitigated in IETF protocols.

its a start, in theory.

[nimbius]

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.

All RFCs have a "security considerations" section

[raymorris]

All RFCs are supposed to have a section covering security considerations, and there are a couple of of RFCs about that. RFC 3552 (2003), has section 3.2.1. "Confidentiality Violations", indicating that protocol authors should consider the possibility of eavesdropping. The new RFC (7258) just expands upon 3552.

It is technical rather than political in the sense that 7258 essentially says we wouldn't develop SMTP the same way again, sending everything in the clear. If we were developing a new mail protocol, we should design it to support encryption from the get-go. (Ie include RFC 3207 capabilities in the original RFC 2476). That's a technical decision, with a technical implementation.