I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avtcore-srtp-aes-gcm-14 Reviewer: Ben Campbell Review Date: 2014-09-11 IETF LC End Date: 2014-09-11 Summary: This draft is almost ready for publication as a proposed standard, but there are open issues that should be addressed first. Note: I have not attempted to verify the pseudocode fragments in this draft. Major issues: [Note: I am on the fence on whether the following is a major or minor issue. I put it in the major section to draw attention to it, but I am prepared to downgrade it if discussion seems to suggest doing so.] -- Section 9.4, SSRC Management If I read this section correctly, the draft requires central management of SSRC values when you have a master key shared among endpoints in a SRTP session, and goes so far to require authentication of data a central SSRC manager. This seems like a pretty big architectural change to the handling of SSRC that would likely be an impediment to deployment. I also have to wonder if such an SSRC manager could become a central point of attack. I note that RFC 3711, section 9.1 talks about what I gather is the same issue, and does not seem to call for a central SSRC manager. Are the requirements here that different than for 3711? Minor issues: -- General: There are a number of instances of 2119 normative language that I suspect do not define new normative requirements as much as repeat normative requirements from elsewhere (either in this draft, or from elsewhere.) This creates confusion on which text is authoritative, and creates an opportunity for inconsistent normative statements about the same thing. I strongly suggest that anytime you repeat or summarize normative text that is authoritatively stated elsewhere, you either use descriptive (non-normative) language (e.g., Foo is required to bar the baz), or clearly attribute the source (e.g. [XXX] says that foo MUST bar the baz.) -- References: The draft has normative down ref to RFC 3610. This was not explicitly mentioned in the IETF last call email, and does not appear to be included in the down ref registry. -- 8.1: If this draft contradicts normative language from RFC 3711, it should explicitly update 3711. -- 8.2 Can you offer guidance on when it might be (or not be) necessary to disguise the length of the plaintext? Especially how that might be known at the SRTP layer? -- 14.1: Does the master salt need to be kept secret? If the answer is "it depends", can you offer guidance? Also, can you offer a definition of "properly erased"? Nits/editorial comments: -- There is a citation of RFC2675, but it doesn't appear in the references. -- The abstract is out of place (Should be at beginning.) -- section 1, third paragraph: "... provides a high level of security ..." That may change over time. I suggest prefacing with "At the time of this writing..." -- section 3, last paragraph: Please expand IV on first mention. -- section 5.3, last paragraph: First and last sentence seem to contradict each other. -- 15.1: The IANA registration section for the SDES crypto-suites is oddly stated. That registry is just a table; the use of the srtp-crypto-suite-ext ABNF construction may be confusing.