Subject: [perpass] BoFing in Vancouver

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Sep 2013 16:58:15 +0100

Hiya,

In case folks here aren't on the main IETF discuss list, there's
been a flood of mail [1,2,3] there on this topic, and Jari and I
wrote a bloggy thing [4] as well.

The IAB are considering how to deal with some of this stuff as
part of the tech plenary in Vancouver. [5] I guess we'll hear
more about that as it firms up.

But since a tech plenary is probably not the best place to try
get work (or plans for work) done, the IESG and IAB also discussed
having a BoF-like session for more detailed discussion of the
topic and what the IETF could or should be doing.

Current thinking is to have a session based around the discussion
on this list, so that'd probably be called the perpass BoF but as
with the list, there's no plan for this to be a WG forming BoF.

So, this is a call for:

a) suggestions as to how to best use some face-to-face time,
b) agenda proposals, and,
c) folks who are willing to volunteer to do stuff (e.g. lead
   a discussion on topic foo, write an I-D about bar,...).

I guess (a) and (b) are better done on the list, but feel free
to send me offlist mail about (c).

As the next IETF meeting [6] is coming up quite soon, please
try respond to this in the next week or so if you're going to.
The IESG/IAB call where we agree what BoFs to have is on
Sep 24th and it'd be nice to have a reasonable idea about
how we'll handle this before then, so this isn't a hard
deadline and there'll be further calls for input before we get
near to having a worked out agenda.

My initial idea for this would be a 2/2.5 hour session where we
have someone scene-set, then some open-mic, then a set of short
presentations about specific problems or things the IETF could
do, and then more open-mic. Hopefully we'd wrap up with a list
of actionable things and associated victims^H^H^H^H^H^Hvolunteers.

I think the drafts that Brian [7] and Yaron [8] have written
are fine examples of the kind of specific thing for which
we'd want to have short presentations. (BTW: As always, more
drafts are welcome.) I don't think we want overly fuzzy or
broad presentations and we don't want to have presentations
that merely complain about the state of the universe, so
please do keep in mind that the IETF cannot fully "solve"
whatever it is you think the problem is, and that what we're
after here is to identify specific pieces of IETF work that
are doable and that can help mitigate the threat of pervasive
monitoring.

But I'm very open to other suggestions if you have 'em or to
being told the above is crazy, if that's what you think.

In the meantime please continue to use this list for discussion
of specific things the IETF could or should be doing and if
you intend to write up an I-D on this topic, just fire ahead
and do that and then send a link to the list, same as always.

Thanks,
S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg82071.html
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg82073.html
[3] http://www.ietf.org/mail-archive/web/ietf/current/msg82167.html
[4] http://www.ietf.org/blog/2013/09/security-and-pervasive-monitoring/
[5] http://www.ietf.org/mail-archive/web/ietf/current/msg82266.html
[6] http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF88
[7] http://tools.ietf.org/html/draft-trammell-perpass-ppa
[8] http://tools.ietf.org/html/draft-sheffer-tls-bcp
[9] what a lot of references :-)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 10:39:52 -0600

On 9/9/13 9:58 AM, Stephen Farrell wrote:

> So, this is a call for:
> 
> a) suggestions as to how to best use some face-to-face time, b)
> agenda proposals, and,

We'll want to use the high-bandwidth time wisely, and we know that
security-related discussions (well, all discussions) can easily go off
track. Staying focused on the core issues, and on problems that might
have engineering solutions, will be paramount.

> c) folks who are willing to volunteer to do stuff (e.g. lead a
> discussion on topic foo, write an I-D about bar,...).

I'm willing to lead a session, write I-Ds, etc. Indeed, while you were
writing your email message, I was writing an I-D about the use of TLS
in XMPP:

https://datatracker.ietf.org/doc/draft-saintandre-xmpp-tls/

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Scott Brim <[email-masked]>
Date: Mon, 9 Sep 2013 12:48:04 -0400

As long as you reserve a room that can hold 400 people and some
reporters, I think a BOF is a fabulous idea. :-)

Scott

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Sep 2013 10:52:00 -0700

> topic and what the IETF could or should be doing.

The plenary could be an excellent venue for a tutorial on operational 
and technical privacy issues at Internet-scale systems level.

The current furor is over "monitoring", where that seems to have less to 
do with simple, link-level wiretapping and more to do with compromised 
intermediaries.  (It's fine if I have that wrong; I'm interested in 
having the tutorial offer clarity about the actual threats we should be 
focusing on and, perhaps, comment on basic techniques for mitigating them.)

The purpose of the plenary, then, would be to get the IETF onto the same 
page about the problem space we should be considering and the technical 
toolset available for dealing with it.

If it happens that there is simple, low-hanging fruit, such as improving 
random-number implementations, or the like that's obviously good and 
needs to be pursued, but I doubt that's the serious and substantive part 
of the work that needs to be done.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Brian Trammell <[email-masked]>
Date: Mon, 9 Sep 2013 19:54:32 +0200

hi Stephen,

I'm certainly happy to do a quick presentation on the threat model outlined in -perpass-ppa, as well as leading a discussion on next steps with the model and where we see it being useful, in Vancouver. 

I expect I'll have time to get a -01 revision out soon, as well; certainly before the meeting.

Cheers,

Brian

On Sep 9, 2013, at 5:58 PM, Stephen Farrell <[email-masked]> wrote:

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Sep 2013 14:15:15 -0400

I would like to keep discussion of NSA capabilities out of the BOF as well.

For the sake of having a focused and effective discussion I think we should
just stipulate the list of possible compromises and focus on what we can do
to address them.

Speculation as to the nature of the NSA capabilities is probably best done
in the bars and on mailing lists. What we discovered over the weekend
should cause a lot of the assumptions as to how PRISM works to be reviewed.

When we first heard of PRISM it was assumed that the data was being
voluntarily disclosed by Google etc. It now appears that it is plaintext
traffic on the Internet trunks that is being intercepted.

While it is true that the NSA probably can't do the intercepts without any
help, we can't build an Internet without intermediaries either. The
question at issue should be not whether an intermediary can default but
whether that default could be detected.

Ben Laurie's Certificate Transparency demonstrates a way to keep one set of
intermediaries under constant observation making default unlikely to
succeed unobserved. We need to start looking for equivalent schemes for all
the intermediaries we are forced to trust.

These include:

1) Generation of ECC Curves

2) Cryptographic Hardware, in particular SSL accelerators
2a) Kleptography as described by Motti Young to encode random seeds in the
modulus
2b) Disclosing private key through TLS covert channel

3) CAs

4) Standards organizations

On (4) the folk who I am suspicious of are not so much the direct
participants but the folk who I have never met that pop up and send me
private emails telling me that they agree wholeheartedly on some proposal I
am making and I should resist attempts to make some change.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 09 Sep 2013 20:20:06 +0200

> I would like to keep discussion of NSA capabilities out of the BOF as
We shouldn't get bogged down by politics but lets agree that we need a
clear understanding of our ... ahem... design goals? right?

        Cheers Leif

---

From: Dave Crocker <[email-masked]>
Date: Mon, 09 Sep 2013 11:39:52 -0700

> a) suggestions as to how to best use some face-to-face time,

On this list or the plenary or both:  List topics worthy of pursuit; 
develop the explanation of them as much as possible.  Hence, avoid 
tutorials during the BOF.

So, use the BOF to debate priorities and possible lines of development.

I'll suggest a baseline and then three major 'bins' to put topics into, 
and they probably can be explored in parallel:

0.  Establish the Baseline

     In effect, this would be documenting real-world exposures, based on 
operational data and not just conjecture.  What are the actual threats 
that are relevant here?

     I'd also lobby for settling on a definition of privacy that helps 
us pursue the current concerns.  I couldn't convince the authors of RFC 
6973 to choose a definition, but still feel that an effort claiming to 
be about privacy needs to define it in technical and/or operational terms.

1.  Implementation & Deployment Cleanup

    Some problems are due to poor implementation of otherwise-well 
documented and understood issues.  For example, I've heard that random 
number generation is one of those, with failures to fully appreciate RFC 
1750. IETF work could be to:

      a) document common implementation problems and their best fixes;

      b) BCP(s) for integrated deployment of the relevant capabilities; 
that is, noting all the necessary pieces and how they fit together, to 
mitigate specific privacy-related concerns.

2.  Component Robustness

     For pieces of relevant technology, such as specific functional 
algorithms:

      a) review relevant IETF docs for sufficiency and tweak or replace 
where needed;

      b) identify missing components and develop them.

3.  Internet-Scale Systems Issues

     Document end-to-end privacy-related concerns and specify the 
integrated set of mechanisms that will reasonably mitigate them.  Here's 
where concern about compromised intermediaries would factor in, for 
example; TLS is useless for that, for any intermediary at, or above, 
transport level. Another line would be meta-data vs. content analysis.

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 9 Sep 2013 16:32:47 -0400

> clear understanding of our ... ahem... design goals? right?

Yes, and I think we can get those thrashed out on the list before the BOF.

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

---

From: Dean Willis <[email-masked]>
Date: Tue, 10 Sep 2013 12:31:40 -0500

On Sep 9, 2013, at 11:39 AM, Peter Saint-Andre <[email-masked]> wrote:

> Signed PGP part

That makes me wonder if a second session should be allocated for the obligatory hand-wringing and mic-ranting, or if we're planning to do that at the plenary level.

You know http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model ...

Denial, anger, bargaining, depression, acceptance.

We don't have a surveillance problem. 
I'm angry that we've been surveilled and that they planted people in our organization to make it easier. 
Maybe if we just use TLS everywhere, it'll be OK. 
This isn't going to work, and I'm sad and giving up on the Internet. 
Oh well, the NSA reads my email, so I don't have to. Beer!

--
Dean

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 10 Sep 2013 13:56:58 -0400

On Tue, Sep 10, 2013 at 1:31 PM, Dean Willis <[email-masked]>wrote:

> That makes me wonder if a second session should be allocated for the
> obligatory hand-wringing and mic-ranting, or if we're planning to do that
> at the plenary level.
>
> You know http://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model<http://en.wikipedia.org/wiki/Kübler-Ross_model>
>  ...
>

Well welcome to the club.

But another point that makes me rather angrier is that we are all now
potential NSA plants. Or rather would if not for the fact that pretty much
everyone feels free to accuse CAs of being tools of the NSA anyway.

The point is that everyone is now in the same boat I have been in these
past 20 years. And just as nobody ever thinks much about my feelings when
accusing me of being an NSA plant I am going to feel free to throw it all
back.

I really don't think it likely the NSA cryptanalytic capabilities are based
on CA compromise because I really can't see how the EFF and co could have
missed the evidence of a program as large as the one revealed by Snowden.
Even without CT, a CA compromise leaves marks.

I don't think the point of compromise is in Google etc. either. Too many
people would have to know. But I certainly won't rule out that as a
possibility.

Looks to me as if PRISM is an old school attack and involves back hoes and
splicing fiber optic cables. That would certainly be consistent with what
we know of the cost of bringing companies into the program. It is the way I
would do it.

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 Sep 2013 14:03:03 -0400

> have engineering solutions, will be paramount.

This is a scope question.  How do we decide what to focus on?  I
suggest that we start by saying it's not security, and it's not
surveillance, it's privacy, i.e. the ability to control the flow of
one's personal information (there's your definition, Dave).  Security
is too large a scope, while surveillance is too small.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Sep 2013 21:26:37 +0300

I suggested within the IAB to do a workshop* (before the meeting), which 
would give us an extra day of intense discussion time. Unfortunately, it 
is a bit close to the next meeting (which  complicates travel planning) 
and some folks have booked their trip already...

Despite all the discussions I fear that a BOF slot will make it very 
difficult to discuss such a broad topic and to make some progress.

Ciao
Hannes

(*): I know that it is not the first time I have suggested a workshop.

On 10.09.2013 21:03, Scott Brim wrote:
> On Mon, Sep 9, 2013 at 12:39 PM, Peter Saint-Andre<[email-masked]>  wrote:

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Sep 2013 11:34:31 -0700

On 9/10/2013 11:03 AM, Scott Brim wrote:
>>  Staying focused on the core issues, and on problems that might
> This is a scope question.  How do we decide what to focus on?

1. I agree with Peter's call for focusing on core issues

2. I'll suggest that deciding on what those are is, itself, the most 
core issue.

Much of what has been getting posted pertains to component mechanisms. 
They are pretty obviously useful mechanisms, but we have no foundation 
for determining whether they are relevant -- or more importantly, 
essential -- to the scope of perpass work.

We need to make sure that we are not merely looking for our keys under 
the lamppost.

d/

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 10 Sep 2013 13:35:52 -0500

Hannes, if we have not solved all the problems such a workshop(*) would
address by December, I would certainly support a workshop in something like
the London IETF timeframe :-)

Spencer

(*) and this is not the first time I've said something snarky and then
supported a workshop you've proposed, either!

On Tuesday, September 10, 2013, Hannes Tschofenig wrote:

> would give us an extra day of intense discussion time. Unfortunately, it is
> a bit close to the next meeting (which  complicates travel planning) and
> some folks have booked their trip already...
>
>> ______________________________**_________________
>> perpass mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>>
>
> ______________________________**_________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/perpass<https://www.ietf.org/mailman/listinfo/perpass>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Sep 2013 21:46:54 +0300

One approach to focus the discussion is to limit it to what the IETF can 
do. Within that category one could also focus on specific applications 
to make it (a) down-to-earth and (b) have a bit time for preparation.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Sep 2013 21:48:52 +0300

Hi Scott,

as you know we have been working on this privacy tutorial (and you have 
given feedback on the trial run). Maybe some information from the 
privacy tutorial would be useful in the discussion to better understand 
the range of privacy related threats and some of the terminology.

Since we (IAB Privacy Program) had planned to re-run the tutorial for a 
wider audience that might actually be useful preparation.

What do you think?

Ciao
Hannes

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 Sep 2013 14:58:46 -0400

On Tue, Sep 10, 2013 at 2:48 PM, Hannes Tschofenig
<[email-masked]> wrote:
> given feedback on the trial run). Maybe some information from the privacy
> tutorial would be useful in the discussion to better understand the range of
> privacy related threats and some of the terminology.
>

Yes, that would be great as a foundation for the privacy discussion.
You should add material about surveillance. If you're willing, I
suggest you "flip" it as in flipping education: when you think the
deck is ready, send it out, have a bit of discussion in lieu of
presentation, and then have a real discussion of it at the BOF.  You
would be revealing it earlier than planned but not too much earlier.
I think everyone would win.

---

From: Scott Brim <[email-masked]>
Date: Tue, 10 Sep 2013 15:00:54 -0400

On Tue, Sep 10, 2013 at 2:46 PM, Hannes Tschofenig
<[email-masked]> wrote:
> One approach to focus the discussion is to limit it to what the IETF can do.

Sounds good.

> Within that category one could also focus on specific applications to make
> it (a) down-to-earth and (b) have a bit time for preparation.

Want to start with the drafts recently discussed here?

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 10 Sep 2013 22:27:22 +0300

> Want to start with the drafts recently discussed here?

Do you think that the drafts need some face-to-face discussion time? We 
should be able to finalize them before the IETF meeting.

draft-sheffer-tls-bcp-00.txt lists well-known attacks and makes 
reasonable suggestions. Of course there is always room for improvement 
in the write-up.

draft-trammell-perpass-ppa-00.txt introduces the terminology for a new 
adversary model and that looks good to me.

draft-saintandre-xmpp-tls-00.txt is a bit related to Yaron's document 
but also makes sense. Maybe there is room for alignment with 
draft-sheffer-tls-bcp-00.txt.

I personally believe that the difficult aspects are elsewhere, namely

  * mandating an secure protocol design only (e.g. HTTP 2.0 with TLS-on 
always)
  * choice of trust models (think about ZRTP vs. DTLS-SRTP; PGP vs. S/MIME)
  * limiting ourselves to fewer choices (unlike in the SIP world where 
we have documents like 
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-13)
  * avoiding standardization of security solutions that are designed to 
support lawful intercept.

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Sep 2013 22:55:03 +0100

Good to see all the discussion. Keep it up!

Couple of points:

- I entirely agree that the BoF, other than scene setting (and the
usual ranting which we'll keep to a minimum:-) needs to be focused
on what the IETF can do. (Broader list discussion, e.g. about the
open-source community, seems fine and who knows might lead to some
concrete stuff we would like to talk about at the BoF.)

- I think that "privacy" is too broad and not sufficiently focused
as a topic for a BoF session. Much as I'd like to see more progress
on corporate privacy-busting, I think this session will be better
kept more focused on recent pervasive monitoring attacks and what
we can do in the IETF to mitigate those attacks.

- I agree with Dave that it'd be good to have a better idea of what
other protocols/areas of the IETF might be affected and/or part of
the answer. For example, the LISP WG list have an active discussion
now about encrypting encapsulated packet content. That wasn't one
that would have occurred to me but if the LISP folks are up for it
then it seems like a fine addition to their protocol. I'd be keen
to get more examples of IETF protocols where we could do stuff to
counter pervasive monitoring. The protocols where we improve things
btw don't need to have been part of current news stories - I don't
think LISP has featured for example:-)

So keep the discussion flowing and we'll organise more as we go.
Ta,
S.

---

From: Brian Trammell <[email-masked]>
Date: Tue, 10 Sep 2013 23:59:13 +0200

On Sep 10, 2013, at 8:03 PM, Scott Brim <[email-masked]> wrote:

> one's personal information (there's your definition, Dave).

Yep.

> Security is too large a scope,

Absolutely.

> while surveillance is too small.

A key difference between "privacy" and "privacy against pervasive surveillance" is that most models of privacy (including that in 6973) implicitly or explicitly assume that the attacker has a specific target in mind, and that the object of the game is identifying that target; in pervasive surveillance, this is not the case. This is indeed one of the reasons it's above and beyond (targeted) lawful intercept in terms of the threat it presents.

Practically speaking, being uninteresting is no defense (not that it's ever really a _good_ defense, "but I have nothing to hide" notwithstanding). Nor is being indistinguishable, if k-anonymity merely means you're lumped into a k-member group, such that that k-member group has defining characteristics that themselves may prove to be interesting. 

So, "privacy", but with a focus on pervasive surveillance as the specific threat.

Best regards,

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Sep 2013 23:12:24 +0100

> So, "privacy", but with a focus on pervasive surveillance as the specific threat.

+1, that seems right to me.

S.

---

From: manning bill <[email-masked]>
Date: Tue, 10 Sep 2013 19:53:51 -0700

yvr is out for me, but i would gladly participate in a workshop.   i'm concerned about the blanket use of security/crypto pixie dust
to ensure privacy…   some things, as Ted mentioned in another thread, don't need privacy - like time or routing.

/bill

On 10September2013Tuesday, at 11:35, Spencer Dawkins at IETF wrote:

> Hannes, if we have not solved all the problems such a workshop(*) would address by December, I would certainly support a workshop in something like the London IETF timeframe :-)
> 
> Spencer
> 
> (*) and this is not the first time I've said something snarky and then supported a workshop you've proposed, either!
> 
> I suggested within the IAB to do a workshop* (before the meeting), which would give us an extra day of intense discussion time. Unfortunately, it is a bit close to the next meeting (which  complicates travel planning) and some folks have booked their trip already...
> 
> Despite all the discussions I fear that a BOF slot will make it very difficult to discuss such a broad topic and to make some progress.
> 
> Ciao
> Hannes
>

---

From: David Lloyd-Jones <[email-masked]>
Date: Wed, 11 Sep 2013 01:54:06 -0400

I'm not up to speed on these issues, so I have nothing much to say in any
specific way ... yet.  :-)

I do think, however, that the IETF release is an awfully good piece of
work: mature, thoughtful and appropriate in tone. and I want the authors to
have my personal congratulations: good work. Well done.

Cheers,

-dlj.

---

From: Dean Willis <[email-masked]>
Date: Fri, 13 Sep 2013 11:39:53 -0500

On Sep 9, 2013, at 1:15 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> When we first heard of PRISM it was assumed that the data was being voluntarily disclosed by Google etc. It now appears that it is plaintext traffic on the Internet trunks that is being intercepted.

I recall that some of Vint's team at InternetMCI demoed a wire-speed interceptor using an optical splitter tap back before they were sold to Cable & Wireless. In my mind, optical splitter tap == a prism. And this was in the late 90's, so it's gotten better since then. Much better. I suspect that all that is needed is a slight kink in the fiber, and enough signal leaks out that it can be recovered.

> While it is true that the NSA probably can't do the intercepts without any help, we can't build an Internet without intermediaries either. The question at issue should be not whether an intermediary can default but whether that default could be detected.

Given that current belief is that both submarine and physical cables have been tapped, cross-factored with what I believe of the capabilities of multiple nations to perform undersea taps (you can read about in in Wikipedia), I believe we can assume that surveillance can and does occur without the assistance of intermediaries.

http://en.wikipedia.org/wiki/Signals_intelligence_operational_platforms_by_nation

So I second PHB's suggestion that discussion of capability-by-attacker be avoided, and we simply make the presumptions that wires leak, intermediary nodes at all protocol layers are compromised, and that you can be betrayed by anybody at any time, so no trust is absolute.

yes, I had a large box of paranoia for breakfast.

--
Dean

---

From: joel jaeggli <[email-masked]>
Date: Fri, 13 Sep 2013 09:49:41 -0700

On 9/13/13 9:39 AM, Dean Willis wrote:
> 
> On Sep 9, 2013, at 1:15 PM, Phillip Hallam-Baker <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
>> voluntarily disclosed by Google etc. It now appears that it is
>> plaintext traffic on the Internet trunks that is being intercepted.
> 
> I recall that some of Vint's team at InternetMCI demoed a wire-speed
> interceptor using an optical splitter tap back before they were sold to
> Cable & Wireless. In my mind, optical splitter tap == a prism. And this
> was in the late 90's, so it's gotten better since then. Much better. I
> suspect that all that is needed is a slight kink in the fiber, and
> enough signal leaks out that it can be recovered.

In the 90s that was OCxmon/DAG capture cards at oc3/oc12 and so rates in
64bit 66 mhz pci-x slots... That was heady stuff then but it's not super
exciting when PC's can have 40Gb/s nics.

>> While it is true that the NSA probably can't do the intercepts without
>> any help, we can't build an Internet without intermediaries either.
>> The question at issue should be not whether an intermediary can
>> default but whether that default could be detected.
> 
> Given that current belief is that both submarine and physical cables
> have been tapped, cross-factored with what I believe of the capabilities
> of multiple nations to perform undersea taps (you can read about in in
> Wikipedia), I believe we can assume that surveillance can and does occur
> without the assistance of intermediaries.
> 
> So I second PHB's suggestion that discussion of capability-by-attacker
> be avoided, and we simply make the presumptions that wires leak,
> intermediary nodes at all protocol layers are compromised, and that you
> can be betrayed by anybody at any time, so no trust is absolute.
>

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 13 Sep 2013 18:49:07 +0000

>> plaintext traffic on the Internet trunks that is being

PRISM is one program. There are many programs. Other programs are
responsible for dragnet surveillance, analysis and attacking
cryptography. XKEYSCORE is the name of the replicated search/query
system. There are literally thousands of programs that all have specific
names and meanings.

One of the best resources around is Bugged Planet - the main editor has
been keeping good track of every key word, every program, tv clips, news
clippings, etc:

  http://www.buggedplanet.info

If you require a general name for all of these programs, it isn't PRISM,
it is TYRANNY...

All the best,
Jacob

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 17 Sep 2013 16:00:25 +0000

Hi,

> One approach to focus the discussion is to limit it to what the IETF can do.

and, for those important topics that we aren't quite sure what the IETF impact is going to be or even if there is any, I want to mention that it is always possible to spin up a related research group in the IRTF. "Research" in the widest possible sense of "not (yet) engineering" - not necessarily academic science.

It'd need a few folks determined to run the show and grow/form the community. There certainly seems to be energy in this space at the moment.

The nice thing about the IRTF is that have way fewer processes than the IETF; for example, IRTF groups need not operate by consensus and can even be closed membership.

Lars

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Sep 2013 17:09:17 +0100

> The nice thing about the IRTF is that have way fewer processes than the IETF; for example, IRTF groups need not operate by consensus and can even be closed membership.

Hmmm...

"The CFRG is chaired by David McGrew([email-masked]) and Kevin Igoe
([email-masked])."