From nobody Wed Jan 15 11:24:47 2020 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBFF120935; Wed, 15 Jan 2020 11:24:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: perc@ietf.org Message-ID: <157911627983.29326.10576166662354599138@ietfa.amsl.com> Date: Wed, 15 Jan 2020 11:24:39 -0800 Archived-At: Subject: [Perc] I-D Action: draft-ietf-perc-srtp-ekt-diet-11.txt X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jan 2020 19:24:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Privacy Enhanced RTP Conferencing WG of the IETF. Title : Encrypted Key Transport for DTLS and Secure RTP Authors : Cullen Jennings John Mattsson David A. McGrew Dan Wing Flemming Andreason Filename : draft-ietf-perc-srtp-ekt-diet-11.txt Pages : 25 Date : 2020-01-15 Abstract: Encrypted Key Transport (EKT) is an extension to DTLS (Datagram Transport Layer Security) and Secure Real-time Transport Protocol (SRTP) that provides for the secure transport of SRTP master keys, rollover counters, and other information within SRTP. This facility enables SRTP for decentralized conferences by distributing a common key to all of the conference endpoints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-perc-srtp-ekt-diet-11 https://datatracker.ietf.org/doc/html/draft-ietf-perc-srtp-ekt-diet-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-perc-srtp-ekt-diet-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 31 03:48:24 2020 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F612081E; Fri, 31 Jan 2020 03:48:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Christer Holmberg via Datatracker To: Cc: last-call@ietf.org, draft-ietf-perc-srtp-ekt-diet.all@ietf.org, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christer Holmberg Message-ID: <158047129698.21175.5113712510703403314@ietfa.amsl.com> Date: Fri, 31 Jan 2020 03:48:17 -0800 Archived-At: Subject: [Perc] Genart telechat review of draft-ietf-perc-srtp-ekt-diet-11 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.29 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2020 11:48:17 -0000 Reviewer: Christer Holmberg Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-perc-srtp-ekt-diet-11 Reviewer: Christer Holmberg Review Date: 2020-01-31 IETF LC End Date: None IESG Telechat date: 2020-02-06 Summary: I took a long time before I got a reply to my original review comments, and now I realize that I never addressed that reply. Sorry for that. In my previous review, I had a number of editorial suggestions (Minor Issues), and in many cases the author did not agree to those. I will not pursue those, but leave it to the IESG to decide whether something needs to be done. Many of my issues have been addressed in the latest version. However, I do still have a couple of issues. One of them (Q1_1) is a follow-up from my previous review, and for convenience I will include the discussion content in this review. Major issues: Q1_1: >> The text in section 1 says that EKT removes the need for coordinating >> SSRCs,and that an endpoint can choose whatever value it wants. >> >> However, I can't find any explanation on how EKT removes that need. > > The answer is toward the end of the introduction: "EKT does not control the > manner in which the SSRC is generated..." -- it just makes the distribution > of security information easier. I extended that paragraph to clarify. As far as I understand, SSRC collisions can still occur. But, if that occurs, endpoints can provide the new SSRC using EKT – without the need for OOB solutions or signaling – and that is the reason EKT removes the need for coordinating SSRCs. I think it would be good to clarify that. Q_1_2: Section 5.3 reference RFC 3264 for the Offer/Answer procedures. However, since the text is specific to DTLS-SRTP, I think the reference should be to RFC 5763 and draft-ietf-mmusic-dtls-sdp. I assume this also applies to the RFC 3264 reference in Section 4.1 (SRTPMasterKeyLength definition). Minor issues: N/A Nits/editorial comments: N/A