* 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-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.
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 protected] · 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/ _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
