Subject: Re: [Perc] Design Meeting Notes

From: John Mattsson <[email-masked]>
Date: Sun, 18 Oct 2015 16:31:45 +0200

Hi Suhas,

While the conclusions, and next steps in the end of your mail are
fine, the “agreements” in the beginning of your mail are not:

>Don't change the security properties of the SRTP unless it is required for the
>RTP aspects the correspond to security context. [[ref: Security weakness and l
>of thinking went in the design of SRTP]]

Is “security weakness went in the design of SRTP”, really what you meant? ;)

SRTP was designed for point-to-point security, NOT e2e secure
conferencing, it relies on the RTP layer for security critical input
such as SSRC and SEQ, and the privacy properties is nowhere near
modern standards. We SHOULD and NEED to change SRTP to fulfil the
security aspects of PERC.

>HBH will be based on standard SRTP as the default solution. Future
>proposals may be defined  to use non SRTP HBH but the WG needs to decide on
>it. For now the discussion is tabled till  the WG tackles core PERC & SRTP
>design issues.

I have certainly not agreed to this, and it goes completely against
the agreed next step “HBH encryption design - SRTP vs Non-SRTP pros
and cons”.

Some minor comments on next steps:

> Ensure that the DTLS layer handing over the EKT master

We have not agreed to use DTLS for this.

> Placement of E2E context data - In RTP header or after RTP Payload.

Comment: Here I would like to add RTCP and EKT, which both do not need
to be sent for each RTP packet. In fact EKT for PERC might be better
with the MDD storing and forwarding the full EKT field. The MDD likely
has a better understanding of when an endpoint needs the full EKT
field.

Cheers,
John

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 21 Oct 2015 10:17:04 +0000

John,

>has a better understanding of when an endpoint needs the full EKT

I would think the endpoint would.  If it sends an I-Frame, send the full 
EKT field, for example.  However, I have no objection to storing the EKT 
field so long as it caches and sends the right one.  Now that we are 
removing ISN and MKI, then it's even more important that the right value 
be put into packets.

Paul