Options for Securing RTP Sessions
RFC 7201

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

(Richard Barnes) Yes

(Spencer Dawkins) Yes

Comment (2013-12-18 for -09)
No email
send info
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) Yes

Comment (2013-12-19 for -09)
No email
send info
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;-)

(Sean Turner) Yes

Comment (2013-12-19 for -09)
No email
send info
Thanks for this - definitely answered the mail.

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Martin Stiemerling) No Objection