Subject: [Perc] A more efficient way to think about RTP fields

From: Adam Roach <[email-masked]>
Date: Tue, 17 Nov 2015 15:29:49 -0600

I wanted to make a proposal to help make the PERC design team discussion 
about which fields can be read and/or changed in transit somewhat more 
productive.

Rather than diving straight in to the individual bits and fields in the 
RTP header, I think we should instead apply general principles about how 
those fields should be categorized. I beleive I can propose a starting 
point that is pretty uncontroversial:

 1. As EKR mentioned in the meeting, the goal here is not to make an
    SRTP-bis. Anything that is unencrypted in SRTP remains so in PERC.
 2. There is an assumption that fields remain authenticated end-to-end
    in PERC unless we identify a specific reason for the MDD to modify them.
 3. For those fields that are encrypted in SRTP, there is an assumption
    that they remain encrypted end-to-end in PERC unless we identify a
    specific reason for the MDD to read them.

In the discussion in Yokohama, Magnus was asking four questions about 
each field:

 1. Can the MDD modify it?
 2. Does the endpoint need the original value?
 3. Does the field need end-to-end authentication?
 4. Does the field need end-to-end confidentiality?

Mechanically, question #1 and #3 are the same question: anything that is 
unauthenticated in PERC is subject to modification. I don't think 
answering them as separate questions makes sense.

And, of course, it doesn't make sense to ask question #2 except for 
those fields that can be changed.

Question #4 can be trivially decided by application of the principles: 
in SRTP, only the payload (and padding) is encrypted; so, in PERC, only 
the payload (and padding) can possibly be encrypted. Since the point of 
this exercise is to keep the MDD from reading the payload, we can't 
relax this. That answers #4 for all possible fields.

Given the foregoing, I believe the exercise reduces to:

  * What fields does the MDD need to modify?
  * Of those fields (and only those fields), does the original value
    need to be preserved?

That seems to be a far more efficient way to approach the discussion.

FWIW, I think the answers are: X (no), M (no), PT (yes), sequence (yes), 
header extensions (yes). And, iff we allow SSRC changes, add: SSRC 
(yes), CSRC (yes), and Timestamp (yes).

/a

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 17 Nov 2015 14:17:17 -0800

[BA] If PERC e2e confidentiality services are only applied to those fields
(e.g. the payload) that are encrypted within SRTP, then this statement is
automatically true.

[BA] The RTP (and RTCP) fields that need to be modified by the MDD depend
 on what RTP topologies are supported.  It is like trying to define how a
box observed to forward packets behaves with respect to IP header fields
without saying whether it is a bridge, router or NAT.

[BA] It does make sense to me to assume that PERC can only encrypt the
fields that can be encrypted by SRTP.  However, the security services
offered by PERC e2e can be independent of those offered by SRTP, so that
fields which *could* be encrypted by SRTP may be encrypted *only* by PERC,
or by *both* SRTP and PERC.

On Tue, Nov 17, 2015 at 1:29 PM, Adam Roach <[email-masked]> wrote:

> In the discussion in Yokohama, Magnus was asking four questions about each
> field:
>
> unauthenticated in PERC is subject to modification. I don't think answering
> them as separate questions makes sense.
>
> And, of course, it doesn't make sense to ask question #2 except for those
> fields that can be changed.
>
> Question #4 can be trivially decided by application of the principles: in
> SRTP, only the payload (and padding) is encrypted; so, in PERC, only the
> payload (and padding) can possibly be encrypted. Since the point of this
> exercise is to keep the MDD from reading the payload, we can't relax this.
> That answers #4 for all possible fields.
>
>
> header extensions (yes). And, iff we allow SSRC changes, add: SSRC (yes),
> CSRC (yes), and Timestamp (yes).
>
> /a
>
> _______________________________________________
> Perc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc
>

---

From: John Mattsson <[email-masked]>
Date: Tue, 17 Nov 2015 23:56:29 +0100

Hi, Some comments inline on your "pretty uncontroversial" starting point.

> Rather than diving straight in to the individual bits and fields in the
RTP
> header, I think we should instead apply general principles about how those
> fields should be categorized. I beleive I can propose a starting point
that
> is pretty uncontroversial:
>

According to the charter, the goal is to ensure enduser privacy, including
any needed extensions to SRTP.

>    in PERC unless we identify a specific reason for the MDD to modify
them.

Remain? In a conference with RFC3711, nothing is authenticated end-to-end
unless you have a relay topology.

Agree that having everything we can authenticated end-to-end (maybe even if
the MDD modify them) makes a lot of sense. I start to like the idea of
having the MDD add changed fields to a header extension as a general
mechanism. But even so, I think we still need to go through all the fields,
extensions, and packet types. I do not think the MDD should copy things to
a header extension that the receiver clearly have no use of, and for the
e2e sequence number, I still think it makes more sense to have a new
explicit one.

>    specific reason for the MDD to read them.

Do you mean with or without the E flag, with or without header encryption?
I think one assumption is that that several RFC3711 encrypted packet types
(E=1) cannot be end-to-end encrypted.

Which fields the point-to-point protocol defined in RFC3711 protects is not
that relevant. All suggestions so far including your text above argues that
we need to change the coverage of the protection. Stating as you do above
that we can only protect less does not make sense.

*My pretty uncontroversial starting point is that:*
* - We need very strong reasons not to encrypt any privacy sensitive field,
in fact this is the new IETF BCP.*
* - Similarly, we need very strong reasons not to fix any uncovered
security problems.*

Cheers,
John

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Nov 2015 17:01:18 -0600

On 11/17/15 16:56, John Mattsson wrote:
> Remain? In a conference with RFC3711, nothing is authenticated 
> end-to-end unless you have a relay topology.

I mean "remain" as compared to unmediated SRTP.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 17 Nov 2015 15:06:23 -0800

> any needed extensions to SRTP.

My point is simply that there were a bunch of technical decisions made about
what did and did not need to be encrypted in SRTP back when SRTP was
designed. It's of course possible that those decisions were wrong, but if
you
are going to claim that things need to be encrypted that aren't encrypted
in SRTP, then you are revisiting those design decisions and moreover
that implies that those things should be encrypted in 1-1 SRTP as well.

That seems pretty clearly outside of charter scope.

-Ekr

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 18 Nov 2015 02:19:51 +0000

Adam,

>FWIW, I think the answers are: X (no), M (no), PT (yes), sequence 
>(yes), header extensions (yes). And, iff we allow SSRC changes, add: 
>SSRC (yes), CSRC (yes), and Timestamp (yes).

I think the questions make sense, but I'm left feeling that the "FWIW" 
part is where we'll get hung up again. For example, "X" will need to be 
modified if it modifies any other field and retains that field in an RTP 
header extension.

Just to avoid spending a lot of time debating over whether an MDD can or 
should modify any field, what we were aiming for in the "Double" draft 
is to let the MDDs change whatever they wish, but preserve all original 
values in an RTP header extension.  In this way, we retain the 
properties SRTP (i.e., no SRTPbis) and we don't have to spend meeting 
cycles debating which fields to preserve or allow to change.

My personal view is that it really makes no difference at all what 
fields do and do not get changed, so long as the recipient can properly 
authenticate the original data values using the cryptographic mechanisms 
defined in SRTP.

Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 17 Nov 2015 21:26:06 -0600

On 11/17/15 8:19 PM, Paul E. Jones wrote:
> part is where we'll get hung up again. For example, "X" will need to 
> be modified if it modifies any other field and retains that field in 
> an RTP header extension.

Sorry, I can see that I wasn't clear. I meant that the changable list 
was X, M, PT, sequence, and header extensions. The yes/no in parens was 
the answer to the *second* question of "does the original value need to 
be preserved?" I was proposing that, for X, the answer to that *second* 
question is "no".

> Just to avoid spending a lot of time debating over whether an MDD can 
> or should modify any field, what we were aiming for in the "Double" 
> draft is to let the MDDs change whatever they wish, but preserve all 
> original values in an RTP header extension.  In this way, we retain 
> the properties SRTP (i.e., no SRTPbis) and we don't have to spend 
> meeting cycles debating which fields to preserve or allow to change.

That's true, but it just kicks the can down the road. Even with the 
double approach, we ultimately need to provide guidance to MDDs about 
which fields they can expect to change without endpoints rejecting the 
results, and guidance to endpoints about which fields they can 
reasonably expect to have changed by MDDs without considering the 
modifications an attack. The list is important.

All that double gains us in this analysis is that it frees us from 
having to ask the question about whether the original value is important 
to preserve, since all original values end up being preserved.

/a

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 18 Nov 2015 03:52:13 +0000

Adam,

>be preserved?" I was proposing that, for X, the answer to that *second* 

It might not be so obvious with "X". If there were no header extensions 
to start with and the MDD introduced one or two, the receiving endpoint 
might not know that the MDD added the extension or not. That was the 
purpose of the "Ext Len" attribute in he unnamed table on Page 4. 
(Implication is that the MDD could add or change anything by appending, 
but not modifying header extensions -- which is perhaps another topic of 
discussion. For example, would the MDD want to change an audio level 
value?)  I guess with the approach in Double we could determine X 
implicitly at the receiver.

More generally, though, if we allow the MDD to change these fields 
without preserving the values, we are in effect modifying what is in the 
SRTP specs today.  I'm not personally opposed to what you have here, 
though.  I also proposed allowing changes to the X and PT fields without 
preservation in the original solution draft I presented.  I agree with 
your others, but it's important to be mindful that this deviates from 
the current AES-GCM SRTP spec.

>having to ask the question about whether the original value is 
>important to preserve, since all original values end up being 
>preserved.

Does it kick the can down the road?  If the primary objective is 
confidentiality and authentication end-to-end, and we find a way to 
ensure that is possible (and preserving all bits is a way to do it), 
then we meet the objective of the WG.

I guess what I might be missing is the security risk associated with 
allowing the MDD to change a particular field or another (or all of 
them) when the original field value is also preserved.  Why not allow 
the MDD to change what it wants?  (I'm not trying to be contrary.  I 
genuinely don't see the harm and want to be educated.)

Paul

---

From: Stephen Botzko <[email-masked]>
Date: Wed, 18 Nov 2015 09:22:11 -0500

in-line

On Tue, Nov 17, 2015 at 10:52 PM, Paul E. Jones <[email-masked]>
wrote:

>>>> (yes), header extensions (yes). And, iff we allow SSRC changes, add: SSRC
>> Sorry, I can see that I wasn't clear. I meant that the changable list was
>> X, M, PT, sequence, and header extensions. The yes/no in parens was the
>> answer to the *second* question of "does the original value need to be
>> preserved?" I was proposing that, for X, the answer to that *second*
>> question is "no".
>>
>
> It might not be so obvious with "X". If there were no header extensions to
> start with and the MDD introduced one or two, the receiving endpoint might
> not know that the MDD added the extension or not. That was the purpose of
> the "Ext Len" attribute in he unnamed table on Page 4. (Implication is that
> the MDD could add or change anything by appending, but not modifying header
> extensions -- which is perhaps another topic of discussion. For example,
> would the MDD want to change an audio level value?)  I guess with the
> approach in Double we could determine X implicitly at the receiver.
>
> More generally, though, if we allow the MDD to change these fields without
> preserving the values, we are in effect modifying what is in the SRTP specs
> today.  I'm not personally opposed to what you have here, though.  I also
> proposed allowing changes to the X and PT fields without preservation in
> the original solution draft I presented.  I agree with your others, but
> it's important to be mindful that this deviates from the current AES-GCM
> SRTP spec.
>
>>> should modify any field, what we were aiming for in the "Double" draft is
>>> to let the MDDs change whatever they wish, but preserve all original values
>>> in an RTP header extension.  In this way, we retain the properties SRTP
>>> (i.e., no SRTPbis) and we don't have to spend meeting cycles debating which
>>> fields to preserve or allow to change.
>>>
>>
>> double approach, we ultimately need to provide guidance to MDDs about which
>> fields they can expect to change without endpoints rejecting the results,
>> and guidance to endpoints about which fields they can reasonably expect to
>> have changed by MDDs without considering the modifications an attack. The
>> list is important.
>>
>> All that double gains us in this analysis is that it frees us from having
>> to ask the question about whether the original value is important to
>> preserve, since all original values end up being preserved.
>>
>
> confidentiality and authentication end-to-end, and we find a way to ensure
> that is possible (and preserving all bits is a way to do it), then we meet
> the objective of the WG.
>
> allowing the MDD to change a particular field or another (or all of them)
> when the original field value is also preserved.  Why not allow the MDD to
> change what it wants?  (I'm not trying to be contrary.  I genuinely don't
> see the harm and want to be educated.)

I also don't see the harm in letting the MDD change what it wants.
Anything that needs to remain private has to be encrypted end-to-end
anyway, and preserving the original values enables authentication
end-to-end.

And I see a lot of benefits (including future extensibility) in allowing
more freedom in the design.

Stephen

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Nov 2015 09:37:55 -0600

On 11/18/15 08:22, Stephen Botzko wrote:
>
> On Tue, Nov 17, 2015 at 10:52 PM, Paul E. Jones <[email-masked] 
> <mailto:[email-masked]>> wrote:
> ...
>
>
>     I guess what I might be missing is the security risk associated
>     with allowing the MDD to change a particular field or another (or
>     all of them) when the original field value is also preserved.  Why
>     not allow the MDD to change what it wants?  (I'm not trying to be
>     contrary.  I genuinely don't see the harm and want to be educated.) 
>
>

I tried to construct concrete examples of where this falls apart, and 
was not easily able to. So it might be that allowing changes everywhere 
is fine. We're still going to want to offer guidance to endpoints about 
the meaning and handling of original-versus-changed sequence numbers and 
timestamps, but I'm becoming more open to the prospect that perhaps we 
don't need to worry about normatively proscribing specific changes as 
long as original values are recoverable.

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 18 Nov 2015 09:42:59 -0600

On 11/17/15 17:06, Eric Rescorla wrote:
>
> On Tue, Nov 17, 2015 at 2:56 PM, John Mattsson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On Tue, Nov 17, 2015 at 10:29 PM, Adam Roach <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > Rather than diving straight in to the individual bits and fields
>     in the RTP
>     > fields should be categorized. I beleive I can propose a starting
>     point that
>     According to the charter, the goal is to ensure enduser privacy,
>     including any needed extensions to SRTP.
>
>
> designed. It's of course possible that those decisions were wrong, but 
> if you

Yeah, I'm going to ask our chairs and AD to weigh in on this one. It 
seems pretty clearly out of scope for us to boil the SRTP ocean just to 
make secure conferencing possible.

/a

---

From: "Roni Even" <[email-masked]>
Date: Wed, 18 Nov 2015 18:28:07 +0200

On Tue, Nov 17, 2015 at 2:56 PM, John Mattsson <[email-masked]> wrote:

On Tue, Nov 17, 2015 at 10:29 PM, Adam Roach <[email-masked]> wrote:
> Rather than diving straight in to the individual bits and fields in the RTP
> fields should be categorized. I beleive I can propose a starting point that

According to the charter, the goal is to ensure enduser privacy, including any needed extensions to SRTP.

what did and did not need to be encrypted in SRTP back when SRTP was designed. It's of course possible that those decisions were wrong, but if you

[Roni Even] I agree about the encryption. I thought that the discussion in PERC, about which header fields can be changed by the MDD, has to do with the RTP packet authentication and RTP packet size size only.

BTW: there is already an update to RFC3711 in RFC6904 adding encryption support to RTP header extensions.

-Ekr

---

From: Luis Lopez <[email-masked]>
Date: Thu, 19 Nov 2015 09:57:30 +0100

+1
> I also don't see the harm in letting the MDD change what it wants.  Anything that needs to remain private has to be encrypted end-to-end anyway, and preserving the original values enables authentication end-to-end.
> 
> And I see a lot of benefits (including future extensibility) in allowing more freedom in the design.

---

From: John Mattsson <[email-masked]>
Date: Wed, 18 Nov 2015 16:01:57 +0000

Then please include the security ADs as well.

I simply cannot see why encrypting more would be out of scope while encrypting less would be in scope. The charter just says: “Specify any necessary extensions to SRTP”.

We are clearly already revisiting the design choices for the protection coverage of both SRTP and SRTPC. I would say that unless the charter says anything else, then RFC7258 applies.

/John

From: Perc <[email-masked]<mailto:[email-masked]>> on behalf of Adam Roach <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 18 November 2015 16:42
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ben Campbell <[email-masked]<mailto:[email-masked]>>, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Mats Näslund <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Perc] A more efficient way to think about RTP fields

On Tue, Nov 17, 2015 at 2:56 PM, John Mattsson <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Some comments inline on your "pretty uncontroversial" starting point.

Yeah, I'm going to ask our chairs and AD to weigh in on this one. It seems pretty clearly out of scope for us to boil the SRTP ocean just to make secure conferencing possible.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Nov 2015 08:32:36 -0800

On Wed, Nov 18, 2015 at 8:01 AM, John Mattsson <[email-masked]>
wrote:

> I simply cannot see why encrypting more would be out of scope while
> encrypting less would be in scope. The charter just says: “Specify any
> necessary extensions to SRTP”.
>

Well, I think the question is what the referent of "necessary" is. I had
taken
it to be "necessary to make PERC work", rather than just "generally
necessary".

But let's let the ADs clarify...

-Ekr

> We are clearly already revisiting the design choices for the protection
> coverage of both SRTP and SRTPC. I would say that unless the charter says
> anything else, then RFC7258 applies.
>
> /John
>
> From: Perc <[email-masked]> on behalf of Adam Roach <
> [email-masked]>
> To: Eric Rescorla <[email-masked]>, John Mattsson <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Ben Campbell <[email-masked]>, Suhas
> Nandakumar <[email-masked]>, "[email-masked]" <[email-masked]>, Mats
> Näslund <[email-masked]>
>> On Tue, Nov 17, 2015 at 10:29 PM, Adam Roach < <[email-masked]>
>> [email-masked]> wrote:
> Yeah, I'm going to ask our chairs and AD to weigh in on this one. It seems
> pretty clearly out of scope for us to boil the SRTP ocean just to make
> secure conferencing possible.
>
> /a
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Nov 2015 16:27:26 +0100

> That seems pretty clearly outside of charter scope.

Two points on this.

First, SRTP was designed to be efficient with header compression. Use of 
header compression is extremely rare, even in mobile networks. Thus, the 
trade-offs in privacy that was made, I would not consider full relevant 
in today. Thus, the important point is that one can't apply those 
considerations for the original trade-off in today's context.

Secondly, we must be careful to really consider the resulting security 
properties both end-to-end and hop-by-hop. What the WG is chartered with 
is to ensure the media confidentiality end-to-end. That does not only 
require confidentiality, but also source authentication and integrity 
protection of certain sets of information to prevent loosing the 
confidentiality. Also we have learned about a number of attacks that was 
not considered when SRTP was done, these do need to be considered in 
this work.

I might have be a bit more paranoid than necessary when I compiled the 
material in the draft and slide. But, that is primarily in the 
perspective on putting the trust level in the MDD extremely low, wanting 
to be enable verification and detection of actions that can affect a 
participants view of the conference. This is a discussion we also need 
to have on what we mean with semi-trusted.

 From my perspective the charter does not rule in either way on the 
question if we are restricted to not consider better security for the 
whole system than what SRTP provides hop-by-hop.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Thu, 19 Nov 2015 09:30:30 -0600

On 11/19/15 09:27, Magnus Westerlund wrote:
> perspective on putting the trust level in the MDD extremely low, 
> wanting to be enable verification and detection of actions that can 
> affect a participants view of the conference.

As a baseline, I think we can consider it to be more trusted than, say, 
an IP router. Right?

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Nov 2015 16:36:41 +0100

> As a baseline, I think we can consider it to be more trusted than, say,

Yes, I agree with that. But, the interesting question is how much we 
expect it to refrain from trying to affect the human communication in 
non expected ways. Here I am referring to to replay or delay attacks as 
well as the splicing attack.

We also need to consider if we are fine with in retrospect being able to 
detect that the MDD was acting malicious. I think that might be fine for 
some of the risks that is difficult to protect against as they happen. 
Bifurcation, when the MDD keeps one participant isolated from the rest 
might be one of these cases.

Cheers

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Nov 2015 07:41:31 -0800

On Thu, Nov 19, 2015 at 7:27 AM, Magnus Westerlund <
[email-masked]> wrote:

> trade-offs in privacy that was made, I would not consider full relevant in
> today. Thus, the important point is that one can't apply those
> properties both end-to-end and hop-by-hop. What the WG is chartered with is
> to ensure the media confidentiality end-to-end. That does not only require
> confidentiality, but also source authentication and integrity protection of
> certain sets of information to prevent loosing the confidentiality. Also we
> have learned about a number of attacks that was not considered when SRTP
> was done, these do need to be considered in this work.
>

These seem like arguments for a general redesign of SRTP. Without taking a
position
on whether that's needed, it's absurd to have a stronger design for the
SRTP we use
with PERC than the SRTP we use for point-to-point communications.

-Ekr

> material in the draft and slide. But, that is primarily in the perspective
> on putting the trust level in the MDD extremely low, wanting to be enable
> verification and detection of actions that can affect a participants view
> of the conference. This is a discussion we also need to have on what we
> mean with semi-trusted.
>
> question if we are restricted to not consider better security for the whole
> system than what SRTP provides hop-by-hop.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 19 Nov 2015 08:54:53 -0800

On Thu, Nov 19, 2015 at 8:29 AM, Mats Näslund <[email-masked]>
wrote:

> Hi Eric,
>
>
>
> SRTP was designed for a standard e2e security model. The packet fields
> left in the clear were motivated
>
> mainly by the need to allow header compression and to find data for ”IV”s
> in an economic way.
>
>
>
> Even if we now decide to design a slightly different solution, it does not
> necessarily need to
> invalidate the design choices made in the past. The security model now is
> somewhat different.
>

I'm not saying that it invalidates the design choices, I'm just saying that
if that
threat model has changed then we should fix e2e-SRTP as well.

-Ekr

/Mats
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* den 19 november 2015 16:42
> *To:* Magnus Westerlund
> *Cc:* John Mattsson; Adam Roach; [email-masked]; Mats Näslund
> *Subject:* Re: [Perc] A more efficient way to think about RTP fields
>
>
>
>
>
>
>

---

From: John Mattsson <[email-masked]>
Date: Thu, 19 Nov 2015 17:15:48 +0000

The threat model for privacy and pervasive monitoring has no doubt changed since RFC3711 was standardized. To me "PERC" SRTP is a new encryption transform. I see no reason why it could not be used for point-to-point SRTP.

Sent from my C64

On 19 Nov 2015, at 17:55, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Nov 19, 2015 at 8:29 AM, Mats Näslund <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

SRTP was designed for a standard e2e security model. The packet fields left in the clear were motivated
mainly by the need to allow header compression and to find data for ”IV”s in an economic way.

Even if we now decide to design a slightly different solution, it does not necessarily need to
invalidate the design choices made in the past. The security model now is somewhat different.

I'm not saying that it invalidates the design choices, I'm just saying that if that
threat model has changed then we should fix e2e-SRTP as well.

-Ekr

/Mats

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: den 19 november 2015 16:42
To: Magnus Westerlund
Cc: John Mattsson; Adam Roach; [email-masked]<mailto:[email-masked]>; Mats Näslund
Subject: Re: [Perc] A more efficient way to think about RTP fields

On Thu, Nov 19, 2015 at 7:27 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
Den 2015-11-18 kl. 00:06, skrev Eric Rescorla:

On Tue, Nov 17, 2015 at 2:56 PM, John Mattsson <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Hi, Some comments inline on your "pretty uncontroversial" starting
    point.

Two points on this.

First, SRTP was designed to be efficient with header compression. Use of header compression is extremely rare, even in mobile networks. Thus, the trade-offs in privacy that was made, I would not consider full relevant in today. Thus, the important point is that one can't apply those considerations for the original trade-off in today's context.

Secondly, we must be careful to really consider the resulting security properties both end-to-end and hop-by-hop. What the WG is chartered with is to ensure the media confidentiality end-to-end. That does not only require confidentiality, but also source authentication and integrity protection of certain sets of information to prevent loosing the confidentiality. Also we have learned about a number of attacks that was not considered when SRTP was done, these do need to be considered in this work.

These seem like arguments for a general redesign of SRTP. Without taking a position
on whether that's needed, it's absurd to have a stronger design for the SRTP we use
with PERC than the SRTP we use for point-to-point communications.

-Ekr

I might have be a bit more paranoid than necessary when I compiled the material in the draft and slide. But, that is primarily in the perspective on putting the trust level in the MDD extremely low, wanting to be enable verification and detection of actions that can affect a participants view of the conference. This is a discussion we also need to have on what we mean with semi-trusted.

>From my perspective the charter does not rule in either way on the question if we are restricted to not consider better security for the whole system than what SRTP provides hop-by-hop.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287<tel:%2B46%2010%207148287>
Färögatan 6                 | Mobile +46 73 0949079<tel:%2B46%2073%200949079>
SE-164 80 Stockholm, Sweden | mailto: [email-masked]<mailto:[email-masked]>
----------------------------------------------------------------------

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Nov 2015 12:44:33 -0500

> As a baseline, I think we can consider it to be more trusted than, say,

Obviously it is in a position to block media transmission to/from some 
or all of the participants. So you must be willing to trust it to follow 
the policy you have requested for that.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 19 Nov 2015 17:24:42 -0600

The perc charter is explicitly about centralized SRTP conferencing, 
where the MDD is not trusted with the keys to decrypt media. That's in 
the first sentence under "WG Objectives". While it allows for SRTP 
extensions (I think we had things like EKT in mind), I don't think the 
charter allows for fundamental changes to SRTP to happen in perc.

That doesn't mean such changes can't happen elsewhere, if people agree 
that RFC 3711 needs to be improved. But I would caution people that 
making the perc depend on such work would greatly increase the time to 
completion. And if there are limitations in perc due to SRTP, it makes 
sense to document them (perhaps as part of the "Define the trust model 
and describe the resulting security properties" objective.

Thanks!

Ben.

On 19 Nov 2015, at 11:15, John Mattsson wrote:

> The threat model for privacy and pervasive monitoring has no doubt 
> changed since RFC3711 was standardized. To me "PERC" SRTP is a new 
> encryption transform. I see no reason why it could not be used for 
> point-to-point SRTP.
>
> Sent from my C64
>
> On 19 Nov 2015, at 17:55, Eric Rescorla 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>
>
> On Thu, Nov 19, 2015 at 8:29 AM, Mats Näslund 
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Eric,
>
> On Thu, Nov 19, 2015 at 7:27 AM, Magnus Westerlund 
> <[email-masked]<mailto:[email-masked]>> 
> wrote:
> <[email-masked]<mailto:[email-masked]>
>  On Tue, Nov 17, 2015 at 10:29 PM, Adam Roach 
> <[email-masked]<mailto:[email-masked]>
> First, SRTP was designed to be efficient with header compression. Use 
> of header compression is extremely rare, even in mobile networks. 
> Thus, the trade-offs in privacy that was made, I would not consider 
> full relevant in today. Thus, the important point is that one can't 
> apply those considerations for the original trade-off in today's 
> context.
>
> properties both end-to-end and hop-by-hop. What the WG is chartered 
> with is to ensure the media confidentiality end-to-end. That does not 
> only require confidentiality, but also source authentication and 
> integrity protection of certain sets of information to prevent loosing 
> the confidentiality. Also we have learned about a number of attacks 
> that was not considered when SRTP was done, these do need to be 
> considered in this work.
>
> affect a participants view of the conference. This is a discussion we 
> also need to have on what we mean with semi-trusted.
>
> SE-164 80 Stockholm, Sweden | mailto: 
> [email-masked]<mailto:[email-masked]>

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 19 Nov 2015 17:31:31 -0600

BTW, I sent that wearing my "responsible AD" hat. (I am told my hat 
choice was not clearly visible.)

Thanks!

Ben.

On 19 Nov 2015, at 17:24, Ben Campbell wrote:

>> Secondly, we must be careful to really consider the resulting 
>> security properties both end-to-end and hop-by-hop. What the WG is 
>> chartered with is to ensure the media confidentiality end-to-end. 
>> That does not only require confidentiality, but also source 
>> authentication and integrity protection of certain sets of 
>> information to prevent loosing the confidentiality. Also we have 
>> learned about a number of attacks that was not considered when SRTP 
>> I might have be a bit more paranoid than necessary when I compiled 
>> the material in the draft and slide. But, that is primarily in the 
>>> question if we are restricted to not consider better security for 
>>> the whole system than what SRTP provides hop-by-hop.
>>
>> Cheers
>>
>> Magnus Westerlund
>>

---

From: Mats Näslund <[email-masked]>
Date: Thu, 19 Nov 2015 16:29:51 +0000

Hi Eric,

/Mats

From: Eric Rescorla [mailto:[email-masked]]
Sent: den 19 november 2015 16:42
To: Magnus Westerlund
Cc: John Mattsson; Adam Roach; [email-masked]; Mats Näslund
Subject: Re: [Perc] A more efficient way to think about RTP fields

Two points on this.

-Ekr

Cheers

Magnus Westerlund

---

From: John Mattsson <[email-masked]>
Date: Fri, 20 Nov 2015 10:34:14 +0000

Hi Ben!

See inline.

Cheers,
John

On 20/11/15 00:31, "Ben Campbell" <[email-masked]> wrote:

>> the first sentence under "WG Objectives".

The charter VERY explicitly points out that related metadata shall also be
kept private from the MDD:

"ensure that the RTP media and related metadata of the conference is kept
private and only available to the set of invited participants”

The ONLY way to keep metadata private from the MDD is to encrypt is
end-to-end or not send it to the MDD.

>>While it allows for SRTP

PERC will require changes to SRTP. Everybody seems to agree (at least all
documented suggestions) that the "Authenticated portion" (RFC3711 Figure
1) needs to change. The current discussion is about whether the “Ecnrypted
portion” (RFC3711 Figure 1) needs to change as well. I cannot see any
reason why this is a more “fundamental change”.

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Nov 2015 08:34:07 -0600

On 11/20/15 04:34, John Mattsson wrote:
> 1) needs to change.

That's a pretty tortured characterization of the 
draft-jennings-perc-double approach. In that proposal, authentication is 
performed exactly as defined in RFC3711 -- you just do it twice.

/a

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Nov 2015 09:56:30 -0500

> end-to-end or not send it to the MDD.

<hat type="chair"/>

My interpretation matches Ben's here.  The charter clearly says
"centralized SRTP-based conferencing", which means that major updates
to RFC 3711 are off the table.  The work of this group needs to fit
within the extensibility bounds defined by RFC 3711.  That is, the WG
needs to define a transform such that the MDD can be within the
authentication context, but not the encryption context -- not change
what is within the authentication or encryption boundaries.

In particular, discussion of which RTP fields need to be encrypted is
outside the scope of this WG.

--Richard

---

From: John Mattsson <[email-masked]>
Date: Fri, 20 Nov 2015 15:49:31 +0000

>outside the scope of this WG.

<hat type=“fighting for enduser privacy"/>

I also very strongly agree with Ben’s text above (basically nothing you
can disagree with). Nobody (at least not I) have stated that the work is
anything except "centralized SRTP-based conferencing”...

But the work is all about _privacy enhanced_ centralized SRTP-based
conferencing with the charter very clearly stating that the solution shall
ensure the privacy of metadata (in RTP or RTCP).

I do not even have a opinion whether any additional metadata shall be
encrypted, but I have a very strong opinion that metadata privacy should
be discussed (i.e. draft-westerlund-perc-rtp-field-considerations) and
should we agree that some metadata are privacy sensitive, then mitigations
are in scope (but should of course be balanced against any problems or
complexity caused by the mitigations). To me the main goal with PERC is
privacy. To quote Sean Turner: “Do it right”.

/John

JOHN MATTSSON
Ericsson IETF Security Coordinator
Senior Researcher, Security

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Nov 2015 11:09:42 -0500

> privacy. To quote Sean Turner: “Do it right”.

John, if you feel that SRTP provides insufficient privacy protections,
that's fine.  But it's not an issue for PERC.  The charter is clear
that the privacy enhancement we're after here is to extend the
protections that SRTP provides against a network attacker so that they
also protect against the MDD (with some minimal affordance for
changing some fields) -- not to change the baseline protection level.
If you would like to increase the baseline level of security for
real-time media beyond what SRTP provides, feel free to approach the
ADs about forming a new WG.

--Richard

---

From: Adam Roach <[email-masked]>
Date: Fri, 20 Nov 2015 10:43:53 -0600

> <hat type=“fighting for enduser privacy"/>

But you're not.

You're not, because you claim you've identified a broad class of problem 
that affects all of SRTP, and you are trying to fix it only for the PERC 
case. Your approach leaves one-to-one calls -- for which the expectation 
of privacy is exponentially higher than it is in the group-call case -- 
out of the equation.

You're not, because your insistence that we perform a laborious, 
field-by-field analysis before we make any useful progress on PERC 
delays this work. In the high-bandwidth context of a face-to-face 
meeting, we burned half an hour on this exact topic, and made virtually 
no progress. Unless we revise that behavior, we're going to have a 
re-run of this wasted time on the upcoming design team call. This is 
time and effort we could instead be spending on fulfilling the WG's 
milestones. By impeding progress in the WG, you are lengthening the time 
that users are forced to make use of MCUs that have access the entire, 
unencrypted contents of the conversation.

Your heart may be in the right place, but your actions are harmful. 
You're omitting one class of users from the protections you claim they 
need, and delaying the date that even minimal privacy arrives for another.

I laud your goals, for I fight for end-user privacy, too. We share a 
goal, but your selected tactics are harming that goal.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Nov 2015 11:43:18 +0100

> the policy you have requested for that.

I don't think it is so clear cut as this. One can actually preliminary 
trust it to do its work. And then have functions to verify that it was 
in fact following the policy. Retrospective inspection of information 
that is asserted to be correct about what actually happen would enable 
such watch guards on the MDDs.

The question is how we intended to deal with an MDD that intentionally 
suppresses attempts to interact within the conference from some 
conference participant. It might be that we say that such attacks must 
be handled by the conference participant (human) complaining to the 
conference organizer (human) that it failed to provide its input.

My realization is that a lot of this discussion is actually about the 
trust model for the MDD. What do we trust it with doing, and what does 
we not trust it with. From my perspective the privacy and 
confidentiality of the media end-to-end we have no trust in the MDD. I 
am also are concerned if the MDD could substitute or change who the 
media are indicated to originate with. The switching decision appears to 
need to lay with the MDD in some usages, others may have MDD external 
control of the forwarding decisions. I think the WG should discuss if 
this needs to be monitored.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Nov 2015 11:58:31 +0100

> unencrypted contents of the conversation.

Adam, I also wished we could have made more progress in discussing the 
fields in the face to face meeting. However, I do see this as necessary 
discussion. We need to agree on what the trust model for the MDD is. 
Doing the analysis I did stray into a model of minimal trust. Yes, I did 
become paranoid as some of the implications are not particular nice.

I will do my best to update the slide set for the design team meeting on 
Monday and be more explicit about the trust model applied. That way I 
hope we can get through to discuss the implications of some of the 
information, especially the header extensions.

About the delay, unless we agree on what the design goals when it comes 
to the basic security level is, we will have much issues going forward 
then the time lost spending a month discussing it.

I do expect us to have consensus at least in the design team on the 
privacy nature of the various fields and header extensions by no later 
than January. That includes an agreement on the trust model for the MDD.

What might confuse you slightly is that at least John and I have spent 
time discussing and are thinking on some few areas of improved security. 
These we do want to ensure that they are possible to implement in the 
future. The clear ones can roughly be characterised as the following:

- Improved Hop-by-hop protection against third party passive attacks. 
The basic idea here is to replace SRTP with DTLS as hop-by-hop 
protection, thus preventing information leakage from the RTP header and 
non-confidentiality protected header extensions.

- retrospective media decryption: To prevent a late joiner that has been 
able to capture the media packets from retrospectively decrypt them by 
joining the conference. This basically requires group key re-keying on 
each change of the current participant rooster.

Cheers

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Nov 2015 10:21:23 -0500

> this needs to be monitored.

ISTM that an important attack would be when the MDD is secretly under 
the control of one of the participants, who has a goal of manipulating 
the outcome of the conference. (Or, equivalently, one of the 
participants has been infiltrated by somebody controlling the MDD.) In 
that case the content of the media streams can be available for making 
decisions about what streams to suppress, etc.

As you note, it is essential to understand the trust model.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 25 Nov 2015 15:10:20 -0600

On 11/25/15 04:58, Magnus Westerlund wrote:
> fields in the face to face meeting. However, I do see this as 
> necessary discussion. We need to agree on what the trust model for the 
> MDD is. Doing the analysis I did stray into a model of minimal trust. 
> Yes, I did become paranoid as some of the implications are not 
> particular nice.
>
> I will do my best to update the slide set for the design team meeting 
> on Monday and be more explicit about the trust model applied. That way 
> I hope we can get through to discuss the implications of some of the 

Going through the header extensions seems worthwhile (although I'll note 
that the decision about encryption appears to be under the control of 
the endpoints, so all we really need here is guidance, not rules).

But that's not where we wasted a bunch of time. Where we wasted time was 
discussions around things like "Do we need to hide the M-bit from the 
MDD?" And rather than going into a detailed analysis of each existing 
(non-extension) field, I'm trying to point out that we can save a lot of 
time by accepting the general principle that the MDD will be no less 
privileged than an on-path network node (e.g., router, SBC, ALG, etc) is 
_today_. Like, right now. In November of 2015.

The thing is, I'm not *proposing* this constraint. It's not something to 
come to consensus around; it's simply a fact. All I'm doing is pointing 
out that it is a logical consequence of our charter. PERC is not 
chartered to improve SRTP beyond current state of the art. Maybe that 
improvement needs to happen, but it's not allowed to happen in PERC. 
This isn't just my interpretation -- you have seen the WG chairs and the 
responsible area director weigh in on the topic. It is Out. Of. Scope.

The logical consequence of this fact is that discussing whether anything 
in the RTP header (outside of RTP extension headers) is encrypted (or 
otherwise inaccessible to the MDD) is also out of scope. Don't include 
it in your slides; don't bring it up in conversation. This is not the 
working group for it. And we sure as heck have better things to spend 
our time discussing on Monday.

/a

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 25 Nov 2015 15:20:14 -0800

Adam said:

"Going through the header extensions seems worthwhile"

[BA] In particular, I'm concerned about header extensions that contain
information gleaned from the cleartext payload.  This includes:

a. Client-mixer header extension (RFC 6464)
b. Frame marking header extension (draft-ietf-avtext-framemarking)

The ability to switch video depending on the "last N" active speakers
provides very substantial scalability benefits to SFUs.  However, the
question is how to achieve this scalability benefit without leaking too
much information to the SFU about the contents of the audio.

It seems likely to me that RFC 6464 provides too much information to the
MDD, and of course providing the MDD with access to cleartext audio for the
purpose of active speaker detection is also out of the question.  VAD with
CN is not helpful to the SFU, so you'd have to have the client stop sending
when muted.  At the end of the day, a workable solution would have to
enable the MDD to determine at least the "last N" speakers.

Overall,  we may have to make a distinction between leaks of "metadata"
(e.g. IP and MAC endpoint addresses, SSRCs, dominant participants, etc.)
 which are to some extent unavoidable and content.

On Wed, Nov 25, 2015 at 1:10 PM, Adam Roach <[email-masked]> wrote:

>> discussion. We need to agree on what the trust model for the MDD is. Doing
>> the analysis I did stray into a model of minimal trust. Yes, I did become
>> paranoid as some of the implications are not particular nice.
>>
>> Monday and be more explicit about the trust model applied. That way I hope
>> we can get through to discuss the implications of some of the information,
>> especially the header extensions.
>>
>
> that the decision about encryption appears to be under the control of the
> endpoints, so all we really need here is guidance, not rules).
>
> discussions around things like "Do we need to hide the M-bit from the MDD?"
> And rather than going into a detailed analysis of each existing
> come to consensus around; it's simply a fact. All I'm doing is pointing out
> that it is a logical consequence of our charter. PERC is not chartered to
> improve SRTP beyond current state of the art. Maybe that improvement needs
> to happen, but it's not allowed to happen in PERC. This isn't just my
> interpretation -- you have seen the WG chairs and the responsible area
> director weigh in on the topic. It is Out. Of. Scope.
>
> otherwise inaccessible to the MDD) is also out of scope. Don't include it
> in your slides; don't bring it up in conversation. This is not the working
> group for it. And we sure as heck have better things to spend our time
> discussing on Monday.
>
> /a
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 26 Nov 2015 09:59:17 +0100

> _today_. Like, right now. In November of 2015.

Sorry, I am not certain what you mean with your last part. In an SRTP 
point-to-point context there is a significant difference between an IP 
router, which is not expected to modify the UDP payload, i.e. the RTP 
parts at all, and an SBC and ALG which may in fact the security context 
termination point. If you mean any device that is not part of the 
security context, then I can agree with your statement that it will not 
be less privileged. But if you talk about entities that have full access 
to packet by having the security context, then clearly not.

> responsible area director weigh in on the topic. It is Out. Of. Scope.

I am not disagreeing that redesigning SRTP is out of scope for the WG. I 
am also fully aware that SRTP as hop-by-hop solution is part of what we 
need to solve. However, the analysis of the security properties of the 
resulting system is in scope. What I and John also have argued for is 
that DTLS may be an option for hop-by-hop security that would give 
different security properties. And from that basis we argued that the 
End-to-End solution should consider if it reveals to much information. I 
am okay with restraining my self from discussing aspects that point to 
point SRTP would reveal, given that the WG not flatly refuses to at 
least discuss if we can have a solution that enables one in the future 
from replacing SRTP with DTLS as hop-by-hop security. Note, not define, 
simply that we choose designs that can enable us to replace the 
hop-by-hop protocol with another.

In regards to your example of the M bit. Yes encrypting the M bit 
end-to-end would be to make more information confidential than is 
currently in regular SRTP. I agree that this is going beyond what is 
needed for the basic security level. However, we still need to discuss 
if it is needed or not for the MDD to be able to change the M bit, in 
other the possibility to include it in end-to-end integrity and source 
authentication. Potential attacks from that choice by the MDD and the 
implications of such a choice from media handling is very much in scope 
for the WG. Primarily because they do effect the needed trust in the MDD.

Cheers

Magnus Westerlund

---

From: John Mattsson <[email-masked]>
Date: Thu, 26 Nov 2015 10:52:30 +0000

On 20/11/15 17:09, "Richard Barnes" <[email-masked]> wrote:
>that's fine.

Richard, I do not like to be told what I want. I have never stated that I
want to change point-to-point SRTP. I don’t, and this is about PERC. While
I am fine with SRTP as the hob-by-hob protocol, I do not think that the
PERC e2e layer should be designed with the assumption that SRTP is the
only possible hop-by-hop protection mechanism.

>  But it's not an issue for PERC.  The charter is clear

It would be good with some references from the charter to motivate that
interpretation. The only use of the word “minimal” I can find in the
charter is that meta information provided to the MDD shall be minimal:

"The meta information provided to the central device is to be limited to
the minimal required for it to perform its function”

Another good sentence is:

"ensure that the RTP media and related metadata of the conference is kept
private and only available to the set of invited participants and other
devices trusted by those participants”

>ADs about forming a new WG.

Ericsson already have, the result was PERC. Ericsson prepared the first
text and then chaired the meeting agreeing on the initial PERC charter,
and we are very happy with it.

SRTP extensions have been discussed before, during, and after the creation
of the PERC charter. I can think of the following: e2e protection of
header extensions, e2e protection of PTCP packet types, Extending the SRTP
context, Introducing SRTP ROC as a new field, Redefine the Associated
Data/Authenticated portion, Add new e2e source identifier to SRTP payload,
Add new e2e sequence number to SRTP payload, change the IV formation in
GCM, change replay protection, add additional processing to SRTP...

I am very surprised by the sudden suggestion that metadata privacy and
extensions to SRTP would be out of scope, especially from the chair.

John

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Nov 2015 08:37:42 -0800

Top-posting because I'm not really responding to anyone in particular.

We  have an existing design of SRTP that classifies pieces of the RTP packet
into two categories:

- Authenticated-only
- Encrypted + Authenticated

As has been noted several times, rather more of the packet is
Authenticated-only
than would be the case in a conventional channel security protocol (e.g.,
DTLS).
There were a number of reasons for this, but they included:

- Enabling unprivileged network elements to inspect pieces of the packet.
- Reducing per-packet overhead by using portions of the RTP header as
  control information that would ordinarily be in the header of the envelope
  protocol (e.g., the sequence number).

It seems likely that if more of the packet were encrypted, then SRTP would
be
more secure, or at least easier to analyze, as this discuss suggests.
However,
the current design is a compromise between that imperative and the factors
listed above (among others). So while I certainly agree that it wouldn't be
out of charter scope to have the hop-by-hop protocol encrypt more of the
packet, it seems like it would fall afoul of the considerations which led
to this design in the first place, since those factors applied primarily to
the behavior of the encrypted traffic on the wire. Stated differently:

"Why would it be OK to have more of hop-by-hop SRTP encrypted with
PERC than we do for E2E SRTP?"

Note: if the answer is "things have changed", then that's totally valid,
but it
seems like then we should also plan to change E2E SRTP and then we get
into the question of charter scope.

-Ekr