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

From: Martin J. Dürst <[email-masked]>
Date: Wed, 1 Mar 2017 17:27:06 +0900

Hello Juha, Stephen, others,

On 2017/03/01 16:16, Hakala, Juha E wrote:
> Hello Stephen,
>
> Two comments:
>
> As regards this,
>
>> - What deployed code supports the ?+ or ?= constructs?  If some arguably
>> "important" code does, I'd change my abstain to a no-objection, as then
>> there'd be an at least modest new feature to justify the new RFC.
>
> the National Library of Finland intends to revise its current URN resolver so that it supports r- and q-components. Funding for this work has been obtained from EU project EUDAT, which applies persistent identifiers to research data sets. The work will start as soon as RFC2141bis has become an Internet standard.

As far as I'm aware, RFC2141bis will become a Proposed Standard, not an 
Internet Standard. My guess is that that's what Juha meant. It takes a 
lot of time to get to full Internet Standard, and interoperable 
implementations are definitely required.

> As far as I know, there are no existing implementations of upcoming URN syntax features yet, since the URN user community has been patiently waiting for the final version of the URN syntax. Many of us are national libraries, so our time scale tends to be different from that of most other Internet organizations ;-). Once RFC2141bis has been published as an Internet standard, we still need to define the syntax for specifying resolution services and service parameters in the r-component. This should not take much time, and it can be done during the application development.
>
> Concerning this:
>
>> Normally, I'd just ballot no-objection and let that go, but given that this has
>> consumed cycles for 6 years that could perhaps have been more usefully
>> engaged in dealing with
>> 3986 issues, I think abstaining is a better position to take on the off-chance
>> that that sends some tiny form of signal.
>
> URNBIS needed 6 years partly because there were many 3986-based URN issues the WG had to solve before sufficient consensus was found.
>
> Just to give one example, URI syntax says that:
>
> "The fragment identifier component of a URI allows indirect
>    identification of a secondary resource by reference to a primary
>    resource and additional identifying information."
>
> However, f-component in the URN syntax has no role in identification, since fragment identifiers would have extended the scope of many existing standard identifier systems in an unacceptable manner. For instance, ISBNs identify books but not their component parts, so a URN:ISBN with an f-component still identifies a book as a whole, and the f-component indicates just a location within the book.

This shows one of the main problems the WG was having: Not everybody 
uses the same vocabulary, and for many communities, vocabulary is pretty 
important.

Regards,    Martin.

> The communities using URNs and other persistent identifiers (national libraries, national archives, universities, research institutions, scientific publishers etc.) need an updated URN syntax specification, not an improved version of URI syntax - which might of course be very useful for many other Web users out there. Be that as it may, I am glad that URI syntax revision is outside the scope of the URNBIS WG.
>
> All the best,
>
> Juha Hakala

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 1 Mar 2017 20:14:48 -0700

On 2/28/17 5:37 PM, Stephen Farrell wrote:

> - Section 8 should I think recognise the dangers inherent
> in long-term stable identifiers helping with
> (re-)identification of people and/or network entities.

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?

> While that is not the "fault" of URNs, I'd say it is worth
> warning folks who may just possibly think twice before
> creating new URNs with those failings. (Though I recognise
> that that may call for a reference to RFC6919;-)

I'm sure you meant RFC 6920. :-)

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Mar 2017 08:11:00 +0000

Hiya,

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

I'm not sure if there's a useful bit of text in RFC6973
at which you could point, but it'd be worth a look.

> I'm sure you meant RFC 6920. :-)

Off-by-one error:-)

Cheers,
S.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 2 Mar 2017 21:13:44 +0900

> real examples of such in existing URNs but if there were

https://datatracker.ietf.org/doc/rfc7254/history/

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 2 Mar 2017 21:14:36 +0900

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Mar 2017 12:20:58 +0000

> https://datatracker.ietf.org/doc/rfc7254/history/

Thanks Martin - I had a feeling there was something I'd
forgotten (or maybe tried to forget;-). That is a good
example though.

Cheers,
S.

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Mar 2017 08:35:34 -0500

--On Thursday, March 2, 2017 08:11 +0000 Stephen Farrell
<[email-masked]> 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?
> 

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Mar 2017 14:33:34 +0000

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.

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Mar 2017 10:45:32 -0500

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, 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
<[email-masked]> wrote:

>>>> 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?
>>> 
>>> prevent correlation and can be as "good" for
>>> re-identification as the non-hashed value.
>>> 
>> 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.
>> 
>> 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.  
>> 
>> 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.
>> 
>> 
>> 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.
>> 
>> supposedly-unique identifiers.  Avoiding such duplication is
>> an important operational and security issue, at least IMO.
>> 
>> best,
>>    john
>> 
>> 
>> 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 2 Mar 2017 08:58:26 -0700

If Stephen can propose text, that's great. I'm happy to do so for
Stephen's review, but I probably won't have time until tomorrow.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 2 Mar 2017 16:57:14 +0000

On 02/03/17 15:45, John C Klensin wrote:
> 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

---

From: John C Klensin <[email-masked]>
Date: Thu, 02 Mar 2017 12:16:40 -0500

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
<[email-masked]> wrote:

>> 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, 
> 
>       considerations in RFCs [RFC3552] and the privacy
> considerations       for Internet protocols [RFC6973].
> 
> NEW:
> 
>       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.
> 
>>>>>> 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?
>>>>> 
>>>> 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.
>>>> 
>>>> Because of the diversity of the issues involved, the intent
>>>> of the WG was that Expert Review of URN NID registration
>>>> entirely appropriate for the IESG to include a privacy
>>>> expert on that team if you (collectively) believe that
>>>> would be helpful.  
>>>> 
>>>> 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.
>>>> 
>>>> 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.   
>>>> 
>>>> additional privacy.  I find it very hard to imagine that
>>>> they would have simply given up and conclude that no such
>>>> 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
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> 
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 2 Mar 2017 11:08:46 -0700

That seems like a fine path forward. I don't have anything else to add.