Options for Securing RTP Sessions
draft-ietf-avtcore-rtp-security-options-10

[Ballot comment]

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;-)

[Ballot comment]
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.

[Ballot comment]
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 that's 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 on the first occurence.

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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-avtcore-rtp-security-options-09, which is
currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Options for Securing RTP Sessions) to Informational RFC


The IESG has received a request from the Audio/Video Transport Core
Maintenance WG (avtcore) to consider the following document:
- 'Options for Securing RTP Sessions'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Real-time Transport Protocol (RTP) is used in a large number of
  different application domains and environments.  This heterogeneity
  implies that different security mechanisms are needed to provide
  services such as confidentiality, integrity and source authentication
  of RTP/RTCP packets suitable for the various environments.  The range
  of solutions makes it difficult for RTP-based application developers
  to pick the most suitable mechanism.  This document provides an
  overview of a number of security solutions for RTP, and gives
  guidance for developers on how to choose the appropriate security
  mechanism.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-security-options/ballot/


No IPR declarations have been submitted directly on this I-D.