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

From: [email-masked]
Date: Mon, 13 Feb 2017 01:29:58 -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-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/

---

From: Roni Even <[email-masked]>
Date: Mon, 13 Feb 2017 09:59:22 +0000

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:[email-masked]] On Behalf Of [email-masked]
Sent: יום ב 13 פברואר 2017 11:30
To: [email-masked]
Cc: [email-masked]
Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-13.txt

Abstract:

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.

_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2017 11:04:13 -0500

> There are also some editorial and nits changes

Magnus & Ben: does this resolve your issues?

I noticed one nit:

In Section 10 the following text:

    ... A mandatory to implement and use
    media security solution is created by combining this secured RTP
    profile and DTLS-SRTP keying [RFC5764] as defined in the
    communication security section of this memo Section 7

is lacking a period at the end. Based on the diffs it may also be 
lacking a paragraph break, but in the actual document there is a page 
break there so it is hard to say for sure.

No need to fix it now. It can await the next edit.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 23 Feb 2017 09:50:50 +0100

> Magnus & Ben: does this resolve your issues?

Yes for me. (Sorry for the delay, I cleared my discuss a while back, but 
I guess I failed to answer this.)

Thanks!

Ben.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Feb 2017 09:14:29 +0100

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

> ftp://ftp.ietf.org/internet-drafts/
-

-- 

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]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Feb 2017 17:43:02 -0500

Roni, Jonathan,

Are you able to change in a way that will satisfy Magnus?

	Thanks,
	Paul

On 2/24/17 3:14 AM, Magnus Westerlund wrote:
>> 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.
>>

---

From: Roni Even <[email-masked]>
Date: Sun, 26 Feb 2017 07:13:04 +0000

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

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: יום ו 24 פברואר 2017 10:14
> To: Roni Even; [email-masked]
> 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.
> 
> 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.
> 
> 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.
> 
> 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
> 
> > The security consideration is just considerations and added text about
> > the CaptureID There are also some editorial and nits changes Roni
> >
> >
> submission until the htmlized version and diff are available at tools.ietf.org.
> >

---

From: Roni Even <[email-masked]>
Date: Sun, 26 Feb 2017 07:13:57 +0000

Hi Paul,
I hope we will be done ASAP
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: שבת 25 פברואר 2017 00:43
> To: Roni Even; [email-masked]; Jonathan Lennox
> Cc: Magnus Westerlund
> > 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:
> >
> > 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.
> > I would interpret as indicating a stronger user protection then what
> > is actually provided.
> >
> > Cheers
> >
> > Magnus
> >
> >> The security consideration is just considerations and added text
> >> about the CaptureID There are also some editorial and nits changes
> >> Roni
> >>
> >>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Feb 2017 15:14:10 +0100

Den 2017-02-26 kl. 08:13, skrev Roni Even:
> HI Magnus, Thanks,

Yes, but I think it would be much clearer to have the implementation 
requirement written out in Section 7.

I would expand this paragraph:

All CLUE implementations MUST implement DTLS 1.0, with the cipher
    suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
    [FIPS186].  The DTLS-SRTP protection profile
    SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.

to say:

    All CLUE implementations MUST implement DTLS 1.0, with the cipher
    suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve
    [FIPS186].  The DTLS-SRTP protection profile
    SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Encrypted 
SRTP Header extensions [RFC6904] MUST be supported.

> specified in [RFC7022], and thus can't be used for long term tracking

Sounds good.

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

Not to my knowledge. I think this is done.

Thanks

Magnus Westerlund

---

From: Roni Even <[email-masked]>
Date: Mon, 27 Feb 2017 15:09:38 +0000

Hi Paul,
Just submitted -14 that I think addresses Magnus concerns
Roni

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Feb 2017 17:20:17 +0100

> Just submitted -14 that I think addresses Magnus concerns

Yes, I this is good enough.

Thanks

Magnus Westerlund

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2017 12:37:19 -0500

Thank you Roni and Magnus!

IIUC we should be good to go now.
I'm going to review and update my shepherd writeup now and then submit 
to iesg. If you know any reason not to do that then speak up NOW.

	Thanks,
	Paul