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
>>>>>