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

[Stephen Farrell <[e-mail]>]

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