Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)
Note: This ballot was opened for revision 07 and is now closed.
(Pasi Eronen) Yes
(Cullen Jennings) (was Discuss, Yes) Yes
(Jari Arkko) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Russ Housley) No Objection
(Chris Newman) (was Discuss, No Objection) No Objection
(Jon Peterson) No Objection
(Tim Polk) No Objection
Comment (2008-11-06 for -)
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.
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
(David Ward) No Objection
Magnus Westerlund (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.