Subject: [AVTCORE] comments on draft-ietf-avtcore-rtp-security-options-04

From: Dan Wing <[email-masked]>
Date: Thu, 15 Aug 2013 19:18:28 -0700

Overall a strong document, and I know it was difficult to write.

My comments:

In the Introduction, the end of
   Because of the heterogeneity of
   RTP applications and use cases, however, a single security solution
   cannot be mandated. 
feels like it could include a citation back to draft-ietf-avt-srtp-not-mandatory.

In section 3.1, Depending on when AES-GCM is published compared to when draft-ietf-avtcore-rtp-security-options is published, updating the following paragraph might be prudent (so it no longer says "ongoing work", as it will be published work at that point),
   AES-GCM:  There is also ongoing work to define AES-GCM (Galois
      Counter Mode) and AES-CCM (Counter with CBC) authentication for
      AES-128 and AES-256.  This authentication is included in the
      cipher text which becomes expanded with the length of the
      authentication tag instead of using the SRTP authentication tag.
      This is defined in [I-D.ietf-avtcore-srtp-aes-gcm].

In section 3.1.1, 
s/cipher suits/cipher suites/

Section 3.1.4, suggest changing
OLD:
   This can enable interworking between DTLS-SRTP and for
   example security descriptions or other keying systems where either
   part can set the key.
NEW:
   This can enable interworking between DTLS-SRTP and 
   other keying systems where either party can set the key (e.g., 
   interworking with security descriptions).
(original says "either part", should say "either party").

Section 3.4 for consistency with the section title and the rest of the section's text, I suggest:
OLD:
   There does not appear to be significant usage of RTP over DTLS.
NEW:
   There does not appear to be significant usage of DTLS for RTP.

Section 3.6 says:
   Mechanisms have been defined that encrypt only the payload of the RTP
   packets, and leave the RTP headers and RTCP in the clear.  
which immediately made me think, "ah, like SRTP."  But then the rest of the section goes on to describe non-SRTP object encryption (DRM).  Can that first sentence somehow be made clearer that this section is not describing SRTP encryption, but object encryption?  Afterall, SRTP also leaves RTP headers in the clear.  Also, the title of the section is "Payload-Only Security Mechanisms", but the second paragraph discusses the need for transport security (which is not 'payload security').  Perhaps the section could be renamed to "Object Security" or "Digital Rights Management" or some other term, so that the payload security and transport security can both be discussed without exceeding the scope of the section title.

Section 4.1.1,
s/might provided/might provide/

Section 4.1.3, Changing from "I", "you", and "your" to "host" and "peer" would keep this section more consistent with the rest of the document.

Section 4.1.3, I had some technical heartburn over these two paragraphs, which together make it seem like DTLS-SRTP is weaker than Security Descriptions, and the text claims this weakness is because DTLS-SRTP sends the certificate hash over signaling whereas Security Descriptions sends the session key over signaling:
      For example, consider a point-to-point communication system that
      uses DTLS-SRTP using self-signed certificates for key management,
      and SIP for signalling.  In such a system the end-points for the
      DTLS-SRTP handshake have securely-established keys that are not
      visible to the signalling nodes.  However, as the certificates
      used by DTLS are not bound to any PKI they can't be verified.
      Instead, hashes of the certificate are sent over the signalling
      path.  If the signalling can be trusted not to collaborate on
      performing a man-in-the-middle attack by modifying the hashes,
      then the end-points can verify that they have established keys
      with the peer they are doing signalling with.

      Systems where the key-exchange is done using the signalling
      systems, such as Security Descriptions [RFC4568] or MIKEY embedded
      in SDP [RFC4567], enable a direct binding between signalling and
      key-exchange.  Independent of DTLS-SRTP or MIKEY in SDP the actual
      security depends on the trust one can place in the signalling
      system to correctly associate the peer's identity with the key-
      exchange.

Of course, DTLS-SRTP does not need to rely solely on trust for identity, which is described elsewhere in this same document.  RFC4474 or a later section of this same document should be cited in that first paragraph (or in the Using Identities section, whichever the authors prefer), as RFC4474 provides a way to ensure the DTLS-SRTP certificates are bound to the identity provider's public key.  Yes, RFC4474 has some deficincies and perhaps those should be mentioned briefly (doesn't survive going through an SBC, for example).  I would add a citation and description of RFC4474 to that first paragraph discussing DTLS-SRTP.

The second paragraph I quoted of Section 4.1.3, I am confused that its first sentence discusses Security Descriptions and MIKEY, but the paragraphs second sentence starts with "Independent of DTLS-SRTP or MIKEY in SDP" -- is this an editing mistake and that second sentence supposed to read "Independent of **security descriptions** or MIKEY" ??  If it is not an editing mistake, I admit I cannot parse that second paragraph and it would benefit from a rewrite to make its point more clear.

Section 4.1.5 on privacy mentions relays.  It might be useful to add a citation to TURN as an example of a relay.

Section 5.1:
OLD:
   At the basic level DTLS has a number of good security properties.
   For example, to enable a man in the middle someone in the signalling
   path needs to perform an active action and modify the signalling
   message.
NEW:
   At the basic level DTLS has a number of good security properties.
   For example, to enable a man in the middle someone in the signalling
   path needs to perform an active action and modify both the signalling
.....................................................^^^^
   message and the DTLS handshake.
...........^^^^^^^^^^^^^^^^^^^^^^^

Also, what is meant by "At the basic level"?  That wording implies there an identified problem/weakness at some other level (advanced level).

Section 5.2, 
   Unless one uses a Identity provider and the proposed identity
   solution [I-D.ietf-rtcweb-security-arch], the web application still
   has the possibility to insert a MITM. 

There are other ways to detect and prevent insertion of a MitM other than an Identity provider -- such as verifying the certificate hash out of band (verifying it matches what is printed on a business card, or verifying the hash is the same as the previously-used hash with that same user as described by ZRTP, as two examples).  Could that be re-worded so that Identity provider is just one way to avoid insertion of MITM?

Section 5.2,
      Prevent tracking between sessions:  RTP CNAMEs and DTLS-SRTP
      certificates provide information that could possibly be re-used
      between session instances.  Thus to prevent tracking, the same
      information can't be re-used between different communication
      sessions.
Yes, but another solution (allowing the re-use of DTLS-SRTP certificates, thus saving CPU resources to create new public/private key pairs) is to have better TLS handshake, such as is being pursued for TLS 1.2 so the certificates are exchanged later in the TLS exchange (after the session is encrypted).  I would suggest:
OLD:
      Prevent tracking between sessions:  RTP CNAMEs and DTLS-SRTP
      certificates provide information that could possibly be re-used
      between session instances.  Thus to prevent tracking, the same
      information can't be re-used between different communication
      sessions.
NEW:
      Prevent tracking between sessions:  static RTP CNAMEs and DTLS-SRTP
      certificates provide information that is re-used
      between session instances.  Thus to prevent tracking, the information
      is not re-used between sessions or the information is not sent in the
      clear between sessions.

Section 5.3, I suggest:
OLD:
   If these goals are to be meet with the specified
   solution there needs to exist trust in that neither the
   implementation of the client nor the platform the application runs
   can be accessed or modified by the attacker.
NEW:
   To meet these goals with the specified solution the client 
   implementation and the application platform are trusted to 
   protect against access and modification by an attacker.

-d

---

From: Colin Perkins <[email-masked]>
Date: Thu, 29 Aug 2013 13:13:15 +0100

Dan,

Thank you for the detailed review. These are all good comments, which we'll address in the next version. 

Addressing the comments on Section 4.1.3 and 5.2 required some fairly extensive text changes. I'd be grateful if you could check these when the revised draft appears. 

Cheers,
Colin

On 16 Aug 2013, at 03:18, Dan Wing <[email-masked]> wrote:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

-- 
Colin Perkins
http://csperkins.org/