Thanks for the review, Bjoern.

Ted

On Fri, = Jan 9, 2015 at 5:08 PM, Bjoern Hoehrmann <derhoermi@gmx.net>= wrote:

* Ted Hardie wrote:
>The program and authors would appreciate review of
>draft-iab-privsec-confidentiality-threat-01.txt (
>http://www.ietf.org/id/draft-iab-privsec-conf= identiality-threat-01.txt).
>Note that the text on mitigations to these threats has been split into = a
>second document which is forthcoming.=C2=A0 Reviews can be sent to this= list or
>the authors.

Mostly editorial things on sections 1-3:

Typo in Section 1 "attacket".

In Section 2 I think the example for "Infererence" should be repl= aced by
a much simpler one.

I am not happy with using "Observation" with the specified meanin= g in
this context. The word usually refers to the act, not the data, and here it may be easy to confuse it with, say, targeted surveillance as part of a justice system, perhaps especially for non-native readers. I encourage trying to find an alternative term.

The definition for "Collaborator" seems to lack "deliberatel= y". It might
be a good idea to strike "(keys or data)" since it does not seem = to
clarify anything, and invites misinterpretations (say, keys and data are bad, but "meta data" is okay).

The definition for "Unwitting Collaborator" as though an "Un= witting
Collaborator" is a "Collaborator". That seems incorrect to m= e.

I do not think "Key Exfiltration" depends on the presence of a "collaborator". Same for "Content Exfiltration".

I think Section 3 would benefit from a short preface that explains, as
the section title suggest, this is an "idealised" description, an= d
explains how this is useful. Right now the section jumps right into
describing something that is extremely implausible without qualifiers,
and many readers might be unfamiliar with such descriptions.

The claim that "The use of encryption to protect confidentiality is generally enough to prevent direct observation" seems incorrect or at<= br> least misleading to me (it might prevent direct observation of the
unencrypted plaintext, but not all direct observation; that should be
explicit).

Typo "privascy" in 3.2.

Putting "We note with some alarm ..." at the end of a long paragr= aph
is probably not a good idea as it may easily be missed.

In section 3.3 it's not immediately clear whether in "To illustrat= e how
capable the attacker is even given its limitations" 'the attacker&= #39; is
the idealised attacker introduced at the beginning, or some other one.
The two "even"s make the first (very long) sentence hard to read = for me.

In section 3.3.2, given that the document already noted geoip databases, the reverse-dns example seems more harmful than useful.

Section 3.3.7 should probably note that Wifi MACs have already been
extensively mapped to locations, and I assume similar databases that
map ethernet MACs to user identities also exist.
--
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de
D-10243 Berlin =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.bjoernsworld.de
=C2=A0Available for hire in Berlin (early 2015)=C2=A0 =C2=B7 http://www.websitedev.de/

--047d7b2e127f7fc153050c774a00-- From nobody Mon Jan 12 13:59:48 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2866C1A87E6 for ; Mon, 12 Jan 2015 13:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXC_bInqRzj9 for ; Mon, 12 Jan 2015 13:59:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A9B1A6F0A for ; Mon, 12 Jan 2015 13:59:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7F140BEDF for ; Mon, 12 Jan 2015 21:59:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psc9i5-4dWus for ; Mon, 12 Jan 2015 21:59:38 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.41.61.73]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4958ABEDC for ; Mon, 12 Jan 2015 21:59:38 +0000 (GMT) Message-ID: <54B443CA.4020505@cs.tcd.ie> Date: Mon, 12 Jan 2015 21:59:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: perpass References: <20150112214918.14918.60258.idtracker@ietfa.amsl.com> In-Reply-To: <20150112214918.14918.60258.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150112214918.14918.60258.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [perpass] Fwd: [lisp] I-D Action: draft-ietf-lisp-crypto-00.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jan 2015 21:59:47 -0000 FYI, for those of you interested in LISP and security, I'm sure Dino would welcome comments Cheers, S. -------- Forwarded Message -------- Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-00.txt Date: Mon, 12 Jan 2015 13:49:18 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: lisp@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF. Title : LISP Data-Plane Confidentiality Author : Dino Farinacci Filename : draft-ietf-lisp-crypto-00.txt Pages : 11 Date : 2015-01-12 Abstract: This document describes a mechanism for encrypting LISP encapsulated traffic. The design describes how key exchange is achieved using existing LISP control-plane mechanisms as well as how to secure the LISP data-plane from third-party surveillance attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-crypto-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp From a.mohaisen@gmail.com Tue Jan 13 10:41:35 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071F11A90BC for ; Tue, 13 Jan 2015 10:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5bopDZ7uIwm for ; Tue, 13 Jan 2015 10:41:31 -0800 (PST) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 667471A90A5 for ; Tue, 13 Jan 2015 10:41:31 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id rp18so4434874iec.11 for ; Tue, 13 Jan 2015 10:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=EKjb6A3JDWVhArBqHjR35x6Lg4Aio6e2Rb5tyYV1wic=; b=OmQKOy6oaaVAw50TXPAzms53mSAly1qcPHOfpW88LJexbiXOZv+1v6/75sLz4u2hE2 dRW1PnI5ZSujos9KwLgHTlgfwfSBI9g+0dOGdxtmONXd+AGCX7CXlccBABG0HwwoQFUq /xasdanrABdaLFpzVrWbH+0Xeifkzf9vNkuBJzYrkvF2YtTLV+QzmLw6veRSkCCj3Tuc VUl/xDHty/yBISEbu/OOfbxa881u65Y9GXI5/DCXDfnj5NPR7JtZJHmYL7cSwlINYKLN knhCmp2M0hBn+NF+RGTVpJYo9kvpQNenF5lIvlVF0+4DybqY8IMOntjBEOouWgLeKjcI 75iQ== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr1000960igz.42.1421174490599; Tue, 13 Jan 2015 10:41:30 -0800 (PST) Received: by 10.50.51.196 with HTTP; Tue, 13 Jan 2015 10:41:30 -0800 (PST) Date: Tue, 13 Jan 2015 13:41:30 -0500 Message-ID: From: Aziz Mohaisen To: ted.ietf@gmail.com Content-Type: multipart/alternative; boundary=047d7bdca448ad183d050c8cf879 Archived-At: X-Mailman-Approved-At: Tue, 13 Jan 2015 10:52:14 -0800 Cc: perpass@ietf.org Subject: Re: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 18:42:20 -0000 --047d7bdca448ad183d050c8cf879 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=9Chybrid adversary=E2=80=9D. 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 =E2=80=9CIdealized Pervasive Passive Attacker=E2=80= =9D is a bit confusing; on the one hand, it is understood that the attacker does not actively seek to gain access to users data =E2=80=94 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 =E2=80=94 e.g., stat= ed in the last paragraph on page 3. Even when a vulnerability exists in such intermediaries, the adversary would have to actively use the vulnerability =E2=80=94 by compromise, as stated towards the end of page 3 =E2=80=94 in o= rder 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=E2=80=99t traditionally considered in the IETF community or the commun= ity 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 Date: 9 January 2015 at 16:19 Subject: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt To: "" 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 --047d7bdca448ad183d050c8cf879 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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 men= tioned to highlight the idealized pervasive passive adversary (as defined i= n the document) seem to share some elements of an active attack, suggesting= that this perhaps should be called a =E2=80=9Chybrid adversary=E2=80=9D. M= ost 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 confidenti= ality, with multiple suggested techniques. While mentioned later in the doc= ument, 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 passi= ve 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 =E2=80=9C= Idealized Pervasive Passive Attacker=E2=80=9D is a bit confusing; on the on= e hand, it is understood that the attacker does not actively seek to gain a= ccess to users data =E2=80=94 by the virtue of being passive. On the other = hand, at the same time the attacker can observe data in intermediaries by c= ompromising those intermediaries =E2=80=94 e.g., stated in the last paragra= ph on page 3. Even when a vulnerability exists in such intermediaries, the = adversary would have to actively use the vulnerability =E2=80=94 by comprom= ise, as stated towards the end of page 3 =E2=80=94 in order to be able to o= bserve contents in the intermediary. To this end, the definition seems to m= ix 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]=C2=A0 -> this does = not seem (to me) to imply a passive monitoring attack. If you get the coope= ration 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 expla= nation towards the end of the page concerning passive attacks is ad-hoc, an= d misses the point that the main feature of passive attacks is that they ar= e non-evasive.

Page 12:
- [These attacks all rely on a colla= borator providing the attacker with some information, either keys or data.= =C2=A0 These attacks have not traditionally been considered in security ana= lyses of protocols, since they happen outside of the protocol.] -> I am = not sure if you mean those attacks aren=E2=80=99t traditionally considered = in the IETF community or the community at large. This statement should be r= emoved if it means the community at large (including academic), since they = are widely studied in the analysis of protocols. Related terms covering som= e of those attacks include:

=C2=A0=C2=A0 =C2=A0- partial key exposu= re
=C2=A0=C2=A0 =C2=A0- related key attacks
=C2=A0=C2=A0 =C2=A0- acti= ve corruption (related to secure multiparty computation; e.g., Hirt and Mau= rer from Crypto 2001)

These are heavily studied in the context of si= de-channel and timing attacks (e.g., RSA crypto-analysis). Maybe the IETF c= ommunity 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 analy= sis 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.

T= ypos and editorial:
page 1:
- attacket -> attacker
page 2: - To build a thread model -> threat model
page 4: =C2=A0
- develo= ped map IP addresses ->=C2=A0 developed to map IP addresses
- privasc= y reasons ->=C2=A0 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 t= hat can operate at line speed -> require processing hardware that can op= erate at line speed
- the attacker need only interact -? the attacker ne= eds only to interact

page 15:
- interactions may real -> inter= actions are may be real

From: Ted Hardie <ted.ietf@gmail.com>
Date: 9 January 2015 a= t 16:19
Subject: [perpass] Review request: draft-iab-privsec-confidentia= lity-threat-01.txt
To: "<per= pass@ietf.org>" <perpass= @ietf.org>

The program and authors would appreciate revie= w of draft-iab-privsec-confidentiality-threat-01.txt (http://www.ie= tf.org/id/draft-iab-privsec-confidentiality-threat-01.txt).=C2=A0 Note = that the text on mitigations to these threats has been split into a second = document which is forthcoming.=C2=A0 Reviews can be sent to this list or th= e authors.

Thanks,

Ted Hardie

--047d7bdca448ad183d050c8cf879-- From nobody Tue Jan 13 12:47:33 2015 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AA51ACF03 for ; Tue, 13 Jan 2015 12:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWGZtGqSyfTR for ; Tue, 13 Jan 2015 12:47:25 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532161ACEF9 for ; Tue, 13 Jan 2015 12:47:25 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z20so5358444igj.4 for ; Tue, 13 Jan 2015 12:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hWOOtu0sXn75ugEdhQKBXWEblBk1PCWRJb/l9bFzfis=; b=qsF4MgjFfOiyEtWeZMzyDTUpUssBnmBFFnTOiZt8bKcfOkej8jV+5RL+SW3lh+wFhD W1CisciKsjuFs0y3KgXRxK+1TwLhY+E5Wt988yUyYJTwXvRbPYLj7GfA6ZkjJYHHQT3t BQfWK1PFbjCaSF3otcSwNBYr7icm/QXHJh1b5wGI7fKEk6Db+G8ai8tPhH/bBPZrHGeQ kZ++cANbbya3QLXby4hELytEHIkNnqhuAPIDm/1ALrdrk+sbe1mQ1M5WZVWuCAIqg9Rg C8JJUSemeOR1vVIJUD2wYLTVdKAGaN2sV1LOhsVYqW/ABi/JCUEqtmoeE+omFZFBZTOc 7RLA== MIME-Version: 1.0 X-Received: by 10.107.160.135 with SMTP id j129mr255316ioe.91.1421182043616; Tue, 13 Jan 2015 12:47:23 -0800 (PST) Received: by 10.50.51.196 with HTTP; Tue, 13 Jan 2015 12:47:23 -0800 (PST) Date: Tue, 13 Jan 2015 15:47:23 -0500 Message-ID: From: Aziz Mohaisen To: Ted Hardie , perpass@ietf.org Content-Type: multipart/alternative; boundary=001a1140ef02defcf6050c8ebaee Archived-At: Subject: Re: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 20:47:31 -0000 --001a1140ef02defcf6050c8ebaee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=9Chybrid adversary=E2=80=9D. 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 =E2=80=9CIdealized Pervasive Passive Attacker=E2=80= =9D is a bit confusing; on the one hand, it is understood that the attacker does not actively seek to gain access to users data =E2=80=94 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 =E2=80=94 e.g., stat= ed in the last paragraph on page 3. Even when a vulnerability exists in such intermediaries, the adversary would have to actively use the vulnerability =E2=80=94 by compromise, as stated towards the end of page 3 =E2=80=94 in o= rder 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=E2=80=99t traditionally considered in the IETF community or the commun= ity 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 Date: 9 January 2015 at 16:19 Subject: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt To: "" 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 --001a1140ef02defcf6050c8ebaee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= The document provides an interesting view of the threat posed by pervasive = monitoring and tries to formalize a threat model around the problem. Howeve= r, the model still lacks rigor, and examples mentioned to highlight the ide= alized pervasive passive adversary (as defined in the document) seem to sha= re some elements of an active attack, suggesting that this perhaps should b= e called a =E2=80=9Chybrid adversary=E2=80=9D. Most of my comments in the f= eedback 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 s= hould be specified to be indirect, and not just any information obtained th= rough analysis (e.g., summary)

Page3:
- The first paragraph in se= ction 3.1 does not take into account the effort in DPRIVE WG, and its chart= er that provides a requirement of DNS confidentiality, with multiple sugges= ted techniques. While mentioned later in the document, the attack on the sa= id example of DNS when such efforts are utilized is only limited in the giv= en settings.

- (Page 2-3) The word passive is somewhat misleading. = Capabilities listed under the passive pervasive attack include elements whe= re a system is compromised; surely compromising a system is an active act a= nd not passive. The description of the =E2=80=9CIdealized Pervasive Passive= Attacker=E2=80=9D is a bit confusing; on the one hand, it is understood th= at the attacker does not actively seek to gain access to users data =E2=80= =94 by the virtue of being passive. On the other hand, at the same time the= attacker can observe data in intermediaries by compromising those intermed= iaries =E2=80=94 e.g., stated in the last paragraph on page 3. Even when a = vulnerability exists in such intermediaries, the adversary would have to ac= tively use the vulnerability =E2=80=94 by compromise, as stated towards the= end of page 3 =E2=80=94 in order to be able to observe contents in the int= ermediary. 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]=C2=A0 -> 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 incl= ude a flavor of active attacks. Perhaps, instead of creating a confusion ar= ound the concept of pervasive (passive) attacks, naming them as such (activ= e, 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 th= e main feature of passive attacks is that they are non-evasive.

Page 12:
- [These attacks all rely on a collaborator providing the atta= cker with some information, either keys or data.=C2=A0 These attacks have n= ot traditionally been considered in security analyses of protocols, since t= hey happen outside of the protocol.] -> I am not sure if you mean those = attacks aren=E2=80=99t traditionally considered in the IETF community or th= e community at large. This statement should be removed if it means the comm= unity at large (including academic), since they are widely studied in the a= nalysis of protocols. Related terms covering some of those attacks include:=

=C2=A0=C2=A0 =C2=A0- partial key exposure
=C2=A0=C2=A0 =C2=A0- = related key attacks
=C2=A0=C2=A0 =C2=A0- active corruption (related to s= ecure multiparty computation; e.g., Hirt and Maurer from Crypto 2001)
These are heavily studied in the context of side-channel and timing attac= ks (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 mecha= nism, what matters from a security/privacy analysis point of view is the st= ate 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: =C2=A0
- developed map IP addresses ->= =C2=A0 developed to map IP addresses
- privascy reasons ->=C2=A0 priv= acy reasons

page 5:
- a good sampling -> a good sample?
page 8:
- thorugh -> through?

page 10:
- his analysis som= etimes -> 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 sp= eed -> require processing hardware that can operate at line speed
- t= he attacker need only interact -? the attacker needs only to interact
page 15:
- interactions may real -> interactions are may be real

From: Ted Hardie <ted.ietf@gmail.com>
Date: 9 January 2015 at 16:19<= br>Subject: [perpass] Review request: draft-iab-privsec-confidentiality-thr= eat-01.txt
To: "<perpass@ietf.org>" <perpass@ietf.org>

The program and au= thors would appreciate review of draft-iab-privsec-confidentiality-threat-0= 1.txt (http://www.ietf.org/id/draft-iab-privsec-c= onfidentiality-threat-01.txt).=C2=A0 Note that the text on mitigations = to these threats has been split into a second document which is forthcoming= .=C2=A0 Reviews can be sent to this list or the authors.

Thanks,
=
Ted Hardie

--001a1140ef02defcf6050c8ebaee--