ietf
[Top] [All Lists]

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

2013-12-11 07:27:09

Hi Stewart,

Thanks for the comments. I do think the main point you
raise is one that warrants discussion and seems similar
to Eliot's but clearer, at least to me, (I still don't
get Eliot's real issue;-)

On 12/11/2013 12:27 PM, Stewart Bryant wrote:
                   Pervasive Monitoring is an Attack
                  draft-farrell-perpass-attack-02.txt

   This BCP simply records the consensus to design
   protocols so as to mitigate the attack, where possible.

SB> "where possible" has huge implications, since it does not
SB> define where on the scale unnoticeable cheap to leading
SB> in technology and cost the boundary lies.

That's maybe fair. OTOH, "where possible" may be the most
precise we can get without either neutering the BCP or
dragging it into endless ratholes. (But see below.)

SB> I hope that you mean "where economically feasible
SB> within the context of the application"

I don't think it means exactly that. I think "where
possible" in this context means "considering the other
constraints faced in the design of IETF protocols."
If it helped to add that without enumerating those
other constraints then I think that'd maybe be ok.

   More limited-scope monitoring to assist with network management that
   is required in order to operate the network or an application is not
   considered pervasive monitoring.

SB> This discussion on the tension between monitoring for good and bad
SB> reasons  focuses on network management in the technical sense.
SB> However there are many legitimate reasons for traffic analysis
SB> and traffic content monitoring that go beyond the basics of
SB> network management.

That's a fair comment, but I've not seen any suggested alternative
that'd not neuter the meaning of the BCP so far, including yours
below.

SB>
SB> Our technologies are used in many environments and we need
SB> to ensure that they are fit for off of those environments.
SB> For example there are many reasons why a business may need
SB> or even be required to monitor, filter and record the content and
SB> the metadata of the traffic they flows through its networks.
SB>
SB> There is also the issue of the tension between privacy and
SB> the big data models that are the economic fuel that enables
SB> many cloud and Internet services to be affordable to many
SB> Internet users.
SB>
SB> I thus think that we need to be very careful with setting
SB> the scope of permitted monitoring enabled by protocols
SB> in such a restricted way.

SB> I think that we need to say something of the form:
SB>
SB> Note that limited-scope monitoring required in order to assist
SB> with network management or that is required in order to operate the
SB> network or an application are not considered pervasive monitoring.
SB> Equally monitoring that the user consents to in order that the
SB> operator may operate the network or provide a service economically
SB> or monitoring in compliance with local regulations should not be
SB> considered an attack.

Thanks for the concrete suggestion, but I have a number of
problems with that text:

- Required in order to operate the network is very vague
and could be used to justify almost anything at all. What
would *not* be justifiable with that text? (See my response
to Alissa on that just now, which makes the same point.)

- User consent is a rathole that I think we have to avoid.
Would an EULA then mean that users have consented to pervasive
monitoring? If you read most of those then they generally
have the user give up everything. And how would a protocol
designer ever know if a user had consented to something or
not? I don't think we can include any mention of user
consent in this BCP.

- I don't think we should call out economics in a BCP like
this. All IETF work is constrained by a number of practical
factors, including economics but also performance, fairness,
fate-sharing and loads of other things. We shouldn't be
calling all or any of those out here.

- Local regulations again adds that huge ambiguity when
considering RFC 2804. I really don't think that this BCP
should be used to try to re-do the raven discussion or
cause WGs to have to re-do that over and over. Adding
that phrase would have that detrimental effect.

So again, I do agree that the network management bit is
not perfect, but every alternative so far seems far worse
that the -02 version to me at least. (And others have
expressed that concern as well.)

SB>
 
   There is though a clear potential
   for such limited monitoring mechanisms to be abused as part of
   pervasive monitoring, so this tension needs careful consideration in
   protocol design.  Making networks unmanageable in order to mitigate
   pervasive monitoring would not be an acceptable outcome.

SB> Again I am concerned that network management (unless you have
SB> a far broader view of what NM is than I) is simply too narrow
SB> a scope for permitting monitoring.

I think any change there would be easy enough if we could
figure out a non-neutering change to the text earlier in
that paragraph.

   But
   equally, ignoring pervasive monitoring in designing network
   management mechanisms would go against the consensus documented in
   this BCP.  An appropriate balance will likely emerge over time as
   real instances of this tension are considered.

SB> My view is that we need to get a much better handle on what
SB> that balance is before we publish this BCP. To do otherwise
SB> is going to stall IETF work and result in an inconsistency
SB> as IDs make the "case law".

Mine fwiw is that we should document the consensus that was
overwhelming in the room in YVR and then work out the details
based on real protocol design issues as those arise. I don't
believe that we can or should try to build a theoretical
castle in the sky before documenting the most significant bit
of the consensus.

To give another reason for that - today, we don't have (IMO)
any practical scheme for e2e email security that'd usefully
mitigate pervasive monitoring when a service provider either
colludes, is coerced or hacked. In that particular case, I
don't have much hope we'll solve it soon, but if someone did
come up with a scheme that made a significant difference then
this BCP should be usable for them to argue that the IETF
should be doing work on that when or if we're working on mail
standards.

So its not actually possible for this BCP to fully describe
all the details since we don't have practical solutions in
many of the e2e cases today.

SB>
SB> Some text of the following form would also be of use in the draft:
SB>
SB> An protocol defined or modified to mitigate monitoring
SB> MUST take into account the deployment needs and economic
SB> realities of the broad spectrum of operators, who will
SB> deploy the protocol both now and into the foreseeable future.

Again I don't think calling out "economic realities" like
that is correct. We shouldn't design our protocols for just
the current business models that people have since those
change over time. Not that long ago, many people could have
argued that no IETF work matched the economic realities and
even today, there are many places where the economic realities
are sufficiently different that such constraints are not
appropriate to include in a BCP like this.

Note - I'm not saying that WGs should ignore economic issues,
but that we should not call them out here.

   It is also important to note that the term "mitigation" is a
   technical term that does not necessarily imply an ability to
   completely prevent or thwart an attack.  As in common English usage,
   this term is used here in the sense of "make less severe, serious, or
   painful."  [OED] In this case, designing IETF protocols to mitigate
   pervasive monitoring will almost certainly not completely prevent
   such from happening, but can significantly increase the cost of such
   monitoring or force what was covert monitoring to be more overt or
   more likely to be detected (possibly later) via other means.

SB> I think that the above is stated backwards. Surely we should state up
SB> front that the goal, as with most security, is to increase the
SB> cost of monitoring to a find a more acceptable point on the
SB> cost-return curve in the light of current technology and ideally
SB> to be able to maintain this as technical capabilities change over time.

I don't think about it solely in terms of monetary cost, and nor
I think will a lot of users. Service providers and implementers
do of course, but that cost-return isn't the only consideration
at least not until you take into account reputation costs and
opportunity costs and so on, all of which are pretty vague. And
that's not even mentioning whatever it is that users think
about giving up privacy. So when considering a threat the
ideal (which is generally not possible) is to completely
mitigate that threat, and all we're saying here is to expect
even more imperfection than usual;-) I think we do need to
say that, otherwise we may create the false impression that
we're claim to solve the problem.

Cheers,
S.



- Stewart

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