Subject: [perpass] perpass: what next?

From: Stephen Farrell <[email-masked]>
Date: Fri, 17 Apr 2015 12:29:47 +0100

Hiya,

I think this list has been really useful since we started it back
in August 2013. We initiated a bunch of new work on here (e.g. cfrg
curves, tcpinc, dprive, rfc7258) and I think the concerns dealt
with here have influenced lots of other work in the IETF as well.
Many thanks for all that great input and of course most of the
things above aren't finished, but even so, we're now looking for
some more great input:-)

The IESG will be meeting f2f in early May at our "retreat" and one
of the topics on that agenda is "where next with perpass" so your
ideas on that are very welcome.

Please discuss those here and/or send 'em to the IESG or to some
random AD or to me. But discussing 'em on this list is way better,
and of course even betterer is to write an I-D (and please do point
again at ones you've written, just to refresh folks' minds).

While I do have some ideas, I'd rather not skew the discussion by
throwing those out right now. I will also report back here after
the IESG discussion.

And just as a reminder, we've used this list mostly for very
initial discussions and seen all chunky items of work handled
elsewhere, be that in current WGs or by forming new WGs or
whatever. I think that's been a good mode of operation so far,
so we're not really asking here about how to change that, but
rather for discussion of which topics we can usefully try handle
in that same way over the coming year or two.

So, fire away...

Thanks,
S.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Apr 2015 10:02:32 -0400

> in that same way over the coming year or two.

I think that the items have been correctly chunked off, and I think that
waiting is not yet complete, so we can not yet grok what the next step is.

I think that the ACME work is very significant, and once it is further along,
I think that extending it into non-web-server realms is important.

The biggest issue that I see in the perpass space has been persistent market
failures of some of our key technologies.  Not entirely our problem, but each
time I see an industry "consortia" write a specification behind closed doors
that is more than a list of RFCs, I think we have failed.  Among groups that
I have observed the Broadband Forum has done the best job in my opinion.

This is very much a case where there has been a significant gap between what
we specify, and what there are resources to actually implement *AND*
deploy.  I wish that the consortia could be involved in funding and
coordinating open source reference implementations.  The Eclipse and Apache
foundations are sometimes really good at this, but they also seem to go and
invent new specifications at times for reasons I think has more to do who is
funding them than what is needed.

So my message to the IESG for your retreat is: how can the IETF better
leverage ISOC's contacts and marketing efforts... How can we make IETF work (including
"running code") more relevant to things like Tenure Track committees... can
we "infiltrate" NSF-like entities in various places.   Many ccTLD entities
seem to have money to spend on infrastructure initiatives (CIRA, nic.cz,
nic.nl, nic.mx are the ones I know about)... maybe there could be some overt
coordination here.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Mike Liebhold <[email-masked]>
Date: Fri, 17 Apr 2015 12:01:58 -0700

Hi all,

Congratulations on the great work to date.  But let's understand, that 
while the workproducts to date will help shore up the security of our 
legacy internet architecture, My impression after Snowden et. is that 
the whole stack offers up a vast exploitable attack surface. and that 
IETF ought to begin _serious_ consideration of completely new secure 
architectures - e.g.  a secure onion/tor routed peer internet,  
meshnets, blockchains for cerificated authentication ., etc.     It's a 
little ironic that the  military, IC and black hats already have secure 
p2p internets,  Isn't it time for the rest of us to enjoy the same 
levels of privacy and security, and *resilience*?

Michael Liebhold
Senior Researcher, Distinguished Fellow
Institute for the Future
@mikeliebhold  @iftf

On 4/17/15 4:29 AM, Stephen Farrell wrote:
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 17 Apr 2015 21:44:14 -0700

> again at ones you've written, just to refresh folks' minds).

-Key discovery in email has been kicked around a bunch, but no
reasonable proposals yet. Doesn't seem that hard.
-Messaging might be premature to discuss, as there are various
approaches, but we should think about it.
-There has been talk of PGP refreshing, but I don't know if that
happened/is being worked on
-Much of the work on better SSH has been ignored in standards: would
be nice to see some things adopted (useable PKI, etc)
-Anonymity remains untouched.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 18 Apr 2015 13:29:00 +0100

Just adding a factoid...

> happened/is being worked on

Yep, there's been nicely active discussion on the openpgp list [1]
for the last month and a bit and that may be shaping up to turn
into a wg that'll mostly develop an RFC4880bis, at least to start
off with.

If anyone cares about that: goto [1] :-)

S.

[1] https://www.ietf.org/mail-archive/web/openpgp/current/maillist.html

---

From: Adam Caudill <[email-masked]>
Date: Sat, 18 Apr 2015 12:37:46 -0400

> reasonable proposals yet. Doesn't seem that hard.

Key discovery, if we limit the scope of the initiative, shouldn't be that
hard
to achieve, and could lead to a huge amount of progress.

Email is so horribly broken, I think the entire system needs to be
replaced, but
I think it's clear that we aren't at a point where that's going to happen.
While
I, and I think many of us, would like a solution that addresses the metadata
leaking and other major issues, the changes are too radical to work within
the
current system. So, if we can get to the point that we are encrypting a
higher
percentage, I think that's a goal worth pursuing. We aren't going to
achieve the
perfect, certainly not now, and to achieve anything, I think we are going to
have to limit our definition of good. While I want to see email as we know
it
replaced with something that provides strong modern crypto, forward secrecy,
minimal metadata leaks, and all messages encrypted by default - at this
point
I'd be happy if we could get the number of emails using end to end crypto
to a
non-trivial number. For now, that might be the best we can actually achieve.

Email is likely the largest source of exposed information that end users
expect
to be private, and while much has been done in other areas, email remains
wide
open. Opportunistic SSL/TLS has become more common, and it does provide some
privacy, we all know that it's not real security and how trivial it is for
an
active attacker to disable. This is an area that desperately needs some
progress
made. There's been some discussion on the endymail[1] list, but there hasn't
been any real progress - I don't believe anything actionable has come out
of it
so far.

[1] https://www.ietf.org/mail-archive/web/endymail/current/maillist.html

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2015 03:26:10 -0000

>reasonable proposals yet. Doesn't seem that hard.

There's a draft in DANE which I think is fatally flawed for reasons
that boil down to DNS lookups are utterly unlike mailbox lookups.  

I agree it's not that hard.  Something like webfinger with the http
server found via SRV should work.

R's,
John

---

From: Tim Bray <[email-masked]>
Date: Sat, 18 Apr 2015 20:26:24 -0700

I guess, since I submitted two revs of
https://tools.ietf.org/html/draft-bray-privacy-choices, it’s probably
self-evident that I think that’s a useful line of work.  But just to be
explicit: I do, and am available for editorial duties if there’s consensus
on moving it forward.

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Apr 2015 10:53:58 -0400 (EDT)

> server found via SRV should work.

And at the dane list it is also discussed why others think the current
proposal(s) work well for real life mailboxes, and why out-of-band
key discovery for email boxes is very problematic.

For perpass people not on the dane list, the proposals for key discovery
for verifying and encrypting email are:

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-03

https://tools.ietf.org/html/draft-ietf-dane-smime-08

Paul

---

From: carlo von lynX <[email-masked]>
Date: Tue, 21 Apr 2015 18:59:47 +0200

I'm so glad to hear more and more voices talk about
taking 'clean slate' into serious consideration.
After five years talking to walls I feel like the
walls are starting to shake...

On Fri, Apr 17, 2015 at 12:01:58PM -0700, Mike Liebhold wrote:
> [..] My impression after Snowden et.
> is that the whole stack offers up a vast exploitable attack surface.
> and that IETF ought to begin _serious_ consideration of completely
> new secure architectures - e.g.  a secure onion/tor routed peer
> internet,  meshnets, blockchains for cerificated authentication .,
> etc.     It's a little ironic that the  military, IC and black hats
> already have secure p2p internets,  Isn't it time for the rest of us
> to enjoy the same levels of privacy and security, and *resilience*?

Whoops! This is the first time I hear that some parts of the
Internet already *have* the sort of architecture some research
folks have been working on for over a decade now? Do you have
*any* pointers about this?

> I think it's clear that we aren't at a point where that's going to happen.

That, I firmly believe, is one of the greatest fallacies in the
community. Faceboogle, Whatschat and Snapapp have already proven
that users do not care about the looks of their messaging app as
long as it reaches their peers and possibly does so in a neater
way than old-fashioned formal e-mail.

I met a girl of twenty who managed to get to that age with *FIVE*
addresses in her e-mail address book. The only five institutions
or people she couldn't convince to use something fancier. And
this girl does care about privacy.. her group meets on Telegram
and uses end-to-end crypto.. but what's the point in preferring
e-mail if it is completely insecure? And of course the PGP hassle
is completely inacceptable.

So maybe, just maybe.. instead of waiting until the population
has to a large extent dropped e-mail and gone proprietary, we
should come up with something that actually works. Getting
people to install an app or operating systems to ship with a
new messaging standard is probably not the greatest hurdle.

Trying to remain backwards compatible at the expense of UX,
security and popularity is the big mistake here. Just let the
systems co-exist and watch how users will slowly migrate away
from e-mail as they migrated away from Myspace. To you that
may sound like apples and oranges, but to them it's just like
giving up on Myspace.

> While I, and I think many of us, would like a solution that addresses the metadata
> the current system. So, if we can get to the point that we are encrypting a
> higher percentage, I think that's a goal worth pursuing. We aren't going to
> achieve the perfect, certainly not now, and to achieve anything, I think we are going to
> it replaced with something that provides strong modern crypto, forward secrecy,
> point I'd be happy if we could get the number of emails using end to end crypto
> to a non-trivial number. For now, that might be the best we can actually achieve.

There is no "for now" - there is no reason to wait any longer
for better things. Technologies like GNUnet and RINA are waiting
to get debugged, improved and be deployed. A worldwide end-to-end 
encrypted and anonymizing communications system is a feasible
goal and focusing on anything less will make us contempt that 
we at least achieved *something* ... while Snowden and the NSA 
itself said that the metadata is the real meat that is 
threatening our western societies.

Letting a few people decide whether there is or isn't democracy
is exactly what the separation of powers (aka checks & balances)
was supposed to protect us from - but with the Internet we have
created a monster that makes it impossible to detect the
infringement of the secrecy of communication. And the metadata
collection makes the freedom of assembly a joke - it wasn't
intended as a means to know exactly who is dissenting with the
government.

Thinking that e-mail is such a huge investment that we cannot
step back from it and replace it is one of the great mistakes
in thinking that the IESG could focus on correcting. Another
one is the popular belief in the federation of servers as a
viable architecture. Federation has failed us several times.
See http://about.psyc.eu/Federation for a write-up on that.

> There's been some discussion on the endymail[1] list, but there hasn't
> of it so far.

I'm still waiting for replies to my proposal. I suggested to
either use the GNU Name System (GNS) or a Distributed Social 
Graph strategy to address the problems of keys, discovery and
SPAM protection seen in traditional mail systems.
                                                                                                                
I'm afraid the biggest hurdle in starting this kind of serious
discussion is that the technologies needed to make *distributed*
communications systems with agnostic relays (think Tor) rather
than metadata-scient servers are coming from the research 
community that has quietly worked on these topics for several
decades and is now confronting the majority of Internet experts
like you and me (luckily I started looking into this 5 years ago,
so I've got a little headstart) with a whole new design that 
hardly has anything to do with everything you have been familiar 
with in the past decades.

No more DNS/DNSSEC/DANE, no more X.509, no need for IPv6. So much 
of what was achieved will remain for secondary purposes but must 
be obsoleted for the main objective of making humans interact.

Currently I'd say http://freehaven.net/anonbib/ is the new IETF.
Scientific consensus and eventually running code is the new credo.
At least if we want to focus on the needs of humans, not make the
net a bit more responsive (QUIC) or the browser a bit more remote-
controllable (WebRTC) - usually with a cloud server acting as the
big brother.

Wait, there's more. Since we don't expect that there is enough
economic motivation for the great players of the Internet to
throw money at this problem and focus on it - some folks and I
have prepared a law proposal that would make secure and anonymous
networking a precondition for selling computers or devices after
a certain date. This would create the necessary incentive to
focus all engineering intelligence on solving these issues ASAP.
You may want to promote it (or suggest edits to it). It's here:
	http://youbroketheinternet.org/legislation/

So here's my three point plan for perpass:

- Do some housekeeping concerning old thinking that has long
  been disproven but keeps bubbling up in the collective
  mentality of the Internet engineering community.
- Promote thorough analysis and understanding of what some of
  us call "GNU Internet" technologies (lacking better terms).
  Create the mental foundation necessary to be able to
  participate in the process.
- Start working on some layers and protocols involved, since a
  whole new stack is necessary for end-user apps to materialize.

As it stands it's like TCP/IP happening again: a few
visionary guys are brewing up the entire network stack and
everybody else will start discussing it when it's already a
reality going into people's households.

-- 
  E-mail is public! Talk to me in private using Tor.
  torify telnet loupsycedyglgamf.onion		DON'T SEND ME
          irc://loupsycedyglgamf.onion:67/lynX  PRIVATE EMAIL
         http://loupsycedyglgamf.onion/LynX/    OR FACEBOOGLE

---

From: Mike Liebhold <[email-masked]>
Date: Tue, 21 Apr 2015 13:24:02 -0700

On 4/21/15 9:59 AM, carlo von lynX wrote:
> the first time I hear that some parts of the
> Internet already*have*  the sort of architecture some research

e.g.
- hidden services on TOR , and other onion networks
https://www.torproject.org/docs/hidden-services.html.en

-  Military MANETs Mobile Ad Hoc Networks e.g.
  https://datatracker.ietf.org/doc/charter-ietf-manet/

- Zeta Cartel wireless network,
http://www.wired.com/2012/11/zeta-radio/

- the blockchain...etc..

There's lots more

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Apr 2015 06:58:31 -0700

> key discovery for email boxes is very problematic.

There's a difference between actually solving a problem, and making a
stab at a solution. Unless you are a mail provider, you don't know
what's actually deployable. In fact, adding SMTP commands and extra
headers containing keys is probably much less burdensome from an
operational perspective: patching software vs. hooking things up in
weird ways.

Proposals need to answer the following questions
1: Who gets to say which key to use?
2: How is key rotation handled?
3: Is this going to be compatible with Google/Yahoo/Microsoft's
existing way of doing things?
4: How hard it is to start using the new system?

As far as I can tell, the DANE based solution doesn't answer much of this.

Sincerely,
Watson Ladd

---

From: carlo von lynX <[email-masked]>
Date: Thu, 23 Apr 2015 15:31:09 +0200

> https://www.torproject.org/docs/hidden-services.html.en

Ehm okay, like everybody else too.. Tor is a bit half way there:

- by not providing bidirectional authentication it favors
  client/server architectures even when routing by public key.
  where it bidirectional, doing e2e apps would be more easy.
- by artificially trying to provide real-time performance
  Tor is unnecessarily easier to de-anonymize by traffic shaping.
  A fix called "alpha mixing" is however in the planning since 2006.
- various other minor issues with the DHT etc to be fixed...
 
> http://www.wired.com/2012/11/zeta-radio/

heard of these, but didn't think they could be employed this way.
will look into them.

> - the blockchain...etc..

Bitmessage seems to perform better than I originally expected...
because it does not use plain blockchain technology. Blockchain
as such must theoretically run into scalability issues as
popularity increases, according to my understanding of physics.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Thu, 23 Apr 2015 15:21:36 -0400

> again at ones you've written, just to refresh folks' minds).

Heya,

We've authored and will be updating soon an I-D on technical methods
used to accomplish censorship:

https://tools.ietf.org/html/draft-hall-censorship-tech-00

I'm going to be updating that within the next week and will have an
academic co-author.

I'm looking to generate a series of documents like these that cover
topics that IETF engineers might find valuable when doing protocol or
implementation work if they'd like to avoid unanticipated and
potentially problematic uses of their protocols. The next subject to
tackle (and it may be better to break down further) in my mind is
traffic analysis, which can be a bear of a topic (i.e., very hard).

Since there is no natural WG for this work, but I'm hopeful it could
be valuable work, I was hoping perpass would be a great place to have
discussion about these kinds of cross-WG topics in pervasive
monitoring (and maybe a few will make the cut and garner AD
sponsorship... but that seems a ways off!).

best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 29 Apr 2015 10:53:22 -0700

> -----Original Message-----
On Friday, April 17, 2015, at 4:30 AM, Stephen Farrell wrote:
> ...

OK Stephen, since you asked...

In general, I think of privacy mitigation in three steps. First, we have to
deploy encryption, and make sure that it actually works. We have lots of
activity on that. 

Second, we have to consider all the metadata that is not covered by
encryption, such as header elements or management protocols. We should apply
data minimization to mitigate that. We have some activity starting therewith
the DHCP anonymity profile in DHC and the data minimization work in DNSOP.
We need more of that, there are plenty protocols that leaks unencrypted
information, we have to scrub them.

Finally, we have to look at the "end-to-end" issues, such as all the
tracking that is taking place by means of cookies, cached files, browser
fingerprinting or e-mail analysis. I understand that the latter issue is a
bit controversial. The "pervasive monitoring" work concentrates on a threat
actor that can passively monitor a bunch of links, typically a state actor
with very big budgets. But protecting against this passive monitoring is not
sufficient.

Suppose that an advertising system collects enough data to understand the
type of chocolate that consumers prefer, their age, or the time they drive
their car. Suppose that this advertising company receives a visit of the
"men in black." They ask a simple question: please run this filter for us,
we really need to identify the "youth morning driver chocolate liberation
front." For the company, that is very much an "offer they cannot refuse."
For the men in black, that's way more effective than having to install a
bunch of taps everywhere and run a lot of data collection. And it doesn't
matter that all the traffic from the members of the liberation front was
encrypted...

-- Christian Huitema

---

From: Stefan Winter <[email-masked]>
Date: Thu, 30 Apr 2015 09:21:01 +0200

Hi,

> that is more than a list of RFCs, I think we have failed. [..]

> deploy.

I have one example where we have left spec-writing to third parties and
thus seem to neglect the "deploy" part of the value chain to some
extent, and one which leads to security and privacy problems.

My main focus of work is secure enterprise wireless networks. The medium
is of course IEEE's "problem", but the secure authentication part brings
in EAP, which is an IETF spec.

EAP is a really complex protocol and needs server *and* client side
config to deliver its security properties. Two short examples:

a) the end-user device /can/ configure an anonymous outer identity for
authentication routing purposes (concealing the local part of the
username); but that's extra config. If neglected, the end-device leaks
the actual username of the person trying to authenticate across the AAA
infrastructure.

b) the end-user device /can/ be configured to verify the X.509
certificate of its EAP server before it sends the user credentials; but
the user needs to install CAs and whatnot. If neglected, the end-user
device will send passwords to random third parties (and we have some
anecdotal evidence suggesting the rate of such "don't care" configs is
>>50%).

EAP asks much from a server operator and the end user trying to
configure it. Assuming that everybody will just get it right is delusional.

A variety of (non-interoperable) third-party approaches to
automated/better/more convenient EAP configuration has blossomed,
creating a mess of config formats / sane defaults / insane defaults
landscape.

I've tried to bring work to the IETF to create a config file format for
EAP; the basic idea being that if IETF created EAP, we should also
create a means to communicate EAP *configuration*.

I didn't find a spot-on working group to take this to and presented it
to opsarea / opsawg instead.

There was only a rather mild interest in the draft, it hasn't led to
much review activity or a motion to adopt it as a WG draft at this
point. I find that a bit disappointing. I'm considering to go AD
shopping to publish this in the ISE stream for the lack of a better path
to publication.

But really... this is privacy (and security!) relevant work, it's about
an IETF technology, it is about a technology which is in active use out
there, and it obviously is a piece of work that needs standardisation
because there are so many non-interoperable approaches. So... why does
such an item gain so little traction? I don't know the answer; if anyone
does...

BTW, the current draft is here; as it happens, it expires today, and
honestly I'm wondering if it's worth refreshing it:

https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Michael Richardson <[email-masked]>
Date: Thu, 30 Apr 2015 09:52:17 -0400

> shopping to publish this in the ISE stream for the lack of a better path

I agree that we do a poor job here, and I think that we should make this kind
of interaction smoother.  I spent four years working on rfc4332 (OE for IPsec/IKE),
and version 1 was always going to be on the ISE.

    > https://tools.ietf.org/html/draft-winter-opsawg-eap-metadata-01

I would say yes. I was going to ask if there were implementations, and you
clearly have some... Would there be value to deploy this at IETF meeting
networks?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Apr 2015 10:58:11 -0400

> clearly have some... Would there be value to deploy this at IETF meeting

That would certainly be interesting. I definitely agree with Stefan's main point here that 802.1x is too difficult. There is no common language or set of operational assumptions shared between different client implementations, so it's impossible to carry what one has learned about configuring it in one context to another.  I would like to see work on this happen somewhere in the IETF.

One of the IT folks at my office yesterday was complaining about how hard it is to configure, and also the lack of widespread 802.11w support in clients and servers (although this particular issue is something we may not be able to do anything about). This conversation happened because I was trying to get a chromebook on our office network for the first time and not only was the UI completely different than the apple UI, when it failed there was no way to figure out from the error message why it had.