From nobody Thu Aug 27 04:27:45 2020 Return-Path: X-Original-To: pearg@ietfa.amsl.com Delivered-To: pearg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152AA3A0BC5 for ; Thu, 27 Aug 2020 04:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=MZcho5lY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PZxxidSA 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 het-16CM5OoY for ; Thu, 27 Aug 2020 04:27:42 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFBF3A0BBE for ; Thu, 27 Aug 2020 04:27:41 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 180AA5C02A4 for ; Thu, 27 Aug 2020 07:27:41 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 27 Aug 2020 07:27:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=z+dH86B s6COk4EiECxHp2nomVdneogsyENu07RjgaRI=; b=MZcho5lYxYKq3bxLaasumOt S5/MalWv/I8RWGt9zoGf3dtp9uzPmhFRGkQCTUPN+2YaYUb8KCwkfCSq2oZsCe/9 9zaSm6SuOF8RvcESOTswbrbvU5ifl02NJ2WtqsZNjbhfCQ67h55OAAHGHsjajYbT +NsOwg0w2YyQXn1nOaxBXuQN3UgyOSe7uVzw3Ho8Z4kEl6GV3oKWePWoHvOt9w1R ixcmaCQzfyh5psBB4F93AubbbNIxF7Xwm2RCCqRh03kAps0r/hN/PLhBEhaQdPrV jjC6F4bV8efLv7G0bw0OrBgRE94gAPaJ4u/emUhpGnp78uV7OLnE22MWsQx5UqQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=z+dH86 Bs6COk4EiECxHp2nomVdneogsyENu07RjgaRI=; b=PZxxidSAuw0fO6OJw4XkWT D9fgvI/sm+lUQ72SAbF7QKrY+58e6QmQ5BUeH/ISx6ow4yxwnKH++EwLMUNLZlr2 4JOIt9dnMAlnQd1UA2DoDx1tVYKBWl9/tyvqXS37FRPfdLvx4SgIwBBZ8GQuvXem BXy0qqGe/Oqe1uPGAJ4qMpWZkaDBoIoKyr+1zBb0E3idmQ1Uf+D4lpbIZ9ROVy9i y3LYOcmP7vUPMYkoNr5ob57l64y4JV/qPGKm6k+EVLpgqJN7oZV4B6h+nVd6XKy1 7QlkH3RgMtZLq6H/ayR5rxM24FPa/zfKFdgZMVc0u0d0QdmNI3b+K6FfJEChoTnw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeekfeffhefhke etfedutdeiheegvdekteetudfgheetgfffieeiveeiheeluedtleenucffohhmrghinhep ihgvthhfrdhorhhgpdhirhhtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtgho mh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BFCA3180137; Thu, 27 Aug 2020 07:27:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: In-Reply-To: <6DEE1D7C-0C69-4446-AC93-E47D8862BEC7@sinodun.com> References: <6DEE1D7C-0C69-4446-AC93-E47D8862BEC7@sinodun.com> Date: Thu, 27 Aug 2020 21:27:20 +1000 From: "Bron Gondwana" To: pearg@irtf.org Content-Type: multipart/alternative; boundary=1d6829bc73114d14915a831cf0752091 Archived-At: Subject: Re: [Pearg] =?utf-8?q?Call_for_Adoption=3A_Personal_Information_Tagg?= =?utf-8?q?ing_for_Logs_=28draft-rao-pitfol-02=29?= X-BeenThere: pearg@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Privacy Enhancements and Assessment Proposed RG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 11:27:44 -0000 --1d6829bc73114d14915a831cf0752091 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 actiona= ble - it has an example, but otherwise doesn't clearly articulate how an= d 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 entre= aty to have an obfuscation layer. If this is supposed to interoperate b= etween systems by different vendors or within different scopes of contro= l, it should be more rigorous in defining exact structure. I was also confused by the table of specific items and levels of protect= ion required - it seems both incomplete and somewhat arbitrary in the se= nsitivity levels given to different fields - and definitely the final fo= rm 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 h= ave: * name:"CONTAINSPII_personName:Joe Blogs" from that table be written to = the log - something like that - prefixing the value such that the format= s 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 a= voids encoding specific PII levels into the log format itself and keeps = the tagging with the value through many more conversions (though I do ad= mit it fails on non-string fields). I may be missing something here tho= ugh. Cheers, Bron. On Mon, Aug 17, 2020, at 19:20, Sara Dickinson wrote: > Hi All,=20 >=20 > This email starts a two week Call for Adoption of the draft 'Personal = Information Tagging for Logs=E2=80=99. The draft is available at: https:= //tools.ietf.org/html/draft-rao-pitfol-02 >=20 > Please review this draft to see if you think it is suitable for adopti= on by PEARG and send comments to the list, clearly stating your view. >=20 > This call for adoption ends on 31st August 2020. >=20 > Sara.=20 > --=20 > Pearg mailing list > Pearg@irtf.org > https://www.irtf.org/mailman/listinfo/pearg >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --1d6829bc73114d14915a831cf0752091 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
I support the adoption of this concept and this document.<= br>

A mini review:
With my developer hat on, I don= 't find the document particularly actionable - it has an example, but ot= herwise 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 entr= eaty to have an obfuscation layer.  If this is supposed to interope= rate 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 i= n the sensitivity levels given to different fields - and definitely the = final form of this document will need to refer to an IANA registry or so= me other location at which a canonical list of known items can be found.=

Regarding that format - if I was designing something lik= e 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.

An= ything doing redaction would redact every unknown CONTAINSPII_{Name}, an= d have a lookup table to decide whether to redact known items.  Thi= s avoids encoding specific PII levels into the log format itself and kee= ps 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.

On Mon, Aug 17, 2020, at 19:20, S= ara Dickinson wrote:
Hi All, 

This em= ail starts a two week Call for Adoption of the draft 'Personal Informati= on Tagging for Logs=E2=80=99. 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 ad= option ends on 31st August 2020.

Sara. 
-- 
Pearg mailing list


--
&nb= sp; Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fast= mailteam.com


--1d6829bc73114d14915a831cf0752091--