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

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

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