Hi SM,
On 11/27/2013 06:56 PM, SM wrote:
At 08:13 27-11-2013, IAB Chair wrote:
At the Vancouver IETF meeting, the IAB held a technical plenary that
discussed pervasive monitoring. The IAB believes that pervasive
monitoring represents an attack on the
The minutes for that plenary is not available at the moment. I would
appreciate if the minutes could be published.
See Mary's mail.
Internet in as much as large amounts of information that is intended
to be confidential between sets of individuals is in fact gathered and
aggregated by third parties. Such a broad scale attack can undermine
confidence in the infrastructure, no matter the intent of those
collecting the information.
draft-farrell-perpass-attack-00 is intended to establish an IETF
community consensus on this matter. We encourage the community to
read and engage in discussion about this draft, and also to take
practical measures to limit pervasive monitoring within their
environments.
In Section 1:
"that should be mitigated where possible via the design of protocols
that make pervasive monitoring significantly more expensive or
infeasible"
That sounds like an arms race [1].
Well, only to the same extent that any cycle of threats emerging
and us figuring out mitigations is an ongoing process, so I don't
see this as being different in that respect, after we've taken the
step to recognise that its an attack that we ought try mitigate.
"A fuller problem statement with more examples and description can be
found in [ProblemStatement]"
That document is not available.
Yes. (As stated in the References section.) The idea there is
to start by collating text from the various drafts that people
have already sent to the perpass list. I hope we'll get a draft
of that in the not-too-distant but I'm pretty sure that most
everyone is already familiar with the gist of the problem
here - certainly well enough to express support or not for
this draft when it gets to a last-call. (And personally I'm
hoping that LC on this one will start in the near future.)
"In particular, the term, when used technically, implies nothing about
the motivation of the bad-actor mounting the attack, who is still
called a bad-actor no matter what one really thinks about their
motivation."
The usual term in the IETF is "adversary" and not "bad-actor". "bad
actor" is sometimes defined as "contentious individual".
That term was a bikeshed [2] on the perpass list already (including
a mail from your good self:-)
I figure s/bad actor/actor/ as suggested by PSA was the best
change. (I've a few other minor changes to make as a result
of discussion on that list as well, hope to get -01 out with
those over the weekend.)
[2] http://www.ietf.org/mail-archive/web/perpass/current/msg01083.html
The Security Considerations section that the intended BCP is all about
privacy. The Introduction section mentions "illegal purposes by
criminals". I would describe the problem as having different angles;
bad people could capture the information being exchanged and use it for
nefarious purposes, nation states [2] can capture the information and
use it to find out what the people are discussing.
I'm not sure if you're suggesting some change there but I think the
point you make above is already made in the (very short) draft in
which case repeating it wouldn't be that useful.
The draft is well-written. Given the catchy title
Thanks:-)
I am left to wonder
which parts of the document is polite fiction (a social scenario in
which all participants are aware of a truth, but pretend to believe in
some alternative version of events to avoid conflict or embarrassment).
In very simplistic terms the draft says:
"consensus to design protocols so as to mitigate the attack, where
possible."
Yep.
Quoting Martin Thomson: we trusted you; we were naive; never again.
Yeah, I like his draft too. I was quite tempted to AD-sponsor partly
to see how it irritates overly-process-oriented folks :-)
Cheers,
S.
Regards,
-sm
1. the continuing competitive attempt by two or more nations each to
have available to it more and more powerful weapons than the other(s).
2.
http://ir.elbitsystems.com/phoenix.zhtml?c=61849&p=irol-newsArticle&ID=1810121&highlight=