Thanks for the review, Bjoern. Ted
On Fri, Jan 9, 2015 at 5:08 PM, Bjoern Hoehrmann <derhoe...@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-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:bjo...@hoehrmann.de · 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 perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass
