Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt

[Roni Even <[e-mail]>]

HI Magnus,
Thanks,

The security consideration when discussing captureID references RFC7941 where it says:

"In RTP sessions where any type of confidentiality protection is
   enabled for RTCP, the SDES item header extensions MUST also be
   protected.  This implies that to provide confidentiality, users of
   the Secure Real-time Transport Protocol (SRTP) need to implement and
   use encrypted header extensions per [RFC6904].  "
 
so since we mandate RTCP confidentiality the RTP header extension MUST also be encrypted.

As for the non-traceable I will change to 

"CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as
    specified in [RFC7022], and thus can't be used for long term tracking of the user."

Any other open issue? I would like to submit what would maybe be the final version
Roni




> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: יום ו 24 פברואר 2017 10:14
> To: Roni Even; [e-mail]
> Subject: Re: [clue] FW: I-D Action: draft-ietf-clue-rtp-mapping-13.txt
> 
> Hi,
> 
> To be clear, yesterday's posting with remaining issues are applicable on this
> version.
> 
> That is actually a shortcoming of RTCWeb Security architecture and there
> exists an tracked issue for it:
> 
> https://github.com/rtcweb-wg/security-arch/issues/34
> 
> So, yes, I would really like to see the communication security section
> mandate encrypted RTCP. This due to the information included in RTCP about
> the application. The protection profile mandated does imply equal strength
> RTCP protection, but if one uses other profiles it might not be as clear cut. So
> a wording on protecting RTCP at same or similar protection strength to RTP I
> think is motivated.
> 
> What I also think is missing in the new text is discussion of RTP header
> extension encryption, i.e. RFC 6904. I thought the conclusion on the capture
> ID is that there is no strong generation requirements to ensure they don't
> contain privacy sensitive information. And it definitely reveals what is
> happening in the application context to third parties.
> Thus, I think encrypting the RTP header extensions would be good practice in
> clue situations.
> 
> I also reacted to the use of "untraceable" in this sentence:
> 
> CLUE endpoint MUST generate short-term persistent RTCP CNAMES, as
>     specified in [RFC7022], resulting in untraceable CNAME values.
> 
> The point of them is that they are not long term persistent and thus can't be
> used for long term tracking of the user. Writing "untraceable"
> I would interpret as indicating a stronger user protection then what is actually
> provided.
> 
> Cheers
> 
> Magnus
> 
> Den 2017-02-13 kl. 10:59, skrev Roni Even:
> > Hi,
> > This new version is submitted to address Magnus and Ben comments.
> > There is a new section Communication security that specifies normative
> security for CLUE media.
> > The security consideration is just considerations and added text about
> > the CaptureID There are also some editorial and nits changes Roni
> >
> >
> > -----Original Message-----
> > From: clue [mailto:[e-mail]] On Behalf Of
> > [e-mail]
> > Sent: יום ב 13 פברואר 2017 11:30
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt
> >
> >
> > 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-13.txt
> > 	Pages           : 14
> > 	Date            : 2017-02-13
> >
> > Abstract:
> >    This document describes how the Real Time transport Protocol (RTP) is
> >    used in the context of the CLUE protocol (ControLling mUltiple
> >    streams for tElepresence).  It also describes the mechanisms and
> >    recommended practice for mapping RTP media streams defined in
> Session
> >    Description Protocol (SDP) to CLUE Media Captures and defines a new
> >    RTP header extension (CaptureId).
> >
> >
> > 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-13
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-13
> >
> >
> > 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/
> >
> > _______________________________________________
> > clue mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/clue
> >
> > _______________________________________________
> > clue mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/clue
> >
> -
> 
> --
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------