Tapping the link can be done passively - no warrant, no paid-off corporation, no undercover government agents posing as ISP employees.
Tapping at the end requires one of these things. Nothing has been said about key exchange and/or authentication. On Nov 5, 2013, at 12:48 PM, Eric Burger <[email protected]<mailto:[email protected]>> wrote: I do not see how this can help. In fact, I see this as a very DANGEROUS proposal. The reason is precisely because all this proposal does is mean that ONLY the NSA, GCHQ, MSS (PRC), and GRU gets to analyze all data. Worse, their secrets stay secret, so there is no accountability. Why do I say this? Because these organizations have the capability to take the full firehose. They do not need to tap anything, they just insert an extra router and they are in. No need for messy warrants, paid-off corporations, or undercover ISP employees that are actually in the employ of the government. I do not get how link encryption helps at all. Please illuminate. On Nov 5, 2013, at 10:01 AM, Phillip Hallam-Baker <[email protected]<mailto:[email protected]>> wrote: One of the handicaps we are working under is that the IETF is historically the ARPANET 'End to End' working group and we define the Internet stack from the IP layer up. Some problems can't be addressed at the IP layer, in particular it is impossible to address traffic analysis efficiently or pervasively. Tor is very good at what it does but Tor can't support three billion users doing streaming video under any imaginable circumstances. A much better option would be to tell every network vendor that they have to build full speed encryption/decryption capability into every link adapter and exchange encrypted data all the time the fiber is lit. The protocol for establishing the link layer encryption need not be very fancy. It arguably does not even need to be proof against a man in the middle attack since any man in the middle is going to be forced to drink the whole fire hose. There are devices for encrypting OC-768 40Gbit links today. But they are niche products made for NSA use (now where does all that data come from??). AES in standard cell does not add a huge number of gates to a circuit. Vendors need to be trained to believe that they have to add it to every chip or won't be able to sell the product. On circuit encryption is potentially much better against traffic analysis in any case since if you bolt a hardware encryptor onto a link and feed it data, it is likely that the timing of bits at least provides hints for a timing attack. Such a scheme would be in no way a replacement for end-to-end encryption. And there would be an issue of collusion with the carriers and governments. But reducing the attack surface from every government who can rent a back hoe to one government with a subpoena is very powerful. And forcing the intelligence agencies to collude to perform traffic analysis would further limit capabilities. The payoff for this effort is a major increase in work factor and in particular, forcing an adversary attempting a traffic analysis attack to intercept and decrypt multiple fire hoses. 40Gb/sec is quite a lot of data to store. It is over an exabyte per link per year. Or about a quarter million 4Tb hard drives. Or $200 million at $500 per drive (including racking etc.) And that is per link. The NSA budget is in the tens of billions a year. So we can eat up the whole pie by encrypting 50-500 links. Or the entire military budget would be 5,000 links. The only feasible attack would be to suborn the fab. But I expect that there will be a presidential executive order prohibiting that type of sabotage under the next President recognizing the fact that the cost of such activities in terms of damage to trust in international commerce is vastly greater than the benefit to the boasting generals careers. 40Gb/sec is not a vast quantity of data to encrypt with hardware support. Not for a device that is all custom VLSI anyway by its very nature. If the fiber is lit it is going to take the same power whether it sends all zeros or a mixture of ones and zeros. There would be a small degree of additional complexity introduced by the need to conceal the sizes of the underlying packets. It would not be a perfect defense against every attack and there is still the possibility that the attacker would persuade data to be sent over unencrypted links and such. But it would establish a gratifying increase in work factor which is the objective here. -- Website: http://hallambaker.com/ _______________________________________________ perpass mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/perpass _______________________________________________ perpass mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
