Subject: [perpass] refining the description of the perpass list

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Nov 2013 17:56:02 +0000

Hiya,

I think we got a great outcome last week, at the tech
plenary and all the other sessions where we discussed
pervasive monitoring. Thanks to everyone who sent mail,
presented or spoke at a mic for all your constructive
contributions.

Sean and I chatted at the end of the week and figured
it'd be useful to refine the description of this list
to reflect that progress. Hopefully that'll help us
keep the list more focused between now and London.
Since this is not intended to be a working group, this
isn't a charter, but is a bit similar, so we'd like
to run it by the list in case any discussion is needed.

We'd like to get that out of the way in the next few
days and then move on to discussion of how to go forward
with the bits and pieces of work that were identified
at the meeting and earlier on the list. (I need to go
back over the meeting notes and listen back to the audio
which I'll do in the next few days but let's get any
discussion of this out of the way first.)

Our current revised list description based on all that
happened in Vancouver is as follows:

"
The perpass list is for IETF discussion of pervasive
monitoring.

IETF specifications need to be designed to protect against
pervasive monitoring where possible.  This list is intended
for technical discussions attempting to meet that goal.

Discussion is limited to specific technical proposals for
improvements in IETF protocols and to IETF process changes
aiming to increase the liklihood that implementation and
deployment of IETF protocols results in better mitigation
for pervasive monitoring.

Those with proposals are encouraged to embody them in
detailed internet-draft specifications, rather than
relying solely email messages.

The typical modus-operandi of the perpass list should be
to identify a credible piece of work, with identified
volunteer effort, and then to find a home for that work
within the IETF. Once such a home is identified work
should move to whatever other lists are relevant.

Note that the perpass list is a non-working group list,
that is, there is no intent to form an IETF working
group on this topic.
"

Comments welcome, and we'll get back about the plan for
specific work items in a few days.

Thanks,
Stephen & Sean.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Nov 2013 18:59:05 +0100

> that is, there is no intent to form an IETF working
we could argue about words but I suggest not doing that

giving this my "+1"
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 11 Nov 2013 19:05:40 +0100

Am 11.11.13 18:56, schrieb Stephen Farrell:
> improvements in IETF protocols

So, the list would not be used for discussing the implementation or the 
deployment of IETF security protocols?

As an example, the XMPP manifesto Peter distributed, see 
https://github.com/stpeter/manifesto, would not be in scope of the 
discussions.

Ciao
Hannes

---

From: Robin Wilton <[email-masked]>
Date: Mon, 11 Nov 2013 18:22:14 +0000

Thanks Stephen,

I found the perpass session very constructive and useful, and I hope the same spirit will drive e activities of the list/virtual group.

I'd also just like to express my thanks for what I thought was an excellent contribution to the Technical Plenary on your part. Bruce Schneier can't be an easy act to follow, and you did a great job.

All the best,
Robin

Robin Wilton

Technical Outreach Director - Identity and Privacy

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 11 Nov 2013 14:10:52 -0500

> for technical discussions attempting to meet that goal.
Where "possible," or where "appropriate."

Surely you are not inferring that every "specification"
needs to be so designed?  It seems context dependent.
> for pervasive monitoring.
What if one believes that mitigation is not
appropriate, or that it pervasive monitoring
should be enhanced?  Those apostates should
go somewhere else?

Guess you don't want discuss improving the
protocols to enhance DPI or data retention. :-)

cheers,
tony

---

From: Robin Wilton <[email-masked]>
Date: Mon, 11 Nov 2013 19:26:58 +0000

Tony,

Since it's not plausible to assume you aren't aware of RFC 2804, I have to wonder whether some of your comments below aren't just meant to be deliberately provocative.

Best wishes,

Robin

Robin Wilton

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Nov 2013 08:37:30 +1300

On 12/11/2013 08:10, Tony Rutkowski wrote:
...
> should be enhanced? 

Hi Tony,

In the IETF we try to focus our lists on precise objectives. I didn't
see you in Vancouver but I assume you watched the plenary (if not, it's
available at www.ietf.org/live). Despite a few complaints about details
of the way the hums at the end were phrased, the sense of the room was
pretty clear: the plenary felt that pervasive surveillance is a technical
attack and our technical specifications should defend against it. I take
the proposed revised charter for this list as embodying that sense and
describing a triage process for concrete technical proposals to achieve
it. That seems appropriate to me.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Mon, 11 Nov 2013 15:16:33 -0500

> for pervasive monitoring.

Wording issue: "mitigation" is "the action of reducing the severity,
seriousness, or painfulness". It would be best to (optionally) make it
possible to block pervasive monitoring completely.

Perhaps change "mitigation for" to something like "potential resistance to"?

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 11 Nov 2013 15:26:45 -0500

Hi Robin, Brian,

It's not clear why asking whether "IETF specifications
need to be designed to protect against pervasive monitoring"
without exceptions is "deliberatively provocative."

And Brian, I don't care who met and what anyone
through they hummed.  It just seems to me that
the assertion is extreme.    RFC 2804 is at least
neutral.  It doesn't require swearing allegiance to
a particular view or doing anything affirmative
for ever activity of the organization.

Furthermore, no one has yet defined what is even
meant by "pervasive monitoring."  That seems rather
different from what RFC 2804 is attempting to cover.
There might be all kinds of different forms and contexts
of platforms that nominally fall under the aegis of
pervasive monitoring that are perfectly appropriate if
not needed.  For example, the use of SMTP on my own
network is arguably pervasive monitoring.  Watching
for malware at gateways is pervasive monitoring.

I participate in a great many standards bodies, and
have no particular allegiance or reverence for any
them, including the IETF.  You might consider that
the IETF may have just gone off into religious
territory of unquestionable belief that does not
serve the IETF well.

--tony

---

From: Robin Wilton <[email-masked]>
Date: Mon, 11 Nov 2013 21:44:39 +0000

Tony, specifically, you mused on whether the IETF should work on specifications that enhance pervasive monitoring, DPI and data retention. 

I think RFC 2804 set out a very clear, principled IETF position on interception of communications.   I think it would be strange if, at the first IETF since the Snowden revelations, the consensus was to do more to enhance the technology of wiretapping, rather than to reaffirm the principles on which 2804 was based.

I hope this makes it clearer why there were parts of your email that I found hard to accept at face value.

Yrs.,
Robin

Robin Wilton

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Nov 2013 22:03:27 +0000

Hi Scott,

> Perhaps change "mitigation for" to something like "potential resistance to"?

To be honest, I think mitigation is really more accurate
and will be more widely understood. The term is common when
considering threats/attacks, whereas "resistance" could
require explaining.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Nov 2013 22:05:58 +0000

Hi Hannes,

> https://github.com/stpeter/manifesto, would not be in scope of the

Good catch! That, and the like, should clearly be in scope.

I'd count it as an improvement, though since its not a change
that's probably not clear enough in the above.

I've tidied up that paragraph to say:

"
Discussion is limited to specific technical proposals for
improvements in IETF protocols, their implementation or
deployment and to IETF process changes aiming to increase the
liklihood that development, implementation and deployment of
IETF protocols results in better mitigation for pervasive
monitoring.
"

Cheers,
S.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Nov 2013 14:05:48 -0800

> To be honest, I think mitigation is really more accurate

Mitigation has a nicely clinical ring to it.

I'm more worried about whether the 'for' should be an 'of'.

Does this depend upon the English dialect at play?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 11 Nov 2013 22:46:49 +0000

Tony,

> Where "possible," or where "appropriate."

I think either is good enough.

> should be enhanced?  Those apostates should

If someone believed that, then they would be unlikely
to be a happy and constructive contributor on this list;-)

As Brian points out, refining the list to this scope is
entirely consistent with the Vancouver tech plenary
outcome. If you want to disagree with the outcome of the
Vancouver tech-plenary, then the list for that discussion
would be [email-masked] and not this one.

And to be clear, yes, there is the implication that
continued off-topic posting here (especially with occasional
inflammatory content as has happened) could lead to an
RFC 3683 PR-action, as I've previously explained to you
in off list mail.

I really hope you don't take us down that road, but I
want to be clear that this refinement of the list
description does mean that your continual statements
that this work is some kind of religious quest are now
quite clearly off-topic for this list.

In contrast, calling out any actual flaws in proposals
that are made is entirely within scope and is welcome.

S.

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 11 Nov 2013 18:49:04 -0500

Stephen,

I think the dialogue here provides an ample
indication of how extreme the behavior
has become in the IETF.  It is also interesting
to contrast that behavior with the many other
bodies industry bodies in this sector.

I guess the IETF really provides a home for
everyone. :-)

--tony

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 12 Nov 2013 00:33:47 -0500

> considering threats/attacks, whereas "resistance" could

In the Perpass session I pointed out that the problem is not limited to
covert surveillance like the NSA has been practicing. The problem of overt
surveillance is far harder to deal with.

The government of North Korea just murdered 80 people for the 'crime' of
watching South Korean TV [For comparison the communist system killed
between 0.3 and 3.5 million in the 1994-1998 famine and would be killing as
many again without foreign food aid]..

We are not going to do much more than mitigate in such situations and it is
quite likely that no standards based scheme is going to be appropriate
because steganography is an essential part of the solution.

-- 
Website: http://hallambaker.com/

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2013 09:34:45 -0500

Stephen,

I agree that mitigation is the preferred term.

I am not so comfortable with using this list to incrementally develop
new proposals via e-mail exchanges, instead of requiring proposals to be
prepared as I-Ds. There are enough folks on the list with IETF I-D prep
experience to assist anyone who needs help.

The rigor of writing a document usually helps refine one's ideas
(and spares others from half-baked notions :-) ).

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2013 14:40:52 +0000

Hi Steve,

> (and spares others from half-baked notions :-) ).

I agree, which is why I included this bit:

"Those with proposals are encouraged to embody them in
detailed internet-draft specifications, rather than
relying solely on email messages."

I'm quite happy to make that a bit stronger if someone
has words to offer, but we also don't want to push away
all mail discussion of course - I think it should be
fine if there's an initial discussion on a topic to see
if its worth pursuing, so long as that's fairly quickly
turned into an I-D and we don't get the "design via
email exchanges" thing taking up everyone's cycles.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 13 Nov 2013 12:56:28 -0500

I think I have something like 12 Internet drafts at the moment, at least
six of which are on these issues.

I don't write a draft on every proposal and far more people read the emails
than the drafts. Often the idea changes substantially during list
discussions.

Since many of my drafts are now written by a computer, there is not a great
deal more innovative content in the drafts than the on list discussion in
any case.

---

From: Dean Willis <[email-masked]>
Date: Wed, 13 Nov 2013 12:39:27 -0600

> protocols to enhance DPI or data retention. :-)

I think you've got it!

But it might be nice to have another group that is working "red team"
enhancements to DPI so we know what and who to watch out for...

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Nov 2013 17:37:21 -0500

Stephen,
...

> email exchanges" thing taking up everyone's cycles.
we're in agreement. so long as you moderate the list to maintain
the desired balance, I think it will be fine.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Nov 2013 23:22:48 +0000

> the desired balance, I think it will be fine.

Cool - and speaking of which, anyone else who's willing to
volunteer to help moderate this list please drop a mail to
Sean and I.

And if someone thinks some thread is out of control or has
other comments for the moderators, please do send those on.

I'll update the list description text as per this discussion
tomorrow.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Nov 2013 11:07:11 +0000

The new list description is up now. [1] Thanks for
not turning that into an endless debate!

I'd like to also thank Paul Wouters and Dave Crocker
for volunteering to do list moderation, so please heed
what they say if they need to put on that hat here
in future. Sean and I will still be listed as
moderators for a bit, but we'll be depending on Paul
and Dave to handle any issues that arise from now on.

Cheers and thanks again to Dave and Paul,
S.

[1] https://www.ietf.org/mailman/listinfo/perpass

---

From: pindar wong <[email-masked]>
Date: Thu, 14 Nov 2013 19:22:27 +0800

sorry I'm perhaps too late ... but I would have suggested that instead of

better mitigation for pervasive monitoring

we use

better mitigation of pervasive monitoring

i.e. mitigation of damages -- instead of mitigation for damages

*http://legal-dictionary.thefreedictionary.com/Mitigation
<http://legal-dictionary.thefreedictionary.com/Mitigation>*or

better pervasive monitoring mitigation.

I guess Tony will correct me.

p.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 14 Nov 2013 16:19:08 +0100

On Mon, Nov 11, 2013 at 06:49:04PM -0500,
 Tony Rutkowski <[email-masked]> wrote 
 a message of 22 lines which said:

> It is also interesting to contrast that behavior with the many other

I have the feeling that many (most?) of SDO are indeed driven by large
corporations eager to sell surveillance systems to various actors
(good or bad, as long as they have money) and are therefore willing,
not to increase the security of the user but, quite contrary, to help
surveillance, for instance by standardizing tools for it (see ITU's
NGN project, for instance).

I'm happy that IETF is different.