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

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 <james.hamlin@purple.us> wrote:
> 
> 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
> 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 <pkyzivat@alum.mit.edu>
> Sent: 21 September 2020 15:47
> To: James Hamlin
> Cc: rum@ietf.org
> Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-03.txt
> 
> 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:
>> 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
>> 
>> 
>> 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.
>> 
>> 
> 
> 
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum