Re: [rtcweb] Let's define the purpose of WebRTC

["John Elwell" <[e-mail]>]

Concerning SDES, I agree its security is poor. Essentially it is a 
hop-by-hop model, because any intermediary with access to the signalling has 
access to the keys, and with the help of a media gateway can trans-key or 
map to RTP.

There are so many things one might need to do to interwork with legacy 
(demux, terminate ICE, terminate DTLS-SRTP, even transcode possibly). All 
can be done with a media gateway. Trying to avoid this for particular 
situations (e.g., finding a way of using RTP or SRTP/SDES) will not 
necessarily eliminate the need for a media gateway for other functions in 
those situations and will certainly not avoid the need for a media gateway 
in all situations. Wouldn't it be better to stick to a simple approach for 
WEB-RTC (minimal options) and say that if you want to interoperate with 
anything else you just have to use a media gateway? Applications that need 
to interoperate can choose whether they use WEB-RTC and take the hit, or 
instead can choose some other technology (such as plug-ins). In some ways 
this would be fairer. Also it is probably the only way of getting WEB-RTC 
completed in a reasonable time.

John


----- Original Message ----- 
From: "Randell Jesup" <[e-mail]>
To: <[e-mail]>
Sent: Monday, November 07, 2011 3:14 AM
Subject: Re: [rtcweb] Let's define the purpose of WebRTC


On 11/6/2011 9:01 AM, Tim Panton wrote:
> Almost all of the discussions here in the last few weeks are about interop 
> with existing SIP
> deployments. ( forking,glare, SDP, RTP muxing) The bulk of the use-cases 
> on which that effort is
> based are also around interop with non-browser devices and channels, but 
> the charter
> never mentions legacy interop. It only talks about browser-to-browser and 
> replacing the
> myriad plugins. It also talks about being a platform for innovation, which 
> is now a
> non-goal for the group.

I respectively disagree.  While I (and others) have sat back and let a
bunch of people argue over that, I assure you that interop has not been
a major factor in my discussions with other stakeholders or a primary
use-case for me.  Has interop gotten discussion?  Yes, partly due to
many of the people arguing here, and partly due to some of those cases
being tougher, or that interop exposes some tricky edge cases that may
exist without interop as well.

For example, you mention forking and glare.  Well, I've given very
non-interop cases of where forking would be useful: contacting someone
who has 2 desktops, a notebook, a tablet, and a phone all logged into
the service, or some of the game scenarios, or a very
non-standard-SIP-like mesh conference using forked invites.  And glare:
Cullen's classic example of glare is two people talking, browser to
browser, and one saying "lets add video", and both turning it on.  No
interop or SIP required for that to cause glare.  And RTP muxing?
That's to avoid the startup-delay of having to ICE multiple ports (and
the funny side-effects if they choose different paths).  Yes that does
add some requirements to think about for interop; that's not subverting
the charter or drifting from it.

> Iñaki asked a question as to the purpose of WebRTC, so I quoted the 
> charter.
> As I re-read it, I found that we have drifted a _long_ way from those 
> stated goals.
>
> On that basis, I say we have to re-evaluate something - either the charter 
> or what we
> now have. They are (to my mind) incompatible.
>
> As a concrete example - (there are _many_ but to name a current example) - 
> we seem to be
> on the point of dropping the SRTP requirement in order to ease interop 
> with legacy devices.
> How that squares with the charter - or indeed the ITEF's security stance I 
> have no clue.

People have discussed cases where SRTP either doesn't really add to the
user's security, and if you are interfacing to the PSTN, being forced
through a media gateway might be merely a HW/$ cost to the service, or
it might also be a major degrader of the call quality, of the media
gateway isn't close to either the PSTN gateway or the caller.

These are arguable cases, but for the time being, a number of use-cases
and possible applications would want to have the option of talking to a
PSTN gateway, even if that's not the primary use.  That makes it worth
exploring to see if it's possible while retaining other requirements,
and not opening the user to bid-down attacks, etc.  Thus far, we don't
have a great solution or perhaps even a usable one.

For browser-to-browser (webrtc-to-webrtc really), there's much less (if
any) reason to avoid SRTP.

As for SDES... I don't consider SDES to be secure, especially not in our
threat model.  The app has access to the keys, and we don't trust the
app.  It's more secure than no encryption, and it may be better at
interop, but that's it.  I think I'd oppose SDES use for anything except
interop cases.

-- 
Randell Jesup
[e-mail]
_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb