Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
RFC 8723

Approval announcement
Draft of message to be sent after approval:

From: The IESG <>
To: IETF-Announce <>
Cc: The IESG <>,,,, Suhas Nandakumar <>,,,
Subject: Protocol Action: 'SRTP Double Encryption Procedures' to Proposed Standard (draft-ietf-perc-double-12.txt)

The IESG has approved the following document:
- 'SRTP Double Encryption Procedures'
  (draft-ietf-perc-double-12.txt) as Proposed Standard

This document is the product of the Privacy Enhanced RTP Conferencing Working

The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba.

A URL of this Internet Draft is:

Technical Summary

This document define SRTP procedures for enabling end to end media 
confidentiality and integrity for end-points in a Multimedia conferences.
It does so by defining 2 types of SRTP transforms - outer and inner. 
The inner transform is responsible for ensuring end-to-end integrity 
and encryption. The outer transform covers integrity and encryption 
hop-by-hop (between endpoints and the media distributor or between 
the media distributors).

Working Group Summary

This document has been discussed and reviewed several times by the
WG. There were few individuals with concerns regarding the 
following areas

1. Allow Media distributor (MD) to modify the SSRC field 
in the RTP header. However they weren't able to propose
solutions that can mitigate the SSRC splicing attack 
identified by the WG. Also to note, the WG had previously
reached consensus on non-modifiability of the SSRC by the 
media distributor. However, the discussion was re-opened to 
help the concerned individual to put forward the proposals.
But as aforementioned, there was no proposal submitted that
satisfactorily addressed the splicing attack. Hence the 
WG decided to go forward with previously reached consensus to 
not allow MD to modify the SSRC.

2. Mechanisms to carry the end to end scoped payload header information:
Originally the proposal was to carry such information as an 
RTP header extension. However, there was a proposal to 
carry similar information as the payload header. The authors of the 
document made accommodations to work out a solution that addressed 
the concern. This involved moving the OHB from header extension to 
payload header as part of the endpoint procedures.

Additionally there were complaints about complexity and
bits on the wire. However, no one brought alternative
proposals to the WG that met the security objectives.

The chairs called for consensus - in-room and on-list -, there was
support to go with the procedures defined in the current version 
of the specification. Even though there are few individuals who aren't
totally happy, the WG had consensus on the proposals.

Also there were discussions on solution approaches for dealing 
with the repair packets. Two possible solutions were discussed. One was 
related to applying the hop-by-hop transform for the repair packet on 
the single encrypted packet vs double encrypted packet. The former 
implying a split in SRTP transform context states (E2E, RTX, HBH) and 
the latter implying a simple canonical way of doing classic SRTP 
(But just with a new transform called double). Hence the latter approach 
was chosen given its simplicity of implementing on plethora of end-points 
versus acceptable extra processing needed on relatively lower number of MD implementations.

Some objections were raised in the working group, and re-raised during the first IETF LC,
proposing that the encryption applied by PERC should be split so that in the WebRTC case,
E2E keys could be supplied by someone other than the browser. It became clear in both
WG discussions and post-LC discussions involving the ADs that this would be counter to
the WebRTC security model, which is required in the PERC charter. So any work to address
these concerns would be future work, and not blocking on the current documents.

Document Quality

libsrtp, a widely used SRTP library in commercial and open source 
SIP  and Webrtc products, has a branch with the implementation 
for double encryption procedures as defined in this specification. 
This document did not require expert review of the types noted.


The document shepherd is Suhas Nandakumar;
the responsible Area Director is Alexey Melnikov.