From nobody Mon Feb 3 18:24:17 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 9256D120033; Mon, 3 Feb 2020 18:24:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <158078305359.28654.7682604939948678479.idtracker@ietfa.amsl.com> Date: Mon, 03 Feb 2020 18:24:13 -0800 Archived-At: Subject: [Perc] Adam Roach's Yes on draft-ietf-perc-srtp-ekt-diet-11: (with COMMENT) 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: Tue, 04 Feb 2020 02:24:14 -0000 Adam Roach has entered the following ballot position for draft-ietf-perc-srtp-ekt-diet-11: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Re-sending my initial comments, as only one of the 17 were addressed in subsequent revisions. While no single comment rises to the level of a DISCUSS-worthy issue, several of these are moderately severe. I would appreciate either a response to each comment, or a corresponding change in the document. --------------------------------------------------------------------------- Thanks to the work that everyone has put in on getting an EKT mechanism specified and finalized. I have a handful of comments that I would like to see considered prior to publication of the document. --------------------------------------------------------------------------- §1: > EKT provides a way for an SRTP session participant, to securely > transport its SRTP master key and current SRTP rollover counter to > the other participants in the session. Nit: "...participant to securely..." --------------------------------------------------------------------------- §4.1: > EKTMsgTypeExtension = %x03-FF Shouldn't this be "%x01 / %x03-ff" ? > SRTPMasterKeyLength = BYTE > SRTPMasterKey = 1*256BYTE I think this either needs to be "1*255BYTE", or we need text that explicitly indicates that an SRTPMasterKeyLength value of 0x00 means "256 bytes." Probably the former. I think this is even further constrained by the fact that EKTCiphertext is limited to 256 bytes, and contains the SRTPMasterKeyLength, SRTPMasterKey, SSRC, and ROC (and is not compressed) -- which means the SRTPMasterKeyLength can't be more than (256 - 1 - 4 - 4 =) 247 bytes. So perhaps "1*247BYTE" is more appropriate? --------------------------------------------------------------------------- §4.2.1: > The creation of the EKTField MUST precede the normal SRTP > packet processing. Why? This seems unnecessary and unnecessarily complicated. If the order of operations has an impact on the bits on the wire (I don't see how it does?), then please include some explanatory text here that clarifies the reason for this constraint. --------------------------------------------------------------------------- §4.2.1: > When a packet is sent with the ShortEKTField, the ShortEKFField is > simply appended to the packet. Nit: s/ShortEKFField/ShortEKTField/ --------------------------------------------------------------------------- §4.2.1: > 5. If the SSRC in the EKTPlaintext does not match the SSRC of the > SRTP packet received, then all the information from this > EKTPlaintext MUST be discarded and the following steps in this > list are skipped. I can see implementors easily interpreting this as requiring them to discard the RTP payload as well. If that's not the intention (I don't think it is), consider adding text like "The FullEKTField is removed from the packet then normal SRTP or SRTCP processing occurs." --------------------------------------------------------------------------- §4.3: > Section 4.2.1 recommends that SRTP senders continue using an old key > for some time after sending a new key in an EKT tag. This is the first appearance of the phrase "EKT tag," which never seems to be properly defined. I presume this is meant to be the combination of the EKT Ciphertext and the SPI? In any case, please clearly define this term somewhere, preferably before using it the first time. --------------------------------------------------------------------------- §4.3: > cannot be used and they also need to create a counter that keeps > track of how many times the key has been used to encrypt data to > ensure it does not exceed the T value for that cipher (see ). The parenthetical phrase appears to be missing something here. > If > either of these limits are exceeded, the key can no longer be used Nit: "...either... is exceeded..." > for encryption. At this point implementation need to either use the Nit: "...implementations need..." --------------------------------------------------------------------------- §4.5: > If a source has its EKTKey changed by the key management, it MUST > also change its SRTP master key I suppose it's not terribly important for interop, but the implication that this change takes place immediately seems to contradict the 250 ms period specified in §4.2.1. Perhaps a few words here about how these two normative statements are intended to interact would save implementors a bit of grief. --------------------------------------------------------------------------- §4.6: > This document defines the use of EKT with SRTP. Its use with SRTCP > would be similar, but is reserved for a future specification. After reading this far, I was quite surprised to find this qualification. If this is the intention for this document, please adjust the rest of the text to match. Some examples follow. > The following shows the syntax of the EKTField expressed in ABNF > [RFC5234]. The EKTField is added to the end of an SRTP or SRTCP > packet. ----- > Rollover Counter (ROC): On the sender side, this is set to the > current value of the SRTP rollover counter in the SRTP/SRTCP context > associated with the SSRC in the SRTP or SRTCP packet. ----- > 1. The final byte is checked to determine which EKT format is in > use. When an SRTP or SRTCP packet contains a ShortEKTField, the > ShortEKTField is removed from the packet then normal SRTP or > SRTCP processing occurs. ----- > The reason for > using the last byte of the packet to indicate the type is that > the length of the SRTP or SRTCP part is not known until the > decryption has occurred. ----- > 7. At this point, EKT processing has successfully completed, and the > normal SRTP or SRTCP processing takes place. ----- > This allows > those peers to process EKT keying material in SRTP (or SRTCP) and > retrieve the embedded SRTP keying material. --------------------------------------------------------------------------- §4.7: > To accommodate packet loss, it is > RECOMMENDED that three consecutive packets contain the > FullEKTField be transmitted. Nit: "...containing..." (alternately, remove "be transmitted" -- both make a grammatically correct sentance) More substantially -- under "New sender:", I'm a little surprised that there isn't any mention of other senders re-keying in response to a new sender joining. In the vast majority of conferences, when a sender joins, that same entity generally will also be a receiver. It seems this should trigger other senders to include the key in their next packet. --------------------------------------------------------------------------- §4.7: > Rekey: > By sending EKT tag over SRTP, the rekeying event shares fate with > the SRTP packets protected with that new SRTP master key. Is this actually true? Going back to the 250 ms period specified in §4.2.1, it seems that the master key is sent out in packets pretty far removed from those it actually protects. Between this and the inconsistency I mention in §4.5 above, this increasingly feels like maybe there were two different ways of reasoning about the timing of sending a master key versus the timing of actually using it. Does the text in §4.2.1 perhaps represent an outdated notion of how this is intended to work? --------------------------------------------------------------------------- §4.7: > If sending audio and video, the RECOMMENDED > frequency is the same as the rate of intra coded video frames. If > only sending audio, the RECOMMENDED frequency is every 100ms. Is this "100ms" correct? Assuming, say, the use of Opus at voice quality with 20 ms packets, this is taking packets on the order of 40 bytes in length and tacking on something like 20 to 30 bytes to every fifth packet. That's an increase in overall stream size on the order of roughly 15% to 20%. At the same time, when using real-time video, intra frames are going to happen roughly every 500 ms to 1500 ms. If a cadence on that order is okay for audiovisual streams, I have to imagine it's okay for audio streams. So, to clarify: is this "100ms" a typo for "1000 ms"? --------------------------------------------------------------------------- §7.2: > +----------+-------+---------------+ > | Name | Value | Specification | > +----------+-------+---------------+ > | AESKW128 | 1 | RFCAAAA | > | AESKW256 | 2 | RFCAAAA | > | Reserved | 255 | RFCAAAA | > +----------+-------+---------------+ > > Table 3: EKT Cipher Types Section 5.2.1 reserves "0" as well. I suspect we want to replicate that reservation in this table. From nobody Tue Feb 4 14:39:40 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 8AF151200B7; Tue, 4 Feb 2020 14:39:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <158085597556.15832.2393413092926333829.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 14:39:35 -0800 Archived-At: Subject: [Perc] Roman Danyliw's No Objection on draft-ietf-perc-srtp-ekt-diet-11: (with COMMENT) 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: Tue, 04 Feb 2020 22:39:36 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-perc-srtp-ekt-diet-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The document appears to have already gotten significant review with iterative updates. Section 5.2. If an EKTKey message is received that cannot be processed, then the recipient MUST respond with an appropriate DTLS alert. Is there any more specificity that can be provided on which DTLS alert might be appropriate? From nobody Tue Feb 4 22:18:05 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 6233C120045; Tue, 4 Feb 2020 22:18:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <158088348139.15764.233834325113998124.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2020 22:18:01 -0800 Archived-At: Subject: [Perc] Barry Leiba's No Objection on draft-ietf-perc-srtp-ekt-diet-11: (with COMMENT) 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, 05 Feb 2020 06:18:01 -0000 Barry Leiba has entered the following ballot position for draft-ietf-perc-srtp-ekt-diet-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree that Adam’s comments need to be addressed. From nobody Wed Feb 5 07:18:33 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 4168612085E; Wed, 5 Feb 2020 07:18:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <158091590126.12779.3007387758704769922.idtracker@ietfa.amsl.com> Date: Wed, 05 Feb 2020 07:18:21 -0800 Archived-At: Subject: [Perc] Magnus Westerlund's Discuss on draft-ietf-perc-srtp-ekt-diet-11: (with DISCUSS) 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, 05 Feb 2020 15:18:21 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-perc-srtp-ekt-diet-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I think there are an important discrpency between the figure and the ABNF for the full EKT message in section 4.1: Figure 1: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : EKT Ciphertext : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0 0 0 1 0| +-+-+-+-+-+-+-+-+ The ABNF parts that appears relevant: EKTCiphertext = 1*256BYTE ; EKTEncrypt(EKTKey, EKTPlaintext) Epoch = 2BYTE SPI = 2BYTE FullEKTField = EKTCiphertext SPI Epoch EKTMsgLength EKTMsgTypeFull Note that the above ABNF states that the SPI is followed by a 16-bit Epoch field prior to the length field. Can you please ensure that this discrepancy is clarified. From nobody Thu Feb 6 04:54:33 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 08B411201B7; Thu, 6 Feb 2020 04:54:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-perc-srtp-ekt-diet@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org, suhasietf@gmail.com, perc@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <158099366902.12347.15708611914046375594.idtracker@ietfa.amsl.com> Date: Thu, 06 Feb 2020 04:54:29 -0800 Archived-At: Subject: [Perc] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-perc-srtp-ekt-diet-11=3A_=28with_COMMENT=29?= 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: Thu, 06 Feb 2020 12:54:29 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-perc-srtp-ekt-diet-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-srtp-ekt-diet/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. Please find below two non-blocking questions. NB: the document shepherd write-up should be updated with the responsible AD ;-) Regards, -éric About section 4.3.1 What is a "packet" in the context of "appended to the packet"? Is it the UDP payload ? Should the UDP length be increased? is it the layer-2 frame ? I also wonder whether 250 msec is enough in all case... Unsure whether SRTP is only used in real-time communication (for info, just reviewed 2 I-D from Delay Tolerant Network... so I may be biased)