SRTP Double Encryption Procedures
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Suhas Nandakumar <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org 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 Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-double/
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. Personnel The document shepherd is Suhas Nandakumar; the responsible Area Director is Alexey Melnikov.