Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)
Peter Saint-Andre <stpeter@stpeter.im> Thu, 02 March 2017 18:08 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EBF1294EB; Thu, 2 Mar 2017 10:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stpeter.im header.b=whCiG8OX; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=l5uWvL9y
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 o34wmYjY7py3; Thu, 2 Mar 2017 10:08:48 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8931294CF; Thu, 2 Mar 2017 10:08:48 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 0DE842072E; Thu, 2 Mar 2017 13:08:48 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 02 Mar 2017 13:08:48 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=SiO5Q0y8ohOxXTt 7/I95g4rt//M=; b=whCiG8OX1KYZ/hmWXe7GI12gOY/VosVlWmj81cqjzG1Ntfj c59U0xexyMut2sg0gEh+Hr8dPv64e+FUo6AnFSXG9zirBLdCipWKtMA+HeTUppPs wijMkCjVQ960Hdus/H4HghiTTwdgHiyVCzQx4raIRh4I3EuT3c3yawuM10HA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= smtpout; bh=SiO5Q0y8ohOxXTt7/I95g4rt//M=; b=l5uWvL9yxJM4Mm/F0Xgt cyYt0Doy1TAHQGCnTlbvZxj61tHeggXeuVPm82B75Ob+UxJoiPuMSrtjesWypU4J meopyip7RYzw+RCA7UubqCKlXzSakoaczOnm57QEHEpVYN9sLofFFNXk/fCSp/0i /3Ntcs3SK3bbEpu49vSBt0I=
X-ME-Sender: <xms:r1-4WBYGj7kPQUZKILRHyXf1PFWO_HD8Ujr9aypTSS0rc0Km9923MA>
X-Sasl-enc: ZHJJ9mqIckh7HrXJVGjRiCQVxKqF69oFjNMmVPdsxnHf 1488478127
Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 2643E7E0EE; Thu, 2 Mar 2017 13:08:47 -0500 (EST)
To: John C Klensin <john-ietf@jck.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <148832863670.29552.9014381848292739838.idtracker@ietfa.amsl.com> <68d0ad57-9ba0-beb2-2fe4-2f036fce3e93@stpeter.im> <836b3132-def8-0534-487a-bc78b69ee82c@cs.tcd.ie> <BFFE81EB342F7B722E788428@PSB> <2cd348ce-1378-ddf7-574a-73283709999c@cs.tcd.ie> <9499477E8333E7F4AB7E0101@PSB> <cac6ea0e-ab9c-1add-3437-922f05c5b933@cs.tcd.ie> <73C38C9E8D1BC77A7A8F9707@PSB>
From: Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <3ccc5410-f216-a63b-ed95-d9a02280b0f7@stpeter.im>
Date: Thu, 02 Mar 2017 11:08:46 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <73C38C9E8D1BC77A7A8F9707@PSB>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/944hjYP1vPvvuRCv-cKyhURLifE>
Cc: draft-ietf-urnbis-rfc2141bis-urn@ietf.org, urn@ietf.org, The IESG <iesg@ietf.org>, urnbis-chairs@ietf.org, barryleiba@computer.org
Subject: Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 18:08:50 -0000
That seems like a fine path forward. I don't have anything else to add. On 3/2/17 10:16 AM, John C Klensin wrote: > Stephen, I edited your text to reflect the document's general > practice of describe documents and attaching the RFC citation > rather than using the reference anchor as a sentence object, > but, otherwise, done. > > I'm going to wait a few hours to see if anyone complains that > I've missed anything, then will compile and circulate the > working draft to this list. That should still give Peter time > to paste any alternate or additional text into the working draft > if he feels the inclination or need. > > thanks, > john > > > --On Thursday, March 2, 2017 16:57 +0000 Stephen Farrell > <stephen.farrell@cs.tcd.ie> wrote: > >> >> >> On 02/03/17 15:45, John C Klensin wrote: >>> Stephen, >>> >>> If you want to craft some text and tell us where to put it, >>> I'd appreciate it. Noting that there is already a template >>> requirement for security and privacy information and the DE >>> team is charged with reviewing those templates for >>> completeness, >> >> Sure. I'd suggest the following change in 6.4.4: >> >> OLD: >> >> o Various issues discussed in the guidelines for security >> considerations in RFCs [RFC3552] and the privacy >> considerations for Internet protocols [RFC6973]. >> >> NEW: >> >> o Various issues discussed in the guidelines for security >> considerations in RFCs [RFC3552] and the privacy >> considerations for Internet protocols [RFC6973]. In >> particular note the privacy considerations text in >> [RFC7254] which may provide a useful model for such >> cases. >> >> And adding 7254 as a reference as well. >> >> If Peter or someone wants to suggest more text, that'd also be >> fine by me. >> >> Cheers, >> S. >> >>> I >>> think it is important that such text be as extensive as needed >>> but no longer and, in particular, that it not add to the >>> redundancy that you and Alissa have complained about any more >>> than necessary. >>> >>> thanks, >>> john >>> >>> >>> --On Thursday, March 2, 2017 14:33 +0000 Stephen Farrell >>> <stephen.farrell@cs.tcd.ie> wrote: >>> >>>> >>>> Hi John, >>>> >>>> For context (that I'm sure isn't needed for some of you, >>>> but will nonetheless spell out just in case:-), as I'm >>>> an abstain ballot, I'm not blocking this, but I am happy >>>> to chat of course. >>>> >>>> That said, yes, I think it would be good and sufficient >>>> to highlight the need for privacy to be considered as >>>> part of evaluations here, and I'd also hope that the IESG >>>> when appointing DEs keep that in mind. I also agree that >>>> there's a danger here of trying to police things too >>>> much, hence my reference to rfc6919 and it's fine concept >>>> of "MUST (but we know you won't)" that is worth avoiding >>>> in any text we add about privacy. >>>> >>>> Anyway, yes I think a bit more text that emphasises that >>>> there can be (for some folks, unexpected) privacy issues >>>> here and a pointer to the example of rfc7254 should be >>>> fine. >>>> >>>> If it helps for me to try help craft a bit of text along >>>> those lines, I'm happy to help with that, but I'm also >>>> happy for the folks involved to just do that if they so >>>> choose. >>>> >>>> Cheers, >>>> S. >>>> >>>> On 02/03/17 13:35, John C Klensin wrote: >>>>> >>>>> >>>>> --On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell >>>>> <stephen.farrell@cs.tcd.ie> wrote: >>>>> >>>>>>> Perhaps you could clarify what some of your concerns are >>>>>>> here, above and beyond the use of URIs in general (after >>>>>>> all, a URN is a URI). Reading between the lines, I imagine >>>>>>> you might be worried that URNs within a particular URN >>>>>>> namespace (e.g., for U.S. Social Security Numbers or the >>>>>>> like) - once suitably resolved into one or more URLs - >>>>>>> might enable an attacker to determine a person's physical >>>>>>> location (e.g., via IP address) or actual identity (e.g., >>>>>>> a pseudonym could "resolve" to a real name). Are these >>>>>>> guesses on the mark? >>>>>> >>>>>> Yep. Perhaps things like including an IMSI or IMEI (or >>>>>> values easily correlated with such) in the NSS part is >>>>>> what it'd useful to call out. I'm not sure if there are >>>>>> real examples of such in existing URNs but if there were >>>>>> it'd be a fine thing to note that including such things >>>>>> imposes (often unmet) requirements for e.g. confidentiality >>>>>> on protocols and applications that use those URNs. If >>>>>> may also be useful to say that things like hashing the >>>>>> privacy sensitive value before inclusion in the URN don't >>>>>> prevent correlation and can be as "good" for >>>>>> re-identification as the non-hashed value. >>>>>> >>>>>> The argument to include text here is that it seems to be >>>>>> very tempting to include that kind of information for many >>>>>> folks. >>>>> >>>>> Stephen, >>>>> >>>>> It seems to me that the possibility of creating URNs that >>>>> could disclose private, or personal-information-tracing, >>>>> information is not an issue with URN symtax and definitions >>>>> but with what namespaces are created (and NIDs registered). >>>>> In principle (and as others have suggested), that issue >>>>> could apply to any URI and to most other identifier types >>>>> that can be used on the Internet. For URIs, even if the >>>>> domain is fixed a simple search using a URI query can >>>>> disclose personal location or other private information if >>>>> the search parameters are then harvested and/or stored, >>>>> which I understand to be a common practice. >>>>> >>>>> Two observations about this issue wrt the present document: >>>>> >>>>> (1) The NID registration approval process and associated >>>>> protections. >>>>> >>>>> Because of the diversity of the issues involved, the intent >>>>> of the WG was that Expert Review of URN NID registration >>>>> proposals would never rely on a single individual but on a >>>>> team with different perspectives, working together. As I >>>>> reread the draft just now, while that team idea is strongly >>>>> hinted at, perhaps it should be made more explicit (if you >>>>> think so, text would be welcome). In any event, appointment >>>>> of designated experts (individually or as a team) is under >>>>> control of the IESG. It seems to me that it would be >>>>> entirely appropriate for the IESG to include a privacy >>>>> expert on that team if you (collectively) believe that >>>>> would be helpful. >>>>> >>>>> Projecting a bit from other experience, a focused discussion >>>>> about potential problems with a particular proposed >>>>> namespace (including but not limited to privacy issues) is >>>>> much more likely to lead to understanding and, where >>>>> plausible, mitigation of those problems than some sort of >>>>> general statement in a registration specification. The >>>>> comments in the I-D about team efforts and parties working >>>>> together "in a spirit of good faith and mutual >>>>> understanding" are specifically intended to facilitate such >>>>> discussions. Given the RFC 7254 example (and your ultimate >>>>> "No objection" position on it), it is hard to imagine the >>>>> new procedure working less well to prevent privacy problems >>>>> than the current "IETF Consensus" arrangements. >>>>> >>>>> I also note that the registration template explicitly calls >>>>> for consideration of security and privacy issues in >>>>> namespaces and namespace registrations. That should be a >>>>> considerable improvement from your standpoint over the >>>>> language of RFC 3406. >>>>> >>>>> >>>>> (2) Namespace registrations and the Protocol Police >>>>> >>>>> URN namespaces and the identifying NIDs are as, or more, >>>>> easily used without formal IETF approval or registration >>>>> than URI scheme names, media types, and many other >>>>> identifiers. The Protocol Police have been quite >>>>> ineffective in preventing or punishing such actions. If we >>>>> create barriers to registration that seem burdensome and/or >>>>> frustrate people from what they "want to do", experience >>>>> indicates that the registration procedure, and perhaps >>>>> syntax and other restrictions, will simply be ignored. >>>>> >>>>> RFC 7254 may be a good example here too: if GSMA really >>>>> believed that they needed a namespace of that type and that >>>>> the IETF had said "no, you can't have one because it might >>>>> lead to disclosure of personal information", the only two >>>>> outcomes I can imagine are that they would have gone ahead >>>>> and used an unregistered URN namespace or that they would >>>>> have picked out some other identifier over which the IETF >>>>> does not claim authority. Neither would provide significant >>>>> additional privacy. I find it very hard to imagine that >>>>> they would have simply given up and conclude that no such >>>>> identifier collection or namespace was needed. >>>>> >>>>> Rather than try to create prohibitions that we cannot >>>>> enforce, the new registration procedures are intended to >>>>> facilitate discussions in which our experts can use our >>>>> expertise to shed light on issues and identify and mitigate >>>>> problems where possible while encouraging the registrations >>>>> themselves. The latter, if nothing else, reduces the odds >>>>> of duplication of supposedly-unique identifiers. Avoiding >>>>> such duplication is an important operational and security >>>>> issue, at least IMO. >>>>> >>>>> best, >>>>> john >>>>>
- [urn] Stephen Farrell's Abstain on draft-ietf-urn… Stephen Farrell
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Hakala, Juha E
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Martin J. Dürst
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Peter Saint-Andre
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Stephen Farrell
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Martin J. Dürst
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Martin J. Dürst
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… John C Klensin
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Stephen Farrell
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Stephen Farrell
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… John C Klensin
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Peter Saint-Andre
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Stephen Farrell
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… John C Klensin
- Re: [urn] Stephen Farrell's Abstain on draft-ietf… Peter Saint-Andre