Subject: Re: [Rum] Let's get into it

From: Brian Rosen <[email-masked]>
Date: Wed, 7 Aug 2019 17:14:48 -0400

Working on these comments.  I submitted a new version (-01)

I edited the doc to say the client cert is provisioned.  Given that it’s provisioned by the entity that the provides the server, do I need to say anything else about validating the cert?

I’m fine with requiring support for SIP-over-websockets (RFC7118), but is that a general goodness these days?

The general requirements require TLS for SIP, so I don’t think I need anything else for telephone number privacy, right?

6.2.1 says “Route headers MAY be included in one-stage dial-around calls and emergency calls.”  6.2.2 is one-stage-dial around, so it fits the exception for the SHOULD.

I added the reference to RFC6351 for xCard.   I think we should have a discussion of whether this mechanism should be retained.  The purpose was to deal with an objection from providers that if they supported this interface, anyone could download some random code claiming to meet it, and they wouldn’t have a clue where it came from or a way to contact anyone if it didn’t behave.  As you point out, there isn’t any way for the server to put any trust in the data.  The requirement for TLS covers eavesdropping, but it still could obtain PII.  I left the text for now, but we should discuss.

You said “The proxy is found using DNS and may be a list created from NATPR/DNS SRV records. What is the defintion of “the proxy” in this statement?”,  It seems obvious to me that the proxy URI is found in the configuration and the SRV resolves to an IP address (or addresses).  What is unclear?

Simultaneous ring is a pretty well known thing, which I think everyone does with parallel fork in one form or another.  There is only two MUSTs for the server (if there are multiple registrations, ring them all, and CANCEL any ringing UAs that didn’t answer). 3261 doesn’t discuss CANCEL when forking and I don’t see where we say anything that could be construed as violating anything I can see in 3261.  I’m at a loss to understand what I should change.

The reference to OUTBOUND also confuses me.  Yeah, you could get some forking when following Outbound, but that wouldn’t change this fork of independent registered UAs would it?  What text suggestion do you have?  I’m very happy to clarify anything unclear, but I don’t see the problem yet.

I added the RFC references to REFER, and included the 7647 update as well as explicit support for norefersub,

Could we have a discussion of whether we require support for IPv4.  I think we do, but are their other opinions?  I fixed “domain part”.

I replaced the media and SRTP sections with references to the WebRTC media specifications.  There is a significant problem where there are existing endpoints that simply can’t be upgraded to support SRTP video.  This may be less of a problem if the systems that support those endpoints anchor media in their SBCs.

The example operator URI in Section 11.1 doesn’t contain a number-which-is-not-an-E164, and thus doesn’t need user=dialstring.

> On Jul 10, 2019, at 6:28 AM, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
>> On 9 Jul 2019, at 21:48, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Please comment on anything.
> 
> Section 5:
> 
> "Both HTTPS and all SIP Transactions MUST use TLS 1.2”
> 
> “Transactions” doesn’t work well here. “Connections” would be better.
> Instead of hard-coding a specific version of TLS you may want to point to the BCP by the UTA wg,
> unless you anyway will update this profile from time to time.
> 
> " During the establishment of secure connections with a provider, the
>    RUE MAY be asked by the server for a client certificate.  In that
>    case it SHOULD provide a client certificate.  Providers MAY reject
>    requests that fail to provide a recognized certificate.”
> 
> What’s in the client cert? How do you validate the client certs?
> 
> Section 6 doesn’t mentionSIP over WebSockets. I assume that would apply.
> 
> 
> Since you are using phone numbers as identifiers, I from an EU standpoint
> suggest disallowing all non-secure transports. Phone numbers are 
> considered personal identifiers and are affected by the EU GDPR.
> 
> 
> Section 6.2.1 forbids Route headers in initial INVITE requests. The example
> in 6.2.2 has a very visible Route: header in the initial request.
> 
> Section 6.2.3 talks about an xCard without any references or comments
> about trust for that information.
> 
> Section 6.2.4:
> 
> "The RUE MUST accept inbound calls sent to it by the proxy mentioned
>    in the configuration.”
> 
> The proxy is found using DNS and may be a list created from NATPR/DNS SRV
> records. What is the defintion of “the proxy” in this statement?
> 
> "If Multiple simultaneous RUE SIP registrations from different RUE
>    devices with the same SIP URI exist, the Provider MUST parallel fork   the call to all registered RUEs so that they ring at the same time.
>    The first RUE to reply with a 200 OK answers the call and the
>    Provider MUST CANCEL other call branches.
> "
> Is this normative (you have many MUST here). If so - how does this
> change the behaviour of RFC 3261?
> Also, I think this texts forgets about SIP outbound. Since Outbound is a MUST,
> you need to clarify the mix of parallell and serial forking that will happen.
> 
> 
> Section 6.3:
> 
> "The RUE MUST support   REFER to enable call transfer.“
> 
> Which combination of REFER? I assume that “Mid call signaling” is “in-dialog transactions” in SIP lingo,
> but REFER with or without Replaces? With or without subscription for updates?
> 
> Section 6.4:
> 
> " Relay Service URIs and User Address of Records (AoR) MUST resolve (in
>    accord with [RFC3263 <https://tools.ietf.org/html/rfc3263>]) to globally routable IPv4 addresses.  The AoRs
>    MAY also resolve to IPv6 addresses.”
> 
> How do you resolve a complete URI into an IP address? I guess you mean
> the domain part that resolves to a list of addresses using DNS.
> Why is IPv4 a MUST?
> 
> Section 8:
> 
> "All media streams between the RUE and another endpoint or relay
>    Provider MUST be exchanged using the secure real-time transport
>    protocol (SRTP) [RFC3550 <https://tools.ietf.org/html/rfc3550>] using DTLS [RFC5763 <https://tools.ietf.org/html/rfc5763>], [RFC5764 <https://tools.ietf.org/html/rfc5764>], except
>    that for backwards compatibility with older video endpoints, RTP MAY
>    be negotiated if SRTP negotiation fails.
> “
> 
> How do you handle the risk of downgrade attacks here? That exception is dangerous
> and maybe should be handled elsewhere, not in the client. 
> 
> 
> Section 11.1
> 
> The example operator URI for red.example.net <http://red.example.net/> seems to lack “;user=dialstring”
> 
> Section 11.2
> 
> "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be
>       used when sending requests to the Provider.  Multiple URIs
>       identify alternative (redundant) paths to the Provider.
> “
> 
> Outbound proxy is of course something you look up in DNS to get the list of
> actual servers. Is there a need to have an additional list in this json format?
> 
> " ice-servers” - propably a bad name. I don’t remember seeing “ice server” as a term.
> As turn servers are also STUN servers, I think “turn-servers” is better.
> 
> “credentials”: This is tricky indeed. Sending credentials in clear text like this,
> even if it’s over HTTPS is an interesting approach in this age and time.
> Regardless of that, make sure you consider OAuth/OpenID connect auth
> for some services.
> 
> “lifetime”:; You are really not clear on what happens when the configuration
> expires. Is the RUE forbidden to use anything here? What about emergency calls
> - will they work even without configuration?
> 
> General:
> 
> You do not mention bundling of RTP streams, which may be beneficial here.
> 
> Good work!
> 
> /O
> 
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Aug 2019 15:57:02 -0400

In draft-rosen-rue-00 and earlier section 6.5 on NAT Traversal puts 
control of ICE, STUN, and TURN on the provider through provisioning of 
the RUE. The STUN/TURN servers are presumably selected by the provider.

In -01 this is changed to simply referencing 
draft-ietf-rtcweb-transports. That document puts some of the control 
over these in the hands of the browser, and allows the browser to be 
configured (presumably by the user). (Of course there is still a lot of 
control in the hands of the web server.)

Given that we are not assuming/requiring that the RUE be browser-based, 
it isn't clear to me that draft-ietf-rtcweb-transports is a necessary or 
sufficient condition.

OTOH, we don't want to exclude webrtc browser-based implementations. I 
have a feeling we need more options here. But at least we need more 
discussion on how this should work.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Aug 2019 15:40:55 -0400

On 8/7/19 5:14 PM, Brian Rosen wrote:
> I edited the doc to say the client cert is provisioned.  Given that it’s 
> provisioned by the entity that the provides the server, do I need to say 
> anything else about validating the cert?

I think we need to examine what the goal is here, and whether it is 
being achieved. I don't think enough is said to decide.

This client cert mechanism was first added way back when (2015 I think). 
IIRC, the motivation was because the providers wanted to restrict access 
to RUE *implementations* that have passed interoperability testing, in 
order to reduce the problems of dealing with buggy implementations or 
attackers.

The idea was that certs would only be made available to 
*implementations* (e.g. images) that have been tested. There was no 
expectation that each user who obtains a rue would need to have it tested.

But the exact mechanism for binding a cert to a tested implementation 
was never worked out. I've asked around from time to time and I haven't 
learned of any way to achieve this.

Brian's new text pushes this off one level but doesn't solve the 
problem. The provider's *sip* server can perhaps trust that the rue got 
the cert from the provider's provisioning server. But the provisioning 
server still has to decide if this is a trustworthy implementation.

The Apple store and the Google Play Store solve this problem by being 
the distributor of apps. The developer has to submit the app, which is 
then tested/verified by the store and then being assigned credentials. 
Potentially we could have something list that by having a RUE Store 
operated by a RUE testing authority. But I don't think anybody is 
prepared to operate such a thing and it would require the devices 
receiving these apps to bypass the normal vendor restrictions on 
installations.

I don't have a good answer here.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Aug 2019 16:20:51 -0400

draft-rosen-rue-01 changes the video codec requirements. It now simply 
references webrtc RFC7742.

RFC7742 distinguishes three types of endpoints: "WebRTC browser", 
"WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes 
that each end is one of these.

Is the expectation here that both the RUE and the provider comply with 
one of these? In particular, that the provider may simply be a 
"WebRTC-compatible endpoint? Notably:

    "WebRTC-compatible endpoints" are free to implement any video codecs
    they see fit.  This follows logically from the definition of "WebRTC-
    compatible endpoint".  It is, of course, advisable to implement at
    least one of the video codecs that is mandated for WebRTC browsers,
    and implementors are encouraged to do so.

Similarly, the audio requirements have been changed to reference webrtc 
RFC7874. That one doesn't have the distinction between "WebRTC browser", 
"WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the 
same requirements to all. In particular, it requires OPUS support. I 
don't know why it doesn't make the same endpoint distinctions as for video.

I think simply referencing these documents isn't sufficient. Seems like 
we need a more nuanced specification of what is required, though we may 
still reference these docs with qualifications.

	Thanks,
	Paul

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 13 Aug 2019 08:45:47 +0200

> On 7 Aug 2019, at 23:14, Brian Rosen <[email-masked]> wrote:
> 
I would encourage that to get some base level of interoperability. 
> I’m fine with requiring support for SIP-over-websockets (RFC7118), but is that a general goodness these days?
I just noted that it was excluded. Adding it will certainly help implementations that want to use WebRTC.

> The general requirements require TLS for SIP, so I don’t think I need anything else for telephone number privacy, right?
The phone numbers will end up in log files, in all kind of middle boxes. TLS is no guarantee of privacy any more, if it ever was.
My general experience is that is a bad identifier in SIP as phone numbers seldom are permanent and people by law has the
right to have hidden phone numbers. You want a more permanent identifier.

> 6.2.1 says “Route headers MAY be included in one-stage dial-around calls and emergency calls.”  6.2.2 is one-stage-dial around, so it fits the exception for the SHOULD.
ok
> 
> I added the reference to RFC6351 for xCard.  
ok
> I think we should have a discussion of whether this mechanism should be retained.  The purpose was to deal with an objection from providers that if they supported this interface, anyone could download some random code claiming to meet it, and they wouldn’t have a clue where it came from or a way to contact anyone if it didn’t behave.  As you point out, there isn’t any way for the server to put any trust in the data.  The requirement for TLS covers eavesdropping, but it still could obtain PII.  I left the text for now, but we should discuss.
> 
Usually you start with a name that by using DNS can resolve into many proxys. you don’t configure “a proxy” in SIP, you configure a SIP domain and end up with “the proxy”. That’s two dfferent things. Your text bypasses the DNS  NAPTR/SRV resolution by indicating that “the proxy” should be configured, which I don’t think is a good thing.
And since you write about incoming calls, the problem gets worse, sincie your device may end up with one proxy and get incominig calls from another, unless you force
it by using SIP Outbound. Wiith SIP Outbound the proxy has to use the incominig connection, which I think is a good thing.

> Simultaneous ring is a pretty well known thing, which I think everyone does with parallel fork in one form or another.  There is only two MUSTs for the server (if there are multiple registrations,…
Implementers may think that by writing something that is obvious in 3261 you may have changed something. You may add a disclaimer saying “this is just a clarification, not normative text”.
> The reference to OUTBOUND also confuses me.  Yeah, you could get some forking when following Outbound, but that wouldn’t change this fork of independent registered UAs would it?  What text suggesti…
As most programmers doesn’t have experience of SIP Outbound it may not be clear that when using outbound there will be a combination of parallell and serial forking. Parallell on the various registrations, serial in the various reg-id registrations from the same device.
> I added the RFC references to REFER, and included the 7647 update as well as explicit support for norefersub,
ok
> Could we have a discussion of whether we require support for IPv4.  I think we do, but are their other opinions?  I fixed “domain part”.
What is the problem you are trying to solve by adding this requirement?
> I replaced the media and SRTP sections with references to the WebRTC media specifications.  There is a significant problem where there are existing endpoints that simply can’t be upgraded to suppor…
If you switich to WebRTC you are also adding AVPF which is not compatible with most SIP devices. Some sort of b2bua will be required for legacy interop.
> The example operator URI in Section 11.1 doesn’t contain a number-which-is-not-an-E164, and thus doesn’t need user=dialstring.
ok

/O
> 
> 
> 
>> On Jul 10, 2019, at 6:28 AM, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 
> -- 
> Rum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rum

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2019 15:32:11 -0400

Getting back to this, sorry for the delay.

> On Aug 12, 2019, at 3:40 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> I think we need to examine what the goal is here, and whether it is being achieved. I don't think enough is said to decide.
> 
> This client cert mechanism was first added way back when (2015 I think). IIRC, the motivation was because the providers wanted to restrict access to RUE *implementations* that have passed interoperability testing, in order to reduce the problems of dealing with buggy implementations or attackers.
I think you are confusing validating an implementation from authenticating a user.  The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implementations code.

We can decide we don’t want the option of having mutual auth.

> 
> The idea was that certs would only be made available to *implementations* (e.g. images) that have been tested. There was no expectation that each user who obtains a rue would need to have it tested.
> 
> But the exact mechanism for binding a cert to a tested implementation was never worked out. I've asked around from time to time and I haven't learned of any way to achieve this.
> 
> Brian's new text pushes this off one level but doesn't solve the problem. The provider's *sip* server can perhaps trust that the rue got the cert from the provider's provisioning server. But the provisioning server still has to decide if this is a trustworthy implementation.
> 
> The Apple store and the Google Play Store solve this problem by being the distributor of apps. The developer has to submit the app, which is then tested/verified by the store and then being assigned credentials. Potentially we could have something list that by having a RUE Store operated by a RUE testing authority. But I don't think anybody is prepared to operate such a thing and it would require the devices receiving these apps to bypass the normal vendor restrictions on installations.
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2019 15:34:45 -0400

Well, we certainly want interoperability, and I think we can only get that with MTI codecs.

I think we really are talking about a WebRTC-compatible endpoint, but we want interoperability with a WebRTC browser endpoint.

Not sure how to say this.  Maybe Adam can help.

Brian

> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat <[email-masked]> wrote:
> 
> draft-rosen-rue-01 changes the video codec requirements. It now simply references webrtc RFC7742.
> 
> RFC7742 distinguishes three types of endpoints: "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it assumes that each end is one of these.
> 
> Is the expectation here that both the RUE and the provider comply with one of these? In particular, that the provider may simply be a "WebRTC-compatible endpoint? Notably:
> 
> Similarly, the audio requirements have been changed to reference webrtc RFC7874. That one doesn't have the distinction between "WebRTC browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It applies the same requirements to all. In particular, it requires OPUS support. I don't know why it doesn't make the same endpoint distinctions as for video.
> 
> I think simply referencing these documents isn't sufficient. Seems like we need a more nuanced specification of what is required, though we may still reference these docs with qualifications.
> 
> 	Thanks,
> 	Paul
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Aug 2019 15:45:15 -0400

> On Aug 13, 2019, at 2:45 AM, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> 
>> On 7 Aug 2019, at 23:14, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>> 
See the note to Paul about whether we want to keep this option.  If we do, then what else should the doc say?

> I just noted that it was excluded. Adding it will certainly help implementations that want to use WebRTC.
I’m getting more comfortable doing this.  Any other voices for or against?

> right to have hidden phone numbers. You want a more permanent identifier.
The use here is for dialing other people by phone number.  The whole VRS system is based on that in the US.  There is an ENUM based routing directory that is used to route calls to a user with a videophone in the system.  We can add text to the security section that discusses this, but when we have to say “worry about log files” I think we’re pretty far afield.   Would you rather say we can’t use phone numbers?  I don’t think that would work.
> it by using SIP Outbound. Wiith SIP Outbound the proxy has to use the incominig connection, which I think is a good thing.
Okay, I see your point.  I’ll change the text to just talk about the provisioned domain.
> Implementers may think that by writing something that is obvious in 3261 you may have changed something. You may add a disclaimer saying “this is just a clarification, not normative text”.
Ok
> As most programmers doesn’t have experience of SIP Outbound it may not be clear that when using outbound there will be a combination of parallell and serial forking. Parallell on the various regist…
Ok

> What is the problem you are trying to solve by adding this requirement?
Interoperability with other endpoints, and in lots of remaining networks and systems that don’t yet work without IPv4
> If you switich to WebRTC you are also adding AVPF which is not compatible with most SIP devices. Some sort of b2bua will be required for legacy interop.
Yeah, in a pracrucak sense the providers use SBCs, which I don’t like, but it sure is common.  That solves the problem.  The problem with anything else is a downgrade attack.  
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rum <https://www.ietf.org/mailman/listinfo/rum>

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Aug 2019 16:57:36 -0500

I certainly have thoughts. The executive summary is that I personally 
believe RUM should specify Opus as the one audio codec MTI, and match 
RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale 
below.

 From an interop perspective, the important thing is that any given 
profile has (at least) one MTI video codec and (at least) one MTI audio 
codec. I know there is a strong desire -- one that I share -- that these 
endpoints can talk to/be implemented in web browsers without the need 
for media transcoding.

For audio: WebRTC selected G.711 and Opus as both MTI; the former 
because it works without transcoding to landline PSTN destinations, and 
the latter because it sounds much, much better. RUM could make the same 
decision; or it could decide to move away from a codec that is as old as 
I am and opt to designate Opus as the only MTI. Given that RUM 
inherently needs to deploy into audio/video environments, backwards 
compatibility with the PSTN seems to be unnecessary baggage.

For video: While specifying either VP8 or H.264 would be sufficient for 
system interop, and for interop with compliant WebRTC endpoints, I'd 
really prefer not to re-live the WebRTC video codec wars. Concretely, 
what I would propose is that RUM indicate that the video codec 
requirements are defined to be identical to those defined for "WebRTC 
Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM 
endpoints *are* *not* WebRTC Non-Browsers per se; merely that they 
comply with the same video codec requirements as WebRTC Non-Browsers.

/a

---

From: Richard Shockey <[email-masked]>
Date: Tue, 27 Aug 2019 18:34:00 -0400

+1 to Adam's excellent comments. 

— 
Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook –Twitter  rshockey101

PSTN +1 703-593-2683

On 8/27/19, 5:57 PM, "Rum on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:

    

    /a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 09:47:43 -0400

> I think you are confusing validating an implementation from authenticating a user.  The notion of mutual auth with a per-device cert is completely separate from some notion of “signing” an implemen…

No. You can argue that the client cert mechanism in not an appropriate 
mechanism for this, but it was the intent when the mechanism was proposed.

I can see how this might be confused if you weren't there at the time. 
And perhaps the thinking about it has evolved since it was first 
included. I wasn't party to what happened during 2016-18.

IIUC the providers still want this - a way to screen out RUE 
*implementations* that have not passed their testing. However, I don't 
know how to achieve that goal. And I'm inclined to think that it is an 
unreasonable expectation. It is akin to web site operators asking for a 
way to screen out any browser implementations that they haven't already 
tested against.

> We can decide we don’t want the option of having mutual auth.

Clearly there is need for some mechanism to securely associate a RUE 
with an account at the provider and a phone number. And this needs to 
work with devices that are persistently connected. If a RUE suffers a 
power or network outage that is restored in the middle of the night then 
it should be able to reconnect without a user login so that it can be 
available for incoming calls.

That was intended to be covered by passwords. But care must be taken to 
secure those.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 10:15:44 -0400

Inline...

> compatibility with the PSTN seems to be unnecessary baggage.

Please keep in mind where we are coming from. The RUM will be a new 
interface to the *existing* VRS infrastructure. That infrastructure 
currently has proprietary devices that serve the RUE function, deployed 
to VRS users and to Communications Assistants (CAs, Interpreters). These 
have G.711 MTI, and also *recommend* G.722.2.

Making OPUS the only MTI audio codec would be problematic.

> comply with the same video codec requirements as WebRTC Non-Browsers.

Continuing my comment above, existing devices have H.264 Constrained 
Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds 
are many of these devices aren't capable of VP8.

We can't realistically require a wholesale swap out of existing devices 
before the RUE defined by RUM can work. We can *discuss* whether forcing 
the providers to transcode is a practical way forward. I'm dubious.

	Thanks,
	Paul

>> I think we really are talking about a WebRTC-compatible endpoint, but 
>> we want interoperability with a WebRTC browser endpoint.
>>
>>> "WebRTC non-browser", and "WebRTC-compatible endpoint". AFAIK it 
>>> assumes that each end is one of these.
>>>
>>> Is the expectation here that both the RUE and the provider comply 
>>> with one of these? In particular, that the provider may simply be a 
>>> Similarly, the audio requirements have been changed to reference 
>>> webrtc RFC7874. That one doesn't have the distinction between "WebRTC 
>>> browser", "WebRTC non-browser", and "WebRTC-compatible endpoint". It 
>>> applies the same requirements to all. In particular, it requires OPUS 
>>> support. I don't know why it doesn't make the same endpoint 
>>> distinctions as for video.
>>>
>>> I think simply referencing these documents isn't sufficient. Seems 
>>> like we need a more nuanced specification of what is required, though 
>>> we may still reference these docs with qualifications.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2019 10:38:08 -0400

If we require OPUS and G.711 as MTI and we require both H.264 and VP8 as MTI, then we get backwards compatibility without transcoding and forwards compatibility with WebRTC.  Isn’t that what we want?

Brian

> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> Inline...
> 
>> I certainly have thoughts. The executive summary is that I personally believe RUM should specify Opus as the one audio codec MTI, and match RFC 7742's "Non-Browser" requirements for the video codec MTI. Rationale below.
>> From an interop perspective, the important thing is that any given profile has (at least) one MTI video codec and (at least) one MTI audio codec. I know there is a strong desire -- one that I share -- that these endpoints can talk to/be implemented in web browsers without the need for media transcoding.
>> For audio: WebRTC selected G.711 and Opus as both MTI; the former because it works without transcoding to landline PSTN destinations, and the latter because it sounds much, much better. RUM could make the same decision; or it could decide to move away from a codec that is as old as I am and opt to designate Opus as the only MTI. Given that RUM inherently needs to deploy into audio/video environments, backwards compatibility with the PSTN seems to be unnecessary baggage.
> 
> Please keep in mind where we are coming from. The RUM will be a new interface to the *existing* VRS infrastructure. That infrastructure currently has proprietary devices that serve the RUE function, deployed to VRS users and to Communications Assistants (CAs, Interpreters). These have G.711 MTI, and also *recommend* G.722.2.
> 
>> For video: While specifying either VP8 or H.264 would be sufficient for system interop, and for interop with compliant WebRTC endpoints, I'd really prefer not to re-live the WebRTC video codec wars. Concretely, what I would propose is that RUM indicate that the video codec requirements are defined to be identical to those defined for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It should be made clear that RUM endpoints *are* *not* WebRTC Non-Browsers per se; merely that they comply with the same video codec requirements as WebRTC Non-Browsers.
> 
> Continuing my comment above, existing devices have H.264 Constrained Baseline Profile, Level 1.3, packetization mode 1 as the MTI codec. Odds are many of these devices aren't capable of VP8.
> 
> We can't realistically require a wholesale swap out of existing devices before the RUE defined by RUM can work. We can *discuss* whether forcing the providers to transcode is a practical way forward. I'm dubious.
> 
> 	Thanks,
> 	Paul
> 
>> /a

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2019 10:41:08 -0400

Ever since I’ve been working on this doc, the cert was for mutual auth of the user, instead of username and password.  

We get to use the IETF’s best practice here.  Do we require a RUM device to support mutual auth, or not?  We’re always going to support username and password for authentication.
We get to decide what else.

Brian

> On Aug 28, 2019, at 9:47 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> No. You can argue that the client cert mechanism in not an appropriate mechanism for this, but it was the intent when the mechanism was proposed.
> 
> I can see how this might be confused if you weren't there at the time. And perhaps the thinking about it has evolved since it was first included. I wasn't party to what happened during 2016-18.
> 
> IIUC the providers still want this - a way to screen out RUE *implementations* that have not passed their testing. However, I don't know how to achieve that goal. And I'm inclined to think that it is an unreasonable expectation. It is akin to web site operators asking for a way to screen out any browser implementations that they haven't already tested against.
> 
> Clearly there is need for some mechanism to securely associate a RUE with an account at the provider and a phone number. And this needs to work with devices that are persistently connected. If a RUE suffers a power or network outage that is restored in the middle of the night then it should be able to reconnect without a user login so that it can be available for incoming calls.
> 
> That was intended to be covered by passwords. But care must be taken to secure those.
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 11:14:57 -0400

> Ever since I’ve been working on this doc, the cert was for mutual auth of the user, instead of username and password.

OK. As long as we are clear that is what it is about.

> We get to decide what else.

We've already been dinged about passing passwords around in 
configuration. Is it better if we use a password to fetch an initial 
device configuration that includes certs?

I think we need to have a new discussion of the overall security setup, 
including access to address book and video mail. Are they all under a 
single credential, or separate. Also how passwords expire and are 
refreshed/updated, etc. IIRC there were concerns about all of these.

	Thanks,
	Paul

---

From: Eric Burger <[email-masked]>
Date: Wed, 28 Aug 2019 11:25:38 -0400

I guess the question is whether we want today’s devices to have a chance of being RUM compatible. I don’t think anyone will be surprised if a five-year-old device is history. Is it realistic for current devices to get VP8 upgrade? [Would be nice for some manufacturers or others building such devices to pipe in here.]

> On Aug 28, 2019, at 10:38 AM, Brian Rosen <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2019 11:34:25 -0400

Good discussion to have.

A cert is public, so no real privacy issues other than what is in the identity (which a username gives you also).  How the private key associated with the cert is handled is of concern, but I imagine it’s the usual CSR thing which never reveals the key.  But we do need some kind of security on the provisioning information itself.  If there was a cert, then the provisioning could be signed by or for the rue.  I kind of like that.  It’s all new mechanism, but maybe worthwhile.  You run code on the device that creates the CSR, upload it, and download the cert.  Then the rue can sign the provisioning file (which really doesn’t need the cert, so it could do that any time).

There are two contact maintenance mechanisms in the draft now - file upload/download and CardDAV.  CardDAV is okay security-wise.  File upload and download is from a provider, so we could have providers sign the file with the cert so only that user could verify it.

Brian

> On Aug 28, 2019, at 11:14 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> We've already been dinged about passing passwords around in configuration. Is it better if we use a password to fetch an initial device configuration that includes certs?
> 
> I think we need to have a new discussion of the overall security setup, including access to address book and video mail. Are they all under a single credential, or separate. Also how passwords expire and are refreshed/updated, etc. IIRC there were concerns about all of these.
> 
> 	Thanks,
> 	Paul
> 
>> Brian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 28 Aug 2019 11:36:51 -0400

That wouldn’t be needed, right?  If rum devices implemented both H.264 and VP8, and existing devices only implemented H.264, then we have backwards compatibility.  There are some details (profile, packetization, ..)

> On Aug 28, 2019, at 11:25 AM, Eric Burger <[email-masked]> wrote:
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 11:48:18 -0400

> I guess the question is whether we want today’s devices to have a chance of being RUM compatible. I don’t think anyone will be surprised if a five-year-old device is history. Is it realistic for cu…

Lets be clear about what we mean by "RUM compatible".

When Henning and I were working on this with the providers in 2014 and 
2015 there was an expectation that the providers would be required to 
support the defined RUE devices, but they would also be permitted to 
support their existing proprietary devices. The RUE devices could have 
requirements that their existing devices don't meet. But calls between 
the two were expected to work.

There was great consternation when subsequently the FCC issued a 
proposed order that said only VRS calls involving RUE-compatible devices 
would be compensated. (But that was in 2015. I presume it has not happened.)

If there is an intent to exclude non-RUM-compliant devices from use in 
VRS calls then there needs to be a migration plan to get from here to there.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Aug 2019 12:13:04 -0400

On 8/28/19 11:34 AM, Brian Rosen wrote:
> Good discussion to have.
> 
> A cert is public, so no real privacy issues other than what is in the identity (which a username gives you also).  How the private key associated with the cert is handled is of concern, but I imagine it’s the usual CSR thing which never reveals the key. 

> But we do need some kind of security on the provisioning information itself.  If there was a cert, then the provisioning could be signed by or for the rue.  I kind of like that.  It’s all new mechanism, but maybe worthwhile.  You run code on the device that creates the CSR, upload it, and download the cert.  Then the rue can sign the provisioning file (which really doesn’t need the cert, so it could do that any time).

It could be that the RUE creates a self signed cert and then uploads it 
to the provider during initial configuration of the RUE on the provider. 
But, is there something we can reference on how to do it?

Could the initial connection to the provisioning server include this 
cert as a client. The server won't know this cert and so will challenge 
for a password. Server would then save the cert for the user. In 
subsequent connections with the same client cert a password wouldn't be 
required.

IIRC, the providers wanted to be able separate credentials that a user 
used to log into his provider account from those used by the RUE when 
registering. (So that they could be changed independently.) What I 
sketched above might solve that.

> There are two contact maintenance mechanisms in the draft now - file upload/download and CardDAV.  CardDAV is okay security-wise. 

Again the question is whether this can be accessed with the same 
credentials as used for registering. If not, then how does the RUE get 
them, since it will probably want to sync automatically.

> File upload and download is from a provider, so we could have providers sign the file with the cert so only that user could verify it.

I think there is a question here of how this is intended to be used. I 
have the impression that there is an expectation that the result can be 
used "manually", and so should be in clear text in a human readable format.

But I think we also had an expectation that a RUE could use this 
automatically to update its own address book if CardDAV wasn't 
available. Clearly this is a degraded mechanism compared to CardDAV.

For automated use by the RUE we need to again deal with what credentials 
are required to retrieve these.

Unlike registering the device to receive calls, updating the address 
book is only needed when a person is present. So this could potentially 
require prompting the user for a password.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 28 Aug 2019 13:12:22 -0500

The deployed base of H.264 changes the calculus a bit. Given that fact, 
I'm not sure VP8 support gains very much. Constrained baseline and 
packetzation mode 1 are both MTI in WebRTC. It's notable that WebRTC 
only requires level 1.2, although it recommends 1.3. I *think* most 
browsers support 1.3, so specifying H.264 constrained baseline level 1.3 
with packetization mode 1 as the single video MTI seems reasonable.

/a