Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitori

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