Subject: Re: [rtcweb] SRTP not mandatory-to-use

From: Harald Alvestrand <[email-masked]>
Date: Mon, 02 Jan 2012 13:48:16 +0100

At the risk of resurrecting a dead horse

On 12/14/2011 03:41 PM, Xavier Marjou wrote:
> Is there any scientific reference comparing the performances (cpu) of
> a SRTP communication vs an RTP communication on a smartphone device,
> or on an interworking network server? The feedback I have is that SRTP
> overhead is significant, at least on interworking network servers
> handling several calls in parallel. One example is
> http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS  which gives figures,
> perhaps non-optimized, but figures anyway:
>
>
> 00:59:38.531 os_core_unix.c pjlib 0.9.0-trunk for POSIX initialized
> MIPS test, with CPU=180Mhz,  198.0 MIPS
> Clock  Item                                      Time     CPU    MIPS
>   Rate                                           (usec)    (%)
>   8KHz codec encode/decode - L16/8000/1           1704    0.170    0.34
>   8KHz stream TX/RX - G.711                       6786    0.679    1.34
>   8KHz stream TX/RX - G.711 SRTP 32bit           21688    2.169    4.29
>   8KHz stream TX/RX - G.711 SRTP 32bit +auth     33501    3.350    6.63
>   8KHz stream TX/RX - G.711 SRTP 80bit           21725    2.172    4.30
>   8KHz stream TX/RX - G.711 SRTP 80bit +auth     33551    3.355    6.64
Note that the codec used here (G.711) is hardly a complex encoder; it 
can be implemented using a lookup table, which is probably small enough 
to serve out of cache.
The first line seems to have been included by a copy/paste error.

A different cut'n'paste from the same table:

  8KHz codec encode/decode - G.711                2701    0.270    0.53
  8KHz codec encode/decode - GSM                 75750    7.575   15.00
  8KHz codec encode/decode - iLBC              2856203  285.620  565.53
  8KHz codec encode/decode - Speex 8Khz         436162   43.616   86.36
  8KHz codec encode/decode - L16/8000/1           1704    0.170    0.34
  8KHz stream TX/RX - G.711                       6786    0.679    1.34
  8KHz stream TX/RX - G.711 SRTP 32bit           21688    2.169    4.29
  8KHz stream TX/RX - G.711 SRTP 32bit +auth     33501    3.350    6.63
  8KHz stream TX/RX - G.711 SRTP 80bit           21725    2.172    4.30
  8KHz stream TX/RX - G.711 SRTP 80bit +auth     33551    3.355    6.64
  8KHz stream TX/RX - GSM                        82035    8.203   16.24
  8KHz stream TX/RX - GSM SRTP 32bit             90890    9.089   18.00
  8KHz stream TX/RX - GSM SRTP 32bit + auth      99334    9.933   19.67
  8KHz stream TX/RX - GSM SRTP 80bit             90893    9.089   18.00
  8KHz stream TX/RX - GSM SRTP 80bit + auth      99356    9.936   19.67

So if someone wishes to do GSM, the overhead of SRTP is on the order of 
10%; if they do iLBC, the overhead is microscopic. On this particular 
platform and implementation.

---

From: Randell Jesup <[email-masked]>
Date: Tue, 03 Jan 2012 01:29:53 -0500

> platform and implementation.

Two things:
1) the numbers are odd (cache effects?) - SRTP+AUTH takes an additional 
2.7% cpu for GSM, but an additional 1.7% on GSM.
2) the iLBC number is non-sensical for an optimized implementation and 
is almost certainly the floating-point implementation from the spec (and 
perhaps even on hardware without FP support).

I'll also note a 180MHz MIPS processor is very slow by modern standards. 
  Our "lowest-spec" CPU should probably be the equivalent of a 300MHz 
ARM (and that's arguably too low, perhaps significantly too low).

-- 
Randell Jesup
[email-masked]

---

From: <[email-masked]>
Date: Tue, 3 Jan 2012 12:55:35 +0000

Hi,

Randell Jesup wrote:
>  Our "lowest-spec" CPU should probably be the equivalent of a 300MHz ARM
>(and that's arguably too low, perhaps significantly too low).
>

Looking at the specs of any recent smartphones with Wi-Fi and/or 3G connectivity, even the low-end ones seem to have at least 600 MHz ARM. Anything that I could imagine running WebRTC, in terms of real products, will have an even faster CPU. 

Nokia has had phones with SIP and SRTP for several years, so I doubt that will be an issue. It's all the other stuff that WebRTC will need that will be much more challenging.

Markus

---

From: Randell Jesup <[email-masked]>
Date: Tue, 03 Jan 2012 14:58:13 -0500

> Nokia has had phones with SIP and SRTP for several years, so I doubt that will be an issue. It's all the other stuff that WebRTC will need that will be much more challenging.

I chose 300MHz because that's the speed of the ARM in a first-generation 
DaVinci and some of the older OMAPs I believe.  Agreed, not really 
current devices likely to get webrtc - though support for lower-spec 
devices does enable people wanting to build really inexpensive web 
devices (wired or wireless).  And lower overhead also means lower 
battery use (though Justin reminds me that the CPU isn't the limiting 
factor here usually; it's the display and wireless link).

I should note that audio SRTP overhead isn't really the issue; it's the 
overhead for encrypting/decrypting far larger streams of video, and the 
SRTP overhead is (mostly) proportional to bitrate, so large resolution 
and/or low-compression streams will use more overhead.

Note: while I'm discussing nits here, I am in overall favor of 
SRTP-required, if for no other reason than to head off bid-down attacks. 
  I'd love to have the option of not using it in very specific scenarios 
(PSTN gateway, internal corporate network or one with an PBX that 
doesn't support a keying scheme we do), but I've yet to see a solution 
for those that doesn't hurt other use-cases.  (And I've tried to find a 
way.)

(And yes, SRTP doesn't help you much if you're MITM'd - see ekr's 
identity stuff & BrowserID for that.)

-- 
Randell Jesup
[email-masked]

---

From: Justin Uberti <[email-masked]>
Date: Tue, 3 Jan 2012 17:38:35 -0500

On Tue, Jan 3, 2012 at 2:58 PM, Randell Jesup <[email-masked]>wrote:

>> Looking at the specs of any recent smartphones with Wi-Fi and/or 3G
>> connectivity, even the low-end ones seem to have at least 600 MHz ARM.
>> Anything that I could imagine running WebRTC, in terms of real products,
>> will have an even faster CPU.
>>
>> Nokia has had phones with SIP and SRTP for several years, so I doubt that
>> will be an issue. It's all the other stuff that WebRTC will need that will
>> be much more challenging.
>>
>
> DaVinci and some of the older OMAPs I believe.  Agreed, not really current
> devices likely to get webrtc - though support for lower-spec devices does
> enable people wanting to build really inexpensive web devices (wired or
> wireless).  And lower overhead also means lower battery use (though Justin
> reminds me that the CPU isn't the limiting factor here usually; it's the
> display and wireless link).
>

I would argue that if you're processing video streams, SRTP overhead pales
compared to the heavy encode/decode lifting.

> (PSTN gateway, internal corporate network or one with an PBX that doesn't
> support a keying scheme we do), but I've yet to see a solution for those
> that doesn't hurt other use-cases.  (And I've tried to find a way.)
>

If we make SRTP mandatory to use, people will figure out a way to make SRTP
work in their scenarios. If we don't, people will continue to use the same
old objections as to why they can't deploy SRTP.

SRTP isn't a panacea, but I think we have a chance to take a big step
forward here.

>
> (And yes, SRTP doesn't help you much if you're MITM'd - see ekr's identity
> stuff & BrowserID for that.)
>
> --
> Randell Jesup
> [email-masked]
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Jan 2012 15:08:52 -0800

Justin Uberti said:

"If we make SRTP mandatory to use, people will figure out a way to make SRTP work in their scenarios. If we don't, people will continue to use the same old objections as to why they can't deploy SRTP.

SRTP isn't a panacea, but I think we have a chance to take a big step forward here."

[BA] In practice, the details of precisely how this is implemented make a difference. 

For example, it is quite different to require SRTP in all circumstances, versus say, recommending that SRTP be preferred by default but allowing RTP to be negotiated (via RFC 5939 or simple fallback).  

Requiring SRTP in all circumstances (e.g. offering RTP/SAVP(F) and not falling back or allowing negotiation of RTP/AVP(F)) would not preclude gateways from translating to RTP/AVP(F), without user knowledge.  

This would result in an illusion of security, compared with an actual negotiation which would apprise the user as to whether security is actually in place.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Jan 2012 15:59:40 -0800

Chris Blizzard said:

"That really depends on how it's presented to users."

[BA] The choice is either not to provide any information to users, or to provide information in some form. 

If there is no information provided, then the user would not know whether media security is really in place or not.   

While that might lead to suitably low expectations (e.g. users should assume no security, even if SRTP is used), the conversation had talked about setting a higher bar. 

If information is provided, then it would seem desirable for that information to be reflective of the level of security in place.   If not, why bother?

---

From: Ted Hardie <[email-masked]>
Date: Tue, 3 Jan 2012 16:02:58 -0800

> Requiring SRTP in all circumstances (e.g. offering RTP/SAVP(F) and not
> falling back or allowing negotiation of RTP/AVP(F)) would not preclude
> gateways from translating to RTP/AVP(F), without user knowledge.
>
> This would result in an illusion of security, compared with an actual
> negotiation which would apprise the user as to whether security is actually
> in place.
>
I'm a little lost.  In a gateway implemented in a back-to-back user
agent, won't you end up with the same
illusion?

The case I think you're talking about is this:

UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2

Do you expect that the gateway would be refuse to use SRTP on one side
if it intended not to use it on the other?  That seems pretty unlikely
to me personally, especially in cases where the gateway is to the PSTN
or a standard SIP system.  Or do you expect that the negotiation would
be extended so that the gateway somehow indicates that it will not
SRTP on side two to side one?

If the requirement is SRTP always for WEBRTC, then a b2bUA would have
to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC
applications, but that seems to be what we want.

What am I missing?

Ted

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jan 2012 16:19:30 -0800

> applications, but that seems to be what we want.

I, too, am confused.

Without using the words SRTP, here's the functionality I want, starting from
first principles.

When I have a call, I would like to know to the extent possible:

(a) Who the entity on the other end is.
(b) That the call is secure to that entity, i.e., that we provide
confidentiality
and integrity for the data.

Obviously, once the data is delivered to the entity on the other side, I can
no longer know what the security properties are. At best, they can simply
assert those properties, whether via some technical mechanism or via
a non-technical mechanism ("I promise to keep this conversation secret
and I'm willing to sign an NDA"). That's out of scope for the security services
we know how to offer.

Now, it's clearly the case that there are settings in which there is a gap
between the entity I want to be talking to and the entity that the technology
allows me to provide a secure association to. One such example, as Ted
suggests, is a gateway to the PSTN, which does not provide a secure
channel. What I would like at that point is to be able to:

(a) know that I am talking to the gateway and be able to distinguish this
case from that where I am talking directly to the entity of interest.
(b) have confidentiality and integrity provided for my data in transit to the
gateway.

Obviously, this has the potential to be misleading if the UI is done badly,
but that seems like a result of having a system with differential security
properties, not the result of having always-on crypto for the first hop
link. The only way I know to not have people be potentially confused is
to only have one security level, but since we've already established that
it can't always be secure to the target entity, the only way to have one
security level is to have it be never secure, which also seems rather
undesirable.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Jan 2012 16:28:19 -0800

Ted Hardie said: 

> agent, won't you end up with the same illusion?
> 
> if it intended not to use it on the other? 

[BA] If the SBC needed to enable communication with a legacy endpoint, then it
might want to negotiate security compatible with that endpoint. 

Today there are PSTN gateways that support SRTP with SDES, but interop is 
frequently an issue (I've had to debug interop issues countless times), so 
I've often had to advise customers to turn SRTP off until an issue was resolved. 

Few PSTN gateways support any flavor of end-to-end security today (e.g. ZRTP, DTLS/SRTP, etc.), 
so a failover option is even more likely in that case. 

> applications, but that seems to be what we want.

[BA] What you're missing is what legacy systems actually implement (see the SIPIt reports).

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jan 2012 16:41:50 -0800

> [BA] What you're missing is what legacy systems actually implement (see the

In the interest of clarity, when I say that I would require SRTP for WebRTC,
what I mean is that if you wish to have your WebRTC client talk to a PSTN
gateway that doesn't support SRTP, you would need to have a gateway
in between. E.g.,

UA-1 <--- SRTP ---> WebRTC GW <--- RTP --> PSTN GW <---- PSTN

I don't know what others have in their hands, but it's not my intent to levy
a requirement for crypto through the entire RTP pathway, let alone to
endpoints which don't even speak RTP. Of course, in the case above,
whatever your UA displayed about the identity of the target would be
somewhat disappointing.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 3 Jan 2012 16:57:19 -0800

> Looking at the specs of any recent smartphones with Wi-Fi and/or 3G connectivity, even the low-end ones seem to have at least 600 MHz ARM. Anything that I could imagine running WebRTC, in terms of…

[BA] I agree that computational load is a non-issue.  I've deployed very inexpensive devices (e.g. ATAs costing less than $100) that support SRTP (albeit only with simple keying mechanisms like SDES).   

In practice, it's not SRTP computational load, but interop particularly in keying mechanisms where the issue is.  I've had to advise customers to turn SRTP off on devices that claim to support it, due to interop issues (e.g. SDES).  

There is some support out there for ZRTP, but few DTLS/SRTP implementations.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 04 Jan 2012 04:11:24 -0500

On 1/3/2012 7:41 PM, Eric Rescorla wrote:
> On Tue, Jan 3, 2012 at 4:28 PM, Bernard Aboba<[email-masked]>  wrote:
>>
>> Ted Hardie said:
>>

Only if it expects to remove itself from the media path.  If it's going 
to remain on the media path (and I believe for a number of reasons 
that's required), this is a non-issue.

I think it has to be on the media path due to the ICE and 'consent' 
requirement.  If we didn't have that, then we could *consider* allowing 
no-SRTP and get a benefit from it (i.e. avoidance of requiring a gateway 
to talk to non-webrtc destinations).  However, I see no viable way to 
obtain such a benefit without significant compromise to security and/or 
some of the use-cases, and/or without presuming unlikely changes from 
legacy infrastructure (though some PBXes might).

I spent a while on this, because the benefit is real - not in reducing 
overhead, but in reducing delay in some/many cases (if the gateway isn't 
close-to-colocated with one or another of the endpoints).  Cullen and I 
talked about it offline as well.  The best I came up with was not a 
viable solution, IMHO, and you open up the risk of bid-down attacks if 
you're not careful.

> UA-1<--- SRTP --->  WebRTC GW<--- RTP -->  PSTN GW<---- PSTN
>

:-)

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Jan 2012 17:28:12 -0500

>
>  Justin Uberti said:
>
> "If we make SRTP mandatory to use, people will figure out a way to make
> SRTP work in their scenarios. If we don't, people will continue to use the
> same old objections as to why they can't deploy SRTP.
>
>
>
I thought our goal is to design a web based real time communication network
with the widest possible set of capabilities. I never thought that the goal
of this group is to promote other architectural agendas, even the ones as
such as spreading communications security. Security of communications would
be defined by the application developer. If application developer designs
something that is meant to be insecure (like place all calls through a
middle server that will record everything and publish it on an open web
site), it would be. I do not understand why application developer with
WebRTC should not have an option to communicate without SRTP. Ability for
developer to specify that RTP is allowed for certain connection takes
nothing from security of WebRTC, and makes a lot of issues (such as
interop, getting initial application developed and tested, etc) a lot
simpler.

I do believe that SRTP CPU load argument is nonsense (especially with newer
CPUs where there is hardware AES offload), but I the only argument I heard
so far for mandatory SRTP use was that future WebRTC developers are so
incompetent and ignorant that they will never use SRTP unless we force
them. Make it simple to specify that SRTP is required via an API, make it
default, and developers will use it. As long as WebRTC connection does not
automatically fall back to RTP if SRTP connection is required and cannot be
established, I simply don't see what the problem is.
_____________
Roman Shpount

---

From: Alan Johnston <[email-masked]>
Date: Wed, 4 Jan 2012 17:09:23 -0600

Here is the problem - allowing RTP opens up WebRTC to a bid down
attack on media security.  There are few good ways to prevent this bid
down attack, and none of them work given the lack of standardization
and control over WebRTC signaling.

Also, allowing both RTP and SRTP is a user interface nightmare for the
browsers.  They have had all kinds of problems in the past with simple
HTTP/HTTPS, and this will be even uglier.

Mandating SRTP avoids both these problems.

- Alan -

On Wed, Jan 4, 2012 at 4:28 PM, Roman Shpount <[email-masked]> wrote:
> nothing from security of WebRTC, and makes a lot of issues (such as interop,
> getting initial application developed and tested, etc) a lot simpler.
>
> incompetent and ignorant that they will never use SRTP unless we force them.
> Make it simple to specify that SRTP is required via an API, make it default,
> and developers will use it. As long as WebRTC connection does not

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Jan 2012 18:23:57 -0500

On Wed, Jan 4, 2012 at 6:09 PM, Alan Johnston <[email-masked]>wrote:

> If create connection API request does not specifically allow RTP
connection, it should not be negotiated. The only possible bid down attack
would be due to replacement of JavaScript (or some other cross site
scripting issue). In this case security would already be compromised. So,
what exact problem are we solving here by removing allow RTP option from
the API?

> HTTP/HTTPS, and this will be even uglier.
What does this have to do with user interface? This is an API (application
decision). User either trusts the application to provide security, or not.
I am not sure HTTP/HTTPS analogy applies here since we are dealing with
much more complex applications here, so either application developer will
design something that is secure, or not. User has no way to verify this.
Unless we provide some end-to-end security verification methods (which are
not part of SRTP as it is defined now), user interface is almost pointless,
since all it can say that secure connection is established to some unknown
remote party.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jan 2012 17:13:56 -0800

> attack on media security. 

[BA]  There are a number of potential approaches that can minimize the
potential for bid-down while still preventing interoperability failure. 

Even if we assume all hosts implement SRTP with perfect interoperability
such approaches would still be necessary, if only to permit debugging and
minimize interop problems with respect to key management. 

As an example, it is possible to constrain an initial offer (e.g.
require RTP/SAVP(F) with some key management scheme), while
allowing fallback in the event of failure. 

The fallback could be to a scheme with lesser but still passable security
(e.g. from RTP/SAVP(F) with ZRTP or DTLS/SRTP to SDES), or it could
be all the way to RTP/AVP(F) if policy permits it and the user approves.  

> Mandating SRTP avoids both these problems.

[BA] If the problem were so easy to solve, why is AVT moving forward on
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ?

The reality is that RTCWEB cannot avoid grappling with the issues articulated
in that document, given the wide range of RTCWEB usage scenarios and the 
current state of implementations.   

By itself, mandating SRTP accomplishes as little (or even less) than mandating IPsec 
did within IPv6.  At the time of that debate, IKEv1 was widely implemented and even
IKEv2 was more widely implemented than either ZRTP or DTLS/SRTP
are today.  Yet because of the wide range of usage scenarios
"one size fits all" key management didn't work there, and as AVT has already 
recognized, it isn't likely to work here either. 

So yes, we can mandate SRTP.  In theory it isn't hard to implement and the
computational cost is low.  But let's not kid ourselves that this gets us very far
down the road to security and interoperability  in a wide range of RTCWEB 
scenarios.  Accomplishing this is with a single key management scheme is 
unlikely, for the reasons draft-ietf-avt-srtp-not-mandatory describes.   And if
you accept that (as AVT WG appears to), then we are left with the same question,
just one layer up.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 Jan 2012 17:23:04 -0800

On Wed, Jan 4, 2012 at 3:23 PM, Roman Shpount <[email-masked]> wrote:
>>
> If create connection API request does not specifically allow RTP connection,
> it should not be negotiated. The only possible bid down attack would be due
> to replacement of JavaScript (or some other cross site scripting issue). In
> this case security would already be compromised. So, what exact problem are
> we solving here by removing allow RTP option from the API?
>

I think the bid-down attack being discussed is one in which the user
prefers SRTP but accepts RTP; in those cases an attacker can remove
SRTP from the set offered of offered choices and force an insecure
communication to occur by having the answerer appear to prefer to RTP
(when, in fact, they saw only an RTP choice in the offer).  At least
as far as I can see, this attack is unrelated to the replacement of
the Javascript application.

regards,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Wed, 4 Jan 2012 17:32:23 -0800

> potential for bid-down while still preventing interoperability failure.

Are they easier or harder to deploy than SRTP?

> http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ?

As the document pretty clearly states, because RTP is used in a
variety of deployment scenarios, including any source multicast (see
section 2).  At least my personal reading is also not that the
document recommends against consistently securing the confidentiality
and integrity of RTP where possible; it simply points out that there
are other security methods available in some networks (e.g. 3GPP
networks) and that there are some deployments where it is not.

So far, I have not heard use cases for RTCWEB that include deployments
where it is not possible.  If you could provide text for the use
case/scenarios draft that illustrates one and explain why, that would
be very useful in moving this discussion forward.

Until then, I think the Danvers Doctrine pretty plainly pushes us to
make SRTP mandatory to implement.  The key question is whether is
whether it is:  always on; default on; negotiated on.  I am not
personally persuaded that "negotiated on" makes for easier debugging
of the resulting system, at least in the common case.  To me, it
increases the number of possible attacks and thus the code needed to
mitigate them.

Just my personal opinion, without hats.

thanks,

Ted

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jan 2012 17:35:42 -0800

> the Javascript application.

[BA] An alternative is to force an initial offer preferring RTP/SAVP(F). 
That way, if both endpoints support SRTP and the offered key management
scheme, it is guaranteed to be negotiated.  Only if the preferred option is
not mutually supported could an alternative be selected.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Jan 2012 22:25:13 -0500

> not mutually supported could an alternative be selected.
I would actually prefer a situation where a deliberate decision by
application developer is required to allow RTP. By default, SRTP only
connection should be accepted with no option to bid down (ie offer with
RTP/SAVP(F) only and no null codec). If developer specifies that non-secure
connections are allowed, only then RTP/AVP should be present in the offer
or accepted in the answer (with crypto attributes or some other way to
specify that AVPS is also supported). This way there no "accidental" RTP
connections.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 4 Jan 2012 22:36:25 -0500

> increases the number of possible attacks and thus the code needed to

This argument about debugging keeps coming up, and although I am not
persuaded by this argument, it is not a completely unreasonable request.
However, I don't think this needs to be controllable from JS. One could
easily imagine a plain-RTP option being available from a developer options
dialog or console, for use by developers in debugging specific problems
with their service.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 04 Jan 2012 23:45:55 -0500

On 1/4/2012 10:25 PM, Roman Shpount wrote:
>
> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> RTP/SAVP(F) only and no null codec). If developer specifies that
> non-secure connections are allowed, only then RTP/AVP should be present
> in the offer or accepted in the answer (with crypto attributes or some
> other way to specify that AVPS is also supported). This way there no
> "accidental" RTP connections.

As Eric R. would probably tell you, you not only have to worry about 
bid-down attacks (and they're important), but also the "threat model" 
for rtcweb is that we don't trust:
a) the JS application
b) the service provider/website
to maintain security and privacy for our conversation.  The JS 
application may be malicious or may have been subverted without 
knowledge of the provider, or the provider may have been compromised (by 
an attacker or by legal force) even if they're not actively evil.

If you mandate SRTP (and use DTLS-SRTP), then the application and the 
website never have access to the keys, and you have end-to-end security 
(modulo gateways).  If you combine that with the identity mechanisms 
from ekr's draft/presentation at Taipei, and you have verified, no MITM, 
end-to-end encryption.  (Without identity info, we have no way to detect 
a MITM attack, especially if brokered by the service provider.)
Side note: SDES generally has the same problem; the JS app and service 
provider/website have access to the keys.  (With some pain we might be 
able to encrypt the SDES keys themselves, but I'm not sure that's 
practical.)

The "interop with legacy needs no SRTP or optional SRTP" argument fails 
if we have to go through a gateway to get to legacy equipment anyways. 
And though I've tried hard to find a practical way around it, the 
'consent' requirements handled by using ICE/etc end up requiring us to 
use a gateway. If you're using a gateway to talk to legacy devices 
and/or PSTN gateways, you can include SRTP in the gateway for the webrtc 
side.

-- 
Randell Jesup
[email-masked]

---

From: Stefan Hakansson LK <[email-masked]>
Date: Thu, 5 Jan 2012 07:57:19 +0100

> "accidental" RTP connections.

FWIW I proposed some time earlier that the application, when creating 
the PeerConnection object, could say that RTP is allowed (default is 
not-allowed). If this is not done no RTP would be offered nor accepted.

Of course this does not help if you don't trust the application.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 5 Jan 2012 07:17:55 +0000

Randell,

I agree that SRTP has to be mandated-to-implement for the reasons which you have mentioned and also agree that SRTP fallback should not be accepted by default to avoid bid-down attack.

The only possible solution for RTP media in WebRTC is to provide the user configuration in the browser (WebRTC client) to allow the trust website to create RTP media based session. In this model, (browser) user provides the consent to pass RTP media and user will know the implications. In case untrusted website asks for RTP session through JavaScript, those request will be declined. Hope it is inline with trusted model as user is responsible for RTP session and not JavaScript or web-server. 

RTP mechanism shall be used in the trusted site & network like intranet, Enterprise application. The need of RTP session is to reduce WebRTC-GW cost in performing SRTP-RTP. 

I understand that it adds up complication in browser implementation as browser has to consider both SRTP & RTP based on the configuration. It is more like pop-up is blocked in browser by default in the browser except for personal banking website based on user configuration.

My point is that WebRTC client should be flexible for different deployment rather than considering every URL is untrusted.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Randell Jesup
>Sent: Thursday, January 05, 2012 10:16 AM
>To: [email-masked]
>Subject: Re: [rtcweb] SRTP not mandatory-to-use
>
>> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> non-secure connections are allowed, only then RTP/AVP should be
>> present in the offer or accepted in the answer (with crypto attributes
>> or some other way to specify that AVPS is also supported). This way
>> there no "accidental" RTP connections.
>
>a MITM attack, especially if brokered by the service provider.) Side
>note: SDES generally has the same problem; the JS app and service

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Jan 2012 08:21:24 +0100

> http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory ?
Because srtp-not-mandatory is pushing the token to the next layer up.
In particular, quoting from -07:

    When it comes to fulfilling the "MUST Implement" strong security for
    a specific application, it will fall on that application to actually
    consider what building blocks it is required to support.  To maximize
    interoperability it is desirable if certain applications, or classes
    of application with similar requirements, agree on what data security
    mechanisms and key-management should be used.  If such agreement is
    not possible, there will be increased cost, either in the lack of
    interoperability, or in the need to implement more solutions.
    Unfortunately this situation, if not handled reasonably well, can
    result in a failure to satisfy the requirement of providing the users
    with an option of turning on strong security when desired.

We're the next layer up.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jan 2012 23:42:26 -0800

> (modulo gateways).  

[BA] That depends very much on the exact design of the system.  Within
RTCWEB the term "DTLS/SRTP" is potentially describing a system
different from the framework used in SIP, if signaling is done out of band (e.g.
we're not assuming that RFC 4474 is being implemented). 

If signalling is out of scope (e.g. SIP is handled in Javascript), then one cannot make 
the same claims about overall system security as one could with a SIP implementation. 
The same thing is true with respect to ICE, by the way -- once you remove signalling
from the scope, the security properties change (e.g. the browser doesn't get to examine
the SDP offer/answer exchange if signaling is done out-of-band).  

> If you combine that with the identity mechanisms
> end-to-end encryption.  

[BA] I would characterize the current draft as lacking in details, frankly.   Do we 
really think that this will be implemented in version 1.0?  If not, then what keying
mechanism do we use along with the "mandatory to use SRTP"?   From my
perspective, making SRTP "mandatory to use" is not very helpful unless we
are clear about how the keying is done.  We don't need to repeat the IPsec/IPv6
experience.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 4 Jan 2012 23:48:10 -0800

> not-allowed). If this is not done no RTP would be offered nor accepted.

[BA] We need to be a bit more clear about what we mean here.  Hadriel
has pointed out that RFC 5939 is rarely implemented.  Given that, we need
to be clear if we're talking about offering *both* RTP/SAVP(F) (preferred)
and RTP/SAVP, or just RTP/SAVP(F), with the ability to do another offer/answer
if that fails.  Obviously the implementation complexity, delays, etc. will differ
between these approaches.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Jan 2012 00:03:39 -0800

Justin said:

[BA] Having been involved in deployment of millions of SRTP endpoints, I wouldn't say SRTP is hard to deploy.  Virtually *all* the pain comes from key management. 

The same thing is true of IKE/IPsec by the way.  When people complain about IPsec, they almost always are talking about an IKE issue. 

Justin said:

"If you could provide text for the use

be very useful in moving this discussion forward."

[BA] It's not hard to come up with scenarios where SRTP might be fine, but DTLS/SRTP would be burdensome.

PSTN gateways are a good example of that.  Some support SRTP today, and almost all of these do SDES.  If we
insisted, we could probably get some vendors to support ICE too.  But asking for DTLS/SRTP (especially a variant
different from the one implemented in SIP) is highly unlikely. 

Justin said: 

"Until then, I think the Danvers Doctrine pretty plainly pushes us to

make SRTP mandatory to implement."

[BA] No objection to mandating implementation here.  SRTP is implemented in sub-$100 devices, so it's no big deal. 

The key question is whether is whether it is:  always on; default on; negotiated on.  I am not

of the resulting system, at least in the common case. 

[BA] I'm not sure how we can avoid the possibility of "negotiation" in signaling unless we adopt a pure media security approach (e.g. ZRTP). 
As long as it is possible to use offer/answer, you'll have the potential to "negotiate" SDES, DTLS/SRTP (SIP Flavor), etc. 

Justin said:

"To me, it increases the number of possible attacks and thus the code needed to mitigate them."

[BA] Are you saying that a DTLS/SRTP variant integrated with Oath or other identity schemes would require minimal code and would interoperate seamlessly???

Much more likely is that browser vendors would each support their own favorite identity service (as they've done with location) and we'd end up with a non-interoperable yet "standard" solution.  

No thanks.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 5 Jan 2012 06:56:46 -0500

On Wed, Jan 4, 2012 at 11:45 PM, Randell Jesup <[email-masked]>wrote:

> bid-down attacks (and they're important), but also the "threat model" for
> rtcweb is that we don't trust:
> a) the JS application
> to maintain security and privacy for our conversation.  The JS application
> may be malicious or may have been subverted without knowledge of the
> provider, or the provider may have been compromised (by an attacker or by
> legal force) even if they're not actively evil.
>
>
I agree that there are a lot of other threat models, but none of this is
addressed with a standard SRTP. If we design a different protocol (or key
management schema) and create an appropriate UI to give access to this we
can solve these problems. But, as most of us already know with HTTPS, users
will not care/know enough to use this new UI to actually verify anything,
so we will be dealing with the same set of security problems. So, from this
point of view I am not sure these problems can (and should be solved).
Also, keep in min that while adding identity to communication we should
still allow for anonymous calls.

> (modulo gateways).  If you combine that with the identity mechanisms from
> ekr's draft/presentation at Taipei, and you have verified, no MITM,
> end-to-end encryption.  (Without identity info, we have no way to detect a
> MITM attack, especially if brokered by the service provider.)
> provider/website have access to the keys.  (With some pain we might be able
> to encrypt the SDES keys themselves, but I'm not sure that's practical.)
>
> The "interop with legacy needs no SRTP or optional SRTP" argument fails if
> we have to go through a gateway to get to legacy equipment anyways. And
> though I've tried hard to find a practical way around it, the 'consent'
> requirements handled by using ICE/etc end up requiring us to use a gateway.
> If you're using a gateway to talk to legacy devices and/or PSTN gateways,
> you can include SRTP in the gateway for the webrtc side.
>
>
We are actually talking here about things that do not yet exist (like
end-to-end identity in SRTP) or never saw any real deployment (like
DTLS-SRTP). At this point we might as well design a new protocol. Let's
replace ICE while we are at it, and have a protocol that does key exchange,
media consent (including bandwidth and media type consent which is not part
of anything now) in one transaction. I know it is tempting to use layered
approach, but each layer we add slows down the connection time and
compromises interop and security. At least this way a WebRTC implementer
would not need to support 10 random parts of 50 different RFCs.

I agree with your point on legacy gateways. My main concern is a barrier to
entry in implementation of anything that communicates with WebRTC. The more
things needs to be implemented, working, and tested at the same time, the
harder it is to implement. With current approach, SRTP, ICE, RTP, and codec
support need to start working together. If we have an ability to turn off
SRTP, the other components are much easier to debug. If we provide no
access to key exchange, it would be almost impossible to identify bad
payload due to bad codec or media processing failure generated by a third
party component. I have to do interop with new implementations which
support encryption on the regular basis. Most of the communications from
third parties start with "can we turn the encryption off for debugging?" or
"can we turn the encryption off during development?".
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Jan 2012 07:19:31 -0800

On Jan 5, 2012, at 3:56, "Roman Shpount" <[email-masked]> 
> 
> At this point we might as well design a new protocol.

[BA] That seems like a precipitous conclusion, given that we haven't even come up with a set of requirements and evaluated existing protocols against them. On the other hand, the security draft contains "modified" versions of existing schemes (thrown in without WG consensus), so it's not like that is defensible either.

>  My main concern is a barrier to entry in implementation of anything that communicates with WebRTC. 

WebRTC will by nature have a high bar.  The question is if the bar is high that we still have interop issues 5+ years from now.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 5 Jan 2012 09:56:02 -0700

On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote:

> 
> This argument about debugging keeps coming up, and although I am not persuaded by this argument, it is not a completely unreasonable request. However, I don't think this needs to be controllable from JS. One could easily imagine a plain-RTP option being available from a developer options dialog or console, for use by developers in debugging specific problems with their service.

I think the best solution for the debugging issue is to allow SRTP to negotiate a NULL cipher in special cases such as Justin described above. This keeps what you are debugging as close as possible to the version when debugging is turned off. I like Justin's idea of having to enable this in the browser and not having it under JS control. 

Cullen (in my individual contributor role)

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Thu, 05 Jan 2012 11:07:17 -0600

> I think the best solution for the debugging issue is to allow SRTP to negotiate a NULL cipher in special cases such as Justin described above. This keeps what you are debugging as close as possible…

+1, unless I get more votes, in which case +all-of-my-votes

-- 
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: Alan Johnston <[email-masked]>
Date: Thu, 5 Jan 2012 11:08:14 -0600

> Cullen (in my individual contributor role)

This seems like the right way to do this.

- Alan -

---

From: Ted Hardie <[email-masked]>
Date: Thu, 5 Jan 2012 09:12:22 -0800

Hi Bernard,

The threading must have gotten mixed up here, because the responses
below are to me, not Justin.   Some further discussion in-line.

On Thu, Jan 5, 2012 at 12:03 AM, Bernard Aboba
<[email-masked]> wrote:
> [BA] Having been involved in deployment of millions of SRTP endpoints, I
> wouldn't say SRTP is hard to deploy.  Virtually *all* the pain comes from
> key management.
>
> The same thing is true of IKE/IPsec by the way.  When people complain about
> IPsec, they almost always are talking about an IKE issue.
>
>

Thanks for the clarification.  But if we accept the current threat
model (untrusted JS, where we wish to avoid revealing the SRTP keys to
the application), I'm not sure that there is any way to avoid this
pain.

> different from the one implemented in SIP) is highly unlikely.

I agree that increasing the number of variants will be a pain for
gateway operators.   If there is something currently is deployed and
meets the threat model, I am sure that there would be interest.  But
shifting to something that reveals the keys to an untrusted part of
the system seems to be the wrong approach for solving the problem, at
least to me personally.

> [BA] I'm not sure how we can avoid the possibility of "negotiation" in
> signaling unless we adopt a pure media security approach (e.g. ZRTP).
> As long as it is possible to use offer/answer, you'll have the potential to
> "negotiate" SDES, DTLS/SRTP (SIP Flavor), etc.
>

Well, we've agreed to offer/answer as the basic model, but I think
we're still discussing whether that means that includes negotiation of
SRTP vs. RTP.

> [BA] Are you saying that a DTLS/SRTP variant integrated with Oath or other
> identity schemes would require minimal code and would interoperate
> seamlessly???
>
Nope, I'm saying that supporting that *plus* a negotiation that allows
for vanilla RTP means we have to add other protections against bid
down attacks.  Those protections men more code.

Hope that clarifies things,

Ted

---

From: Randell Jesup <[email-masked]>
Date: Thu, 05 Jan 2012 12:28:57 -0500

On 1/5/2012 2:17 AM, Ravindran, Parthasarathi wrote:
> RTP mechanism shall be used in the trusted site&  network like intranet, Enterprise application. The need of RTP session is to reduce WebRTC-GW cost in performing SRTP-RTP.

"and user will know the implications "

Right.  ;-)

> I understand that it adds up complication in browser implementation as browser has to consider both SRTP&  RTP based on the configuration. It is more like pop-up is blocked in browser by default in the browser except for personal banking website based on user configuration.

And those sorts of things and exception-mechanisms are a real problem 
for most users, UI-wise.  Users don't generally understand the issues or 
what they're agreeing to, no matter how scary we make the warnings.    
It helps some, but often confuses as many users as it helps.  This is 
reinforced every time I play remote-IT-person over the phone with my 
stepmother.

As for SRTP costs:

The SRTP cost for the client is low enough not to be an issue 
(measurable, but within reason on any expected hardware).

The SRTP cost on a server hosting a large number of connections (and 
mostly just routing them) may be significant to a service provider -- 
for example, games where 'broadcast' announcements to large numbers of 
connected users have to be encrypted for each connection, or a 
hangout-like conference where streams are sent to a central location and 
resent to a large number of other members (especially in the 
without-mixing case).

In these cases, the server has to encode and/or decode a medium to large 
number of streams, but isn't doing heavy processing of the decoded 
media, so SRTP cost is a much larger factor.

Similar aspects apply to WebRTC gateways, at least run on commodity 
hardware - media data isn't being processed, just streams forwarded with 
decryption/encryption (and ICE, which should be in the noise).

So, an argument can be made (from a performance of the server/gateway 
point-of-view) that there's some justification for plain RTP, at least 
in a few use cases.  However, even in those there are often privacy 
issues - for example, in a Hangout-like app allowing video to be passed 
around without encryption is a privacy risk in general, and users aren't 
well set up to evaluate the risks (and even more importantly, the 
difference in risk in different situations).

So, even though there are cost optimizations to pure RTP for servers, 
they don't (to me) justify allowing plain RTP in webrtc in general.  The 
added risk to the user of snooping (which is hard to explain to the 
user) is significant; and what is the payoff?  Mostly it's slightly 
reduced gateway/server costs (since I don't think we can eliminate a 
webrtc->legacy gateway due to the consent requirement).   If we could 
eliminate that, then you'd also get a bonus of lower delay in interop 
(or much lower in some cases).  Since I don't see that happening, the 
benefits are relatively low and the risk to users (and possible UI 
confusion) is higher.

>>> <[email-masked]<mailto:[email-masked]>>  wrote:
>>>

-- 
Randell Jesup
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Jan 2012 10:02:05 -0800

Comments below.

On Jan 5, 2012, at 9:12, "Ted Hardie" <[email-masked]> wrote:

> the application), I'm not sure that there is any way to avoid this.
> 
> least to me.

[BA] It might help to articulate the trust model in more detail. I understand the JS and web server arguments but with things like SBCs the notion can get muddled, particularly if media termination is envisaged.  

> Hope that clarifies things,

[BA] Yes, it does.  Maybe it would help to separate parts of this discussion (SRTP vs. RTP, key mgmt, etc.).

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Jan 2012 10:30:14 -0800

Comments below.

> "and user will know the implications "

[BA] Yeah I'm not even sure that people on this list would grasp *all* the security implications based on UI no matter how descriptive it was.

> And those sorts of things and exception-mechanisms are a real problem for most users, UI-wise.  Users don't generally understand the issues or what they're agreeing to, no matter how scary we make the warnings.    It helps some, but often confuses as many users as it helps.  This is reinforced every time I play remote-IT-person over the phone with my stepmother.

[BA] Heh. WebRTC is more complex than today's security scenarios, and if it is necessary to understand device permissions, SRTP vs. RTP, authenticated versus non-authenticated key mgmt, MITM opportunities, etc.  how many of *us* would grasp it instantly?

> As for SRTP costs:
> 
> The SRTP cost for the client is low enough not to be an issue (measurable, but within reason on any expected hardware.

[BA] Agreed.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 5 Jan 2012 08:54:56 +0100

> I've often had to advise customers to turn SRTP off until an issue was resolved. 

Interoperability with SRTP has been an issue at several SIPits. But we do see a change,
we see huge improvements in the number of successful interoperability tests.

From the summary of the latest SIPit:

"** SRTP

All implementations supported SDES for SRTP key exchange.

Good interop with many different combinations of endpoints.

Some calls were left up for an extended period so that sequence number wrapping and roc increments were tested. Once the roc had changed the call was put on hold and resumed with success. In this situation new RTP streams with different SSRCs were created and the sequence number/roc combination re-generated thus proving that support for multiple SRTP contexts exists.

Debate surrounding how to signal 'best-effort crypto' continues. Some implementations choose to advertise RTP/AVP with a=crypto attributes and then go crypto if answer also has them and non-crypto if they do not. RTP/SAVP is used to signal the desire for mandatory crypto. Another approach observed was to repeat the same media line twice, once for crypto and once for non-crypto and rely on the receiving end to only accept one of them and port reject the other. In this case both m-lines had the same port number and payload number descriptions so if a receiving end accepted both then the originator would have no clue as to whether it was receiving crypto or non-crypto traffic."

https://www.sipit.net/SIPit29_summary

The first time I personally tested SRTP at SIpit we couldn't get any calls through across vendor boundaries...

We will have to bring Webrtc to SIPit for testing :-)

/O

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Jan 2012 12:59:45 -0800

Good summary of the current status and issues (e.g. ROC and signaling).  And yes, the situation is improving w/SDES, so I guess we'll have to pick something else in RTCWEB in order to keep it interesting :(

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 9 Jan 2012 14:47:07 +0000

Randell,

IIUC, the flexibility vs manageability of the browser is the point of the discussion. Providing SRTP and RTP provides the flexibility for some deployment but it is possible that novice user may be mislead by those configuration. ISTM, the question is whether advanced users should not be provided with the browser option as some of the user may get confused and leads to security issues. IMO, SRTP vs RTP has to be combination of user and website (JavaScript) choice rather than browser choice.  I would be interested in hearing more opinion from others before we decide "SRTP mandatory-to-use" in WebRTC.

Please read inline.

Thanks 
Partha

>Sent: Thursday, January 05, 2012 10:59 PM
>To: [email-masked]
>> I agree that SRTP has to be mandated-to-implement for the reasons
>which you have mentioned and also agree that SRTP fallback should not be
>accepted by default to avoid bid-down attack.
>>
>> The only possible solution for RTP media in WebRTC is to provide the
>user configuration in the browser (WebRTC client) to allow the trust
>website to create RTP media based session. In this model, (browser) user
>provides the consent to pass RTP media and user will know the
>implications. In case untrusted website asks for RTP session through
>JavaScript, those request will be declined. Hope it is inline with
>trusted model as user is responsible for RTP session and not JavaScript
>or web-server.
>>
>> RTP mechanism shall be used in the trusted site&  network like
>intranet, Enterprise application. The need of RTP session is to reduce
>WebRTC-GW cost in performing SRTP-RTP.
>
>> I understand that it adds up complication in browser implementation as
>browser has to consider both SRTP&  RTP based on the configuration. It
>is more like pop-up is blocked in browser by default in the browser
>except for personal banking website based on user configuration.
>
>
<partha> I'm with you that some of the user will not know the security implications while adding the site for allowing RTP when website instructs to add its site even though browser provides the security warning. "Ok" button will be clicked without any reading :-) My point is that it is possible to misguide those users by Dr.Evil website even though SRTP is used. Say, those users allow RTP plugin in the browser or the user will not check whether validity of webrtc identity.  </partha>

>(measurable, but within reason on any expected hardware).
<partha> Agreed </partha>

>connected users have to be encrypted for each connection, or a hangout-
>like conference where streams are sent to a central location and resent
>to a large number of other members (especially in the without-mixing
>case).
>
<partha> The argument here is that WebRTC allows only SRTP by default until otherwise users configures to allow RTP for the specific URL (website) and JavaScript API of the same website request for RTP. I agree with you that user or JavaScript *MUST NOT* use RTP for Hangout-like app. It does not mean that all WebRTC application MUST use SRTP. Some of the application based on the network deployment may use RTP. </partha>

>they don't (to me) justify allowing plain RTP in webrtc in general. 

<partha> It is debatable. Let us see others opinion here. </partha> 

 The
>> My point is that WebRTC client should be flexible for different
>deployment rather than considering every URL is untrusted.
>>
>> Thanks
>> Partha
>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Randell Jesup
>>>>      scheme, it is guaranteed to be negotiated.  Only if the
>preferred
>>>>      option is
>>>> application developer is required to allow RTP. By default, SRTP
>>>> only connection should be accepted with no option to bid down (ie
>>>> offer with
>>>> present in the offer or accepted in the answer (with crypto
>>>> attributes or some other way to specify that AVPS is also
>>>> supported). This way there no "accidental" RTP connections.
>>> knowledge of the provider, or the provider may have been compromised
>>> (by an attacker or by legal force) even if they're not actively evil.
>>>
>>> website never have access to the keys, and you have end-to-end
>>> security (modulo gateways).  If you combine that with the identity
>>> mechanisms
>>> end-to-end encryption.  (Without identity info, we have no way to
>>> detect a MITM attack, especially if brokered by the service
>>> provider.) Side
>>> provider/website have access to the keys.  (With some pain we might
>>> be able to encrypt the SDES keys themselves, but I'm not sure that's
>>> practical.)
>>>
>>> The "interop with legacy needs no SRTP or optional SRTP" argument
>>> fails if we have to go through a gateway to get to legacy equipment
>anyways.
>>> 'consent' requirements handled by using ICE/etc end up requiring us
>>> to use a gateway. If you're using a gateway to talk to legacy devices
>>> and/or PSTN gateways, you can include SRTP in the gateway for the
>>> webrtc side.
>>>
>>>
>>> --
>>> Randell Jesup
>>> [email-masked]

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 10 Jan 2012 15:24:28 -0600

On 1/5/2012 11:08 AM, Alan Johnston wrote:
> On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings<[email-masked]>  wrote:
>>

And to me.

So, just to ask the next question ... if we require the use of SRTP and 
allow NULL ciphers (for debugging and whatnot), are there any remaining 
problems with requiring the use of SRTP?

Thanks,

Spencer

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 11 Jan 2012 01:53:28 +0000

Hi all,

In case the proposal is to use browser configuration for debugging, it is also possible to allow the configuration for sending RTP with user consent for a specific URL (website) and debugging shall use the same infrastructure.  I have indicated in the another mail thread that 

1) SRTP session is the default in WebRTC (default API value & No configuration)
2) SRTP session is created if JavaScript (JS) API requested for RTP and no configuration in browser for a specific URL
3) SRTP session is created if configuration in browser allows for a URL but JS API does not.
4) RTP session is created if configuration in browser allows for a URL and JS API request for RTP session.

The above proposal is inline with current security trust model wherein webserver is not trusted and user consent is assured for RTP session. This configuration falls under the same category of configuration exception for plug-in, pop-up blocker, JavaScript execution, cookies. This proposal provides flexibility in some of the deployment wherein double encryption shall be avoided or security is assured by non-WebRTC mechanism. The more details are provided in http://www.ietf.org/mail-archive/web/rtcweb/current/msg03108.html.

The point to be noted is that security key management mechanism is not part of the proposal. Let us discuss it separately whether single key management is sufficient (SRTP-DTLS) or multiple key management like ZRTP, SRTP-SDES, SRTP-DTLS is required for WebRTC. 

Please let me know your opinion on this.

Thanks
Partha

>Of Spencer Dawkins
>Sent: Wednesday, January 11, 2012 2:54 AM
>To: Alan Johnston
>Cc: [email-masked]
>easily imagine a plain-RTP option being available from a developer
>options dialog or console, for use by developers in debugging specific
>problems with their service.
>>> I think the best solution for the debugging issue is to allow SRTP to
>negotiate a NULL cipher in special cases such as Justin described above.
>This keeps what you are debugging as close as possible to the version
>when debugging is turned off. I like Justin's idea of having to enable
>this in the browser and not having it under JS control.
>>>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 11 Jan 2012 12:52:15 +0530

Partha,

|it is also possible to allow the configuration for sending 
|RTP with user consent for a specific URL (website)

The problem with it is that the need to do SRTP not only depends on what
you are accessing but also how and from where you are accessing it. Even
if you are accessing a trusted website, you many still want to do SRTP
if you are accessing it from a public hotspot or Internet cafe.

I think it is a tradeoff b/w simplifying WebRTC user experience vs the
cost of connecting users to endpoints that don't do SRTP. My vote is for
the for former.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ravindran, Parthasarathi
|Sent: Wednesday, January 11, 2012 7:23 AM
|To: Spencer Dawkins; Alan Johnston; Bernard Aboba; Cullen Jennings
(fluffy)
|Cc: [email-masked]
|Subject: Re: [rtcweb] SRTP not mandatory-to-use
|
|Hi all,
|
|In case the proposal is to use browser configuration for debugging, it
is also possible to allow the
|configuration for sending RTP with user consent for a specific URL
(website) and debugging shall use
|the same infrastructure.  I have indicated in the another mail thread
that
|
|1) SRTP session is the default in WebRTC (default API value & No
configuration)
|2) SRTP session is created if JavaScript (JS) API requested for RTP and
no configuration in browser
|for a specific URL
|3) SRTP session is created if configuration in browser allows for a URL
but JS API does not.
|4) RTP session is created if configuration in browser allows for a URL
and JS API request for RTP
|session.
|
|The above proposal is inline with current security trust model wherein
webserver is not trusted and
|user consent is assured for RTP session. This configuration falls under
the same category of
|configuration exception for plug-in, pop-up blocker, JavaScript
execution, cookies. This proposal
|provides flexibility in some of the deployment wherein double
encryption shall be avoided or security
|is assured by non-WebRTC mechanism. The more details are provided in
http://www.ietf.org/mail-
|archive/web/rtcweb/current/msg03108.html.
|
|The point to be noted is that security key management mechanism is not
part of the proposal. Let us
|discuss it separately whether single key management is sufficient
(SRTP-DTLS) or multiple key
|management like ZRTP, SRTP-SDES, SRTP-DTLS is required for WebRTC.
|
|Please let me know your opinion on this.
|
|Thanks
|Partha
|
|>-----Original Message-----
|>From: [email-masked] [mailto:[email-masked]] On
Behalf
|>Of Spencer Dawkins
|>Sent: Wednesday, January 11, 2012 2:54 AM
|>To: Alan Johnston
|>Cc: [email-masked]
|>Subject: Re: [rtcweb] SRTP not mandatory-to-use
|>
|>On 1/5/2012 11:08 AM, Alan Johnston wrote:
|>> On Thu, Jan 5, 2012 at 10:56 AM, Cullen Jennings<[email-masked]>
|>wrote:
|>>>
|>>> On Jan 4, 2012, at 8:36 PM, Justin Uberti wrote:
|>>>
|>>>>
|>>>> This argument about debugging keeps coming up, and although I am
not
|>persuaded by this argument, it is not a completely unreasonable
request.
|>However, I don't think this needs to be controllable from JS. One
could
|>easily imagine a plain-RTP option being available from a developer
|>options dialog or console, for use by developers in debugging specific
|>problems with their service.
|>>>> _______________________________________________
|>>>
|>>> I think the best solution for the debugging issue is to allow SRTP
to
|>negotiate a NULL cipher in special cases such as Justin described
above.
|>This keeps what you are debugging as close as possible to the version
|>when debugging is turned off. I like Justin's idea of having to enable
|>this in the browser and not having it under JS control.
|>>>
|>>> Cullen (in my individual contributor role)
|>>
|>>
|>> This seems like the right way to do this.
|>>
|>> - Alan -
|>
|>And to me.
|>
|>So, just to ask the next question ... if we require the use of SRTP
and
|>allow NULL ciphers (for debugging and whatnot), are there any
remaining
|>problems with requiring the use of SRTP?
|>
|>Thanks,
|>
|>Spencer
|>_______________________________________________
|>rtcweb mailing list
|>[email-masked]
|>https://www.ietf.org/mailman/listinfo/rtcweb
|_______________________________________________
|rtcweb mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 11 Jan 2012 08:39:56 +0000

Hi Muthu,

I agree with you that it is not website trust but also network has to be considered. Please look at this requirement like accessing company intranet service (email, document) from public hotspot or Internet café. Your usecase wherein the deployment will consider security like VPN wherein the (webRTC) application has no need to perform the double encryption. In case accessing company (Enterprise) e-mail in a specific hotspot/public internet care is unsecure, then accessing company WebRTC application is also unsecure. If not, it is perfectly fine to access RTP WebRTC application as the security is ensured in some other layer of the network. 

>From WebRTC perspective, the standard should not mandate to use as WebRTC is one of the application in the system.

Thanks
Partha

>From: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
>Sent: Wednesday, January 11, 2012 12:52 PM
>To: Ravindran, Parthasarathi; Spencer Dawkins; Alan Johnston; Bernard
>Aboba; Cullen Jennings (fluffy)
>Cc: [email-masked]
>Subject: RE: [rtcweb] SRTP not mandatory-to-use
>
>Partha,
>
>|it is also possible to allow the configuration for sending RTP with
>|user consent for a specific URL (website)
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 11 Jan 2012 09:54:01 +0100

> I agree with you that it is not website trust but also network has to be considered. Please look at this requirement like accessing company intranet service (email, document) from public hotspot or…

It seems that there is no evolution at all in this issue, same
arguments as two months ago.

AFAIR the main question/problem is: who does decide when to use SRTP
or just plain RTP? does such a suggestion come from the web page
itself? If so, the user (the human user) can be deceived:

  "Press the 'Accept unsecure communication' button and you will win a car !!!"

The double encryption is not a problem at all. The application (the
browser) performs SRTP encryption (no problem here!) and the TCP/IP
stack in the computer or in the router performs network encryption.
Which is the problem??? There is no problem at all. All of this just
seems a poor argument in favour of plain RTP to interoperate with
legacy and non secure RTP implementations (and this is the fail of
lazy SIP vendors, don't bring that to WebRTC please).

Regards.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 11 Jan 2012 10:56:45 +0000

Hi Inaki,

My proposal is not to trust the website but the user decides based 
on browser configuration. Please see the different combination in
the earlier mail wherein there is no compromise on the security 
trust model.

Human user who "Press the 'Accept unsecure communication' button 
and you will win a car !!!" will allow RTP plug-in to install or 
configure browser to win the car. It is as good as sending the 
air ticket money to unknown country king based on spam mail in 
secured (https) e-mail access user for getting lump sum money 
from King (spammer). 

Also, please note that SRTP-DTLS does not prevent WebRTC server
from accessing the secured WebRTC media (data) but helps user to 
identify that the media is not end-to-end. My statement is based 
on my understanding of WebRTC security architecture

Partha(Browser +  JS) ----------WebRTCserver-----Browser+ JS (Inaki)
      |                                                          |
       ----(SRTP+DTLS)-----WebRTC Media server---(SRTP+DTLS) ----- 

In the above topology, webserver owns WebRTC media server as well. 
Web media server terminates & originates the media. The identity is 
the differentiating factor. For example, if I see the browser window
with identity [email-masked] instead of [email-masked], then I have to 
understand that browser is not end-to-end because of identity.

My current argument has nothing to do with PSTN interop. AFAIK, 
SRTP-DTLS standardization in WebRTC is good for SBC :-). 

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]]
>Sent: Wednesday, January 11, 2012 2:24 PM
>To: Ravindran, Parthasarathi
>Cc: Muthu Arul Mozhi Perumal (mperumal); Spencer Dawkins; Alan Johnston;
>Bernard Aboba; Cullen Jennings (fluffy); [email-masked]
>> I agree with you that it is not website trust but also network has to
>be considered. Please look at this requirement like accessing company
>intranet service (email, document) from public hotspot or Internet café.
>Your usecase wherein the deployment will consider security like VPN
>wherein the (webRTC) application has no need to perform the double
>encryption. In case accessing company (Enterprise) e-mail in a specific
>hotspot/public internet care is unsecure, then accessing company WebRTC
>application is also unsecure. If not, it is perfectly fine to access RTP
>WebRTC application as the security is ensured in some other layer of the
>network.
>
>
>It seems that there is no evolution at all in this issue, same arguments
>as two months ago.
>
>AFAIR the main question/problem is: who does decide when to use SRTP or
>just plain RTP? does such a suggestion come from the web page itself? If
>so, the user (the human user) can be deceived:
>
>seems a poor argument in favour of plain RTP to interoperate with legacy
>and non secure RTP implementations (and this is the fail of lazy SIP
>vendors, don't bring that to WebRTC please).
>
>
>Regards.
>
>--
>Iñaki Baz Castillo
><[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 11 Jan 2012 12:07:54 +0100

> secured (https) e-mail access user for getting lump sum money

Right. My question is: why to allow that? wasn't a primary aim of
WebRTC to avoid such a risk?

> understand that browser is not end-to-end because of identity.

Well, I expect that the typicall picture will not include the "WebRTC
Media Server" (it could however).

> SRTP-DTLS standardization in WebRTC is good for SBC :-).

Ok, but I'm not talking about that. I'm just wondering why the human
user should be able to "trust" a website asking permission for
untrusted/insecure plain RTP. This is not about having a media server
or not.

Example: I'm in an airport with open WiFi. If I establish a plain RTP
communication anyone in that network can inspect it. Why to allow
that?

I repeat my main argument against allowing plain RTP:

The double encryption is not a problem at all. The application (the
browser) performs SRTP encryption (no problem here!) and the TCP/IP
stack in the computer or in the router performs network encryption.
Which is the problem??? There is no problem at all.

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 11 Jan 2012 13:40:04 +0000

Hi Inaki,

I think that we are in the same page of not using plain RTP in
airport with WiFi. It is the main reason for asking SRTP as a 
default media protocol. Also, the public internet application like
Google hangout should be based on SRTP. So, Most of the WebRTC
application will based on SRTP but some of the WebRTC application
prefers to RTP (intranet site) which MUST NOT be restricted by 
IETF standard.

The double encryption avoidance is the matter of optimization in 
network design as double encryption in endpoint calls for double 
decryption in the network for some of the services. I agree that 
it may not be problem in some of the network because of
the network resource availability or network entity is not involved 
(browser-browser scenario) but we can't generalize this. In case it is 
possible, Double encryption has to be avoided and IETF has to 
recommend accordingly. 

Please read inline for more comments.

Thanks
Partha

>Sent: Wednesday, January 11, 2012 4:38 PM
>> Human user who "Press the 'Accept unsecure communication' button and
>> you will win a car !!!" will allow RTP plug-in to install or configure
>> browser to win the car. It is as good as sending the air ticket money
>> to unknown country king based on spam mail in secured (https) e-mail
>> access user for getting lump sum money from King (spammer).
>
>Right. My question is: why to allow that? wasn't a primary aim of WebRTC
>to avoid such a risk?
>
<partha> I guess that my point does not come out well. I'm saying that
user who accept unsecure communication for a car will allow RTP plug-in
to be added in the browser wherein security will be compromised anyway
and not related to WebRTC. </partha>

>
>> Also, please note that SRTP-DTLS does not prevent WebRTC server from
>> accessing the secured WebRTC media (data) but helps user to identify
>> that the media is not end-to-end. My statement is based on my
>> understanding of WebRTC security architecture
>>
>untrusted/insecure plain RTP. This is not about having a media server or
>not.
>
>communication anyone in that network can inspect it. Why to allow that?

<partha> Agreed. Public internet WebRTC application has to be based on
SRTP </partha>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 11 Jan 2012 14:52:15 -0500

To reply to the OP: The consensus that I see having emerged from this
discussion is that SRTP should be mandatory to use, with a provision for
NULL ciphers for debugging. This provision is only exposed through
developer settings, and can never be invoked from the web app; for all
practical purposes, applications will have to use SRTP

As for the key management mechanism, SDES and DTLS will be supported; while
DTLS is preferred, there are few DTLS-SRTP implementations in existence at
this time.

As far as I know, this is what the major WebRTC implementations are
planning to do.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jan 2012 12:00:30 -0800

Some questions:

What keying mechanism(s) MUST be implemented?  SDES?  DTLS/SRTP?  both?

Is the implication that both SDES and DTLS/SRTP MUST be offered? 

Is the preference for DTLS/SRTP implied, or explicit (RFC 5939)? 

As for the NULL cipher, the discussion so far has been in the context of DTLS/SRTP.  If DTLS/SRTP is not chosen (e.g. SDES is negotiated in offer/answer), then what?

From: [email-masked]
Date: Wed, 11 Jan 2012 14:52:15 -0500
To: [email-masked]
CC: [email-masked]
Subject: Re: [rtcweb] SRTP not mandatory-to-use

To reply to the OP: The consensus that I see having emerged from this discussion is that SRTP should be mandatory to use, with a provision for NULL ciphers for debugging. This provision is only exposed through developer settings, and can never be invoked from the web app; for all practical purposes, applications will have to use SRTP

As for the key management mechanism, SDES and DTLS will be supported; while DTLS is preferred, there are few DTLS-SRTP implementations in existence at this time.
As far as I know, this is what the major WebRTC implementations are planning to do.

an/listinfo/rtcweb

---

From: Randell Jesup <[email-masked]>
Date: Wed, 11 Jan 2012 16:20:11 -0500

On 1/11/2012 2:52 PM, Justin Uberti wrote:
> As for the key management mechanism, SDES and DTLS will be supported;
> while DTLS is preferred, there are few DTLS-SRTP implementations in
> existence at this time.

I'd like to explore the possibility of making sure there's a workable 
DTLS-SRTP implementation openly available, and locking WebRTC down to 
that only.

I should note that while libsrtp 1.4.2 (last official release) doesn't 
have DTLS-SRTP support, there are DTLS-SRTP support functions and test 
code in the project's CVS since ~2006, and resiprocate/recon supports 
DTLS-SRTP via a modified OpenSSL.  So, I'm not sure the barrier is huge 
given DTLS support already.

The reason (as I've mentioned at times) is that SDES means we expose the 
media to the JS app and to the website, neither of which we've agreed to 
trust.  All the discussion of blocking access to decrypted media from 
the JS app is moot if it has the keys.

If we use SDES, we're effectively trusting the JS app (and website) to a 
very large extent.  (Not to turn on the camera/mic, but with the 
contents of all conversations.)  It also means bid-down to SDES is 
trivial.  I'm not sure what this would mean to identity validation via 
BrowserID or others (ekr?); that might survive this, but it means media 
could be decrypted in realtime or later if anyone has copies of the 
packets and can get the key from the app/website.

-- 
Randell Jesup
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jan 2012 13:41:46 -0800

On Wed, Jan 11, 2012 at 1:20 PM, Randell Jesup <[email-masked]> wrote:
> DTLS-SRTP implementation openly available, and locking WebRTC down to that
> only.
>
> I should note that while libsrtp 1.4.2 (last official release) doesn't have
> DTLS-SRTP support, there are DTLS-SRTP support functions and test code in
> the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via
> a modified OpenSSL.  So, I'm not sure the barrier is huge given DTLS support
> already.

The situation is actually rather better than this:

1. OpenSSL 1.0.1 (currently in beta) has all the TLS-side support needed for
    DTLS-SRTP.
2. The new entry points in libsrtp, while helpful are just helper
    functions. If you're willing to embed a bit of knowledge about key
construction
    into the application, you should be able to use libsrtp 1.4.2.
(though I suspect
    you actually don't want to. libjingle, for instance, recommends use of the
    libsrtp CVS version).
3. As you say, resip and recon have support for DTLS-SRTP, though you
likely won't
    need it for WebRTC anyway, since that support is largely SIP-specific.

So in terms of having a working implementation, the issue is primarily
integration
into your WebRTC stack

> trust.  All the discussion of blocking access to decrypted media from the JS
> app is moot if it has the keys.

I agree that this is a real concern.

> very large extent.  (Not to turn on the camera/mic, but with the contents of
> all conversations.)  It also means bid-down to SDES is trivial.  I'm not
> sure what this would mean to identity validation via BrowserID or others
> (ekr?); that might survive this, but it means media could be decrypted in
> realtime or later if anyone has copies of the packets and can get the key
> from the app/website.

I believe that a properly constructed identity scheme a la the one I outlined
in my draft (advertisement: I've been working on a prototype, so more details
coming soon) will resist bid-down attacks, but I don't really see any merit
for doing anything other than browser-browser key establishment for
WebRTC.

FWIW, my take on the broader question is that the key issue is how we wish
to interop with legacy SIP/PSTN-type stuff. If we want it to be possible to
interop without media gatewaying, then the large amount of non-SRTP gear
means that as a practical matter one must support RTP. SDES is almost
an afterthought in this scenario, in that it would allow you to interop with
SRTP with some unknown but probably relatively small fraction of the
installed base.

If you don't care about interop without media gatewaying, then there is no
reason to do anything other than SRTP and I would argue no need to do
anything other than DTLS, because there's no backward-compatibility
issue.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jan 2012 13:46:25 -0800

> packets and can get the key from the app/website.

[BA] While I agree with your assessment of the security implications of not
supporting end-to-end key management, I'm concerned about the practicality
of mandating use of an RTCWEB DTLS/SRTP variant in RTCWEB v1.0. 
The SIPIt reports note progress on SDES implementation, but DTLS/SRTP
not so much, and integrating DTLS/SRTP within RTCWEB would require more
work beyond what is available in SIP DTLS/SRTP implementations today. 
As a result, I am more inclined toward Justin's proposal for RTCWEB v1.0
(assuming that the questions are answered). 

My view is that Justin's approach will maximize the potential for initial
RTCWEB implementations to interoperate, whereas a mandate for DTLS/SRTP
with no SDES support is very likely to result in initial interoperability problems
which could fester for a long time.  IMHO, an interoperable RTCWEB v1.0
should be our highest priority, even if it doesn't have all the features we
would want for v2.0 and beyond.  This also goes for some of the more
advanced features described in the RTP draft, by the way.  Perfect is
the enemy of the good. 

>From the description in the Security draft, it is not clear to me whether the
RTCWEB DTLS/SRTP proposal will necessarily interoperate with SIP 
implementations of DTLS/SRTP.   While the proposals have elements
in common (e.g. DTLS/SRTP itself, fingerprinting, etc.) SIP DTLS/SRTP
implementations cannot be expected to implement BrowserId, and 
RTCWEB DTLS/SRTP implementations may not support RFC 4474.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jan 2012 13:56:41 -0800

> SRTP with some unknown but probably relatively small fraction of the

[BA] Quite a few PSTN gateways support SRTP/SDES, including very inexpensive ones (e.g. $<100). 
As was mentioned, there has been considerable movement on SRTP/SDES implementation recently as the SIPIt reports show. 
So I don't think that a desire to support legacy interop necessarily implies a requirement for RTP support.

I would say that DTLS/SRTP support is an issue though.  Prospects for support of SIP DTLS/SRTP within PSTN gateways
are not good, let alone an RTCWEB variant.  

> anything other than DTLS, because there's no backward-compatibility

[BA] As noted above, I don't think that legacy interop implies support for RTP other than for debugging. 
However, I would agree that legacy interop does imply the need to implement (and offer) SDES, albeit
perhaps as a fallback (e.g. if DTLS/SRTP is supported, this will always be negotiated).

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jan 2012 14:04:45 -0800

On Wed, Jan 11, 2012 at 1:56 PM, Bernard Aboba
<[email-masked]> wrote:
> As was mentioned, there has been considerable movement on SRTP/SDES
> implementation recently as the SIPIt reports show.
> I would say that DTLS/SRTP support is an issue though.  Prospects for
> support of SIP DTLS/SRTP within PSTN gateways

OK. I'm not sufficiently informed on the level of support for SDES in
the gateway
environment. If it's that popular, then great; we can replace "RTP" in my
statement above with SRTP/SDES.

Best,
-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Jan 2012 17:50:13 -0500

On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup <[email-masked]>wrote:

> have DTLS-SRTP support, there are DTLS-SRTP support functions and test code
> in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP
> via a modified OpenSSL.  So, I'm not sure the barrier is huge given DTLS
> support already.
>
>
Can you name a single soft-phone, hard-phone, SBC, or gateway that
currently supports DTLS-SRTP?

The reason I am asking is libsrtp, despite being widely used, is extremely
buggy (last official release for instance crashes with GPF), and does not
even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody
provide an indication on how widely they are used? I know that OpenSSL
supported DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be
interesting to hear from SBC implementers before decision is made.

How many additional round trips does DTLS require for connection setup? Are
we planning to support certificate validation?
_____________
Roman Shpount

---

From: Randell Jesup <[email-masked]>
Date: Wed, 11 Jan 2012 17:51:09 -0500

On 1/11/2012 4:41 PM, Eric Rescorla wrote:
> On Wed, Jan 11, 2012 at 1:20 PM, Randell Jesup<[email-masked]>  wrote:
> integration into your WebRTC stack

Great, all this sounds good.

> anything other than DTLS, because there's no backward-compatibility

I agree, and since I believe the answer is "no interop without a media 
gateway" (I've tried to figure a safe way, no luck unless you relax the 
requirements for consent and the like), then I come down on 
SRTP-mandatory, DTLS-SRTP strongly preferred to be mandatory unless 
there's an implementation roadblock.

-- 
Randell Jesup
[email-masked]

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Jan 2012 18:03:28 -0500

On Thu, Jan 5, 2012 at 10:19 AM, Bernard Aboba <[email-masked]>wrote:

>
> [BA] That seems like a precipitous conclusion, given that we haven't even
> come up with a set of requirements and evaluated existing protocols against
> them. On the other hand, the security draft contains "modified" versions of
> existing schemes (thrown in without WG consensus), so it's not like that is
> defensible either.
>
>
This is my point exactly. We mandate the use of certain protocols
(DTLS-SRTP) without listing the application requirements. DTLS will come
with a lot of code baggage and additional round-trip during code setup. It
will not provide end-to-end security or identity validation (at least
without something else added into a mix).
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Jan 2012 15:07:54 -0800

Romain said:

"Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP? "

[BA] Yes, I can name a single implementation shipping in commercial products :)  However, for ZRTP, I believe there are multiple (independent?) implementations.  

Romain also said:

"The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used software is using this?"

[BA] DTLS is not supported within Windows 7 or Windows Phone 7.5.  Overall, I would say that DTLS is not widely used at the moment, though I do think it's fair to say that interest is increasing. 

Finally, Romain said:

"Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made.

How many additional round trips does DTLS require for connection setup? Are we planning to support certificate validation?"

[BA] By "certificate validation" do you mean PKI support?  Or are we talking about something along the lines of what is in SIP DTLS/SRTP or the RTCWEB security draft Appendix (e.g. support for self-signed certs and fingerprint validation)?

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Jan 2012 18:10:08 -0500

On Wed, Jan 11, 2012 at 6:07 PM, Bernard Aboba <[email-masked]>wrote:

> [BA] By "certificate validation" do you mean PKI support?  Or are we
> talking about something along the lines of what is in SIP DTLS/SRTP or the
> RTCWEB security draft Appendix (e.g. support for self-signed certs and
> fingerprint validation)?
>

Yes, what I am talking about is any type of remote identity validation
and/or remote fingerprint validation.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Wed, 11 Jan 2012 18:14:04 -0500

> advanced features described in the RTP draft, by the way.  Perfect is

This is exactly my thinking. We are working very hard at getting DTLS/SRTP
up and running, but I am all too familiar with betting the farm on
something that is all-new.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 11 Jan 2012 18:17:52 -0500

On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount <[email-masked]> wrote:

> How many additional round trips does DTLS require for connection setup?
> Are we planning to support certificate validation?
>

When used with JSEP, DTLS should not require any additional roundtrips for
connection setup, since DTLS can be brought up as part of transport
establishment. In fact, connection setup should occur faster than when
using SDES, since the keys can be negotiated before the answer arrives.
This prevents clipping of the answerer's media from occurring.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Jan 2012 18:20:43 -0500

> practical purposes, applications will have to use SRTP
I would still argue (even though I am obviously a minority here), that
plain RTP should be supported and this support should be accessible via JS
API with no web server configuration changes. The reasons are (apart from
debugging that will be addressed by NULL cypher), are overall symmetry with
HTTP vs HTTPS. As I have mentioned before, there are environments where
completely unsecured communication applications should be delivered, such
as some countries, army, prisons and such. I understand that you want to
disregard these people but they are internet users as well. Please keep in
mind that I am not arguing for a back-door to intercept secure
communications (against IETF policy) or to provide a way for secure
communication to fall back to unsecured. All I am looking for is an ability
to provide unsecured service if I, as a service provider, decide to do so.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Wed, 11 Jan 2012 18:22:33 -0500

> This prevents clipping of the answerer's media from occurring.

Should we provide some sort of best practice document on DTLS-SRTP
implementation? Should we mandate a minimal set of DTLS features that
should be supported to enable WebRTC interop?
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Jan 2012 15:25:14 -0800

On Wed, Jan 11, 2012 at 3:22 PM, Roman Shpount <[email-masked]> wrote:
>> establishment. In fact, connection setup should occur faster than when using
>> SDES, since the keys can be negotiated before the answer arrives. This
>> prevents clipping of the answerer's media from occurring.
>
>
> implementation? Should we mandate a minimal set of DTLS features that should
> be supported to enable WebRTC interop?

The requirements in RFC 5246 (DTLS inherits these) and 3711 should be
sufficient to ensure interop. If they're not, I don't see a problem with adding
some more.

-Ekr

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 12 Jan 2012 00:10:18 +0000

Justin & all,

As per my offline discussion in IETF-82, lot of folks has trouble in following rtcweb alias because of the massive e-mail per day. I wish the consensus of “SRTP is mandatory to use or mandatory to implement” has to be postponed at least for interim RTCWeb face-to-face meeting on 1st Feb.

I see lot of e-mail chain about key management in the alias. I’ll reply in one of them for key management.

Thanks
Partha

From: Justin Uberti [mailto:[email-masked]]
Sent: Thursday, January 12, 2012 1:22 AM
To: Ravindran, Parthasarathi
Cc: Iñaki Baz Castillo; [email-masked]
Subject: Re: [rtcweb] SRTP not mandatory-to-use

As far as I know, this is what the major WebRTC implementations are planning to do.
On Wed, Jan 11, 2012 at 8:40 AM, Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Inaki,

Thanks
Partha

>From: Iñaki Baz Castillo [mailto:[email-masked]<mailto:[email-masked]>]
>Bernard Aboba; Cullen Jennings (fluffy); [email-masked]<mailto:[email-masked]>
>2012/1/11 Ravindran, Parthasarathi <[email-masked]<mailto:[email-masked]>>:

>> with identity [email-masked]<mailto:[email-masked]> instead of [email-masked]<mailto:[email-masked]>, then I have to

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

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 12 Jan 2012 01:05:54 +0000

Hi Justin,

Sorry,  I have trouble in accessing JSEP draft at IETF RTCWeb site (http://tools.ietf.org/wg/rtcweb/) and googling does not yield any draft. Could you please forward me JSEP draft to see how DTLS keys are negotiated in JSEP proposal even  before the answer is received from the remote WebRTC client.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, January 12, 2012 4:48 AM
To: Roman Shpount
Cc: Randell Jesup; [email-masked]
Subject: Re: [rtcweb] SRTP not mandatory-to-use

On Wed, Jan 11, 2012 at 5:50 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Jan 11, 2012 at 4:20 PM, Randell Jesup <[email-masked]<mailto:[email-masked]>> wrote:

I'd like to explore the possibility of making sure there's a workable DTLS-SRTP implementation openly available, and locking WebRTC down to that only.

I should note that while libsrtp 1.4.2 (last official release) doesn't have DTLS-SRTP support, there are DTLS-SRTP support functions and test code in the project's CVS since ~2006, and resiprocate/recon supports DTLS-SRTP via a modified OpenSSL.  So, I'm not sure the barrier is huge given DTLS support already.

Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP?

The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8_128_HMAC_SHA1_8 support).

As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used software is using this?

Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made.

How many additional round trips does DTLS require for connection setup? Are we planning to support certificate validation?

When used with JSEP, DTLS should not require any additional roundtrips for connection setup, since DTLS can be brought up as part of transport establishment. In fact, connection setup should occur faster than when using SDES, since the keys can be negotiated before the answer arrives. This prevents clipping of the answerer's media from occurring.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 11 Jan 2012 20:49:33 -0700

Inline answer with my Cisco hat on .... I've mostly given up mention this because I sent it to RAI lists too many times before but ...

> Can you name a single soft-phone, hard-phone, SBC, or gateway that currently supports DTLS-SRTP? 

Yes, Yes, Yes, and Yes respectively. For example, pretty much all the Cisco high end tele presence stuff with includes endpoints, conference bridges, protocol conversion devices etc supports it. The bulk of the platforms that are newer than 5 years old from Cisco support DTLS-SRTP. It interoperates with other vendors. We don't go to SIPIT because with this sort of stuff as it does not seem to be the best way to test it. We find that many of the vendors to test with at SIPIT are just getting going and are still trying to get their spiral loops to work. Don't get me wrong - I love SIPIT and strongly support it, but it's not the place to test everything. I've been told a lot of IMS systems can do MiKEY  though I don't recall seeing a test of that at SIPIT. Different folks, different places. 

> The reason I am asking is libsrtp, despite being widely used, is extremely buggy (last official release for instance crashes with GPF), and does not even provide full DES-SRTP implementation (no F8…

I have no idea how much our internal version have diverged from the version you are using but the libSRTP is being used for a huge number of calls by enterprises, movements, and military systems. There's not a lot of bugs reported. I'm certainly not claiming there are bugs in any given piece of software but you can look at release notes of cisco products and see this is pretty stable. I realize this does not help much but DTLS-SRTP is not real complicated if you already have a good TLS stack and crypto engine - regardless of the quality of any given implementation, it should not be hard to make a good one. 

> As far as DTLS (non-SRTP) implementations are concerned, can anybody provide an indication on how widely they are used? I know that OpenSSL supported DTLS for a while, but what commonly used softwa…

I note most the good deployed SSL VPN in the world are DTLS . Check out the market share of SSL VPN to traditional IPSec. DTLS is widely used. Heck, at the next IETF, just check out the amount of DTLS traffic coming from IETF participants. 

> Also, what would be the impact of adding DTLS to SBC? It would be interesting to hear from SBC implementers before decision is made.

I've been on the design and implementation team for multiple SBCs - I was even a co-founder of an SBC company. But it's really easy to figure out - you don't need to know much about SBC - it more or less the same as it would be for any UA.  

Lets say you have nice SBC that will do 10,000 concurrent sessions. These are not cheap. If you are doing RTP on one side and DTLS-SRTP on the other side of each call. Lets just use a pessimistic estimate of average call duration of 3 minutes. So this device is doing 10000 / 3 / 60 = 55 session setups per second. The expensive part of this is the RSA private key operation. A single core on the crappy computer I am sending this email from does about 850 rsa1024 private key operations on a single core. Try out your machine with "openssl speed rsa1024". It roughly equivalent to two private key ops - So a big SBC needs 110 per second under pessimistic assumption and a small CPU can do 850. As you can imagine, an SBC like that is using some pretty beefy processors - they impact of the DTLS is often hard to measure it is so little. The amount of processing you need to process the all the SIP for a single call greatly exceeds the amount of processing to set up the DTLS connection. DTLS also requires much less per connection state than SIP although SBC are typically more constrained by CPU than memory. 

> How many additional round trips does DTLS require for connection setup?

A drop in the bucket compared to ICE :-) It depends on how you assume the ICE ends up going and if you do early media or not. There are many ways to overlap lots of this processing to minimize impact so it a slightly hard question to answer but if you draw some call flows with ICE, you will probably agree with my sort of flip "drop in the bucket" answer. 

> Are we planning to support certificate validation?

Uh, don't think I am following you here - it's just a dummy X.509 record to carry the public keys. There's no CA to validate it at. 

Thought I sound like I might be arguing for DTLS-SRTP to be the only thing - I'm not sure what I think. I want to see what the whole security systems looks like. If the weakest link is weak, well no point in making other links super strong.  Clearly the UI needs the ability of indicating in a secure way if the call is secure or not and the identity of who is at the other end of secure part. I can imagine Browser to Browser perhaps always being secure, I agree secure should be preferred to insecure where both are possible, but have a hard time imagining that we won't wish we had RTP for Browser to Legacy. 

Part of me believes that not having the option of using RTP in fallback legacy cases would be about equally insane to not supporting IPv4 and only doing v6. Sorry for all the nots.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jan 2012 10:15:38 +0100

Just forking the thread because real information may be good to have....

what's the status of libsrtp maintenance at the moment? Who does it, and 
is it adequately provisioned?

It seems like a key component of so many implementations, so it would be 
good for the community if it's properly looked after.

                  Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 12 Jan 2012 10:19:18 +0100

On 01/12/2012 02:05 AM, Ravindran, Parthasarathi wrote:
>
> Hi Justin,
>
> Sorry,  I have trouble in accessing JSEP draft at IETF RTCWeb site 
> (http://tools.ietf.org/wg/rtcweb/) and googling does not yield any 
> draft. Could you please forward me JSEP draft to see how DTLS keys are 
> negotiated in JSEP proposal even  before the answer is received from 
> the remote WebRTC client.
>

A copy of the JSEP proposal is archived in the W3C WebRTC archives:

http://lists.w3.org/Archives/Public/public-webrtc/2012Jan/0002.html

It has not yet been submitted as an internet-draft; indeed, one of the 
things we have to decide is whether it should be an internet-draft or a 
part of the W3C API spec.
>
> Thanks
>
> Partha
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Justin Uberti
> *Sent:* Thursday, January 12, 2012 4:48 AM
> *To:* Roman Shpount
> *Cc:* Randell Jesup; [email-masked]
> *Subject:* Re: [rtcweb] SRTP not mandatory-to-use
>
>     I'd like to explore the possibility of making sure there's a
>     workable DTLS-SRTP implementation openly available, and locking
>     WebRTC down to that only.
>
>     I should note that while libsrtp 1.4.2 (last official release)
>     doesn't have DTLS-SRTP support, there are DTLS-SRTP support
>     functions and test code in the project's CVS since ~2006, and
>     resiprocate/recon supports DTLS-SRTP via a modified OpenSSL.  So,
>     I'm not sure the barrier is huge given DTLS support already.
>
>
> The reason I am asking is libsrtp, despite being widely used, is 
> extremely buggy (last official release for instance crashes with GPF), 
> and does not even provide full DES-SRTP implementation (no 
> F8_128_HMAC_SHA1_8 support).
>
> How many additional round trips does DTLS require for connection 
> setup? Are we planning to support certificate validation?
>
> When used with JSEP, DTLS should not require any additional roundtrips 
> for connection setup, since DTLS can be brought up as part of 
> transport establishment. In fact, connection setup should occur faster 
> than when using SDES, since the keys can be negotiated before the 
> answer arrives. This prevents clipping of the answerer's media from 
> occurring.
>
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 12 Jan 2012 11:05:59 +0100

> (assuming that the questions are answered). 

When asking implementers at SIPit I have gotten a lot of people pointing to not ready implementations in GnutTLS and OpenSSL (still in beta). Talking with an OpenSSL developer a few days ago, I was clearly informed that OpenSSL DTLS support is ready for implementation, no reason to wait.

Another reason I heard mostly from hardware device vendors was that the chips vendors lack support of DTLS.

I think it's mostly a question of lack of customer demand. If people realize that the encryption keys are more or less distributed without control with SDES, this will not be accepted. A secure IP-telephony project in germany went for ZRTP because they could not accept SDES and hardware phone vendors did not want to fix DTLS even if they was offered orders of a quantity of phones...

With all the implementations listed in this thread I think we can have successful tests of DTLS-srtp at the next SIPit event. Remember that we had very few participants at SIPit in Monaco, so using that report as statistical evidence is propably not a good thing.

/O

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 12 Jan 2012 10:11:03 +0000

Hi Harald,

Thanks for the link.  From JSEP proposal section, I understand that Jingle has different signaling mechanism than SIP and the exact text is as follows:

“In protocols that decouple session descriptions from transport, such as Jingle, the transport information can be sent separately; in protocols that don't, such as SIP, the information can be easily aggregated and recombined. Sending transport information separately can allow for faster ICE and DTLS startup, since the necessary roundtrips can occur while waiting for the remote side to accept the session.”

I’ll go through this mechanism in detail and provide further comments.

Thanks
Partha

From: Harald Alvestrand [mailto:[email-masked]]
Sent: Thursday, January 12, 2012 2:49 PM
To: Ravindran, Parthasarathi
Cc: Justin Uberti; [email-masked]
Subject: Re: [rtcweb] JSEP draft query [was RE: SRTP not mandatory-to-use]

It has not yet been submitted as an internet-draft; indeed, one of the things we have to decide is whether it should be an internet-draft or a part of the W3C API spec.

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Thursday, January 12, 2012 4:48 AM
To: Roman Shpount
Cc: Randell Jesup; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] SRTP not mandatory-to-use

rtcweb mailing list

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 12 Jan 2012 11:03:53 +0000

Cullen,

Nice to see the last few statements from legacy perspective.

<snip> Clearly the UI needs the ability of indicating in a secure way if the call is secure or not and the identity of who is at the other end of secure part. I can imagine Browser to Browser perhaps always being secure, I agree secure should be preferred to insecure where both are possible, but have a hard time imagining that we won't wish we had RTP for Browser to Legacy. 

</snip>

I look for configuration in browser for RTP traffic to get the user consent while sending/receiving the media.  

Apart from this, SRTP-DTLS is the only proposed standard RFC in IETF for current WebRTC security trust model. SRTP-SDES breaks the model by trusting JS app and ZRTP is the informational draft. I agree with you that implementing  SRTP-DTLS in middle box like SBC is possible if standard and market adopts. So, I'll prefer to have SRTP-DTLS as long as there is no alternative standard proposal or new proposal exists.  

Thanks
Partha

>Of Cullen Jennings
>Sent: Thursday, January 12, 2012 9:20 AM
>To: Roman Shpount
>Inline answer with my Cisco hat on .... I've mostly given up mention
>this because I sent it to RAI lists too many times before but ...
>
>Yes, Yes, Yes, and Yes respectively. For example, pretty much all the
>Cisco high end tele presence stuff with includes endpoints, conference
>bridges, protocol conversion devices etc supports it. The bulk of the
>platforms that are newer than 5 years old from Cisco support DTLS-SRTP.
>It interoperates with other vendors. We don't go to SIPIT because with
>this sort of stuff as it does not seem to be the best way to test it. We
>find that many of the vendors to test with at SIPIT are just getting
>going and are still trying to get their spiral loops to work. Don't get
>me wrong - I love SIPIT and strongly support it, but it's not the place
>to test everything. I've been told a lot of IMS systems can do MiKEY
>though I don't recall seeing a test of that at SIPIT. Different folks,
>different places.
>
>>
>I have no idea how much our internal version have diverged from the
>version you are using but the libSRTP is being used for a huge number of
>calls by enterprises, movements, and military systems. There's not a lot
>of bugs reported. I'm certainly not claiming there are bugs in any given
>piece of software but you can look at release notes of cisco products
>and see this is pretty stable. I realize this does not help much but
>DTLS-SRTP is not real complicated if you already have a good TLS stack
>and crypto engine - regardless of the quality of any given
>implementation, it should not be hard to make a good one.
>
>>
>I note most the good deployed SSL VPN in the world are DTLS . Check out
>the market share of SSL VPN to traditional IPSec. DTLS is widely used.
>Heck, at the next IETF, just check out the amount of DTLS traffic coming
>from IETF participants.
>
>>
>I've been on the design and implementation team for multiple SBCs - I
>was even a co-founder of an SBC company. But it's really easy to figure
>out - you don't need to know much about SBC - it more or less the same
>as it would be for any UA.
>
>Lets say you have nice SBC that will do 10,000 concurrent sessions.
>These are not cheap. If you are doing RTP on one side and DTLS-SRTP on
>the other side of each call. Lets just use a pessimistic estimate of
>average call duration of 3 minutes. So this device is doing 10000 / 3 /
>60 = 55 session setups per second. The expensive part of this is the RSA
>private key operation. A single core on the crappy computer I am sending
>this email from does about 850 rsa1024 private key operations on a
>single core. Try out your machine with "openssl speed rsa1024". It
>roughly equivalent to two private key ops - So a big SBC needs 110 per
>second under pessimistic assumption and a small CPU can do 850. As you
>can imagine, an SBC like that is using some pretty beefy processors -
>they impact of the DTLS is often hard to measure it is so little. The
>amount of processing you need to process the all the SIP for a single
>call greatly exceeds the amount of processing to set up the DTLS
>connection. D  TLS also requires much less per connection state than SIP
>although SBC are typically more constrained by CPU than memory.
>
>
>>
>setup?
>A drop in the bucket compared to ICE :-) It depends on how you assume
>the ICE ends up going and if you do early media or not. There are many
>ways to overlap lots of this processing to minimize impact so it a
>slightly hard question to answer but if you draw some call flows with
>ICE, you will probably agree with my sort of flip "drop in the bucket"
>answer.
>
>Uh, don't think I am following you here - it's just a dummy X.509 record
>to carry the public keys. There's no CA to validate it at.
>
>> _____________
>> Roman Shpount
>Thought I sound like I might be arguing for DTLS-SRTP to be the only
>thing - I'm not sure what I think. I want to see what the whole security
>systems looks like. If the weakest link is weak, well no point in making
>other links super strong.  Clearly the UI needs the ability of
>indicating in a secure way if the call is secure or not and the identity
>of who is at the other end of secure part. I can imagine Browser to
>Browser perhaps always being secure, I agree secure should be preferred
>to insecure where both are possible, but have a hard time imagining that
>we won't wish we had RTP for Browser to Legacy.
>
>Part of me believes that not having the option of using RTP in fallback
>legacy cases would be about equally insane to not supporting IPv4 and
>only doing v6. Sorry for all the nots.
>
>
>
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Jan 2012 06:56:01 -0500

Just as a side not SRTP-SDES is a fairly simple feature to implement. All
you need as AES CM, SHA1  HMAC, F8, and a replay database. This is a few
thousand lines of code (or a lot less if you have good crypto library, such
as OpenSSH, GnuTLS, or Intel IPP, handy).

libsrtp comes with its own crypto library (which is considerably worse
maintenance state wise and performance wise then OpenSSH or GnuTLS). It
also implements extensive self-checks as a part of library initialization,
which are strictly speaking not necessary. For some reason libsrtp
implements two replay libraries (one for RTP and another for RTCP) even
though they suppose to do the same thing. It also implements a number of
crypto routines that are not normally used for anything when implementing
SRTP.

My point is, if all is needed is an implementation of SRTP-SDES, the state
of libsrtp is irrelevant since it is easy enough to code around. If
SRTP-DTLS is needed, then couple of order of magnitude more code is needed
to implement TLS handshake, which will mean using an existing mature DTLS
implementation and adding SRTP encoding if necessary.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jan 2012 06:37:04 -0800

On Thu, Jan 12, 2012 at 3:56 AM, Roman Shpount <[email-masked]> wrote:

> maintenance state wise and performance wise then OpenSSH or GnuTLS). It also
> implements extensive self-checks as a part of library initialization, which
> are strictly speaking not necessary. For some reason libsrtp implements two
> replay libraries (one for RTP and another for RTCP) even  though they
> suppose to do the same thing. It also implements a number of crypto routines
> that are not normally used for anything when implementing SRTP.
>

DTLS-SRTP was specifically designed so that one could put together a DTLS
stack and an SRTP stack with minimal modifications to both (and no necessary
modifications to the SRTP stack). In the case of OpenSSL and libsrtp, you
do the OpenSSL handshake, then use a new interface to export the keys
which you then push onto libsrtp using existing interfaces.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jan 2012 06:40:45 -0800

> Another reason I heard mostly from hardware device vendors was that the chips vendors lack support of DTLS.

Aside from the question here, I'd be interested to talk to vendors who
have this concern.
The hardware interfaces for DTLS are very similar to those for DTLS.
Indeed, if you're
just doing asymmetric key acceleration they are identical. So, please
feel free to
point anyone like this to me and I'll be happy to try to help.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 Jan 2012 16:59:49 +0200

Hi Ekr, Hi Olle, 

I am also interested to hear why vendors want to put support support for DTLS into their chip. I would rather assume that they want to have the SRTP support in hardware and use hardware support for some selected functions of the key exchange (instead of implementing the entire protocol). 

I believe that there is a confusion about DTLS-SRTP from how the design looked like initionally when the DTLS record layer was used; the design was later changed to support SRTP and to use DTLS to create the SRTP security associations. 

Ciao
Hannes

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Jan 2012 11:18:56 -0500

On Thu, Jan 12, 2012 at 9:37 AM, Eric Rescorla <[email-masked]> wrote:

> My point is if you use OpenSSL crypto functions you can replace libsrtp
with a few hundred lines of code. It is almost easier then integrating with
libsrtp (and introduce another instance of unoptimized encryption and check
sum functions).
_____________
Roman Shpount

---

From: Oscar Ohlsson <[email-masked]>
Date: Thu, 12 Jan 2012 22:42:20 +0100

Randall said:

> workable DTLS-SRTP implementation openly available, and 
> locking WebRTC down to that only.
> 
> If we use SDES, we're effectively trusting the JS app (and 
> website) to a very large extent.  (Not to turn on the 
> camera/mic, but with the contents of all conversations.)  It 
> also means bid-down to SDES is trivial.  I'm not sure what 
> this would mean to identity validation via BrowserID or 
> others (ekr?); that might survive this, but it means media 
> could be decrypted in realtime or later if anyone has copies 
> of the packets and can get the key from the app/website.

As has been pointed out many times before it is not significantly harder to eavesdrop on a SDES call than a DTLS-SRTP call. When comparing SDES to DTLS-SRTP the comparison should really be made with plain DTLS-SRTP without key continuity or the new identity mechanism.

There are a number of reasons why key continuity doesn't work in a web context. EKR mention the problem of multiple browsers but there are other issues as well (e.g., public key not bound to an id, an increasing amount of public keys stored over time, anonymous users with one time public keys, etc). It is therefore unlikely that the user will react if the peer's fingerprint is replaced by the web application.

The new identity mechanism doesn't help eiter unless it is made mandatory to use. In the same way as the web application can downgrade from DTLS-SRTP to SDES it can downgrade from DTLS-SRTP+identity to plain DTLS-SRTP. I doubt that the identity mechanism can be made mandatory since:

(1) Many web applications do not want to depend on external identity providers
(2) Some users do not have any identity provider account
(3) Many web applications are already trusted by the user
(4) Users may not always want to reveal their identity
(5) Working out all the details of the identity mechanism will take time

Protecting ourselves against the web application would also require disabling (or at least require user consent for) lots of useful JavaScript functionality (e.g. forwarding, manipulation, or recording of streams). The bottom line is that (except in the case of security aware users) the web application will be able to eavesdrop on calls.

I know that logging and cross-site scripting has been pointed out as potential vulnerabilities for SDES. These two problems should be properly analyzed but let's defer that discussion for now. 

Regards,

Oscar Ohlsson

---

From: Randell Jesup <[email-masked]>
Date: Thu, 12 Jan 2012 16:54:54 -0500

On 1/12/2012 11:18 AM, Roman Shpount wrote:
>
> On Thu, Jan 12, 2012 at 9:37 AM, Eric Rescorla <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> with a few hundred lines of code. It is almost easier then integrating
> with libsrtp (and introduce another instance of unoptimized encryption
> and check sum functions).

I'm not tied to libsrtp - though I have commit privileges for it, and 
made a bunch of improvements and fixes to it back in the 2004-2005 
timeframe (SRTCP was broken, remove dependence on long long, etc), since 
which point (around 2006) it's been very stable outside of a very 
occasional patch.

Last set of changes generally seem to be around a year and half ago by 
Jonathan Lennox. (A few minor C99 changes this fall).

It does the job.  Perhaps you can replace it with a few hundred lines of 
OpenSSL code; I have to say I'd be surprised.  But srtp.c is ~2000 
lines; I can believe OpenSSL would replace most of the crypto files; 
you'd still need much of the logic in srtp.c and perhaps the replay code.

And realize we're not specifying libsrtp, just SRTP - so your comment 
that libsrtp can be replaced with OpenSSL plus some code is simply more 
indication that SRTP implementations are not a blocker.

-- 
Randell Jesup
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Thu, 12 Jan 2012 14:18:03 -0800

> The new identity mechanism doesn't help eiter unless it is made mandatory to use. In the same way as the web application can downgrade from DTLS-SRTP to SDES it can downgrade from DTLS-SRTP+identit…

I think this points out something I had assumed, but not be
well-stated anywhere:  that any identity associations are stored
outside the javascript applications.  My mental model for that had
been the "known_hosts" file you find in .ssh directories in unix
systems; I had imagined that a browser or an OS would store the
associations.  That doesn't give you great guarantees about identity,
but it does give you reasonable guarantees about persistence of
identity.  To put this another way, with this, I think the bid-down
attack is really effective only the first time the association is
created.

There is always the UI problem of how to notify folks when the
association cannot be validated by the stored data, but I think that's
a separate problem.

Had you not assumed that, or are you drawing different conclusions of
the result of its availablity?

Ted

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 12 Jan 2012 14:21:24 -0800

> the result of its availablity?

More generally, identity assertions should be enforced in the browser or
the OS. This is true whether they are key continuity (which, as Oscar says,
is not the world's greatest mechanism and is primarily usable by
the security conscious) or a 3rd-party identity mechanism of the type that
is discussed in my draft.

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 13 Jan 2012 15:19:50 +0100

> As has been pointed out many times before it is not significantly harder to eavesdrop on a SDES call than a DTLS-SRTP call. When comparing SDES to DTLS-SRTP the comparison should really be made wit…
Sorry, I couldn't parse that.

Are you saying that it is harder (but not significantly harder) to 
eavesdrop on a call with key exchange using SDES than it is to eavesdrop 
on a call with key exchange using DTLS-SRTP?
That didn't compute for me - did something get inverted somewhere?

(I don't feel confident enough in the ways of key exchanges that I want 
to assume that it's a simple inversion - but I think it's strictly 
harder to eavesdrop on DTLS-SRTP than on SDES; with DTLS-SRTP you have 
to do a man-in-the-middle on the key exchange + finagling with the 
confirmation bits sent via the signalling, while in the SDES case, you 
only need to eavesdrop on the signalling, which is strictly a simpler 
operation. Not saying that the difference is significant).

                   Harald

---

From: Oscar Ohlsson <[email-masked]>
Date: Fri, 13 Jan 2012 17:09:39 +0100

Sorry, yes it should be the other way around.

I agree that eavesdropping on a DTLS-SDES call is harder and would require a greater (initial) coding effort. But the difference is not huge as some emails seem to suggest.

1. Search for 'a=fingerprint:' in the offer/answer SDP string and replace what comes after with your own public key fingerprint (a single, statically configured public key would probably do if synching with the TURN server is hard)

2. Force the media to go through the TURN server by deleting all ICE candidates except the relayed one (if deleting is not possible another option is to replace the candidates with bogus ones)

3. Modify an existing TURN server implementation so that it decrypts and re-encrypts the DTLS traffic

Regards,

Oscar Ohlsson 

> Sent: den 13 januari 2012 15:20
> To: Oscar Ohlsson
> > As has been pointed out many times before it is not 
> significantly harder to eavesdrop on a SDES call than a 
> DTLS-SRTP call. When comparing SDES to DTLS-SRTP the 
> comparison should really be made with plain DTLS-SRTP without 
> key continuity or the new identity mechanism.
> Are you saying that it is harder (but not significantly 
> harder) to eavesdrop on a call with key exchange using SDES 
> than it is to eavesdrop on a call with key exchange using DTLS-SRTP?
> (I don't feel confident enough in the ways of key exchanges 
> that I want to assume that it's a simple inversion - but I 
> think it's strictly harder to eavesdrop on DTLS-SRTP than on 
> SDES; with DTLS-SRTP you have to do a man-in-the-middle on 
> the key exchange + finagling with the confirmation bits sent 
> via the signalling, while in the SDES case, you only need to 
> eavesdrop on the signalling, which is strictly a simpler

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Jan 2012 08:51:40 -0800

This discussion illustrates some of the issues that arise in analyzing the security of SIP-based functionality re-purposed for RTCWEB.  If we assume that signaling is not implemented natively, then we cannot depend on functionality provided within signalling in our security analysis.   This implies that the security properties of ICE, DTLS/SRTP, etc. can be different in RTCWEB than they would be within SIP.   In contrast, the security properties of media-only approaches such as ZRTP are the same regardless of the signalling approach (e.g. SIP, Jingle, etc.).  

Within DTLS/SRTP as used in SIP, RFC 4474 is utilized to provide end-to-end integrity of the SDP and address the man-in-the-middle attack you refer to below.   In a scenario where an RTCWEB application needed to interoperate with a DTLS/SRTP implementation utilizing SIP, presumably RFC 4474 would be supported. 

However, if SIP is not implemented natively, then an alternative mechanism is needed.  As you point out below, the identity provider approach described in the security draft does not address all of the potential attacks that are handled by RFC 4474 (e.g. ICE mangling).  

> I agree that eavesdropping on a DTLS-SRTP call is harder and would require a greater (initial) coding effort. But the difference is not huge as some emails seem to suggest.
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 Jan 2012 09:31:29 -0800

On Mon, Jan 16, 2012 at 8:51 AM, Bernard Aboba
<[email-masked]> wrote:
> This discussion illustrates some of the issues that arise in analyzing the
> security of SIP-based functionality re-purposed for RTCWEB.  If we assume
> that signaling is not implemented natively, then we cannot depend on
> functionality provided within signalling in our security analysis.   This
> implies that the security properties of ICE, DTLS/SRTP, etc. can be
> different in RTCWEB than they would be within SIP.   In contrast, the
> security properties of media-only approaches such as ZRTP are the same
> regardless of the signalling approach (e.g. SIP, Jingle, etc.).
>
> Within DTLS/SRTP as used in SIP, RFC 4474 is utilized to provide end-to-end
> integrity of the SDP and address the man-in-the-middle attack you refer to
> below.   In a scenario where an RTCWEB application needed to interoperate
> with a DTLS/SRTP implementation utilizing SIP, presumably RFC 4474 would be
> supported.
>
> However, if SIP is not implemented natively, then an alternative mechanism
> is needed.  As you point out below, the identity provider approach described
> in the security draft does not address all of the potential attacks that are
> handled by RFC 4474 (e.g. ICE mangling).

I'm not tracking this argument at all:

1. If you have end-to-end integrity for the keying material, then providing
end-to-end security for the ICE candidates only offers modest additional
value, since all it does is prevent rerouting of the ciphertext.

2. There's no technical reason why the IdP-based approach detailed in
Appendix A can't cover the ICE candidates as well. Indeed, it's natural
to have it cover as much of the message as possible. However,
since we haven't yet settled on the signaling protocol, it's also not
possible to settle on the exact inputs to the signature. However, the
minimum necessary is the public key of the side.

3. In the RTCWEB setting, since the STUN and TURN servers are likely
to be supplied by the signaling site, it's probably not that difficult for a
malicious signaling server to simply provide STUN and TURN responses
which reroute the traffic through it without tampering with the ICE
candidates at all. E.g., it provides a bogus server-reflexive address, thus
forcing ICE to converge on its TURN server.

-Ekr

>> I agree that eavesdropping on a DTLS-SRTP call is harder and would require
>> a greater (initial) coding effort. But the difference is not huge as some
>> emails seem to suggest.
>>
>> 1. Search for 'a=fingerprint:' in the offer/answer SDP string and replace
>> what comes after with your own public key fingerprint (a single, statically
>> configured public key would probably do if synching with the TURN server is
>> hard)
>>
>> 2. Force the media to go through the TURN server by deleting all ICE
>> candidates except the relayed one (if deleting is not possible another
>> option is to replace the candidates with bogus ones)
>>

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 16 Jan 2012 12:51:36 -0500

Exactly!

On 1/16/2012 12:31 PM, Eric Rescorla wrote:
> ...
> to have it cover as much of the message as possible.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 16 Jan 2012 09:58:03 -0800

> minimum necessary is the public key of the side.

[BA] I agree that it makes sense to cover as much of the message as
possible.   However, I'd also suggest that it is undesirable to tie RTCWEB
key management to particular signaling mechanisms.

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 29 Jan 2012 22:37:18 -0700

Making libsrtp so it had a compile time flag to use the openssl crypto or select it's own crypto seem like it would be a nice improvement to it but lots of the places folks want to use libsrtp is a DSP of some sort - it cab be a big hassle to try and port all of the crypto from openssl to that type of environment so probably would not want to have it require openssl. 

On Jan 12, 2012, at 2:54 PM, Randell Jesup wrote:

> I'm not tied to libsrtp - though I have commit privileges for it, and made a bunch of improvements and fixes to it back in the 2004-2005 timeframe (SRTCP was broken, remove dependence on long long, etc), since which point (around 2006) it's been very stable outside of a very occasional patch.
> 
> Last set of changes generally seem to be around a year and half ago by Jonathan Lennox. (A few minor C99 changes this fall).
> 
> It does the job.  Perhaps you can replace it with a few hundred lines of OpenSSL code; I have to say I'd be surprised.  But srtp.c is ~2000 lines; I can believe OpenSSL would replace most of the crypto files; you'd still need much of the logic in srtp.c and perhaps the replay code.
> 
> And realize we're not specifying libsrtp, just SRTP - so your comment that libsrtp can be replaced with OpenSSL plus some code is simply more indication that SRTP implementations are not a blocker.
> 
> 
> -- 
> Randell Jesup
> [email-masked]