Re: [urn] Stephen Farrell's Abstain on draft-ietf-urnbis-rfc2141bis-urn-21: (with COMMENT)

[John C Klensin <[e-mail]>]

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
<[e-mail]> 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
>> <[e-mail]> 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
>>>> <[e-mail]> 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
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>