Hiya,
On 12/31/2013 07:02 PM, Rene Struik wrote:
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).
Sorry - what text suggests a binary approach? Please do give
quotes, as that is not the intent, and nor is it expressed.
In fact the draft says:
"The IETF will work to mitigate the
technical parts of the pervasive monitoring threat, just as we do for
other protocol vulnerabilities."
I really don't see how that can be mis-interpreted as a
"binary" approach. Can you explain?
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.
No. We are not defining pervasive monitoring as being purely passive,
since it is not. And nor is it an active attack entirely. So its
correct that the definition is that broad and differs from either
passive or active attacks.
I think a perhaps lot of your other comments hang on this
misunderstanding. But I'll comments on bits of those below. But
what you call a misnomer is deliberate, and is needed IMO.
I'd welcome a better definition if we can find one.
(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).
The active aspect is also a part of pervasive monitoring as
defined here, and needs to be considered as such. For example,
if an RSA private key is exfiltrated via an active attack in
order to later decrypt non-PFS ciphertext. (As in the Belgacom
case perhaps.) That is part of the pervasive monitoring
attack, but is not well described as either passive nor active.
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"?
No. It would be wrong to only consider pervasive monitoring as
a passive attack as that is not the case.
I think our conceptions of passive and active have in fact held
us back to an extent in that they may have made us less likely
to recognise the potential for the pervasive monitoring attack
which mixes both approaches and at scale.
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.
No, the main purpose of that paragraph is to empahasise that
the IETF don't need to take a position on the morality or
otherwise of e.g. specific NSA or GCHQ motivations. We can and
do say that their actions are an attack, but we do not say that
their motivations are good, bad or indifferent.
That is necessary so that when someone misinterprets the draft
as saying that "the IETF says that NSA are bad" they can be
corrected by pointing at this text.
The text in this draft *will* be deliberately misinterpreted
by some for their own ends so this really is needed.
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
"should always have been" is correct from a security and privacy
perspective. But it is clearly the case that such consideration has
not been a typical part of current or past practice.
Hence the need for this BCP.
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.
Sigh. "Single quest" is a very weird mis-reading of the draft.
See the text quoted above. I honestly don't get how you end up
thinking that.
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 message was not in relation to this draft. I don't know what
you mean in quoting it sorry. Can you clarify how it relates to
this draft?
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.
I have to say that the above seems to me pretty unclear in comparison
to the current text. (But I would think that of course:-)
4) Section 2, 2nd and 3rd para, seems to be a somewhat hidden admission
"Hidden" is not what I think. I think we have failed in some
respects, and generally not done so well in respect of privacy.
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.
Sorry, I don't get what your comment is getting at.
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.
I wouldn't call it an "admission". Again though, I'm not clear
if you're asking for some change or not.
Cheers,
S.
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(_at_)ietf(_dot_)org mailing lists by 2013-12-31. Exceptionally,
comments may be
sent to iesg(_at_)ietf(_dot_)org 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.