Options for Securing RTP Sessions
Note: This ballot was opened for revision 09 and is now closed.
(Richard Barnes; former steering group member) Yes
(Sean Turner; former steering group member) Yes
Thanks for this - definitely answered the mail.
(Spencer Dawkins; former steering group member) Yes
This was an awesome document, and very helpful for me (I've spent most of my recent IETF years in RAI, but never on the media side). Thank you and the working group for producing it. I have a small number of comments, all about points of clarity. Please consider them along with any other feedback you receive. In section 3.1.1. Key Management for SRTP: DTLS-SRTP DTLS-SRTP usage is clearly on the rise. It is mandatory to support in WebRTC. It has growing support among SIP end-points. DTLS-SRTP was developed in IETF primarily to meet security requirements for SIP. The actual security properties of an established SRTP session using DTLS will depend on the cipher suites offered and used, as well as the mechanism for identifying the end-points of the hand-shake. For example some cipher suits provide perfect forward secrecy (PFS), while other do not. I can guess what perfect forward secrecy is, but I'm guessing. The term appears four times in this draft, and the only reference is given the fourth time the term is used, pointing to http://tools.ietf.org/html/rfc4949. That RFC says this: $ perfect forward secrecy (I) For a key agreement protocol, the property that compromises long-term keying material does not compromise session keys that were previously derived from the long-term material. (Compare: public-key forward secrecy.) Usage: Some existing RFCs use this term but either do not define it or do not define it precisely. While preparing this Glossary, we found this to be a muddled area. Experts did not agree. For all practical purposes, the literature defines "perfect forward secrecy" by stating the Diffie-Hellman-Merkle algorithm. The term "public-key forward secrecy" (suggested by Hilarie Orman) and the definition stated for it in this Glossary were crafted to be compatible with current Internet documents, yet be narrow and leave room for improved terminology. If "muddled area" is still accurate (I'm not remotely an expert), it might be helpful to include a definition that is actually what you meant, but even if the term is now perfectly clear, it would be helpful to have a reference the first time the term is used. Also in section 3.1.1 DTLS-SRTP usage is clearly on the rise. It is mandatory to support in WebRTC. It has growing support among SIP end-points. DTLS-SRTP was developed in IETF primarily to meet security requirements for SIP. This paragraph is true, but might be more useful to the reader if the last sentence continued, "security requirements for SIP, such as ..." - SIP has really broad applicability (people proposed using SIP for SmartGrid control, and it would have worked), so helping people understand what problems STLS-SRTP was solving might be helpful. Section 5.1 has some clues about this, but being specific would be helpful to readers who aren't familiar with previous discussions about media security in RAI. In section 3.1.5. Key Management for SRTP: Other systems The ZRTP [RFC6189] key-management system for SRTP was proposed as an alternative to DTLS-SRTP. ZRTP provides best effort encryption independent of the signalling protocol and utilizes key continuity, Short Authentication Strings, or a PKI for authentication. ZRTP wasn't adopted as an IETF standards track protocol, but was instead published as an informational RFC. Commercial implementations exist. Additional proprietary solutions are also known to exist. It was very easy for me to miss the part where the section was talking about "other systems _besides ZRTP_". The text isn't wrong, but might be clearer if the section title was something like "Key Management for SRTP: ZRTP and Other systems". If the the section header and second paragraph used the same noun (either both "systems" or both "solutions"), that would also work.
(Stephen Farrell; former steering group member) Yes
Thanks for doing this one! - 4.1.3/4.1.4/4.1.4, "Using Identities" would be better if stated in terms of identifiers and not identities. That might conflict with the common (but incorrect) use of the term identify in SIP though, and it might be ok to go with the broken-but-common usage. - 4.1.4, Certificates don't prove identity. The verification with a public key from a cert of the use of a private key is good evidence that the itentifiers in the cert relate to the holder of the private key. While that is a fairly pedantic distinction compared to the text of the draft, its still better to get it right. Mind you, I'm not sure if that'll make so much difference;-)
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection