Become a fan of Slashdot on Facebook


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Privacy The Internet Your Rights Online

RFC 7258: Pervasive Monitoring Is an Attack 67

Posted by Unknown Lamer
from the don't-be-so-nosy dept.
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."
This discussion has been archived. No new comments can be posted.

RFC 7258: Pervasive Monitoring Is an Attack

Comments Filter:
  • Re:Next step: (Score:4, Interesting)

    by StripedCow (776465) on Wednesday May 14, 2014 @08:30AM (#46998535)

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

  • by raymorris (2726007) on Wednesday May 14, 2014 @10:05AM (#46999239)

    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.

Information is the inverse of entropy.