I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document specifies a syntax for doubly encrypting Secure Real Time
Protocol (SRTP) packets so that the inner (media) content is encrypted with
a key known only to the endpoints while some header content is encrypted
with a separate key known by both the endpoints and network relay points
called Media Distributors (with the outer encryption key (usually) changing
on each hop).

Below are details for consideration by the authors and other potential
security reviewers.

Substantive comments:

Page 2 First paragraph:
AES-GCM is the only specified cryptographic mode, but may not be the
appropriate mode to use in distributing this content because there may be
cases where we want to guarantee the integrity of the data end-to-end while
allowing intermediaries to see the content. To support this case, it might
make sense to allow the encryption and integrity protection keys to be
separate so that an intermediary might be given the encryption key but not
the integrity protection key.

As noted in section 8, the inner payload ends up being encrypted twice
(which is a substantial waste of resources). It might make more sense to
include the inner encrypted payload as additional authenticated data in the
outer invocation of AES-GCM to avoid that overhead.

Page 5 section 3.1 Key Derivation:
This section specifies how the end-to-end and hop-by-hop keys must be
derived from a single "master key". But this could only be true at the
source node and would imply the intermediaries are not allowed to see the
master key and the destination would not need to see the master key
(because by the time the destination receives the message the key used for
the outer encryption would be different.

I would expect that the inner and outer keys would be negotiated
independently and there would be no master key from which they are all
derived.

Page 5 Section 4:
If the set of RTP header fields is fixed and there is a fixed ordering to
them, this is OK. But it wasn't obvious to me how to reflect in the OHB the
difference between a new header field being added. And if fields are
deleted (and therefore added to the OHB), it's not obvious in what order
they should be reinserted by the ultimate recipient.

Page 6 Section 5:
The second paragraph says the extensions are truncated when computing the
inner checksum while the third paragraph says there is information in the
OHB to reconstruct the original extensions to allow verification of the
inner checksum. Either of these two techniques could be used, but the
source and destinations must use the same one. Or is this specifying that
some combination be used?

Page 9 paragraph 1 says:
"A Media Distributor that decrypts, modifies, and re-encrypts packets
   in this way MUST use an independent key for each recipient, SHOULD
   use an independent salt for each recipient, ..."
This represents substantial additional work for the Media Distributor. If
it is important to use an independent key for each recipient, some
justification should be noted. The likely one is that it prevents one
recipient from undetectably modifying the copy of data sent to another
recipient. This protection is not needed in all scenarios, and so perhaps
should be optional.


Editorial Comments / Typos:

Page 2 Second paragraph:
There may be a word missing. What is "the double"? Also, throughout the
document the  protocol is referred to as "double", which if intended should
probably be listed in section 2.

Page 2 Last line:
If multiple Media Distributors are allowed, hop by hop also refers to the
path between two Media Distributors.

Page 8 Section 5.2 bullet 2:
<fields are allowed> -> <fields that are allowed>

Page 11 section 7.1 paragraph 1
I suspect there is a word or two missing. "it MUST be encrypted the packet
in repair mode" sounds like something Yoda would say.

Page 13 section 9 last paragraph says:
"If the MD doesn't modify any header fields,
   then an MD that supports AES-GCM could be unused unmodified."
This should say something like ...could use the same key and relay packets
unmodified.