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

From: Stephen Kent <[email-masked]>
Date: Sun, 15 Dec 2013 15:31:04 -0500

Folks,

I've been unsubscribed from this list for a while because of mail 
filtering problems, which delayed my successful submission of these 
comments. I'll be reviewing the archives to see if there are messages to 
which I should reply, as part of this thread.

----

I have several concerns about this I-D 
(draft-farrell-perpass-attack-02.txt), as currently written. I do not 
support publication of the document in its current form.

I think this document should include a clear description of what the 
IETF considers to be "pervasive monitoring" (PM) and how it differs form 
the informal security model we have (often implicitly) used for many 
years. Even the term "pervasive" needs to be clarified here, as there 
are two definitions one finds via a quick search:

Merriam-Webster: "existing in or spreading through every part of something"

     Oxford Dictionaries: "... spreading widely throughout an area .."

If we mean to imply the former definition, we leave ourselves open to 
criticism by those who will argue that the monitoring of which we have 
been made aware is not literally through every part of the Internet. The 
second definition seems more appropriate, i.e., the sense of widespread 
monitoring.

For many years the IETF security community has used an attack model that 
envisions an adversary who can engage in passive and active wiretapping 
at any point along a communication path. We commonly also attribute the 
ability to engage in MiTM attacks to such an adversary. Thus we have 
long believed that plaintext communications are vulnerable to passive 
wiretapping along a communication path if the content is not protected 
via encryption. We also have noted that, for staged delivery 
applications, e.g., mail, content is vulnerable to disclosure and 
modification in storage, especially en route.In response to this model 
we have developed a set of security protocols, (e.g., IPsec, TLS, DTLS, 
S/MIME, SSH, etc.) that can be used to protect transmitted content 
against passive wiretapping, based on use of encryption. These protocols 
also usually incorporate data integrity and authentication mechanisms, 
and, where appropriate, anti-replay mechanisms, to address MiTM attacks. 
Thus we have offered users and system designers a set of tools that 
address the adversarial capabilities based on our model.

When pervasive monitoring is effected via passive wiretapping, or a mix 
of active and passive wiretapping (e.g., using packet injection attacks) 
it is not a new class of attack. It is precisely what we have long 
considered when designing security protocols. Thus I believe this 
document should include comments of the sort noted above, to help 
establish a context for this declaration about "pervasive monitoring".

Having established this context, the next task is to explain why 
pervasive monitoring is significantly different from our long-standing 
model. The extent of such monitoring seems much bigger in scope than 
folks may have imagined, given that intelligence services of numerous 
countries have been identified as carrying on such monitoring. I think 
this document needs to explain, in a technical context, why what 
pervasive monitoring is qualitatively different, and thus merits this 
declaration. We ought not lead readers to believe that we have not 
tended to consider passive and active wiretapping as likely attacks in 
the past.

Some of the reported forms of pervasive monitoring may have involved the 
cooperation of or subversion of an ISP or a telecom provider. This is 
not a qualitatively different form of attack from the generic passive 
wiretapping that out informal security model has always assumed. If we 
had articulated a threat model, in which we discuss adversaries, 
motivations and capabilities, we could either cite it here or cite the 
need to revise it based on recent revelations. Unfortunately, I don't 
recall the IETF having ever published such a document :-).  Anyway, here 
too it is important that readers be told that this way of effecting a 
passive wiretapping attack is not new, relative to the attack model we 
adopted long ago.

Some of the reported forms of pervasive monitoring have involved the 
cooperation of or subversion of application service providers. If 
attacks take place at a point after which IETF protocols terminate, then 
it seems to be largely outside of our purview as a protocol-focused 
standards organization. For example, if I access e-mail via a _web_ 
_interface_ at an MSP, IETF security standards largely do not seem to 
apply to vulnerabilities associated with storage of the mail at the MSP; 
my mail can't be protected e-t-e because I'm not using S/MIME to read 
the mail. I can use TLS to protect the HTTPS session via which I access 
messages, and we can recommend that TLS be used with SMTP to deliver the 
mail to the MSP, but that seems to be the limit of our security 
protocols. So, again, cooperation or coercion of app service providers 
is not a new, unanticipated form of attack.

I described this example because I think this document should 
acknowledge, explicitly, that there are limits to the scope of what the 
IETF can/should do in responding to pervasive monitoring. The IETF is 
not responsible for all aspects of Internet security. To first order, we 
develop protocols and thus we should focus on security mechanisms 
offered by implementations of those protocols. We may choose to issue 
guidance that goes beyond our standards, but we ought to be very careful 
in so doing.

I believe this document should include a discussion about what we 
perceive to be the scope of IETF standards for security in the context 
of pervasive monitoring. You could note, for example, that the IEEE is 
responsible for encryption standards for WiFi. ETSI and 3GPP have been 
responsible for over the air encryption standards for cellular devices. 
The W3C may be the more appropriate venue for some web security topics, 
e.g., beyond the scope of HTTPS. I realize that we do, sometimes, 
generate RFCs that call for security-relevant actions by hosts, e.g., 
random number generation guidance. And we sometimes provide 
implementation guidance in support of security. But these documents 
don't address host security as their primary focus, so there do seem to 
be limits to what we consider to be inscope.

The security focus of most of our security protocols has been 
protectionof (application layer) content. A few security protocols, 
e.g., ESP, do offer optional traffic flow confidentiality security, but 
most do not. We have considered it a secondary concern, one that we 
believe most users would not see as important. Few of our security 
standards address confidentiality of communication metadata. So, this 
document could state that, in light of revelations about pervasive 
monitoring, the IETF will revisit our assumptions about the need for 
metadata confidentiality in our architecture. That might be a good 
justification for why pervasive monitoring is qualitatively different 
from our previous security model.

The discussion of the term "attack" is necessary and useful. However, 
the document elects to refer to pervasive monitoring as one attack, even 
while acknowledging that it may require multiple, coordinated  attacks 
of different sorts. This muddies the discussion, from a technical 
perspective. I'd prefer to see a discussion of the sort I outlined 
above, which is a bit more precise. While I agree that we ought to 
consider commercial privacy-violating activities at the same time that 
we explore countermeasures to nation-state and criminal violations of 
confidentiality, I believe that the document, as worded, conflates the 
two too much.

Others have already commented that the term "mitigate" is overused here. 
I agree. We're going to develop new countermeasures, or remind folks of 
existing ones that are not being used. The use of these countermeasures 
will help mitigate attacks. Countermeasures are not all encompassing, 
contrary to what the text states. A protocol may have one or more 
vulnerabilities, in its design and/or implementation. An attack exploits 
one or more vulnerabilities. A countermeasure thwarts one or more types 
of attacks. It does not cause vulnerabilities to go away, nor does it 
thwart all possible attacks.

The security considerations section says that privacy is the focus of 
the document, but does not define the term or provide a cite. I think 
security should be the primary focus of this document, emphasizing 
confidentiality, a term with a technical definition that typically used 
in well-written IETF security standards.

If this document is going to stand as a declaration of principle in 
terms of an IETF response to pervasive monitoring, it needs to be 
carefully worded, technically accurate, and persuasive.

Steve

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sun, 15 Dec 2013 21:42:25 +0100

>which I should reply, as part of this thread.

Very good comments. Thank you for submitting them.
-- 
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: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 15:30:59 +0000

Hi Steve,

Thanks for the comments. (Steve sent me an earlier version of
his comments, so my responses are partly pre-cooked based on
our earlier off-list discussion.)

As you'll see I don't agree with most of what I guess you'd
like to be done. The main problem I'd have with your suggested
approach is the significant number of ratholes into which we'd
be required to delve. And I don't see any benefit accruing from
any of those to be honest. Nor from the huge delay that'd
ensue.

> second definition seems more appropriate, i.e., the sense of widespread

I think the word pervasive is entirely clear and the draft does
define pervasive monitoring. I'm sure the definition in the draft
can be improved and concrete suggestions are welcome.

> For many years the IETF security community has used an attack model that

Yes we have. Recent events would appear to indicate though
that the attacker here has significantly increased deployment
within much more recent times, and we should respond to that.

> at any point along a communication path. 

Yes. But "at any point" != "at many points" and we didn't properly
consider the latter IMO.

> We commonly also attribute the

Again "a path" != "many paths" which appears to be the case.
And that's relevant e.g. see this thread [1] on the perpass
list.

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

> against passive wiretapping, based on use of encryption. 

As you note below, those leave some meta-data available for
monitoring. But S/MIME in particular leaves very significant
monitoring potential since it doesn't protect important
header fields such as To, From and Subject.

We have also not succeeded in getting these security protocols
used sufficiently widely to counter the level of attack that
is now clearly happening. There are many reasons for that that
are outside the IETF's control, but we really do need to think
some more about those that are not outside our control. I don't
think its credible for us to say or imply that the IETF or the
security area of the IETF has done wonderfully well, and all
that's needed is for people to listen more to us and go use
what's already been defined.

> These protocols

We have interesting debates ahead of us in terms of figuring
out whether or when we were wrong in requiring authentication
mechanisms be used before a protocol can get confidentiality.
I think a lot of that will turn out to be 20-20 hindsight, but
that we'll decide that we overdid things in some cases resulting
in security protocols being too hard to deploy. I say 20-20
hindsight, because I do think that many of the designs done
in the mid-late 1990s were fit for purpose then. With a much
bigger Internet, now used for more things, its not a huge surprise
we need to revisit some assumptions that were quite reasonable
15 years ago.

> address the adversarial capabilities based on our model.

We do have some great tools in the toolbox. But I think we'll
need more and some changes to current ones, e.g. to make them
more easily deployable and get better usage.

And all of that is for the future, and is the kind of work
that this BCP is intended to help cause happen. The BCP itself
cannot and should not be expected to include the details
since many of them are tricky. And by details I mean both
new tools and the analyses that are needed to figure out
changes that might help with current tools.

> establish a context for this declaration about "pervasive monitoring".

I don't agree. I don't think we need that and do think we'd run
into a large number of ratholes if we try.

But it could be a good thing to add a sentence referring back
to 3552 since that does contain a lot of that kind of text. I
think that could be added to the end of the 1st para of section
2 where we say that we'll deal with this threat in the same way
we deal with others. Say something like:

OLD:

   The IETF also has consensus to, where possible, work to mitigate the
   technical parts of the pervasive monitoring attack, in just the same
   way as we continually do for these and any other protocol
   vulnerability.

NEW:

   The IETF also has consensus to, where possible, work to mitigate the
   technical parts of the pervasive monitoring attack, in just the same
   way as we continually do for these and any other protocol
   vulnerability. [RFC3552] provides some useful background and
   guidance on how the IETF handles security considerations, but
   doesn't specifically consider the pervasive monitoring attack,
   for example by considering the security of meta-data that
   is exposed even if the security mechanisms described are used.

> Having established this context, 

Again, I don't think establishing that context is necessary,
and is a potential source of ratholes.

> the next task is to explain why
> declaration. 

I do not agree that this document needs to explain why pervasive
monitoring is qualitatively different. This document merely
needs to record our consensus that it is an attack that we will
try to mitigate. If however, there are ways in which pervasive
monitoring is qualitatively different that will be a good
discussion to have e.g. at the workshop in London and beyond.

> We ought not lead readers to believe that we have not

We have not considered the pervasive monitoring attack in the
past. If you can find RFCs where we explicitly did, I'd love to
get pointers to those. An assertion that that was properly
considered for even e.g. IPsec (which is probably closest to
being true) would also I'd say cause needless and unproductive
controversy. (BTNS anyone? ;-)

I think we're far better off not spending cycles debating who
did what right or wrong in the past, but rather in working on
the problems we face today and tomorrow.

> passive wiretapping attack is not new, relative to the attack model we

I don't agree that that is needed.

> the mail. 

Does that assume that S/MIME is an adequate e2e protection
against pervasive monitoring? If so, I don't agree. And one
could envisage the IETF having a role if say there were to
be work done on how to turn on S/MIME or PGP (or something
better) even while using a web UA. Indeed any e2e mail
security solution developed today would take support for
web UAs as a core requirement. That wasn't the case when
S/MIME and PGP were developed, but it sure is today.

> I can use TLS to protect the HTTPS session via which I access
> protocols. 

Disagree. See above.

> So, again, cooperation or coercion of app service providers

True. However, the scale of the problem is new, especially now
that so much e.g. mail is centralised in a few providers.

> IETF can/should do in responding to pervasive monitoring. 

I agree. And in fact it explicitly does that already. We
could I guess wordsmith that some more but I doubt we'd
improve things much.

> The IETF is

I agree that care would be needed when doing that. But this
document does not do that - it does focus only on IETF work.

> of pervasive monitoring. 

That sounds to me like another potential rathole, and one from
which we'd emerge with little or no benefit gained.

> You could note, for example, that the IEEE is
> e.g., beyond the scope of HTTPS. 

Interesting idea and tempting, but I suspect we'd be irritated
if some other SDO told us to get our act together so I think
while you're right, that'll have to be done liaison-wise and/or
via chats between people. I've been chatting with W3C folks (as
have others) and they're starting to do stuff now. Not sure
about IEEE but it'd be a fine thing if they could e.g. find a
way to make MAC addresses less identifying, though that's tricky.
Might be a thing to ask them about next time we have a liaison
call. (Security hasn't been a topic for recent IETF/IEEE liaison
calls, but maybe it should be.) As for 3GPP, I guess I'd be
surprised but pleased if they had much interest.

> I realize that we do, sometimes,

Again, I don't see that there's anything related to that in
this BCP, and I don't think there should be. If we dived into
some of the ratholes above there might be but not going there
seems like a much more effective way to handle that to me.

> from our previous security model.

Good point. Something along those lines might fit well, and not
take us down a rathole. I added that to the text around the
3552 reference above, it seems to fit well as a qualification that
the reader following the reference ought keep in mind.

> perspective. 

I disagree. Its pretty clear. Feel free to point out what is
confusing.

> I'd prefer to see a discussion of the sort I outlined

I don't believe that, nor do you say why you do.

> Others have already commented that the term "mitigate" is overused here.

I don't recall that comment actually. Can you give me a pointer
in case I've missed it?

> contrary to what the text states. 

The text does not state that. If it did, it'd be wrong. But if
you want to suggest some wordsmithing please do.

> A protocol may have one or more

I agree. But don't see any change needed.

> the document, but does not define the term or provide a cite. 

Hmmm. That seems entirely wrong. Don't you think 6973 is a citation?
But do feel free to suggest more/better ones.

> I think

Putting the emphasis on any particular mitigation would be
wrong here. We should not make the mistake of assuming that
confidentiality is the answer, no matter what the question.

> carefully worded, technically accurate, and persuasive.

I agree. And think it is. But sure it can be improved and
we've accumulated some edits that will be made during last
call.

I don't however think that we should make most changes
along the lines you suggest above. And I strongly believe
that we should avoid ratholes.

Regards,
S.

---

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

Listening to the discussion between Stephen Farrell and Stephen Kent,
I've realized that I do not believe the the current draft clearly
indicates that the big change here is that we need to consider what
happens when monitoring happens along many paths or kat multiple points
along a path.  I believe that Stephen Farrell clearly explained the
difference and change to Stephen Kent.  I agree with that explanation
and believe the draft would be improved by clearly capturing that.

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 16 Dec 2013 18:15:51 +0100

>and believe the draft would be improved by clearly capturing that.

I do not really read this in Stephen Farrell's response and I am not in
fact sure what you mean. <draft-farrell-perpass-attack-02.txt>, for all
I can tell, is telling us that Google Analytics is an attack. The above
sounds more like it would not be okay for the IETF to design some onion
routing protocol without considering an adversary that can see the raw
bits of 99% of publicly routed IP packets and analyse them in real time.
-- 
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: Sam Hartman <[email-masked]>
Date: Mon, 16 Dec 2013 13:35:58 -0500

>>>>> "Bjoern" == Bjoern Hoehrmann <[email-masked]> writes:

    Bjoern> I do not really read this in Stephen Farrell's response and
    Bjoern> I am not in fact sure what you
    Bjoern> mean. <draft-farrell-perpass-attack-02.txt>, for all I can
    Bjoern> tell, is telling us that Google Analytics is an attack. The
    Bjoern> above sounds more like it would not be okay for the IETF to
    Bjoern> design some onion routing protocol without considering an
    Bjoern> adversary that can see the raw bits of 99% of publicly
    Bjoern> routed IP packets and analyse them in real time.  --

So, our threat model has included passive monitoring basically since we
first wrote it down.

To me, the interesting changes here are that:

1) The probability of passive monitoring approaches 1.  We know it's
happening which is a stronger statement than we know it may happen or we
know it sometimes happens.
(I'm not saying it's happening everywhere on every link all the time)

2) We know people are collecting data at multiple points and putting
it together.
So, if a request into a system generates a request out of a system to
another party, it's reasonable to assume attackers will be trying to
corrilate the events.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Dec 2013 13:48:34 -0500

> So, our threat model has included passive monitoring basically since we

Yes, but that doesn't rule out Google Analytics, as long as the user
knows about it and desires it, right?  

I think, therefore, this bit needs an addition:

   For the purposes of this BCP "pervasive monitoring" means very
   widespread privacy-invasive gathering of protocol artefacts including
   application content, protocol meta-data (such as headers) or keys
   used to secure protocols.  Other forms of traffic analysis, for
   example, correlation, timing or measuring packet sizes can also be
   used for pervasive monitoring.

Adding the sentence, "In addition, to qualify as pervasive monitoring,
the activity should be either unknown to or unwelcome by the target of
the monitor," would make the difference explicit.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Dec 2013 14:47:02 -0500

Sam,
> (I'm not saying it's happening everywhere on every link all the time)
Your parenthetical comment admits the probability is not approaching 1,
for all users on all links, ... This may be a reason why we don't have a
rigorous definition for pervasive monitoring yet.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Dec 2013 15:00:54 -0500

Andy,
> the monitor," would make the difference explicit.
I'd suggest "unauthorized" as a replacement for "unknown or unwelcome",
as we try to better define PM.

I don't think it's necessary to mention "keys" here, since the keys
are not that valuable if you don't also grab the data, wrt confidentiality.

Also, "traffic analysis" probably should be discussed separately from
violating the confidentiality of app layer content. It's probably going
to be easier to address content confidentiality vs. traffic analysis,
and so it behooves us to make the distinction here, if we are trying
to use this doc to explain what we want WGs to address.

I am catching up on this thread, as I lost iesg messages for a few weeks.

I assume that others have noted that "artefact" is misspelled.

Steve

---

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

Replying to a bunch of things at once:

> the monitor," would make the difference explicit.

I disagree. Even if X% of people agreed or approved or authorized
the attack, it would still be an attack. While one might have an
argument if X approximated 100, that's just not the case. And user
consent is a huge rathole that's not meaningful for most protocol
design activities, so I also disagree with including variants of
Andrew's suggestion, as well as disagreeing with the statement.

> and believe the draft would be improved by clearly capturing that.

Slippery-slope alert! I don't disagree with the basic point, but
if we start to characterise the details of the attack then we are
heading down a rathole. That is a rathole we probably need to
enter when we try document the threat model, but that is planned
to be and should be a different document. So please let's try
to include as few words here as are needed and no more. I don't
think we need this addition, even though I agree with the
statement, but not all true statements are needed for the BCP
to be correct. And fewer will make it more effective.

> rigorous definition for pervasive monitoring yet.

I assert we have a sufficient definition for this BCP and do
not here need more. Can you say what ambiguity in interpretation
would be caused by the current definition? I don't think any of
us interested in aimless perfection, but if there are ambiguities
that'd have an impact, then those would be very interesting.
If there are no such ambiguities, then we should be done.

Other points from recent mails:

- RFC4949 is already referenced - are we all reading the draft?
- Artefact is correct. [1]

*Please* let's avoid ratholes, I'd ask that everyone think
whether or not any well-meaning suggestion is one or not
before suggesting stuff.

Cheers,
S.

[1] http://www.oxforddictionaries.com/definition/english/artefact?q=artefact

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Dec 2013 16:07:51 -0500

On Mon, Dec 16, 2013 at 08:39:47PM +0000, Stephen Farrell wrote:
 
> the attack, it would still be an attack.

But this leads you immediately down the path to the objection that
inspired my suggestion: lots of things that you might _want_ for
yourself qualify as an attack under the draft as written.  Google
analytics is not an attack even under the slightly funny meaning of
"attack" we're using here; it's a management tool.  The draft actually
makes this point, in that it notes that there's a tension between
making networks managable and mitigating pervasive monitoring.  I
think it's necessary to add some sort of indication of what principles
can be used to resolve that tension.  

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 21:32:29 +0000

> can be used to resolve that tension.  

Google analytics is not an IETF protocol though. More generally,
I don't think we can fully characterise that tension as it'll
have to be worked out as we do the work on real protocols and
learn what we learn. I figure the right thing for now is to
recognise that tension and if it does resolve itself in future
into some nice sharp set of distinctions then we can update the
BCP then. I doubt it will though. But that's ok.

And don't forget that we are not here saying that all IETF
protocols MUST be proof against pervasive monitoring - email
for example isn't and we're not going to stop sending mail.

So I think its just fine that we figure this out over time.

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Dec 2013 16:50:34 -0500

I don't think I've made my point, so let me try again.

> for example isn't and we're not going to stop sending mail.

Right, but the very same technical acts against an email stream are
either an attack or a service, depending on the stuation from the POV
of the users.

For instance, many businesses scan all mail that comes and goes
through the corporate servers in order to ensure certain legal
compliance requirements are satisfied.  

The same style of scanning can be applied in an effort to look for
"terrorists" or whatever.

I claim that the first of these is not one of the forms of "attack",
as long as the users affected know that this is happening (because,
for example, the existence of the tool is disclosed as part of the
corporate policies).  When governments or $bigprovider or whoever does
it without the user knowing, then it's an attack.  But as written, the
draft currently classifies the first of these cases as an attack also.
I think that strains even the constrained meaning of "attack" as used
in this draft.  (I could equally be persuaded that the document just
needs to embrace this odd consequence of the definition, and call it
out.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 16 Dec 2013 22:53:09 +0100

* Stephen Farrell wrote:
>Google analytics is not an IETF protocol though.

Google Analytics is an example of pervasive monitoring along many paths
and at multiple points without approval or authorisation by users. And
the httpbis Working Group could try and mitigate this attack, e.g. it
could require that browsers connect only to a single origin, just like
it could require browsers to support HTTP/2.0 only in encrypted form.
-- 
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: Ted Lemon <[email-masked]>
Date: Mon, 16 Dec 2013 17:09:51 -0500

On Dec 16, 2013, at 4:50 PM, Andrew Sullivan <[email-masked]> wrote:
> corporate policies).

In the case of corporate email, the "user" is the corporation, including, but not limited to, the person who is the intended recipient of the mail.   So the "user" is not under attack, because the "user" is the only entity looking at the mail.

In the case of an email service, the situation is a bit different, but still essentially you are signing up for a service which includes certain features, which you agree to, and then they happen.

The concern here is not about "surveillance" that happens with the user's knowledge and consent.   It is not even about surveillance that is done overtly, but without the user's intent.  It is specifically with surveillance that is done covertly, without the user's consent.

At least, that's how I understood it.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 22:45:09 +0000

Hiya,

> needs to embrace this odd consequence of the definition, and call it

Ah, now I'm getting your point. Sorry for being slow:-)

Yes, we could count your corporate mail scanning example as
something that fits the definition but also fits under the
"tension" statement and live with that. I think that's quite
tenable.

Or in the corporate case above you could reasonably say that
it doesn't fit the "very widespread" part of the definition
whereas the $bigprovider mail service is probably fairly
considered very widespread.

But even if you think both of the above approaches are wrong,
I don't think consent is the angle to take here for the reasons
stated.

As for Google analytics, I'm not familiar enough with how it
really works to say. (I'm in the 0.x% minority who run noscript
and ghostery, etc.:-)

*But*, all of the above is really thinking about specific
deployments. For us, as the IETF, the questions are more about
the protocols, which will probably be the same in numerous
deployments. So I think our WGs probably do need to think
about the topic in general and how to mitigate it. While
there may be use-case specific things done in some WGs,
those are relatively uncommon. (Or maybe I'm getting the
wrong end of your stick again:-)

S.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 16 Dec 2013 18:06:25 -0500

> "tension" statement and live with that. I think that's quite

Ok.  I wonder whether text along this line in the last paragraph at
of section 1 would make it clear enough:

    …might consider them to be.  For the same reason, a given feature
    of a protocol can often be used both to enable behaviours desired
    by users of the protocol, and to enable pervasive monitoring.
    Moreover, as technology advances …

> I don't think consent is the angle to take here for the reasons

Well, if you just say "this is part of that tension" then you don't
need to give a general-purpose profile of that tension, I guess.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: t.p. <[email-masked]>
Date: Tue, 17 Dec 2013 10:57:45 +0000

----- Original Message -----
From: "Andrew Sullivan" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 16, 2013 9:50 PM
> needs to embrace this odd consequence of the definition, and call it

Spot on.

A sea change with websites over the past year or two, probably the
result of an EU directive, is
that many if not most websites are now most informative about Cookies,
what they are, how they are used and so on, before inviting their use.

Cookies are of course a form of pervasive monitoring and without such
information, they are an attack; with it, they are not  (us technicians
may
have known that for years but not acted upon it).

What we need is a similar statement about all the other information that

websites upload from us.  Google has been mentioned, but when looking at
an airline website yesterday, I was surprised to find that connections
were set up to another 10 or so sites, most of which I had never heard
of and whose names had no resemblance to that of the airline or any of
its partners.  And no, I had not clicked any buttons (Like, Twitter,
Facebook etc) anywhere, just entered From, To and Date.  That is an
attack.  That is what we should be calling out (although perhaps not in
this I-D).

Tom Petch

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 17 Dec 2013 11:06:40 +0000

On 16/12/2013 20:39, Stephen Farrell wrote:
> argument if X approximated 100, that's just not the case.
An example of 100% would be an employer doing anti-malware
filtering, monitoring for spyware or trapping the export of intellectual
property, where consent for traffic monitoring is a condition of
employment.

> And user
The issue is where a protocol needs to be designed to operate
in two modes - PM=OK and PM=NotOK. Unless antiPM is
conditional the protocol would not be of use in an  environment
requiring PM.

- Stewart

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 17 Dec 2013 06:22:45 -0500

On 12/16/13 6:06 PM, Andrew Sullivan wrote:
> Ok.  I wonder whether text along this line in the last paragraph
> at of section 1 would make it clear enough:
> 

Although I don't think the BCP needs to explicitly deal with
"beneficial surveillance," Andrew's statement above gets closer to how
I have been thinking about this tension: Rather than "consent" or some
oft-problematic bright line good/bad attack determination, I think
it's more about "surveillance that works in the interests of the user
or, alternatively, against those interests."

best, Joe

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2013 11:41:26 +0000

Hi Stewart,

On 12/17/2013 11:06 AM, Stewart Bryant wrote:
> in two modes - PM=OK and PM=NotOK. 

I think what we want is to setup the definition so that
we never need PM=OK. And I think the current definition
does that - in your corporate example I don't think that
is a case of pervasive monitoring, since it wouldn't
really fit the "very widespread" part of the definition.
So I think its non-pervasive monitoring.

To be clear: I'm not saying that I like or dislike such
non-pervasive monitoring, but I don't think its pervasive
monitoring as defined here. Going back to the hums in
Vancouver as a useful reference, there was not an
overwhelming hum for considering such non-pervasive
monitoring as an attack. I can't recall the exact question
now though sorry - I think it was about middleboxes but
the implication I think is that non-pervasive monitoring
is at least sometimes ok, and the suggested text sent to
the list earlier describes that (better than -02 does I
think).

> Unless antiPM is

If we get the definition right (and I think we have it
close enough) then there should be no real cases where we
have an environment "requiring PM" (for technical reasons)
but rather there will be cases of environments that require
non-pervasive monitoring, e.g. for n/w management or
similar technical reasons. (I do accept that inbound malware
scanning is a real requirement, even though I mostly like
us all encrypting things:-)

I think protocol designers will have to figure out the
various cases arising with various antiPM mechanisms,
and it'll depend.

Say if antiPM feature was to not send the full QNAME in
a DNS query from a recursive resolver in your DMZ, then
that should not be a problem for your corporate whatnot.
(Assuming that particular antiPM mechanism gets worked
out fully etc.) The same should be true for any antiPM
mechanism that takes the "just don't send it" approach
maybe.

If the antiPM feature is to e2e encrypt application
layer payload with endpoint authentication then yes the
corporate whatnot will be problematic for that protocol,
or vice-versa depending on your perspective, whenever
that e2e crypto is used. So protocol designers in that
case will need to deal with the tension that is called
out in the draft.

S.

PS: Please note that this BCP does not call for crypto
being mandatory to use. Should the IETF want to go there,
that would be a different debate, best not confused with
this one.

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Dec 2013 08:10:14 -0500

A week or so ago we had a thread about PM being _indistinguishable_ from an
attack, and the purposes of network operations, which ended with text from
Alissa. Didn't that cover this point?

Scott

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Dec 2013 09:25:33 -0500

Folks,

Rather than discussing specific details of the current doc, I though it 
might
be helpful to offer some text. The text below is my take as what I think we
should be saying.

Steve
-------

Recent revelations [cites] about widespread monitoring of Internet 
communications by a number of national intelligence agencies has caused 
great concern in the IETF community.

The IETF security community has always considered passive wiretapping be 
a feasible attack against the confidentiality of Internet traffic while 
in transit (or while in storage en route to an end user). We also 
presume that active attacks are feasible, especially off-path active 
attacks, e.g., DNS cache poisoning [cite]. Even on-path, 
man-in-the-middle (MITM) attacks are viewed as possible, by some classes 
of adversaries.

The IETF has developed a set of security protocols to counter passive 
and active wiretapping attacks, e.g., IPsec, TLS, SSH, S/MIME, SRTP. All 
of these protocols offer confidentiality, via encryption, as a way to 
defend against passive wiretapping. They also employ cryptographic 
message authentication codes (MACs) or digital signatures to provide 
data integrity and authentication.

The cryptographic mechanisms employed by these protocols are effective 
against a very broad range of attacks and adversaries.

The IETF has not ignored the potential for passive and active wiretapping.

In some respects, widespread monitoring of Internet communication by 
nation states ought not be a surprise. They qualify as threats against 
Internet communication, i.e., motivated, capable adversaries. These 
adversaries have extensive technical capabilities and are motivated to 
collect information in support of (their) national security missions. 
Nonetheless, the scale of the monitoring that has been disclosed is 
considerably greater than what most IETF community members anticipated.

The IETF community perceives a qualitative difference between targeting 
and monitoring individual Internet communications vs. very widespread 
(pervasive) monitoring of such communication. As a result, the IETF 
community has reached consensus [cite] to address the pervasive 
monitoring of Internet communications by revisiting our security 
protocol standards with a goal of making it easier for users and service 
providers to offer better protection for Internet communications.

IETF security standards provide a number of mechanisms to protect the 
application layer content of Internet communications. However, most of 
these standards do not emphasize confidentiality for protocol metadata, 
other than what accrues from encapsulating such data at higher layers. 
Based on the disclosures cited above, the IETF community also has 
decided that more emphasis should be placed on protecting such metadata.

The IETF community recognizes that not all aspects of Internet 
communicationsecurity are within the purview of the IETF. Communication 
security may be offered at multiple layers within the protocol 
hierarchy; the IETF does not create standards for all of these layers. 
For example, the IEEE has created encryption standards for layer 2 (LANs 
and MANs). Security for Internet communications also is affected by 
design and implementation choices within hosts and servers, and most of 
these are outside of the scope of IETF standards.

The IETF community recognizes that not all forms of monitoring of 
Internet traffic constitute the sort of attack that have motivated this 
declaration. Many Internet service providers monitor traffic on their 
nets in support of traffic engineering and network management. Such 
monitoring does not require access to application layer content, but it 
does require access to some types of metadata. Many application service 
providers access application layer content as part of providing their 
services. This access is outside of the scope of this effort. Within an 
enterprise network, monitoring of traffic often is performed in support 
of security, e.g., intrusion detection systems, anti-virus and anti-spam 
filtering. This type of monitoring has a legitimate purpose and is 
within the purview of an enterprise, so it too is not considered an 
attack to be addressed by this IETF effort.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Dec 2013 09:38:31 -0500

Stephen,
> If there are no such ambiguities, then we should be done.
I disagree. I think specific discussions of what is NOT PM will
help, and saying why we believe PM merits our attention, NOW, is
important.  Otherwise, we will look silly to many readers.
> - RFC4949 is already referenced - are we all reading the draft?
     my comment re 4949 was a respond to the ISO terminology message.
> - Artefact is correct. [1]'
Artifact is the US English spelling, as the OED notes. I thought we
usually go with US vs. UK English, which is why we don't see a lot
of instances of "colour" and "behaviour" inn RFCs :-).
> whether or not any well-meaning suggestion is one or not

You say rathole, I say clear explanation of what we see as in and out of 
scope,
why PM is different from what we have long addressed, and examples to 
clarify
this. Avoiding examples creates ambiguity in a context where terms are not
crisply defined. We seem to be in that context.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2013 15:13:47 +0000

Hi Steve,

On 12/17/2013 02:38 PM, Stephen Kent wrote:
> I disagree. 

I guess we disagree:-)

> I think specific discussions of what is NOT PM will
> help, 

Latest suggested text on that on the list was at [1]
following a longish thread.

> and saying why we believe PM merits our attention, NOW, is
> important.  

That's fair. The current text says because PM is
indistinguishable from other attacks, but see
also the text I suggested in [2]. I do think that's
enough really for this document.

> Otherwise, we will look silly to many readers.

Well, as you know, I don't much mind looking silly
myself:-) But I don't think I've not seen anyone
(else?) say the current text looks silly.

>     my comment re 4949 was a respond to the ISO terminology message.

Sorry, didn't mean you there.

> of instances of "colour" and "behaviour" inn RFCs :-).

The RFC editor is fine with either, so long as its
consistent in the document is my understanding. So
both spellings are correct, and neither is wrong.

> You say rathole, 

That was a bit pejorative of me all right I guess, but
I do think there's plenty of scope for us to rathole.

> I say clear explanation of what we see as in and out of
> scope,

I do plan to incorporate a bit of text from my reply
to you earlier on that. [2] And I'll look over the text
you just sent to see if there are bits that could be
stolen^H^H^H^H^H^Hused.

I don't disagree with quite a bit of your text btw,
though there are definitely bits where we do disagree.
I'll watch for responses to your other mail though.

> crisply defined. We seem to be in that context.

I've still not seen a good example of such an ambiguity. If
there are some then that really would be interesting.

Cheers,
S.

PS: I'll be incorporating changes into a -03 in the next
day or two since Jari asked for that.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg84888.html
[2] http://www.ietf.org/mail-archive/web/ietf/current/msg84998.html

---

From: Stephen Kent <[email-masked]>
Date: Tue, 17 Dec 2013 12:12:20 -0500

Stephen,

> ...
yep. my later message provided text to illustrate what I
think is a reasonable way to approach this discussion.
> (else?) say the current text looks silly.
I also don't mind if you look silly; I mind if the IETF looks silly :-).
We have not had feedback from the external audience to which this is 
directed.

> ...I don't disagree with quite a bit of your text btw, though there 
> are definitely bits where we do disagree. I'll watch for responses to 
> your other mail though. 
I'll await your responses.
> there are some then that really would be interesting.

The extended discussion over what is and is not PM, vs. legitimate 
monitoring,
is indicative of what I see as evidence of ambiguity.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Dec 2013 17:19:29 +0000

> is indicative of what I see as evidence of ambiguity.

I don't think extensive discussion by itself does indicate
that. We are quite capable of having extensive discussions
on all sort of things:-) But I do agree that the discussion
on this one has produced improved text that I'm trying to
integrate now. The -03 will pop out this week with that for
folks to chew on.

I would really be interested though in specific ambiguities
and in improving the definition if necessary.

S.

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 19 Dec 2013 15:05:37 +0100

I think there are disagreements on the draft. The authors disagree on
some repeated points made by IETF participants, so I think the document
represents author points as well but we need to make sure this document
represent IETF consensus as it claimed, it needs agreements remotely and in
meeting before submission. We don't want it to be part of attackers attacks.

AB