Subject: [rtcweb] SRTP and "marketing"

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Mar 2012 11:15:31 +0200

I didn't make it to the mic at the meeting today, but I wanted to 
express one concern about the possibility of making RTCWEB SRTP-only.

Hadriel mentioned the "marketing value" of having always-on encryption, 
this idea that only supporting SRTP will make RTCWEB look like something 
secure and trustworthy.  I'm concerned that this might not be the case, 
and in fact that being SRTP-only might effectively be an over-promise, 
in light of the fact the absence of universal authentication.

Hadriel noted that the competitors to this technology are Skype and 
Flash, and it's worth considering the security situation with these 
technologies, because they kind of bracket RTCWEB.  With Skype (assuming 
they've designed it properly), there is actually a universal 
authentication, under a single authority.  So you really do know that 
you're talking to whatever Skype ID you intend to, and nobody else. 
With Flash, well, does anyone expect it to be secure anyway?

What I'm concerned about in the RTCWEB context is that without a 
universal authentication/identity infrastructure, we will end up 
*promising* a secure call, but not *delivering* it.  I haven't done the 
analysis, but it does not seem implausible to me that FireSheep-like 
vulnerabilities are lurking here.

So ISTM the "marketing" argument carries with it some serious risks as 
well as some small possible benefit.

--Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Mar 2012 12:13:39 +0200

On 03/28/2012 11:15 AM, Richard L. Barnes wrote:
> Hadriel mentioned the "marketing value" of having always-on 
> encryption, this idea that only supporting SRTP will make RTCWEB look 
> like something secure and trustworthy.  I'm concerned that this might 
> not be the case, and in fact that being SRTP-only might effectively be 
> an over-promise, in light of the fact the absence of universal 
> authentication.
>
> technologies, because they kind of bracket RTCWEB.  With Skype 
> (assuming they've designed it properly), there is actually a universal 
> *promising* a secure call, but not *delivering* it.  I haven't done 
> the analysis, but it does not seem implausible to me that 
> FireSheep-like vulnerabilities are lurking here.
If there are, we need to close them before we ship the specs.
Given reasonable practices (such as using only HTTPS for loading the 
pages and JS libraries), if we can't deliver security (against known 
attacks), we shouldn't ship the spec.
> well as some small possible benefit.
Only if we don't deliver.
>
> --Richard
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Mar 2012 12:43:31 +0200

> attacks), we shouldn't ship the spec.

I agree that we should lock things down to the extent we can, and I 
think we will be able to do pretty well, using things such as you note.

But at base, without authentication, you cannot prevent MitM if someone 
is in the right place in the network.  You can just constrain the set of 
places from which an MitM can be launched.

> Only if we don't deliver.

Except that "deliver" in this case entails a global 
authentication/identity infrastructure.  And it seems unlikely that 
we'll deliver that in the short run.

--Richard

---

From: Mahalingam Mani <[email-masked]>
Date: Wed, 28 Mar 2012 03:55:16 -0700

On Wed, Mar 28, 2012 at 2:15 AM, Richard L. Barnes <[email-masked]> wrote:

> [...]
> What I'm concerned about in the RTCWEB context is that without a universal
> authentication/identity infrastructure, we will end up *promising* a secure
> call, but not *delivering* it.  I haven't done the analysis, but it does
> not seem implausible to me that FireSheep-like vulnerabilities are lurking
> here.
>
>
>

The choices of framework proposed in today's meeting still carry an overall
undercurrent of the same generic mechanism as a SAML-based authentication
and authorization.
Even if a universal authentication infrastructure should exist - it becomes
a potential single point of failure (imagine that being the defunct
diginotar) or non-success (MS Passport).
Too many trust-anchors (IdPs) is a problem as well for the single end-user
(non-enterprise). But in the end - would users prefer to go with the
trust-anchors they have come to associate with and have gained a reputation
for; or something completely new?

Even with identity - the authoritative case proposes a <name>:<domain>
paradigm and in the 3rd party case too - assertions are based on
association of a user to domain - by an outside idP. Thus, there's
significant closeness in the identity form - regardless of whether it is
the most common RFC822 (email address), SIP URI (with a slight exception of
OpenID) or other URI forms.

-mani

> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 28 Mar 2012 16:42:24 +0200

Changing the subject line...

On 03/28/2012 12:55 PM, Mahalingam Mani wrote:
>
>
> On Wed, Mar 28, 2012 at 2:15 AM, Richard L. Barnes <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [...]
>     *promising* a secure call, but not *delivering* it.  I haven't
>     done the analysis, but it does not seem implausible to me that
> The choices of framework proposed in today's meeting still carry an 
> overall undercurrent of the same generic mechanism as a SAML-based 
> authentication and authorization.
> Even if a universal authentication infrastructure should exist - it 
> becomes a potential single point of failure (imagine that being the 
> defunct diginotar) or non-success (MS Passport).
> Too many trust-anchors (IdPs) is a problem as well for the single 
> end-user (non-enterprise). But in the end - would users prefer to go 
> with the trust-anchors they have come to associate with and have 
> gained a reputation for; or something completely new?
> significant closeness in the identity form - regardless of whether it 
> is the most common RFC822 (email address), SIP URI (with a slight 
> exception of OpenID) or other URI forms.

This actually shows that the IdP proposal brings a dependency with it on 
the domain hierarchy.
This has real issues, the most important one perhaps being that domain 
identities can't be guaranteed over time; even when real-life 
organizational identities exist, it's not unusual to see the domain name 
change hands multiple times, either voluntarily (selling) or 
involuntarily (UDRP, court cases, forgetting to renew and being 
drop-kicked).

Not sure where discussion of this problem belongs; it might not be a 
problem if one never has to verify a stored identity.

I think the proposals bring significant value even in the absence of 
standardized identity verification - FireSheep is a good example, for 
instance; with HTTPS, FireSheep is powerless as long as it's not in 
cahoots with a corrupted CA - which defeats a huge subset of the set of 
potential attackers.

---

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

> well as some small possible benefit.
If I'm totally missing the point (not having attended the event
mentioned), please disregard what I have to say.

I think that there is a value to having an encrypted connection, even if
it does not combine with it authentication from both ends, as this
would, at the very least, prevent snooping of the communications between
the two end points.  This would be the equivalent of using a self-signed
certificate for HTTPS, without the drama of the certificate warnings we
get in browsers.

What I mean is, we can make the higher degree of security be one that
combines authentication with encryption, but always-on encryption can be
the default, and this is what I meant by saying it still has value.  At
least a 3rd-party would not be able to spy on communications between two
people and the connection has a minimum degree of privacy to it. 
Combined with a trusted method of establishing authentication, whether
via a central authority (e.g., current CA's) or allowing users to
exchanged keys via other channels (e.g., PGP chain of trust style), then
a fully trustworthy and private method of communications can be established.

I hope the two degrees I am pointing out are clear.

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard L. Barnes
> Sent: Wednesday, March 28, 2012 12:44 PM
> To: Harald Alvestrand
> Cc: [email-masked]
> Subject: Re: [rtcweb] SRTP and "marketing"
> 
> the

We do need a foundation upon which an authentication/identity 
infrastructure can be built.  We know we need one.

That foundation is DTLS-SRTP, and not Security Descriptions.

-d

---

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

> That foundation is DTLS-SRTP, and not Security Descriptions.

Now you're starting to sound like a marketing guy.  ;)
What's next: "we'll build more synergy and have a unified platform with DTLS-SRTP"?

But more seriously, I don't understand this "foundation" argument.  We're going to have DTLS-SRTP.  No one's suggesting we don't have DTLS-SRTP.  All Browsers MUST implement DTLS-SRTP.  We'll have it for Browser-to-Browser, and for Browser-to-Gateway if the Gateway supports it.  We'll have the foundation.

Requiring it for Gateways would make sense if it offered some real advantage, or didn't have any disadvantages.  There don't appear to be real advantages, while we know of disadvantages.  And gateways have no real means of offering an end-to-end identity.  Why would you want to build a foundation on air?

-hadriel

---

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

On Mar 28, 2012, at 11:15 AM, Richard L. Barnes wrote:

> Hadriel noted that the competitors to this technology are Skype and Flash, and it's worth considering the security situation with these technologies, because they kind of bracket RTCWEB.  With Skype (assuming they've designed it properly), there is actually a universal authentication, under a single authority.  So you really do know that you're talking to whatever Skype ID you intend to, and nobody else. With Flash, well, does anyone expect it to be secure anyway?

As far as I know, you don't actually "know" that with Skype.  You assume it, because you trust Skype.  They could forge whatever identity they wanted to, and they can insert a recording middlebox if they wanted to, afaict.  No one is concerned about that.  They also have skype-in/skype-out to/from the PSTN, and clearly in those cases they can assert whatever identity they want, and record it all.  Again no one is concerned.  Have you ever wondered why no one freaks out?

> What I'm concerned about in the RTCWEB context is that without a universal authentication/identity infrastructure, we will end up *promising* a secure call, but not *delivering* it.  I haven't done the analysis, but it does not seem implausible to me that FireSheep-like vulnerabilities are lurking here.
> So ISTM the "marketing" argument carries with it some serious risks as well as some small possible benefit.

It was my understanding firesheep only works when the connection is HTTP, because it sniffs the packets.  That's a real issue for RTP, not for SRTP (in either SDES or DTLS cases).

Of course neither I nor anyone else can really foretell what the trade press will say - but I remember what they said about SIP back when a couple ARP-spoofing "attack" tools demonstrated how to intercept RTP and play it, since I was in marketing at the time.  At the time, the articles were only advocating people should use "SRTP" instead.  They didn't care at all what the key-exchange protocol was.

-hadriel

---

From: "Jim Barnett" <[email-masked]>
Date: Wed, 28 Mar 2012 15:31:10 -0700

Another point is that username/password authentication schemes aren't
really that secure - it's pretty easy to steal a username and password,
after all.  So there's not  really a binary
authenticated/unauthenticated switch.  It's more a matter of degree.  

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hadriel Kaplan
Sent: Wednesday, March 28, 2012 5:59 PM
To: Richard L. Barnes
Cc: <[email-masked]>
Subject: Re: [rtcweb] SRTP and "marketing"

Flash, and it's worth considering the security situation with these
technologies, because they kind of bracket RTCWEB.  With Skype (assuming
they've designed it properly), there is actually a universal
authentication, under a single authority.  So you really do know that
you're talking to whatever Skype ID you intend to, and nobody else. With
Flash, well, does anyone expect it to be secure anyway?

As far as I know, you don't actually "know" that with Skype.  You assume
it, because you trust Skype.  They could forge whatever identity they
wanted to, and they can insert a recording middlebox if they wanted to,
afaict.  No one is concerned about that.  They also have
skype-in/skype-out to/from the PSTN, and clearly in those cases they can
assert whatever identity they want, and record it all.  Again no one is
concerned.  Have you ever wondered why no one freaks out?

It was my understanding firesheep only works when the connection is
HTTP, because it sniffs the packets.  That's a real issue for RTP, not
for SRTP (in either SDES or DTLS cases).

Of course neither I nor anyone else can really foretell what the trade
press will say - but I remember what they said about SIP back when a
couple ARP-spoofing "attack" tools demonstrated how to intercept RTP and
play it, since I was in marketing at the time.  At the time, the
articles were only advocating people should use "SRTP" instead.  They
didn't care at all what the key-exchange protocol was.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Wed, 28 Mar 2012 20:54:14 -0400

On 3/28/2012 5:58 PM, Hadriel Kaplan wrote:
> As far as I know, you don't actually "know" that with Skype.  You assume it, because you trust Skype.  They could forge whatever identity they wanted to, and they can insert a recording middlebox if they wanted to, afaict.

And they do.  Very, very quietly I assume.  (I.e. they're certainly 
subject to CALEA in the US for on-net calls, and I assume have a deal 
with the FCC/etc to cover it.)  There have been a few public hints about 
this and similar deals with other countries.

>    No one is concerned about that.

Define "no one" :-)

> They also have skype-in/skype-out to/from the PSTN, and clearly in those cases they can assert whatever identity they want, and record it all.  Again no one is concerned.  Have you ever wondered why no one freaks out?

People don't freak out because a) few realize it, b) most who do realize 
it's government mandated on them, and fighting it would likely be a huge 
losing proposition for them ($$$$).  If I were a democracy activist in 
Iran or China other similar countries I would not assume Skype was safe 
(though in many of those countries it probably is, but probably not 
China).  Those are just my assumptions; small on-net companies and 
services can fly under the radar or avoid touching things that force 
them to comply (I did that at Worldgate; no PSTN access == no CALEA).

That doesn't mean I don't want to implement a truly secure 
communications ability.  Note that by "secure" here I mean "I can detect 
if the service MITMd me" -- without reading cert phrases and preferably 
without having to install client certs and somehow build a working PKI.

One idea we've had is a non-centralized WebRTC service built on 
distributed hash tables and a partial-mesh set of connections used to 
pass signaling on WebRTC (or other) data channels to set up calls, with 
some type of Id system to validate who you get connected to (since you 
can't really trust any of the nodes fully).  If an intermediary node can 
downgrade you to SDES and sniff the keys, there is no security.

An alternative would be to allow a hybrid: SDES at the start of a call 
and rekey over to DTLS-SRTP after the call is connected.  If something 
blocks the DTLS connection it would be treated as a 
gateway-to-legacy/PSTN call (i.e. show no security, though it's secure 
against non-in-path attackers); if the DTLS connection is allowed, we 
can use it to rekey to DTLS-SRTP and to verify identity.

This minimizes the risk of bid-down - the primary additional risk is 
that without initial SDES, to tap the signal you'd need to use a 
WebRTC-enabled B2BUA to accept the DTLS-SRTP connection and siphon it 
off.  Also, a "good" gateway in a pure DTLS-SRTP world might have a 
identity established ("[email-masked]"); with SDES it wouldn't by 
default (but it could if it wanted to by rekeying via DTLS also).  You 
also have a start-of-call risk where someone could see & hear until 
rekeying, and perhaps for a short while by blocking actual rekeying by 
dropping/corrupting DTLS packets, until the client either gives up or 
warns of no security.

I'm still strongly in favor of pure DTLS-SRTP - as Harald and others 
say, less moving parts and less things that need to be secured.  But 
this might be a useful compromise if we *need* to support SDES in some 
cases.

-- 
Randell Jesup
[email-masked]

---

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

Hadriel Kaplan wrote:
> As far as I know, you don't actually "know" that with Skype.  You assume it,
> because you trust Skype.  They could forge whatever identity they wanted to,
> and they can insert a recording middlebox if they wanted to, afaict.
> No one is concerned about that.  They also have skype-in/skype-out to/from

This is, of course, not true. See, for example, 
http://www.technologyreview.com/web/38379/

The relevant bit, for those who don't want to read the whole article: 
'"We met using Mumble [which is open-source, uses digital certificate 
authentication, and is regarded by Takriz as more secure than Skype].' 
(brackets in the original).

Which is not to say that Tunisian rebels never used Skype (the article 
mentions several instances where they did), but it is clearly inaccurate 
to say no one was concerned about it.

---

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

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

>> it,
> http://www.technologyreview.**com/web/38379/<http://www.technologyreview.com/web/38379/>
>
> The relevant bit, for those who don't want to read the whole article: '"We
> met using Mumble [which is open-source, uses digital certificate
> mentions several instances where they did), but it is clearly inaccurate to
> say no one was concerned about it.
>
>
And then there is an argument that Skype is a huge security risk exactly
due to the fact that it is using encrypted communications. There were hints
of using Skype communication protocol and Skype client to access files
remotely on the user computer or ability to open ports into a local network
using a Skype client running there (using Skype as a malicious VPN client).
Entire protocol and client are proprietary and were never validated by an
independent party as being secure in a sense of preventing unauthorized
remote access. This is one of the reasons why Skype is not allowed in a lot
of corporate or government networks. Even though this should not apply to
WebRTC since it is going to be an open standard with an intensive peer
review, it would still apply to the web browsers. If web browser software
is compromised due to some sort of attack or malicious plugin (or one of
the browser vendors snooping), and since browser applications will start
establishing unsolicited encrypted connections, there is no easy way to
determine that the browser is not doing something undesirable.  I actually
believe that if sufficient monitoring constraints are not build into a
browser (not to record but at least to monitor who the browser is
exchanging data with and using what protocols), WebRTC would be simply
disabled in most enterprises as a security risk.
_____________
Roman Shpount

---

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

On 3/28/12 11:58 PM, Hadriel Kaplan wrote:
> But more seriously, I don't understand this "foundation" argument.  We're going to have DTLS-SRTP.  No one's suggesting we don't have DTLS-SRTP.  

I'm no-one, but i would strongly argue to use SDES-SRTP considering that
forcing the world to implement a non-used new standard (DTLS-SRTP) for a
new not-yet-implemented new standard (WebRTC) it's a fault.

> All Browsers MUST implement DTLS-SRTP.  We'll have it for Browser-to-Browser, and for Browser-to-Gateway if the Gateway supports it.  We'll have the foundation.
> 

We need to build a new protocol on the foundation of existing protocol.

DTLS-SRTP doesn't exists because no-one use it, there are no diffused
implementation and no interoperability testing done.

DTLS-SRTP require a *huge effort* to set it up.

SDES-SRTP does not require such *huge effort* and will unleash the
advantage of an existing ecosystem of application and protocol stacks
already there.

While i understand Mr. Wing points related to Identity, i think that
Identity will be guaranteed not at "media level" but from existing
transport that is HTTP/HTTPS and all the W3C protocol that run on top of
the Web (Federated Authority) to handle Authorization and Authentication.

Reinventing something new it's imho just wrong.

-- 
Fabio Pietrosanti
Founder, CTO

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

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

---

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

> authenticated/unauthenticated switch.  It's more a matter of degree.  

Why we would like to solve this problem at WebRTC level, while there's a
stockpile of standard, best-practice and future perspective to
authenticate/authorize users over Web secured (TLS) transport?

VoIP for Browser imply that we have a Browser and a Web application
(server & client side javascript).
Imho we should re-use what's already there trying to avoid adding more
complexity.

-- 
Fabio Pietrosanti
Founder, CTO

---

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

On 3/29/12 7:42 AM, Roman Shpount wrote:
> I actually believe that if sufficient
> monitoring constraints are not build into a browser (not to record but
> at least to monitor who the browser is exchanging data with and using
> what protocols), WebRTC would be simply disabled in most enterprises as
> a security risk.

Your concern would be addressed by the use of SDES-SRTP rather than
DTLS-SRTP.

SDES-SRTP would provide, in the context of WebRTC, the transport of SDES
key over HTTP(S) and so would let all existing methods for HTTP/HTTPS
inspection to works fine.

Technology for inspection of HTTP/HTTPS traffic already exists, are
widely deployed and so if we transport keying material over HTTP (with
SDES-SRTP), all Enterprises will already have their existing
infrastructure in-place.

-- 
Fabio Pietrosanti
Founder, CTO

---

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

> SDES-SRTP), all Enterprises will already have their existing

I am not sure I would agree with this. In order for what you propose to
work there is a need for a reliable mechanism to extract SDP from
HTTP/HTTPS traffic. This is not as simple as you would think, since
JavaScript application can use any custom protocol to transmit the SDP
data. It can, for instance, even implement encryption in JavaScript that
will encode SDP using user supplied key, which would make SDP extraction
impossible. In order to implement such inspection we need to have some sort
of hook in the browser that allows an external entity to intercept and
examine all the SDP being passed to and from WebRTC. Without such hook
there is no benefit to SDES. With such hook there is no downside to DTLS.
_____________
Roman Shpount

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 29 Mar 2012 06:08:29 +0000

>>   No one is concerned about that.

There are Billions of people on the planet.  Obviously I don't mean the number who don't care is 0. :)

> That doesn't mean I don't want to implement a truly secure communications ability.  Note that by "secure" here I mean "I can detect if the service MITMd me" -- without reading cert phrases and preferably without having to install client certs and somehow build a working PKI.
> One idea we've had is a non-centralized WebRTC service built on distributed hash tables and a partial-mesh set of connections used to pass signaling on WebRTC (or other) data channels to set up calls, with some type of Id system to validate who you get connected to (since you can't really trust any of the nodes fully).  If an intermediary node can downgrade you to SDES and sniff the keys, there is no security.

If you use SDES, no one should be claiming you *have* end-to-end security.  You have security from the browser to the HTTPS server, but nothing more.  The browser shouldn't be showing a lock icon, for example (and it shouldn't for DTLS-SRTP either).  Since the media potentially goes into the PSTN, it can be no more secure than that.  No matter how much stronger we make the Browser-to-Gateway link, the end-to-end can't exceed the PSTN's level of security.  It's reasonably sufficient security for everyday use, but it won't let you bypass the government.  And using DTLS-SRTP to a gateway won't either.  And arguably even using IdP won't if the government can force the IdP to lie.

> An alternative would be to allow a hybrid: SDES at the start of a call and rekey over to DTLS-SRTP after the call is connected.  If something blocks the DTLS connection it would be treated as a gateway-to-legacy/PSTN call (i.e. show no security, though it's secure against non-in-path attackers); if the DTLS connection is allowed, we can use it to rekey to DTLS-SRTP and to verify identity.

Why bother?  I assume the concern is a bid-down.  Let's imagine we were dealing with a malicious website, and the website javascript removed DTLS-SRTP from SDP but put in SDES, so that browser believes it's talking to a gateway and uses SDES.  The malicious website now has your SRTP key and can decrypt your media, assuming it has some access to your media.  So you build a better browser and try an active check for DTLS-SRTP in the media plane regardless of SDP.  If your browser is popular, why wouldn't the malicious website just insert a DTLS-SRTP b2bua gateway, and still be able to listen in?  

As far as I can see, there is no bid-down issue created by adding SDES - it was already there.  It was already possible to insert a DTLS-SRTP B2BUA and be malicious.  Yes, we may have made it slightly cheaper to be malicious, but it was already possible.  The only thing that prevents a malicious website's DTLS-SRTP B2BUA from working is if then humans verify the fingerprints or having an IdP you can trust.  Even if you *do* verify the fingerprints and find they do NOT match, all you know is it went through one or more gateways in the middle - you don't know it's malicious - it could just be going through the PSTN legitimately.

With SDES the browser can indicate right-off-the-bat that the call is not end-to-end secure, without having to show the fingerprint and having the user read it out.

> This minimizes the risk of bid-down - the primary additional risk is that without initial SDES, to tap the signal you'd need to use a WebRTC-enabled B2BUA to accept the DTLS-SRTP connection and siphon it off.  Also, a "good" gateway in a pure DTLS-SRTP world might have a identity established ("[email-masked]"); with SDES it wouldn't by default (but it could if it wanted to by rekeying via DTLS also).  

Yeah I've been trying to figure out if there's some advantage to having a gateway be able to indicate "[email-masked]", once there is an IdP model.  I would think it's a major pita to deploy such a thing on gateways, unless there's a very popular IdP they could know everyone would trust.  It would actually be easier to just give the gateway a real TLS cert for DTLS to use, from a major CA, since gateways are the types of systems real certs would be reasonably possible to install on.

> I'm still strongly in favor of pure DTLS-SRTP - as Harald and others say, less moving parts and less things that need to be secured.  But this might be a useful compromise if we *need* to support SDES in some cases.

I'm trying to be convinced that DTLS-SRTP is worth the complexity, cost and downsides on the gateways, but I haven't found it yet.  I think people are willing to be convinced, myself included, but I have yet to hear a real advantage for DTLS-SRTP in the gateway scenario.  Everything put forward today for DTLS-SRTP applied to the browser-to-browser scenarios, but not gateways.  

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 29 Mar 2012 15:55:55 +0200

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2012 11:59 PM
> To: Dan Wing
> Cc: Richard L. Barnes; Harald Alvestrand; <[email-masked]>
> But more seriously, I don't understand this "foundation" argument.
> We're going to have DTLS-SRTP.  No one's suggesting we don't have DTLS-
> SRTP.  All Browsers MUST implement DTLS-SRTP.  We'll have it for
> Browser-to-Browser, and for Browser-to-Gateway if the Gateway supports
> it.  We'll have the foundation.
> 
> Requiring it for Gateways would make sense if it offered some real
> advantage, or didn't have any disadvantages.  There don't appear to be
> real advantages, while we know of disadvantages.  And gateways have no
> real means of offering an end-to-end identity.  Why would you want to
> build a foundation on air?

Even without any sort of identity at all, DTLS-SRTP provides superior
media security compared with Security Descriptions -- even if one (or 
both) endpoints are gateways to RTP or are gateways to SDESC-SRTP.

-d

---

From: Randell Jesup <[email-masked]>
Date: Thu, 29 Mar 2012 17:56:49 -0400

> If you use SDES, no one should be claiming you *have* end-to-end security.  You have security from the browser to the HTTPS server, but nothing more.  The browser shouldn't be showing a lock icon,…

Total agreement.  SDES cannot be touted as secure.  It's more secure 
against sniffers; that's all.

> Why bother?  I assume the concern is a bid-down.  Let's imagine we were dealing with a malicious website, and the website javascript removed DTLS-SRTP from SDP but put in SDES, so that browser beli…

This allows avoiding a gateway ('burning gateway' argument) with PSTN 
calls while minimizing the risk of bid-down.  Note, correctly, that you 
need Identity+DTLS-SRTP to be secure against in-signaling-path attackers 
(providers or governments).  That's not of no benefit.  It's not of real 
benefit to J. Random Salesman, but even non-political people may worry 
about someone watching in more than they worry about listening in.  
(#include lawsuits over schools using laptop computers to take snapshots 
from student computers at home, etc, etc).

> As far as I can see, there is no bid-down issue created by adding SDES - it was already there.  It was already possible to insert a DTLS-SRTP B2BUA and be malicious.  Yes, we may have made it sligh…

Video doesn't go through the PSTN...  That's a kinda obvious downgrade.  
And only people who care will note the insecurity; part of why it must 
be dead-simple but not overly intrusive (no doorhangers, etc).  This is 
W3C land though, mostly.  This just comes back to the argument over 
whether users care.  Some do, and most of them are non-technical.  
Identity doesn't provide perfect security.  It does provide better 
security and at least makes any tapper be concerned that they're raising 
red flags, if the person notices/cares.  I guarantee the Tunisian 
rebels/activists mentioned by Tim would care.

> With SDES the browser can indicate right-off-the-bat that the call is not end-to-end secure, without having to show the fingerprint and having the user read it out.

True :-)

> I'm trying to be convinced that DTLS-SRTP is worth the complexity, cost and downsides on the gateways, but I haven't found it yet.  I think people are willing to be convinced, myself included, but…

Whereas I come at it from "I care about browser-to-browser cases and 
avoiding doing something that hurts them, and I don't care about 
security (other than sniffers) for gateway calls".  :-)

-- 
Randell Jesup
[email-masked]

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 29 Mar 2012 17:58:13 -0700

Randell Jesup wrote:
>> Everything put forward today for DTLS-SRTP applied to the
>> browser-to-browser scenarios, but not gateways.
>

And the difficulty is, a browser has no way to tell (a priori) when the 
other end is another browser or a gateway.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 30 Mar 2012 09:43:46 +0000

On Mar 30, 2012, at 2:58 AM, Timothy B. Terriberry wrote:

> And the difficulty is, a browser has no way to tell (a priori) when the other end is another browser or a gateway.

You mean before the browser receives an offer/answer?  Obviously it won't, but why does that matter? (I must be missing something obvious)

-hadriel

---

From: Gregory Maxwell <[email-masked]>
Date: Fri, 30 Mar 2012 08:37:57 -0700

Randell Jesup [[email-masked]] wrote:
> That's not of no benefit. It's not of real

A point which needs to be emphasized is that undetectable attacks are
not at all the same thing as detectable attacks: Even when the chance
of detection is somewhat low, if the cost of detection is high the
possibility of it can be an effective deterrent.

Assuming 'hardcoded' ephemeral key agreement, Users Comparing
Tools->PageInfo->Media->session fingerprint — especially if documented
as a best practice in HowToBeParanoid documents— would be likely to
detect network level mass interception, even if the chance of detection
on a case by case is very low.  This makes the development and deployment
of _covert_ mass surveillance/censorship infrastructure, the sort with
the greatest negative human rights value, less attractive from a cost
benefit perspective.

(Of course, it does nothing for non-secret monitoring— but when the
monitoring is not secret the users of protcol have the most important
information they need in order to make an informed choice about how
they communicate, what public policies they live under, who they have
providing their network services, etc)

In computer and cryptographic security we're often concerned with absolute
protection. This is because absolute security is often achievable in this
area,  a luxury few other kinds of security have. But where absolute
security can't be provided (e.g. we _can't_ prevent MITM without hard to
provide and often missing identity service), relative security still has
value. When considering the real world context of attacks always being
a cost benefit trade-off the removal of nearly-undetectable attacks is as
an enormous relative improvement as is the removal of passive sniffing.