Subject: [perpass] Getting started...

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Aug 2013 17:42:44 +0100

Hi all,

We've enough folks subscribed now (50ish) to kick off.

For those who weren't in Berlin, here's a bit of context. We had a
(hastily arranged:-) meeting after the tech plenary with about 30 or
so folks including Jacob and Linus from the Tor project.  Topics
ranged from that day's announcements from the Guardian newspaper to
issues the Tor project have faced with fingerprinting, and that lead
to a good discussion about how the current threat models we use in the
IETF (whether more or less formally) don't usually take into account
the potential for very widespread passive (or active) monitoring of
nodes using IETF protocols.  That was followed up in the bar in
various ways (please chime in if you remember bits of that or the
earlier chat I've missed out on:-) and we figured that setting up
this list would be a good starting point for us to try see what work
related to this topic might make sense in the IETF.

You should have seen the scope Sean and I figured might work for this
list [1] so let's try to keep to that, but its not a strict charter
or anything so don't be too constrained by it for now.  As this is an
IETF list, normal rules (IPR and netiquette) apply, if you're not
sure if something is appropriate for this list, feel free to ask Sean
or I offlist, but our hope is to try make progress on some or all of
the following:

- experiences with IETF protocols and how they allow for
  fingerprinting and monitoring, esp. in unexpected ways
- things we might practically do about that in the IETF, ideally in
  terms of concrete ideas for protocol or operational changes, and even
  more ideally with protocols that have active working groups who're
  interested in taking on such work
- ideas for new work that'd make our protocols more robust in the
  face of such pervasive monitoring
- descriptions of new threat models that might help people doing
  protocol work in the IETF
- how to get to a "privacy by default" situation as Randy called
  it
- whatever else fits the scope:-)

The only thing to add to that for now is that since the kinds of
monitoring we're considering can be done at many layers, we should
not only be considering the web, or application layer or just
security protocols, but the full suite of protocols and areas in
which the IETF works.

And as usual, since its an IETF list, people need to grab a topic
and organise themselves to do the work or it probably won't happen.
But Sean and I are both supportive of this and willing to help
make sensible stuff happen if we can.

So over to you, what should we be doing?

Thanks,
Sean & Stephen.

[1] http://www.ietf.org/mail-archive/web/ietf-announce/current/msg11780.html

---

From: SM <[email-masked]>
Date: Fri, 16 Aug 2013 17:40:12 -0700

Hi Stephen,
>security protocols, but the full suite of protocols and areas in

"Privacy by default" has, up to now, been a failure in the IETF.  As 
you pointed out things do not happen unless someone volunteers to do 
the work.  There has been a lack of volunteers.  I don't know why.  I 
don't know who is trying to fix that.

Discussions about monitoring is a sensitive subject.  I am curious to 
see whether the 50 people are willing to discuss about that on this 
mailing list. :-)

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2013 11:05:21 +0100

Hi SM,

On 08/17/2013 01:40 AM, SM wrote:
> "Privacy by default" has, up to now, been a failure in the IETF.  

Not sure that I agree. We don't do that, sure. But it'll only be
a failure when we've actually tried, and we've not. And partly
that's because not enough of us know what can be done.

> As you
> pointed out things do not happen unless someone volunteers to do the
> work.  There has been a lack of volunteers.  I don't know why.  I don't
> know who is trying to fix that.

"We" are trying to fix that, where we == this list.

> Discussions about monitoring is a sensitive subject.  

Yes. However, even those who want to be able to monitor at point X,
probably don't want their sensitive stuff monitored at points Y,Z,...
So you don't actually have to have inhaled all the fumes to think
its a good plan for Internet protocols to be more robust against
pervasive monitoring.

> I am curious to

I hope so. We had some good discussions in Berlin at any rate and
my hope is that at least the people involved in that will chime in.
But I guess we'll see when we see.

S.

> 
> Regards,
> -sm
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Brian Trammell <[email-masked]>
Date: Sat, 17 Aug 2013 12:17:44 +0200

hi SM, Stephen, all,

> But I guess we'll see when we see.

There's also a difference between the threat models of pervasive monitoring (an analysis of what can be done) and operational practice (a report of what _is_ done). We should, to the extent possible, work from the former, referring to the latter anecdotally -- because that, I suspect, is all we're going to get.

Of course, if the threat model is "the adversary cooperates with the endpoint(s) of the communication", there's not a whole lot you can do at the protocol level. But that is, I think, a point for wider discussion, and there is significant work to be done, even if it just ends up being a cross-area awareness-building exercise; on which more soon.

Cheers,

Brian

---

From: Randy Bush <[email-masked]>
Date: Sat, 17 Aug 2013 19:18:57 +0900

> I hope so. We had some good discussions in Berlin at any rate and my
> hope is that at least the people involved in that will chime in.  But
> I guess we'll see when we see.

ok, ok.

imiho, there are a vast number of areas we can improve.  as you point
out, a privacy version of jeff's danvers rfc is one start.  another is
just painting privacy by default on the walls at home.  

i know bgp payload does not excite a lot of folk, but encrypting it
makes ip space tracability just that much harder.  and opportunistic
encryption would be trivial to negotiate in the bgp open.  and i am
looking at bgpsec doing payload encryption.

i would love it if my email client ( well, normal email clients :-)
automagically encrypted to the recipients for whom i have a public key.
maybe the folk way up there at layer seven can come up with an even
better idea.

i could drivel on.  but there are a lot of folk far smarter at this
stuff than i.

oh, and can we try to take the constructive road, not the negative
games?  my .procmailrc is too long already.

randy

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2013 11:30:13 +0100

Hi Brian,

On 08/17/2013 11:17 AM, Brian Trammell wrote:
> Of course, if the threat model is "the adversary cooperates with the
> endpoint(s) of the communication", there's not a whole lot you can do
> at the protocol level. 

That's correct. But (and yes, anecdotally;-) the submarine cable
monitoring was apparently done with the co-operation of the cable
owners and not of (all) the n/w operators using those cables. So
even when there is "co-operation," it may be that not everyone at
every n/w layer is co-operating.

> But that is, I think, a point for wider
> discussion, and there is significant work to be done, even if it just
> ends up being a cross-area awareness-building exercise; on which more
> soon.

Looking forward to that.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2013 11:37:16 +0100

Hi Randy,

> looking at bgpsec doing payload encryption.

I think that's a great example of the kind of nob-obvious changes
that could be useful and doable. I'd welcome more... and since we're
just starting out, makng a list of those would maybe be a useful
thing so it'd be great to get suggestions for putting on that list...

> maybe the folk way up there at layer seven can come up with an even

My own fav. would be to actually encrypt the entire message, incl.
sensitive header fields (e.g. To: From: Subject:) - without that PGP
and S/MIME seem to still expose too much to the pervasive monitor.

> games?  my .procmailrc is too long already.

Hope so. But in this case I'm more confident than elsewhere, for this
list. (That is, until we turn up on some wg's list with our great plan
for fixing their stuff. Things might get more challenging then, but
there's fun in that too:-)

S.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 17 Aug 2013 07:31:20 -0400

> looking at bgpsec doing payload encryption.

What? Surely:

a) The results of BGP are manifestly observable, regardless of whether you
can see the payload or not, and

b) The decrypted payload is necessarily visible to pretty much anyone who
wants to see it (otherwise debugging routing problems is impossible)

I feel like I must be missing something.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 17 Aug 2013 07:37:18 -0400

On 16 August 2013 12:42, Stephen Farrell <[email-masked]> wrote:

> what should we be doing?

Certificate Transparency is an anti-monitoring tool, amongst other useful
properties.

The more generalised idea of a public, verifiable log of stuff is probably
useful in other ways, too.

For example, DNSSEC Transparency (OK, hardly much different from CT).

Someone mentioned default encrypting emails: sparse Merkle trees are an
efficient data structure for making a verifiable map of email addresses to
public keys...

Yes, I have a hammer and I am looking for nails.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2013 12:52:37 +0100

Hi Ben,

> Certificate Transparency is an anti-monitoring tool, amongst other useful

Yep. Its a fine tool but more I guess directed at countering
an active attacker who spoofs as a web site and then monitors
or snarfs passwords or whatever.

> efficient data structure for making a verifiable map of email addresses to

neat idea... maybe.

However, that and other foo-transparency ideas also require
clients to ask the log about stuff, in a way that the log
can.... log.

For CT, thats ok since the web site itself (or its
auditors) can contact the CT log, but I wonder if that'd
become a problem for other foo-transparency applications,
e.g. how could an MUA query a log of public keys without
exposing the meta-data that I'm sending you an encrypted
message?

> Yes, I have a hammer and I am looking for nails.

:-)

S.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 17 Aug 2013 08:04:24 -0400

> clients to ask the log about stuff, in a way that the log

So, Private Information Retrieval is a way around this issue. I don't know
much about it, yet, but I'm told its fairly expensive. But I think not too
expensive for this kind of operation.

As it happens, I am planning to do some work with Ian Goldberg on the
subject, and so will have more to say about it in a while.

Also, it may be that simply retrieving the whole log is feasible. We're not
talking about vast amounts of data.

> exposing the meta-data that I'm sending you an encrypted

I would observe that you already reveal that, unless you come up with some
entirely novel way of delivering email. I am not suggesting that this means
the problem should not be solved, but it seems that encrypting the payload
routinely moves the needle a fair amount - enough to be worth doing while
we figure out the whole thing.

---

From: "Russ White" <[email-masked]>
Date: Sat, 17 Aug 2013 11:12:47 -0400

> I think that's a great example of the kind of nob-obvious changes that
could
> be useful and doable. I'd welcome more... and since we're just starting
out,
> makng a list of those would maybe be a useful thing so it'd be great to
get
> suggestions for putting on that list...

Are we talking hop-by-hop encryption of the payload along the lines of ipsec
between peers? Or encrypting the payload by changing the actual BGP packet
format?

How much is on-the-wire monitoring of routing udpates an issue if there is a
cooperating provider (or even an open route view server) mirroring the
global table? Is it even practical to try and "hide" the global table in any
meaningful sense? Beyond this, wouldn't any form of tunneling or proxy or
NAT ruin the traceability anyway? Why not focus on providing proxies and the
like to obfuscate the traffic path rather than trying to encrypt the routing
table?

> > maybe the folk way up there at layer seven can come up with an even

Thunderbird+Enigmail does this. I recently switched off Thunderbird, though,
because of a complete lack of any reasonable calendar client... another part
of this problem is sheer education. I know lots of folks with public keys,
but they won't encrypt their email traffic, because "I have nothing to hide"
--and complete bit of nonsense, but very prevelant.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 17 Aug 2013 16:14:06 +0100

Changed the subject...

> expensive for this kind of operation.

Be interesting if that were the case. I'd otherwise have assumed
it was too expensive but be interested if you find out better.

> talking about vast amounts of data.

I wondered about that. Anyone know how big the MIT PGP key server
DB is for example?

I'd say storing it locally would be fine, and probably figuring
out some kind of sharding thing and then asking for a full shard
rather than Ben's public key could work ok maybe.

> we figure out the whole thing.

Sure. The point is if we added a log that serves up the public keys
of my recipients, then I don't want to make that log yet another place
where monitoring can easily be done.

And aside from that you'd also want to clean up which mail headers are
protected, run SMTP/TLS always (maybe with a flag in the header to say
to barf if TLS isn't on) etc.

Seems like there are a bunch of imperfect things here that could
be pretty doable. I've no idea if people are really motivated to
do 'em though. Nor am I sure if they'd add up to enough to make
mail significantly more robust against monitoring.

S.

---

From: Randy Bush <[email-masked]>
Date: Sun, 18 Aug 2013 00:58:14 +0900

> Why not focus on providing proxies and the like to obfuscate the
> traffic path rather than trying to encrypt the routing table?

if it's cheap, do both.  every cm we can raise the bar cheaply is a win

> Thunderbird+Enigmail does this.

yep.  trying to move family members and coworkers to that mode.  but, as
i hinted, i use a horribly irregular emacs-based email client.

> I know lots of folks with public keys, but they won't encrypt their
> email traffic, because "I have nothing to hide" --and complete bit of
> nonsense, but very prevelant.

i am hoping the frogs will notice the rising water temperature.  foolish
of me, probably.  but this is one reason why i suggested privacy by
default.

---

From: Randy Bush <[email-masked]>
Date: Sun, 18 Aug 2013 01:59:26 +0900

> I'd say storing it locally would be fine

and doing what?  trusting it?  puhleeze!

randy

---

From: Ben Laurie <[email-masked]>
Date: Sat, 17 Aug 2013 13:07:58 -0400

> and doing what?  trusting it?  puhleeze!

This is precisely why you want a _verifiable_ map. So you don't have to
trust it.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Aug 2013 13:20:13 -0400 (EDT)

> "Privacy by default" has, up to now, been a failure in the IETF.

It has been a conscious choice though. For example, compare IKEv1 versus
IKEv2. The privacy of the ID against passive attackers was sacrificed
to save a single RTT. I know "we" (the freeswan people) did not agree,
but everyone else considered speed more important.

I think we have learned since, that with things like session resumption,
we can perhaps get both privacy and speed, although the session
resumption in itself could also be an information leak.

> Discussions about monitoring is a sensitive subject.

Indeed. Many years ago when in The Netherlands, lawful interception
became a reality for ISPs, and a tapping specification (TIIT) came into
existence, ISPs were forced to install commercial "black boxes" that
complied to the spec. I tried to get funding to make an open source
implementation. I quickly found that no one wanted to be known for
sponsoring an interception device. Everyone agrees an opensource box
is better than a blackbox, but everyone was afraid of misinterpretation.

Paul

---

From: Dave Crocker <[email-masked]>
Date: Sat, 17 Aug 2013 10:32:16 -0700

> "Privacy by default" has, up to now, been a failure in the IETF.  As you

We probably should draw a bright line between basic, classic 
"confidentiality" mechanisms, versus whatever we mean by "privacy". 
(The IAB was explicit in not being willing to choose a specific 
definition for its RFC on the topic -- however we might want to settle 
on one, to assist technical guidance.)

Better confidentiality mechanisms (eg, content encryption) might 
facilitate better privacy, but keeping the two constructs clearly 
distinct will probably aid both group focus and clarity about the work 
when communicating to others.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Aug 2013 13:37:30 -0400 (EDT)

> automagically encrypted to the recipients for whom i have a public key.

We should run a mailserver on localhost and have that support encryption
to OPENPGP/SMIME keys from DNSSEC. That way, we don't have to wait
another decade for mail clients not to support encryption in a way
that the masses can use. And it can run on everyone's phone.

Paul

---

From: SM <[email-masked]>
Date: Sat, 17 Aug 2013 12:30:12 -0700

Hi Paul,
>resumption in itself could also be an information leak.

Maybe the IETF could look at this from a "what have we learned" angle 
since then and how we can privacy together with the features we would 
like to have.  To say it different, if there is a trade-off between 
privacy and something else, do we sacrifice privacy in making that trade-off?

>is better than a blackbox, but everyone was afraid of misinterpretation.

It's bad PR and that's the angle people value more.  The benefit of 
having an open source implementation is that anyone who wants to know 
what is being done can read the source code instead of relying on 
rumors which lead to fear and deception.

By the way, you might have tried to implement too early, i.e. people 
may not have understood the value of what you were trying to 
do.  It's also difficult to get funding for anything that isn't 
mainstream if you happen to be in the wrong country.

Regards,
-sm