The document provides an interesting view of the threat posed by pervasive
monitoring and tries to formalize a threat model around the problem.
However, the model still lacks rigor, and examples mentioned to highlight
the idealized pervasive passive adversary (as defined in the document) seem
to share some elements of an active attack, suggesting that this perhaps
should be called a “hybrid adversary”. Most of my comments in the feedback
below are on this point, and cite parts of the document where this issue is
clear. This feedback also provides some typos that need be fixed (towards
the end of the feedback).
I hope these comments/suggestions help.
Aziz
page 2:
Inference should be specified to be indirect, and not just any information
obtained through analysis (e.g., summary)
Page3:
- The first paragraph in section 3.1 does not take into account the effort
in DPRIVE WG, and its charter that provides a requirement of DNS
confidentiality, with multiple suggested techniques. While mentioned later
in the document, the attack on the said example of DNS when such efforts
are utilized is only limited in the given settings.
- (Page 2-3) The word passive is somewhat misleading. Capabilities listed
under the passive pervasive attack include elements where a system is
compromised; surely compromising a system is an active act and not passive.
The description of the “Idealized Pervasive Passive Attacker” is a bit
confusing; on the one hand, it is understood that the attacker does not
actively seek to gain access to users data — by the virtue of being
passive. On the other hand, at the same time the attacker can observe data
in intermediaries by compromising those intermediaries — e.g., stated in
the last paragraph on page 3. Even when a vulnerability exists in such
intermediaries, the adversary would have to actively use the vulnerability
— by compromise, as stated towards the end of page 3 — in order to be able
to observe contents in the intermediary. To this end, the definition seems
to mix both active and passive attackers.
Page 6:
- The last point in section 3.3.2. does not seem to follow the
aforementioned attacker model. [In many jurisdictions, Internet Service
Providers (ISPs) are required to provide identification on a case by case
basis of the "owner" of a specific IP address for law enforcement
purposes] -> this does not seem (to me) to imply a passive monitoring
attack. If you get the cooperation of an ISP, that is no longer a passive
attack.
Page 9:
- Most of those attacks include a flavor of active attacks. Perhaps,
instead of creating a confusion around the concept of pervasive (passive)
attacks, naming them as such (active, hybrid, etc) would be a better idea.
The explanation towards the end of the page concerning passive attacks is
ad-hoc, and misses the point that the main feature of passive attacks is
that they are non-evasive.
Page 12:
- [These attacks all rely on a collaborator providing the attacker with
some information, either keys or data. These attacks have not
traditionally been considered in security analyses of protocols, since they
happen outside of the protocol.] -> I am not sure if you mean those attacks
aren’t traditionally considered in the IETF community or the community at
large. This statement should be removed if it means the community at large
(including academic), since they are widely studied in the analysis of
protocols. Related terms covering some of those attacks include:
- partial key exposure
- related key attacks
- active corruption (related to secure multiparty computation; e.g.,
Hirt and Maurer from Crypto 2001)
These are heavily studied in the context of side-channel and timing attacks
(e.g., RSA crypto-analysis). Maybe the IETF community needs to have more
exposure to those attacks, but they are already studied previously.
A secondary point: while the attacks mentioned on page 12 concern a
mechanism, what matters from a security/privacy analysis point of view is
the state of the matter upon the exposure of the keys/data/etc. (or parts
of them), and how that can be used to launch an attack on the security of a
system/protocol or the privacy of a user.
Typos and editorial:
page 1:
- attacket -> attacker
page 2:
- To build a thread model -> threat model
page 4:
- developed map IP addresses -> developed to map IP addresses
- privascy reasons -> privacy reasons
page 5:
- a good sampling -> a good sample?
page 8:
- thorugh -> through?
page 10:
- his analysis sometimes -> This analysis sometimes
page 14:
- receiving it -> receive it?
- as an transmitter .. -> as a transmitter as well as [a] receiver
- require processing hardware to that can operate at line speed -> require
processing hardware that can operate at line speed
- the attacker need only interact -? the attacker needs only to interact
page 15:
- interactions may real -> interactions are may be real
From: Ted Hardie <[email protected]>
Date: 9 January 2015 at 16:19
Subject: [perpass] Review request:
draft-iab-privsec-confidentiality-threat-01.txt
To: "<[email protected]>" <[email protected]>
The program and authors would appreciate review of
draft-iab-privsec-confidentiality-threat-01.txt (
http://www.ietf.org/id/draft-iab-privsec-confidentiality-threat-01.txt).
Note that the text on mitigations to these threats has been split into a
second document which is forthcoming. Reviews can be sent to this list or
the authors.
Thanks,
Ted Hardie
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
