Subject: [Pearg] Call for Adoption: Personal Information Tagging for Logs (draft-rao-pitfol-02)

From: Sara Dickinson <[email-masked]>
Date: Mon, 17 Aug 2020 10:20:03 +0100

Hi All, 

This email starts a two week Call for Adoption of the draft 'Personal Information Tagging for Logs’. The draft is available at: https://tools.ietf.org/html/draft-rao-pitfol-02

Please review this draft to see if you think it is suitable for adoption by PEARG and send comments to the list, clearly stating your view.

This call for adoption ends on 31st August 2020.

Sara.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Aug 2020 13:12:11 +0100

Hiya,

On 17/08/2020 10:20, Sara Dickinson wrote:
> Hi All,
> 
> This email starts a two week Call for Adoption of the draft 'Personal
> Information Tagging for Logs’. The draft is available at:
> https://tools.ietf.org/html/draft-rao-pitfol-02
> 
> Please review this draft to see if you think it is suitable for
> adoption by PEARG and send comments to the list, clearly stating your
> view.

I read the draft and support adoption - it's a good
topic for the RG and an ok starting point.

I've two high level comments:-

- I hope that the work planned here will include
some testing of the efficacy of the approach being
proposed and not just defining something in the
hope that it might help. In particular I think this
work requires that there exist some good way(s) to
identify what needs to be tagged, and I'm not sure
if that's true today. IOW the existence of an
effective way to spot what needs tagging, without
too many errors, is a prerequisite for this work to
be useful, so I'd hope the intent is to demonstrate
that before the draft became an RFC.

- I'm not really convinced that static or semi-static
sensitivity classifications are a good idea. ISTM that
privacy leaks are often cumulative so while a single
MAC address in a single log entry might be at level
4 (as proposed in the document), if that same MAC
address appears in enough places over enough time,
then it is really far more sensitive, esp. if it is
correlated anywhere with e.g. a name. I don't have a
better proposal myself though, but that seems like a
good thing for the RG to consider.

Cheers,
S.

---

From: tirumal reddy <[email-masked]>
Date: Thu, 27 Aug 2020 14:24:33 +0530

I support adoption of the draft.

-Tiru

On Mon, 17 Aug 2020 at 14:50, Sara Dickinson <[email-masked]> wrote:

> Please review this draft to see if you think it is suitable for adoption
> by PEARG and send comments to the list, clearly stating your view.
>
> --
> Pearg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/pearg
>

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 27 Aug 2020 09:55:13 +0100

Hi All, 

This is just a reminder that the CFA on this draft ends next Monday (31st August). We’ve only had one response so far (thank you Stephen!) so please consider reviewing and providing comments!

Best regards

Sara. 

> On 17 Aug 2020, at 10:20, Sara Dickinson <[email-masked]> wrote:
> 
> Hi All, 
>

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 27 Aug 2020 11:02:38 +0200

I support adoption of this draft. I think this could be extremely useful in the production and usage of datasets based on logs.

Best,

Niels

On 8/27/20 10:54 AM, tirumal reddy wrote:
> On Mon, 17 Aug 2020 at 14:50, Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi All,
> 
>     [email-masked] <mailto:[email-masked]>

-- 
Niels ten Oever
Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam
Postdoctoral Scholar (abd) - Communications Department - Texas A&M University
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 27 Aug 2020 11:30:32 +0200

i support adoption of this draft.

/a

-- 
^\...~...~...~...~...~.../^
Amelia Andersdotter
IETF SHMOO WG Co-Chair
https://datatracker.ietf.org/group/shmoo/about/

Director of Strategic Initiatives, CENTR
www.centr.org
^\...~...~...~...~...~.../^

---

From: "Bron Gondwana" <[email-masked]>
Date: Thu, 27 Aug 2020 21:27:20 +1000

I support the adoption of this concept and this document.

A mini review:

With my developer hat on, I don't find the document particularly actionable - it has an example, but otherwise doesn't clearly articulate how and what to store.

This level of specification is fine if you control all the parts of the system, but at that point this document collapses just being to an entreaty to have an obfuscation layer.  If this is supposed to interoperate between systems by different vendors or within different scopes of control, it should be more rigorous in defining exact structure.

I was also confused by the table of specific items and levels of protection required - it seems both incomplete and somewhat arbitrary in the sensitivity levels given to different fields - and definitely the final form of this document will need to refer to an IANA registry or some other location at which a canonical list of known items can be found.

Regarding that format - if I was designing something like this I would have:
* name:"CONTAINSPII_personName:Joe Blogs" from that table be written to the log - something like that - prefixing the value such that the formats didn't change at all, and the tagging stayed with the value.

Anything doing redaction would redact every unknown CONTAINSPII_{Name}, and have a lookup table to decide whether to redact known items.  This avoids encoding specific PII levels into the log format itself and keeps the tagging with the value through many more conversions (though I do admit it fails on non-string fields).  I may be missing something here though.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]