Skip to main content

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

Yes

(Alexey Melnikov)
(Ben Campbell)

No Objection

(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)
(Suresh Krishnan)

Recuse


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

Roman Danyliw
No Objection
Comment (2019-05-15 for -10) Sent
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/
Warren Kumari
No Objection
Comment (2019-05-15 for -10) Not sent
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.
Éric Vyncke
No Objection
Comment (2019-05-15 for -10) Sent
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?
Alexey Melnikov Former IESG member
Yes
Yes (for -10) Unknown

                            
Alissa Cooper Former IESG member
Yes
Yes (2019-05-15 for -10) Sent
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?
Ben Campbell Former IESG member
Yes
Yes (for -10) Unknown

                            
Magnus Westerlund Former IESG member
(was Discuss) Yes
Yes (2019-08-29) Sent
Thanks for resolving the issues.
Alvaro Retana Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Barry Leiba Former IESG member
No Objection
No Objection (2019-05-12 for -10) Sent
— 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?
Deborah Brungard Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2019-02-28 for -10) Sent
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)...?
Suresh Krishnan Former IESG member
No Objection
No Objection (for -10) Not sent

                            
Adam Roach Former IESG member
Recuse
Recuse (2019-05-13 for -10) Not sent
I am an author.