Subject: Re: [Rum] encryption

From: Ed Sayers <[email-masked]>
Date: Tue, 31 Aug 2021 09:29:59 +0000

Hi,

Thought I'd split out IPv6 and encryption as separate points..

For encryption, the US VRS Providers recently created a new Provider Inter-Operability Profile that now specifically allows for encryption and ICE, amongst other things.

Whilst we all agreed that SRTP-DTLS is the right way to go, we decided to specifically adopt RFC-8643 OSRTP, because this allows for the greatest flexibility and greatest chance of supporting end-to-end encryption, while still supporting a heterogenous range of devices.

Whilst it is true that encryption could be terminated on the RUE interface proxy, any Provider that wants to allow encryption further into their Infrastructure is generally faced with the potential need to fork calls to various devices, possibly only some of which support encryption. Using RFC-5673 alone would mean that older devices that do not support encryption would reject the call as unsupported.

Using OSRTP is by far the simplest and most convenient way to fork the call and still ensure that the widest range of endpoints can ring.

Cheers,

Ed Sayers
Endpoint SDK Team Lead
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.

-----Original Message-----
From: Rum <[email-masked]> On Behalf Of Brian Rosen
Sent: 30 August 2021 22:24
To: Paul Kyzivat <[email-masked]>
Cc: Chad Leeper <[email-masked]>; [email-masked]
Subject: Re: [Rum] IPv6 and encryption

I don’t think there are ANY alternatives to SRTP.  There are alternatives to DTLS-SRTP.  There are moves within the IETF to deprecate SDES, specifically.  There is push back on that, but it’s an ongoing discussion because SDES isn’t secure enough.   Since all providers I know about anchor media, this only affects the initial hop.  Users really want to hear that their media is protected end to end (at least hop by hop) but our document doesn’t require that.  Again, we need a STANDARDS based solution, and we have to live within the constraints the IETF has for new standards with respect to security.  Like nearly every organization, the IETF is much more security conscious than it was, and won’t tolerate bad security although it often recognizes the necessity for backwards compatibility as long as it’s not to a known insecure mechanism.  

I really think this is a “step up to the bar” thing.  We’ve spent lots of time and cycles implementing things that turn out not to be secure enough, and we have to move forward on things that are.  DTLS-SRTP is one of those things, as is IPv6.

Brian

> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> Chad,
> 
> Welcome to the RUM WG!
> 
> On 8/30/21 11:51 AM, Chad Leeper wrote:
>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going forward, it can't be a "MUST" requirement.  I agree with Roger Slusser that mandating compliance using MUST requires providers to implement significant development to change over to what RUM is specifying.
> 
> The requirements in this doc will apply only to devices that claim to conform to it. Presumably you could continue to support your existing devices using whatever mechanisms they currently use. So the implementation burden is only on the server side, not the legacy device side. (Of course the FCC will have a say in this.)
> 
> One motivation for the webrtc requirement is so that a RUE can be built on top of WebRTC. E.g., it can be a server that supports deaf users using any device with a browser. Such a server is effectively just signaling gateway that can establish a p2p link between the browser and the VRS provider server. (It does have to transcode RTT, but that is less of a burden.)
> 
> When defining a specification for an interface that is to be implemented by independent parties it is necessary for essential functions to have at least one mandatory to implement mechanism. Currently there are no standards for connecting a RUE to a provider, so we need to pick *something* to be mandatory to implement. If you have an alternative for the media you would prefer, then please make a specific proposal.
> 
>> - We should keep any new privacy requirements very minimal at this time.  While companies in the EU have already created their systems in compliance with the GDPR, most of the world hasn't created an equivalent yet.  So what may look like an easy change to EU implementers may be a dramatic change for others.
> 
> I don't think we have said much about privacy of retained data. But we are concerned that the media and signaling be private between the RUE and the provider. That is a low bar these days. It is unlikely that anything less could be approved. I expect the FCC will agree.
> 
> If you have an alternate proposal that achieves that then make a proposal we can discuss.
> 
> 	Thanks,
> 	Paul
> 
>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
>>    Providers,
>>    My request below to Roger should have been broader. You all seem to
>>    have
>>    the same issue. I encourage any/all of you to make an alternative
>>    proposal here. Just saying "we don't like what is there" isn't helpful
>>    without an alternative.
>>             Thanks,
>>             Paul
>>    On 8/26/21 5:40 PM, Paul Kyzivat wrote:
>>     > Roger,
>>     >
>>     > On 8/26/21 3:30 PM, Roger Slusser wrote:
>>     >
>>     >> Most providers already support encryption and IPV6 on a limited
>>    scope,
>>     >> not necessarily the way it is defined in RUM spec. Mandating
>>     >> compliance using MUST requires providers to discard sometimes huge
>>     >> amounts of development to change over to what RUM is specifying.
>>    The
>>     >> push back is not about doing these things it is about the loss of
>>     >> time, effort and money to do them in the way RUM mandates with
>>    MUSTs.
>>     >
>>     > Do you think there is something else we could write in this spec
>>    that
>>     > covers encryption and IPv6 in a way that is less burdensome for
>>     > providers while remaining interoperable with all providers?
>>     >
>>     > If so, can you please spell it out?
>>    --     Rum mailing list
>>    [email-masked] <mailto:[email-masked]>
>>    https://www.ietf.org/mailman/listinfo/rum
>>    <https://www.ietf.org/mailman/listinfo/rum>
> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

-- 
Rum mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rum

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 31 Aug 2021 12:11:49 +0200

> On 31 Aug 2021, at 11:29, Ed Sayers <[email-masked]> wrote:
> 
> Hi,
> 
OSRTP supports SRTP-DTLS. It’s not an alternative. And it’s just an informational RFC, not a standards RFC.You still have to implement SRTP-DTLS so you can use that fully in a situation where all devices has support.

There are other ways to construct the SDP if you want to offer both RTP/SAVP and RTP/AVP, but that opens up
for downgrade attacks, so one need serious consideration.
> 
> Whilst it is true that encryption could be terminated on the RUE interface proxy,
Aren’t you mixing signalling and media now?

> any Provider that wants to allow encryption further into their Infrastructure is generally faced with the potential need to fork calls to various devices, possibly only some of which support encryption. Using RFC-5673 alone would mean that older devices that do not support encryption would reject the call as unsupported.

Isn’t that one of the benefits? A user needs to be assured that the call is protected. As a provider you may need to have gateways to the old world if you need that, but still keep the first call leg encrypted at all times.
> Using OSRTP is by far the simplest and most convenient way to fork the call and still ensure that the widest range of endpoints can ring.
But it doesn’t deliver any guarantee of any kind to the user.

/O

---

From: Ed Sayers <[email-masked]>
Date: Tue, 31 Aug 2021 10:30:19 +0000

Hi,

Inline below..

Ed Sayers
Endpoint SDK Team Lead

-----Original Message-----
From: Olle E. Johansson <[email-masked]> 
Sent: 31 August 2021 11:12
To: Ed Sayers <[email-masked]>
Cc: Brian Rosen <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Rum] encryption

EdS - We know it is not an alternative. It simply revert the profile to RTP/AVP, while keeping the fingerprint and setup attributes. This means that an endpoint that sees the attributes can replay likewise and agree SRTP-DTLS. Old endpoints ignore the attributes and can still answer the call.

There are other ways to construct the SDP if you want to offer both RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so one need serious consideration.

EdS - Typically, older endpoints also would not support this, which is the benefit of OSRTP - It is backwardly compatible.

EdS - I am missing what you mean here.

EdS - From a customer standpoint, having a range of devices no longer ring is not a benefit. Using OSRTP as a migration path to support end-to-end encryption while older devices can be gradually 'aged out'.
The user might otherwise have an illusion of security - terminated at the RUM proxy, while the endpoint on the other end is not encrypted (because it cannot support it).

EdS - It provides a progression where more and more endpoints over time can be encrypted. Precisely why we adopted it on the Inter-Provider interface.

/O
> 
> Cheers,
> 
> 
> Ed Sayers
> Endpoint SDK Team Lead
> Purple, a Division of ZP Better Together, LLC purplevrs.com
> 
>> The requirements in this doc will apply only to devices that claim to 
>> conform to it. Presumably you could continue to support your existing 
>> devices using whatever mechanisms they currently use. So the 
>> implementation burden is only on the server side, not the legacy 
>> device side. (Of course the FCC will have a say in this.)
>> 
>> One motivation for the webrtc requirement is so that a RUE can be 
>> built on top of WebRTC. E.g., it can be a server that supports deaf 
>> users using any device with a browser. Such a server is effectively 
>> just signaling gateway that can establish a p2p link between the 
>> browser and the VRS provider server. (It does have to transcode RTT, 
>> but that is less of a burden.)
>>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 08:30:16 -0400

Are you proposing this in addition to requiring DTLS-STRP or instead of it?

Would two users doing point to point calling through typical providers that anchor media reliably get a secure connection hop-by-hop if both users and both providers had conforming implementations and the providers implemented the new inter-provider spec?

User 1   Provider 1     Provider 2     User 2
     DTLS-         DTLS=          DTLS-
     SRTP          SRTP           SRTP      

> On Aug 31, 2021, at 6:30 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi,
> 
> Inline below..
> 
> 
> Ed Sayers
> Endpoint SDK Team Lead
> purplevrs.com <http://purplevrs.com/>
> 
> From: Olle E. Johansson <[email-masked] <mailto:[email-masked]>> 
> To: Ed Sayers <[email-masked] <mailto:[email-masked]>>
> Cc: Brian Rosen <[email-masked] <mailto:[email-masked]>>; Paul Kyzivat <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Ed Sayers <[email-masked]>
Date: Tue, 31 Aug 2021 13:06:14 +0000

Hi Brian,

I would say that OSRTP is more a way of negotiating SRTP. It allows older endpoints that can’t/don’t support encryption to still potentially participate in a call.

Yes, the intention of adding OSRTP to the updated Inter-Provider specification was to allow the possibility of end-to-end SRTP-DTLS encryption between the endpoints of two different Providers once supported (or passed on) where possible.

We thought this to be the best balance between adding burdensome complexity, calls failing out-right or some devices not ringing, whilst still allowing encryption whenever it possibly could be.

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<https://purplevrs.com/>

[Purple is DEI certified!]
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: Brian Rosen <[email-masked]>
Sent: 31 August 2021 13:30
To: Ed Sayers <[email-masked]>
Cc: Olle E. Johansson <[email-masked]>; Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [Rum] encryption

On Aug 31, 2021, at 6:30 AM, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Inline below..

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com<http://purplevrs.com/>

-----Original Message-----
From: Olle E. Johansson <[email-masked]<mailto:[email-masked]>>
Sent: 31 August 2021 11:12
To: Ed Sayers <[email-masked]<mailto:[email-masked]>>
Cc: Brian Rosen <[email-masked]<mailto:[email-masked]>>; Paul Kyzivat <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] encryption

On 31 Aug 2021, at 11:29, Ed Sayers <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Whilst it is true that encryption could be terminated on the RUE
interface proxy,

/O

Cheers,

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC purplevrs.com<http://purplevrs.com>

-----Original Message-----
From: Rum <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Rosen
Sent: 30 August 2021 22:24
To: Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Cc: Chad Leeper <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rum] IPv6 and encryption

Brian

On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Chad,

Welcome to the RUM WG!

                Thanks,
                Paul

On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
 Providers,

Roger,

If so, can you please spell it out?
 --     Rum mailing list
 [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
 https://www.ietf.org/mailman/listinfo/rum
 <https://www.ietf.org/mailman/listinfo/rum>

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Aug 2021 10:15:39 -0400

I was involved in adding OSRTP to the VRS Provider Profile. This was an 
upgrade from the prior version that had no security. The bid down risk 
was understood. The point was to provide a mechanism to phase in the 
secure mechanisms while not requiring a flag day for all providers to 
upgrade. It is important to understand that the connections between 
providers is a small closed community regulated by the FCC. It was my 
expectation (and I think also the providers) that this was a transition 
step, and that once all providers had upgraded to it then a subsequent 
version will remove the optionality.

But that is the private world of provider interconnection. The situation 
with RUEs connecting to providers has quite different constraints. For 
one, it is a new interface being implemented for the first time by both 
provider servers and RUE developers. So the need to phase it in is 
different. It will be realized as users migrate from proprietary devices 
to standard RUEs. Also, these connections are over the wild and woolly 
internet and so more concerning for attacks.

	Thanks,
	Paul

On 8/31/21 9:06 AM, Ed Sayers wrote:
> Hi Brian,
> 
> I would say that OSRTP is more a way of negotiating SRTP. It allows 
> older endpoints that can’t/don’t support encryption to still potentially 
> participate in a call.
> 
> Yes, the intention of adding OSRTP to the updated Inter-Provider 
> specification was to allow the possibility of end-to-end SRTP-DTLS 
> encryption between the endpoints of two different Providers once 
> supported (or passed on) where possible.
> 
> We thought this to be the best balance between adding burdensome 
> complexity, calls failing out-right or some devices not ringing, whilst 
> still allowing encryption whenever it possibly could be.
> 
> Cheers,
> 
> **
> 
> *Ed Sayers*
> Endpoint SDK Team Lead
> purplevrs.com <https://purplevrs.com/>
> 
> 	
> 
> Purple is DEI certified!
> 
> 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:*Brian Rosen <[email-masked]>
> *Sent:* 31 August 2021 13:30
> *To:* Ed Sayers <[email-masked]>
> *Cc:* Olle E. Johansson <[email-masked]>; Paul Kyzivat 
> <[email-masked]>; [email-masked]
> *Subject:* Re: [Rum] encryption
> 
> Would two users doing point to point calling through typical providers 
> that anchor media reliably get a secure connection hop-by-hop if both 
> users and both providers had conforming implementations and the 
> providers implemented the new inter-provider spec?
> 
>     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.
> 
> 
> 
> 
>     Cc: Brian Rosen <[email-masked] <mailto:[email-masked]>>; Paul
>     Kyzivat <[email-masked]
>     <mailto:[email-masked]>>;[email-masked] <mailto:[email-masked]>
>         For encryption, the US VRS Providers recently created a new
>         Provider Inter-Operability Profile that now specifically allows
>         for encryption and ICE, amongst other things.
> 
>         Whilst we all agreed that SRTP-DTLS is the right way to go, we
>         decided to specifically adopt RFC-8643 OSRTP, because this
>         allows for the greatest flexibility and greatest chance of
>         supporting end-to-end encryption, while still supporting a
>         heterogenous range of devices.
> 
> 
> 
>     OSRTP supports SRTP-DTLS. It’s not an alternative. And it’s just an
>     informational RFC, not a standards RFC.You still have to implement
>     SRTP-DTLS so you can use that fully in a situation where all devices
>     has support.
> 
>     EdS - We know it is not an alternative. It simply revert the profile
>     to RTP/AVP, while keeping the fingerprint and setup attributes. This
>     means that an endpoint that sees the attributes can replay likewise
>     and agree SRTP-DTLS. Old endpoints ignore the attributes and can
>     still answer the call.
> 
>     There are other ways to construct the SDP if you want to offer both
>     RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so
>     one need serious consideration.
> 
>     EdS - Typically, older endpoints also would not support this, which
>     is the benefit of OSRTP - It is backwardly compatible.
> 
> 
> 
>         any Provider that wants to allow encryption further into their
>         Infrastructure is generally faced with the potential need to
>         fork calls to various devices, possibly only some of which
>         support encryption. Using RFC-5673 alone would mean that older
>         devices that do not support encryption would reject the call as
>         unsupported.
> 
> 
>     Isn’t that one of the benefits? A user needs to be assured that the
>     call is protected. As a provider you may need to have gateways to
>     the old world if you need that, but still keep the first call leg
>     encrypted at all times.
> 
>     EdS - From a customer standpoint, having a range of devices no
>     longer ring is not a benefit. Using OSRTP as a migration path to
>     support end-to-end encryption while older devices can be gradually
>     'aged out'.
>     The user might otherwise have an illusion of security - terminated
>     at the RUM proxy, while the endpoint on the other end is not
>     encrypted (because it cannot support it).
> 
> 
> 
>         Using OSRTP is by far the simplest and most convenient way to
>         fork the call and still ensure that the widest range of
>         endpoints can ring.
> 
> 
>     EdS - It provides a progression where more and more endpoints over
>     time can be encrypted. Precisely why we adopted it on the
>     Inter-Provider interface.
> 
> 
>     /O
> 
> 
>         Cheers,
> 
> 
>         Ed Sayers
>         Endpoint SDK Team Lead
>         <http://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: Rum <[email-masked] <mailto:[email-masked]>>
>         On Behalf Of Brian Rosen
>         Cc: Chad Leeper <[email-masked]
>         <mailto:[email-masked]>>; [email-masked]
>         <mailto:[email-masked]>
>         I don’t think there are ANY alternatives to SRTP.  There are
>         alternatives to DTLS-SRTP.  There are moves within the IETF to
>         deprecate SDES, specifically.  There is push back on that, but
>         it’s an ongoing discussion because SDES isn’t secure enough.
>            Since all providers I know about anchor media, this only
>         affects the initial hop.  Users really want to hear that their
>         media is protected end to end (at least hop by hop) but our
>         document doesn’t require that.  Again, we need a STANDARDS based
>         solution, and we have to live within the constraints the IETF
>         has for new standards with respect to security.  Like nearly
>         every organization, the IETF is much more security conscious
>         than it was, and won’t tolerate bad security although it often
>         recognizes the necessity for backwards compatibility as long as
>         it’s not to a known insecure mechanism.
> 
>         I really think this is a “step up to the bar” thing.  We’ve
>         spent lots of time and cycles implementing things that turn out
>         not to be secure enough, and we have to move forward on things
>         that are.  DTLS-SRTP is one of those things, as is IPv6.
> 
>         Brian
> 
> 
> 
>             On Aug 30, 2021, at 5:06 PM, Paul Kyzivat
>             <[email-masked] <mailto:[email-masked]>> wrote:
> 
>             Chad,
> 
>             Welcome to the RUM WG!
> 
>                 - While WebRTC w/ SRTP/DTLS (encryption) is an excellent
>                 idea going forward, it can't be a "MUST" requirement. I
>                 agree with Roger Slusser that mandating compliance using
>                 MUST requires providers to implement significant
>                 development to change over to what RUM is specifying.
> 
> 
>             When defining a specification for an interface that is to be
>             implemented by independent parties it is necessary for
>             essential functions to have at least one mandatory to
>             implement mechanism. Currently there are no standards for
>             connecting a RUE to a provider, so we need to pick
>             *something* to be mandatory to implement. If you have an
>             alternative for the media you would prefer, then please make
>             a specific proposal.
> 
> 
>                 - We should keep any new privacy requirements very
>                 minimal at this time.  While companies in the EU have
>                 already created their systems in compliance with the
>                 GDPR, most of the world hasn't created an equivalent
>                 yet.  So what may look like an easy change to EU
>                 implementers may be a dramatic change for others.
> 
> 
>             I don't think we have said much about privacy of retained
>             data. But we are concerned that the media and signaling be
>             private between the RUE and the provider. That is a low bar
>             these days. It is unlikely that anything less could be
>             approved. I expect the FCC will agree.
> 
>                 On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat
>                 <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>> wrote:
>                   Providers,
>                 [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>                 <mailto:[email-masked]>>
>                   <https://www.ietf.org/mailman/listinfo/rum
>                 <https://www.ietf.org/mailman/listinfo/rum>>
> 
> 
>             --
>             Rum mailing list

---

From: Brian Rosen <[email-masked]>
Date: Tue, 31 Aug 2021 10:19:47 -0400

Okay.

First, let me say that I am VERY willing to add a requirement to support OSRTP if it means we get consensus on this issue.  Full stop.

But I want to ask if, on the RUE interface, it has any actual meaning.

If, as I understand it, providers world wide universally have a media anchor and B2BUA connecting to a user for all calls, then the provider’s RUE interface is there, at that B2BUA/media anchor.  If the provider upgrades to a conforming RUE interface, it supports DTLS-SRTP.  If a client RUE implements a conforming interface, it supports DTLS-SRTP, and the client can make a call to/through that provider with the first leg encrypted.  Same for a call received by the RUE.  So, if both sides conform, we don’t need OSRTP.

The only thing this seems to help is allowing a RUE to connect to a provider that doesn’t yet support our document.  Then you don’t fail the call.  I’m not clear if that should be a requirement on the client.  SHOULD maybe.

Again, very willing to add a MUST requirement to support 5673 if that gets us consensus on this issue.

Brian

> On Aug 31, 2021, at 9:06 AM, Ed Sayers <[email-masked]> wrote:
> 
> Hi Brian,
>  
> On Aug 31, 2021, at 6:30 AM, Ed Sayers <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
> 
> Inline below..
> 
> 
> Ed Sayers
> Endpoint SDK Team Lead
> On 31 Aug 2021, at 11:29, Ed Sayers <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi,
> 
> Purple, a Division of ZP Better Together, LLC purplevrs.com <http://purplevrs.com/>
> 
> From: Rum <[email-masked] <mailto:[email-masked]>> On Behalf Of Brian Rosen
> To: Paul Kyzivat <[email-masked] <mailto:[email-masked]>>
> Cc: Chad Leeper <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Chad,
> 
> Welcome to the RUM WG!
> 
> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>  Providers,
>  [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>  https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
>  <https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>>
> 
> --
> Rum mailing list
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> 
> --
> Rum mailing list
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>
> --
> Rum mailing list
> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 31 Aug 2021 16:41:55 +0200

I propose that all RUE devices need to support DTLS-SRTP and not anything else. Gateway to old devices has to be seen as a service provider problem. 

Oppurtunistic crypto doesn’t guarantee privacy at all and is wide open for middlemen to downgrade the call and listen in.

I do agree that it is simpler for a service provider to say “oh, some calls randomly will be encrypted”. But we can surely expect better. 

All of these discussions where part of the WebRTC standardization process. The documents ended up with DTLS-SRTP as a requirement. I don’t expect the IETF to move backwards here.

/O

> On 31 Aug 2021, at 14:30, Brian Rosen <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 31 Aug 2021 12:15:25 -0400

On 8/31/21 10:19 AM, Brian Rosen wrote:
> Okay.
> 
> First, let me say that I am VERY willing to add a requirement to support 
> OSRTP if it means we get consensus on this issue.  Full stop.
> 
> If, as I understand it, providers world wide universally have a media 
> anchor and B2BUA connecting to a user for all calls, then the provider’s 
> RUE interface is there, at that B2BUA/media anchor.  If the provider 
> upgrades to a conforming RUE interface, it supports DTLS-SRTP.  If a 
> client RUE implements a conforming interface, it supports DTLS-SRTP, and 
> the client can make a call to/through that provider with the first leg 
> encrypted.  Same for a call received by the RUE.  So, if both sides 
> conform, we don’t need OSRTP.
> 
> The only thing this seems to help is allowing a RUE to connect to a 
> provider that doesn’t yet support our document.  Then you don’t fail the 
> call.  I’m not clear if that should be a requirement on the client. 

IIUC the interface that providers currently provide to currently 
deployed devices is substantially different than the RUE spec as it 
stands today.

So to support the RUE spec the provider servers will need some new 
implementations work. They will probably want to support their old 
devices for awhile, so there will be two interfaces running side by side 
on those servers.

I don't see how OSRTP would help in this environment. The new interface 
only needs to support DTLS/SRTP, while the old one does whatever it does.

Or is the problem around migration of existing deployed devices to 
support the RUE spec? Are you concerned that some devices won't be 
capable of being upgraded to support DTLS/SRTP?

	Thanks,
	Paul

>   SHOULD maybe.
>> On Aug 31, 2021, at 9:06 AM, Ed Sayers <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Brian,
>> older endpoints that can’t/don’t support encryption to still 
>> potentially participate in a call.
>> complexity, calls failing out-right or some devices not ringing, 
>> whilst still allowing encryption whenever it possibly could be.
>> Cheers,
>>
>> **
>>
>> *Ed Sayers*
>> Endpoint SDK Team Lead
>> *From:*Brian Rosen <[email-masked] <mailto:[email-masked]>>
>> *Sent:*31 August 2021 13:30
>> *To:*Ed Sayers <[email-masked] <mailto:[email-masked]>>
>> *Cc:*Olle E. Johansson <[email-masked] <mailto:[email-masked]>>; Paul 
>> Kyzivat <[email-masked] <mailto:[email-masked]>>; 
>> [email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [Rum] encryption
>>     Cc: Brian Rosen <[email-masked] <mailto:[email-masked]>>;
>>     Paul Kyzivat <[email-masked]
>>         Provider Inter-Operability Profile that now specifically
>>         allows for encryption and ICE, amongst other things.
>>
>>     OSRTP supports SRTP-DTLS. It’s not an alternative. And it’s just
>>     an informational RFC, not a standards RFC.You still have to
>>     implement SRTP-DTLS so you can use that fully in a situation where
>>     all devices has support.
>>
>>     EdS - We know it is not an alternative. It simply revert the
>>     profile to RTP/AVP, while keeping the fingerprint and setup
>>     attributes. This means that an endpoint that sees the attributes
>>     can replay likewise and agree SRTP-DTLS. Old endpoints ignore the
>>     attributes and can still answer the call.
>>
>>     There are other ways to construct the SDP if you want to offer
>>     both RTP/SAVP and RTP/AVP, but that opens up for downgrade
>>     attacks, so one need serious consideration.
>>
>>     EdS - Typically, older endpoints also would not support this,
>>     which is the benefit of OSRTP - It is backwardly compatible.
>>
>>
>>
>>         devices that do not support encryption would reject the call
>>         as unsupported.
>>
>>
>>     Isn’t that one of the benefits? A user needs to be assured that
>>     the call is protected. As a provider you may need to have gateways
>>     to the old world if you need that, but still keep the first call
>>     leg encrypted at all times.
>>
>>         Purple, a Division of ZP Better Together, LLCpurplevrs.com
>>         <http://purplevrs.com/>
>>
>>         please notify us immediately by e-mail, and delete the
>>         original message.
>>
>>
>>
>>
>>         <mailto:[email-masked]>>;[email-masked]
>>         <mailto:[email-masked]>
>>         document doesn’t require that.  Again, we need a STANDARDS
>>         based solution, and we have to live within the constraints the
>>         IETF has for new standards with respect to security.  Like
>>         nearly every organization, the IETF is much more security
>>         conscious than it was, and won’t tolerate bad security
>>         although it often recognizes the necessity for backwards
>>         compatibility as long as it’s not to a known insecure mechanism.
>>
>>         spent lots of time and cycles implementing things that turn
>>         out not to be secure enough, and we have to move forward on
>>         things that are.  DTLS-SRTP is one of those things, as is IPv6.
>>
>>         Brian
>>
>>
>>
>>                 - While WebRTC w/ SRTP/DTLS (encryption) is an
>>                 excellent idea going forward, it can't be a "MUST"
>>                 requirement. I agree with Roger Slusser that mandating
>>                 compliance using MUST requires providers to implement
>>                 significant development to change over to what RUM is
>>                 specifying.
>>
>>
>>             When defining a specification for an interface that is to
>>             be implemented by independent parties it is necessary for
>>             alternative for the media you would prefer, then please
>>             make a specific proposal.
>>
>>
>>             private between the RUE and the provider. That is a low
>>             bar these days. It is unlikely that anything less could be
>>                 <[email-masked]
>>                 <mailto:[email-masked]><mailto:[email-masked]
>>                 [email-masked] <mailto:[email-masked]><mailto:[email-masked]
>>                 <mailto:[email-masked]>>