Hi Steve,
A couple of points...
On 01/02/2014 04:03 PM, Stephen Kent wrote:
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.
I fully agree its an attack, but the point of indistinguishable
is not to be polite, but rather to counter those who'd declare
that it is not an attack because their government only ever do
good things. That is also important. (And is the main reason for
this response as its a new point, I think most of the stuff
below is repetitive.
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:
I think I responded to that (wasn't it on list too? but anyway...).
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.
"a path" != many paths which is what we've now seen to be the case
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.
Sorry, no - those are fine tools but they do not fully protect.
For example S/MIME doesn't cover mail headers etc.
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.
If that last is meant to mean that we've already done enough
then I don't share that view.
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.
I don't think that's defensible to be honest if you mean that
we've long considered this scale and kind of attack and designed
countermeasures accordingly.
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
ofthe communications channel over which the end-systems communicate.
Again, that talks about "the" channel though.
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.
I don't agree to be honest that that is needed. The fact of the attack
is sufficient justification, compared to previous consideration of
potential, not actually exploited, threats.
We ought not lead readers to believe that we have not considered passive
and active wiretapping as likely attacks in the past.
I agree we did consider those. But in too limited a way as it turns
out.
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.
I strongly disagree with that last point. If we are ever to succeed
with end-to-end email security for example (which I doubt), then that
would have to encompass web-UAs as an inherent part of the overall
system. Thus the security of the message store and submission server
would be intimately related to any e2e confidentiality mechanism.
And of course, we'd also need to counter spam somehow. Those are real
requirements that show that our threat models do need to extend to
some (but not all) aspects of host security.
Regards,
S.