Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29

Randall Gellens <rg+ietf@qti.qualcomm.com> Fri, 10 July 2015 01:47 UTC

Return-Path: <rg+ietf@qti.qualcomm.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F71D1A21B7 for <ecrit@ietfa.amsl.com>; Thu, 9 Jul 2015 18:47:43 -0700 (PDT)
X-Quarantine-ID: <mrWoxv2t3xon>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrWoxv2t3xon for <ecrit@ietfa.amsl.com>; Thu, 9 Jul 2015 18:47:41 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A341A1B9A for <ecrit@ietf.org>; Thu, 9 Jul 2015 18:47:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1436492861; x=1468028861; h=message-id:in-reply-to:references:date:to:from:subject: cc; bh=AYMnJTtFin9z2Z21rDMbcBw3oofaBrZOr3DkZib6kfk=; b=OpPLgaGC5HpyGQlpe0YnMqNBOztEOMRxrclUHc+Ch4DhS5YTPlimNLkF VgB2kh74Vo5B3lbbHRFCyQoWLoTqGYdJtJAvi2GHRyTQMdS87Eg+n0RHf k7wO+FFdPXMmO8RGavtbqQNqTFxguxvjd4duu1rr4quBbF2wEQqxlvQ0i s=;
X-IronPort-AV: E=McAfee;i="5700,7163,7857"; a="219766187"
Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 18:47:41 -0700
X-IronPort-AV: E=Sophos;i="5.15,443,1432623600"; d="scan'208";a="1010747847"
Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jul 2015 18:47:41 -0700
Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t6A1ldk7012185; Thu, 9 Jul 2015 18:47:40 -0700
X-IronPort-AV: E=Sophos;i="5.15,443,1432623600"; d="scan'208";a="957687318"
X-ojodefuego: yes
Received: from unknown (HELO [99.111.97.136]) ([10.64.162.243]) by Ironmsg03-R.qualcomm.com with ESMTP; 09 Jul 2015 18:47:38 -0700
Mime-Version: 1.0
Message-Id: <p0624060ad1c4cfdd4c23@[99.111.97.136]>
In-Reply-To: <AA8402BC-217E-4072-94A6-4C9B3BB2A08B@cooperw.in>
References: <99E88B8D-C7E1-4C33-A5FC-45E105D28580@cooperw.in> <p06240600d194f63d737f@[99.111.97.136]> <AA8402BC-217E-4072-94A6-4C9B3BB2A08B@cooperw.in>
X-Mailer: Eudora for Mac OS X
Date: Thu, 09 Jul 2015 18:47:37 -0700
To: Alissa Cooper <alissa@cooperw.in>
From: Randall Gellens <rg+ietf@qti.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
X-Random-Sig-Tag: 1.0b28
Archived-At: <http://mailarchive.ietf.org/arch/msg/ecrit/KnKFDwEJ3rLqJwKxUsnUj3gtQgE>
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] AD review: draft-ietf-ecrit-additional-data-29
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2015 01:47:43 -0000

At 3:19 PM -0700 7/9/15, Alissa Cooper wrote:

>  Hi Randy,
>
>  Thanks for addressing my comments. I have one follow-up below.

Hi Alissa,

Thanks very much.  Please see in-line.

>  On Jun 28, 2015, at 6:53 PM, Randall Gellens 
> <rg+ietf@qti.qualcomm.com> wrote:
>
>>>
>>>  Section 4.3.4:
>   >> I'm curious about the kinds of "investigations"
>>>  that PSAPs do and how they have used unique
>>>  device IDs in those investigations -- could you
>>>  explain? At first blush this seems to require
>>>  over-sharing of sensitive data.
>>
>>  The most common situation that I'm aware of is
>   > repeated false/accidental calls.  If there is no
>>  callback number or it isn't usable, the PSAP may
>>  need to try and track down the device by
>>  contacting the service providers in the area.  In
>>  the case of handsets without current service,
>>  they may be able to determine who last had
>   > service. 
>
>  How does the user make an emergency call without current service?

It varies by region; for example, in the U.S. and some European 
countries, telephone companies (cellular and wirelines) are required 
to provide emergency access (911 or 112) even if the device or 
landline has no service.  So, old cell phones that haven't had 
service in years can still be used to dial 911 (or 112), and 
landlines that have been turned off for non-payment can usually still 
dial 911.  The situation with landlines is a little different from 
cell phones, so there can be a completely dead landline that is 
unable to dial 911.  PSAPs do get lots false calls from old cell 
phones that parents have given to kids as toys, for example.  Or 
older kids who think it's funny.

>   > There could be other situations where
>>  this might be useful (e.g., a disconnected call
>>  where the call taker believes there is a need for
>>  assistance but was not able to obtain a location
>   > or other information).
>
>  It would be helpful if the above explanation could be included in the draft.

I have added this.

>  Given the explanation above, does it really make sense for the 
> device to be providing this information in addition to the service 
> provider? That is, the device may have many possible device IDs 
> that it could include, but it may not know which ones the service 
> provider collects and correlates to specific users, so it won't 
> necessarily know which ones to provide. Given that all of these IDs 
> can be uniquely identifying in different contexts, providing 
> multiple IDs that won't get used seems like not the best idea. And 
> if the user is abusing the emergency call system, he won't include 
> these anyway.

An attacker won't include the information (or would include fake 
information), but a legitimate device that is used by someone playing 
pranks, or kids as a toy, or someone who does need help and is using 
a device without service and can't provide any other information, 
would include information, and in these cases, it's better if the 
device includes it, since it's not clear what the service provider 
knows or will provide.

>  Are we sure that all of the device types specified actually get 
> used in this way by PSAPs? E.g., I was curious about whether 
> service providers track device RFIDs.

I'm not aware of this being common with consumer devices, but it 
could happen with specialized devices.

>
>  I also think, as much as I dislike the subscriber privacy indicator 
> specified in 4.4.1, it should cover this data element as well, 
> particularly since this element can be inserted by the service 
> provider without the user knowing.

The thing about the subscriber privacy indicator is that it's up to 
local regulation what elements it covers and what it means.  I don't 
think we can dictate that.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Whenever you find that you are on the side of the majority,
it is time to reform.                         --Mark Twain