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

I commented earlier to Stephen (off list) that BCP status seemed a bit 
out of place for
a position statement, so I'm heartened to see others have a similar 
concern. I concur
with the suggestion that this be (IAB stream) Informational.

If published as Informational, I don't worry that this doc does not lay 
out details
for what WGs are expected to do. At the behest of two IAB members, I am 
working on a
doc that examines keying options for major IETF security protocols, and 
discusses what
changes could be made to facilitate anonymous encryption as a fallback 
from authenticated encryption. This is just one aspect of an overall 
response to PM, but it will yield concrete proposals. Other folks are 
working on an updated threat model doc.
I have also noted that the document refers to PM as "indistinguishable" 
from an attack,
which IMHO seems too polite. PM is effected via passive and active 
wiretapping attacks, and
thus it IS an attack. Tim Bray's message characterized the current draft 
as saying "The perpass-attack draft says that pervasive monitoring has 
the characteristics of an attack, ..." This suggests that a reader 
doesn't interpret the text as saying that PM _is_ an attack.
We should avoid words that may lead a reader to believe that PM is 
/equivalent/ to an
attack. Its easy to make a case that PM is an attack. I provided (off 
list) feedback a
few weeks ago suggesting a different way to present the issues here, and 
have updated that text:
For many years the IETF security community has used an attack/threat 
model [RFC3552] that envisions an adversary who can engage in passive 
and active wiretapping at any point along a communication path. We 
commonly 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. However,
RFC 3552 states:

   By contrast, we assume that the attacker has nearly complete control
   of the communications channel over which the end-systems communicate.
   This means that the attacker can read any PDU (Protocol Data Unit) on
   the network and undetectably remove, change, or inject forged packets
   onto the wire.  This includes being able to generate packets that
   appear to be from a trusted machine.  Thus, even if the end-system
   with which you wish to communicate is itself secure, the Internet
   environment provides no assurance that packets which claim to be from
   that system in fact are.

This statement is pretty clear. I think the PM document needs to 
explain, in a technical context, why pervasive monitoring is 
qualitatively different, and thus merits this declaration by the IETF. 
We ought not lead readers to believe that we have not considered 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 our security model has always assumed.
Some of the reported forms of pervasive monitoring have involved the 
cooperation of or subversion of application service providers. This does 
represent a major deviation from
the 3552 model:

   The Internet environment has a fairly well understood threat model.
*In general, we assume that the end-systems engaging in a protocol**
**   exchange have not themselves been compromised.*

So we should acknowledge this as one asp[ect of PM that is different 
from our threat model. However, 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.