Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 02:17:42 -0400

Well gee that doesn't sound like too hard a choice set to choose from, though I guess it depends on whether there's a requirement/desire to interop with existing VoIP devices and the PSTN, or not.

If we don't expect/desire RTCWEB clients to communicate with existing VoIP devices or PSTN, then sure we can start with a clean slate.  In fact, you could also create a whole new version of SIP for inter-server, since there's no need to use SIP v2.0 between RTCWEB domains and we've learned things we could have done better, and for a pure inter-domain server-to-server signaling protocol it could be a lot simpler. 

But anyway... with regards to your alternatives below, you seem to imply that using DTLS-SRTP is by itself "secure", such that the UI could display a lock-icon for example.  I was under the impression that DTLS-SRTP provided no guarantee of anything without the humans on both ends verifying they're using the same keying material/SAS/etc.  Is that not the case? (okay yes it requires being a MitM to subvert, but that's not a high enough bar to claim anything)

Assuming that's true, and given how few humans would actually know to perform manual verification of dtls-srtp, I think this topic isn't as cut-and-dried as choosing between "secure" vs. "insecure".  Both alternatives are capable of being secure or insecure, and it's up to the human to do something to figure it out in either case.  There is no real alternative which is inherently "secure", afaict.

-hadriel

Recently EKR wrote:
> This is very late, but here is my attempted summary of the discussion
> about COMSEC choices at the interim. I'm not saying that this captures
> everyone's position, but the following positions are the ones that in
> my view have significant levels of support.
> 
> 
> Alternative A: [DTLS MUST, NO SDES, NO RTP]
> 
>    An RTC-Web client MUST support DTLS-SRTP and ONLY DTLS-SRTP for
>    media, without support for either SRTP with supplied keying
>    material (SDES-style) AND plain RTP. DTLS-SRTP provides for
>    end-to-end key negotation between the two RTCWEB clients. The
>    client MUST support the SRTP_AES128_CM_HMAC_SHA1_80 protection
>    profile and the DTLS cipher suite
>    TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement
>    differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA
>    in that it mandates support for Diffie-Hellman key exchange in
>    order to provide Perfect Forward Secrecy.
> 
>    An RTCWEB client MUST provide its user with the ability to to see
>    keying material information sufficient to allow indepent
>    verification of their peer's identity.  (REF
>    draft-kaufman-rtcweb-security-ui).
> 
>    The primary drawback of this alternative is the lack of backwards
>    compatibility with devices and software that only support plain
>    RTP, but the requirement for a handshake makes interoperation with
>    these devices not completely trivial anyway.
> 
> 
> 
> Alternative B: [DTLS-SRTP MUST, SDES MAY, RTP MUST]
> 
>    An RTC-Web client MUST support DTLS-SRTP for media. DTLS-SRTP
>    provides for end-to-end key negotation between the two RTCWEB
>    clients.  The client MUST support the SRTP_AES128_CM_HMAC_SHA1_80
>    protection profile and the DTLS cipher suite
>    TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Note that this requirement
>    differs from the current TLS default, TLS_RSA_WITH_AES_128_CBC_SHA
>    in that it mandates support for Diffie-Hellman key exchange in
>    order to provide Perfect Forward Secrecy. This MUST be the default
>    mode of operation.
> 
>    An RTCWEB client MAY support SRTP with the keying material supplied
>    via the signaling channel with the SRTP_AES128_CM_HMAC_SHA1_80
>    protection profile.  In the case of a web browser client, the
>    keying material should be supplied via a Javascript API.
>    DTLS-SRTP, with its end-to-end keying and authentication capability
>    is preferred over SDES-style [RFC4568] keying.  However, the
>    additional API overhead required to add support for a way to force
>    a particular key is low.  In addition, once plain RTP is to be
>    supported the arguments against the lower security level provided
>    by SDES-style keying are no longer relevant.  Also there are a
>    small number of potential use cases where interoperability with
>    existing SDES-keyed software or devices may be achieved if the
>    RTCWEB endpoint supports this mode of keying.
> 
>    An RTCWEB client MUST support RTP.  This provides no privacy but
>    maximizes interoperability.  Note that SRTP with a Null cipher has
>    equivalent security but does not meet the interoperability
>    requirement.  Plain RTP provides no protection for the media, and
>    so is discouraged as a mode of operation for RTCWEB.  However,
>    support for RTP is required in order to provide interoperability
>    with legacy RTP devices and software that do not support
>    encryption.  In addition, some use cases such as high-volume PSTN
>    or PBX gateways within an organization may scale more readily
>    without the overhead of media encryption.
> 
>    An RTCWEB client MUST provide its user with the ability to know
>    whether or not the media they are sending is protected by encryption
>    and with the ability to see keying material information sufficient
>    to allow indepent verification of their peer's identity.
>    (REF draft-kaufman-rtcweb-security-ui). Note that this user
>    interface element is much more critical---and hence much more
>    problematic than with alternative A. If DTLS-SRTP is always
>    used, then the user knows what security mechanisms are provided.
>    As soon as multiple alternatives with widely varying security
>    (or no security in the case of RTP) are provided, then users
>    need to actually verify that the security level is satisfactory,
>    which is inherently problematic given typical user behavior.
> 
> I expect to leave time for discussion of this during my slot tomorrow.
> I look forward to a good discussion.
> 
> Best,
> -Ekr
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 28 Jul 2011 03:48:20 -0700

Agree that the "clean slate" approach is not very appealing.  "Since we require ICE, we can also require X, Y, Z" is flawed logic, not only from a deployment/interoperability point of view, but also from a regulatory point of view.  The definitions of interconnected/non-interconnected VOIP and the associated regulatory requirements do not have a browser exemption. 

> From: [email-masked]
> To: [email-masked]
> Date: Thu, 28 Jul 2011 02:17:42 -0400
> Subject: Re: [rtcweb] Retransmit: Summary of Alternatives for media keying
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 07:52:50 -0400

> Well gee that doesn't sound like too hard a choice set to choose from, though I guess it depends on whether there's a requirement/desire to interop with existing VoIP devices and the PSTN, or not.

There is a requirement to interop with existing VoIP devices and the PSTN, however other requirements (like ICE for consent to send media) will impose additional requirements that limit which existing VoIP devices are or can be made compatible.

> 
> If we don't expect/desire RTCWEB clients to communicate with existing VoIP devices or PSTN, then sure we can start with a clean slate.

There is a desire for the media to be transported in RTP for a variety of reasons, including the ability to easily terminate the traffic in PSTN gateways, reuse of existing RTP stacks for building both browsers and interoperable devices, and middlebox awareness of what the traffic might be.

>  In fact, you could also create a whole new version of SIP for inter-server, since there's no need to use SIP v2.0 between RTCWEB domains and we've learned things we could have done better, and for a pure inter-domain server-to-server signaling protocol it could be a lot simpler. 
> 

You could. In fact, for inter-domain federation you are probably free to use whatever you and the other domain agree to use.

However, again for software reuse reasons, you're likely to pick SIP.

> But anyway... with regards to your alternatives below, you seem to imply that using DTLS-SRTP is by itself "secure", such that the UI could display a lock-icon for example.  I was under the impress…

Plain RTP - can be intercepted by both MitM attackers and passive observers. No perfect forward secrecy (in fact, no secrecy at all). 

SRTP w/SDES-style keying - both MitM attackers and passive observers can record the traffic but not play it out until they obtain key. The key is provided by the server and is likely recorded in server logs. Protection of the key on the wire requires HTTPS or similar signaling. Impossible to provide perfect forward secrecy.

DTLS-SRTP (or any other end-to-end keying) - assuming the use of DH key agreement, both MitM attackers and passive observers can record the traffic, however ONLY MitM attackers are able to participate in the key agreement algorithm, and so ONLY MitM attackers would ever be able to play out the contents. The key agreement occurs between the two endpoints (assuming no MitM attacker, of course) and is not recorded anywhere else and is not available to the signaling server. Provides perfect forward secrecy. MitM attacks be avoided if you trust the signaling service and exchange fingerprints between the two ends for authentication OR if you use a user interface that lets you examine the fingerprints and verify them out-of-band OR if you use additional software that you trust (along with a 3rd party that you trust) to examine the fingerprints automatically and alert you in the case of mismatch.

All of these statements of course only apply between you and whatever is terminating the session. If it is a gateway to another protocol, the security provided stops at that point and is only continued if the far end of the gateway is also secure *and* you trust both that security and the gateway.

> Assuming that's true, and given how few humans would actually know to perform manual verification of dtls-srtp, I think this topic isn't as cut-and-dried as choosing between "secure" vs. "insecure"…

There are gradations of security that are provided by default, depending on the choices made.

If the browser is able to send plain RTP at all, then you need a way for the user to tell if it is sending plain RTP or encrypted RTP. If it can only send encrypted RTP, then this requirement goes away. For some threat models (for instance passive observers watching your unencrypted wifi traffic), any encryption at all is better than plain RTP. For others (passive observers that can record the traffic and also have future access to the server logs), encryption + end-to-end keying is far superior to any of the other choices.

But, like all security arguments, you are correct. It is never black and white, so you can never say "this is secure". But you can certainly say "this ISN'T secure" for some of them (like plain RTP, or even the ability for the browser to switch you from SRTP to RTP without making it clear to the user).

Think of the threat models you are likely to experience yourself... then tell me which level of protection YOU want.

Matthew Kaufman

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Jul 2011 14:04:10 +0200

> But anyway... with regards to your alternatives below, you 
> seem to imply that using DTLS-SRTP is by itself "secure", 
> such that the UI could display a lock-icon for example.  I 
> was under the impression that DTLS-SRTP provided no guarantee 
> of anything without the humans on both ends verifying they're 
> using the same keying material/SAS/etc.  Is that not the 
> case? (okay yes it requires being a MitM to subvert, but 
> that's not a high enough bar to claim anything)
> 
> Assuming that's true, and given how few humans would actually 
> know to perform manual verification of dtls-srtp, I think 
> this topic isn't as cut-and-dried as choosing between 
> "secure" vs. "insecure".  Both alternatives are capable of 
> being secure or insecure, and it's up to the human to do 
> something to figure it out in either case.  There is no real 
> alternative which is inherently "secure", afaict.
[JRE] I agree with Hadriel's concern. DTLS-SRTP itself, if using only self-signed certs at the endpoints, requires other means (signalling path or human-assisted) to  provide strong guarantees that you are talking to the person or organization you expect. For SIP, the (theoretical) solution is to send a fingerprint of the certificate and have that bound to authenticated identity in accordance with RFC 4474, although not feasible in most deployed SIP environments. Although RTC-Web is not specifying signalling, clearly it needs to say something about the problem, and can't just indicate to the user that communication is secure just because DTLS-SRTP is used.

Secondly, if interworking with legacy SIP, where DTLS-SRTP (or whatever we select) is terminated at a gateway, there is a real problem ensuring that the user knows the call is not necessarily secure end-to-end. Perhaps this argues towards option B, since if DTLS-SRTP is not used from browser to gateway, at least the browser should know to indicate a lesser level of security to the user.

The whole issue of the browser knowing what it can tell the user concerning the security posture of a communication is a really difficult problem.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 08:25:14 -0400

On Jul 28, 2011, at 8:04 AM, Elwell, John wrote:

> [JRE] I agree with Hadriel's concern. DTLS-SRTP itself, if using only self-signed certs at the endpoints, requires other means (signalling path or human-assisted) to  provide strong guarantees that you are talking to the person or organization you expect.

Agreed.

However there are weaker guarantees of properties that are certainly favorable as compared to, for instance, plain RTP or even server-keyed SRTP. (See my previous email.)

> For SIP, the (theoretical) solution is to send a fingerprint of the certificate and have that bound to authenticated identity in accordance with RFC 4474, although not feasible in most deployed SIP environments. Although RTC-Web is not specifying signalling, clearly it needs to say something about the problem, and can't just indicate to the user that communication is secure just because DTLS-SRTP is used.

Correct.

> Secondly, if interworking with legacy SIP, where DTLS-SRTP (or whatever we select) is terminated at a gateway, there is a real problem ensuring that the user knows the call is not necessarily secur…

If you are sitting in an Internet cafe using someone else's unencrypted wifi and a telephony service provider you trust would you rather 1) use DTLS-SRTP between you and the telephony provider and plain RTP past their gateway inside their internal network, or 2) use plain RTP on the wifi network and all the way to the telephony provider?

I agree that we can't display "this connection is secured everywhere" to the user... but look, HTTPS is the same. When I see a lock icon on my screen and click to see that yes, I'm really talking to who it says in the address bar, I still can't tell if they're terminating my HTTPS session in a front-end box and then using HTTP beyond it, or if the HTTPS really goes all the way to the server. And when I use HTTPS to talk to Gmail, there's no way to tell if an email I send will be sent over a TLS channel or if it'll just be plain SMTP from Gmail to my recipient.

> The whole issue of the browser knowing what it can tell the user concerning the security posture of a communication is a really difficult problem.

It isn't a difficult problem if what the user is told is confined to what is provably true. (See my previous Gmail example.)

Matthew Kaufman

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 11:13:53 -0400

> If you are sitting in an Internet cafe using someone else's unencrypted wifi and a telephony service provider you trust would you rather 1) use DTLS-SRTP between you and the telephony provider and…

I would be perfectly happy with using sdes-based SRTP.  But if the call would otherwise fail altogether, I'd like the option to make the call no matter what (ie, even if it ends up being cleartext).

(And since you're sitting in an Internet cafe in hearing distance of everyone, any sense of privacy is gone anyway. ;)

> I agree that we can't display "this connection is secured everywhere" to the user... but look, HTTPS is the same. When I see a lock icon on my screen and click to see that yes, I'm really talking to who it says in the address bar, I still can't tell if they're terminating my HTTPS session in a front-end box and then using HTTP beyond it, or if the HTTPS really goes all the way to the server.

But the browser ties the identity of the name I typed in the address bar to the cert, so that if I typed "https://mybank.com", I know it's secure to mybank.com.  Of course it could be cleartext after whomever has a cert for mybank.com, and may even end up triggering protocols that exit mybank.com and go to evil.com, but I implicitly trust mybank.com to be careful with bank info.  That's not the same for DTLS-SRTP; until and unless the human being verifies the keys/SAS with the far end, nothing is known.  The DTLS-SRTP may only reach the NAT-router in the Internet Cafe, for example, be terminated by it and a separate DTLS-SRTP between it and the bank.  And if I'm talking to an IVR system (as one frequently does with banks), there is no human to verify the keys/SAS with.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 13:18:52 -0400

> I would be perfectly happy with using sdes-based SRTP.  But if the call would otherwise fail altogether, I'd like the option to make the call no matter what (ie, even if it ends up being cleartext).

Why would the call "otherwise fail altogether"?

> (And since you're sitting in an Internet cafe in hearing distance of everyone, any sense of privacy is gone anyway. ;)

Have you ever called into a conference call from a public place, with your microphone muted?

> But the browser ties the identity of the name I typed in the address bar to the cert, so that if I typed "https://mybank.com", I know it's secure to mybank.com.  Of course it could be cleartext after whomever has a cert for mybank.com, and may even end up triggering protocols that exit mybank.com and go to evil.com, but I implicitly trust mybank.com to be careful with bank info.  

Ok, so you trust your "banking service".

> That's not the same for DTLS-SRTP; until and unless the human being verifies the keys/SAS with the far end, nothing is known.

If you trust your "calling service" (and are connected to it with HTTPS) then you can use that trusted service to exchange the fingerprints and verify the keys of the far end to prevent MITM.

(You can also add a browser extension that uses a service that you trust but that isn't your calling service, and when you're calling other people with the same extension you can check the fingerprints in an automated way using that.)

If you *don't* trust your "calling service", then that's just like not trusting your banking service when you type in passwords.

>  The DTLS-SRTP may only reach the NAT-router in the Internet Cafe, for example, be terminated by it and a separate DTLS-SRTP between it and the bank.  And if I'm talking to an IVR system (as one frequently does with banks), there is no human to verify the keys/SAS with.

Correct. But there is a signaling channel, and if you trust it you can assure that there is no router doing MITM at the cafe. Perhaps you'll even be calling your bank's IVR using *their* calling service...

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Jul 2011 13:22:05 -0400

Question that I could probably answer if I understood the DH key 
exchange thing:

Is it possible for anyone with packet-replacement access to the media 
path to perform a MITM attack against DH?

If so: Is it possible to deliver some token by the "high path" (where 
the SDES keys would go) that ensures that the DH key exchange is with 
someone possessing that token?

That would limit MITM attacks to attackers who had access to both the 
"high path" and the media path.

                                Harald

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Jul 2011 13:27:54 -0400

That's effectively what DTLS-SRTP does.

-Ekr

On Thu, Jul 28, 2011 at 1:22 PM, Harald Alvestrand <[email-masked]> wrote:
> Question that I could probably answer if I understood the DH key exchange
> thing:
>
> Is it possible for anyone with packet-replacement access to the media path
> to perform a MITM attack against DH?
>
> If so: Is it possible to deliver some token by the "high path" (where the
> SDES keys would go) that ensures that the DH key exchange is with someone
> possessing that token?
>
> That would limit MITM attacks to attackers who had access to both the "high
> path" and the media path.
>
>                               Harald
>

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 28 Jul 2011 13:32:17 -0400

On Jul 28, 2011, at 1:22 PM, Harald Alvestrand wrote:

> Question that I could probably answer if I understood the DH key exchange thing:
> 
> Is it possible for anyone with packet-replacement access to the media path to perform a MITM attack against DH?

Yes.

> 
> If so: Is it possible to deliver some token by the "high path" (where the SDES keys would go) that ensures that the DH key exchange is with someone possessing that token?

You can do that, or you can check the fingerprints via the high path to authenticate each end and prove that there's no MITM on the media path.

> 
> That would limit MITM attacks to attackers who had access to both the "high path" and the media path.
> 

Correct. And the high path can be protected with HTTPS and the associated PKI.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Thu, 28 Jul 2011 17:54:51 -0400

On 7/28/2011 1:18 PM, Matthew Kaufman wrote:
>   we can't display "this connection is secured everywhere" to the user... but look, HTTPS is the same. When I see a lock icon on my screen and click to see that yes, I'm really talking to who it says in the address bar, I still can't tell if they're terminating my HTTPS session in a front-end box and then using HTTP beyond it, or if the HTTPS really goes all the way to the server.

And more to the point, you trust the chain of certificates incorporated 
into the browser to verify it's actually the entity that owns mybank.com 
(and EV certs come into play here too).  Overall, that's a "good" chain 
of trust, though no such chain is perfect.

> If you trust your "calling service" (and are connected to it with HTTPS) then you can use that trusted service to exchange the fingerprints and verify the keys of the far end to prevent MITM.

Right, this is trusting that not only they are who they say they are, 
but also trusting that they haven't been compromised.   And one may not 
have the same level of trust in that that you have (have to have) in 
your bank.

> (You can also add a browser extension that uses a service that you trust but that isn't your calling service, and when you're calling other people with the same extension you can check the fingerpr…

Definitely possible, and adds another largely-independent layer of trust.

> If you *don't* trust your "calling service", then that's just like not trusting your banking service when you type in passwords.

I may trust my calling service to connect me (to someone), but I may not 
trust them to not MITM me themselves (read CALEA or other national 
security services), and I may not trust them not to be compromised, 
since they have a far smaller monetary stake in avoiding it compared to 
a bank.

Another idea related to identity: as mentioned, the cert trust chain in 
a browser verifies that you're talking to mybank.com or myprovider.com.  
This can be leveraged to provide authentication by cert that you're 
talking to someone who's part of mybank.com, even if you went through 
myprovider.com to get there and myprovider.com might be compromised.  It 
doesn't directly help verify you're talking to Joe Your Neighbor, but 
other services can help with that (as mentioned - extensions, etc).

Effectively, for a fairly large subset of the net, we have a deployed 
PKI of a form.  It's not perfect (DNSSEC anyone; recent todo with bogus 
certs because a CA snafu) but for most uses that it covers it's pretty 
good.  Getting it to cover identifying the destination as a dependent of 
the primary cert may be an issue for many companies, however.

In any case, there may be a way to leverage this existing trust chain, 
both to authenticate who's calling you and who you're calling, for a 
subset of possible destinations.

-- 
Randell Jesup
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Thu, 28 Jul 2011 18:15:42 -0400

On 7/28/2011 5:54 PM, Randell Jesup wrote:
>> (You can also add a browser extension that uses a service that you 
>> trust but that isn't your calling service, and when you're calling 
>> other people with the same extension you can check the fingerprints 
>> in an automated way using that.)
>

Replying to myself with something the Mozilla team was thinking about 
(we may come
back with more on this later, after talking to the people here about 
it):  an example of an
independent layer of identity trust would be the just-announced 
BrowserID initiative:

https://browserid.org/

The plan is to move this into the browser itself.

Also see 
http://identity.mozilla.com/post/7616727542/introducing-browserid-a-better-way-to-sign-in

Perhaps the browserid data could be used to facilitate authentication of 
SAS data, for example.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 18:33:25 -0400

> You can do that, or you can check the fingerprints via the high path to authenticate each end and prove that there's no MITM on the media path.

That's assuming the high path itself is secure end-to-end.  Since this group has already agreed to allow HTTP rather than mandate HTTPS, and since it can go from your web service to SIP and beyond, such a guarantee is hard to enforce.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Jul 2011 18:44:40 -0400

> Why would the call "otherwise fail altogether"?

Because I'm calling someone who has a legacy VoIP device or is on the PSTN, and they're not going to support DTLS-SRTP.
Of course we could require the RTCWEB service to deploy "gateways" in order to terminate DTLS-SRTP and do SDES-based SRTP or cleartext RTP to non-RTCWEB, but that's expensive and complex.  Not to mention its mis-leading - the media is not secure end-to-end, and again the lock-icon model won't work.

> Have you ever called into a conference call from a public place, with your microphone muted?

Nah, I talk too much.  ;)

-hadriel
p.s. Of course I'm speaking as an individual - my employer would probably be ecstatic with requiring such gateways.

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 29 Jul 2011 01:12:52 -0400

On Jul 28, 2011, at 5:54 PM, Randell Jesup wrote:

> And more to the point, you trust the chain of certificates incorporated into the browser to verify it's actually the entity that owns mybank.com (and EV certs come into play here too).  Overall, that's a "good" chain of trust, though no such chain is perfect.

It appears to be "good enough" for people to do banking using their web browser, which is pretty amazing if you think about it.

> Right, this is trusting that not only they are who they say they are, but also trusting that they haven't been compromised.   And one may not have the same level of trust in that that you have (have to have) in your bank.

I'm not sure how this is any different from any other type of calling scenario.

You always need to trust the person at the far end to not reveal the call, and trust the equipment they (and you) are using.

> Definitely possible, and adds another largely-independent layer of trust.

Yes, but independent layers of trust are a feature, not a bug.

And what are you arguing here? My claim is that DTLS-SRTP is often *more* secure than SDES-style keying, and certainly no worse.

This is one of the things that backs up my claim. I still haven't heard why SDES or plain RTP would be superior from a security point of view.

> I may trust my calling service to connect me (to someone), but I may not trust them to not MITM me themselves (read CALEA or other national security services), and I may not trust them not to be compromised, since they have a far smaller monetary stake in avoiding it compared to a bank.

Sure, but again all of these things are EASIER if they use SDES. They can MITM you themselves by letting anyone get a copy of the traffic from anywhere and sending that person the keys, even after the fact. (Both passive attacks like this and getting the key later are prevented with DTLS-SRTP and DH key agreement).

> 
> Another idea related to identity: as mentioned, the cert trust chain in a browser verifies that you're talking to mybank.com or myprovider.com.  This can be leveraged to provide authentication by cert that you're talking to someone who's part of mybank.com, even if you went through myprovider.com to get there and myprovider.com might be compromised.  It doesn't directly help verify you're talking to Joe Your Neighbor, but other services can help with that (as mentioned - extensions, etc).

Yes, all good ideas, but built upon DTLS-SRTP, and not SDES or plain RTP.

> 
> Effectively, for a fairly large subset of the net, we have a deployed PKI of a form.  It's not perfect (DNSSEC anyone; recent todo with bogus certs because a CA snafu) but for most uses that it covers it's pretty good.  Getting it to cover identifying the destination as a dependent of the primary cert may be an issue for many companies, however.

I doubt it, but perhaps.

> 
> In any case, there may be a way to leverage this existing trust chain, both to authenticate who's calling you and who you're calling, for a subset of possible destinations.

Almost certainly.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 29 Jul 2011 01:14:35 -0400

> That's assuming the high path itself is secure end-to-end.  Since this group has already agreed to allow HTTP rather than mandate HTTPS, and since it can go from your web service to SIP and beyond,…

I don't believe we had complete consensus to allow HTTP rather than HTTPS... and of course you are free to not use calling services that aren't using HTTPS, just as you're free to not use web-based email providers or web-based social networking sites that don't require the use of HTTPS.

The guarantee of what happens beyond the service is difficult. The guarantee of what happens within the service goes as far as you can trust the service.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 29 Jul 2011 01:17:43 -0400

> Because I'm calling someone who has a legacy VoIP device or is on the PSTN, and they're not going to support DTLS-SRTP.

I'm confused... do you want maximum security (because DTLS-SRTP is probably the best path to that of the choices) or maximum interoperation with legacy (because plain RTP is probably the easiest way to get that)

> Of course we could require the RTCWEB service to deploy "gateways" in order to terminate DTLS-SRTP and do SDES-based SRTP or cleartext RTP to non-RTCWEB, but that's expensive and complex.

Expensive? Maybe. Complex? Not really.

>  Not to mention its mis-leading - the media is not secure end-to-end, and again the lock-icon model won't work.

The lock icon model works just as well as the lock icon works on Gmail to indicate that your interaction with Gmail is protected but the email you send might be going via plain SMTP.

It might even be better than this, if we do a good job of sending requirements to W3C.

>> Have you ever called into a conference call from a public place, with your microphone muted?

Even so, you'd probably rather not be recorded by a 3rd party using the microphone in your headset if you can avoid it.

Matthew Kaufman

---

From: Randell Jesup <[email-masked]>
Date: Fri, 29 Jul 2011 08:59:47 -0400

> And what are you arguing here? My claim is that DTLS-SRTP is often *more* secure than SDES-style keying, and certainly no worse.

No disagreement at all.   I'm discussing that DTLS-SRTP is vulnerable 
(to a degree) to MITM
attacks, which is well-known, if you don't have a known-secure signaling 
channel.  I'm not making the
argument that Hadriel is.

> Sure, but again all of these things are EASIER if they use SDES. They can MITM you themselves by letting anyone get a copy of the traffic from anywhere and sending that person the keys, even after…

Absolutely.

> Yes, all good ideas, but built upon DTLS-SRTP, and not SDES or plain RTP.

Yes, that's the idea.

>> Effectively, for a fairly large subset of the net, we have a deployed PKI of a form.  It's not perfect (DNSSEC anyone; recent todo with bogus certs because a CA snafu) but for most uses that it co…

My concern was getting companies to deploy subsidiary certs to the 
browsers of call center agents, etc
(especially as these functions are often out-sourced).

>> In any case, there may be a way to leverage this existing trust chain, both to authenticate who's calling you and who you're calling, for a subset of possible destinations.

Good!

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Jul 2011 10:17:57 -0400

> argument that Hadriel is.

But that *is* the argument I was making. (or at least trying to :)  
I certainly wasn't claiming SDES nor RTP are as secure as DTLS-SRTP could be.

What I said to start this whole thing was: the two alternatives should not be described as choosing between secure and insecure.  BOTH alternatives require the user to verify something for the call to be secure.  BOTH alternatives have the potential to be very secure.  That is all.

BTW, I am assuming of course that even if we choose the alternative of DTLS+SDES+RTP, that DTLS would always be preferred, and if the peer cannot do it then SDES, and if the peer can't do that then RTP. (assuming the human has set whatever browser knobs are necessary to enable/disable this stuff)
So between two RTCWEB browsers it would always be DTLS-SRTP.

-hadriel

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 29 Jul 2011 10:30:35 -0400

> I certainly wasn't claiming SDES nor RTP are as secure as DTLS-SRTP could be.

We agree here.

> What I said to start this whole thing was: the two alternatives should not be described as choosing between secure and insecure.  BOTH alternatives require the user to verify something for the call…

I suppose that depends on what you mean by "the potential to be very secure"... certainly plain RTP *might* be secure, if it never leaves your desktop.

DTLS-SRTP + a security inspection UI gives the user a way to verify something *independently of the service provider* to see if the call is secure. SDES does not. The only way to be sure the service provider isn't colluding with someone to tap your call when you use SDES is to agree with the other party to mangle the key you receive from the service provider. (The "pessimist" approach to trust in this environment.)

> BTW, I am assuming of course that even if we choose the alternative of DTLS+SDES+RTP, that DTLS would always be preferred, and if the peer cannot do it then SDES, and if the peer can't do that then…

Agree. Though the human needs to be able to see a lot more about what is going on if we allow all three.

> So between two RTCWEB browsers it would always be DTLS-SRTP.

Agree.

Matthew Kaufman

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 29 Jul 2011 10:52:53 -0400

> I suppose that depends on what you mean by "the potential to be very secure"... certainly plain RTP *might* be secure, if it never leaves your desktop.

Yeah I should have clarified.  I meant since the alternative of DTLS+SDES+RTP includes DTLS-SRTP, and the human can verify it, and I assume DTLS-SRTP would always be preferred... then it has the potential to be very secure. (namely if DTLS-SRTP is used and the human verifies it)

In other words, both Alternative A and B have the ability to use DTLS-SRTP in the same way.  The only difference is Alternative A (DTLS only) would fail if trying to talk to someone who can't do DTLS-SRTP.  Alternative B would still succeed in letting people talk.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Fri, 29 Jul 2011 11:06:40 -0400

> DTLS-SRTP + a security inspection UI gives the user a way to verify something *independently of the service provider* to see if the call is secure. SDES does not. The only way to be sure the servic…
This is where there's an opening for browser extensions, potentially (mangling
the agreed-to-by-protocol keys, such as by using a pre-shared secret) - though that
would require some level of external interaction with the keying from JS/etc code.
That may be worth exposing to the W3/JS layer, perhaps.  (Should the JS layer have access
to the keys?  Be able to modify them (per above)?  Security implications?  What if it
wants to implement an "answering-machine" function via recording packets for later
replay?  Or will it have  access to decoded packets,  or will it only have access
to decoded media and have to re-encode it for "answering-machine" use?)

If the user and the person they're talking to has the option of using an extension
(or the app) to modify the keys at both ends, that allows for perfect(*) security via
pre-shared secrets of whatever form.

* Nothing is perfect

> Agree. Though the human needs to be able to see a lot more about what is going on if we allow all three.

Mostly that the user be allowed to see it, and that if one does put up 
any sort of Lock icon it would
only be for the "most" secure.  (Though this is a security-UI issue, not 
a technical one.)  You could
even not put up anything about the security level unless the protocol 
detected an attack or unless
the user's 3rd-party  verification tool agreed it was secure by some 
independent channel.

>> So between two RTCWEB browsers it would always be DTLS-SRTP.
Ditto

-- 
Randell Jesup
[email-masked]