Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice
2013-12-15 14:31:34
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
|
|