ietf
[Top] [All Lists]

Re: Last Call: <draft-farrell-perpass-attack-02.txt> (Pervasive Monitoring is an Attack) to Best Current Practice

2013-12-16 09:31:28

Hi Steve,

Thanks for the comments. (Steve sent me an earlier version of
his comments, so my responses are partly pre-cooked based on
our earlier off-list discussion.)

As you'll see I don't agree with most of what I guess you'd
like to be done. The main problem I'd have with your suggested
approach is the significant number of ratholes into which we'd
be required to delve. And I don't see any benefit accruing from
any of those to be honest. Nor from the huge delay that'd
ensue.

On 12/15/2013 08:31 PM, Stephen Kent wrote:
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.

I think the word pervasive is entirely clear and the draft does
define pervasive monitoring. I'm sure the definition in the draft
can be improved and concrete suggestions are welcome.

For many years the IETF security community has used an attack model that

Yes we have. Recent events would appear to indicate though
that the attacker here has significantly increased deployment
within much more recent times, and we should respond to that.

envisions an adversary who can engage in passive and active wiretapping
at any point along a communication path. 

Yes. But "at any point" != "at many points" and we didn't properly
consider the latter IMO.

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

Again "a path" != "many paths" which appears to be the case.
And that's relevant e.g. see this thread [1] on the perpass
list.

   [1] http://www.ietf.org/mail-archive/web/perpass/current/msg01387.html

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. 

As you note below, those leave some meta-data available for
monitoring. But S/MIME in particular leaves very significant
monitoring potential since it doesn't protect important
header fields such as To, From and Subject.

We have also not succeeded in getting these security protocols
used sufficiently widely to counter the level of attack that
is now clearly happening. There are many reasons for that that
are outside the IETF's control, but we really do need to think
some more about those that are not outside our control. I don't
think its credible for us to say or imply that the IETF or the
security area of the IETF has done wonderfully well, and all
that's needed is for people to listen more to us and go use
what's already been defined.

These protocols
also usually incorporate data integrity and authentication mechanisms,
and, where appropriate, anti-replay mechanisms, to address MiTM attacks.


We have interesting debates ahead of us in terms of figuring
out whether or when we were wrong in requiring authentication
mechanisms be used before a protocol can get confidentiality.
I think a lot of that will turn out to be 20-20 hindsight, but
that we'll decide that we overdid things in some cases resulting
in security protocols being too hard to deploy. I say 20-20
hindsight, because I do think that many of the designs done
in the mid-late 1990s were fit for purpose then. With a much
bigger Internet, now used for more things, its not a huge surprise
we need to revisit some assumptions that were quite reasonable
15 years ago.

Thus we have offered users and system designers a set of tools that
address the adversarial capabilities based on our model.

We do have some great tools in the toolbox. But I think we'll
need more and some changes to current ones, e.g. to make them
more easily deployable and get better usage.

And all of that is for the future, and is the kind of work
that this BCP is intended to help cause happen. The BCP itself
cannot and should not be expected to include the details
since many of them are tricky. And by details I mean both
new tools and the analyses that are needed to figure out
changes that might help with current tools.



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".

I don't agree. I don't think we need that and do think we'd run
into a large number of ratholes if we try.

But it could be a good thing to add a sentence referring back
to 3552 since that does contain a lot of that kind of text. I
think that could be added to the end of the 1st para of section
2 where we say that we'll deal with this threat in the same way
we deal with others. Say something like:

OLD:

   The IETF also has consensus to, where possible, work to mitigate the
   technical parts of the pervasive monitoring attack, in just the same
   way as we continually do for these and any other protocol
   vulnerability.

NEW:

   The IETF also has consensus to, where possible, work to mitigate the
   technical parts of the pervasive monitoring attack, in just the same
   way as we continually do for these and any other protocol
   vulnerability. [RFC3552] provides some useful background and
   guidance on how the IETF handles security considerations, but
   doesn't specifically consider the pervasive monitoring attack,
   for example by considering the security of meta-data that
   is exposed even if the security mechanisms described are used.

Having established this context, 

Again, I don't think establishing that context is necessary,
and is a potential source of ratholes.

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. 

I do not agree that this document needs to explain why pervasive
monitoring is qualitatively different. This document merely
needs to record our consensus that it is an attack that we will
try to mitigate. If however, there are ways in which pervasive
monitoring is qualitatively different that will be a good
discussion to have e.g. at the workshop in London and beyond.

We ought not lead readers to believe that we have not
tended to consider passive and active wiretapping as likely attacks in
the past.

We have not considered the pervasive monitoring attack in the
past. If you can find RFCs where we explicitly did, I'd love to
get pointers to those. An assertion that that was properly
considered for even e.g. IPsec (which is probably closest to
being true) would also I'd say cause needless and unproductive
controversy. (BTNS anyone? ;-)

I think we're far better off not spending cycles debating who
did what right or wrong in the past, but rather in working on
the problems we face today and tomorrow.

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.

I don't agree that that is needed.

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. 

Does that assume that S/MIME is an adequate e2e protection
against pervasive monitoring? If so, I don't agree. And one
could envisage the IETF having a role if say there were to
be work done on how to turn on S/MIME or PGP (or something
better) even while using a web UA. Indeed any e2e mail
security solution developed today would take support for
web UAs as a core requirement. That wasn't the case when
S/MIME and PGP were developed, but it sure is today.

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. 

Disagree. See above.

So, again, cooperation or coercion of app service providers
is not a new, unanticipated form of attack.

True. However, the scale of the problem is new, especially now
that so much e.g. mail is centralised in a few providers.

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. 

I agree. And in fact it explicitly does that already. We
could I guess wordsmith that some more but I doubt we'd
improve things much.

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 agree that care would be needed when doing that. But this
document does not do that - it does focus only on IETF work.

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. 

That sounds to me like another potential rathole, and one from
which we'd emerge with little or no benefit gained.

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. 

Interesting idea and tempting, but I suspect we'd be irritated
if some other SDO told us to get our act together so I think
while you're right, that'll have to be done liaison-wise and/or
via chats between people. I've been chatting with W3C folks (as
have others) and they're starting to do stuff now. Not sure
about IEEE but it'd be a fine thing if they could e.g. find a
way to make MAC addresses less identifying, though that's tricky.
Might be a thing to ask them about next time we have a liaison
call. (Security hasn't been a topic for recent IETF/IEEE liaison
calls, but maybe it should be.) As for 3GPP, I guess I'd be
surprised but pleased if they had much interest.

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.

Again, I don't see that there's anything related to that in
this BCP, and I don't think there should be. If we dived into
some of the ratholes above there might be but not going there
seems like a much more effective way to handle that to me.

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.

Good point. Something along those lines might fit well, and not
take us down a rathole. I added that to the text around the
3552 reference above, it seems to fit well as a qualification that
the reader following the reference ought keep in mind.

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 disagree. Its pretty clear. Feel free to point out what is
confusing.

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.

I don't believe that, nor do you say why you do.

Others have already commented that the term "mitigate" is overused here.

I don't recall that comment actually. Can you give me a pointer
in case I've missed it?

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. 

The text does not state that. If it did, it'd be wrong. But if
you want to suggest some wordsmithing please do.

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.

I agree. But don't see any change needed.

The security considerations section says that privacy is the focus of
the document, but does not define the term or provide a cite. 

Hmmm. That seems entirely wrong. Don't you think 6973 is a citation?
But do feel free to suggest more/better ones.

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.

Putting the emphasis on any particular mitigation would be
wrong here. We should not make the mistake of assuming that
confidentiality is the answer, no matter what the question.


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.


I agree. And think it is. But sure it can be improved and
we've accumulated some edits that will be made during last
call.

I don't however think that we should make most changes
along the lines you suggest above. And I strongly believe
that we should avoid ratholes.

Regards,
S.




Steve


<Prev in Thread] Current Thread [Next in Thread>