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

[Stephen Farrell <[e-mail]>]

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