Subject: [perpass] Encrypt all lit fiber 24x365

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 10:01:58 -0500

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/

---

From: Raphaël Jacquot <[email-masked]>
Date: Tue, 05 Nov 2013 16:09:16 +0100

On 05.11.2013 16:01, Phillip Hallam-Baker wrote:

> There would be a small degree of additional complexity introduced by
> the need to conceal the sizes of the underlying packets.

not really.
sending no packets accross an encrypted link ends up sending tons of 
encrypted 0 bits during the time when there's no packet to send
you end up transmitting "line noise" 100% of the time.

---

From: Martin Millnert <[email-masked]>
Date: Tue, 05 Nov 2013 16:30:17 +0100

Hi Phillip,

On Tue, 2013-11-05 at 10:01 -0500, Phillip Hallam-Baker 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.
> 
> 
> 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 vendors selling transponder type bitstream encrypters.  It's
relatively easy to apply bitstream crypto at the bitstream layer, as I
understand it. (How this holds for 100G serial stream, I don't know.
Many 100G transceivers utilize 4x25G or 10x10G serialisation and muxing
techniques, and how encryption/keying/timing would work here I'm not
sure...)

I would be very vary of proprietary encryption protocols however.
Interoperable and openly standardized (though not bastardized), AES-type
encryption would provide some safety.
Key management, obviously is an issue, as well.

Otherwise, I've been talking about this myself.
At the optical transceiver level, it would be relatively straightforward
to insert a crypt/decrypt layer.  

Technical difficulties are to manage this on highspeed links, where
integrated DWDM transceivers are using all available, or more, of the
power budget of the various transceiver form factors.

The further away from the core you are, the cheaper it will be to do
crypt/decrypt.  OTOH, core links have more paying customers behind them,
so the economics are different here.

Router-to-router encryption would... definitely help.  

My 2c.
<snip>

/M

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 05 Nov 2013 10:36:39 -0500

Hi Phill,

And just how does one get from Phill and friends
in perpass talking about clever schemes, to  "forcing"
all the governments, vendors, and providers of the
world to implement those schemes?   That seems
like a rather large and important step to be asserting
as part of your technical(?) plan! :-)

You do realize that ironically at this very moment,
there are ITU-T meetings occurring where some of
those actors are collaborating on doing the opposite.
In fact, if you examine the appendix to the original
submitted Rec. Y.2770, you'll see about 34 use cases
for the commercial benefits of pervasive  surveillance.
And, that doesn't include government use cases.

One of the unintended consequences of the past
couple months of exposing stolen UK and US
documents is that the budgets and stature of the
services of a great many other countries became
substantially increased, and the providers/vendors
will be subject to more extensive pervasive
surveillance requirements.  It's funny how the
real world works.

best,
tony

On 11/5/2013 10:01 AM, Phillip Hallam-Baker wrote:
> 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.
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 13:20:15 -0500

It all depends on whether the enemy is s bunch of authoritarian governments
with their gulags for political prisoners or a bunch on religious fanatics
who can clean a Kalashnikov and milk a goat.

I suspect that the truth of the matter is that there is no enemy at all and
all the surveillance is just a bunch of boasting generals polishing their
egos and pouring billions of dollars of taxpayer money into vanity projects
to do so.

Can't necessarily stop the intercepts but we can end the careers of a few
militarists wo fogot who the enemy was and decided to go to war on their
own citizens instead.

Their tradecraft stinks, their code names are ludicrous aggrandizing
showboats popping powerpoint slides that they keep unencrypted on a server
run by the guy with a stripper girlfriend.

The NSA is not a police force, they are not a law enforcement agency. They
have no business having any involvement in civil police functions.

The Snowden issue is going to be a campaign issue in 2016 regardless of
what the parties want.

On Tue, Nov 5, 2013 at 10:36 AM, Tony Rutkowski <[email-masked]>wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 13:33:23 -0500

> techniques, and how encryption/keying/timing would work here I'm not

I am aware that there are existing products designed to prevent data
disclosure. But I am not certain that they are designed to prevent traffic
analysis or qualified for that role.

To be effective in that capacity, the links have to be designed to prevent
timing attacks and be qualified in that role.

Yes, it will require some work. But I think it is quite practical. All that
it takes is for some of the major purchasers to put this down as a
requirement in their RFPs and features will appear in the silicon. In fact
the requirement is even weaker, the manufacturers merely need to suspect
that this might be the case.

Yes, I agree that a very likely outcome is that some governments will issue
an order telling their ISPs to encrypt the links and give them the
decryption keys. But moving from a world where the PLA and the NSA are both
tapping Google's links in the US to one where only the NSA can do that is
still an advance. There is a limit to the amount of data that the PLA
mole's in the NSA and their stripper girlfriends can extract from the
system, they can only carry so many USB sticks out the gate of Fort Meade
every day.

> Key management, obviously is an issue, as well.

+1

Yes, it has to be done right. And it might well be a job for IEEE rather
than IETF but I think it needs to be something that the IETF is involved in
setting requirements for and integrating into the IP stack.

---

From: Tony Rutkowski <[email-masked]>
Date: Tue, 05 Nov 2013 13:44:33 -0500

Phill,

Might I suggest that your characterizations
are far from accurate here, and I would certainly
not denigrate the UK government in this fashion.

You are, however, evading the key question
repeated below:
> world to implement those schemes?
...especially when most those other governments
governments and a great many providers are now
scaling up their activities to instantiate more pervasive
surveillance in the infrastructure.  Or, is this all just
an academic exercise?

--tony

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2013 15:48:52 -0500

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-masked]> 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.
> 
> -- 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 20:56:11 +0000

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-masked]<mailto:[email-masked]>>
 wrote:

On Nov 5, 2013, at 10:01 AM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

And that is per link.

--
Website: http://hallambaker.com/
_______________________________________________
perpass mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

---

From: Theodore Ts'o <[email-masked]>
Date: Tue, 5 Nov 2013 17:09:57 -0500

> million 4Tb hard drives. Or $200 million at $500 per drive (including

That's assuming the attacker is going to attack link-level security
--- which to me sounds like the French assuming the Germans would make
a full frontal assault on the Maginot Line.

It would seem that a much more intelligent thing for the adversary to
do is to force/induce/send a national security letter/FISA warrant so
as to put the tap between the decryption gear and the default-free
zone router.

						- Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 19:33:33 -0500

On Tue, Nov 5, 2013 at 3:48 PM, Eric Burger <[email-masked]>wrote:

> 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 am taking it as granted that someone who deploys a $500K router knows how
to initialize the crypto securely and that the systems would be performing
the usual PFS/ephemeral do-winkies.

So inserting an extra router should be immediately visible.

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2013 20:00:27 -0500

Immediately visible and OK. That is the problem. For state surveillance, there is no need for secrecy.

On Nov 5, 2013, at 7:33 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> 
> 
> 
> On Tue, Nov 5, 2013 at 3:48 PM, Eric Burger <[email-masked]> wrote:
> I am taking it as granted that someone who deploys a $500K router knows how to initialize the crypto securely and that the systems would be performing the usual PFS/ephemeral do-winkies. 
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Nov 2013 19:00:46 -0600

> surveillance in the infrastructure.  Or, is this all just

It’s a matter of setting GAAP-like “generally accepted best practices” for fiber operations that expose fiber operators to shareholder and customer lawsuits for failure to implement  those best practices.

If Google implements continuous-flow encryption on its fiber, it won’t be long before somebody sues Yahoo for not doing the same. If all the US fiber is secured, it won’t be long before French companies seek the same competitive advantage.

All we have to do is set the baseline best-practice (possibly in collaboration with other standards bodies), and market forces will do the rest.

—
Dean

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 5 Nov 2013 20:00:55 -0500

> as to put the tap between the decryption gear and the default-free

And then when the packets cut across multiple jurisdictions, the traffic
patterns are hidden unless the governments are willing to cooperate.

The technical layer and the political layer are separate. Forcing an
attacker to obtain a legal warrant is the desired outcome because that
forces a measure of accountability.

I note that others have expressed skepticism as to my understanding of the
political realities. I suggest that their experience in national politics
in general and US politics in particular is almost certainly less than
mine.

These events have cost Microsoft, Google and the other major US providers
of cloud services several billion dollars in lost revenues as customers ask
if they can trust US companies. Those companies have plenty of political
clout to protect their interests. While corporate interests don't always
win in the US system, this is an issue where the corporate interest and
public opinion are in very strong agreement.

For reasons that will not apply to his successor, the current President had
particular reason to rely on the intelligence services, specifically the
need to wind down two wars that the US had been losing due to the utter
incompetence of his predecessor. Whoever wins in 2016 is not going to be
facing those same needs but to get elected they will have to answer the
questions raised by the civil rights abuses of the intelligence services
now that the Snowden documents have made the issues apparent to the
population at large.

Gen Alexander has been fired, so has Clapper and so have much of their
support staffs. Now that was for the political embarrassment that their
incompetent tradecraft has caused the politicians but their successors are
not going to be engaging in business as usual. I believe that they are
going to have little choice but to concentrate on what should be the core
mission of the NSA: defending the US and its allies.

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Nov 2013 19:09:57 -0600

> a full frontal assault on the Maginot Line.

Every national security unit with submarine capability implements undersea fiber taps. Literally, they send out a sub, tap a fiber, mirror its data onto another “dark” fiber in the bundle (or a fiber leased to a puppet), and start scraping data — mostly “metadata” from the pipe.

Scambling every fiber is going to seriously mess with that sort of intercept.

This is believed to be the attack model executed on Google, tapping fibers between their data centers.

> as to put the tap between the decryption gear and the default-free

Sure. But at least somebody knows who is scraping the data that way. This requires “legal” mechanisms be deployed. Much of the current concern is about illegal (or “secret quasi-legal with no review and no recourse") intercepts.

—
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Nov 2013 19:12:44 -0600

> Immediately visible and OK. That is the problem. For state surveillance, there is no need for secrecy.

Wrong. See, the GCHQ has been surveilling US citizens using taps, and the NSA has been surveilling UK citizens using taps. Both are allowed to use covert mechanisms to surveil foreigners. Then they trade data sets with each other.

This is state surveillance, but since it’s quite reasonably “illegal”, it also requires secrecy.  Securing the transit links such that a “legal order” is required would significantly impact the interception.

—
Dean

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 5 Nov 2013 17:17:23 -0800

> This is state surveillance, but since it’s quite reasonably “illegal”, it also requires secrecy.  Securing the transit links such that a “legal order” is required would significantly impact the int…

Except that its clear that they already HAVE gotten "legal" orders for such surveillance.  E.g. AT&T secret room, GCHQ's deal with Level 3, etc...

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Nov 2013 20:23:15 -0500

That’s my point.

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 5 Nov 2013 17:53:24 -0800

> Except that its clear that they already HAVE gotten "legal" orders for such surveillance.  E.g. AT&T secret room, GCHQ's deal with Level 3, etc...

If it was purely legal they would do it above the table, installing a tap inside the data center themselves. They don’t, and most companies would find that a wide overreach.

Encrypting the links that transport lots of private data to faraway places look like a reasonable practice. But it is one of many possible solutions. It may well be more practical to use a form of end-to-end encryption between the components of the data centers. See classic debate on end-to-end versus link-by-link, in which end-to-end tends to win most of the time.

- -- Christian Huitema

---

From: Martin Millnert <[email-masked]>
Date: Wed, 06 Nov 2013 07:21:01 +0100

On Tue, 2013-11-05 at 17:53 -0800, Christian Huitema wrote:
> Encrypting the links that transport lots of private data to faraway
> places look like a reasonable practice. But it is one of many possible
> solutions. It may well be more practical to use a form of end-to-end
> encryption between the components of the data centers. See classic
> debate on end-to-end versus link-by-link, in which end-to-end tends to
> win most of the time.

If the applications and the complexity of adding end-to-end encryption
to them is low in the DC interconnect case, it may be the easiest
approach.  Also, defense-in-depth.

However, with MAC PHY's already available with 802.1AE - MacSEC, doing
AES-128 or AES-256 (switches available today!), it's also quite
low-hanging-fruit for the data link layer.  And this applies for all
traffic on a link, and some links are obviously more interesting than
others.

If for example ISPs renting trans-oceanic wavelengths from cable system
operators were to encrypt their router-to-router links, the defensive
surface against pervasive surveillance would drastically grow in terms
of number of organizations to engage with secret laws.

This does make tapping much more complex, and expensive, and really is
quite low hanging fruit.

Decreasing pervasive surveillance is not an all-or-nothing project.

However, before ISPs could begin encrypting their backbone links, there
would have to be a business case for doing it, e.g. customers demanding
it.   What would help, I believe, is some form of standard on how
operators do the encryption, that could be included as a MUST in RFQs.
This could very well be an RFC.

It would also definitely help to get this going that a couple of really
large networking enterprises made vendors create/expand products.  These
would be IEEE, and I wonder if 802.1AE is sufficient already?

/M

---

From: Norbert Bollow <[email-masked]>
Date: Wed, 6 Nov 2013 12:13:49 +0100

Christian Huitema <[email-masked]> wrote:

> > Except that its clear that they already HAVE gotten "legal" orders
> > for such surveillance.  E.g. AT&T secret room, GCHQ's deal with
> > Level 3, etc...
> 
> If it was purely legal they would do it above the table, installing a
> tap inside the data center themselves. They don’t, and most companies
> would find that a wide overreach.

Yes, and in addition public opinion is relevant here too. 

We definitely need to work on forcing all surveillance interception to
be done explicitly above the table, that will be an important step
forward.

> places look like a reasonable practice. But it is one of many
> possible solutions. It may well be more practical to use a form of
> end-to-end encryption between the components of the data centers. See
> classic debate on end-to-end versus link-by-link, in which end-to-end
> tends to win most of the time.

Even when end-to-end encryption of all communications content is
implemented, there is still the issue of traffic analysis revealing “who
communicated with whom/with what service” information.

Encrypting links will reduce the attack surface in regard to that.

Greetings,
Norbert

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 06 Nov 2013 07:55:25 -0500

You might want to consider getting on the
new EC advisory committee in Brussels that is
dealing with expanding the Data Retention
Directive.  You can go via Berne where Switzerland
has already decided to be in full compliance.
But you can always express your views there.

--tony

---

From: Tony Rutkowski <[email-masked]>
Date: Wed, 06 Nov 2013 08:25:49 -0500

Wow, this list is getting deeply technical. :-)

What it does provide, however, is some insight
into underlying motivations and use cases.

Pervasive surveillance exists in every nation.
It has existed since the first bit went over a
transport path.   The value of pervasive surveillance
for commercial and governmental purposes is
scaling dramatically worldwide.  It's value is
being constantly demonstrated, and end users
seem to appreciate it.  It is required my multiple
legal and regulatory mandates.

To raise another Scott McNealy metaphor -
what is occurring here is like someone going
down to the Amazon river near its mouth,
dipping one's hand into the water, and shouting
stop.  Have fun at your session.

--tony

---

From: Dean Willis <[email-masked]>
Date: Wed, 6 Nov 2013 15:15:07 -0600

On Nov 5, 2013 7:17 PM, "Nicholas Weaver" <[email-masked]> wrote:
> > Wrong. See, the GCHQ has been surveilling US citizens using taps, and
the NSA has been surveilling UK citizens using taps. Both are allowed to
use covert mechanisms to surveil foreigners. Then they trade data sets with
each other.
> >
> > This is state surveillance, but since it’s quite reasonably “illegal”,
it also requires secrecy.  Securing the transit links such that a “legal
order” is required would significantly impact the interception.
>
> Except that its clear that they already HAVE gotten "legal" orders for
such surveillance.  E.g. AT&T secret room, GCHQ's deal with Level 3, etc...

There are basically two classes of surveillance that require distinct
analysis:

1) Surveillance that requires collaboration by service providers, generally
through a "legal" framework of compulsion or a less qualified process of
human subversion. Overt, mostly. Typically used within the legal domain of
a state actor or enterprise.

2) Surveillance that can occur without the knowledge or support of the
provider. Illegal within the US, typically launched from outside the domain
of a state actor or enterprise.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 7 Nov 2013 09:55:27 -0500 (EST)

> of a state actor or enterprise.

Phill made the point during his talk at the BoF yesterday, that (roughly 
speaking), we should consider cases where our actions cause attacks to 
move from class (2) to class (1) to be victories.  This is (to me), 
broadly speaking, true, in that it gives the collective us more knowledge 
about what is going on.

However, I fear that the knowledge we gain may be more limited that we 
would like.  In particular, I fear that NSLs or similar things will come 
with gag orders so strong that the company's counsel will not be able to 
use knowledge of them to alter company policy, or even that the gag will 
prevent the engineer being served from contacting the company's counsel. 
There are probably technical measures which could help a little, such as 
requiring multiple persons to authenticate certain classes of operations, 
though I suspect those are out of scope for IETF protocol work.

-Ben Kaduk

(I have received between -1000 and 0 NSLs in the past 30 years.)

---

From: Dean Willis <[email-masked]>
Date: Thu, 7 Nov 2013 11:07:42 -0600

On Nov 7, 2013, at 8:55 AM, Benjamin Kaduk <[email-masked]> wrote:
> 
> However, I fear that the knowledge we gain may be more limited that we would like.  In particular, I fear that NSLs or similar things will come with gag orders so strong that the company's counsel will not be able to use knowledge of them to alter company policy, or even that the gag will prevent the engineer being served from contacting the company's counsel. There are probably technical measures which could help a little, such as requiring multiple persons to authenticate certain classes of operations, though I suspect those are out of scope for IETF protocol work.

I don’t disagree. That’s why we need best practices for:

1) end to end application-level (TLS, DTLS, etc.)
2) IP node to IP node (IP peer level; application level like HTTPS, IPSEC transport, or opportunistic tcpcrypt and/or BTN) 
3) IP domain to IP domain (VPN; IPSEC tunnel)
4) MPLS-to-MPLS (and similar sub-IP overlays) 
5) physical link  (fiber drivers, WPA, etc.)

encryptions and authentications all at the same time. Layers in a tasty birthday cake. If you’ve been subject to US junk food adverts, think of it like Lay’s potato chips. You can’t eat just one. Another motto: No eggshells.

They’re going to hit the weak spot. We want the weak spot to require a whole stack of subpoenas and a whole lot of informed consent. Compliance with the law is required; our goal is to make sure the law is also complied with by the the attackers.

And we don’t think that GCHQ is going to be able to get a subpoena directly in the US, or vice versa, so the game of using foreign agents to spy on domestic assets (and trade data with each other) will get mostly shut down.

Sure, "they" might pass a law that says end-user encryption is illegal. We want them to have to pass that law, and have the public discourse needed to pass such a law in a democracy. Of course, rogue states are going to do whatever they’re going to do, but we can certainly reduce how much of it they do to other states.

This is not a “resistance” thing; it’s a "civil-defense" thing. If one state’s or one enterprise’s infosec is appallingly weak, other actors are going to take advantage of that weakness. If one nation’s or enterprise’s IT products have weak infosec as a matter of policy, that nation or enterprise is going to be very disadvantaged in external sales of those products. Our task is to set the bar sufficiently high without breaking the bank in the process. We must also remember that said bar is going to keep moving at the pace of Moore’s law. Adequate security in 1990 is not adequate security in 2013, and so on.

—
Dean

---

From: Martin Millnert <[email-masked]>
Date: Thu, 7 Nov 2013 20:07:50 +0100

+1

/M

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Nov 2013 13:15:53 -0800

I think it very unlikely that the NSA would think that they can use
information gained through a court order for 'swapsies' with other intel
agencies as they have been found to have done giving raw intercepts to
Israel.

Getting a court order to get intercept keys for a machine in a foreign
jurisdiction is much harder than in-jurisdiction.

The objective here is to prevent traffic analysis. Difficult to to that if
you only have the keys for the routers in your own jurisdiction.

On Thu, Nov 7, 2013 at 6:55 AM, Benjamin Kaduk <[email-masked]> wrote:

> speaking), we should consider cases where our actions cause attacks to move
> from class (2) to class (1) to be victories.  This is (to me), broadly
> speaking, true, in that it gives the collective us more knowledge about
> what is going on.
>