Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

[Roman Shpount <[e-mail]>]

On Fri, Apr 26, 2013 at 2:42 PM, Tim Panton <[e-mail]> wrote:

>
> On 26 Apr 2013, at 18:59, Roman Shpount wrote:
>
>
> The arguments why SDES is required in some cases instead of DTLS are:
>
> 1. Additional call setup delay caused by DTLS
>
>
> This is a serious problem - made worse by the O/A semantics - I think we
> will find that in real usage
> sites will pre-warm a DTLS connection so it is ready to go when the user
> clicks connect.
>
>
Pre-warming connection before user consent has some security implications
as well. I would much rather see a mechanism to do ICE setup and DTLS key
exchange at the same time. Should we look into extending ICE/STUN to carry
public/private key exchange?

>
> 2. High computational load on each call setup. This can be significant
> with high number of short calls being setup. This would be especially
> significant for any sort of server interfacing WebRTC or WebRTC to SIP
> gateway.
>
>
> I would dispute this - remember exactly the same users have almost
> certainly logged into an https:// portal - indeed only a small
> percentage of them will start a DTLS session for during any given web
> session. The web seems to still be working.
>

Do you dispute that DTLS key exchange represent additional CPU load? If you
dispute that this is additional load is significant, then we can look at
what percentage of the CPU load associated with the call it represents. For
short calls (10 sec or less) it is going to be a significant portion. This
is additional load on the component that is dealing with media, and the
fact that client have already done key exchange with the server is not
relevant.

3. High complexity -- you are doubling or tripling amount of code you need
> in your SRTP stack to support DTLS negotiations. Most of the code in
> readily available libraries is not needed and represents no functional
> value (certificate support, unneeded encryption methods, compression,
> streaming, etc), but will require a significant amount of support effort
> and can be a security risk (I am talking about something like OpenSSL or
> GnuTLS which ends up in the media processing stack).
>
>
> That's true to an extent, but it only applies to devices that don't
> already do TLS for something else.
> Webservers, web browsers, Sip/xmpp engines, anything offering an https
> management interface, will already have that code
> in use for other purposes. The DTLS specific code is quite small.
>

Once again you are talking about signaling/web interfaces that do
not necessarily run on the some network components, ie TLS can be handled
by web server and then signaling sent over some other protocol to the media
server which will need to support DTLS. Also, in case of web servers there
is a way to do the key exchange once per session and reuse TLS connection
and exchanged keys for multiple requests between the same client and
server. I am not sure there is a mechanism in place to do the same with
DTLS key exchanges in media connection.


> As it stands right now, I would prefer never to use DTLS-SRTP with any
> client to server communication applications, since it has no security value
> in such scenarios (server can access media anyway) and will cause
> significant usability, performance, and support issues.
>
>
> There I also disagree. The ability to offer a DTLS connection that
> presents a browser checkable x509 certificate for yourbank.com over the
> media path in a call to a bank's authorized call center agents might be a
> significant advantage.
>
>
Do web servers currently validate the remote certificate on DTLS
connections? I assume they do not, so there is no way to validate x509
certificate on the media connection. As far as I know we are not even
supposed to pass DNS names in SDP, so I am not sure what we will be
validating there in the first place.
_____________
Roman Shpount