Subject: [rtcweb] SRTP and PFS

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Feb 2012 21:59:23 +0000

Howdy,
A comment made today at the interim meeting was that DTLS-SRTP provided Perfect Forward Secrecy (PFS), whereas SDES does not.  I believe this was meant as (1) even if the long-term DTLS key of Alice were to be learned in the future, that a previous call between Alice and Bob could not be decrypted, and (2) that the web-server does not see the keys and thus compromising such things as the web-server logs does not compromise previous call content.

Since the topic came up with regard to comparison of DTLS-SRTP vs. SDES in the context of interworking with non-WebRTC environments, I would point out that using DTLS-SRTP in such environments does not provide PFS either.  If an interworking gateway is required, then even if it does DTLS-SRTP, both of the encrypt/decrypt keys for SRTP for each call are known to the interworking gateway and it will likely log them.  Thus if the interworking gateway's logs are compromised, any/all previous calls to/from it can be decrypted.

-hadriel

---

From: Alan Johnston <[email-masked]>
Date: Wed, 1 Feb 2012 16:12:05 -0600

Hadriel,

Two points about this.  The scenario of a gateway having access to the
key is not exactly comparable with every web server in the path in
addition to the gateway.  Also, key destruction when a session ends is
part of a key management protocol - if the gateway implements the key
management, then it will do this.  On the other hand, deletion of SDES
keys by any web server that handles it is not part of any standard,
nor is it practical.

So I believe there is a difference, even when there is a gateway.
When there isn't a gateway, there is an even bigger difference.

- Alan -

On Wed, Feb 1, 2012 at 3:59 PM, Hadriel Kaplan <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 1 Feb 2012 14:49:39 -0800

It seems to me that the SDES discussion (and also the SRTP vs. RTP discussion) is really about requirements arising from legacy interop scenarios. 

How about reposing the question as follows:

"If we accept the legacy interop use cases, what are the implications for protocol support?"

As Hadriel pointed out, the entire body of legacy systems is not really relevant to this question, only those legacy systems which an RTCWEB browser would need to interoperate with. 

If reposed this way, the question may be amenable to data-based responses along various dimensions.  For example, one could ask what fraction of the "public facing legacy systems" implement:

SRTP vs. RTP-only  (we talked about this today)
Various codecs (I suspect that G.711 is 100%, but there may be others worth looking at)
(S)AVP vs. (S)AVPF
Various SDP extensions (such as RFC 5939)

As was noted, it's likely that the fraction of legacy system implementing ICE is very low, so we can assume that a gateway is needed for that.

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Feb 2012 15:11:32 -0800

> Various codecs (I suspect that G.711 is 100%, but there may be others worth looking at)

IIRC there are some PSTN terminations (mostly in 3rd-world countries) 
which only allow G.729.  We could decide to not care.  Overall I doubt 
it's a major portion of the traffic, but it's non-zero.  And G.729 is 
not something Mozilla is likely to ship.

> As was noted, it's likely that the fraction of legacy system implementing ICE is very low, so we can assume that a gateway is needed for that.

Doesn't this invoke the consent issue?  If that's the case, unless we 
expect that to change significantly, we'll be talking to gateways in 
most cases.  So the question is down to the complexity/cost of the gateway.

-- 
Randell Jesup
[email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 1 Feb 2012 23:36:55 +0000

On Feb 1, 2012, at 5:12 PM, Alan Johnston wrote:

> management, then it will do this.  

I'm not sure I understand what you mean - there's nothing built into the DTLS-SRTP protocol that auto-magically deletes the generated SRTP keys from local logs.  And if the interworking gateway does SIPREC or CALEA, it might even export those keys off-box. (although generally they just mirror the RTP post-decrypt/pre-encrypt, afaict)

> On the other hand, deletion of SDES

Right, but I'm not claiming SDES has PFS - I'm only stating that DTLS-SRTP does not either.

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Feb 2012 16:25:41 -0800

> I'm not sure I understand what you mean - there's nothing built into the DTLS-SRTP protocol that auto-magically deletes the generated SRTP keys from local logs.  And if the interworking gateway doe…

True, but this isn't an aspect of DTLS-SRTP as a protocol; this is an 
endpoint issue.

> Right, but I'm not claiming SDES has PFS - I'm only stating that DTLS-SRTP does not either.

I'd rephrase that as "if you don't trust the other endpoint, no protocol 
can give PFS (or any security against that endpoint), only security 
against intermediate attackers".

-- 
Randell Jesup
[email-masked]

---

From: Alan Johnston <[email-masked]>
Date: Wed, 1 Feb 2012 19:21:58 -0600

Hadriel,

See below.

- Alan -

On Wed, Feb 1, 2012 at 6:25 PM, Randell Jesup <[email-masked]> wrote:
>> I'm not sure I understand what you mean - there's nothing built into the
>> DTLS-SRTP protocol that auto-magically deletes the generated SRTP keys from
>> local logs.

Interesting - I did a quick search and you may be right.  Perhaps Ekr
can comment on this.

For an example of how this should be done, see

  http://tools.ietf.org/html/rfc6189#section-4.7.3

  And if the interworking gateway does SIPREC or CALEA, it might
>> even export those keys off-box. (although generally they just mirror the RTP
>> post-decrypt/pre-encrypt, afaict)

In that case, I don't care what it does with the keys as long as they
are treated and handled as cryptographic material.

I don't think that your average web server run by your average ISP has
any notion how keying material should be handled - nor should they
need to.

> I'd rephrase that as "if you don't trust the other endpoint, no protocol can
> give PFS (or any security against that endpoint), only security against
> intermediate attackers".
>
> --
> Randell Jesup
> [email-masked]
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Feb 2012 17:28:28 -0800

> Interesting - I did a quick search and you may be right.  Perhaps Ekr

I think this is mostly a stylistic issue. I.e., TLS just doesn't give a lot
of implementation advice and neither does DTLS and DTLS-SRTP.

>  http://tools.ietf.org/html/rfc6189#section-4.7.3

I'd be happy to add appropriate text to the arch document. I'll put it on
my TODO list but please remind me if I forget :)

Best,
-Ekr