Subject: [perpass] Review request: draft-iab-privsec-confidentiality-threat-01.txt

From: Ted Hardie <[email-masked]>
Date: Fri, 9 Jan 2015 13:19:16 -0800

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

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 10 Jan 2015 02:08:52 +0100

>second document which is forthcoming.  Reviews can be sent to this list or

Mostly editorial things on sections 1-3:

Typo in Section 1 "attacket".

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

I am not happy with using "Observation" with the specified meaning 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 "deliberately". 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 "Unwitting
Collaborator" is a "Collaborator". That seems incorrect to me.

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, and
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
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 paragraph
is probably not a good idea as it may easily be missed.

In section 3.3 it's not immediately clear whether in "To illustrate how
capable the attacker is even given its limitations" 'the attacker' 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örn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 12 Jan 2015 08:49:34 -0800

Thanks for the review, Bjoern.

Ted