Subject: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 15:13:20 +0200

Hi all,

I've made two "pictures" showing WebRTC and SIP interop for two cases:

1) SDES-SRTP is allowed in WebRTC:
      http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png

2) Just DTLS-ETK-SRTP is allowed in WebRTC [*]
      http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png

[*] slides 30-35 in
http://tools.ietf.org/agenda/83/slides/slides-83-rtcweb-3.pdf

For those claiming to mandate *just* DTLS-EKT-SRTP in WebRTC, please
see the *cost* of such a decision, and also:

- Thanks for requiring a super Signaling+Media B2BUA/SBC in WebRTC/SIP
interop scenarios. Some vendors will be very happy and will become
very rich. Such a super device (also a DTLS to SDES conversor,
including DTLS key updates to re-INVITE) will be "a bit"... expensive.

- Thanks for disallowing *pure* SIP protocol usage (and instead
requiring SIP B2BUAs/SBCs or custom WebRTC signaling to SIP conversion
gateways). WebRTC is supposed to let the signaling protocol up to the
application, but pure SIP protocol will not be possible since a SIP
B2BUA/SBC is required, and those devices always break/limit the SIP
protocol (*always*).

So IMHO, option 2 ("just DTLS-EKT-SRTP is allowed in WebRTC") is The Barrier.

Best regards.

PS: Note that the same is true for WebRTC/XMPP-Jingle interop.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 4 Apr 2012 18:43:47 +0200

> So IMHO, option 2 ("just DTLS-EKT-SRTP is allowed in WebRTC") is The Barrier.

Hi, nobody cares about the implications of option 2 ???

Do all the people planning to interop with SIP assume that they'll
need the super B2BUA in the second image (without the possibility of
using a pure SIP proxy)?:

BTW Fabio has sent two magistral mails explaining why DTLS is not the
panacea and why SDES can be good enough to satisfy the same level of
security than DTLS. No comments?

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Apr 2012 13:24:39 -0400

>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png
<sarcasm>I guess we should look at this as a business opportunity ;) I am
not sure why you assume that building such gateway would take 10 years. I
can sell a gateway like this to anybody who needs it right now.</sarcasm>

My assumption is that IP phones will migrate to WebRTC effectively
eliminating SIP in end user devices. The only place where SIP will remain
would be federation, which commonly uses some sort of SBC anyway. This SBC
will need to be extended to support ICE anyway. Might as well through in
support for DTLS-EKV-SRTP. I doubt it will map DTLS key updates to
re-invites. Most probably it will simply re-encode.

______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 4 Apr 2012 19:34:18 +0200

> re-invites. Most probably it will simply re-encode.

Roman... I hope you missed the </sarcasm> closing tag just HERE, am I
right? XDDD

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: jesse <[email-masked]>
Date: Wed, 4 Apr 2012 17:42:44 -0700

> My assumption is that IP phones will migrate to WebRTC effectively
eliminating SIP in end user devices.

That is your academic assumption, why does IT department need to spend
extra money to either desert or upgrade its existing SIP devices without
substantial gain? After all, tons of users are still using window xp.

Backward capability is a key to the success of new technology.

-Jesse

The only place where SIP will remain would be federation, which commonly
uses some sort of SBC anyway. This SBC will need to be extended to support
ICE anyway. Might as well through in support for DTLS-EKV-SRTP. I doubt it
will map DTLS key updates to re-invites. Most probably it will simply
re-encode.
>
> ______________
> Roman Shpount
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Apr 2012 22:14:02 -0400

> Backward capability is a key to the success of new technology.
Please note the <sarcasm> tags.

On the more serious note, very few SIP end points offer working ICE
support. So, in a large sense, interop with them is not an option. Out of
the ones that do support ICE and SRTP, very few are actually connected
directly to a public internet. Most of them are connected to some sort of
PBX or an IP PBX type service. So, in reality you do not need to bridge
every IP phone with WebRTC. If a few PBX and hosted centrex vendors will
add support for WebRTC required features, we will get compatibility with
existing end points. To support the rest you will need to deploy some sort
of gateway.

In my personal opinion, tons of users use XP due to the fact that never MS
OS versions do not offer a significant reason to upgrade, while introducing
enough usability and operational issues to create a significant upgrade
hurdle (I am trying to be politically correct here). WebRTC enabled end
points, on the other hand, will offer significant benefits to traditional
SIP phones, since they will allow development of higher quality integrated
real time communications services. I hope this will drive a much quicker
standard adoption.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 11:04:17 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> On the more serious note, very few SIP end points offer working ICE support.
> So, in a large sense, interop with them is not an option.

For me there is a BIG difference when a kind of B2BUA is required
(which involves signaling "transaction"). That's the barrier IMHO.

ICE support can be implemented in a ICE-Lite RTP/SRTP proxy, see:

The problem arises when media encrypt/decrypt is required, and evenr
more when a key update in RTP (like the DTLS EKT update) must be
converted into a signaling re-INVITE by a super Signaling+Media B2BUA:

> Out of the ones
> that do support ICE and SRTP, very few are actually connected directly to a
> public internet. Most of them are connected to some sort of PBX or an IP PBX
> type service. So, in reality you do not need to bridge every IP phone with
> WebRTC.

That is a *very* limited scope of what WebRTC can provide. An IT
department should be able to deploy its own WebRTC infrastructure (a
Web+WebSocket server) within its "local" network, so browsers
accessing to such a local website share the network with SIP/XMPP
phones/devices/softphones.

Please don't imagine WebRTC and SIP interop as the communication
between two islands ;)

> If a few PBX and hosted centrex vendors will add support for WebRTC
> required features, we will get compatibility with existing end points.

Pure SIP proxies do exist. A PBX is not always needed, so again, SIP
world does not require to be "an island".

> To support the rest you will need to deploy some sort of gateway.

Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent
mails about SDES and DTLS).

> real time communications services. I hope this will drive a much quicker

The problem is that there is a *NEW* SRTP related spec for WebRTC:

  http://tools.ietf.org/html/draft-ietf-avt-srtp-ekt-03

Maybe it could also become a standard for SIP? I hope, but currently
it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a
island.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Roni Even" <[email-masked]>
Date: Thu, 5 Apr 2012 12:09:50 +0300

Hi,

I think that your point of view about IP PBX that need to support RTCweb is
interesting but the problem is that RTCweb is not the application, it is an
enabler, so you may see multiple applications servers that will offer
communication services (like Skype, MS Messenger, Google), so I am wondering
if the IP PBX will need to peer with all of them or will the application
servers peer with the IP PBXs using SIP as was proposed in RTCweb. 

Roni Even

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Roman Shpount
Sent: Thursday, April 05, 2012 5:14 AM
To: jesse
Cc: [email-masked]
Subject: Re: [rtcweb] WebRTC-SIP interop: and why SDES-SRTP is a need

That is your academic assumption, why does IT department need to spend extra
money to either desert or upgrade its existing SIP devices without
substantial gain? After all, tons of users are still using window xp.

On the more serious note, very few SIP end points offer working ICE support.
So, in a large sense, interop with them is not an option. Out of the ones
that do support ICE and SRTP, very few are actually connected directly to a
public internet. Most of them are connected to some sort of PBX or an IP PBX
type service. So, in reality you do not need to bridge every IP phone with
WebRTC. If a few PBX and hosted centrex vendors will add support for WebRTC
required features, we will get compatibility with existing end points. To
support the rest you will need to deploy some sort of gateway.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 11:18:40 +0200

2012/4/5 Roni Even <[email-masked]>:
> so I am wondering if the IP PBX will need to peer with all of them or will
> the application servers peer with the IP PBXs using SIP as was proposed in
> RTCweb.

You don't need to make a web browser to talk SIP (UDP/TCP/TLS) in
order to interop with a SIP network.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 5 Apr 2012 09:55:58 +0000

IMHO, there is no need to tweak WebRTC recommendation for the sake of SIP proxy. I'm fine as long as there is a way in WebRTC to interop with SIP. For example, SIP proxy is not suitable for IETF SIPREC recording implementation itself!!!

But I'm also surprised to see that there is no response for Fabio Pietrosanti mail on DTLS-SRTP trust model mail thread.

Thanks
Partha 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Iñaki Baz Castillo
>Sent: Thursday, April 05, 2012 2:34 PM
>To: Roman Shpount
>Cc: [email-masked]
>support.
>For me there is a BIG difference when a kind of B2BUA is required (which
>involves signaling "transaction"). That's the barrier IMHO.
>
>> that do support ICE and SRTP, very few are actually connected directly
>> to a public internet. Most of them are connected to some sort of PBX
>> or an IP PBX type service. So, in reality you do not need to bridge
>> every IP phone with WebRTC.
>
>Please don't imagine WebRTC and SIP interop as the communication between
>two islands ;)
>
>
>
>> hurdle (I am trying to be politically correct here). WebRTC enabled
>> end points, on the other hand, will offer significant benefits to
>> traditional SIP phones, since they will allow development of higher
>> quality integrated real time communications services. I hope this will
>> drive a much quicker standard adoption.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 12:02:53 +0200

> IMHO, there is no need to tweak WebRTC recommendation for the sake of SIP proxy. I'm fine as long as there is a way in WebRTC to interop with SIP. For example, SIP proxy is not suitable for IETF SI…

For the cases in which you need recording, ok, go ahead with a SIP
SBC/B2BUA/server or whatever you need, but please let using a pure SIP
proxy for those not interested in media recording ;)

> But I'm also surprised to see that there is no response for Fabio Pietrosanti mail on DTLS-SRTP trust model mail thread.

Me too. I hope Fabio's nice explanations will be considered by the WG
rather than continuing with "DTLS (which has been NEVER tested with
SRTP) is the only magical solution for the multimedia communications".

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Apr 2012 13:14:17 +0200

> The problem arises when media encrypt/decrypt is required, and evenr more when a key update in RTP (like the DTLS EKT update) must be converted into a signaling re-INVITE by a super Signaling+Media B2BUA:

...and, in general we should not specify procedures which require an intermediary to trigger and send re-INVITEs in the first place, because that itself can then cause lots of issues.

Regards,

Christer

> every IP phone with WebRTC.

That is a *very* limited scope of what WebRTC can provide. An IT department should be able to deploy its own WebRTC infrastructure (a
Web+WebSocket server) within its "local" network, so browsers
accessing to such a local website share the network with SIP/XMPP phones/devices/softphones.

Please don't imagine WebRTC and SIP interop as the communication between two islands ;)

> required features, we will get compatibility with existing end points.

Pure SIP proxies do exist. A PBX is not always needed, so again, SIP world does not require to be "an island".

> To support the rest you will need to deploy some sort of gateway.

Not in the case SDES+SRTP is allowed in WebRTC (see Fabius's recent mails about SDES and DTLS).

Maybe it could also become a standard for SIP? I hope, but currently it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a island.

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 13:20:05 +0200

> ...and, in general we should not specify procedures which require an intermediary to trigger and send re-INVITEs in the first place, because that itself can then cause lots of issues.

Agreed. So if WebRTC-SIP interop is important (or a valuable point for
WebRTC) then please DON'T rely on the existence of such a monstrous
super signaling+media B2BUA, and DON'T assume that WebRTC-SIP interop
is the communication between two separate islands. Please. It should
be much better, and allowing SDES-SRTP is the key for that.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 09:53:20 -0400

>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_SDES-SRTP.png

This picture is not entirely correct -- ICE Lite proxy should be on both
SIP and Media path.

>  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png
Not sure why key update needs to be converted into signaling if media is
re-encrypted. Key updates on both sides of the proxy are independent. Such
proxy can also change SDES-SRTP key on each re-INVITE initiated by either
side, but apart from doing actual encryption/decryption, operation wise it
should not be any different then ICE-Lite proxy.

> to a

I actually do imagine WebRTC/SIP interop as two islands. If we need to
proxy media and convert Web+WebSocket into SIP this is a definition of
island bridge for me.

> world does not require to be "an island".

Once  again, if SIP proxy is combined with media proxy, you can bridge SIP
and WebRTC, even if DTLS-SRTP is used.

> mails about SDES and DTLS).
Once again, we still need a gateway to support ICE. If end point is adding
ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.

> it's not, so by *mandating* DTLS-EKT-SRTP in WebRTC we are creating a
Same as above.

P.S. I actually do not like DTLS-SRTP, since it does not have a large
installed base, comes with too many features, slows down call setup, will
requirecomplex interop and such. At the same time I do not think that
interop with legacy SDES-SRTP is a reason not to use it. I believe we
should design a new key exchange method, that can be mapped to SDES-SRTP
via signaling alone, addresses SDES-SRTP issues (transmitting keys over
clear channel in signaling, replay of signaling) without introducing all
the problems related to DTLS-SRTP. Any number of methods using public key
based exchange over signaling and ICE should do the trick.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 16:39:39 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> This picture is not entirely correct -- ICE Lite proxy should be on both SIP
> and Media path.

Incorrect. The proxy would communicate with the ICE-Lite server(s)
using some kind of proprietary protocol. This is already true in some
SIP proxies (SER, Kamailio, OpenSer) and media-proxies (rtpproxy,
mediaproxy, irtpproxy).

> should not be any different then ICE-Lite proxy.

Maybe.

> I actually do imagine WebRTC/SIP interop as two islands. If we need to proxy
> media and convert Web+WebSocket into SIP this is a definition of island
> bridge for me.

If you say that we need to "convert Web+WebSocket into SIP" then you
are absolutely wrong, even more taking into account that
"draft-ibc-sipcore-sip-websocket-01" (The WebSocket Protocol as a
Transport for SIP) is being adopted by the IETF SIPCORE Working Group
as a new SIP transport.

The slide 8 in [2] shows a *pure* SIP proxy, and not a "WebSocket to
SIP gateway". So ***NO*** island at signaling level, not at all.

[1] http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01
[2] http://sip-on-the-web.aliax.net/

> ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.

Building an ICE-Lite RTP/SRTP tunnel/proxy is "easy". After ICE
"handhake" the server can relay UDP packets as kernel space (conntrack
in Linux), but if you need to decrypt and encrypt you need to do that
at user space, which is much worse and requires much more CPU.

> requirecomplex interop and such.

> I believe we should
> design a new key exchange method, that can be mapped to SDES-SRTP via
> signaling alone,

And wouldn't that be a mechanism with "non a large installed base"?

> addresses SDES-SRTP issues (transmitting keys over clear
> channel in signaling, replay of signaling)

If HTTPS / WSS is used, there is no "clear channel". It would be easy
to mandate *all* the browser communication using TLS for the case in
which SDES-SRTP is used. That is a feasible and valid requirement
IMHO.

> without introducing all the
> problems related to DTLS-SRTP. Any number of methods using public key based
> exchange over signaling and ICE should do the trick.

So a complete new protocol. Bye any kind of interop (except if you
have the magic super B2BUA).

PS: Please consider reading Fabios's mails and reply to them. The
discussion will be more interesting is such nice explanations are not
ignored ;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 11:40:28 -0400

On Thu, Apr 5, 2012 at 10:39 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> SIP
> Internal protocols do not matter. The "super B2BUA" can be using a custom
protocol between RTP forwarder and SIP processor. Does not change the fact
that from logical point of view it is on both SIP and media path. At
minimum you are missing a custom protocol connection between ICE-Lite
gateway and SIP proxy. So, your picture is still wrong.

> proxy
> This assumes ICE support in SIP end points. If they do not support ICE you
still need a media proxy driven by SIP proxy. Not that different from
encryption.

> You can still get STUN messages after initial handshake, so you need to
monitor/filter media. Not sure this is possible with conntrack. If you are
doing media proxy with re-encryption in the user space you can probably get
about 10GB/sec worth of throughput with the modern dual Xeon E5 server.

> And wouldn't that be a mechanism with "non a large installed base"?

I would prefer a simpler new protocol then a complex existing one with no
real user base. Something as simple as sending public key in the SDP and
sending session key in ICE handshake STUN message would be better the DTLS.
It is simple to implement, does not send keys over clear channel, and can
be mapped to SDES-SRTP using ICE-Lite proxy with no additional signaling
messages or doing re-encryption. This probably needs to be enhanced to
support public key algorithm/key length negotiation and replay protection,
but this should be trivial as well.

> which SDES-SRTP is used. That is a feasible and valid requirement

HTTPS/WSS is used you provide better protection, but there are still issues
with cross-site scripting, web site security etc. You did prevent some of
the attacks, but you still nowhere near being secure. Once again, if we
have a key exchnage that can be mapped to SDES-SRTP, there is no need to
compromise.

> have the magic super B2BUA).

I think idea of interop is gone for all practical purposes. We gave it up
when we made ICE a requirement.

> discussion will be more interesting is such nice explanations are not
I've read it. Nice tutorial, but does not change anything I am saying here.

P.S. I have feeling that anything security related keeps being discussed
here without converging anywhere. My proposal (DTLS-SRTP by default,
SDES-SRTP from HTTPS sessions or RTP from HTTP session if enabled) got
ignored as well. This at least inline with current HTTP(S) security model.
______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 17:54:18 +0200

> that from logical point of view it is on both SIP and media path. At minimum
> you are missing a custom protocol connection between ICE-Lite gateway and
> SIP proxy. So, your picture is still wrong.

Too much lines if I draw such a custom protocol ;)

> still need a media proxy driven by SIP proxy. Not that different from

Lot's of SIP providers force the media throught a RTP proxy, which
indeed is a protocol violation since such proxies do alter the SDP
which is not allowed (theorically). But such a RTP proxy is just a UDP
tunnel so it can be done at kernel space (and it is).

> monitor/filter media. Not sure this is possible with conntrack.

It's possible, sure. First packets are handled in user space, and
later go to kernel space with conntrack rules. It's real and there are
two RTP proxies doing that: MediaProxy and irtpProxy.

> If you are

If the "EKT update to SIP re-INVITE" is not required that's a good new
(at least). What I would HATE is having to deal with a signaling B2BUA
for interop with SIP.

> the attacks, but you still nowhere near being secure. Once again, if we have
> a key exchnage that can be mapped to SDES-SRTP, there is no need to
> compromise.

I'm sure that DTLS does not solve *all* those problems.

> when we made ICE a requirement.

I don't agree. At least ICE is specified for SIP and XMPP-Jingle. SIP
vendors are lazy since they rely of annoying SBC's that break
everything but gives them money, so they "don't need" ICE. But if
WebRTC becomes real then SIP vendors will read the ICE RFC and can
implement it.

The same is not true if a new DTLS-XXXX spec is born for WebRTC since
that would require a new standard also for SIP, XMPP and so.

> here without converging anywhere.

Well, I'm learning a lot about SRTP, SDES and DTLS XD

> My proposal (DTLS-SRTP by default,

So you proposed allowing plain RTP and now just a new DTLS-XXXX-SRTP
is valid for you? :)

Well, ok, IMHO there is enough debate for now. Let's wait a bit :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 12:30:10 -0400

On Thu, Apr 5, 2012 at 11:54 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> I do not believe either one of them does ICE-Lite to RTP. As far as I
know, they are both RTP-to-RTP only.

> So you proposed allowing plain RTP and now just a new DTLS-XXXX-SRTP

I am still proposing the same thing -- some new protocol instead of
DTLS-SRTP, which does public key key exchange, and SDES-SRTP from HTTPS
with RTP from HTTP if enabled. This should allow the widest possible
interop without forcing a security model on them. I do not belive this
compromises security since it allows the application developer pick the
security model they want (new and most secure, old but interoperable, or
none at all).
______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 18:35:10 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> I do not believe either one of them does ICE-Lite to RTP. As far as I know,
> they are both RTP-to-RTP only.

Sure. I just say that "it's feasible" to do.

> DTLS-SRTP, which does public key key exchange, and SDES-SRTP from HTTPS with
> RTP from HTTP if enabled. This should allow the widest possible interop
> without forcing a security model on them. I do not belive this compromises
> security since it allows the application developer pick the security model
> they want (new and most secure, old but interoperable, or none at all).

draft required :)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 05 Apr 2012 13:42:21 -0400

On 4/5/2012 9:53 AM, Roman Shpount wrote:
>
> On Thu, Apr 5, 2012 at 5:04 AM, Iñaki Baz Castillo <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     2012/4/5 Roman Shpount <[email-masked] <mailto:[email-masked]>>:

I agree.

> re-encrypted. Key updates on both sides of the proxy are independent.
> Such proxy can also change SDES-SRTP key on each re-INVITE initiated by
> either side, but apart from doing actual encryption/decryption,
> operation wise it should not be any different then ICE-Lite proxy.

I think he's assuming the gateway/B2BUA would not decrypt/re-encrypt, 
but would proxy keys from one protocol to the other.  That's obviously 
lower overhead, but a more complex protocol.  I have never assumed that 
proxying of keys would be the default.

> Once  again, if SIP proxy is combined with media proxy, you can bridge
> SIP and WebRTC, even if DTLS-SRTP is used.
>
> Once again, we still need a gateway to support ICE. If end point is
> adding ICE to interop with WebRTC, why not add DTLS-SRTP at the same time.
>
> installed base, comes with too many features, slows down call setup,
> will requirecomplex interop and such. At the same time I do not think
> that interop with legacy SDES-SRTP is a reason not to use it. I believe
> we should design a new key exchange method, that can be mapped to
> SDES-SRTP via signaling alone, addresses SDES-SRTP issues (transmitting
> keys over clear channel in signaling, replay of signaling) without
> introducing all the problems related to DTLS-SRTP. Any number of methods
> using public key based exchange over signaling and ICE should do the trick.

I find this argument more compelling than the previous one.  Call setup 
is certainly an issue (though I believe there are answers to it).  If 
there's a good alternative (and of course I remember the IETF 
presentation from a number of years ago that showed all 14 or so extant 
key-exchange methods, none of which was an obvious choice (witness all 
the problems actually ever agreeing on one, which is why SDES has become 
the lowest-common-denominator exchange, even though most don't actually 
use it).

However, the bar for introducing Yet Another Key Exchange Protocol at 
this late date is pretty darn high, unless it's amazingly simple (and 
likely insecure or with other unwelcome properties) or a modification of 
an existing protocol.

I strongly dislike SDES for a number of reasons - not solely that the 
key is exposed to the server (as in the server/app may be evil or 
hacked), but exposure of the keys will likely engender requirements from 
authorities to record keys to allow for later decryption of media. 
That's a direct threat to privacy (especially given many organizations 
willingness to provide access without legal orders).  Also, once those 
keys are recorded, the database of such keys becomes a tempting target 
in of itself (though it's only of use to someone tapping the raw 
packets, which limits the exposure - governments generally have no 
problem getting that; individuals have more problems (but can)).  And as 
mentioned earlier, it makes the servers much more of a target for 
hacking and requests/orders from authorities.

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 14:14:06 -0400

On Thu, Apr 5, 2012 at 1:42 PM, Randell Jesup <[email-masked]>wrote:

> However, the bar for introducing Yet Another Key Exchange Protocol at this
> late date is pretty darn high, unless it's amazingly simple (and likely
> insecure or with other unwelcome properties) or a modification of an
> existing protocol.
>
> My issue is that patching DTLS-SRTP also comes with a fairly high cost now
and for the foreseeable future, since each of the patches will require an
independent interop. We either need to define and make all of those patches
a requirement, or each end point communicating with WebRTC will need to
verify if public-key exchange is supported, if ICE key exchange is
supported , and such. Each option provides a different key exchange path,
which would be a challenge for interop and provide a potential attack
vector (from my experience, protocols with a lot of complex scenarios
serving the same purpose are typically easier to break into).

> I strongly dislike SDES for a number of reasons - not solely that the key
> is exposed to the server (as in the server/app may be evil or hacked), but
> exposure of the keys will likely engender requirements from authorities to
> record keys to allow for later decryption of media. That's a direct threat
> to privacy (especially given many organizations willingness to provide
> access without legal orders).  Also, once those keys are recorded, the
> database of such keys becomes a tempting target in of itself (though it's
> only of use to someone tapping the raw packets, which limits the exposure -
> governments generally have no problem getting that; individuals have more
> problems (but can)).  And as mentioned earlier, it makes the servers much
> more of a target for hacking and requests/orders from authorities.
>

I dislike SDES for being a "somewhat secure" protocol. This is a very
dangerous territory where end user is under impression of being protected,
but reality is different. IMHO, in such situations it is better to have no
security at all, so that users know not to do anything they will regret.
______________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 20:21:04 +0200

> security at all, so that users know not to do anything they will regret.

And the same is true for DTLS, so?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Apr 2012 14:37:23 -0400

On Thu, Apr 5, 2012 at 2:21 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> This can be mitigated with either identity validation or via fingerprint
validation via an independent channel. For SDES-SRTP the only way is secure
is that everything on its path is secure, which is much harder to validate.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 5 Apr 2012 20:40:42 +0200

2012/4/5 Roman Shpount <[email-masked]>:
> This can be mitigated with either identity validation

This argument has been already refuted by Fabio, am I right? The
identity is provided by the signaling server so nothing new here.

> or via fingerprint
> validation via an independent channel.

Again, define such an "independent channel" and let me know how the
signaling server CANNOT alter it.

-- 
Iñaki Baz Castillo
<[email-masked]>