SRTP Double Encryption Procedures
draft-ietf-perc-double-12

Note: This ballot was opened for revision 10 and is now closed.

(Ben Campbell) Yes

Alissa Cooper Yes

Comment (2019-05-15 for -10)
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?

Alexey Melnikov Yes

Magnus Westerlund (was Discuss) Yes

Comment (2019-08-29)
Thanks for resolving the issues.

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2019-05-15 for -10)
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/

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2019-05-15 for -10)
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.

Mirja Kühlewind No Objection

Comment (2019-02-28 for -10)
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)...?

Barry Leiba No Objection

Comment (2019-05-12 for -10)
— 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?

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2019-05-15 for -10)
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?

Adam Roach Recuse

Comment (2019-05-13 for -10)
I am an author.