Interesting People mailing list archives
the DPI case
From: David Farber <dave () farber net>
Date: Fri, 18 Jul 2008 14:30:31 -0700
________________________________________ From: Ed Gerck, Ph.D. [egerck () nma com] Sent: Friday, July 18, 2008 4:37 PM To: David Farber Subject: the DPI case [Dave: for IP if you wish] List, The outcry against DPI (Deep Packet Inspection) has reached the level of the US Congress and has been well discussed in this list. An often forgotten aspect of this discussion (but mentioned by Rony Kay in the Linley Embedded Security Seminar this week, with program at <http://www.linleygroup.com/Seminars/security.html>) is that there /are/ security needs for DPI. These needs are becoming more prevalent as other security tools such as CAPTCHA are increasingly being bypassed -- exposing the "soft core" of web services to attacks. See <http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9104619> To protect against DPI, end-users could rely on encryption. However, there are caveats. We all see today the expansion of software into chips, so that DPI and all that it needs (e.g., regular-expression parsing) are moving to faster silicon -- as well as encryption (coming even to end-user Intel CPUs). This means that /both/ encryption and DPI will be easier and faster to do. It is also obvious to us that ISPs and content providers can easily do DPI in encrypted TLS traffic to their respective servers. With the new MACSEC (IEEE 802 Standards ) being pushed now for layer 2 it is even easier and wider. In short, there is no way with any of MACSEC/IPSEC/TLS tools to prevent a node in otherwise good standing to become a "bad" node. This means that traffic inspection can be done at many different points, encryption or not, at different layers as well. The only solution is end-to-end encryption (with /no/ gaps), which is not viable in many cases of interest for the average user. Enterprises will be able to protect themselves, but not against GAK unless they use proprietary crypto (which also has problems). What we have now is a layered system for protection, with the base of the pyramid (the average user) open for DPI and other surveillance methods even with all the encryption methods. In the future, I see that upper layer technologies can be moved to the end-user layer but this will depend on usability, which decreases as you go up, and cost (the reverse) improvements. BTW, this is where my work and interest fits in. At the end, I see that the wired Internet and the wireless Internet will have this in common: traffic is fully exposed, so that /both/ protection (user/role authentication, encryption) and surveillance (DPI) are needed. Comments? Any thoughts on an end-user key distribution system that scales and supports such things as multicast any time soon, that ordinary folk can use? Best regards, Ed Gerck www.gerck.com ------------------------------------------- Archives: https://www.listbox.com/member/archive/247/=now RSS Feed: https://www.listbox.com/member/archive/rss/247/ Powered by Listbox: http://www.listbox.com
Current thread:
- the DPI case David Farber (Jul 18)