Last Call Review of draft-ietf-avtcore-srtp-aes-gcm-14
review-ietf-avtcore-srtp-aes-gcm-14-genart-lc-campbell-2014-09-12-00

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.