Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
RFC 5764
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Lars Eggert No Objection
(Cullen Jennings; former steering group member) (was Discuss, Yes) Yes
(Pasi Eronen; former steering group member) Yes
(Chris Newman; former steering group member) (was Discuss, No Objection) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Ward; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Jon Peterson; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) (was Discuss) No Objection
Section 3: "This improves the cryptographic performance of DTLS, but may cause problems when RTCP and RTP are subject to different network treatment (e.g., for bandwidth reservation or scheduling reasons.)" The above sentence seems so backwards. If you multiplex them together then they can't be subject to different treatment. And the reasons seems to be wrong ones for arguing against multiplexing. The three main reasons why RTP and RTCP isn't multiplex as stated in the MUX draft are: Simplicity, effiency and 3rd party monitoring. Especially the last is hard to combine with encryption services, especially such that perform setup point to point.
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Tim Polk; former steering group member) No Objection
Section 4.2, immediately before Figure 1: A brief statement that the master key and master salt are provided to the SRTCP key derivation function seems to be missing here. These invocations are implied by Figure 1, but are conspicuously absent from the text.