Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

From: Jari Arkko <[email-masked]>
Date: Wed, 4 Dec 2013 06:45:38 +0200

I wanted to draw your attention on this last call:

> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Pervasive Monitoring is an Attack'
>  <draft-farrell-perpass-attack-02.txt> as Best Current Practice
> 
> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/

It is a short read and important, so please comment. The last call ends in four weeks and covers holiday time, but we'll deal with this document on the January 9th telechat in the IESG, so in practice there should be enough time to comment.

I would like to see this document as a high-level policy we have on dealing with this particular type of vulnerabilities in the Internet. A little bit like RFC 3365 "Danvers Doctrine" was on weak vs. strong security. Please remember that the details and tradeoffs for specific solutions are for our WGs to consider and not spelled out here. The draft does say "where possible" - I do not want to give the impression that our technology can either fully prevent all vulnerabilities or do it in all situations. There are obviously aspects that do not relate to communications security (like access to content by your peer) and there are many practical considerations that may not make it possible to provide additional privacy protection even when we are talking about the communications part. But I do believe we need to consider these vulnerabilities and do our best.

Jari

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 04 Dec 2013 00:41:43 -0500

> I would like to see this document as a high-level policy we have on dealing with this particular type of vulnerabilities in the Internet. A little bit like RFC 3365 "Danvers Doctrine" was on weak v…

It is good to have the consensus recorded in a document like this,
but I think the current draft is too vague to be usefully cited
and not just abused as a club against ourselves in the future.
If it's worth making a BCP on this, then it's worth beefing up
to be more specific about what it means and what context it's
coming from.

I believe it should have at least a couple clear examples of:
- mechanisms that have been (or can be) used as mitigations
- examples of instances and general cases where incorporating
  mitigations is not a concern

I suggest both of these because I don't want to imagine many
reviews later on that say "you forgot to deal with pervasive
monitoring in the $FOO protocol", when there may not even be
good technical mechanisms available to deal with it, and/or
it may not even be applicable for the $FOO protocol.

For instance, this BCP shouldn't be able to be misinterpreted
to imply that all protocols need to implement their own crypto,
nor that they have mandatory incorporation of TLS, or anything
like that.

The "where possible" in the abstract and 2nd paragraph of section 2,
should be more like "where it is possible, important for the use cases
of the protocol, and reasonable to implement and operate such
mechanisms".  The simple "where possible" doesn't seem like much of
a limitation or escape clause to me ... just about anything is
_possible_, but it may not always make sense.

As an example, would we expect MPLS to do anything about
pervasive monitoring or can new MPLS extensions keep moving
through the IETF without heeding to this BCP?

It's also not clear to me whether it's intended to only apply
to protocol behavior "on the wire" or also to logging behaviors,
log formats, and other privacy-defeating factors of implementations.
It specifically says that this is about privacy, and that requires a
lot more than just wire protocol work in order to create.  I think
it would be good to mention these aspects, if this as a BCP will
really be referenced by the community in the future.

-- 
Wes Eddy
MTI Systems

---

From: SM <[email-masked]>
Date: Tue, 03 Dec 2013 21:47:22 -0800

At 09:48 03-12-2013, The IESG wrote:
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-12-31. Exceptionally, comments may be

First of all, I'll thank Mary Barnes for the minutes.

According to the minutes "the [removed] has turned the Internet into a
giant surveillance platform".  Quoting some extracts:

   "This is the lessons of the [removed]'s attempt to collect contact
    lists from the Internet backbone.  If you saw the data, they got
    about ten times as much information from [removed] users than from
    [removed] users, even though I'm sure the ratio of users is the
    reverse.  The reason?  [removed] uses SSL by default; [removed] does
    not."

I don't see anything in draft-farrell-perpass-attack-02 which might 
mitigate the above.

An interesting point from the minutes is:

  "there was no cost to cooperate because your cooperation would be secret.
   Now companies have to assume that it will be public.  There's been huge
   losses of sales, mostly foreign, hardware manufacturers, software, cloud
   providers.  And there is a PR benefit in fighting.  And more companies
   are realizing that."

It looks like it will be embarrassing for companies caught 
collaborating with the adversaries.

The minutes mentioned that:

   "We were safer when our email was at 10,000 ISPs than when it's
    at ten. Fundamentally, it makes it easier for the NSA and others
    to collect.  So anything to disperse targets makes sense."

There was an interesting comment:

    "The other thing is that we need to kind of actually work on
     describing the threat model in a way that would be useful to
     people doing work in the IETF."

And:

   "First of all, I think it's pretty clear that in the past, we
    have considered certain attacks improbable.  I think it is now clear
    that any attack we can imagine is sufficiently probable that we can --
    should consider it."

And:

   "All people want to protect the privacy.  However, there are
    tradeoffs.  One danger I feel is, if we put too strong encryption
    then probably some government would not try to connect Internet
    directly."

Most of the discussion was about encrypting as much as possible.  It 
is difficult to determine whether going for full-blown encryption 
will motivate some government not to allow direct connections to the 
Internet.  At the enterprise level, it is likely that the network 
people will want to prohibit direct connections.  Schools usually 
seek to do that as students are not that studious when they are given 
full access to the Internet.

At 20:45 03-12-2013, Jari Arkko wrote:
>I would like to see this document as a high-level policy we have on 
>dealing with this particular type of vulnerabilities in the 
>Internet. A little bit like RFC 3365 "Danvers Doctrine" was on weak 
>vs. strong security. Please remember that the details and tradeoffs 
>for specific solutions are for our WGs to consider and not spelled 
>out here. The draft does say "where possible" - I do not want to 
>give the impression that our technology can either fully prevent all 
>vulnerabilities or do it in all situations. There are obviously 
>aspects that do not relate to communications security (like access 
>to content by your peer) and there are many practical considerations 
>that may not make it possible to provide additional privacy 
>protection even when we are talking about the communications part. 
>But I do believe we need to consider these vulnerabilities and do our best.

I don't see anything in draft-farrell-perpass-attack-02 which is a 
little bit like the "Danvers Doctrine".  Some of the alternatives are:

   (i)   Consider any attack as sufficiently probably and document it [1].

   (ii)  Have the draft discuss about centralization [2].

Regards,
-sm

1. Credits to the person who suggested that.
2. There was a comment about that.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Dec 2013 13:09:08 +0000

Hi Wes,

> and not just abused as a club against ourselves in the future.

That's a fair comment, and there are at least two ways one could
have gone about documenting the consensus - the "bare" approach
taken in this draft or one where we included many more details
of the threat and mitigations.

The reasons why we took the current approach are:
- we think there's value in documenting the most-significant bit
  of the consensus and I would assert that that can usefully be
  cited, but yes, its not a guidebook for protocol designers
- if we want this to be a useful BCP for say the next decade
  and beyond (thinking about 3365 for example) then the nature
  of the threats and mitigations will change significantly
  in that period (or maybe sooner, depending on what's in
  tomorrow's Guardian:-), so there could be a downside in being
  more specific
- we have folks working to document the threat model separately
  in a way that is aimed to be usable for protocol designers
  and I think that'll cite this and is maybe part of more what
  you were thinking of; similarly, we're looking for folks to
  e.g. help document how to do opportunistic encryption or
  the like as a tool that can be used, but I think both of
  those and other things such as TLS BCPs will be better
  processed separately, from this
- there's sooo much potential to bikeshed on every additional
  bit of text;-)

So, the draft and my responses below are offered in that context.

> - mechanisms that have been (or can be) used as mitigations

That could be done, but as I said above I'd be worried that
it mightn't be that useful, if taken too literally and might
cause some lovely bikeshedding.

>   mitigations is not a concern

Hmm. Trickier. See below.

> _possible_, but it may not always make sense.

Personally, I think its important that we not have this BCP have
a massive get-out-of-jail clause that effectively neuters the
impact we want it to have. And I'd be worried that the kind of
text you're implying might have that effect. (Or did you mean
something else?)

But I do think this is an important discussion for the IETF LC.

> through the IETF without heeding to this BCP?

I don't think this would affect MPLS extensions. (Although I
did ask about that for the last one that went by the IESG:-)
I'd love to see some more security mechanisms defined for MPLS.
It'd be even better if those were likely to be defined.

> log formats, and other privacy-defeating factors of implementations.

Both, IMO. But in many (though not all) cases our specs are
silent about what has to be logged.

> really be referenced by the community in the future.

Thanks for the thoughtful comments,
S.

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 05 Dec 2013 12:26:41 -0500

On 12/4/2013 8:09 AM, Stephen Farrell wrote:
> ...

Ok; thanks for explaining, and I buy your motivations.

> Hmm. Trickier. See below.

I decided I can live without this, assuming there is at least some
clear recognition included that this BCP is intended to inspire the
IETF to think about pervasive monitoring in its protocol designs,
and do at least a few things to improve the state of the art, but
that it is not to be used as a club to force every new RFC to have
some mandatory-to-implement anti-snooping capability.

I have a couple pieces of suggested text helping with this below
that you might consider if you understand my concern.

As a start, I would suggest we be clear that this is not an attack
against the protocols, but rather against the users.  It's not
causing the protocols to break, cease to function, give incorrect
results, etc.  Mitigating it, then depends on assessing for a given
protocol (or deployment), who the users are and what they're using
it for.  SNMP or NTP probably don't need mitigations for pervasive
monitoring, for instance.  So, maybe it would be good to have a
clear statement in Section 2 like:

"The target of pervasive monitoring attacks on the Internet is
not the Internet protocols themselves, but it is the users of
the protocols and the general utility of the Internet itself as
a medium of communications for specific applications that are
"IETF RFCs already contain a mandatory 'Security Considerations'
section intended for discussion of the threats and available
mitigations relevant to the technologies described in the RFC.
As a type of potential attack, if pervasive monitoring is
relevant to a particular protocol, then the threat that it poses,
and the available mitigations are expected to be considered in
new IETF work.  It is possible for certain technologies that
pervasive monitoring may not be viewed as a significant
threat."monitored.  The protocol mitigations that are useful need to
be applied in ways that benefit the user-oriented applications,
and not necessarily other protocols in the network such as those
that may be used for network management, measurements, services
not linked to specific users and groups, control plane functions,
or some machine-to-machine or sensor communications, for instance.
IETF protocols need to assess the threat that pervasive monitoring
poses to their users and usage models on a case-by-case basis, and
implement appropriate mitigations, if any."

> But I do think this is an important discussion for the IETF LC.

Understood, and I agree.  Probably, rather than a "get out of jail"
clause, what I think we should clarify is that this attack could
merely be considered another piece that's part of the security
considerations we already produce to explain on a case-by-case basis
what mitigations are available for the perceived threats of a given
protocol and its envisioned usages.

> It'd be even better if those were likely to be defined.

Good that we agree!  I think the text that I suggested above, or
something like it, would be helpful in making this clear.

> silent about what has to be logged.

Right; and I guess my point is that if we want that to change,
then it should be mentioned here as one type of possible mitigation,
with corresponding tradeoff in the potential log usages by admins
that would need to be made on a case-by-case basis.

I guess my real point is that when the protocols are privacy-preserving,
but the implementations aren't as careful, then it just shifts the
focus of the attack.

> Thanks for the thoughtful comments,

Thanks for writing up this document, so we can record consensus
beyond the simple hum statements.

-- 
Wes Eddy
MTI Systems

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 05 Dec 2013 18:58:12 +0000

Hi Wes,

> Ok; thanks for explaining, and I buy your motivations.

Great.

> results, etc.  

Well, it appears that that's not always the case. For example
the explanation for the petrobas story [1] that's been offered
does seem to involve protocol attacks, as does the quantuminsert
stuff apparently. [2] Though of course, we don't have full
information in any of these cases.

[1]
http://g1.globo.com/fantastico/noticia/2013/09/nsa-documents-show-united-states-spied-brazilian-oil-giant.html
[2]
http://arstechnica.com/tech-policy/2013/11/uk-spies-continue-quantum-insert-attack-via-linkedin-slashdot-pages/

That said, see below...

> Mitigating it, then depends on assessing for a given

Was there a bit garbled here?

> implement appropriate mitigations, if any."

Modulo the likes of [1,2] above I think some text along those
lines could work. But I'd expect more discussion of this
topic during IETF LC so its maybe a bit soon to push out a
-03 with changes. I'll respond again to this mail later on
when/if Jari tells me a new rev would be good or at the end
of IETF LC at latest. (I'll keep a list of mails with text
suggestions to go back to so I don't forget 'em at [3].)
Sound ok?

[3] http://down.dsg.cs.tcd.ie/misc/ppbcp-text-suggestions.txt

Cheers,
S

>>> As an example, would we expect MPLS to do anything about>>> pervasive monitoring or can new MPLS extensions keep moving

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 05 Dec 2013 13:59:23 -0500

Apololgies, I had some cut-and-paste incompetence in the example
text I sent, here's a retry:

monitored.  The protocol mitigations that are useful need to

-- 
Wes Eddy
MTI Systems

---

From: t.p. <[email-masked]>
Date: Fri, 6 Dec 2013 09:31:29 +0000

I oppose publication of this I-D by the IETF.

The point has already been that better defences against monitoring
likely means greater use of encryption and encryption is at times
harmful.  Two examples come immediately to mind.

Not long ago, a capital city was subject to riots which were more
extensive, and went on for longer, than might have been expected.
Afterwards, the police explained that they had lacked the intelligence
that they usually had, that the organisers of the riots had been using
encryption to communicate and that the police had been unable to crack
their messages.  (I understand that the manufacturers of the devices in
question had declined to help the civil power).  And yes, that capital
city is where the IETF will meet next March.  (The probabliity of you
being caught up in a riot then is very small but if you are, recall that
encryption has made it worse).

Secondly, a few days ago, there was a report of the user of a well-known
brand of TV finding that the TV set was monitoring his behaviour, not
just what he watched but anything else that he did with the TV, such as
loading pen drives and viewing pictures, and passing that data back to
the manufacturer.  The report said that the user was Internet aware,
realised that the traffic patterns did not correspond to his usage and
could intercept the traffic and see what was happening (passive
monitoring?  MITM attack?).  I do not know whether the data was in the
clear or whether the encryption was weak enough to be cracked but if it
had been strong, then the user could not have found out what he did; and
the manufacturer might be fobbing us off with a story about gathering
environmental data, such as the rate of wear of the silicon, in order to
reduce the set's contribution to global warming.

One future posited for IPv6 is that every device with power - cars,
washing machines, hair dryers etc - will be Internet connected and so,
potentially, will act as that TV did; and when they use strong
encryption, we will unable to tell what they are doing.

Encryption has its dangers and the IETF should not be encouraging its
widespread adoption.

Tom Petch

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 04, 2013 4:45 AM
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive
Monitoring is an Attack) to Best Current Practice

> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/

It is a short read and important, so please comment. The last call ends
in four weeks and covers holiday time, but we'll deal with this document
on the January 9th telechat in the IESG, so in practice there should be
enough time to comment.

I would like to see this document as a high-level policy we have on
dealing with this particular type of vulnerabilities in the Internet. A
little bit like RFC 3365 "Danvers Doctrine" was on weak vs. strong
security. Please remember that the details and tradeoffs for specific
solutions are for our WGs to consider and not spelled out here. The
draft does say "where possible" - I do not want to give the impression
that our technology can either fully prevent all vulnerabilities or do
it in all situations. There are obviously aspects that do not relate to
communications security (like access to content by your peer) and there
are many practical considerations that may not make it possible to
provide additional privacy protection even when we are talking about the
communications part. But I do believe we need to consider these
vulnerabilities and do our best.

Jari

---

From: Stefan Winter <[email-masked]>
Date: Fri, 06 Dec 2013 11:15:06 +0100

Hi,

> Encryption has its dangers and the IETF should not be encouraging its

Knives have their dangers, and the metal-processing industry should not
be encouraging their widespread adoption.

Funny - that conclusion, which is analogous to yours, doesn't make much
sense to me. Does it to you?

Encryption is a tool - it's neither good nor bad in itself. What you do
with it is the question.

What we have seen in deployed reality is that lack of usage of this tool
by the internet population at large has played into the hands of
adversaries. The idea to put the tool into everybody's hands and make
them *use* it is absolutely a good idea as a countermeasure IMHO.

Especially since the adversaries *are* using it, regardless whether the
good guys do or not. The rioters you mention above did use it - and they
can continue to do so no matter what we decide in the IETF. The TV
manufacturer could have used it - they were simply stupid enough to
forget about it.

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: Stephen Farrell <[email-masked]>
Date: Fri, 06 Dec 2013 11:58:21 +0000

On 12/06/2013 10:15 AM, Stefan Winter wrote:
> The TV manufacturer could have used it - they were simply stupid
> enough to forget about it.

I think in that case, the person who spotted the issue would
also have considered it odd if ciphertext continued to be
emitted after they had clicked the "don't send" button.

S.

---

From: t.p. <[email-masked]>
Date: Fri, 6 Dec 2013 18:49:52 +0000

----- Original Message -----
From: "Stefan Winter" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 06, 2013 10:15 AM

<tp>
The analogy that come to my mind is not knives, but guns.

Many, probably most, countries in the world place quite stringent
restrictions on what their citizens can do in owning or using guns.
Were the UN to produce a convention restricting their use, one country
one vote, I expect that it would be passed with a large majority.  The
evil done by terrorists, criminals, evil empires and so on with guns
outweighs the good.

The technology is neutral; the user of it is evil or not, as the case
may be.

If encryption makes terrorism, crime and so on more likely, then we
could see countries impose restrictions on encryption in the same way as
for guns, and a few years down the line, the role of the IETF in
encouraging the use of strong encryption could be seen as a serious
misjudgment, one that is damaging to the standing of the IETF.

Authentication is fine, in fact I think that it is grossly misunderstood
and underused and does not, as far as I can see, pose a threat;
encryption is a different matter.

Tom Petch

Greetings,

Stefan Winter

---

From: t.p. <[email-masked]>
Date: Fri, 6 Dec 2013 18:57:02 +0000

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Stefan Winter" <[email-masked]>; <[email-masked]>
Sent: Friday, December 06, 2013 11:58 AM
> emitted after they had clicked the "don't send" button.

The person who spotted the issue did click "don't send" and the messages
continued to be sent (according to the reports).  Which is, after all,
exactly what you would expect to see with good security - don't give the
other parties an opportunity to use traffic analysis to determine what
is going on.

Tom Petch

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Dec 2013 19:53:49 +0000

Replying to two of your mails at once...

> misjudgment, one that is damaging to the standing of the IETF.

Wow. The IETF already has a consensus on the use of strong
crytopgraphy. And has had for 17 years. Please read RFC 1984.
If you have read it, I have no clue how you could accept it
and make the above (spurious, but that's beside the point)
argument. If you have read it, but don't accept it, then go
right ahead and write a draft suggesting a replacement that
fits your worldview better. If you have not read it, please
do.

> other parties an opportunity to use traffic analysis to determine what

My point was in response to your saying that that case
demonstrated that ciphertext would prevented the person
from knowing their TV was sending out messages when
they didn't want that. The fact is in that case that
any message ciphertext or plain would demonstrate that
the TV is misbehaving. So your argument falls.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Dec 2013 10:01:10 +1300

I hadn't expected to respond to this Last Call since my
comments have already been incorporated. However, I'd now
like to express my support for publication on the grounds
that...

On 06/12/2013 22:31, t.p. wrote:
> harmful.  

...this is a social, economic and  political issue outside the
IETF's scope. Our ethical obligation as engineers is clear to me:
make the Internet as secure as possible, from all security points
of view including privacy. Actually the recent revelations don't
change a thing except that they have brought a well understood
attack model into public view and underlined that we need to
defend against it.

We don't solve (e.g.) consumer protection issues by allowing the
Internet to trivially breach privacy.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Dec 2013 16:38:41 -0500

On Thu, Dec 5, 2013 at 1:59 PM, Wesley Eddy <[email-masked]> wrote:
> monitored.

In the case of surveillance, the general utility of the Internet for
specific applications is not the target, it's an indirect target in
order to get at the ultimate users. I think your first statement was
correct, without the "and".

> The protocol mitigations that are useful need to

Yes but protocol designs at all layers do need to pay more attention
to modern privacy attacks and may need mitigations in support of
making privacy possible. (Whether protocol implementations do depends
on their context.)

Scott

---

From: Scott Brim <[email-masked]>
Date: Fri, 6 Dec 2013 16:48:44 -0500

Tom: The fundamental task for the IETF is not to force privacy on
everyone, but to make sure that they have the choice. Even where the
IETF thinks something should be mandatory to deploy, that doesn't have
to mean crypto.

Scott

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 6 Dec 2013 18:05:51 -0500

> encryption has made it worse).

We have had riots in Broadwater Farm three out of the last four periods of
Conservative government. Should we ban Conservative governments then?

The 1985 riots predate general UK internet availability and cellular phone
service. So there is an existence proof for the possibility of London riots
before the Internet.

The battle of Cable Street in 1936 was instrumental in suppressing fascism
in the UK and led to the forced abdication of the King.

Moreover, the fatality rate suggests that the risk of being murdered in
London during a riot is actually less than the risk of being murdered in
most US cities under normal circumstances.

In contrast the proponents of mass surveillance were recently responsible
for starting a war that caused the death of over half a million people.

If the US bans all firearms then we can talk about encryption control.
Until that happens they have no credibility on the subject of public order.

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

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 7 Dec 2013 15:42:01 +1100

> likely means greater use of encryption and encryption is at times

…

> Encryption has its dangers and the IETF should not be encouraging its

The strings “encryption” and “encrypt” doesn’t appear in the draft; the closest it comes is the reference to RFC1984, whose name includes “crypt”.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 8 Dec 2013 17:38:32 -0000

I don't believe anything Stephen has written debates a nation state's right to
make a law about surveillance. Due process of law may enable wiretap or
pervasive monitoring. It may require companies operating in a nation to hand
over keys, to not enable encryption as a service, or to deny transmission of
encrypted traffic. 
 
What Stephen has described is how a malicious third party may collect bulk
information about users by parsing a "tap" on a trunk connection within the
Internet. The traffic in this case may be transiting infrastructure under the
control of a company under the influence of a nation state. Furthermore (and
perhaps more significantly) the traffic may be obtained through a "tap" placed
on the infrastructure without the knowledge of the company controlling the
infrastructure. Stephen points out that there is no way to distinguish between a
nation state inspecting traffic between its citizens or that transits the nation
(under due process of law), and traffic that is inspected and collected for
criminal (or less illegal, money-making) purposes.
 
Should we take Tom's reasoning to the extreme we would argue that a nation state
should have the right to disrupt the operation of the Internet within their
borders and that right should be made available to them through interference
with routing protocols. Therefore, we should not allow secure operation of OSPF.
 
Hmmm, maybe governments need to be able to see all on-line bank transactions in
order to spot drug dealers moving money around. So all on-line banking should be
in the clear.
 
It is my belief that all governments have available to them mechanisms through
due process of law to obtain the information that they believe they need. What
Stephen's document is about is preventing snooping/surveillance attacks on
Internet traffic by parties that do not have support of the law.
 
Cheers,
Adrian

From: ietf [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: 06 December 2013 23:06
To: t.p.
Cc: IETF Discussion Mailing List
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive
Monitoring is an Attack) to Best Current Practice

 

The battle of Cable Street in 1936 was instrumental in suppressing fascism in
the UK and led to the forced abdication of the King.
 
Moreover, the fatality rate suggests that the risk of being murdered in London
during a riot is actually less than the risk of being murdered in most US cities
under normal circumstances. 

In contrast the proponents of mass surveillance were recently responsible for
starting a war that caused the death of over half a million people. 
 
If the US bans all firearms then we can talk about encryption control. Until
that happens they have no credibility on the subject of public order.

---

From: Stefan Winter <[email-masked]>
Date: Mon, 09 Dec 2013 08:59:38 +0100

Hi there,

> The analogy that come to my mind is not knives, but guns.

You're trying to drag me with my knives into a gunfight (pun
inevitable). But that won't work: I've chosen the analogy with a bit of
care:

Knives are easily available to anyone, just like encryption.

The distribution of knives can't reasonably be regulated so that they
are only available to few sanctioned bodies; they are simple to
manufacture, "blueprints" if you think you need some can be found
easily, and the raw materials cannot be held away from the public
either; they are just too useful for any sort of purposes.

The same goes for encryption: anyone with a compiler can implement the
publicly available algorithms and manufacture an encrypting/decrypting
device of program himself (for you probably "Weapon of Mass Encryption"
;-) [*] ). In fact, it has happened hundreds of times and nobody raises
an eyebrow.

In both, the product has already proliferated, and it is not possible to
roll back to a state where it hasn't.

Also, both of those have proven to have both too numerous and
unquantifiable good and bad uses, and both of it in scale; there is no
obvious, generally-accepted world-wide agreement that either of the two
can only be used for nefarious purposes.

So, I feel good comparing these two tools.

Contrary to that, your comment tries to drag me into comparing
encryption with a class of tool (yes, it also is one) which fails
comparability to encryption in all the points I made above:

Guns are not easily available to anyone. In absolute terms, they *are*
though; regulation merely raises the bar to get one. I guess if you
really want one, there are plenty of ways getting one illegally in most
countries of the world. Otherwise, the terrorists wouldn't have guns,
would they? This in itself makes your point below a bit moot: if you'd
heavily regulate the use of encryption, it would still keep being
available; and with the bar too high for John Does, its use would become
common only for those who have something to hide.

Guns have not (yet) proliferated; governments try to keep in a state
where this doesn't happen. They do struggle with this in the 3D printer
age now; it will be interesting to see how they can cope with that step
towards proliferation.

Guns have a much harder time proving that they have good uses
outweighing/getting on par with the bad ones. Encryption has proven its
good uses plenty of times; it also has its bad ones, but due its general
applicability to any sort of communication on a much more equal scale
than guns do.

You couldn't even make a point to the contrary: your "argumentation" in
your original mail merely managed to point out two singular uses where
the use of encryption didn't match your personal point of view of being
"good". If the same encryption technology is used by demonstrating
masses in totalitarian countries, which enabled them to lead to a
revolution towards democracy, your opinion on exactly the same use of
technology might have swung around.

So, to sum up: encryption is a general-use technology. Your attempt to
position it as a threat to society is rather futile.

> encryption is a different matter.

Now that is really quite a bit short-sighted.

Authentication without encryption allows every listener (including those
in the perpass sense) to find out who exactly made the statement, with
some strong amount of provability. If at the same time banning
encryption, this exposes everyone's communication to the world, with no
way of provable deniability, and no way of talking in private.

This is like a dream for perpass-style attackers.

With the kind of statements you made in this thread, I can't help but
wonder on whose paycheck you are. I read British Telecom as per your
your mail address (and certainly hope that you are not representing
company opinion), but can't help think it's "5 Eyes" instead.

Greetings,

Stefan Winter

[*] IETFers should really wear T-Shirts stating "I produce Weapons of
Mass Encryption" :-)
-- 
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

---

From: Stefan Winter <[email-masked]>
Date: Mon, 09 Dec 2013 09:02:07 +0100

Hi,

>> misjudgment, one that is damaging to the standing of the IETF.

Uh. At least my mail client indents the above as if it was me making
this ridiculous statement.

Disclaimer: that fine example of misguided thinking above is Tom Petch's
alone.

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 09 Dec 2013 10:08:11 +0100

Hi,

> [*] IETFers should really wear T-Shirts stating "I produce Weapons of

Well... since I actually got off-list comments from people *wanting*
that T-Shirt, here it is:

http://netsecpro.spreadshirt.de/

There's only one product in the shop :-)

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: <[email-masked]>
Date: Mon, 9 Dec 2013 09:15:45 +0000

attempts are made to limit misuse of knives from a social engineering viewpoint.
In the US, the TSA won't let them on planes.
In the UK, the Royal Armoury (oh, the people you can _trust_ with weapons) ran its No To Knives campaign.
http://www.theguardian.com/media/2007/nov/22/digitalmedia.advertising
http://www.royalarmouries.org/projects/ntk
in Scotland:
http://www.noknivesbetterlives.com/
but it's hardly 'spoons are less harmful - eat more soup'.

I can imagine similar social engineering efforts - 'use encryption? what do you have to hide? You're just making it harder to spot the real terrorists' etc.

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: ietf [[email-masked]] On Behalf Of Stefan Winter [[email-masked]]
Sent: 09 December 2013 07:59
To: t.p.; [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

Hi there,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: <[email-masked]>
Date: Mon, 9 Dec 2013 20:21:23 +0000

> Knives are easily available to anyone, just like encryption.

...and just like pervasive monitoring?

So, I feel good comparing knives with pervasive monitoring.

http://blogs.wsj.com/digits/2013/12/09/tech-giants-band-together-for-nsa-reform/
the irony of corporations that are profiting from pervasive monitoring -
that's how Facebook and Google work - complaining
about government pervasive monitoring is not lost on me.

What I don't feel good about is perpass-attack, which is going to
be at best ignored, or wildly misinterpreted and misused by its intended
audience. It's primarily a kneejerk reaction to news events to assuage
the consciences of IETF insiders.

also, do we get drafts through last call by simply now announcing in
the draft that it has been through last call? That does make things
easier. Must start writing 'this RFC' in drafts, which will help that
benighted state come to pass.

Lloyd Wood

---

From: Josh Howlett <[email-masked]>
Date: Mon, 9 Dec 2013 22:22:21 +0000

>about government pervasive monitoring is not lost on me.

And -- irony number two -- no amount of encryption will protect you from
the monitoring by these corporations. And nor, by extension, those they
are obliged (legally or otherwise) to cooperate with.

>audience. It's primarily a kneejerk reaction to news events

+1

(That doesn't necessarily make it a futile exercise, if it also happens to
improves security in ways consistent with the general threat environment,
which I believe it does. But in this specific case that includes
adversaries that render discussion of technical measures largely
irrelevant by virtue of their influence on the marketplace, so...)

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: t.p. <[email-masked]>
Date: Tue, 10 Dec 2013 14:38:06 +0000

<inline tp>

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, December 09, 2013 8:21 PM

http://blogs.wsj.com/digits/2013/12/09/tech-giants-band-together-for-nsa
-reform/
the irony of corporations that are profiting from pervasive monitoring -
that's how Facebook and Google work - complaining
about government pervasive monitoring is not lost on me.

<tp>

And that is another example of the use of encryption that I think
may be abusive.

Increasingly, I find that when I access a website, of some leisure
interest, an https:// tunnel has been set up to Google, Facebook,
Twitter or some such, which makes me think that they are acquiring
personal information about me, information which I cannot see,
perhaps for use in a way I will not approve of.  It is like phishing,
only
different.

And there seems to be no way of stopping it (short of a router ACL to
prevent access to Google).

Tom Petch

</tp>

Lloyd Wood

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Dec 2013 08:20:59 +0100

Hi,

> perhaps for use in a way I will not approve of.  It is like phishing,

The HTTPS tunnel originates from your own machine. You can see what's
going into the tunnel if you want. HTTPS is about securing the
transport, not the endpoints.

> prevent access to Google).

It's well-known that Facebook "Like" buttons and things like that
communicate home before being used for anything. If they'd do it
unencryptedly, they'd still do it. The encryption doesn't change their
desired behaviour, only the way their payload is transported.

By encrypting, at the very least your personal data leaks to Google etc.
alone. (*) If they'd send it unencryptedly, everyone on the IP path,
such as a perpass attacker, *also* learns about your personal data.

So: encryption does something good even in the scenario you describe.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Wed, 11 Dec 2013 08:35:10 +0100

Hi,

> ...and just like pervasive monitoring?

That's a very good thought.

Yes, I believe encrpytion and the ability to pervasively monitor are
both easily available to everyone.

The next step after availability is actual usage, and this is where
things get interesting.

I believe that where encryption is not actually *used*, pervasice
monitoring *will* happen. Or, to state it a bit more in a logic-oriented
way:

Either the use of encryption proliferates, or the use of pervasive
monitoring proliferates.

It is a strict XOR: you can't have both, and you can't have none of the two.

Thinking more in the mathematic direction, I'd even say: it's an XOR in
the fuzzy logic sense: the truth value of the sum of both statements
equals 1; i.e. the more you sacrifice on one side, the more will creep
in on the other side.

As a corollary: if we don't want to enable perpass attakcs, we have to
make sure encryption gets *used* wherever possible.

For the general internet use, this probably means: since a vast majority
of internet users don't know and don't care about security, and will
accept whatever is the default unless it's inconvenient - our job is to
make encryption the default, and make it as convenient as possible. The
convenience may come at the expense of "perfect" security at times; but
it's a WG job to weigh that appropriately.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Dec 2013 12:27:29 +0000

Pervasive Monitoring is an Attack
                   draft-farrell-perpass-attack-02.txt

    This BCP simply records the consensus to design
    protocols so as to mitigate the attack, where possible.

SB> "where possible" has huge implications, since it does not
SB> define where on the scale unnoticeable cheap to leading
SB> in technology and cost the boundary lies.
SB> I hope that you mean "where economically feasible
SB> within the context of the application"

    More limited-scope monitoring to assist with network management that
    is required in order to operate the network or an application is not
    considered pervasive monitoring.

SB> This discussion on the tension between monitoring for good and bad
SB> reasons  focuses on network management in the technical sense.
SB> However there are many legitimate reasons for traffic analysis
SB> and traffic content monitoring that go beyond the basics of
SB> network management.
SB>
SB> Our technologies are used in many environments and we need
SB> to ensure that they are fit for off of those environments.
SB> For example there are many reasons why a business may need
SB> or even be required to monitor, filter and record the content and
SB> the metadata of the traffic they flows through its networks.
SB>
SB> There is also the issue of the tension between privacy and
SB> the big data models that are the economic fuel that enables
SB> many cloud and Internet services to be affordable to many
SB> Internet users.
SB>
SB> I thus think that we need to be very careful with setting
SB> the scope of permitted monitoring enabled by protocols
SB> in such a restricted way.

SB> I think that we need to say something of the form:
SB>
SB> Note that limited-scope monitoring required in order to assist
SB> with network management or that is required in order to operate the
SB> network or an application are not considered pervasive monitoring.
SB> Equally monitoring that the user consents to in order that the
SB> operator may operate the network or provide a service economically
SB> or monitoring in compliance with local regulations should not be
SB> considered an attack.
SB>
  
    There is though a clear potential
    for such limited monitoring mechanisms to be abused as part of
    pervasive monitoring, so this tension needs careful consideration in
    protocol design.  Making networks unmanageable in order to mitigate
    pervasive monitoring would not be an acceptable outcome.

SB> Again I am concerned that network management (unless you have
SB> a far broader view of what NM is than I) is simply too narrow
SB> a scope for permitting monitoring.
  
    But
    equally, ignoring pervasive monitoring in designing network
    management mechanisms would go against the consensus documented in
    this BCP.  An appropriate balance will likely emerge over time as
    real instances of this tension are considered.

SB> My view is that we need to get a much better handle on what
SB> that balance is before we publish this BCP. To do otherwise
SB> is going to stall IETF work and result in an inconsistency
SB> as IDs make the "case law".
SB>
SB> Some text of the following form would also be of use in the draft:
SB>
SB> An protocol defined or modified to mitigate monitoring
SB> MUST take into account the deployment needs and economic
SB> realities of the broad spectrum of operators, who will
SB> deploy the protocol both now and into the foreseeable future.

    It is also important to note that the term "mitigation" is a
    technical term that does not necessarily imply an ability to
    completely prevent or thwart an attack.  As in common English usage,
    this term is used here in the sense of "make less severe, serious, or
    painful."  [OED] In this case, designing IETF protocols to mitigate
    pervasive monitoring will almost certainly not completely prevent
    such from happening, but can significantly increase the cost of such
    monitoring or force what was covert monitoring to be more overt or
    more likely to be detected (possibly later) via other means.

SB> I think that the above is stated backwards. Surely we should state up
SB> front that the goal, as with most security, is to increase the
SB> cost of monitoring to a find a more acceptable point on the
SB> cost-return curve in the light of current technology and ideally
SB> to be able to maintain this as technical capabilities change over time.

- Stewart

---

From: <[email-masked]>
Date: Wed, 11 Dec 2013 12:34:01 +0000

+1

Lloyd Wood

________________________________________
From: ietf [[email-masked]] On Behalf Of Stewart Bryant [[email-masked]]
Sent: 11 December 2013 12:27
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

    But

- Stewart

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 13:26:46 +0000

Hi Stewart,

Thanks for the comments. I do think the main point you
raise is one that warrants discussion and seems similar
to Eliot's but clearer, at least to me, (I still don't
get Eliot's real issue;-)

> SB> in technology and cost the boundary lies.

That's maybe fair. OTOH, "where possible" may be the most
precise we can get without either neutering the BCP or
dragging it into endless ratholes. (But see below.)

> SB> within the context of the application"

I don't think it means exactly that. I think "where
possible" in this context means "considering the other
constraints faced in the design of IETF protocols."
If it helped to add that without enumerating those
other constraints then I think that'd maybe be ok.

> SB> and traffic content monitoring that go beyond the basics of

That's a fair comment, but I've not seen any suggested alternative
that'd not neuter the meaning of the BCP so far, including yours
below.

> SB> considered an attack.

Thanks for the concrete suggestion, but I have a number of
problems with that text:

- Required in order to operate the network is very vague
and could be used to justify almost anything at all. What
would *not* be justifiable with that text? (See my response
to Alissa on that just now, which makes the same point.)

- User consent is a rathole that I think we have to avoid.
Would an EULA then mean that users have consented to pervasive
monitoring? If you read most of those then they generally
have the user give up everything. And how would a protocol
designer ever know if a user had consented to something or
not? I don't think we can include any mention of user
consent in this BCP.

- I don't think we should call out economics in a BCP like
this. All IETF work is constrained by a number of practical
factors, including economics but also performance, fairness,
fate-sharing and loads of other things. We shouldn't be
calling all or any of those out here.

- Local regulations again adds that huge ambiguity when
considering RFC 2804. I really don't think that this BCP
should be used to try to re-do the raven discussion or
cause WGs to have to re-do that over and over. Adding
that phrase would have that detrimental effect.

So again, I do agree that the network management bit is
not perfect, but every alternative so far seems far worse
that the -02 version to me at least. (And others have
expressed that concern as well.)

> SB> a scope for permitting monitoring.

I think any change there would be easy enough if we could
figure out a non-neutering change to the text earlier in
that paragraph.

> SB> as IDs make the "case law".

Mine fwiw is that we should document the consensus that was
overwhelming in the room in YVR and then work out the details
based on real protocol design issues as those arise. I don't
believe that we can or should try to build a theoretical
castle in the sky before documenting the most significant bit
of the consensus.

To give another reason for that - today, we don't have (IMO)
any practical scheme for e2e email security that'd usefully
mitigate pervasive monitoring when a service provider either
colludes, is coerced or hacked. In that particular case, I
don't have much hope we'll solve it soon, but if someone did
come up with a scheme that made a significant difference then
this BCP should be usable for them to argue that the IETF
should be doing work on that when or if we're working on mail
standards.

So its not actually possible for this BCP to fully describe
all the details since we don't have practical solutions in
many of the e2e cases today.

> SB> deploy the protocol both now and into the foreseeable future.

Again I don't think calling out "economic realities" like
that is correct. We shouldn't design our protocols for just
the current business models that people have since those
change over time. Not that long ago, many people could have
argued that no IETF work matched the economic realities and
even today, there are many places where the economic realities
are sufficiently different that such constraints are not
appropriate to include in a BCP like this.

Note - I'm not saying that WGs should ignore economic issues,
but that we should not call them out here.

> SB> to be able to maintain this as technical capabilities change over time.

I don't think about it solely in terms of monetary cost, and nor
I think will a lot of users. Service providers and implementers
do of course, but that cost-return isn't the only consideration
at least not until you take into account reputation costs and
opportunity costs and so on, all of which are pretty vague. And
that's not even mentioning whatever it is that users think
about giving up privacy. So when considering a threat the
ideal (which is generally not possible) is to completely
mitigate that threat, and all we're saying here is to expect
even more imperfection than usual;-) I think we do need to
say that, otherwise we may create the false impression that
we're claim to solve the problem.

Cheers,
S.

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 10:07:14 -0500

Regarding "where possible", since every situation is different, I do
not think the IETF should try to find a balance, or say anything
universal about deployment. There is no position that will work for
everyone.  The IETF should absolutely try to make privacy/security a
_possibility_, and that's why every effort should offer the
_possibility_ of mitigation.  That's as far as we should go.

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Dec 2013 07:13:52 -0800

> I believe encrpytion and the ability to pervasively monitor are both
> easily available to everyone.

not at all.  pervasive monitoring requires ability to be pervasive.  but i
can encyrpt my traffic.

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Dec 2013 07:18:18 -0800

> The IETF should absolutely try to make privacy/security a

how many documents say if you want priavcy use ipsec.  that's been a
real winner for us, eh?  i always leave open the possibility that cash
may fall from the sky.

that we did not design the internet as a *far* more secure place is a
major embarrassment.  clean it up.

randy

---

From: Jari Arkko <[email-masked]>
Date: Wed, 11 Dec 2013 17:40:11 +0200

+1

Although I don't know about the initial design - the world was a different place then. But if we don't make a concerted effort to improve the situation when we get information about problems… 

(And what we do should not be a reaction to specific issues but rather a part of the long term evolution of the Internet. And it does need that evolution.)

Jari

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Dec 2013 07:44:20 -0800

> if we don't make a concerted effort to improve the situation when we
> get information about problems…

the ietf, when we see major problems, we spend our energy picking nits

ask yourself, what have you done in constructive terms to better secure
the internet today?

randy

---

From: Avri Doria <[email-masked]>
Date: Wed, 11 Dec 2013 07:52:01 -0500

Hi,

I have been following this discussion and have little to say till now . I think it is an important BCP that should be published as soon as possible.

I was concerned when the issue of operational needs for monitoring was first brought up, as that often serves as an entry point for surveillance. I think it is as important to consider how we do operational functions to be attack resistant as it any other network service or function.

The draft does not say functionality must be abandoned. It just says we need to work on preventing pervasive surveillance attacks. This should be the case in network management and operations as it is anywhere else.

We should be careful about making unnecessary exceptions and accept that the tussle of  protection and function is ongoing and can only be solved over time as the protocol work proceeds.

Avri Doria

[email-masked] wrote:
>Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt>
>(Pervasive Monitoring is an Attack) to Best Current Practice
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 16:07:35 +0000

Looking at this paragraph and the comments on it, maybe
the thing to do is to make the text talk more about
functions and try avoid tricky terminology.

So how'd a change along these lines be:

OLD:

   considered pervasive monitoring.  There is though a clear potential
   pervasive monitoring would not be an acceptable outcome.  But

NEW:

   Monitoring in itself can be a good thing and need not be part of
   a pervasive monitoring attack. For example, network management
   functions often require monitoring packets or flows, anti-spam
   mechanisms may need to see mail message content and some kinds
   of monitoring can be part of mitigating the pervasive monitoring
   attack, e.g. with Certificate Transparency logs. [RFC6962]
   There is though a clear potential
   for such monitoring mechanisms to be abused as part of
   pervasive monitoring, so this tension needs careful consideration in
   protocol design.  Making networks unmanageable in order to mitigate
   pervasive monitoring would not be an acceptable outcome.  But
   equally, ignoring pervasive monitoring
   would go against the consensus documented in
   this BCP.  An appropriate balance will likely emerge over time as
   real instances of this tension are considered.

Feedback appreciated. Probably better if that's more like "good
direction" or "bad direction" rather than immediate wordsmithing,
e.g. tweaking the examples is probably not the most important
for now.

S.

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 11:15:08 -0500

> real winner for us, eh?  i always leave open the possibility that cash

More context: I said: "Regarding "where possible", since every
situation is different, I do
not think the IETF should try to find a balance, or say anything
universal about deployment."

I didn't mean we should just stop at making privacy possible, I meant
that in writing this document, we shouldn't try to make short
rule-of-thumb memes for what to do when. It's complicated. Trying to
encapsulate it in something as short as "where possible" doesn't work.
When you extend that to "unless that gets in the way of operations"
you open up more cans of worms. I tried to keep what I said above
short, and look where it got me.

Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 11:25:31 -0500

>    real instances of this tension are considered.

Good direction. Just to be clear, the issue is not whether we will
provide tools to mitigate what appears to be an attack. We will, and
we will also design protocols to be resistant to attack. This
paragraph should be about when to use techniques, not what techniques
to incorporate into protocols.

Scott

---

From: Avri Doria <[email-masked]>
Date: Wed, 11 Dec 2013 11:44:09 -0500

Looks like a good language direction to me.

Avri Doria

---

From: Dave Crocker <[email-masked]>
Date: Wed, 11 Dec 2013 09:48:22 -0800

On 12/11/2013 7:18 AM, Randy Bush wrote:
> real winner for us, eh?
...
> major embarrassment.  clean it up.

Sentiments about the history of Internet security efforts, such as the 
above, are prevalent.  They are also quite wrong.

The presumption of statements like the above is that current Internet 
security problems represent the technical community's failure to attend 
to 'security' concerns.

The reality is that there has been an extensive range of very serious 
efforts over many years, including the one cited above.  One can always 
wish for more and maybe even different efforts, but the ones that have 
been pursued were all reasonable and would have been useful, if they had 
gained widespread deployment.

Yet the only two IETF efforts to reach mass-adoption are[1]:

    1) TLS, and only for server authentication and 'link' encryption. 
(That is, not client authentication and not end-to-end, within multi-hop 
applications[2])  Worse, while server authentication is useful to 
mitigate man-in-the-middle attacks, it has not proved very useful at 
improving user evaluation of server context -- that is, whether they 
should trust the content from the server.)

    2) DKIM, with its narrow, domain- and server-oriented authentication.

In both cases, 'mass' adoption really means within the relatively tiny 
community of server operators, rather than amongst the much larger 
end-user community.

It is counter-productive to indulge in mea culpas, like "embarrassment", 
about failures to do things that are beyond the state of the art.  And 
in the case of security a mass scale, we are very clearly in a topic far 
beyond what the 'usable security' world knows how to solve.

That does not mean we can't make the necessary progress, but it means we 
are in a realm of research, not just resolve.

d/

[1] Usually when I cite the poor success rate of IETF security work, 
someone insists it's actually better, and they come up with exactly one 
additional example, which turns out to be marginally qualified at best. 
However none of the successful security mechanisms started in the IETF, 
which is a point we should consider instructive.  If there is one way we 
really should adjust our attitudes, it is about the challenge of gaining 
widespread use.

[2] Protection at the transport layer is fine, but it isn't just email 
that is multi-hop at the application layer, needing meaningful, 
object-based end-to-end protection.  For example, so is the Web, given 
caching and the like...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 13:41:57 -0500

On Wed, Dec 11, 2013 at 12:48 PM, Dave Crocker <[email-masked]> wrote:
> [2] Protection at the transport layer is fine, but it isn't just email that
> is multi-hop at the application layer, needing meaningful, object-based
> end-to-end protection.  For example, so is the Web, given caching and the
> like...

... and we're not just talking about crypto, we're talking about
protocol and system behavior as well.

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 Dec 2013 15:53:21 -0500

Responding to the most tempting target even though it is several
days old...

--On Saturday, December 07, 2013 10:01 +1300 Brian E Carpenter
<[email-masked]> wrote:

> IETF's scope. Our ethical obligation as engineers is clear to
> me: make the Internet as secure as possible, from all security
> points of view including privacy. Actually the recent
> revelations don't change a thing except that they have brought
> a well understood attack model into public view and underlined
> that we need to defend against it.

While I favor the principle, I'm not so sure about the ethical
obligation, especially from the perspective of my background in
political communications and their effects.

Consider the following scenario:

	(1) We conclude that access to the free flow of
	information, including across national boundaries, and
	access to the Internet as a medium for such flows, are
	desirable.   Note that this is implicit in
	frequently-repeated statements such as "The Internet is
	for Everyone".
	
	(2) Some government concludes that, as a matter of
	national security (its definition), it should declare
	the use of encryption illegal [1] and block all Internet
	traffic and connections that involve pervasive
	encryption.

Now, keeping in mind the conclusion in the first statement, the
very long history of transmission and sharing of coded
information in apparently clear-text messages, and that
application of the second statement would essentially disconnect
the population of that country from the Internet if encryption
were pervasive, are you sure that:

	(i) Trying to insist on pervasive encryption is an
	ethical obligation?
	
	(ii) That population, including but not limited to
	whatever subset of it wants to openly discuss or change
	the behavior of the relevant government, is better
	served by pervasive encryption (and hence being cut off
	from the Internet) than being left connected and with
	alternatives that have historically included encoding
	information into seemingly-innocuous message flows?

I want to stress that I'm not arguing for or against pervasive
encryption here.   I'm also a long term advocate of encouraging
countries who want to disconnect to do so, especially when their
doing that would have obvious and severe negative economic or
political consequences.  I just think we should be careful about
starting to base our reasoning and conclusions on perceived
ethical imperatives, especially without sorting through the
possible scenarios consequent of such conclusions.

I also want to suggest a thought experiment as an exercise
before I go back to lurking.  One of the more frequent arguments
for pervasive encryption of traffic passing over the Internet is
to drive up the costs of those who would engage in pervasive
surveillance by forcing them to decrypt everything.  Suppose
instead that everyone adopted the practice of including either
encrypted message components or seemingly-random blocks of text
or strings or seemingly-random words in every message, web
pages, or other protocol transaction while leaving other
portions of those messages, etc., in the clear, taking advantage
of the observation that a really well-encrypted message is, with
the exception of header or envelope information, superficially
indistinguishable from noise.   That would make it harder to
block traffic simply because it was encrypted but would still
require the surveillance agency to attempt to decrypt those
blocks of text (many of which could not be decrypted even with
unlimited resources because they contained no information) to
determine whether they carried messages of interest.  

Of course the use of that approach would not prevent the use of
strong encryption, just as today, if someone thought it
necessary.

With the understanding that these questions are part of that
thought experiment but otherwise purely rhetorical,

-- Would we be more or less secure as a result of that
	sort of practice?
-- Would the Internet be accessible to more or fewer
	people with that approach than with pervasive encryption?
-- Especially noting that some code-breaking techniques
	become easier with larger bodies of crypto-text and that
	content-free noise that is superficially
	indistinguishable from encrypted text may be worst
	nightmare for some other techniques, how would that
	approach compare to pervasive encryption from the
	standpoint of costs to the would-be surveillance agency?

      --john

:-)

[1] There is lots of precedent for conclusions of that type,
including among governments usually considered friendly to
individual freedom.

> 
> We don't solve (e.g.) consumer protection issues by allowing
> the Internet to trivially breach privacy.
> 
>     Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 21:19:00 +0000

I've a question about the relevance of your comment
John:

On 12/11/2013 08:53 PM, John C Klensin wrote:
>  if encryption
> were pervasive

The draft in question does not call for that. It calls
for proper consideration of the pervasive monitoring
attack and work to mitigate that.

Use of encryption for confidentiality will be a relevant
mitigation for various protocols, but to comment as if
this draft called for ubiquitous confidentiality seems
very odd if one has read the draft.

John - can you say what part of the draft caused you to
incorrectly conclude that "pervasive encryption" (whatever
that means) is even being discussed never mind recommended?

Thanks,
S.

---

From: <[email-masked]>
Date: Wed, 11 Dec 2013 21:55:29 +0000

It's not just encryption that is indistinguishable from noise - perfect compression can be, too.

We can drive up monitoring costs in the clear by just encouraging deployment of IPComp
and stream and payload compression. With a really expensive-to-decode and effective
compression algorithm.

At that point, distinguishing cleartext from the encrypted traffic becomes
much harder, as does determining targets to attack. And since compression is entirely
in the clear, it's not subject to munitions embargoes, being prohibited, etc. It's
just more work to handle for an attacker, which is rather the point.

Of course, once you have widespread compression deployed, adding encryption
in is not that hard, no? All you need to do is encrypt the compression dictionary,
not the entire content.

Kolmogorov complexity, here we come.

(As an aside, I've long suspected that it should be possible to make a more efficient
yet completely compatible file gzip with multi-pass building of the most suitable
dictionary before outputting the file. One-pass streaming, even with -9 block size, is
ultimately limiting...)

Lloyd Wood

________________________________________
From: ietf [[email-masked]] On Behalf Of John C Klensin [[email-masked]]
Sent: 11 December 2013 20:53
To: Brian E Carpenter; [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

      --john

:-)

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2013 10:58:47 +1300

> attack and work to mitigate that.

And I intended my comment to mean that. I suspect that
pervasive encryption would be more of a curse than a
blessing; IMHO we need to do a lot more analysis to
determine the appropriate counter-measures. They may well
include pervasive *ability to encrypt* but that is a vastly
different statement from recommending pervasive encryption.
And as the French government has so neatly demonstrated,
pervasive encryption doesn't actually prevent surveillance.

    Brian

---

From: <[email-masked]>
Date: Wed, 11 Dec 2013 22:08:20 +0000

I read the draft as giving de facto control of all IETF output to the security directorate.

Which I would regard as an attack on the IETF...

Lloyd Wood

________________________________________
From: ietf [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: 11 December 2013 21:19
To: John C Klensin; Brian E Carpenter; [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

Thanks,
S.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 12 Dec 2013 02:56:23 +0100

>that means) is even being discussed never mind recommended?

I am not sure what to make of your comments here. Perhaps an example
might help, http://edition.cnn.com/2010/CRIME/12/08/wikileaks.students/

  U.S. agencies have warned some employees that reading the classified
  State Department documents released by WikiLeaks puts them at risk of 
  losing their jobs. But what about students considering jobs with the 
  federal government? Do they jeopardize their chances by reading 
  WikiLeaks?

If surveillance is pervasive, then students must assume someone will
know which sites they visit and assume there will be repercussions. So
they are forced into a constant state of fear where they need to care-
fully consider, say, which headlines on a newspaper website they click.

If your draft is not about removing this fear, then I do not know what
it might be about. If it is, then it would seem to call for "ubiquitous
confidentiality" unless you are making a very fine point.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Dec 2013 15:20:57 +1300

Bjoern,

On 12/12/2013 14:56, Bjoern Hoehrmann wrote:
> it might be about. 

One of the IETF's difficulties in this type of discussion is separating
technology (where we have some claim to say something) from social
(and economic and political) issues where we may have strong opinions
as individuals but where the IETF has nothing to say.

The fear you describe is not part of the technology; it's part of
how society in one country is using the technology.

> If it is, then it would seem to call for "ubiquitous

Indeed it is making a fine point - what it calls for is the
IETF to provide technological mechanisms that allow operators
and users to protect privacy. To what extent those mechanisms
are deployed is not under the IETF's control and will presumably
vary between countries.

   Brian

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 21:28:28 -0500

On Dec 11, 2013 9:21 PM, "Brian E Carpenter" <[email-masked]>
wrote:
> and users to protect privacy.

... and to avoid hampering privacy capabilities that already exist.

Scott

> To what extent those mechanisms

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2013 02:44:27 +0000

> confidentiality" unless you are making a very fine point.

WRT the fear - what Brian said. He put it better than I
would have.

As to the question of "what's it about that's not ubiquitous
confidentiality":

There are many other techniques that will be relevant in the end
I'd say. For example, over time, I'd hope that we end up with
fewer protocols that provide uncontrollable opportunities for
tracking. That will require application protocol design
considerations that don't involve crypto.

Some protocol designers will I would hope require fewer long
term identifiers to be visible to many entities, for example
some values only needed hop-by-hop could change so as not to
be the same end-to-end. I'm thinking of how the X-Forwarded-For
that became the standards track HTTP Forwarded header field
could have been done better had privacy been a serious
requirement. Maybe some hash function would have been a part
of a better solution there, or maybe obfuscation, but
confidentiality would not have been relevant in doing that
work.

For DNS, we've seen a proposal to not send the full QNAME in
all queries as those are sent up towards the root. No crypto,
since it just involves sending less stuff, but a possibly
nice (though not problem-free) mitigation.

Perhaps CGAs will become more popular - those do involve crypto
but no confidentiality.

Speculating - perhaps people will find better ways to manage
networks without recording (bytes from) every packet or flow.
If sampling and statistical methods can meet the requirements
without being so close to pervasive monitoring then that might
make for a privacy-friendly IPFIX profile for example.

Yes, confidentiality provided via crypto will be a part of some
protocol design work. But far from all of it. And for many protocol
designers, if they can easily layer on top of TLS or IPsec then
that'll be the right choice and those protocol designers won't
be doing crypto protocol design. (Thankfully:-)

Certificate Transparency is another potential part of some
mitigations for pervasive monitoring, and while that might be
a user of a confidentiality service, it doesn't provide one.

And so on.

And there will be cases where we've no good mitigations to
offer: I've no idea how one might run DHCP with crypto based
confidentiality, nor even practical e2e email security as
I mentioned before. There'll be loads of protocols where
we just don't have a workable confidentiality service and
we'll live with that.

So yes, we've a wait on our hands before we get perfection.
Please don't hold your breath:-)

And what the 106-email-but-inconclusive "https at ietf.org"
discussion does show up is that there are still some arguments
for making some information available in clear. (I'm not saying
what I think is the right conclusion of that argument.) This
draft doesn't claim to judge the best outcome for that discussion,
it just says that the discussion needs to be given proper (and
not perfunctory) consideration. Its sort of optimistic in that
respect and assumes that if the IETF do properly consider
something then we tend to have a hard time denying e.g. laws
of physics:-) I guess the biggest stick embedded in the draft
is that if some WG demonstrably don't tackle the issue where
some obvious mitigation exists, then that WG should experience
unhappiness.

And even with all that, this draft does not actually call for
any security mechanism to be more-than-MTI, where MTI means
mandatory to implement which has been the IETF's consensus
position on strong security mechanisms for over a decade [1].

So there's no process innovation here and confidentiality is
just one tool in a toolbox that I hope we start filling up
some more. And I figure this BCP can help there to really get
better technical outcomes, and without being at all onerous.
I don't think its quite a no-brainer, but for anyone who's
thought the issues through, it should appear to be a
no-brainer.

Hence my question as to the (ir)relevance of John's comment.

But having said all that, would I personally like it if the
IETF did reach a consensus position that everything possible
MUST be encrypted by default? I probably would. But that's a
separate day's work and is not called for by this draft no
matter how many times people mis-represent the draft as saying
that it does.

Hope that helps,

S.

[1] http://tools.ietf.org/html/rfc3365

---

From: t.p. <[email-masked]>
Date: Thu, 12 Dec 2013 10:23:37 +0000

Jari

I am wondering what the role of the IAB is in this.  Statements of
policy such as this I have seen previously from the IAB, as in the
RFC2804 that has just been referenced.  Whereas the IETF produces the
engineering, such as TLS or IPsec, which is rather different in nature.
Does the IAB approve or disapprove of this?  Why isn't it involved?

And when I look at the IAB website, I am bemused.  The IAB is calling
for papers for a conference on this precise topic, to be held in three
months, by which time you want this I-D to be signed, sealed and
delivered.  So that the IAB can wave it at all participants and say
'Discussion over'?  Or what?

It seems to me that this I-D is an ideal candidate to be presented and
discussed at the conference after which, the IAB can produced a
carefully considered document.

Tom Petch

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 04, 2013 4:45 AM

Jari

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Dec 2013 10:42:36 +0000

On 11/12/2013 15:07, Scott Brim wrote:
> .
I would like to explore this a bit more if I may.

RFC3552 says we must describe

       1.   which attacks are out of scope (and why!)
       2.   which attacks are in-scope
       2.1  and the protocol is susceptible to
       2.2  and the protocol protects against

Now consider the attack that caused us to start this work programme
and think about RFC791. Would that pass security review against
the new hurdles?

I think that the answer to 2.1 is: This protocol is susceptible to a
metadata harvesting attack of the protocol, and moreover it
provides an essential clue in analyzing the payload. It also
provides essential clues in determining the topology of the
network to an observer and thus making other network
elements vulnerable to attack.

So would RFC791 be accepted for publication with its vulnerability
to a pervasive monitoring attack?

- Stewart

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2013 11:21:29 +0000

Stewart,

>       2.2  and the protocol protects against

I'll note that many of the 2119 MUSTs in 3552 aren't
enforced in practice - generally secdir reviews and
the like are much more reasonable and try to figure
out whether or not a draft has done a good enough
job and those reviews do not include mindless checking
of boxes as to whether the MUSTs from 3552 have been
met. I'm sure the same is true for other area reviews
as well - we're all basically a fairly practical bunch
who want work to get done and done well, but we don't
want to build a form-filling bureaucracy. (Well, the
IETF does have a tendency to wander in that direction
but then some of us also push back the other way as
well:-)

Separately, I would argue that this draft takes a
better approach than the overly prescriptive parts of
3552. I think the informative parts of 3552 are much
more useful than the 2119 language parts.

So if you're worried that this BCP will suddenly
mean that the security area starts to jump down
everyone's throat, then I'd say you should relax.
The security area already has plenty of BCP
ammunition in that respect, but luckily doesn't
behave like a set of process-obsessed fools. And
it won't start doing that either is my pretty
confident prediction. This BCP will have no effect
on that at all.

> to a pervasive monitoring attack?

Answers to counterfactual questions won't get us very
far, so please take this with the large pinch of salt
it deserves.

The text of RFC791 would almost certainly be bounced
today for loads of reasons. Things have moved along a
lot in the 32 years since that was published. So my
answer is "no" - it'd not be accepted for publication
for lots of reasons. I don't think its useful to
speculate as to which issue would be the most blocking
in the alternative universe you're envisaging where
we re-invent IP in 2013. (And I hope people who want
to explore that alternative universe start new threads
for that:-)

But I don't see what you're hoping to learn from any
answer to that counterfactual question to be honest.

Cheers,
S.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 12 Dec 2013 13:41:22 +0200

Tom,

The IAB has seen the document and discussed it before we posted it for public review. And had some comments, and some members still do :-) My plan has been to find IETF consensus on this matter, but also have the IAB support the document (in its final form - I'm sure there will be changes). But we are not there yet - lets determine first what the IETF thinks.

As for who is making what kinds of statements - I think the most fundamental difference is between IETF consensus and IAB opinion. The former is obviously a stronger statement.

With regards to the workshop that the IAB is organising, it is an important event, but still one among many. My crystal ball says that we will be discussing impacts and defences related to pervasive monitoring for many years to come. Stephen's document states something which I believe we can and should state today - that pervasive monitoring should be and defences for it should seriously considered when we at the IETF do protocol work. In the coming months and years we'll do a lot of work in parallel in continuing IETF's work to secure various applications and protocols in individual working groups. And we'll for sure learn many things along the way about more general aspects of this problem. For instance, I'm hoping that we'll understand better what opportunistic encryption can and can not do for us. I'm sure the IAB workshop will provide some of those learnings, but at the same time we'll for sure learn yet more in IETF-89 and many other events as well. So the discussion is definitely not over now, not when this document is an RFC, not when the workshop is held, and it may not be ever over. We keep inventing new protocols and applications, for instance.

Jari

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Dec 2013 12:22:07 +0000

> but then some of us also push back the other way as
Sure, and I think I am looking for considered text in
the BCP that ensures, to be able to "do the right thing".
> confident prediction. This BCP will have no effect
Please remember, not so long ago, we had a situation
where routing protocols and updates to existing routing
protocols consistently stalled on concerns about
their security.
> answer to that counterfactual question to be honest.
I am trying to understand the impact of the BCP you propose
on the Routing and Internet layers. In particular whether
its publication will mean that new lower layer protocols
designed in the same "protocol style" as we have used
in the past will continue to be accepted and whether
we will be asked to revise work in progress on the
modification of those protocols to include these issue
in the base protocol.

Remember we reached a point a few years ago where
routing work almost stalled due to concerns about security
of the base routing protocols. Hence my concern about
the  wider consequences of this fairly hasty document
on work in these area.

I constructed an example based on IP as a
lower layer protocol that that everyone is familiar with.
As you will gather I am concerned that without greater
care in the proposed BCP  text we might be unable to
publish anything like it in the  future, or at least not
be able to publish it without considerable argument with
the Security Area.

So, let's go back to the example, or use IPv6 if you prefer,
and explain what technical changes (if any) we would
need to make to it to be able to publish, post the publication
of this BCP, or tell me what an acceptable security
considerations section would look like for the existing packet
design.

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 Dec 2013 12:37:48 +0000

I should add to this response that Dave Crocker
proposed that we pull back on this BCP and
explicitly consider its impact in each of our
working groups.

I think that this is a useful and necessary approach
to the problem in order to ensure that we calmly
address the threat in a measured and proportionate
way and fully understanding the impact on the
Internet, the users of internet technology and
the operation of the IETF of this proposed BCP.

- Stewart

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 12 Dec 2013 07:50:13 -0500

Hi,

The IETF/IAB may wish to update (and expand) the 1989 "ethics" 
document, RFC 1087:

            Ethics and the Internet
            http://tools.ietf.org/html/rfc1087

--
HLS

On 12/12/2013 6:41 AM, Jari Arkko wrote:
> With regards to the workshop that the IAB is organising, it is an important event, but still one among many. My crystal ball says that we will be discussing impacts and defences related to pervasive monitoring for many years to come. Stephen's document states something which I believe we can and should state today - that pervasive monitoring should be and defences for it should seriously considered when we at the IETF do protocol work. In the coming months and years we'll do a lot of work in parallel in continuing IETF's work to secure various applications and protocols in individual working groups. And we'll for sure learn many things along the way about more general aspects of this problem. For instance, I'm hoping that we'll understand better what opportunistic encryption can and can not do for us. I'm sure the IAB workshop will provide some of those learnings, but at the same time we'll for sure learn yet more in IETF-89 and many other events as well. So the discussion is defi
nitely not over now, not when this document is an RFC, not when the workshop is held, and it may not be ever over. We keep inventing new protocols and applications, for instance.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2013 13:11:30 +0000

Hiya,

Snipped various bits...

> the BCP that ensures, to be able to "do the right thing".

I'd argue its not needed on the basis that the draft
just highlights the consensus on this threat but makes
no process innovation. But if you want to suggest text...

> protocols consistently stalled on concerns about

Ok, I get the concern. One could argue that the
better routing security we hope to have soon was
actually a good outcome though:-) But we don't
have to go there.

> considerations section would look like for the existing packet

Honest answer? I don't know. Let's consider source
addresses say. I for one would not try to make a case
that we could do away with those, nor that we know
for sure how to make them less leaky when considered
as identifying meta-data, when operating at the scale
of the Internet. So for me, its similar to the e2e
email security situation, which I understand a lot
better. We do know there are issues but I don't think
we have a practical mitigation that we could stand
over as "the" way to solve either problem.

But other folks know a *lot* more about lower layers
than me, so what'd happen would likely depend on
their analysis of the situation and of what's
practical. And that analysis should be done in
whatever is the relevant WG and should consider
the pervasive monitoring threat. But from what I
know, I don't think this BCP as-written could
justify blocking say some new IPv6 transition
mechanism just because source addresses were leaky
assuming that there really is no good mitigation
for the transition mechanism in question.

If at some point someone does come up with a
good practical way to mitigate the threat for
a protocol that is being developed or updated
then this BCP would call for that mitigation to
be seriously considered. And the usual set of
judgement calls as to whether or not that has
happened would follow. So YMMV as usual.

Again, I don't think there's any process change
here - sometimes we just don't have good mitigations
ready to go, even where we do know a threat exists.
And even when we do, or someone claims we do, have
a good mitigation the usual engineering analysis
and consensus processes are how we figure out what
to do.

Does that help?

S.

PS: "hasty" - are you trying to sound like an Ent? :-)

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 12 Dec 2013 14:57:00 -0500 (EST)

> that we need to defend against it.

My observation is that no technological policy applied with complete
uniformity is ever the ideal solution.  In this case, "making the
Internet as secure as possible" sounds good until one considers the
implication of allowing complete privacy for all possible criminal
activities.

I would say that our ethical obligation as engineers is not to decide
what technological policy is best for society, but rather to inform
and educate the public (in all its facets) as well as possible about
the realities and the possibilities of the technology, so that the
larger society can decide how to handle the unavoidable tradeoffs
between various benefits and costs.

Dale

---

From: Eliot Lear <[email-masked]>
Date: Thu, 12 Dec 2013 21:51:20 +0100

Dale,

> between various benefits and costs.
Without getting into whether I agree or disagree with you on this point,
I think it's a good way to frame at least some of the discussion. 
Thanks for that.

Eliot

---

From: Ted Faber <[email-masked]>
Date: Thu, 12 Dec 2013 13:58:08 -0800

On 12/12/2013 11:57, Dale R. Worley wrote:
> uniformity is ever the ideal solution.  

I may get that tattooed somewhere prominent.  (Well put.)

-- 
Ted Faber
http://www.isi.edu/~faber           PGP:
http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See
http://www.isi.edu/~faber/FAQ.html#SIG

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Dec 2013 18:47:41 -0500

On Thu, Dec 12, 2013 at 3:51 PM, Eliot Lear <[email-masked]> wrote:

> I think it would be a good way for the IETF to frame its work.

We are not going to come to agreement on normative ethics but we should be
able to come to agreement on describing the consequences of technical
decisions and documenting the normative ethical systems that have evolved.

We are not going to come to agreement on issues such as the ideological
commitments underlying bitcoin.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Dec 2013 14:43:06 +1300

> I think it's a good way to frame at least some of the discussion. 

I agree too. On the other hand, the IETF writes technical documents. I think
we decided some years ago to leave the larger society issues, including
education, to ISOC.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Dec 2013 14:54:49 +1300

Tom,

> Does the IAB approve or disapprove of this?  Why isn't it involved?

Like RFC 1984 and RFC 2804, this one is intended to be jointly
issued by the IAB and IESG. I don't see any difference (except for
the artefact that it has to be assigned to one of the streams,
which didn't exist when the two previous RFCs were issued).

> delivered.  

Yes - this is a statment of principle. We can continue to waste time
wordsmithing, or we can just put it out there and save bits.

So that the IAB can wave it at all participants and say
> 'Discussion over'?  Or what?

The discussion of the principle *was* over in Vancouver.
Workshops, and IETF WGs, have to apply the principle to actual
technology.

> carefully considered document.

I hope the workshop will be discussing specific technology, or at
least specific technical guidelines, not wordsmithing the general
principle.

> explicitly consider its impact in each of our

I strongly disagree. That detailed consideration should
follow *after* the general principle has been committed
to the RFC repository. Otherwise we will simply enter a
maze of looping discussions.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Dec 2013 07:06:51 +0100

Hi Brian,

Speaking as a member of the IAB but certainly not for the IAB, I have to
take issue with you on a number of points below:

> which didn't exist when the two previous RFCs were issued).

Sort of.  The current plan of record was for this to be issued as a
BCP.  The document is currently in IETF last call, and then the IESG
will decide what to do with it.  The intent is for the IESG to allow the
IAB to insert an IAB statement if we wish to have one in there.

> wordsmithing, or we can just put it out there and save bits.

Well actually there is confusion about this, which is in part why there
is a debate.  We've already seen one working group chair expecting the
IESG to take actions on documents based on this statement of principle. 
And so some care is therefore required.

> Workshops, and IETF WGs, have to apply the principle to actual

I couldn't disagree more.  The discussion over the matter BEGAN in
Vancouver.  Nobody – NOBODY – should stop a discussion of principles on
this list.  And just to prove the point, you concurred with Dale Worley
at least on what one of those discussion points should be.  And to take
it even further, and this is only Eliot's opinion, I suspect agreement
can be found on the following points:

  * Pervasive surveillance represents an attack on the Internet in as
    much as large amounts of information that is intended to be
    confidential between sets of individuals is in fact gathered and
    aggregated by third parties.
  * Such a broad scale attack can undermine confidence in the
    infrastructure, no matter the intent of those collecting the
    information.
  * This is a hard problem.  The very nature of some of the key
    functions of the Internet allow for pervasive surveillance.  It will
    NOT be technically feasible to eliminate all aspects of pervasive
    surveillance.
  * Those working on protocol development should take seriously the
    threat, and conscientiously weigh all of these considerations as
    they develop technical specifications.

The practical ramifications of that last point is that at the very
least, WGs should show their work in terms of how they weighed the
issues, even if they couldn't solve all of them.

> least specific technical guidelines, not wordsmithing the general

Certainly not wordsmithing, but in fact workshops are often for teasing
out general principleS (there are a few in play).

Eliot

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 Dec 2013 09:18:10 +0000

On 13/12/2013 01:54, Brian E Carpenter wrote:
> The discussion of the principle *was* over in Vancouver. Workshops, 
> and IETF WGs, have to apply the principle to actual technology.
I hope not. The lines were cut in Vancouver, and Jari has on several
occasions told me that this list is the right place to have the
full  discussion.

- Stewart

---

From: <[email-masked]>
Date: Fri, 13 Dec 2013 11:23:59 +0000

A reminder from the Tao:

"One fact that confuses many novices is that the face-to-face WG meetings are much less important in the IETF than they are in most other organizations. Any decision made at a face-to-face meeting must also gain consensus on the WG mailing list. There are numerous examples of important decisions made in WG meetings that are later overturned on the mailing list, often because someone who couldn't attend the meeting pointed out a serious flaw in the logic used to come to the decision. Finally, WG meetings aren't "drafting sessions", as they are in some other standards bodies: in the IETF, drafting is done elsewhere."

In other words, it wasn't over in Vancouver.

I'd like to know if this draft is being ramroaded through, or whether those doing so are novices unaware of how the IETF traditionally operates.

Lloyd Wood

________________________________________
From: ietf [[email-masked]] On Behalf Of Brian E Carpenter [[email-masked]]
Sent: 13 December 2013 01:54
To: [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

[..]

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Dec 2013 13:34:03 +0100

An update.

I wrote:

> Well actually there is confusion about this, which is in part why
> there is a debate.  We've already seen one working group chair
> expecting the IESG to take actions on documents based on this
> statement of principle.  And so some care is therefore required.

The group I had in mind was HTTPBIS.

Here is a snipit from a message from Mark Nottingham who is chair of the
HTTPBIS working group today:

> The wild card in all of this is draft-farrell-perpass-attack. If that document gains IETF consensus, we'll need to demonstrate that we've at least considered pervasive monitoring as a threat, and can explain why we have taken the approach we have.

In my opinion, that is PRECISELY what needs to happen.  WGs should "show
their work" that they have conscientiously considered the matter of
pervasive monitoring.  A more generalized form of the above text in the
document would be very helpful.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Dec 2013 13:04:31 +0000

Hi Eliot,

On 12/13/2013 12:34 PM, Eliot Lear wrote:
> Here is a snipit from a message from Mark Nottingham who is chair of
> the HTTPBIS working group today:
> 
>> The wild card in all of this is draft-farrell-perpass-attack. If
>> that document gains IETF consensus, we'll need to demonstrate that
>> we've at least considered pervasive monitoring as a threat, and can
>> explain why we have taken the approach we have.
> 
> In my opinion, that is PRECISELY what needs to happen.  WGs should
> "show their work" that they have conscientiously considered the
> matter of pervasive monitoring.  A more generalized form of the above
> text in the document would be very helpful.

I've no problem with that, since I agree Mark's mail captures
what we do want to happen as a result of this BCP. (I also
thought his first mail did, but whatever.)

Anyway, how's this for a suggestion, say placed somewhere near
the end of section 2:

   Working groups and other sources of IETF specifications
   need to be able to describe how they have considered
   pervasive monitoring, and if the attack is relevant to
   their work, to be able to justify related design
   decisions.

   This does not mean that a new "pervasive monitoring
   considerations" is required in Internet-drafts or
   other documentation - it simply means that, if asked,
   there needs to be a good answer to the question "is
   pervasive monitoring relevant to this work and if so
   how has it been addressed?"

I don't think we want to force everyone to write up why
pervasive monitoring is or isn't relevant to their work
but getting a good answer if the question is asked should
be the expectation. That could be in meeting minutes, mail
discussions or in drafts or writeups if that's what a WG
want to do. In other cases it'll be clear that the attack
just isn't relevant at all and the question shouldn't even
be asked, e.g. for many codepoint allocations.

I'd be happy to see better suggested wording as well,
Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Dec 2013 14:13:25 +0100

Stephen,

>    how has it been addressed?"

Thank you, that is precisely the sort of text I was looking for.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 13 Dec 2013 13:35:17 +0000

> Thank you, that is precisely the sort of text I was looking for.

Cool. Added to my to-do list. [1]

Be interested in knowing if you're also ok with the earlier
suggested change? [2] I think that matches well with adding
the above as well.

S.

[1] http://down.dsg.cs.tcd.ie/misc/ppbcp-text-suggestions.txt
[2]    http://www.ietf.org/mail-archive/web/ietf/current/msg84888.html

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 Dec 2013 08:07:56 -0600

On 12/12/13 7:54 PM, Brian E Carpenter wrote:

> issued by the IAB and IESG.

No. 1984 and 2804 were Informational. This is targeted as a BCP. It will 
be a product of the IETF, not the IAB or IESG. It will be a consensus 
document of the IETF. As 2026 says:

    While it is recognized that entities such as the IAB and IESG are
    composed of individuals who may participate, as individuals, in the
    technical work of the IETF, it is also recognized that the entities
    themselves have an existence as leaders in the community.  As leaders
    in the Internet technical community, these entities should have an
    outlet to propose ideas to stimulate work in a particular area, to
    raise the community's sensitivity to a certain issue, to make a
    statement of architectural principle, or to communicate their
    thoughts on other matters.  The BCP subseries creates a smoothly
    structured way for these management entities to insert proposals into
    the consensus-building machinery of the IETF while gauging the
    community's view of that issue.

Obviously (given the document editors), IESG and IAB members were 
interested in "inserting this proposal into the consensus-building 
machinery of the IETF". But it is, in the end, going to be a product of 
the IETF.

As Jari said, the IAB may explicitly endorse this document, and I think 
it would be wonderful if they would.

> I don't see any difference (except for

Which is part of the reason for doing this as a BCP. The IAB gets to 
issue its statements as Informational documents in its own stream. The 
IESG manages the IETF stream and publishes consensus documents of the 
IETF. That's nicely clarified in 5741, so doing this as a BCP is the 
most appropriate. And being the consensus of the IETF will (hopefully) 
be a stronger statement than "statements from on high."

> Workshops, and IETF WGs, have to apply the principle to actual

See other messages. This is just rubbish. The discussion in Vancouver 
(especially when one contrasts the IAB plenary from what was said in the 
perpass BOF) made it clear that there was still some work to do 
clarifying the bounds of the principle.

That said, I do agree that this document is about the general principle, 
not the details of how it applies to particular technology. We should 
get the document clear that we (the IETF) intend to take seriously the 
security threat of pervasive monitoring of data, a threat that we didn't 
take as seriously before, and that we will attempt to mitigate that 
threat in our protocols, where it is possible *and* sensible. I think 
the current rev of the document is darn close (if not already there) on 
the general principle, though I'm fine with finding the words to make 
the "possible and sensible" part agreeable to folks. But we don't want 
to mush the document up so much that it becomes "whenever we feel like 
it". The principle has limits, and we should make sure we express that 
fact clearly, but (I think) we absolutely do want to say that we have a 
general hole to plug in many protocols, one that we didn't think was as 
likely to be exploited as it turns out to be. And I think we want to say 
that as concisely and generally as we are able to.

> least specific technical guidelines, not wordsmithing the general

Yep.

> maze of looping discussions.

Brian said it better than I could. I completely agree.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Eliot Lear <[email-masked]>
Date: Fri, 13 Dec 2013 15:13:49 +0100

Stephen,

> suggested change? [2] I think that matches well with adding

I *did* state that I wasn't married even to my own text, and the change
you reference in [2] is definitely in the right direction.  To be clear,
there are many reasons why it is helpful to have data in the clear, not
just monitoring.  A good example is network caching (be it DNS or HTTP
or whatever).  I don't think you need to go into all of these examples
so long as we amongst ourselves understand that we're not outlawing this
sort of thing that people need to do to scale or preserve bandwidth.  
On that basis I can live with [2], but if the IESG wants to wordsmith
it, that's okay with me as well. I have no particular objection to
Stewart's and Alissa's versions either, although I understand that you
have concerns about that text.

Eliot

---

From: Tim Bray <[email-masked]>
Date: Fri, 13 Dec 2013 11:14:51 -0800

Just for the record: I fully support advancing a future version of
draft-farrell-perpass-attack to BCP, noting that there have been some
useful improvements to the current draft proposed in this discussion.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Dec 2013 08:19:07 +1300

> IAB to insert an IAB statement if we wish to have one in there.

And the difference of principle, apart from the process artefact, is what?
The document itself says "This document was initiated by both the IESG and IAB,
but it is published as an IETF-stream consensus document,..."

> And so some care is therefore required.

Of course.

> this list.  

No, and we have plenty of evidence in the discussion that we're aiming
at a rough consensus, not a consensus. IMHO that's exactly why we
should settle on a simple, bare-bones statement of general principle.
Otherwise, we'll be wordsmithing while Rome burns.

> And just to prove the point, you concurred with Dale Worley

Agreed. Is that incompatible with draft-farrell-perpass-attack-02?

> out general principleS (there are a few in play).

All the more reason to get the over-arching simple statement of principle
done ASAP. If I have any criticism of draft-farrell-perpass-attack-02,
it's that it's too long. But it isn't worth the effort of making it
shorter.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Dec 2013 08:25:04 +1300

Regards
On 14/12/2013 03:07, Pete Resnick wrote:
> be a product of the IETF, not the IAB or IESG. 

True, but as the document observes we have moved the goalposts by
inventing the streams.

> It will be a consensus

Well yes, I have to admit that, but if this doesn't sound too facile,
there was pretty clear consensus in Vancouver about the principle
of the principle. As with 1984 and 2804, there is work to do in
getting the words right.

   Brian

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 13 Dec 2013 16:13:28 -0600

> document would be very helpful.

Eliot, thanks for putting the thought into these words.

I've run into people expressing concerns about whether publishing 
draft-farrell-perpass-attack will obstruct documents that are currently 
in working groups.

My answer would be that whether working groups might be asked to "show 
their work" has much more to do with our increased awareness of the 
practice of pervasive monitoring than whether, and in what form, this 
document in Last Call is published.

Anyone with an e-mail account, Jabber ID or microphone can ask "but what 
about pervasive monitoring?" and no BCP is required.

draft-farrell-perpass-attack is only a short-hand answer to use, if 
someone answers that question with another question, like "why should we 
be worried about pervasive monitoring?" Reality trumps formalism.

IMO.

Spencer, speaking without a hat, or even a bandana ...

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Dec 2013 14:23:25 +0200

> document would be very helpful.

Yes - this is what I had in mind as well. Some text about this would be useful in my opinion, too.

>   how has it been addressed?"

This would work for me.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Dec 2013 14:24:47 +0200

> That said, I do agree that this document is about the general principle, not the details of how it applies to particular technology. We should get the document clear that we (the IETF) intend to take seriously the security threat of pervasive monitoring of data, a threat that we didn't take as seriously before, and that we will attempt to mitigate that threat in our protocols, where it is possible *and* sensible. I think the current rev of the document is darn close (if not already there) on the general principle, though I'm fine with finding the words to make the "possible and sensible" part agreeable to folks. 

+1

Jari

---

From: Jari Arkko <[email-masked]>
Date: Sat, 14 Dec 2013 14:14:47 +0200

>> 
> I hope not. The lines were cut in Vancouver, and 

I can confirm this. Indeed, this is just the usual IETF process. We discuss something in meetings, we confirm on the mailing list, we write detailed drafts and debate text.

Hopefully the IESG and IAB can support the end result, but the draft should be IETF's (rough) consensus opinion. As always*.

Jari

*) Well, we can of course publish, e.g., IAB RFCs (which are not necessarily IETF consensus opinions) and have done so in the past. I'm sure we'll see a stream of documents from the IAB on this and other topics in the future. As well. But IETF's opinions are also important, and obviously carry even larger weight. And obviously much of the work on the actual technical changes and new protocols is IETF work (UTA WG, HTTPBIS WG, …)

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 13:52:20 +0000

Hiya,

For the record...

> Thank you, that is precisely the sort of text I was looking for.

I just has a chat with Stewart Bryant about these changes
and he suggested one further tweak to the above. His concern
was that we shouldn't e.g. jump on the first minor new spec
tweak to come out of some WG and insist that the WG go back
and fix years of earlier work to be better at dealing with
the pervasive monitoring attack, if that spec is just say
defining some new TLV or mail header field or something
and doesn't have anything to do with the attack really.

So that'd be something like:

    Working groups and other sources of IETF specifications
    need to be able to describe how they have considered
    pervasive monitoring, and if the attack is relevant to
    the work to be published, to be able to justify related
    design decisions.

The change is s/their work/the work to be published/
which seems like a good change to me so I'll incorporate
that.

The intent here is not to hand out a get-out-of-jail card
but rather to encourage us to ask the questions about
pervasive monitoring at the appropriate times and not
have it as a big stick that's used to beat up every
innocent little Internet-draft:-)

Cheers,
S.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Dec 2013 09:53:37 -0500

Given the extensive discussion and ongoing document changes, and the upcoming holiday period, I have extended the last call period to January 17th, 2014. The document is on IESG telechat agenda for January 23rd, 2014.

Jari

---

From: Scott Brim <[email-masked]>
Date: Mon, 16 Dec 2013 12:35:22 -0500

>>   how has it been addressed?"

In that first paragraph, I would prefer to say "privacy" rather than
"pervasive monitoring". Vulnerability to pervasive monitoring is just
one way in which privacy problems show themselves. It shouldn't be the
only angle from which the problems are viewed.

Scott

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 Dec 2013 12:51:15 -0500

>>>>> "Scott" == Scott Brim <[email-masked]> writes:

    Scott> In that first paragraph, I would prefer to say "privacy"
    Scott> rather than "pervasive monitoring". Vulnerability to
    Scott> pervasive monitoring is just one way in which privacy
    Scott> problems show themselves. It shouldn't be the only angle from
    Scott> which the problems are viewed.

Yes, but I don't think a general privacy requirement is appropriate for
this document.
Here, we're trying to document a consensus that we want to look at
specific attacks when people monitor at a bunch of points, combine data,
etc.
That's more specific than privacy, and that specific question is one I
want WGs to answer.

---

From: Scott Brim <[email-masked]>
Date: Mon, 16 Dec 2013 14:09:27 -0500

> That's more specific than privacy, and that specific question is one I

Right. There are two issues:

  - What should be in this document (about pervasive monitoring)

  - What would we like WGs to consider?

I believe we need to keep it simple for WGs, and give them just one
clear, essential, question to consider. A general privacy question is
not appropriate for this document, but it is appropriate for what we
ask WGs to think about.

This document could say "WGs should consider pervasive monitoring".
That's fine. When it comes to adding to WG guidelines, we should ask a
more general question.

Thanks ... Scott

---

From: Jari Arkko <[email-masked]>
Date: Mon, 16 Dec 2013 16:41:17 -0500

I think Sam is right that this document is about calling out specific threats. 

(If you really want a text change, using the phrase "privacy issues including pervasive monitoring" might work.)

Jari

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Dec 2013 13:33:55 -0500

> (If you really want a text change, using the phrase "privacy issues including pervasive monitoring" might work.)

I don't want a change in this document ... but the thread was going
beyond this doc, into what we will ask WGs to do (I'm pretty sure WG
guidelines should be separate.)  If you want one phrase both here and
in WG guidelines. the one you came up with is quite good.

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Dec 2013 18:27:37 -0800

Seriously late to the party here, sorry...

Is there any chance of having a look at an -03, or maybe a proposed diff to
-02 given the discussion so far?  I don't want to comment on old resolved
stuff.

-MSK

On Tue, Dec 3, 2013 at 9:48 AM, The IESG <[email-masked]> wrote:

> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>    The IETF has consensus that pervasive monitoring is a technical
>    attack that should be mitigated in the design of IETF protocols,
>    where possible.
>
>
>
>
> The file can be obtained via
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Dec 2013 02:54:34 +0000

Worked on it tonight, need to check various bits but it'll
be out Friday/Sat.

S

---

From: John C Klensin <[email-masked]>
Date: Tue, 31 Dec 2013 15:48:28 -0500

Hi.
As I indicated in my earlier note, I've been extremely reluctant
to be drawn into this very extensive discussion.  As a result,
I've waited until the last day of the LC period to post this
although most of it was written shortly after receiving your
note on the 11th (I have reviewed -03 to be sure that anything
that changed after my earlier comments has been appropriately
reflected(.  The reason for my reluctance is rooted in a matter
of principle that I believe many of the people who have
commented do not share and I don't actually expect to change
anyone's mind (especially yours).  So I am really not expecting
a response to this note -- I just want it on the record that the
likely decisions do not reflect anything significantly better
than rough consensus.

That principle is that I do not believe the IETF should be
making statements supporting any particular religion or set of
religious principles or, as we might say on this side of the
pond, expressing strong support for motherhood and apple pie.
Statements of general concern are ok, but apparent commitments
to action without specifics seem to me to be ill-advised.  To
me, your document, and much of the discussion, reflects the
reason why that principle is important: No matter what
assurances are made to the contrary, we've seen example after
example, general guideline after general guideline, turned into
rigid rules during or after Last Call on particular documents
because some AD decides that a document that doesn't match his
(usually -- I think we've yet to have a really abusive,
testosterone-poisoned, woman AD) ideas of how things should work
and should therefore be blocked until the authors or WG either
conform to whatever "requirement" supports his conclusion or
produce an overwhelming proof that should not be necessary.  

I think much of that case had been made by others and was
writing my note in that context (see below).  But maybe not.

So, at the risk of repeating something others have said, I don't
want to see a Last Call (or, worse, post-Last Call) debate about
whether the authors of a document that isn't seen to be secure
enough against persuasive surveillance has done everything that
might be possible to mitigate that risk.   I'm in favor of
mitigation being considered an important consideration, just as
I'm in favor of privacy considerations more generally being
considered important considerations.  But I'm also in favor of
congestion control, operational reasonableness, security
considerations that don't directly relate to privacy including
strong authentication when it is warranted,
internationalization, and a slew of other things that I think we
should be considering when protocols are adopted... and
considered without the impediment of someone saying "well, the
IETF adopted a formal statement that says 'Particular issue XYZ
should be mitigated where possible' so that consideration should
dominate the others."

My problem with going in that direction interacts with your
draft in many ways even though I'm in agreement about the
high-level issue.  As a description of an issue, I think it is
fine.  When you describe and rely on the consensus reached at
IETF 88, I start having objections because I think the questions
were stated in a way (and context) that made disagreement with
them, or examination of the implications and details, nearly
impossible.

To take an example I hope is not taken as a proposal, the
security of SMTP against in-transit interception and monitoring
of messages could a considerably improved by eliminating
relaying  (i.e., the application-level store and forward design
of the protocol).  That would have a number of profoundly bad
effects, at least IMO, but it would enable some rather simple
methods of mitigating the threat that are of arguable or complex
utility if relaying is permitted.  If the Apps ADs ever get
around to getting back to me about a months-old request to
discuss practical methods of moving RFCs 5321 and 5322 forward
to Internet Standard, I don't think it is reasonable to
legitimize an attempt to impose a requirement that starts with
"RFCnnnn says that monitoring threats should be mitigated where
possible, so we have to return to first principles and debate
whether SMTP should have relaying" when, without such a
statement, we'd be able to say "widely deployed, useful, and
working that way for a few decades, we just don't need to have
that discussion about the base protocols".

>From that point of view, when you say "Those developing IETF
specifications need to be able to describe..." [Section 2,
paragraph 4], I get the chills because, despite the mitigating
(sic) second sentence, the third, and the subjectiveness of "a
good answer", allows someone with the inclination to block
almost any application-layer protocol until it is encumbered
sufficiently with privacy decorations to make it unattractive
and unlikely to be adopted in practice.  I would like the 5th
paragraph of Section 2, except that I don't look forward to the
pain I believe this document is likely to cause as that
"appropriate balance" emerges and is visited and re-visited.

Now to put my earlier note and your questions about it and its
relevance in context...

> very odd if one has read the draft.

Oh, I had read the draft, and read the newer version this week.
What I tried to do was to think about making the broad and
general statements in the draft actionable and what that would
mean.  Remembering that I work at the application layer where
almost all data that users might consider sensitive occurs
directly rather than by side-effect, our toolkit is rather
limited.    At least at the application level, if there are ways
with most protocols to significantly mitigate pervasive
surveillance that do not replace it with ubiquitous
confidentiality (or with pervasive encryption, which is what I
actually said) and that fall within the scope of IETF protocols,
I don't know what they might be.    

Actually, I do, but I think the IETF would find them
unpalatable, and that brings me back to my concern about this
document and its apparent attempt (whether you intended it or
not) to move mitigation of pervasive surveillance to the front
of the tradeoff line.  For example, effective surveillance of
traffic content by monitoring of Internet links would become
considerably more difficult if we (pervasively) went back to
routing at the packet (or datagram) level and optimized our
routing algorithms to prefer diverse paths within a stream or
flow.  At least as I understand it, that would largely eliminate
the use of MPLS and would slow things down overall unless ISPs
started engineering their networks for more path diversity
between any two endpoints (presumably increasing costs for the
amount of traffic handled).   But it would make interception of
a single flow for surveillance purposes a lot more unpleasant
and costly for the monitoring body without requiring encryption.
There are other examples but, as far as I know, they are equally
unattractive... unless frustrating pervasive surveillance
becomes out primary objective (and, as you point out in the last
paragraph of Section 2, that of others).  

> that means) is even being discussed never mind recommended?

I hope that the above responds to that question, whether we
agree about the conclusions or not.

best regards and best wishes for the new year,
   john

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 31 Dec 2013 23:45:18 +0100

>I've waited until the last day of the LC period to post this

The Last Call period has been extended to January 17th, as per
https://www.ietf.org/mail-archive/web/ietf/current/msg84997.html
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 31 Dec 2013 16:23:25 -0800

On 12/31/2013 12:48 PM, John C Klensin wrote:
> might be possible to mitigate that risk.

As always, folks should take special note, when John and I agree on 
something.  (Although in this realm of discussion, we usually do.)

In this case, I raised similar concerns some time ago:

     http://www.ietf.org/mail-archive/web/ietf/current/msg84897.html

where the basic message is:

      We should not approve an IETF policy statement
     until we have a good idea of the way we will use it.

The current draft does not come close to satisfying that requirement. 
In fact from what I've seen, the community has been quite diligent at 
avoiding all discussion of practicalities.

A document like this draft is a good idea.  But it can't reasonably be a 
Best Current Practices until the community has some idea of what the 
practices will (and should) be.

Until then, publishing this document is merely an emotional exercise 
that is frankly certain to cause more confusion than insight.

d/

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 1 Jan 2014 02:35:49 +0100

> avoiding all discussion of practicalities.

I support that, and believe that is what the majority wanted, a
solution of guidance of future practices not just definitions,
suggestions or declarations.

> practices will (and should) be.

It is not a good idea because its aim is not clear, is it a BCP or is
it a declaration and suggestions. It should make things clear how the
community, the WGs and IESG will use this document, or if they will
not use it at all, just for publishing.

> that is frankly certain to cause more confusion than insight.

I agree totaly, but I think it does not cause confusion for the IESG,
but confusion to WGs.

AB

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Jan 2014 00:28:47 -0500

--On Tuesday, December 31, 2013 16:23 -0800 Dave Crocker
<[email-masked]> wrote:

>> So, at the risk of repeating something others have said, I
>> don't want to see a Last Call (or, worse, post-Last Call)
>> debate about whether the authors of a document that isn't
>> seen to be secure enough against persuasive surveillance has
>> done everything that might be possible to mitigate that risk.
> 
> 
> As always, folks should take special note, when John and I
> agree on something.  (Although in this realm of discussion, we
> usually do.)
> 

And, indeed, I was aware of that message, which appeared a few
hours before I sent mine out, more or less in response to yours
and Brian's together.  Comparison of your notes of the 11th and
yesterday to mine of the 11th and yesterday indicates to me that
we are thinking about the key issues a little differently, but
reaching the same conclusion about both those issues and overall.

   john

s

---

From: Melinda Shore <[email-masked]>
Date: Tue, 31 Dec 2013 20:38:26 -0900

>     until we have a good idea of the way we will use it.

I think this is a critical point and I agree quite strongly
with it.  I've mostly been baffled by the IETF response to
revelations about internet eavesdropping, to be honest,
and it's struck me that work on some of the problems that
need to be solved to provide better privacy guarantees (for
example, fixing PKI and providing better keying) have been
pushed to a back burner in a scramble to make grandiose
pronouncements.  It's not that draft-farrell is a bad
document on its own merits, it's just that I cannot for
the life of me understand what it specifically means for
work moving through the IETF process.

Melinda

---

From: <[email-masked]>
Date: Wed, 1 Jan 2014 06:08:26 +0000

what it means for work moving through the IETF process
is that any work becomes subject to security veto.

if security types don't like your work - tough. it's
going nowhere. draft-farrell really widens that scope.
and this is going to mean arguments about
much more than the tradeoffs of using MD5.

for a self-described technical organisation that
does not make policy pronouncements (which is
itself a very political position, but never mind)
this draft is awfully political.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Melinda Shore [[email-masked]]
Sent: 01 January 2014 05:38
To: [email-masked]
Subject: Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

Melinda