Subject: [rtcweb] Consensus call regarding media security

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Mar 2012 16:50:25 +0200

WG,

In todays RTCWEB WG meeting there was discussion around media security
mechanism. In this meeting there was some clear consensus in the
meeting which we would like to confirm on the list.

The first was that there was overwhelming consensus that all RTP
packets SHALL be protected by SRTP.

Secondly that no one objected against making DTLS-SRTP a mandatory to
implement and the default keying mechanism. Additional mechanisms are
not precluded.

WG participants may state their position regarding these consensus calls
until 12th of April when the chairs will declare the final consensus. If
you where present in the meeting room and comment on this, please
indicate that.

Best Regards

Magnus Westerlund
For the WG chairs

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 28 Mar 2012 10:55:05 -0400

> you where present in the meeting room and comment on this, please
I already brought-up my concerns in the other thread, so I'll summarize
the core point I was making here.  Would using SRTP *require* a central
authority for establishing authenticity, or can authenticity be
established via a point-to-point means (e.g., how it's traditionally
done via SSH [i.e., upon first connection or via previous key exchange])?

This is about degrees of trust that the user is will to place upon
various methods, of course.  I am stating that the option should exist
for authenticity of an end point to be established outside of a central
authority (e.g., key exchange via other means).

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Mar 2012 17:13:53 +0200

> authority (e.g., key exchange via other means).

This will still be possible. I agree that it's very important in some
applications.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Mar 2012 11:49:22 -0400

As I have mentioned before on this list I am strongly against making SRTP
protection for RTP a requirement. I think this is an unnecessary
requirement that serves little real purpose except feeding into some
marketing message that most of the WebRTC users would not care about.
Unless use of identity is also a requirement, requiring SRTP will provide
security only in a very narrow sense of the word. At the same time I do
believe that extra standard requirements will stifle innovation and  will
complicate new service or application creation.

I have no objection to making DTLS-SRTP a required to implement protocol.
_____________
Roman Shpount

On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund <
[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 28 Mar 2012 11:56:02 -0400

Roman,

I think there is a misunderstanding (I assume you did not attend the 
meeting today).  It has been clarified that SRTP allows the NULL 
encryption algorithm, and that this option will be available.

Igor

On 3/28/2012 11:49 AM, Roman Shpount wrote:
> As I have mentioned before on this list I am strongly against making 
> SRTP protection for RTP a requirement. I think this is an unnecessary 
> Unless use of identity is also a requirement, requiring SRTP will 
> provide security only in a very narrow sense of the word. At the same 
> time I do believe that extra standard requirements will stifle 
> innovation and  will complicate new service or application creation.
>
> On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     WG,
>
>     [email-masked] <mailto:[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Mar 2012 16:06:44 +0000

Actually, I was confused about that - it seems to me it's still an open item whether to allow null cipher or not.

-hadriel

On Mar 28, 2012, at 5:56 PM, Igor Faynberg wrote:

Roman,

I think there is a misunderstanding (I assume you did not attend the meeting today).  It has been clarified that SRTP allows the NULL encryption algorithm, and that this option will be available.

Igor

On 3/28/2012 11:49 AM, Roman Shpount wrote:
As I have mentioned before on this list I am strongly against making SRTP protection for RTP a requirement. I think this is an unnecessary requirement that serves little real purpose except feeding into some marketing message that most of the WebRTC users would not care about. Unless use of identity is also a requirement, requiring SRTP will provide security only in a very narrow sense of the word. At the same time I do believe that extra standard requirements will stifle innovation and  will complicate new service or application creation.

On Wed, Mar 28, 2012 at 10:50 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
WG,

Best Regards

Magnus Westerlund
For the WG chairs

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

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

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

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 28 Mar 2012 11:10:38 -0500

> encryption algorithm, and that this option will be available.

The cipher algorithms are not the issue, and in many cases, neither is 
the CPU consumption required to do the encryption/decryption. I believe 
the larger concern that has been expressed is making WebRTC media 
dependent on DTLS-SRTP (the protocol) itself, since it is still 
relatively immature deployment-wise, and there are not many 
implementations available for developers to use to build products.

As an example, if the WG had chosen SDES-SRTP instead (even though it 
has its own set of faults), this concern would not be present, because 
that is already widely deployed, well understood and there are proven 
implementations available to choose from.

I'm not in any way lobbying against DTLS-SRTP being a MUST, though: I 
support that position.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Wed, 28 Mar 2012 18:12:03 +0200

I agree with Igor and Magnus, it's better to have "Security by Default"
in place, and then leave to the open options for:
- Key Agreement
- Encryption algorithms

Interesting consideration on RTP encryption by default:

          Why RTP Does Not Mandate a Single Security Mechanism
	http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-08

Also a must read, while designing IETF widely spread protocols:

                   Strong Security Requirements for
           Internet Engineering Task Force Standard Protocols
		http://tools.ietf.org/html/rfc3365

It's up the Telecommunication Regulators, Telecommunication Providers,
Telecommunication Equipment Manufacturer and Security Monitoring
equipment to handle the rules for Lawful interception, where an agency
have the rights to listen to a conversation.

But this is "a particular case" for which, even when there is
encryption-by-default, it's possible to listen/record the conversation.

Please remind that today there are multiple asymmetric cyberwar in
action and is an irresponsible action to even think not to include
security-by-default in any new protocol.

It's ok not to over-complicate the first version of the standard by
introducing dozen of different key management systems (SDES/ZRTP/MIKEY),
but imho it's not ok to leave in 2012 the standardizaton of a
non-encrypted-by-default protocol.

Again, imho it's an act of irresponsibility, what's defined in IETF
environment, have chance to get adopted by *billions* of people.

We must act responsibly.

-- 
Fabio Pietrosanti
Founder, CTO

Tel: +39 02 911930893 + ext: 907
Mobile: +39 340 1801049
E-mail: [email-masked]
Skype: fpietrosanti
Linkedin: http://linkedin.com/in/secret

PrivateWave Italia S.p.A.
Via Gaetano Giardino 1 - 20123 Milano - Italy
www.privatewave.com

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Mar 2012 12:15:10 -0400

Igor,

I could not attend the meeting today, but I am responding to the call of
consent on the list, that did not mention that or any other conditions on
SRTP encryption support. Does it also mean that the call can be established
using plain RTP, or is DTLS handshake, even in order to setup NULL
encruption, is still a requirement? If DTLS handshake is a requirement, I
still would object to it, since this will require an extra implementation
and interop step in anything communicating with WebRTC.

On the related note, where is SRTP profile with NULL encoding defined? I
have seen quite a few SRTP implementations but not a single one of them
supported NULL codec in any of its profiles.  Also, we should be very
careful not to support NULL encoding unless it is specifically enabled in
API. Even though I do want to support unencrypted media, I do not want
anything that allows to bid down from encrypted to unencrypted connection,
for instance during DTLS negotiation, unless specifically enabled.
_____________
Roman Shpount

On Wed, Mar 28, 2012 at 11:56 AM, Igor Faynberg <
[email-masked]> wrote:

> **
> meeting today).  It has been clarified that SRTP allows the NULL encryption
> algorithm, and that this option will be available.
>
> Igor
>
>
> rtcweb mailing [email-masked]://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Wed, 28 Mar 2012 18:17:29 +0200

> I'm not in any way lobbying against DTLS-SRTP being a MUST, though: I

That's true, if you consider that even the US National Security Agency
approved for Classified/Top-Secret use the SDES-SRTP schema
http://www.nsa.gov/ia/programs/mobility_program/index.shtml .

The reason, underlined by NSA for adoption, is that is a mature, secure
and widely diffused internet security protocol.

-- 
Fabio Pietrosanti
Founder, CTO

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Mar 2012 16:35:58 +0000

On Mar 28, 2012, at 6:15 PM, Roman Shpount wrote:

> On the related note, where is SRTP profile with NULL encoding defined? I have seen quite a few SRTP implementations but not a single one of them supported NULL codec in any of its profiles.  

The RFC for SRTP itself included NULL cipher mode - see RFC 3711.
Note that it is even mandatory to implement, but not mandatory to use - so we can specify in RTCWeb it MUST NOT be used, I believe.

-hadriel

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Mar 2012 12:42:51 -0400

On Wed, Mar 28, 2012 at 12:35 PM, Hadriel Kaplan <[email-masked]>wrote:

> supported NULL codec in any of its profiles.
>
> Note that it is even mandatory to implement, but not mandatory to use - so
> we can specify in RTCWeb it MUST NOT be used, I believe.
>
>
What was always getting me confused is that RFC 4568 provided no way to
specify that NULL cipher mode should be used. All crypto suites there are
AES CM or F8 based. This might be irrelevant if we are going to use DTLS
for cipher negotiation.

_____________
Roman Shpount

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Mar 2012 18:54:49 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Roman Shpount
> Sent: Wednesday, March 28, 2012 6:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [rtcweb] Consensus call regarding media security
> 
> Igor,
> 
> I could not attend the meeting today, but I am responding to the call
> of consent on the list, that did not mention that or any other
> conditions on SRTP encryption support. Does it also mean that the call
> can be established using plain RTP, or is DTLS handshake, even in order
> to setup NULL encruption, is still a requirement? If DTLS handshake is
> a requirement, I still would object to it, since this will require an
> extra implementation and interop step in anything communicating with
> WebRTC.

The opposite it also true.

Specifically, if Security Descriptions is required for RTCWEB endpoints,
it requires extra implementation and interop for all RTCWEB endpoints.

> On the related note, where is SRTP profile with NULL encoding defined?
> I have seen quite a few SRTP implementations but not a single one of
> them supported NULL codec in any of its profiles.  Also, we should be
> very careful not to support NULL encoding unless it is specifically
> enabled in API. Even though I do want to support unencrypted media, I
> do not want anything that allows to bid down from encrypted to
> unencrypted connection, for instance during DTLS negotiation, unless
> specifically enabled.

During their (D)TLS handshake, the (D)TLS client and server exchange
a list of cipher suites they support, and use the strongest supported
by both the client and server.  To negotiate Null, the ClientHello needs
to include the Null cipher suite and the (D)TLS server needs to choose 
Null -- if its policy allows choosing Null.  A (D)TLS server will 
usually not allow negotiating Null, and a (D)TLS client will usually 
not include Null in its list of cipher suites.

-d

> _____________
> Roman Shpount
> 
> 
> 
> On Wed, Mar 28, 2012 at 11:56 AM, Igor Faynberg <igor.faynberg@alcatel-
> lucent.com> wrote:
> 
> 
> 
> 	Roman,
> 
> 	I think there is a misunderstanding (I assume you did not attend
> the meeting today).  It has been clarified that SRTP allows the NULL
> 		As I have mentioned before on this list I am strongly
> against making SRTP protection for RTP a requirement. I think this is
> an unnecessary requirement that serves little real purpose except
> feeding into some marketing message that most of the WebRTC users would
> not care about. Unless use of identity is also a requirement, requiring
> SRTP will provide security only in a very narrow sense of the word. At
> the same time I do believe that extra standard requirements will stifle
> <[email-masked]> wrote:
> 
> 
> 			WG,
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Mar 2012 19:06:45 +0200

> Behalf Of Basil Mohamed Gohar
> Sent: Wednesday, March 28, 2012 4:55 PM
> To: [email-masked]

A central authority is not required.

DTLS-SRTP itself doesn't use the information in the DTLS certificates (the
information that might be present is ignored).  

Of course, if you want identity, then an identity service needs to exist.
But it is possible to operate DTLS-SRTP without identity, which still
provides value beyond Security Descriptions.  For example, because you
mentioned ssh, an 'easy' way to do DTLS-SRTP is to place the remote
peer's certificate fingerprint into your local address book.  No central
authority is needed, and you could get an alert if/when the remote peer's 
certificate changes.  A similar technique for HTTP is described in 
draft-ietf-websec-key-pinning.  A similar technique for ZRTP is
http://tools.ietf.org/html/rfc6189#section-12.

> authority (e.g., key exchange via other means).

I agree that is valuable.

-d

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Mar 2012 19:56:23 +0200

2012/3/28 Roman Shpount <[email-masked]>:
> protection for RTP a requirement. I think this is an unnecessary requirement
> that serves little real purpose except feeding into some marketing message
> that most of the WebRTC users would not care about. Unless use of identity
> is also a requirement, requiring SRTP will provide security only in a very
> narrow sense of the word. At the same time I do believe that extra standard
> requirements will stifle innovation and  will complicate new service or
> application creation.

SRTP (with SDES so without identity authentication) is still much
better than plain RTP, right? If I'm in an airport connected to an
open WiFi network, but I use HTTPS/WSS for signaling from my WebRTC
browser, then I can be sure that no one in the airport can intercept
my media streams (using SRTP-SDES).

Of course this does not solve the fact that there could be some MiM
attacker somewhere in the signaling path, but NOT in the airport! What
is sure is that if I was using plain RTP then everyone in the open
WiFi network could intercept my media streams.

IMHO it's really clear that SRTP (even with SDES) is MUCH better than
plain RTP. And so far I have not heard any advantage fof allowing
plain RTP other than "it allows interoperability with my 5 years ago
SIP device".

So +1 for the voted consensus.

Regards.

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

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 28 Mar 2012 14:01:15 -0400

> So +1 for the voted consensus.
This captures the sentiment of what I was trying to convey.  So, +1 to
this explanation.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 28 Mar 2012 11:30:06 -0700

Hadriel Kaplan wrote:
>
> Actually, I was confused about that - it seems to me it's still an open
> item whether to allow null cipher or not.

As a browser vendor, I could see adding an about:config option to enable 
the null cipher for debugging purposes, but would expect that for the 
vast majority of users it will never be allowed.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Mar 2012 20:39:46 +0200

2012/3/28 Timothy B. Terriberry <[email-masked]>:
> As a browser vendor, I could see adding an about:config option to enable the
> null cipher for debugging purposes, but would expect that for the vast
> majority of users it will never be allowed.

And if such an about:config option is automatically reverted upon
browser restart, then much better.

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

---

From: Justin Uberti <[email-masked]>
Date: Wed, 28 Mar 2012 16:21:37 -0400

On Wed, Mar 28, 2012 at 2:30 PM, Timothy B. Terriberry <
[email-masked]> wrote:

> the null cipher for debugging purposes, but would expect that for the vast

As another browser vendor, this is also my expectation.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 28 Mar 2012 16:41:49 -0400

On Wed, Mar 28, 2012 at 1:56 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> requirement
My main objection is that if an application developer does not take care to
develop a secure application, nothing you can do on the standard side will
make it a secure application. If I am building a public voice blog that
records a voice message that anybody can listen to on the web site security
is not needed. My assumption is that a fair number of applications would be
like this. So for such applications this is an unnecessary feature.

WebRTC will not exist in vacuum. It will communicate with other systems. It
is not limited to old SIP devices. It can be something new like server side
speech recognition that is integrated with web application. For such
application extra code and interop requirements to support security will
represent a real and significant cost. Any requirement, unless absolutely
necessary will create barriers to entry for new applications. I would like
to avoid as many of those as possible.
_____________
Roman Shpount

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 28 Mar 2012 17:08:03 -0400

On 03/28/2012 04:41 PM, Roman Shpount wrote:
> My main objection is that if an application developer does not take
> care to develop a secure application, nothing you can do on the
> standard side will make it a secure application. If I am building a
> public voice blog that records a voice message that anybody can listen
> to on the web site security is not needed. My assumption is that a
> fair number of applications would be like this. So for such
> applications this is an unnecessary feature.
>
> WebRTC will not exist in vacuum. It will communicate with other
> systems. It is not limited to old SIP devices. It can be something new
> like server side speech recognition that is integrated with web
> application. For such application extra code and interop requirements
> to support security will represent a real and significant cost. Any
> requirement, unless absolutely necessary will create barriers to entry
> for new applications. I would like to avoid as many of those as
> possible. 
> _____________
> Roman Shpount
Roman,

You make a lot of good points.  However, the inverse is true as well -
namely, that is if encryption is not mandated, most implementations will
likely leave it out, and adoption of secured communications would be
stifled even longer.  I cannot speak about the implementation
difficulties, but I can speak from the user side that most people will
remain ignorant of the underlying technology and not know enough to
demand nor enable a feature if it is optional to implement and/or use.

As WebRTC is a new standard, requiring encryption will ensure that, at
least going forward, the important concept of encryption is widely
adopted correctly from the beginning.  Tacking it on later, no matter
how much it is emphasized, will be difficult or impossible.

The scope of WebRTC is broad enough to consider that we need to think
about what's best going forward with regards to its implementation. 
Security by default is one of the best practices in general, the support
from the browser community and others that are behind it will definitely
ensure that adoption is widespread enough to make it easy enough to
integrate into existing systems, as free software solutions will become
available shortly after the standard emerges.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 28 Mar 2012 23:11:56 +0200

> like this. So for such applications this is an unnecessary feature.

In all those scenarios you mention, using security (SRTP) is not *bad*, is it?
The fact that in certain scenarios it could be not needed, it does not
mean that "no security" is better than "security".

> to avoid as many of those as possible.

RFC 3711 was created in 2004, 8 years ago!

Which "new" application you mean if it's not capable of implementing a
simple specification from 2004? how "new" is it? is it really new? or
is it a "SIP voicemail server" made in 2002?

Sorry but I still see *no* argument at all in favour of allowing plain
RTP in WebRTC. And AFAIK there is already consensus about it: plain
RTP is not allowed.

Regards.

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

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 01:56:22 -0400

> available shortly after the standard emerges.
I would actually challenge the assumption that free software will emerge.
SRTP with SDES was released 8 years ago. The only open source library that
supported it until recently was libsrtp, which is a broken unusable peace
of code spaghetti (GPF crashes, two different replay DBs which do the same
thing, random number generator that stops working after generating few
thousand keys) that supports 2/3 of the protocol (no F8 support). Majority
of open source (and a large number of closed source) clients use this
library, but do not see any of those issues since very few real SRTP calls
are actually placed. DTLS-SRTP is two years old. Support for it was just
added to GNU TLS (unusable by many due to GNU license) and to OpenSSL
(using above mentioned libsrtp). There is little or no experience with
DTLS-SRTP interop. All of these things are not trivial.

My point is, if we require support for encryption implementation in the
standard and if 4 or 5 browser vendors will cooperate, we will get vast
majority of WebRTC clients security enabled. If everything surrounding
WebRTC will not use encryption, it is not a big loss since, in most cases,
it is not doing now anyway.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Mar 2012 23:02:05 -0700

I agree with proposition #1 (SRTP) unconditionally. 

With respect to proposition #2 (DTLS-SRTP), perhaps the words "with details to be worked out" should have been added.  

I believe that the consensus achieved was only on a general direction, not an endorsement of particular proposals. 

Personally, I would like to have more specifics about the required features of DTLS-SRTP in the RTCWEB context.

> Date: Wed, 28 Mar 2012 16:50:25 +0200
> From: [email-masked]
> To: [email-masked]
> Subject: [rtcweb] Consensus call regarding media security
> 
> WG,
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 02:04:54 -0400

On Wed, Mar 28, 2012 at 5:11 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> I actually think that you are confusing encryption with security. No
encryption often means better security. Bot nets use encryption to
communicate, it does not mean they enable user security. In a lot of cases
ability for the user to check what exactly they are communicating and to
whom is security. As a security conscious person I do not want encrypted
communication from my computer or my network unless I know exactly who it
is going to. If I do not have to I would prefer my communications to be
unencrypted.

> Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of those
use libsrtp. For all of them SRTP is broken. Not a single one of them
bothered to check or only recently detected problems (
https://issues.asterisk.org/jira/browse/ASTERISK-16665).

> I do not see an argument why RTP should not be allowed. I think you are
arguing we should require a feature (SRTP) for the sake of requiring a
feature.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 02:06:29 -0400

On Wed, Mar 28, 2012 at 5:11 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> And AFAIK there is already consensus about it: plain
> RTP is not allowed.
>
>
AFAIK there is a consensus call on this exact issue right now. Nothing was
reached yet.
_____________
Roman Shpount

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 08:44:14 +0200

> This captures the sentiment of what I was trying to convey.  So, +1 to
+1

I totally support this initiative.

If we would allow plain RTP any people with just using free too such as
Cain&Abel http://www.oxid.it/cain.html can do Mitm+RTP-recording+Playing
with a couple of click.

We do not really want to see such kind of reviews and widespread of
dumb-proof hacking tools/video/howto to show "your grandma how easy is
to intercept your neighborhood calls".

That's just a bad reputation that will hit that newly born technology.

-- 
Fabio Pietrosanti
Founder, CTO

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 14:14:44 +0200

2012/3/29 Roman Shpount <[email-masked]>:
> I actually think that you are confusing encryption with security.

Roman, you still don't want to see my simple example. Could you please
reply to the following two questions rather than avoiding them?:

1) Why is better to use plain RTP in an open WiFi network (airport)
rather than using SDES-SRTP?

2) Why is plain RTP better than SDES-SRTP in any other case?

> No encryption often means better security.

Sorry, I don't agree. Encryption is not enough, of course, but it's
better than nothing (and again: the open WiFi network in the airport).

> Bot nets use encryption to
> communicate, it does not mean they enable user security.

1) User identity authentication/validation and confidentiality (encryption).

2) Just confidentiality (encryption).

3) Nothing.

1 is better than 2 and 2 is better than 3.

> In a lot of cases
> communication from my computer or my network unless I know exactly who it is
> going to. If I do not have to I would prefer my communications to be
> unencrypted.

Sure, but you are advanced user and I hope you are not talking in
behalf of the 500 millions of Facebook users in the world.
So you will be able to enter into your browser about://config and set
a null crypto key for SRTP (so you get plain RTP and can debug it or
whatever). This is confirmed to be the expectation of two browser
vendors.

> Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of those use
> libsrtp. For all of them SRTP is broken. Not a single one of them bothered
> to check or only recently detected problems
> (https://issues.asterisk.org/jira/browse/ASTERISK-16665).

I expect that, once SRTP becomes widely extended (thanks to WebRTC),
developers will really want to fix their SRTP support, including
libsrtp. But we cannot make a *new spec less secure than it can be
just due a to a bug in a opensource library.

> arguing we should require a feature (SRTP) for the sake of requiring a

I still don't understand why everyone in an airport should be able to
intercept my audio/video communication with a simple RTP sniffer.

Regards.

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

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 29 Mar 2012 14:35:37 +0200

On 2012-03-29 08:02, Bernard Aboba wrote:
> With respect to proposition #2 (DTLS-SRTP), perhaps the words "with
> details to be worked out" should have been added. 
> 
> I believe that the consensus achieved was only on a general direction,
> not an endorsement of particular proposals.
> 
> Personally, I would like to have more specifics about the required
> features of DTLS-SRTP in the RTCWEB context.

I hope someone that knows the details can elaborate on this. I thought
DTLS-SRTP has a core that you will need to implement. Then there is
clearly a question of crypto algorithms to be supported. But that also
applies to SRTP where we also need to select which crypto suites that
are to be implemented if any in addtion to the MITM. The WG will need to
select these details as part of the next steps.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Mar 2012 14:54:42 +0200

There are a number of potential variants:

a. DTLS-SRTP with IdP (Eric's proposal)
b. DTLS-SRTP as used with SIP (e.g. w/RFC 4474)
c. DTLS-SRTP-EKT
d. DTLS-SRTP with PKI (could be used in government or high security settings)

These variants differ in their potential use cases, security properties and interoperability with existing implementations.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 29 Mar 2012 10:00:07 -0400

> DTLS-SRTP interop. All of these things are not trivial.
This is FUD. Google+ Hangouts uses libsrtp for all of its calls, and over
the billions of minutes of call time to date, we haven't seen any crash
bugs that could be blamed on libsrtp. And we track this stuff pretty
closely.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 10:20:28 -0400

> rather than using SDES-SRTP?

I did not say that use of plain RTP is better in an open WiFi. what  am
saying that if I am communicating with a large number of applications it is
no worse. For me, anything that can cause protocol not to work or to be
used for some sort of an attack goes under MUST. Anything that is nice to
have should be under SHOULD. From my point of view security is a SHOULD.

> 2) Why is plain RTP better than SDES-SRTP in any other case?

In case of an enterprise network, their security concerns are not about
user privacy (it is not end user equipment in a first place) but adherence
to corporate standards or ability to monitor. In such cases SRTP is a
liability, not an asset. In Flash, in HTTP, in email, encryption is
optional. If you have anything where encryption is mandatory while
communicating with an external party, it is not acceptable in a lot of
enterprise or government environments. My goal is to have WebRTC
functionality available in as many places as possible, even if it means
giving up encryption in some cases.

Developing new applications is harder. If you are building a speech
recognition engine, you often need to add media support. Adding encrypted
media support is much harder. I want people to build new things with the
minimal effort, even just to educate themselves or to try new things. This
is what makes progress possible. The more things we pile up in front of
this, the harder it would be for people to do new things.

> And you are missing a point completely. If I am operating a corporate
network with 50,000 computers, do I need to go into about://config for all
of them? If I am put into this situation, I would just disable WebRTC
completely and call it security. This is exactly what I am trying to avoid.

> use

The issue is most of the developers would just look at this as a hurdle to
interop with WebRTC, instead of the enabling the security. If security
implementation is not taken seriously, you often end up with something that
can communicate but not really secure. For instance you can use a bad
algorithm to generate encryption keys and end up with keys that are easily
predictable. Result -- encrypted but unsecured traffic. Encryption should
be something that application developers can turn on or off, but unless
they want it, forcing support for it is a fulls quest.

> intercept my audio/video communication with a simple RTP sniffer.

There are enough cases where I or other users do not care if this happens,
so I think that encryption should be a SHOULD.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 10:31:13 -0400

On Thu, Mar 29, 2012 at 10:00 AM, Justin Uberti <[email-masked]> wrote:

> This is not a FUD. Even with 100s of millions of secured minutes we are
pushing we see new libsrtp related problems on a weekly basis. I gave you a
reference to the Asterisk bug. This bug is addressed in sourceforge, but
present in the download library (1.4.4) that is included in a lot of the
products. This bug guarantees a crash in case RTCP and even small packet
loss are present.  You can try to run crypto_get_random in a loop until it
generates an error. Simple and easy to reproduce bug. There is probably
more, but it is outside of the scope of this list. If you want to do your
users a favor -- swap this lib out from your code. You probably have a much
better crypto utilities (random, AES) in other code you use, such as
OpenSSL. The rest is trivial to re-implement and it will make the result
product faster and more secure.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 11:15:21 -0400

I wanted to clarify what i actually want to see as security/encryption
policy for WebRTC.

1. SRTP-DTLS is required to be supported and is offered by default with no
option to bid down to anything else.
2. From HTTPS session SDES SRTP can be enabled via an API method
3. From HTTP session RTP can be enabled via an API method

I only want to allow RTP from HTTP initiated session, since I see no
benefit of supporting SDES SRTP there. I only want to allow SDES SRTP from
HTTPS initiated sessions, since SDES SRTP provides no security benefits
when session description is transmitted over clear channel.

With my proposal, if an application provider does not care about security,
they will use HTTP/RTP. If they care about security, they will use
HTTPS/DTLS-SRTP or SDES-SRTP, if interop or weather forces them to do so.
Also, this way we do not provide false sense of security if someone decides
to start SDES-SRTP session from HTTP.

Is someone can explain to me how this is less secure, even in the airport
wifi comparing to SDES-RTP from HTTP session, please do so.

P.S. I do know why this is less secure then DTLS-SRTP only option.
_____________
Roman Shpount

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 29 Mar 2012 17:19:34 +0200

I agree that there was clear consensus on mandating the use of SRTP but it was not clear to me what the consensus is regarding the use of SRTP with a null cipher. Does the statement "there was overwhelming consensus that all RTP packets SHALL be protected by SRTP" mean that the null cipher will not be allowed?

Regards
Andy

> Behalf Of Magnus Westerlund
> Sent: 28 March 2012 16:50
> To: [email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 17:21:04 +0200

2012/3/29 Roman Shpount <[email-masked]>:
> I only want to allow RTP from HTTP initiated session, since I see no benefit
> of supporting SDES SRTP there. I only want to allow SDES SRTP from HTTPS
> initiated sessions, since SDES SRTP provides no security benefits when
> session description is transmitted over clear channel.
>

You miss something:

1) I access some web using HTTPS with a valid certificate and so.

2) Some HTML and JavaScript is got.

3) The JS code opens a *non* secure WebSocket connection to some other
server (same domain or not, it does not matter here).

4) WebRTC signaling goes through the WebSocket connection (so forget
the initial HTTPS hyper-secure-and-verified connection).

5) SDES-SRTP is negotiated and accepted by both peers.

6) So signaling can be intercepted (unsecure WebSocket connection),
and therefore also the SDES keys. Interception possible regardless the
initial communication was HTTPS.

7) FAIL.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 17:23:13 +0200

> I agree that there was clear consensus on mandating the use of SRTP but it was not clear to me what the consensus is regarding the use of SRTP with a null cipher. Does the statement "there was over…

IMHO it's very easy:

- The JavaScript WebRTC API MUST NOT be able to set a null cipher (never).

- The browser MAY include an option in about://config ("SRTP: user
null cipher for debugging purposes").

- Such an option is reverted (so dissabled) upon browser restart.

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

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Thu, 29 Mar 2012 11:30:17 -0400

> - Such an option is reverted (so dissabled) upon browser restart.
I think the standard need not specify that NULL cipher is allowed to
enable the debugging feature for browsers or other implementations. 
It's reasonable to assume that, when testing and debugging, one may
break the spec in the process.  Leaving it out of the standard is the
safest way to prevent it from being used in a production environment.

-- 
Libre Video
http://librevideo.org

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 29 Mar 2012 17:31:34 +0200

I would be happy with that.

Andy

> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: 29 March 2012 17:23
> To: Hutton, Andrew
> Cc: Magnus Westerlund; [email-masked]
> > I agree that there was clear consensus on mandating the use of SRTP
> but it was not clear to me what the consensus is regarding the use of
> SRTP with a null cipher. Does the statement "there was overwhelming
> consensus that all RTP packets SHALL be protected by SRTP" mean that
> the null cipher will not be allowed?
> 
> IMHO it's very easy:
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 29 Mar 2012 11:33:46 -0400

> initial communication was HTTPS.

First of  all, HTTP WebSocket connection are normally not allowed from
HTTPS initiated sessions (or generate a warning).

Second, my point was that SDES-SRTP is no more secure then plain RTP when
signaling is transmitted over clear channel. You are saying the same thing.
If SDES-SRTP is allowed, there is no harm in allowing plain RTP from HTTP,
since, as far as security is concerned, there is no difference.

Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 17:42:49 +0200

2012/3/29 Roman Shpount <[email-masked]>:
> First of  all, HTTP WebSocket connection are normally not allowed from HTTPS
> initiated sessions (or generate a warning).

Ok, I didn't check that.

> signaling is transmitted over clear channel. You are saying the same thing.

Right:)

> since, as far as security is concerned, there is no difference.

The only I meant is that the signaling must be secured. Otherwise,
using SDES-SRTP adds no security at all. But the signaling could be a
different connection (i.e. WebSocket) different from the HTTP(s)
connection used to retrieve the web.

Let's assume this example:

- The browser access the web via plain HTTP.

- The JS opens two websocket connections:
  1) First one for the WebRTC signaling, a secure WS connection.
  2) Second one for other realtime stuff, a NON secure WS connection.

If the SDES key is carried over the first WS connection (wss) then
it's ok, it provides confidenciality. But if the SDES key is carried
over the second WS connection (ws, so unsecure) then it's
interceptable and therefore also the SRTP.

Question: can the WebRTC stack figure which WS connection is being
used for WebRTC signaling?
Autoanswer: NO, since the signaling protocol is up to the app developer.

So Houston we have a problem if we try to make requirements in which
SDES-SRTP can be used. I'm in favour of mandating SDES-SRTP in WebRTC,
but we need to solve this issue, and it is not easy (AFAIK).

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 29 Mar 2012 17:02:08 +0000

WebRTC trust model has to be considered as one of the main factor for deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES. There is no means to track or analyze whether Dr.Evil involves in monitoring or recording or terminate the media traffic.  It will be good in case whoever advocate for SDES explain how SDES fits within WebRTC trust model.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Magnus Westerlund
>Sent: Wednesday, March 28, 2012 8:20 PM
>To: [email-masked]
>mechanism. In this meeting there was some clear consensus in the meeting
>which we would like to confirm on the list.
>
>The first was that there was overwhelming consensus that all RTP packets
>SHALL be protected by SRTP.
>

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 19:31:46 +0200

> WebRTC trust model has to be considered as one of the main factor for deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES…

Sure!

From:
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-arch/?include_text=1

"   The basic assumption of this architecture is that network resources
   exist in a hierarchy of trust, rooted in the browser, which serves as
   the user's TRUSTED COMPUTING BASE (TCB).  Any security property which
   the user wishes to have enforced must be ultimately guaranteed by the
   browser (or transitively by some property the browser verifies)."

So, it means that if the browser already have a hierarchy of trust to
use TLS for HTTPS, then SDES-SRTP will inherit the trust-properties of
the HTTPS website from which it's loaded.

It seems to me quite easy to fit SDES-SRTP into the browser model, as it
allow you to assure that the communication path between the client and
the server is secure.

Do you expect WebRTC to be only peer-to-peer/client-to-client?

I sincerly expect *a lot* of communications to goes trough SIP/RTP media
proxy for security purpose, for billing purposes, for value added
service purpose.

SDES-SRTP provide a very reliable and simple way to let a WebRTC peer to
establish security with the server, assuming that it already have
established security trough HTTPS/TLS that's a consolidate trust method.

-- 
Fabio Pietrosanti
Founder, CTO

Tel: +39 02 85961748 (direct)
Mobile: +39 340 1801049
E-mail: [email-masked]
Skype: fpietrosanti
Linkedin: http://linkedin.com/in/secret

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 19:32:51 +0200

> WebRTC trust model has to be considered as one of the main factor for deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES…

If Dr. Evil attaks my back webpage and owns it, and then I visit it
(HTTPS with valid certificate) and enter my back credentials... for me
that is much worse than the case you describe. Should we drop HTTPS
then because it does not fit 100% "security" requirements?

BTW: previously you wanted to allow plain RTP in WebRTC... and now
DTLS-SRTP is the only valid solution? :)

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 29 Mar 2012 19:34:15 +0200

> established security trough HTTPS/TLS that's a consolidate trust method.

+2  (I don't use "+1" since I don't use Google+).

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

---

From: "Fabio Pietrosanti (naif)" <[email-masked]>
Date: Thu, 29 Mar 2012 19:56:47 +0200

> select these details as part of the next steps.

Hi Magnus,

imho the selection of a crypto algorithms is not the first priority (it
will probably goes with some well known AES-stuff), as the first
priority is to define which will be the Key Management system to be used
for DTLS-SRTP.

Given the SRTP standard,the security and trust model radically change
depending on the key exchange system details.

With DTLS-SRTP the key exchange and security/trust model seems quite
opaque and there's not a specific guideline to implement it and/or to
satisfy a specific security requirement.

While the SDES-SRTP method satisfy  all the 4.1.1.* Calling method
requirement of
http://tools.ietf.org/html/draft-ietf-rtcweb-security-02#section-4.1.1 ,
because it would just rely on existing TLS/HTTPS method.

So it would not even enter into the context/discussion of trust with the
server, that has been already managed by the existing TLS/HTTPS.

I did not really understand how DTLS-SRTP would like to manage the
so-many-complicated trust scenario that TLS/HTTPS already manage.

Imho everything should be simplified with two context:
- Do you need end-to-site (TLS equivalent) security?
  SDES-SRTP + TLS/HTTPS

- Do you need end-to-end (ZRTP/PGP equivalent) security?
  DTLS-SRTP with user-driven verification schema (such as Short
Authentication String / Fingerprint / Key pinning)

-- 
Fabio Pietrosanti
Founder, CTO

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 31 Mar 2012 10:06:56 +0000

Inaki,

I agree with your argument of allowing HTTP as it fit with this trust model. 

Please note that I request for plain RTP with user consent (configuration) as it will fit within trust model with exception. I'm saying that SRTP-DTLS is the only mechanism which meets all the requirement as of now in the listed candidates. Having said that, in case anybody convince for changing the trust model then SDES shall be considered or SDES may be preferred over SRTP-DTLS. IMO, trust model should help for selecting security key mechanism.

I'll reply to another thread separately.

Thanks
Partha

>Sent: Thursday, March 29, 2012 11:03 PM
>To: Ravindran, Parthasarathi
>Cc: [email-masked]
>> WebRTC trust model has to be considered as one of the main factor for
>deciding the key mechanism. AFAIK, SDES does not fit into WebRTC as
>Dr.Evil HTTPS RTCWeb server must be trusted in case of SDES. There is no
>means to track or analyze whether Dr.Evil involves in monitoring or
>recording or terminate the media traffic.  It will be good in case
>whoever advocate for SDES explain how SDES fits within WebRTC trust
>model.
>
>that is much worse than the case you describe. Should we drop HTTPS then
>because it does not fit 100% "security" requirements?
>
>BTW: previously you wanted to allow plain RTP in WebRTC... and now DTLS-
>SRTP is the only valid solution? :)
>
>--
>Iñaki Baz Castillo
><[email-masked]>