Subject: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 10:43:17 +0200

One of the "features" that this claims to be enable is:
"Ambient Listening", which seems to be having the device start recording
the environment without user consent or indication. This seems like an
anti-feature, especially in consumer devices.

-Ekr

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Jul 2016 10:16:23 -0400

> anti-feature, especially in consumer devices.

As far as I can tell, "Ambient Listening" is a feature of MCPTT, and
while the work in draft-holmberg-dispatch-mcptt-rp-namespace is needed
by MCPTT, the draft is not sufficient to enable "Ambient Listening".
The only argument I can see against proceeding with the draft is if we
wanted to reject the draft specifically to prevent MCPTT from being
implemented because we didn't like the "Ambient Listening" feature of
MCPTT.

And it does appear that 3GPP is aware of the privacy implications of
"Ambient Listening":

   MCPTT is primarily targeting to provide a professional Push To Talk
   service to e.g., public safety, transport companies, utilities or
   industrial and nuclear plants.  In addition to this a commercial PTT
   service for non-professional use (e.g., groups of people on holiday)
   may be delivered through an MCPTT system.  Based on their operational
   model, the performance and MCPTT features in use vary per user
   organization, where functionality which is more mission critical
   specific (e.g., Ambient Listening and Imminent Peril Call) might not
   be available to commercial customers.

Dale

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jul 2016 16:18:44 +0200

> implemented because we didn't like the "Ambient Listening" feature of

Yes, that's what I'm suggesting.

>    be available to commercial customers.

I found this section fairly unclear as to when these features would be
allowed.

-Ekr

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 18 Jul 2016 14:59:51 +0000

MC is for Mission Critical communications, not for commercial use. We would never expect this from a consumer UE.

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: [email-masked]<mailto:[email-masked]>

On Jul 18, 2016, at 10:47 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley <[email-masked]<mailto:[email-masked]>> wrote:

I found this section fairly unclear as to when these features would be allowed.

-Ekr

Dale

_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Andrew Allen <[email-masked]>
Date: Mon, 18 Jul 2016 16:59:31 +0000

Ekr

MCPTT uses RFC 5373 for auto answer triggering and is what enables the feature.

That RFC describes in detail the security/privacy concerns with auto answering and the "bug my phone" attack.

The ambient listening mode is for first responders such as police and fire fighters in situations when they are injured etc.

This mode would not be enabled in commercial applications.

Andrew

From: dispatch [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Monday, July 18, 2016 11:00 AM
To: Eric Rescorla <[email-masked]>
Cc: DISPATCH <[email-masked]>
Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01

Martin C Dolly

-Ekr

Dale

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 18 Jul 2016 19:36:56 +0200

> On 18 Jul 2016, at 18:59, Andrew Allen <[email-masked]> wrote:
> 
>  
> Ekr
>  
> That RFC describes in detail the security/privacy concerns with auto answering and the “bug my phone” attack.
>  
How can you be sure that no one will find any use case for that mode outside blue light areas?

/O
>  
> Andrew
>  
> From: dispatch [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of DOLLY, MARTIN C
> To: Eric Rescorla <[email-masked] <mailto:[email-masked]>>
> Cc: DISPATCH <[email-masked] <mailto:[email-masked]>>
> Email: [email-masked] <mailto:[email-masked]>
> 
> On Jul 18, 2016, at 10:47 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
>  
> On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley <[email-masked] <mailto:[email-masked]>> wrote:
> Eric Rescorla <[email-masked] <mailto:[email-masked]>> writes:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>_______________________________________________
> dispatch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2016 13:42:14 -0400

The key question to answer is: How can a *user* know it won't be enabled 
on his device?

	Thanks,
	Paul

On 7/18/16 1:36 PM, Olle E. Johansson wrote:
>
>> On 18 Jul 2016, at 18:59, Andrew Allen <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>> Ekr
>>
>> The ambient listening mode is for first responders such as police and
>> fire fighters in situations when they are injured etc.
>>
>> *From:* dispatch [mailto:[email-masked]] *On Behalf
>> Of *DOLLY, MARTIN C
>> *Sent:* Monday, July 18, 2016 11:00 AM
>> *To:* Eric Rescorla <[email-masked] <mailto:[email-masked]>>
>> *Cc:* DISPATCH <[email-masked] <mailto:[email-masked]>>
>> *Subject:* Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01
>>
>> MC is for Mission Critical communications, not for commercial use. We
>> would never expect this from a consumer UE.
>>
>> Martin C Dolly
>>     On Mon, Jul 18, 2016 at 4:16 PM, Dale R. Worley
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
> [email-masked]

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 18 Jul 2016 17:59:53 +0000

Cannot occur. 

Martin C Dolly
Email: [email-masked]

> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> The key question to answer is: How can a *user* know it won't be enabled on his device?
> 
>    Thanks,
>    Paul
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 18 Jul 2016 20:07:06 +0200

> On 18 Jul 2016, at 19:59, DOLLY, MARTIN C <[email-masked]> wrote:
> 
> Cannot occur. 
Does the protocol prohibit that? How? For all usages in all implementations?

/O

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jul 2016 18:22:39 +0000

Hi,

The person to whom you make the auto-answer call needs to authorize you to make such calls to that person. 

The service does NOT allow one to make auto-answer calls to "anyone".

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 18 July 2016 21:07
To: DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01

/O
> Core & Government/Regulatory Standards AT&T
> Cell: 609-903-3360
> Email: [email-masked]
> 
>>>> That RFC describes in detail the security/privacy concerns with 
>>>> auto answering and the "bug my phone" attack.
>>>> 
>>>> The ambient listening mode is for first responders such as police 
>>>> and fire fighters in situations when they are injured etc.
>>>> 
>>>> *From:* dispatch [mailto:[email-masked]] *On Behalf Of 
>>>> *DOLLY, MARTIN C
>>>> *Subject:* Re: [dispatch] 
>>>> draft-holmberg-dispatch-mcptt-rp-namespace-01
>>>> 
>>>> MC is for Mission Critical communications, not for commercial use. 
>>>> We would never expect this from a consumer UE.
>>>> 
>>>> Martin C Dolly
>>>> Core & Government/Regulatory Standards AT&T
>>>> Cell: 609-903-3360

---

From: Andrew Allen <[email-masked]>
Date: Mon, 18 Jul 2016 19:42:35 +0000

Totally agree with Christer and as I said all ‎these concerns are addressed in RFC 5373 which is the mechanism to get the device to auto answer in the first place.

Sent from my BlackBerry 10 smartphone.
  Original Message
From: Christer Holmberg
Sent: Monday, July 18, 2016 20:23
To: Olle E. Johansson; DOLLY, MARTIN C
Cc: [email-masked]
Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01

Hi,

Regards,

Christer

-----Original Message-----
From: dispatch [mailto:[email-masked]] On Behalf Of Olle E. Johansson
Sent: 18 July 2016 21:07
To: DOLLY, MARTIN C <[email-masked]>
Cc: [email-masked]
Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01

/O

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 18 Jul 2016 17:56:56 -0400

> I found this section fairly unclear as to when these features would be

True, but this isn't the document that defines MCPTT.

It's useful to be paranoid about "Ambient Listening", but there is no
technical solution.  Anyone can *already* build a UA that simply answers
an incoming call without notifying the user, and that function can be
triggered by any element of the INVITE request that is chosen.  And no
doubt such code is being maliciously inserted into UAs somewhere as we
discuss this.  The only mitigation is a proper regulatory framework to
protect the public, and proper legal enforcement.

What the IETF can do to help is ensure that the technical documents
clearly state what the regulators need to take into account.  It appears
that RFC 5373 is where that is done.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Jul 2016 18:54:22 -0400

> The service does NOT allow one to make auto-answer calls to "anyone".

And that authorization is performed by the user, in the device? (Not in 
the network.) And this can't be preconfigured by the SP as part of 
device provisioning? (At the same time they preinstall all those apps 
users don't want and can't remove.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 19 Jul 2016 04:37:57 +0000

Hi,

> And that authorization is performed by the user, in the device? (Not in the network.) And this can't be 
> preconfigured by the SP as part of device provisioning? (At the same time they preinstall all those apps 

Users need to be authorized in order to use the MCPTT service to begin with (with or without auto-answer). MCPTT is NOT a service that the "average consumer" can just download/preinstall, sign-up for and start using. MCPTT is a "tool" that can be used by authorized professionals (fire fighters, first responders, etc...) when performing their work.

Regards,

Christer

---

From: David Viamonte <[email-masked]>
Date: Tue, 19 Jul 2016 09:55:20 +0200

Just adding some context without entering the technical discussion: in
particular, this feature is also available in some of the traditional radio
systems that Public Safety and First Responders are using today. Since
MCPTT is intended to emulate and eventually replace those systems in the
future, the intention is that it should be able to mimick such features.

Hacing said this, like with many technical solutions, ways to misuse the
capability will certainly exist. Let's hope that having the capability
developed based on open standards may allow for controlling it in a more
transparent way than vendors implementing their own solutions each.

On Tue, Jul 19, 2016 at 6:37 AM, Christer Holmberg <
[email-masked]> wrote:

> the network.) And this can't be
> Users need to be authorized in order to use the MCPTT service to begin
> with (with or without auto-answer). MCPTT is NOT a service that the
> "average consumer" can just download/preinstall, sign-up for and start
> using. MCPTT is a "tool" that can be used by authorized professionals (fire
> fighters, first responders, etc...) when performing their work.
>
> Regards,
>
> Christer
>
>
>

---

From: Allen Richard <[email-masked]>
Date: Tue, 19 Jul 2016 21:08:46 +0000

Hi there,

I work for ESMCP, a programme in the UK to deliver public safety communications for the 3 Emergency Services. Specifically I have oversight on standards and assuring Public Safety Functionality in our future deployment.

I introduced the Ambient listening requirements in 3GPP, as this is one of our programme’s user requirements . As mentioned previously on the thread this replicates existing TETRA functionality deployed in our current nationwide TETRA network. This is used for emergency service users in distress and is also used to enable professional investigations. This functionality is very strictly controlled within a public safety environment (think system admins for user organisations) ,as it also has personal considerations there, because some will have dedicated devices that they don’t hand in at the end of the working day. This should be viewed in the same context as the professional tools we all use every day (I expect that this email has been scanned by my organisation to help guard against and investigate misconduct).

Cheers,
Richard

From: dispatch [mailto:[email-masked]] On Behalf Of David Viamonte
Sent: 19 July 2016 08:55
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [dispatch] draft-holmberg-dispatch-mcptt-rp-namespace-01

Just adding some context without entering the technical discussion: in particular, this feature is also available in some of the traditional radio systems that Public Safety and First Responders are using today. Since MCPTT is intended to emulate and eventually replace those systems in the future, the intention is that it should be able to mimick such features.

Hacing said this, like with many technical solutions, ways to misuse the capability will certainly exist. Let's hope that having the capability developed based on open standards may allow for controlling it in a more transparent way than vendors implementing their own solutions each.

On Tue, Jul 19, 2016 at 6:37 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

> From: dispatch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Olle E.
> Johansson
> Sent: 18 July 2016 21:07
> To: DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
>> On 18 Jul 2016, at 19:59, DOLLY, MARTIN C <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Cannot occur.
>> Cell: 609-903-3360<tel:609-903-3360>
>>> On Jul 18, 2016, at 1:42 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> On 18 Jul 2016, at 18:59, Andrew Allen <[email-masked]<mailto:[email-masked]>
>>>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>
>>>>>
>>>>> Ekr
>>>>>
>>>>> *From:* dispatch [mailto:[email-masked]<mailto:[email-masked]>] *On Behalf Of
>>>>> *DOLLY, MARTIN C
>>>>> *To:* Eric Rescorla <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>>>>> *Cc:* DISPATCH <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>
>>>>> Cell: 609-903-3360<tel:609-903-3360>
>>>>> Email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>>
>>>>>
>>>>> On Jul 18, 2016, at 10:47 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>
>>>>> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>   <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>>
>>>>>       Eric Rescorla <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> writes:
>>>>>   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

**********************************************************************
This email and any files transmitted with it are private and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please return it to the address
it came from telling them it is not for you and then delete it from your system.
This email message has been swept for computer viruses.

**********************************************************************