Subject: [Perc] PERC assumptions about SIP environment

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 12 May 2016 14:55:31 +0000

Hi,

I was looking through the framework document (https://tools.ietf.org/html/draft-jones-perc-private-media-framework-02) and some of the message flows from previous documents and was hoping to find some information to help me understand how this would fit within an existing SIP environment but I did not find anything.

The PERC charter states "The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints" so I was thinking about what this means.

Since the current PERC proposals are based on DTLS-SRTP is it the assumption that PERC only works in a DTLS-SRTP only environment? If this is the case then I assume it needs to be clearly stated somewhere as a limitation.

Also does the current implementation proposal assume that a SIP endpoint discovers it needs to do PERC stuff during the DTLS handshake and there is no need for SIP/SDP mechanisms to discover this?

Regards
Andy

---

From: Adam Roach <[email-masked]>
Date: Thu, 12 May 2016 14:42:45 -0500

> Since the current PERC proposals are based on DTLS-SRTP is it the assumption that PERC only works in a DTLS-SRTP only environment? If this is the case then I assume it needs to be clearly stated so…

I believe that this is, yes, a prerequisite of the system. SRTP is, of 
course, given. And it would be like building a steel door in the middle 
of an open field if we allowed this SRTP to be keyed with SDES. So 
DTLS-SRTP is required.

> Also does the current implementation proposal assume that a SIP endpoint discovers it needs to do PERC stuff during the DTLS handshake and there is no need for SIP/SDP mechanisms to discover this?

I don't think this has been discussed yet. I think we're finally getting 
to a point where it would be reasonable for someone to put together a 
draft that talks about feature discovery and information flow in a SIP 
context. If you'd like to spend some cycles doing that, it would 
probably be a good investment of your time. When I have a few cycles, I 
plan to do something similar for WebRTC (assuming no one beats me to it) 
-- we should make sure SDP handling is consistent between the two.

/a

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 13 May 2016 02:42:52 +0000

Andrew,

>Hi,
>
>I was looking through the framework document 
>(https://tools.ietf.org/html/draft-jones-perc-private-media-framework-02) 
>and some of the message flows from previous documents and was hoping to 
>find some information to help me understand how this would fit within 
>an existing SIP environment but I did not find anything.

We do not have call flow diagrams in any of the documents.  However, the 
intent is to reuse the existing SDP syntax we have already, augmented 
with whatever pieces and parts we need from current work in various 
other IETF WGs (e.g., MID, RID, and simulcast drafts).  So, the impact 
on SIP is minimal.  The impact on SDP construction is a little greater 
and, of course, media handling is most significant (since we're 
encrypting everything twice with two different keys).

>The PERC charter states "The solution should be implementable by both 
>SIP (RFC3261) and WebRTC endpoints" so I was thinking about what this 
>means.

I take that to mean we're not going to go invent something that doesn't 
fit cleanly.  Perhaps as extreme examples, we're not going to create a 
replacement for SDP or SRTP.  I would view it as a goal to be able to 
add PERC support to an existing implementation in a way that is 
"natural".

>  Since the current PERC proposals are based on DTLS-SRTP is it the 
>assumption that PERC only works in a DTLS-SRTP only environment? If 
>this is the case then I assume it needs to be clearly stated somewhere 
>as a limitation.

I don't personally view that as a limitation.  Along with requiring 
DTLS-SRTP, we are also requiring HBH and E2E encryption using two 
entirely different keys, with the E2E key conveyed to other endpoints 
using and EKT provided to the endpoint via the KMF over that 
aforementioned DTLS-SRTP association.  Thus, I don't see it as a 
limitation, but a design choice that will lead to improved 
interoperability.

>Also does the current implementation proposal assume that a SIP 
>endpoint discovers it needs to do PERC stuff during the DTLS handshake 
>and there is no need for SIP/SDP mechanisms to discover this?

We do not have anything written about how this will be determined.  
Clearly, the endpoint knows that it needs to do double encryption and it 
needs to know that it is participating in a multipoint conference where 
multiple video flows coming toward it, perhaps with simulcast flows.  To 
be secure, it needs a way to convey identity and certificate information 
to a higher layer function also not discussed in PERC.  We've been 
focused just on the media aspects, but some of that other stuff would be 
needed for a complete solution.

You're rightfully observing that not everything is defined the current 
drafts.

Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 13 May 2016 08:25:30 +0000

> of an open field if we allowed this SRTP to be keyed with SDES. So

Agreed nothing else makes sense but this is a big deal for the SIP world as it is the first time I believe that a major feature has been totally reliant on a DTLS-SRTP only solution. It is also going to be very hard to deploy in any kind of open SIP network if it means that all SIP endpoints in the network have to support DTLS-SRTP. I guess there is nothing much that can be done about that it is just reality.

However I am thinking that we urgently need to get the new media security working group that we discussed in dispatch at IETF95 up and running to make sure everything is aligned regarding PERC and the best practice for SIP end-to-end two party sessions and SIP opportunistic security. In fact I am thinking that work needs to be done before PERC gets too far.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 19 May 2016 17:32:19 -0500

On 13 May 2016, at 3:25, Hutton, Andrew wrote:

[...]

>
> Agreed nothing else makes sense but this is a big deal for the SIP 
> world as it is the first time I believe that a major feature has been 
> totally reliant on a DTLS-SRTP only solution. It is also going to be 
> very hard to deploy in any kind of open SIP network if it means that 
> all SIP endpoints in the network have to support DTLS-SRTP. I guess 
> there is nothing much that can be done about that it is just reality.
>
> However I am thinking that we urgently need to get the new media 
> security working group that we discussed in dispatch at IETF95 up and 
> running to make sure everything is aligned regarding PERC and the best 
> practice for SIP end-to-end two party sessions and SIP opportunistic 
> security. In fact I am thinking that work needs to be done before PERC 
> gets too far.
>
>

On a side note: there's a proposed charter for that work on the dispatch 
list[1]. I encourage people to go there and comment on it asap.

[1] 
https://mailarchive.ietf.org/arch/msg/dispatch/wPZSo34sd5Iwsu90cthQpRDygPs

[...]

Thanks!

Ben.