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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]