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

[Colin Perkins <[e-mail]>]

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 <[e-mail]> wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt



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