Subject: [perpass] Fwd: here's my message to perpass from yesterday, see any problems with it?

From: Sean Turner <[email-masked]>
Date: Mon, 16 Dec 2013 09:08:01 -0500

Forwarding on behalf on Steve Kent.

spt

> -------- Original Message --------
> Subject:	My comments on aft-farrell-perpass-attack-02.txt seem to post here, so ...
> Date:	Wed, 11 Dec 2013 11:13:20 -0500
> From:	Stephen Kent <[email-masked]>
> To:	perpass <[email-masked]>
> 
> 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 in  scope. 
> 
> The security focus of most of our security protocols has been protection  of (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: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 14:19:04 +0000

> Forwarding on behalf on Steve Kent.

Ta. That did make it to the ietf list over the weekend
and I replied, but whatever's gumming up the system
for Steve also hit my reply;-)

The IETF list is the right place for the discussion
though rather than this list I think so if folks can
wait a while until we unstick whatever's gummed up
that'd be good. I'll send mail when I think that's
done. (I figure there's some spam filter somewhere
that's messing up or something, based on the ticket
I saw generated.)

S.

>> 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 atta
 cks. Thus
 we have offered users and system designers a set of tools that address the adversarial capabilities based on our model. 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Dec 2013 15:53:33 +0000

> that's messing up or something, based on the ticket

The explanation arrived. My response to Steve's mail
contained the string "route" at the end of a sentence,
so then a full stop "." and was followed by a sentence
that started with "In" but with no spaces between those.
That was interpreted as a URI for somewhere naughty
enough to apparently get the message a spam score
sufficiently high that the message is just dropped.

I just fixed that in my response and my mail is on
the IETF discuss list [1] so follow up there if
commenting further please.

If you're also replying to Steve, [2] or to my
reply, please watch out for rewrapping the text if
you don't see your mail hit the list.

What a world;-)

S.

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