Note: This ballot was opened for revision 10 and is now closed.
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?
Thanks for resolving the issues.
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/
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.
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)...?
— 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?
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?
I am an author.