Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt

From: James Hamlin <[email-masked]>
Date: Mon, 21 Sep 2020 09:04:32 +0000

Brian

Thanks for the new draft.

I think the final sentence in section 5.2.5. "Emergency Calls" is out of scope, as it tries to define the interface between the VRS provider and the PSAP. From the rest of the text, the purpose of the data exchange between RUE and VRS provider is already clear; the final sentence could be dropped without detracting from the description of the RUM interface. I propose dropping the text: "Providers MUST implement Data Provider and Service Information blocks as the call is forwarded to the PSAP.".

Best Regards

James

[X][X]

[X]James Hamlin
Contractor
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Sep 2020 10:47:42 -0400

James,

Since you are the one VRS Provider person who regularly contributes 
here, can I ask you to help a bit more?

Back when we started this work with Henning several years ago a major 
concern of the providers was to find a mechanism to easily and cheaply 
restrict access to RUE implementations that have been tested/certified. 
The goal as I understand it was to avoid subjecting the provider systems 
to attacks. But to date we haven't identified a mechanism for doing this 
that actually works. At the moment there is nothing in the draft for that.

I have been arguing that web servers don't limit access to certified web 
browsers and they manage to survive. But still I am willing to entertain 
including a mechanism if we could find one that is workable.

Would you be willing to work on this with us? In particular, to start, 
identify the particular concerns and the level of effort that is/isn't 
acceptable to identify and reject uncertified clients.

	Thanks,
	Paul

On 9/21/20 5:04 AM, James Hamlin wrote:
> I think the final sentence in section 5.2.5. "Emergency Calls" is out of 
> scope, as it tries to define the interface between the VRS provider and 
> the PSAP. From the rest of the text, the purpose of the data exchange 
> between RUE and VRS provider is already clear; the final sentence could 
> be dropped without detracting from the description of the RUM interface. 
> I propose dropping the text/: "Providers MUST implement Data Provider 
> and Service Information blocks as the call is forwarded to the PSAP."./
> 
> 
> Best Regards
> 
> 
> James
> 
> 
> James Hamlin
> Contractor
> The information contained in this e-mail message is intended only for 
> the personal and confidential use of the recipient(s) named above. If 
> you have received this communication in error, please notify us 
> immediately by e-mail, and delete the original message.
> 
>

---

From: James Hamlin <[email-masked]>
Date: Thu, 24 Sep 2020 06:58:59 +0000

Hi Paul

Agreed, the background to this is that VRS Providers wish to provide controlled, limited access to 3rd party applications so as to protect their services from bad actors and misbehaving Apps. And I don't think a solution had been fully agreed.

Best regards

James

James Hamlin
Contractor

________________________________________
From: Paul Kyzivat <[email-masked]>
Sent: 21 September 2020 15:47
To: James Hamlin
Cc: [email-masked]
Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt

James,

        Thanks,
        Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 24 Sep 2020 09:39:29 -0400

Are there any solution proposals?

The solutions for this class of problem that I know about require a closed environment, where there is some trust (here between the environment creator and the providers), and there is some kind of signature on the code.  The environment refuses to execute code that is not signed, and checks the signature digest against the code digest.

We don’t have such an environment, so I am at a loss to suggest any solution.

> On Sep 24, 2020, at 2:58 AM, James Hamlin <[email-masked]> wrote:
> 
> Hi Paul
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Sep 2020 10:55:22 -0400

> We don’t have such an environment, so I am at a loss to suggest any solution.

+1. That has been the problem from the beginning.

So James, do you have an idea for how to solve this, or know someone who 
does?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Sep 2020 11:03:44 -0400

James,

On 9/24/20 10:55 AM, Paul Kyzivat wrote:
>> The solutions for this class of problem that I know about require a 
>> closed environment, where there is some trust (here between the 
>> environment creator and the providers), and there is some kind of 
>> signature on the code.  The environment refuses to execute code that 
>> is not signed, and checks the signature digest against the code digest.
>>

Some further questions on this:

With your existing proprietary solutions do you have a way to prevent 
someone from emulating your client device, and possibly hacking it is a 
malicious way?

Are you depending on security by obscurity?

	Thanks,
	Paul