Dear colleagues:
While I do agree with some of the underlying sentiments of the draft, I
am not that happy with the somewhat sloppy exposition of the draft, in
particular to what problem one really wishes to address (see #1, #2
below). Moreover, I feel that the implicit suggestion of the draft that
one should take an almost binary approach to addressing passive attacks
may be detrimental at achieving a solid security architectural design
(it should be a proper balancing, rather than 0-1 thinking w.r.t. one of
many security architectural considerations).
In my mind, the draft needs to be more carefully written, so as to make
intent and grey scales of proposed design metrics clearer. More details
below.
Some technical comments:
1) In Section 1, 3rd para, the term "attack" (in the context of
pervasive monitoring) is too broadly defined: pervasive monitoring is
(an extreme form of) monitoring and, thereby, an attack form that has
been dubbed (decades ago) in the cryptographic literature as an attack
by a *passive* adversary. (The fact that this may happen on a massive
scale does not change its nature.) In the draft, though, one seems to
lump this together with other attack forms, where a passive adversary
may exploit insights gathered from passive attacks to subsequently
facilitate an active attack (witness the use of "to enforce the
opponent's will on the attacked party" in 3rd para, 3rd line or "that
subverts the intent of a communicator without the agreement of the
parties to the communication" in 3rd para, 6th line). The latter is an
*active* attack, which is not part of pervasive monitoring itself (but
only may take advantage of this). With passive attacks, in most cases
(e.g., when using wireless communications) the presence or absence of an
passive adversary cannot be distinguished. I would strongly suggest
using proper notions and avoiding confusing and ill-defined terms (for
definitions, see, e.g., Definition 12.15 of the Handbook of Applied
Cryptography (CRC Press, 1995)). Shouldn't one simply change the title
of Section 1 to the (somewhat obvious) statement "Pervasive monitoring
is Indistinguishable from a Passive Attack" or "Pervasive Monitoring
Cannot Be Distinguished From Non-Monitoring, So One Should Prepare For
the Worst"?
2) In Section 1, 4th para, if the intent of the draft is to also raise
awareness of active (pervasive) attacks, it should say so clearly and
not suggest, as it seems to do right now, that this is due to "pervasive
monitoring" (since, as already said, this is a misnomer). Here, again,
though, this is nothing new by itself: security services need to be in
place where the interests of communicating parties, including the
communicating networks used by these parties (and lurking adversaries
therein) are not aligned. I would suggest emphasizing, far more than
currently done, the role pervasive monitoring could play in paving the
way towards providing useful insight to make a subsequent (or
interactive) active attack more successful, since that seems to be one
of the underlying currents of the draft.
3) In Section 1, 1st para, it is stated that " [...] that this was an
attack that should be mitigated where possible via the design of
protocols that make pervasive monitoring significantly more expensive or
infeasible". While I wholeheartedly agree that protocol design should
include privacy-relevant objectives (such as hiding header info and
meta-data), to me it seems this should always have been in the security
services objective list with security and communication protocol design
and it is somewhat surprising to see that this apparently is something
new (or, do I read this in the wrong way?). Isn't the main change
between the pre-Snowden and post-Snowden era that one is now aware that
would should attach more weight to security objectives one may very well
have unrightfully ignored in the past??? I am really concerned that this
becomes now a single quest at the detriment of other security objectives
one may wish to cater to. After all, with security and communication
protocol design, one should balance different objectives according to
deployment scenario at hand and there are many, many considerations that
could play a role. To this point, I already expressed concern in an
email of September 6th (see
http://www.ietf.org/mail-archive/web/perpass/current/msg00099.html)
that, e.g., trying to avoid traffic analysis by making all frames the
same size would be disastrous for applications in a highly constrained
setting ("internet of things", "smart objects", and the-like); I also
epressed some other concerns with respect to binary thinking here (see
the link). I would therefore suggest to express the desire of IETF-88
somewhat more intelligently and stipulate, e.g., that protocol should
properly consider security objectives and weigh these and allow security
policy settings to be picked so as to, indeed, enable more privacy-aware
deployments. This is mostly a security policy issue, though, and should
less so be a fixed setting of a security protocol itself. One could dub
this "security policy agility" vs. "crypto agility" if one wishes....
(Note: TLS is an example of a somewhat unfortunate design here, where
one has no security policy agility to hide lots of parms in the protocol
flows at all). The main point of post-Snowded would then be that the
"security policy agility" should include the policy to enable privacy
protection to one's heart content.
4) Section 2, 2nd and 3rd para, seems to be a somewhat hidden admission
that, perhaps, IETF itself may in the past not have done as good a job
as it could have in considering and weighing all security objectives.
After all, notions of passive and active attacks have been around for
decades, but apparently some of this has been not taken too seriously
for a while, or would have been considered "too expensive" to
implementers or vested interests? It can hardly be considered news that,
e.g., if one does not use adequately secured packets, then visible parts
may be eavesdropped upon, etc. Right now, it reads as if one is
indignified even in case one sends entirely unsecured packets and that
this, surprise, surprise, may be vulnerable to attack. To some network
people, it may be considered news if protocol messages do not behave as
specified. To security people, this should be second nature: after all,
all networks and network components should be considered as gigantic
security engines, without constraint on actors on the communication channel.
5) Section 2, 5th para, seems to be an admission that protocol design
should intelligently weigh design objectives (e.g., so as not to rule
out monitoring for network monitoring purposes). So, if this means one
wishes to cater for "security policy agility" as I alluded to above, so
much the better.
Best regards, Rene
On 12/3/2013 12:48 PM, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Pervasive Monitoring is an Attack'
<draft-farrell-perpass-attack-02.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2013-12-31. Exceptionally, comments may be
sent to iesg@xxxxxxxx instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.
Abstract
The IETF has consensus that pervasive monitoring is a technical
attack that should be mitigated in the design of IETF protocols,
where possible.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/
IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-farrell-perpass-attack/ballot/
No IPR declarations have been submitted directly on this I-D.
--
email: rstruik.ext@xxxxxxxxx | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363