Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-12.txt

From: [email-masked]
Date: Sat, 14 Jan 2017 22:41:04 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the ControLling mUltiple streams for tElepresence of the IETF.

        Title           : Mapping RTP streams to CLUE Media Captures
        Authors         : Roni Even
                          Jonathan Lennox
	Filename        : draft-ietf-clue-rtp-mapping-12.txt
	Pages           : 12
	Date            : 2017-01-14

Abstract:
   This document describes how the Real Time transport Protocol (RTP) is
   used in the context of the CLUE protocol.  It also describes the
   mechanisms and recommended practice for mapping RTP media streams
   defined in Session Description Protocol (SDP) to CLUE Media Captures.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 Jan 2017 15:57:03 +0100

Hi,

Looking at the update in the draft-12:

>   The CaptureID is created as part of the CLUE protocol.  The CaptId	
>   SDES item is used to convey the same CaptureID value in the SDES	
>   item.  When sending the SDES item the security considertion specied	
>   in the security section of [RFC7941] are applicable and this SDES	
>   item MUST use similar security as the CLUE protocol messages carried	
>   in the CLUE data channel.

I don't find this sufficient. First of all, there is no clarify of what 
the security treats to the CaptureId are. Secondly, the similar security 
here is far from trivial as the SCTPoDTLS data channel uses DTLS while 
RTP/RTCP security is the combination of the DTLS-SRTP and SRTP 
mechanisms in use. Note that from part of the security aspects DTLS-SRTP 
and DTLS is actually quite different.

I will note that I still haven't found the equivalent the RTCWeb 
security architecture document. Which actually discusses what protection 
profiles to support.

CLUE-Framework:

  In
    addition, the media MUST be secured. DTLS/SRTP MUST be supported
    and SHOULD be used unless the media, which is based on RTP, is
    secured by other means (see [RFC7201] [RFC7202]).  Media security
    is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-
    rtp-mapping].

In signalling this is also not specified:

All CLUE-
    controlled RTP "m" lines must be secured and implemented using
    mechanisms such as SRTP [RFC3711]; no specific security mechanisms
    are made mandatory to use due to the issues addressed in [RFC7202].

I would note, that the point of RFC 7202, is that "solutions" like CLUE 
is the one that shall make mandatory to implement choices. So that CLUE 
WG attempts to dodge that aspect is very worrying.

Then RTP-mapping:

    The Extended Secure RTP Profile for Real-time Transport Control
    Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides
    handling of fundamental issues by offering confidentiality, integrity
    and partial source authentication.  CLUE endpoints MUST support RTP/
    SAVPF and DTLS-SRTP keying [RFC5764].

This part is actually good, but it needs additional sentences saying 
which DTLS algorithms and which DTLS-SRTP protection profiles that needs 
to be supported. And then we arrive back at the question. Does this 
document needs to mandate implementation of RFC6904? And does that 
actually provide equivalent security. Which all comes back to what may 
the CaptureID value contain. Is that privacy sensitive?

I am sorry press you about the security aspects and the need for 
analysis and understanding of what choices implies. Yes, choosing the 
right things are difficult. The RTCWeb Security Architecture document 
(https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12) still 
has a rather large number of issues: 
https://github.com/rtcweb-wg/security-arch/issues

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------