Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi, this thread seems to have converged on getting the draft to address the points in the email below before getting it evaluated by the IESG. Andrew, could you please take care of adding text to the draft addressing those points? People have asked about the history of this draft and there have been some comments about it. In short, this draft was reviewed by the IESG years ago. You can get an idea of how long ago by checking the IESG members at that point in its ballot: http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/ballot/ The process stopped due to a late IPR disclosure. It took a very long time to clarify the implications of that disclosure. There were extensive on and off discussions over many years until a few months ago the DISPATCH WG agreed that it was a good idea to register this. Cheers, Gonzalo On 21/07/2013 5:44 AM, John C Klensin wrote: --On Saturday, July 20, 2013 19:17 -0700 Tim Bray tb...@textuality.com wrote: Fair enough. I think it would be reasonable to ask that: - the draft include the word privacy - the draft discuss the issues around relying on an identifier that persists across changes in device ownership There may be an issue concerning a SIP-related identifier which is unavailable on millions of mobile devices which do not have IMEIs, but it's quite possible that it's non-applicable in the context of the draft. -T Personally, I'd consider getting all three of those issues addressed in the document (including a discussion of the applicability of the latter and a serious discussion of the privacy issues) as adding value... and as requirements for RFC publication in the IETF Stream. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
SM, As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Regards, Mary. On Sun, Jul 21, 2013 at 11:38 AM, S Moonesamy sm+i...@elandsys.com wrote: At 00:03 21-07-2013, Andrew Allen wrote: The reason why the IMEI namespace is being registered as a GSMA namespace and not as part of the 3GPP namespace is that the GSMA has the responsibility for IMEI assignment and hence in maintaining uniqueness of the namespace. It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the dispatch mailing list. I did not see the extensive discussion. I saw the following comment Surely that is just trying to turn the IETF into the policeman. The primary purpose of the IMEI is for preventing use of stolen mobile phones and enabling emergency calls to be made from mobiles that don't have a valid subscription. From what I read the main purpose of the IMEI is to be able to take measures against stolen phones and against equipment which the use cannot be accepted for technical or safety reasons. The secondary purpose is the tracing of malicious calls. There is an apps which sends the IMEI in a cryptographically-protected form over the network. For what it is worth, it's MD5. There has been some work in the IETF on emergency calls (see service URN). At 00:12 21-07-2013, Andrew Allen wrote: As John pointed out having the sub namespace reviewed by IETF provides the opportunity to add text to address privacy concerns with any inappropriate usage. I don't think that it is the role of the IETF to determine whether the usage of a sub-namespace is appropriate or not as it can cause namespace management issues. I tried the explain the subtlety between privacy concerns and privacy considerations. The IMEI can also be used as a customer identifier. Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi Mary, At 07:28 27-08-2013, Mary Barnes wrote: As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Thanks for the feedback. Somebody commented that: It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the DISPATCH mailing list archives. I did not see that extensive discussion. My comment was about that. I do not have any problem with the document shepherd comments. Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
SM The past discussions on this took place a couple of years ago involving primarily Cullen Jennings, Dale Worley and myself. Andrew - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Tuesday, August 27, 2013 10:20 AM Central Standard Time To: Mary Barnes mary.h.bar...@gmail.com Cc: John C Klensin j...@jck.com; tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi Mary, At 07:28 27-08-2013, Mary Barnes wrote: As far as the IPR, as the shepherd and DISPATCH WG co-chair, I posted a note to the DISPATCH WG mailing list before progressing this document to see if anyone had any concerns about the IPR disclosures, which had been discussed in the past and were updated when I asked the authors the requisite questions about IPR while doing the PROTO write-up. No concerns were raised with regards to the updated IPR disclosures (i.e., no one responded to that email). And, you can google draft montemurro ietf ipr archives to find past discussions such as this one: draft montemurro ietf ipr archives Thanks for the feedback. Somebody commented that: It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the DISPATCH mailing list archives. I did not see that extensive discussion. My comment was about that. I do not have any problem with the document shepherd comments. Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Martin Further to our conversation on this topic in Berlin I now respond formerly on the list. 3GPP has defined the mobile terminal as performing the UA role since the very beginning of IMS. Therefore the mapping between the terminal and the instance ID in IMS is a one to one relationship. Andrew - Original Message - From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Monday, July 22, 2013 12:57 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On 20 July 2013 15:34, Andrew Allen aal...@blackberry.com wrote: There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message? I think that reading this thread should provide you with ample reasons. The instance ID in outbound has certain stability requirements that do not strictly correspond to the lifetime of the hardware in use. The other use cases answer very different questions, which include: is this a stolen device, is this device authorized to use the networks, etc... I'm certain those questions can be answered without a device identifier traversing the network. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 20 July 2013 15:34, Andrew Allen aal...@blackberry.com wrote: There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message? I think that reading this thread should provide you with ample reasons. The instance ID in outbound has certain stability requirements that do not strictly correspond to the lifetime of the hardware in use. The other use cases answer very different questions, which include: is this a stolen device, is this device authorized to use the networks, etc... I'm certain those questions can be answered without a device identifier traversing the network.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
The reason why the IMEI namespace is being registered as a GSMA namespace and not as part of the 3GPP namespace is that the GSMA has the responsibility for IMEI assignment and hence in maintaining uniqueness of the namespace. It has nothing to do with IPR which was extensively discussed on the dispatch list. The primary purpose of the IMEI is for preventing use of stolen mobile phones and enabling emergency calls to be made from mobiles that don't have a valid subscription. Andrew - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Saturday, July 20, 2013 10:48 PM Central Standard Time To: John C Klensin j...@jck.com Cc: Tim Bray tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi John, At 18:23 20-07-2013, John C Klensin wrote: See my earlier note, but mostly to aid in getting the documentation right. For example, to the extent that the recent discussion results in a more complete treatment of privacy and/or security considerations in the documentation, that is a net improvement and added value. There was a Last Call for draft-montemurro-gsma-imei-urn-01 in 2007. The draft was sponsored by an Apps AD. draft-montemurro-gsma-imei-urn-04 was evaluated (I did not verify the details) in 2009. An IPR disclosure, about a patent filed several years ago, was filed after that evaluation. The DISCUSS got cleared automatically. draft-montemurro-gsma-imei-urn-08 was dispatched to RAI in 2011. 3GPP was assigned a URN in 2008. The shepherd write-up for draft-montemurro-gsma-imei-urn-16 mentions that this document is required for the 3GPP/IMS specification, thus any vendor that implements the 3GPP specifications follows this specification. The significant difference between the 3GPP URN and the requested GSMA URN is that there is an IPR disclosure on that latter. One of the questions asked by Tim Bray was about the WiFi-only scenario. That was raised previously through a DISCUSS as the softphone issue. The privacy discussion might cause some discontent. As for whether the draft will gain consensus, well, what can I say; if it is the consensus of the IETF to support state-sponsored surveillance there is nothing I can do about it. :-) Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid is also required in order to use the IMEI as a SIP instance ID. So just not registering the sub namespace doesn't avoid the IETF having to address the issue. As John pointed out having the sub namespace reviewed by IETF provides the opportunity to add text to address privacy concerns with any inappropriate usage. - Original Message - From: S Moonesamy [mailto:sm+i...@elandsys.com] Sent: Saturday, July 20, 2013 06:50 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; sm+i...@elandsys.com sm+i...@elandsys.com; ietf@ietf.org ietf@ietf.org; tb...@textuality.com tb...@textuality.com; draft-montemurro-gsma-imei-urn@tools.ietf.org draft-montemurro-gsma-imei-urn@tools.ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Hi Andrew, At 13:48 20-07-2013, Andrew Allen wrote: I think IANA registration of namespaces has a lot of value. draft-montemurro-gsma-imei-urn-16 discusses about two namespaces: (i) gsma (ii) imei It is not possible to get a IANA registration for (ii) as according to draft-montemurro-gsma-imei-urn-16 (ii) is managed by (i). In simple terms (ii) does not require IETF approval. Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Seems the text got munged with some copy pasting so here it is corrected: Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS without an IMEI then it will use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew From: Andrew Allen [mailto:aal...@blackberry.com] Sent: Saturday, July 20, 2013 11:48 PM Central Standard Time To: tb...@textuality.com tb...@textuality.com Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Tim Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS then it will still use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? It survives device wipes, which usually happen upon change of device ownership. I’m not an expert in your application domain, so pardon me if this question is hopelessly naive: It seems that this identifier is related in some way to SIP sessions. It seems that it would be a common operation to launch a SIP session on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an IMEI. Is this a problem? -T Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.commailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.commailto:tb...@textuality.com tb...@textuality.commailto:tb...@textuality.com; ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Look, I don’t remotely understand the 3gpp universe, and I acknowledge John Klensin’s point about the advantages of registering things, in general. Having said that, I worry a little bit that URNs are URIs and there are lots of specs out there that say “use any URI” and I sure wouldn’t want to see these things used anywhere near any application-level protocol. If this were an Apps-Area thing and I thought that registering it would increase the risk that these patent-encumbered, privacy-compromising, operationally-fragile constructs had any chance of creeping into general use by app developers, I’d be lying in the road screaming. As it is, I think the issues with this draft have been raised sufficiently, so I’ll shut up and leave further discussion to those who understand domain-specific technical issues. -Tim On Sun, Jul 21, 2013 at 12:37 AM, Andrew Allen aal...@blackberry.comwrote: Tim Seems the text got munged with some copy pasting so here it is corrected: Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS without an IMEI then it will use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew *From*: Andrew Allen [mailto:aal...@blackberry.com] *Sent*: Saturday, July 20, 2013 11:48 PM Central Standard Time *To*: tb...@textuality.com tb...@textuality.com *Cc*: ietf@ietf.org ietf@ietf.org *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Tim Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS then it will still use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew *From*: Tim Bray [mailto:tb...@textuality.com] *Sent*: Saturday, July 20, 2013 07:01 PM Central Standard Time *To*: Andrew Allen *Cc*: scott.b...@gmail.com scott.b...@gmail.com; ietf@ietf.org ietf@ietf.org *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.comwrote: Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? It survives device wipes, which usually happen upon change of device ownership. I’m not an expert in your application domain, so pardon me if this question is hopelessly naive: It seems that this identifier is related in some way to SIP sessions. It seems that it would be a common operation to launch a SIP session on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an IMEI. Is this a problem? -T Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
At 00:03 21-07-2013, Andrew Allen wrote: The reason why the IMEI namespace is being registered as a GSMA namespace and not as part of the 3GPP namespace is that the GSMA has the responsibility for IMEI assignment and hence in maintaining uniqueness of the namespace. It has nothing to do with IPR which was extensively discussed on the dispatch list. I read the dispatch mailing list. I did not see the extensive discussion. I saw the following comment Surely that is just trying to turn the IETF into the policeman. The primary purpose of the IMEI is for preventing use of stolen mobile phones and enabling emergency calls to be made from mobiles that don't have a valid subscription. From what I read the main purpose of the IMEI is to be able to take measures against stolen phones and against equipment which the use cannot be accepted for technical or safety reasons. The secondary purpose is the tracing of malicious calls. There is an apps which sends the IMEI in a cryptographically-protected form over the network. For what it is worth, it's MD5. There has been some work in the IETF on emergency calls (see service URN). At 00:12 21-07-2013, Andrew Allen wrote: As John pointed out having the sub namespace reviewed by IETF provides the opportunity to add text to address privacy concerns with any inappropriate usage. I don't think that it is the role of the IETF to determine whether the usage of a sub-namespace is appropriate or not as it can cause namespace management issues. I tried the explain the subtlety between privacy concerns and privacy considerations. The IMEI can also be used as a customer identifier. Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi Yes it true , but more argumentations are welcome Sinverely yours 2013/7/20, Scott Brim scott.b...@gmail.com: Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
At 15:53 19-07-2013, Andrew Allen wrote: Do you not think that the text in the security considerations section:: because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity covers the privacy issue? If not what is the additional privacy concern? There is a difference between privacy concerns and privacy considerations. It has been mentioned that the view in 3GPP was that the IMEI should not be of any greater concern when used as an instance ID than using a UUID. draft-montemurro-gsma-imei-urn-16 states that: Specifically the IMEI is to be incorporated in a module which is contained within the terminal. The IMEI SHALL NOT be changed after the terminal's production process. It SHALL resist tampering, i.e. manipulation and change, by any means (e.g. physical, electrical and software). The pervasive use of UUID in computing does not make it a good idea. I doubt that there has been any privacy analysis of how UUID will be used or misused prior to the publication of the RFC. The IMEI is built into the device. The scope for misuse would be clear enough for a person designing identifiers. From draft-montemurro-gsma-imei-urn-16: Therefore the IMEISV (that is, the IMEI URN with svn parameter) MUST NOT be delivered to devices that are not trusted. Further, because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity. The IMEI is considered as personal data in some jurisdictions. There is a strong correlation between the IMEI and a user. I read draft-montemurro-gsma-imei-urn-16 and I see that the four authors have listed their phone numbers as unlisted. Is there a reason for that? The question may sound unrelated to the draft and it can be argued that it is unrelated to the draft. I asked it as it may help the casual reader understand what privacy is about. draft-moonesamy-privacy-identifiers-00 (expired) argues that there is an implicit assumption that the underlying protocols are transmitting the right amount of information needed for the protocols to work. Is for example, urn:gsma:imei:90420156-025763-0, required for SIP to work? I do not think so. The world was somewhat naive about privacy in 2006. Privacy is a hot topic nowadays. The metadata debacle is one of the contributing factors. There seems to be an assumption that the IMEISV is usually sent over trusted channels to trusted parties. The second sentence containing must not written in capital letters takes a position where anonymity of messages is opt-in. The GSM Association has published a set of principles which mentions privacy by design. It is up to the reader to read the two sentences quoted above and determine whether privacy by design is just another buzzword or a principle which the GSM Association considers as important. At 04:23 20-07-2013, Scott Brim wrote: Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? As a responding to Scott's comment about the three years of work I would say that this has the signs of an inevitable decision. I'll describe the IETF angle as follows: Is it okay to assign a Uniform Resource Name namespace for GSMA? The namespace assignment is not a problem. Have an assignment request sitting in the IETF queue for seven years is a problem. It would be good if someone explained why this happened unless the IETF considers it as acceptable to be asked to take inevitable decisions. I agree with Scott's comment. Tim Bray already pointed out that this is a bad idea. At 04:53 20-07-2013, GARBA KORA TAMSIRD BELLO wrote: Yes it true , but more argumentations are welcome The duck won't fly. :-) Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi. Borrowing from several other notes and comments, it seems to me that we have three interlocking issues that keep recurring and producing long discussions. They are by no means independent of this particular draft, but seem to be becoming generic. (1) Are we willing to publish (or even standardize) specs whose nature is to provide a vehicle for making privacy-sensitive information public? The arguments against doing so seem obvious. The arguments for doing so include those who claim they need this will do it anyway so we are better off publishing a spec that will at least reduce interoperability side-effects and permit spelling out the issues as privacy considerations or security ones. (2) Is turning hardware identifiers (physical-layer objects) into applications or user level identifiers an acceptable idea? Are DNS RRTYPEs that map application-level identifiers into other identifiers that can loop back through the DNS without guarantees that the process will terminate part of the same problem or a different one? (3) Do either of the above answers change if the proposal comes from another SDO or a major industry group? I don't know the answers, but I'm pretty sure that trying to address each of these issues separately every time a new protocol, RRTYPE, or URN (or URI) type comes along that interacts with one of them is not the way. It seems to me that we ought to have something along the lines of RFC 1984 in our future and that a plenary discussion might be a useful first step. I don't suppose the IAB or IESG would be willing to postpone or push something out of the announced agendas to allow for that discussion, which, given this Last Call and the recent one over RRTYPs would seem to be critical path. Any volunteers to get in front of the mic lines? john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Wrt privacy in general... On 07/20/2013 02:56 PM, John C Klensin wrote: Any volunteers to get in front of the mic lines? I'd welcome that discussion. I'd love to see us have a BCP61-like [1] RFC on the topic of privacy and I also reckon that that'd help short-cut a number of IETF LCs and IESG DISCUSSes. (For example the Forwarded HTTP header and WebFinger both caused extensive discussions.) FWIW, my personal preference would be that such a BCP would attempt to make our work be more privacy friendly and by default though I'm not quite how how best to try achieve that though. But, even if the outcome wasn't a BCP along the lines I'd prefer, I think such a beast would still be worth having if it meant we could avoid a whole lot of these kinds of similar discussions on individual drafts. S. [1] http://tools.ietf.org/html/bcp61
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Wrt privacy in general... On 07/20/2013 02:56 PM, John C Klensin wrote: Any volunteers to get in front of the mic lines? I'd welcome that discussion. I'd love to see us have a BCP61-like [1] RFC on the topic of privacy and I also reckon that that'd help short-cut a number of IETF LCs and IESG DISCUSSes. (For example the Forwarded HTTP header and WebFinger both caused extensive discussions.) FWIW, my personal preference would be that such a BCP would attempt to make our work be more privacy friendly and by default though I'm not quite how how best to try achieve that though. But, even if the outcome wasn't a BCP along the lines I'd prefer, I think such a beast would still be worth having if it meant we could avoid a whole lot of these kinds of similar discussions on individual drafts. S. [1] http://tools.ietf.org/html/bcp61 I agree completely. Doesn't draft-iab-privacy-considerations do what you want? (And no matter what gets agreed to at a general level, we will still have these discussions about specifics.)
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
--On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell stephen.farr...@cs.tcd.ie wrote: ... But, even if the outcome wasn't a BCP along the lines I'd prefer, I think such a beast would still be worth having if it meant we could avoid a whole lot of these kinds of similar discussions on individual drafts. That was exactly what I was thinking. I think the security analogy is a combination of BCP 61 (RFC 3365) and RFC 1984. That is a quibble but relates to the question of whether draft-iab-privacy-considerations is sufficient. I think it is necessary, but not sufficient. The other piece would be a fairly clear and ideally consensus, statement about what we do and do not intend to do and why. IMO, the only want to make progress on avoiding these similar discussions on individual drafts would be to develop such a consensus and focus the discussions on it. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 07/20/2013 04:06 PM, Scott Brim wrote: On Sat, Jul 20, 2013 at 10:51 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Wrt privacy in general... On 07/20/2013 02:56 PM, John C Klensin wrote: Any volunteers to get in front of the mic lines? I'd welcome that discussion. I'd love to see us have a BCP61-like [1] RFC on the topic of privacy and I also reckon that that'd help short-cut a number of IETF LCs and IESG DISCUSSes. (For example the Forwarded HTTP header and WebFinger both caused extensive discussions.) FWIW, my personal preference would be that such a BCP would attempt to make our work be more privacy friendly and by default though I'm not quite how how best to try achieve that though. But, even if the outcome wasn't a BCP along the lines I'd prefer, I think such a beast would still be worth having if it meant we could avoid a whole lot of these kinds of similar discussions on individual drafts. S. [1] http://tools.ietf.org/html/bcp61 I agree completely. Doesn't draft-iab-privacy-considerations do what you want? As John said, that sets out considerations but what I'm talking about here would be a BCP, so no that's a useful input but doesn't represent an IETF consensus position the way a BCP would. S. (And no matter what gets agreed to at a general level, we will still have these discussions about specifics.)
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 07/20/2013 04:31 PM, John C Klensin wrote: --On Saturday, July 20, 2013 15:51 +0100 Stephen Farrell stephen.farr...@cs.tcd.ie wrote: ... But, even if the outcome wasn't a BCP along the lines I'd prefer, I think such a beast would still be worth having if it meant we could avoid a whole lot of these kinds of similar discussions on individual drafts. That was exactly what I was thinking. I think the security analogy is a combination of BCP 61 (RFC 3365) and RFC 1984. That is a quibble but relates to the question of whether draft-iab-privacy-considerations is sufficient. I think it is necessary, but not sufficient. The other piece would be a fairly clear and ideally consensus, statement about what we do and do not intend to do and why. Fully agree. I do hope we get this discussion at the mic in Berlin. (Or if some folks are already interested in working on this just send me a mail.) If someone felt this whole thing was a bad plan, now'd also be a good time to hear about that (and why). Though of course there'd be loads more opportunities for that too. S. IMO, the only want to make progress on avoiding these similar discussions on individual drafts would be to develop such a consensus and focus the discussions on it. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
The URN containing the IMEI is used by all mobile phones that support voice over LTE. It is a dependency for 3GPP release 8 (which was completed about end of 2008). So yes it is going to be used and its more than 3 years of 3GPP work invested and is already incorporated into many devices. In the pre-existing circuit switched systems the IMEI is delivered to the network as the device identifier and it is also necessary to deliver the same device identifier to the network when using SIP so that when handover takes place between packet switched and circuit switched the network can correlate the communication as being with the same device. Regulations also require the IMEI to be delivered to the network. This associated draft describes how 3GPP uses the IMEI as a SIP instance ID and the reasons why: http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time To: S Moonesamy sm+i...@elandsys.com Cc: Tim Bray tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
So if it’s going to be used, exactly as specified, whatever we do, then what value is added by the IETF process? -T On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen aal...@blackberry.comwrote: The URN containing the IMEI is used by all mobile phones that support voice over LTE. It is a dependency for 3GPP release 8 (which was completed about end of 2008). So yes it is going to be used and its more than 3 years of 3GPP work invested and is already incorporated into many devices. In the pre-existing circuit switched systems the IMEI is delivered to the network as the device identifier and it is also necessary to deliver the same device identifier to the network when using SIP so that when handover takes place between packet switched and circuit switched the network can correlate the communication as being with the same device. Regulations also require the IMEI to be delivered to the network. This associated draft describes how 3GPP uses the IMEI as a SIP instance ID and the reasons why: http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time To: S Moonesamy sm+i...@elandsys.com Cc: Tim Bray tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:58 AM Central Standard Time To: Andrew Allen Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...” Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew From: Tim Bray [mailto:tb...@textuality.commailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:02 AM Central Standard Time To: IETF-Discussion Discussion ietf@ietf.orgmailto:ietf@ietf.org Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen aal...@blackberry.com wrote: The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? The difference is that the UUID (properly) vanishes when the device is factory-reset (“wiped”), as is common when a device is passed on to a new owner. The IMEI persists, however. -T Andrew *From*: Tim Bray [mailto:tb...@textuality.com] *Sent*: Friday, July 19, 2013 10:58 AM Central Standard Time *To*: Andrew Allen *Cc*: ietf@ietf.org ietf@ietf.org *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen aal...@blackberry.comwrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...” Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew *From*: Tim Bray [mailto:tb...@textuality.com] *Sent*: Friday, July 19, 2013 10:02 AM Central Standard Time *To*: IETF-Discussion Discussion ietf@ietf.org *Subject*: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Mobile phones are not usually completely factory reset if resold and even if they were a UUID may still have been stored in non volatile as it may have been generated during final test. In any case if the IMEI was to persist after a resale how would that be a privacy problem given the restrictions placed on the usage in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/? The intention is that the IMEI is not passed to the remote party except when required by regulations for an Emergency call. Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 03:31 PM Central Standard Time To: Andrew Allen Cc: ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 1:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? The difference is that the UUID (properly) vanishes when the device is factory-reset (“wiped”), as is common when a device is passed on to a new owner. The IMEI persists, however. -T Andrew From: Tim Bray [mailto:tb...@textuality.commailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:58 AM Central Standard Time To: Andrew Allen Cc: ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...” Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew From: Tim Bray [mailto:tb...@textuality.commailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:02 AM Central Standard Time To: IETF-Discussion Discussion ietf@ietf.orgmailto:ietf@ietf.org Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
I think IANA registration of namespaces has a lot of value. From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 01:36 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; sm+i...@elandsys.com sm+i...@elandsys.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt So if it’s going to be used, exactly as specified, whatever we do, then what value is added by the IETF process? -T On Sat, Jul 20, 2013 at 11:28 AM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: The URN containing the IMEI is used by all mobile phones that support voice over LTE. It is a dependency for 3GPP release 8 (which was completed about end of 2008). So yes it is going to be used and its more than 3 years of 3GPP work invested and is already incorporated into many devices. In the pre-existing circuit switched systems the IMEI is delivered to the network as the device identifier and it is also necessary to deliver the same device identifier to the network when using SIP so that when handover takes place between packet switched and circuit switched the network can correlate the communication as being with the same device. Regulations also require the IMEI to be delivered to the network. This associated draft describes how 3GPP uses the IMEI as a SIP instance ID and the reasons why: http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ - Original Message - From: Scott Brim [mailto:scott.b...@gmail.commailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 06:23 AM Central Standard Time To: S Moonesamy sm+i...@elandsys.commailto:sm%2bi...@elandsys.com Cc: Tim Bray tb...@textuality.commailto:tb...@textuality.com; ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Thanks, SM, for finding what I said back in 2010. I still think this is architected wrong, conflating devices with communication endpoints higher up the stack, and steers us toward a path toward eventually needing to reduce privacy even more. However, 3GPP has apparently already already started marching down that path. Could our liaison explain the situation there? Is anyone actually going to use it? Is this a done deal - do we have to support it because otherwise 3 years of 3GPP work get undone? Scott - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Except that for normal usages at the application level, the UUID is generated by the app and placed in its private per-app storage, which is always erased on a factory-reset. To Andrew Allen: I strongly recommend factory-resetting your phone before you sell it, and also factory-resetting any phones you buy second-hand, just to be sure. Most people do this, for good reason. -T On Sat, Jul 20, 2013 at 1:55 PM, Scott Brim scott.b...@gmail.com wrote: On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 07/20/2013 01:48 PM, Andrew Allen wrote: I think IANA registration of namespaces has a lot of value. I think backfilling registrations for poached identifiers sets a bad/dangerous example. Doug (not necessarily speaking with any hats, current or former)
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Equivalence is equivalence the rest seems subjective to me - is the glass half full or half empty. The point is they are no more or less harmful. Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Martin There are obviously always alternative design choices but why would you want to include both a pre assigned device ID and a generated device ID in the same message? Andrew - Original Message - From: Martin Thomson [mailto:martin.thom...@gmail.com] Sent: Friday, July 19, 2013 11:25 AM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On 19 July 2013 08:38, Andrew Allen aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ I read that document. The placement of IMEI in the instance id is a little bit of a non-sequitur to my thinking. There are three cases identified where it might be necessary to convey an IMEI, but no real motivation is provided for why it has to be included, specifically, in the instance ID. Nor is it the case that all of these cases necessarily require that IMEI is conveyed in the clear. I can imagine solutions to the real problems that do not require that an IMEI transit the network. However, I'll concede that the relationship between a network provider and the devices that use the network does not necessarily grant those devices any right protections of the form in which Tim seems to be assuming to be necessary. The real risk here is with scope of use. I'd have thought that a P- header would have been more appropriate for these use cases. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim This is not the normal 3GPP IMS scenario. In IMS the device as a whole is considered as a single UA, multiple IMS applications will need to share a common registration procedure that is provided by the underlying OS. Otherwise multiple IMS registrations from different applications on a 3GPP terminal will likely conflict with each other if they do not share a common registration mechanism that registers all IMS apps using a common registration procedure. In IMS, contacts from the same entity are overwritten by subsequent registrations. Which means that if each app were to register individually then any contact parameters such as feature tags from a previous registered app would be overwritten by the latest registering app. Therefore the registration function and the instance ID will likely be part of the OS and not the application. In any case RFC 5626 says nothing about requiring instance IDs to be wiped or regenerated when the UA is transferred to another user or that the UA cannot be embedded in non volative. It doesn't even barr the instance ID being delivered to other users. http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ goes a lot further than RFC 5626 in addressing privacy of the instance ID in that regard. Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 04:07 PM Central Standard Time To: Scott Brim scott.b...@gmail.com Cc: Andrew Allen; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt Except that for normal usages at the application level, the UUID is generated by the app and placed in its private per-app storage, which is always erased on a factory-reset. To Andrew Allen: I strongly recommend factory-resetting your phone before you sell it, and also factory-resetting any phones you buy second-hand, just to be sure. Most people do this, for good reason. -T On Sat, Jul 20, 2013 at 1:55 PM, Scott Brim scott.b...@gmail.commailto:scott.b...@gmail.com wrote: On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
I think IANA registration of namespaces has a lot of value. let me ask the other side of the coin, in this case, what harm will be done by not making this an rfc and registering the imei uri? and i am not a fan of the mrs goldberg argument. randy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 07/20/2013 03:48 PM, Randy Bush wrote: I think IANA registration of namespaces has a lot of value. let me ask the other side of the coin, in this case, what harm will be done by not making this an rfc and registering the imei uri? None, because we lost the battle over protocol parameter poaching years ago. Doesn't mean I have to like it. :) Doug
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Randy Are you suggesting its not a problem if everyone were to just go off and define namespaces and not have them registered with IANA? I don't think that's a good precedence. The GSMA is the authoritative organisation for some identifers that have been used in billions of mobile devices for 20 years. Why should IETF deny them a namespace and a listing in the IANA registry for such identifers? If there are concerns with the usage of these identifiers those concerns should be addressed in the drafts that define the usage. Andrew - Original Message - From: Randy Bush [mailto:ra...@psg.com] Sent: Saturday, July 20, 2013 05:48 PM Central Standard Time To: Andrew Allen Cc: IETF Disgust ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt I think IANA registration of namespaces has a lot of value. let me ask the other side of the coin, in this case, what harm will be done by not making this an rfc and registering the imei uri? and i am not a fan of the mrs goldberg argument. randy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
--On Saturday, July 20, 2013 15:19 -0700 Doug Barton do...@dougbarton.us wrote: On 07/20/2013 01:48 PM, Andrew Allen wrote: I think IANA registration of namespaces has a lot of value. I think backfilling registrations for poached identifiers sets a bad/dangerous example. Doug, This is another of those arguments that I wish we could avoid repeating for each individual document. One of our oldest precedents and principles is that it is better to have things registered than not, even when they are ugly. Having such registrations gives us a fighting chance of avoiding the interoperability problems associated with two different parties accidentally using the same name for different purposes. It also provides a centralized mechanism for mapping identifiers onto documentation. That is both a good thing in itself and, in some cases, provides a place to include warnings about improper uses, nasty side-effects, and security and/or privacy problems. The Internet is not an operating system (or even the PSTN) in which the arbiters of taste can keep something from being incorporated in a release or used. If someone is determined to use a particular capability under a particular name, we can try to talk them out of it but, if they are still determined, the only question is whether we are better off with registration and documentation than without them. And, generally, we are better off with the first. Discussions about poaching, squatting, and even stupidity or bad taste are interesting but not generally helpful. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi Andrew, At 13:48 20-07-2013, Andrew Allen wrote: I think IANA registration of namespaces has a lot of value. draft-montemurro-gsma-imei-urn-16 discusses about two namespaces: (i) gsma (ii) imei It is not possible to get a IANA registration for (ii) as according to draft-montemurro-gsma-imei-urn-16 (ii) is managed by (i). In simple terms (ii) does not require IETF approval. Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.com wrote: Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? It survives device wipes, which usually happen upon change of device ownership. I’m not an expert in your application domain, so pardon me if this question is hopelessly naive: It seems that this identifier is related in some way to SIP sessions. It seems that it would be a common operation to launch a SIP session on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an IMEI. Is this a problem? -T Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.com tb...@textuality.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
--On Saturday, July 20, 2013 11:36 -0700 Tim Bray tb...@textuality.com wrote: So if it's going to be used, exactly as specified, whatever we do, then what value is added by the IETF process? -T See my earlier note, but mostly to aid in getting the documentation right. For example, to the extent that the recent discussion results in a more complete treatment of privacy and/or security considerations in the documentation, that is a net improvement and added value. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Fair enough. I think it would be reasonable to ask that: - the draft include the word “privacy” - the draft discuss the issues around relying on an identifier that persists across changes in device ownership There may be an issue concerning a SIP-related identifier which is unavailable on millions of mobile devices which do not have IMEIs, but it’s quite possible that it’s non-applicable in the context of the draft. -T On Sat, Jul 20, 2013 at 6:23 PM, John C Klensin j...@jck.com wrote: --On Saturday, July 20, 2013 11:36 -0700 Tim Bray tb...@textuality.com wrote: So if it's going to be used, exactly as specified, whatever we do, then what value is added by the IETF process? -T See my earlier note, but mostly to aid in getting the documentation right. For example, to the extent that the recent discussion results in a more complete treatment of privacy and/or security considerations in the documentation, that is a net improvement and added value. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
--On Saturday, July 20, 2013 19:17 -0700 Tim Bray tb...@textuality.com wrote: Fair enough. I think it would be reasonable to ask that: - the draft include the word privacy - the draft discuss the issues around relying on an identifier that persists across changes in device ownership There may be an issue concerning a SIP-related identifier which is unavailable on millions of mobile devices which do not have IMEIs, but it's quite possible that it's non-applicable in the context of the draft. -T Personally, I'd consider getting all three of those issues addressed in the document (including a discussion of the applicability of the latter and a serious discussion of the privacy issues) as adding value... and as requirements for RFC publication in the IETF Stream. john
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hi John, At 18:23 20-07-2013, John C Klensin wrote: See my earlier note, but mostly to aid in getting the documentation right. For example, to the extent that the recent discussion results in a more complete treatment of privacy and/or security considerations in the documentation, that is a net improvement and added value. There was a Last Call for draft-montemurro-gsma-imei-urn-01 in 2007. The draft was sponsored by an Apps AD. draft-montemurro-gsma-imei-urn-04 was evaluated (I did not verify the details) in 2009. An IPR disclosure, about a patent filed several years ago, was filed after that evaluation. The DISCUSS got cleared automatically. draft-montemurro-gsma-imei-urn-08 was dispatched to RAI in 2011. 3GPP was assigned a URN in 2008. The shepherd write-up for draft-montemurro-gsma-imei-urn-16 mentions that this document is required for the 3GPP/IMS specification, thus any vendor that implements the 3GPP specifications follows this specification. The significant difference between the 3GPP URN and the requested GSMA URN is that there is an IPR disclosure on that latter. One of the questions asked by Tim Bray was about the WiFi-only scenario. That was raised previously through a DISCUSS as the softphone issue. The privacy discussion might cause some discontent. As for whether the draft will gain consensus, well, what can I say; if it is the consensus of the IETF to support state-sponsored surveillance there is nothing I can do about it. :-) Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Firstly as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ the use of the IMEI as a SIP Instance ID only pertains to usage of SIP with the 3GPP IMS and if a device is not using IMS sing IMS without an IMEI uses IMS then it will still use a UUID as the SIP instance ID as per RFC 5626. If a device without an IMEI uses IMS then it will also still use a UUID as the SIP instance ID as per RFC 5626. This is specified also in the 3GPP IMS specification TS 24.229 as well as the above draft. So applications running on devices that don't have an IMEI can still use SIP for sessions. The IMEI which has been used in mobile devices for 20 years also survives device wipes for the circuit switched calling capability as used by billions of mobiles today with 2G and 3G networks. So again how is this more harmful for 4G than the current situation with 2G and 3G if a mobile device is transferred to a new owner? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Saturday, July 20, 2013 07:01 PM Central Standard Time To: Andrew Allen Cc: scott.b...@gmail.com scott.b...@gmail.com; ietf@ietf.org ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 3:20 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Can it please be explained how the IMEI URN when used as stated in http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Is any more harmful than as the IMEI is used today by over 90% of mobile phones in use today worldwide? It survives device wipes, which usually happen upon change of device ownership. I’m not an expert in your application domain, so pardon me if this question is hopelessly naive: It seems that this identifier is related in some way to SIP sessions. It seems that it would be a common operation to launch a SIP session on a device such as a WiFi-only tablet, or an iPod touch, that doesn’t have an IMEI. Is this a problem? -T Andrew - Original Message - From: Scott Brim [mailto:scott.b...@gmail.commailto:scott.b...@gmail.com] Sent: Saturday, July 20, 2013 03:55 PM Central Standard Time To: Andrew Allen Cc: tb...@textuality.commailto:tb...@textuality.com tb...@textuality.commailto:tb...@textuality.com; ietf@ietf.orgmailto:ietf@ietf.org ietf@ietf.orgmailto:ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Sat, Jul 20, 2013 at 4:08 PM, Andrew Allen aal...@blackberry.commailto:aal...@blackberry.com wrote: Tim The quote is from RFC 5626 which also states: 3.1. Summary of Mechanism Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Since the UUID in the instance ID is also static how is this significantly different in terms of privacy concerns from the IMEI being used as an instance ID? You're not demonstrating that an IMEI is just as good, you're demonstrating that a UUID is just as bad. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Certainly text can be added to the draft to address concerns. Could Tim please elaborate on what issues he sees when a device is transferred between owners and what potential uses of the URN he has a concern with? Certainly I can see that if it was used as address that had some permanence then that would be an issue however this is not the case as per http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Andrew - Original Message - From: John C Klensin [mailto:john-i...@jck.com] Sent: Saturday, July 20, 2013 09:44 PM Central Standard Time To: Tim Bray tb...@textuality.com Cc: IETF-Discussion Discussion ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt --On Saturday, July 20, 2013 19:17 -0700 Tim Bray tb...@textuality.com wrote: Fair enough. I think it would be reasonable to ask that: - the draft include the word privacy - the draft discuss the issues around relying on an identifier that persists across changes in device ownership There may be an issue concerning a SIP-related identifier which is unavailable on millions of mobile devices which do not have IMEIs, but it's quite possible that it's non-applicable in the context of the draft. -T Personally, I'd consider getting all three of those issues addressed in the document (including a discussion of the applicability of the latter and a serious discussion of the privacy issues) as adding value... and as requirements for RFC publication in the IETF Stream. john - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Last call: draft-montemurro-gsma-imei-urn-16.txt
Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Friday, July 19, 2013 10:02 AM Central Standard Time To: IETF-Discussion Discussion ietf@ietf.org Subject: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Fri, Jul 19, 2013 at 8:38 AM, Andrew Allen aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ Quoting from that document: “If a URN scheme other than UUID is used, the UA MUST only use URNs for which an RFC (from the IETF stream) defines how the specific URN needs to be constructed...” Now, I’m not an expert in the 3GPP world; but the suggestion in that extract that UUIDs are a better choice than a (shaky, unreliable, privacy-problematic) device identifier certainly rings true for those of us who think at the apps level. -T That will explain the primary application of this URN which is intended for use in the 3GPP cellular standards. Andrew *From*: Tim Bray [mailto:tb...@textuality.com] *Sent*: Friday, July 19, 2013 10:02 AM Central Standard Time *To*: IETF-Discussion Discussion ietf@ietf.org *Subject*: Last call: draft-montemurro-gsma-imei-urn-16.txt Just wanted to point out that both Apple (for iOS) and Google (for Android) have strongly discouraged the use of IMEI to identify devices for the purposes of application software. There are privacy, quality, and availability issues with their use. Apple has removed the ability of developers to work with the (often IMEI-derived) “Universal Device ID” (see http://blogs.avg.com/mobile-2/apple-ios-7-puts-unique-device-ids/) and Google has officially deprecated their use: http://android-developers.blogspot.ca/2011/03/identifying-app-installations.html I’m not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I’m pretty sure it’s a bad idea. -Tim - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 19 July 2013 08:38, Andrew Allen aal...@blackberry.com wrote: I suggest you also read http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ I read that document. The placement of IMEI in the instance id is a little bit of a non-sequitur to my thinking. There are three cases identified where it might be necessary to convey an IMEI, but no real motivation is provided for why it has to be included, specifically, in the instance ID. Nor is it the case that all of these cases necessarily require that IMEI is conveyed in the clear. I can imagine solutions to the real problems that do not require that an IMEI transit the network. However, I'll concede that the relationship between a network provider and the devices that use the network does not necessarily grant those devices any right protections of the form in which Tim seems to be assuming to be necessary. The real risk here is with scope of use. I'd have thought that a P- header would have been more appropriate for these use cases.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
At 08:02 19-07-2013, Tim Bray wrote: I'm not sure from reading the draft what the goal of having this URN namespace is, but if it involves encouraging its use by application developers, I'm pretty sure it's a bad idea. I agree that it sounds like a bad idea to encourage application developers to use this URN namespace. There was a documented vulnerability which demonstrated how the IMEI could be captured. In 2006 Leslie Daigle mentioned that the sub-NID namespace does not belong in the version of the draft which was reviewed. I'll quote some comments posted by Scott Brim in September 2010 to Apps Area Review. 'First, this feels like a layering mixup. When would -- or should -- a communicating peer outside a mobile network need to know the IMEI or IMEISV of a device inside a mobile network? An IMEI is used for initial identification on a mobile network or for SIM-less emergency calls. Under what conditions would an Internet-based peer have an IMEI in hand and want to use it in a gsma: URN? If as you say an Internet device is interoperating with a mobile device, it will do so using IP-based protocols and will (should) never learn the mobile device's IMEI. I can see cases where an outsourced management entity might want to speak to a mobile network's administration regarding records for a particular IMEI, but it would do so in a very secure way, not using this particular URN.' If there is an assumption that we are going to start passing around IMEIs as general identifiers, then I'm concerned that you are engineering a world in which one must reveal permanent identifiers in order to communicate. Please enlighten me as to the intent. Right now it feels to me like it enables us to do the wrong thing with IMEIs.' The http://gsmworld.com/newsroom/document%2Dlibrary/ normative reference is a 404. It would be easier to have the draft discuss the GSMA URN only. The alternative is to have the draft discuss the privacy considerations of using IMEI and IMEISV. Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy sm+i...@elandsys.com wrote: It would be easier to have the draft discuss the GSMA URN only. The alternative is to have the draft discuss the privacy considerations of using IMEI and IMEISV. Good catch. Assuming this is a good idea (I’m dubious) it would be completely unacceptable to register it without a discussion of privacy implications. -T Regards, S. Moonesamy
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Tim Do you not think that the text in the security considerations section:: because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity covers the privacy issue? If not what is the additional privacy concern? Andrew From: Tim Bray [mailto:tb...@textuality.com] Sent: Friday, July 19, 2013 12:07 PM Central Standard Time To: S Moonesamy sm+i...@elandsys.com Cc: IETF-Discussion Discussion ietf@ietf.org Subject: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy sm+i...@elandsys.commailto:sm+i...@elandsys.com wrote: It would be easier to have the draft discuss the GSMA URN only. The alternative is to have the draft discuss the privacy considerations of using IMEI and IMEISV. Good catch. Assuming this is a good idea (I’m dubious) it would be completely unacceptable to register it without a discussion of privacy implications. -T Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
Hm, I confess that I searched the text of the draft for the word “privacy” and jumped to conclusions upon seeing no matches. Probably a good idea to work it in for impatient folk like me. I would expand that section to point out that since the IMEI survives device wipes and changes of possession, it shouldn’t be assumed to identify a person. And I really wouldn’t ever expose an IMEI at the application level, but maybe it’s appropriate at the level this draft is addressing. We had endless nightmares, not only because of the wipe-survival, but because app code would try to run on a device that didn't have an IMEI and crash, and so on. -T On Fri, Jul 19, 2013 at 3:53 PM, Andrew Allen aal...@blackberry.com wrote: Tim Do you not think that the text in the security considerations section:: because IMEIs can be loosely correlated to a user, they need to be treated as any other personally identifiable information. In particular, the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity covers the privacy issue? If not what is the additional privacy concern? Andrew *From*: Tim Bray [mailto:tb...@textuality.com] *Sent*: Friday, July 19, 2013 12:07 PM Central Standard Time *To*: S Moonesamy sm+i...@elandsys.com *Cc*: IETF-Discussion Discussion ietf@ietf.org *Subject*: Re: Last call: draft-montemurro-gsma-imei-urn-16.txt On Fri, Jul 19, 2013 at 9:52 AM, S Moonesamy sm+i...@elandsys.comwrote: It would be easier to have the draft discuss the GSMA URN only. The alternative is to have the draft discuss the privacy considerations of using IMEI and IMEISV. Good catch. Assuming this is a good idea (I’m dubious) it would be completely unacceptable to register it without a discussion of privacy implications. -T Regards, S. Moonesamy - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
On 07/19/2013 11:53 PM, Andrew Allen wrote: the IMEI URN MUST NOT be included in messages intended to convey any level of anonymity That seems both perfect RFC 6919 fodder and disingenuous at the same time (how can a message convey a level of anonymity?). I need to read the draft but this seems like it only has downsides from a privacy perspective. So I'd hope there are compelling functional reasons to want it that outweigh the privacy downside. IMEIs are very pervasive, carried around by 100's of millions of people and generally not intended to be shared with the Internet. S.
Re: Last call: draft-montemurro-gsma-imei-urn-16.txt
IMEIs are very pervasive, carried around by 100's of millions of people and generally not intended to be shared with the Internet. my american social security card, which admittedly is a bit old, has Not to be used for identification emblazoned on it in red. for me, a seminal document was the 1973 Records, Computers, and the Rights Of Citizens, a report of the secretary's advisory committee on automated personal data systems of the us department of health, education, and welfare, chaired by willis ware. it spawned the privacy act of 1974, and i still have my copy. see [0]. it warned of the use the social seurity number as an identifier. [interestingly, mitre (also chaired by ware) did a report for the air force in '68 which reccomended the ssn as an id] today, in the states, the ssn is the ubiquitous identifier, and a major target of identity thieves and may be second only to cross site cookies as the identity target of marketeers. in the mobile society, the ids of our devices are becoming identy gold, and should be transmitted with extreme caution and only under compelling circumstances. randy -- [0] http://itlaw.wikia.com/wiki/Records,_Computers_and_the_Rights_of_Citizens
Last Call: draft-montemurro-gsma-imei-urn-16.txt (A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI)) to Informational RF
The IESG has received a request from an individual submitter to consider the following document: - 'A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI)' draft-montemurro-gsma-imei-urn-16.txt as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a Uniform Resource Name namespace for the GSMA (GSM Association)and a sub-namespace for the IMEI (International Mobile station Equipment Identity), and an associated parameter for the IMEISV (International Mobile station Equipment Identity and Software Version number). The IMEI is 15 decimal digits long and the IMEISV is 16 decimal digits long and both are encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV were introduced as part of the specification for Global System for Mobile communications(GSM) and are also now incorporated by the 3rd Generation Partnership Project (3GPP) as part of the 3GPP specification for GSM, the Universal Mobile Telecommunications System (UMTS) and 3GPP LTE (Long Term Evolution). The IMEI and IMEISV are used to uniquely identify Mobile Equipment within these systems and are managed by the GSMA. The file can be obtained via http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-montemurro-gsma-imei-urn/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1224/ http://datatracker.ietf.org/ipr/2090/ http://datatracker.ietf.org/ipr/2095/ http://datatracker.ietf.org/ipr/1213/ http://datatracker.ietf.org/ipr/1471/
