Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)
draft-ietf-perc-double-12

[Ballot discuss]


1. Section 5.1:

To me it appears that one fundamental security flaw exists in the definition of the inner encryption. That is the fact that RTP padding is not included into the inner encrypted part. This prevents the application of RTP padding to prevent the potential privacy leakage that "Guidelines for the Use of Variable Bit Rate Audio with Secure RTP" (RFC 6562) documents. To prevent this type of information leakage and other privacy preserving operations based on applying RTP padding it would be necessary to include the RTP padding into the inner encrypted envelope. Appendix A figure indicates that is the case, but the process description in 5.1 is not matching that.

2. Section 5.1:

  1.  Form an RTP packet.  If there are any header extensions, they
      MUST use [RFC8285].

I got the impression from the framework that it was possible to have some header extension being encrypted using the inner key as (Section 4:3) says:

  If there is a need to encrypt one or more RTP header extensions end-
  to-end, the endpoint derives an encryption key from the E2E SRTP
  master key to encrypt header extensions as per [RFC6904].

That is missing from this step as it can't be applied in step 4. And shouldn't the headers protected in this fashion with the inner keys be part of the authenticated synthetic packet?

3. Section 5.2:

This is minor but still a significant inconsistency:

  3.  A Media Distributor can add information to the OHB, but MUST NOT
      change existing information in the OHB.  If RTP value is changed
      and not already in the OHB, then add it with its original value
      to the OHB.

4.  If the Media Distributor resets a parameter to its original
      value, it MAY drop it from the OHB.  Note that this might result
      in a decrease in the size of the OHB.

So reseting back to original value, is according to 3 not allowed. I think the MUST NOT is wrongly formulated. I assume that the point is that any field value carrying an original value MUST NOT be changed, however, if the field is changed back to its original value, the value SHALL/SHOULD be removed from the OHB?

4. Section 5.2:

... SHOULD use an independent salt for each recipient,

Is that possible on any other legs than MD to MD? What has been statated is that all end-point are required to use the same sal for a session as that is not included in the EKT. Putting a SHOULD requirement on something that is not possbile appears counter productive.

5. Section 7.1:

This section fails to make it clear why RTX packets are retransmitting the double encrypted packets. In normal application of SRTP the buffered packet and what is used for constructing the RTX packet is the unencrypted one. Thus the equivalent for an MD would be to handle the Inner protected only in its cache. Is the reason that an endpoint that recovers a packet anyway have to pass it through the double decryption process and thus it is to avoid a exception case for the endpoint? If that is the case, please note it in the text.

6. Section 7.2:

I fail to see how one can follow this procedure and generate anything that is workable. The reasons is that that the primary encoding and each of multiple redundancy encoding all share the same SSRC and have no independent sequence number space or timestamp space. Thus, I don't see how it is possible to create inner encrypted payloads for each of the primary and redundnacy encoding without two time pads. Why wasn't the simple choice applied here. That is to treat RED as a single endpoint to endpoint format. Thus making it robust if packets are lost on the path, but the MD's can't recreate a packet based on a redundancy paylaod and inject that instead.

I don't see how that this is a correct statement. As RED does not have different SSRCs for the different media encodings what it does can't be represented in FlexFEC.

"Note that Flex FEC [I-D.ietf-payload-flexible-fec-scheme] is a
  superset of the capabilities of RED.  For most applications, FlexFEC
  is a better choice than RED."

7. Section 9:
When this is done, the cryptographic
  contexts used for decryption and re-encryption MUST use different,
  independent master keys and master salts.

Related to discuss item 4 and here at different RFC 2119 levels.


8. Section 9. The use of AES-GCM as symmetric algorithms results in that the source authication level for the inner part has a limited scope, in that any endpoint can create a double protected packet, not only the one that which SSRC it is as there are no cryptographic protection on that level. I think that point is significant for something that is primarily targeting group communication scenarios.

[Ballot comment]
A. Section 3.1:
  Here "PRF_n(k, x)" represents the AES_CM PRF KDF [RFC3711] for
  DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM algorithm and AES_256_CM_PRF
  KDF [RFC6188] for DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM algorithm.

I would recommend that you are a bit more specific about your references. So for the AES_CM PRF I think that should actually point to section 4.3.3 or at least 4.3 of RFC 3711.

B. Section 1 and 4:

Section 1 says:
    In that
  case, the original value of any RTP header field that is changed is
  included in a new RTP header extension called the Original Header
  Block.

Section 4 says:
In the encryption process, the OHB is
  appended to the RTP payload.

I assume it is 1 that should be changed and this is a missed case of moving the OHB from header extensions to encryption payload.

C. Section 4:

In the encryption process, the OHB is
  appended to the RTP payload.

I think that is a bit imprecise.

Considering the diagram in Appendix A.

      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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<++
    |V=2|P|X|  CC  |M|    PT      |      sequence number        | IO
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
    |                          timestamp                          | IO
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IO
    |          synchronization source (SSRC) identifier            | IO
    +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ IO
    |            contributing source (CSRC) identifiers            | IO
    |                              ....                            | IO
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
    |                    RTP extension (OPTIONAL) ...              | |O
+>+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O I |                          payload  ...                        | IO
O I |                              +-------------------------------+ IO
O I |                              | RTP padding  | RTP pad count | IO
O +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+O
O | |                    E2E authentication tag                    | |O
O | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |O
O | |                            OHB ...                            | |O
+>| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |+
| | |                    HBH authentication tag                    | ||
| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||
| |                                                                  ||
| +- E2E Encrypted Portion              E2E Authenticated Portion ---+|
|                                                                      |
+--- HBH Encrypted Portion              HBH Authenticated Portion ----+

If we follow the figure, but I am uncertain as seen by Discuss 1. The OHB is added after the inner protected part (RTP paylaod, RTP padding and E2E authentication tag).


D. Section 5.1:

  5.  Replace the header of the protected RTP packet with the header of
      the original packet, and append an empty OHB (0x00) to the
      encrypted payload (with the authentication tag) obtained from the
      step 4.

I assume that this should say
  5.  Replace the header of the protected synthetic RTP packet with the header of
      the original packet (to restore any header extensions), and append an empty OHB (0x00) to the end of the encrypted payload (with the authentication tag) obtained from the step 4.

E. Section 5.2:

  In order to modify a packet, the Media Distributor decrypts the
  received packet, modifies the packet, updates the OHB with any
  modifications not already present in the OHB, and re-encrypts the
  packet using the the outer (hop-by-hop) cryptographic key before
  transmitting.

I think this text should be clear that the applied key for the encryption is not the same as the one used for the decryption as it is depending on who is the next hop receiver, if that is MD or another endpoint. The text after the bullet list could be more specific to point.

This comment applies to bullet 1 and 5 that should be clarified on that.

F. Section 5.2: Bullet 2:
Should mentions that some header extensions may be changed.

G. Section 8:

If no other header extensions are present in the
  packet and the OHB is introduced, that will consume an additional 8
  octets.  If other extensions are already present, the OHB will
consume up to 4 additional octets.  Packets in repair mode will carry
  additional repair data, further increasing their size.

More leftovers from change from header extension to payload for OHB.

[Ballot comment]
Thanks for this draft.  A few comments:

(1) Section 5.1.  Step 5.  Is the “protected RTP packet” the same as the “synthetic” RTP packet?  If so, I recommend using consistent language.

(2) Section 5.1. Step 5.  Recommend making this text, “append an empty OHB (0x00) to the encrypted payload (with the authentication tag)”, more explicit in stating that concatenation of bytes is encrypted payload + authentication tag + OHB.

(3) Editorial:
** Section 5.2.  Typo. s/the the/the/
** Please review the editorial comments in the SECDIR review
https://datatracker.ietf.org/doc/review-ietf-perc-double-10-secdir-lc-perlman-2018-10-31/

[Ballot comment]
NoObj in the "I read the protocol action, and I trust the sponsoring AD so have no problem and / or this is outside my area of expertise or have no cycles." meaning.

[Ballot comment]
Thanks for the work everyone has put into this document. I have one comment.

I like the fact that this document allows for multiple 'media distributors' on the path, each modifying the 'original header'.


Comment / question:
- section 5.2, point 4 implies that the OHB can be dropped while I understand the efficiency effect to it (or even topology hiding), isn't also removing useful traces / audit trails?

[Ballot comment]
Glad to see this work progressing.

Section 2: Why not use or reference the definitions of terms in draft-ietf-perc-private-media-framework rather than defining them differently here?

[Ballot comment]
— Section 2 —

In the definition of “hop-by-hop”:
The definition of “end-to-end” says there can be more than one distributor.  So, can’t a hop also be distributor to distributor (not involving an endpoint)?

Also, the definition is really of “hop”, rather than of “hop-by-hop”, isn’t it?

— Section 3 —

  The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is
  AES-GCM.  Other combinations of SRTP ciphers that support the
  procedures in this document can be added to the IANA registry.

Is there an implication that the cipher used MUST be one that is in the registry?  If so, it should say that.

  o  the SSRC is the same for both the inner and out outer algorithms

Extra word “out”.

  If the Media Distributor is to be able to modify header fields but
  not decrypt the payload, then it must have cryptographic key for the
  outer algorithm, but not the inner (end-to-end) algorithm.

Missing article, “the cryptographic key”.

— Section 4 —

  to verify the E2E integrity of the packet.

Because you explicitly define “end-to-end” and generally use that term (24 times), I suggest being consistent and not using “E2E” (5 times) also.  Alternatively, you could add “or E2E” to the definition in Section 2.  (Similarly for “HBH”.)

— Section 5.2 —

Doesn’t bullet 4 contradict 3?  If I’m allowed to change something back to its original value and drop it from the OHB, then I’m clearly changing information in the OHB.  Maybe a little rewording would be useful.

— Section 8 —

  These algorithm provide
  for authenticated encryption and will consume additional processing

Should be “These algorithms”.

— Section 10.1 —

  The SRTP transform parameters for each of these protection are:

The word “protection” isn’t right.  Do you want “protection profiles” here?

[Ballot comment]
I would believe that it would be useful to add a reference to RFC3550, especially as PT, SEQ, and M are referenced. Maybe even spell out what those abbreviations mean. Also maybe the doc could say a little more why it is important for an MD to be able to modify these values (given the original values have to be attached for decryption purposes anyway)...?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-perc-double-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the DTLS-SRTP Protection Profiles registry on the Datagram Transport Layer Security (DTLS) Extension to Establish Keys for Secure Real-time Transport Protocol (SRTP) registry page located at

https://www.iana.org/assignments/srtp-protection/

the two existing temporary registrations:

{0x00, 0x09} DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM
{0x00, 0x0A} DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM

will be made permanent, with their references changed to [ RFC-to-be ].

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-11-01):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, draft-ietf-perc-double@ietf.org, suhasietf@gmail.com, perc@ietf.org, Suhas Nandakumar , perc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SRTP Double Encryption Procedures) to Proposed Standard


The IESG has received a request from the Privacy Enhanced RTP Conferencing
WG (perc) to consider the following document: - 'SRTP Double Encryption
Procedures'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  In some conferencing scenarios, it is desirable for an intermediary
  to be able to manipulate some parameters in Real Time Protocol (RTP)
  packets, while still providing strong end-to-end security guarantees.
  This document defines a cryptographic transform for the Secure Real
  Time Protocol (SRTP) that uses two separate but related cryptographic
  operations to provide hop-by-hop and end-to-end security guarantees.
  Both the end-to-end and hop-by-hop cryptographic algorithms can
  utilize an authenticated encryption with associated data scheme or
  take advantage of future SRTP transforms with different properties.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-perc-double/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-perc-double/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD Evaluation of draft-ietf-perc-double-09. Thanks for this work; I think it is important and on the right track, but suffers from some readability issues, especially from §7 onwards. I’d like to discuss my comments prior to IETF last call.
—————————————————

*** Substantive Comments ***

General: Does it make sense to progress this prior to draft-ietf-perc-private-media-framework rather than wait and progress them together? it seems like one really needs to read the framework to understand at least parts of this draft. (Which would, btw, suggest making the framework a normative reference.)

§2, Media Distributor: Should this be defined as switch-based? Otherwise it seems circular.

§5 and subsections: These sections are confusing in the treatment of extensions. §5.1 step 3 says to truncate the header to remove any extensions. Yet other sections of text repeatedly mention the handling of extensions. I think the document needs a paragraph or two to describe the handling of RTP extensions at a high level.

Along those lines, it’s not entirely clear what is meant by putting “ (12 + 4 * CC bytes)” in parentheses after the guidance to truncate in §5.1. Is that the amount to be truncated? Amount left after truncation? (Same question for §5.3)

§5.2: It would be helpful to include a paragraph or two to describe the impact if multiple MDs modify the same field(s). I can infer that, but it would be better to be explicit. (IIRC, there is a passing mention in the security considerations, but it would be better to have more here.)

§8: Can you offer any guidance about selecting 128 vs 256?

§9:

- The security considerations mainly summarize the mechanism. I’d like to see a description of the potential attacks or risks  and how the double mechanism mitigates them.

- “… this shouldn’t typically impact the strength of e2e integrity given the fact that there doesn’t exist header extensions defined today that needs e2e protection.  However, if future specifications define header extensions that needs e2e integrity protection, the input to inner transform may be modified to consider including the header.”

- 2nd paragraph: Why is the HBH key for an outgoing packet only “typically” different than the key for the incoming packet? Are there security implications if they are the same?

- 2nd to last paragraph, last sentence: Please elaborate on those risks?

*** Editorial comments and nits ***

There are a number of abbreviations that need to be expanded on first use. Please remember that abbreviations should be expanded both in the abstract and the body.

- SRTP
- SSRC
- SEQ
- ROC
- PRF
- PT
- SEQ
- RTX
- RED
- FEC

§2:
- Please use the boilerplate from RFC8174. There are a number of lower case instances of normative keywords.
- Please use consistent sentence (or lack of sentence) structure for the definitions in the bullet list.

§3,

- " Generate key and salt values of the length required for the combined inner (end-to-end) and outer (hop-by-hop) algorithms.”: The document is inconsistent in whether it describes a single key with inner and outer halves, or separate inner and outer keys. I realize that this is an artifact of syntax, but it is likely to confuse a reader new to the topic.

- Paragraph starting with “Obviously, if the Media Distributor…”: “Obviously” is a null word in context.

§3.1: This section would be much more approachable if you defined the terms (such as n, k, and x), rather than forcing readers to look them up in 3711. Also, the doubled crypto suite IDs are likely to be confusing to the reader who sees them here without the explanation later in the draft.

§5.2, step 2: “Change any parts of the RTP packet…” -The MS is limited to changing the 3 fields defined for the OHB, right, at least as defined in this draft? Not just anything it wants?

§5.3, last two paragraphs: It’s sort of an odd construction to talk about “any of the following” with a single entry list.

§7 and subsections: These could use another proofreading pass. In particular, it is imprecise about inner vs outer encryption, which actors do what, and has a number of pronouns with ambiguous antecedents. The heavy use of passive voice obscures the actors in multiple places. I will call out some specifics, but please do not treat my comments as exhaustive.

§7: “ The repair mechanism, when used with double, typically operates on the double encrypted data and encrypts
  them using only the HBH key.” Does “double encrypted” mean “outer encrypted”? Also, while I recognize “data” as plural, it’s plural in a non-countable sense; that is, s / them / it.

§7.1:
- “ … cached payloads MUST be the encrypted packets …” - Inner or outer? What device enforces this? (Consider active voice.)
- Which element represents “the other side”? Are we talking about an endpoint or MD? (Please stick to the defined terminology)
- “ When encrypting a retransmission packet, it MUST be encrypted the packet in repair mode.” - I can’t parse the phrase after the comma. Also, what device MUST encrypt it?

§7.2:
- “the primary encoding MAY contain…” - Is that MAY a grant of permission or a statement of fact?

- " The sender takes encrypted payload from the cached packets”- Missing article for encrypted payload? Or should this say “… takes encrypted packets from the cached payload…”?

- “ Any header extensions from the primary encoding are copied to the RTP packet that will carry the RED payload and the other RTP header information such as SSRC, SEQ, CSRC, etc are set to the same as the primary payload.  The RED RTP packet is then encrypted in repair mode and sent.”: This is confusing; parts are copied from the primary encoding and others are the same as in the primary encoding? Don’t both of those mean the same thing?

- “ The receiver decrypts the payload…”: Endpoint or MD? Is this inner or outer encryption?

- Last paragraph: Seems like that belongs in the FEC section. Also, does this document really need to make that sort of recommendation? It seems like a general statement about RED and FEC that is not specific to double.


§7.3:

- "When using Flex FEC [I-D.ietf-payload-flexible-fec-scheme] with double, the negotiation of double for the crypto is the out of band signaling that indicates that the repair packets MUST use the order of operations of SRTP followed by FEC when encrypting.” - The sentence is hard to parse. Also, is MUST a normative requirement or a statement of fact? (It seems odd to signal that you MUST do something).

- “…  data, which is already encrypted, it MUST be encrypted in repair mode packet.” s/ “, which” / “that”. Also, what actor MUST encrypt the data in repair mode? (Consider active voice.)

- “ The algorithm recommend…” s / recommend / recommended

§7.4:
- s/ "sent with [RFC4733]” / “sent using the mechanism in [RFC4733]”
- “ and the relay can not read it so it cannot be used” - missing comma between “it” and “so”.

§8, last paragraph: “ For packets in repair mode, the data they are caring is often already encrypted further increasing the size.” - I assume “caring” is not the intended word. Did you mean “carrying”? If so, consider s / “data they are carrying” / “data they carry”.

§9:
- “... all the RTP fields except headers created by the sender…” Does that mean all the fields created by the sender except headers? Or all the fields other than the headers created by the sender?

- s/ + / and

- “… this shouldn’t typically impact the strength of e2e integrity given the fact that there doesn’t exist header extensions defined today that needs e2e protection.” - hard to parse

- " However, if future specifications define header extensions that needs e2e integrity protection, the input to inner transform may be modified to consider including the header.” s/ “consider including the header” / “include the header”

- s/ “It is obviously critical” / “It is critical”

- “… the outer (hop-by-hop) algorithm key and not the half of the key … “ inconsistent in talking about H2H key vs half-key.

- 11: It’s awkward to use “Thank you” when addressing 3rd persons. I suggest something like “Thanks for …  go to …” or “The authors would like to thank … for…”

- 12.2: It seems like some of these need to be normative:  [I-D.ietf-payload-flexible-fec-scheme], maybe [I-D.ietf-perc-private-media-framework], and [RFC4733].

- Appendix A: Why is this relegated to an appendix? I think would be helpful in the main body of the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

draft-ietf-perc-double is targeted at the Standards track,
and this write­up is for Proposed Standard. This is reflected on the title page
and in the data tracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document define SRTP procedures for enabling end to end media
confidentiality and integrity for end-points in a Multimedia conferences.
It does so by defining 2 types of SRTP transforms - outer and inner.
The inner transform is responsible for ensuring end-to-end integrity
and encryption. The outer transform covers integrity and encryption
hop-by-hop (between endpoints and the media distributor or between
the media distributors).

Working Group Summary

This document has been discussed and reviewed several times by the
WG. There were few individuals with concerns regarding the
following areas
1. Allow Media distributor (MD) to modify the SSRC field
in the RTP header. However they weren't able to propose
solutions that can mitigate the SSRC splicing attack
identified by the WG. Also to note, the WG had previously
reached consensus on non-modifiability of the SSRC by the
media distributor. However, the discussion was re-opened to
help the concerned individual to put forward the proposals.
But as aforementioned, there was no proposal submitted that
satisfactorily addressed the splicing attack. Hence the
WG decided to go forward with previously reached consensus to
not allow MD to modify the SSRC.

2. Mechanisms to carry the end to end scoped payload header information:
Originally the proposal was to carry such information as an
RTP header extension. However, there was a proposal to
carry similar information as the payload header. The authors of the
document made accommodations to work out a solution that addressed
the concern. This involved moving the OHB from header extension to
payload header as part of the endpoint procedures.

The chairs called for consensus - in-room and on-list -, there was
support to go with the procedures defined in the current version
of the specification. Even though there are few individuals who aren't
totally happy, the WG had consensus on the proposals.


Also there were discussions on solution approaches for dealing
with the repair packets. Two possible solutions were discussed. One was
related to applying the hop-by-hop transform for the repair packet on
the single encrypted packet vs double encrypted packet. The former
implying a split in SRTP transform context states (E2E, RTX, HBH) and
the latter implying a simple canonical way of doing classic SRTP
(But just with a new transform called double). Hence the latter approach
was chosen given its simplicity of implementing on plethora of end-points
versus acceptable extra processing needed on relatively lower number of MD implementations.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

libsrtp, a widely used SRTP library in commercial and open source
SIP  and Webrtc products, has a branch with the implementation
for double encryption procedures as defined in this specification.
This document did not require expert review of the types noted.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

The document shepherd is Suhas Nandakumar; the responsible Area Director is Ben Campbell.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

This document has been reviewed and discussed several times with in
the WG. Issues and concerns brought out were significantly discussed
across several working group meetings (in-person and as part of virtual interims and design meetings.)

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

I do not have any concerns about the working group reviews to date.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Security review is welcomed since this document defined SRTP
procedures.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

As noted above, there were few individuals with concerns, but the
chairs were able to reach consensus in support of the specification.
ADs are made aware of this situation and were closely involved
throughout the process.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No IPR has been filed on this document

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The working group as a whole concurs with this approach.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

There were few instances of appeal as mentioned earlier. Responsible
ADs are already made aware of this situation.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No nits were found when verified on the version
draft-ietf-perc-double-09.txt

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

This document does not present the need for these reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

Not applicable.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no requests for downward references.


(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

This document does not change the status of any existing RFC.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document requests an update to an existing registry
(SRTP Protection Profile); The update is not controversial within
the working group. 

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document does not request new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

ABNF content in the document was validated with
https://tools.ietf.org/tools/bap/abnf.cgi