Subject: Re: [clue] Comments on CaptureID and security

From: Roni Even <[email-masked]>
Date: Sun, 12 Feb 2017 09:26:30 +0000

Hi Magnus,
About the requirement to encrypt the RTCP (do not use NULL security profile) I was wondering why it is not mention also on RTCPweb, is it because RTP/RTCP multiplexing? I think that it should be mentioned also there since there is option to support non multiplex RTP/RTCP
Roni 

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: יום ד 18 ינואר 2017 13:53
> To: Roni Even; [email-masked]
> Cc: Jonathan Lennox
> Subject: Re: Comments on CaptureID and security
> 
> Hi,
> 
> Yes, I think encrypting the CaptureID avoids the negative impacts that bad
> construction can have that I can think of. Thus, I support going in that
> direction.
> 
> When it comes to the security solution I would recommend copying the text
> and then make the edits. There is at least two additions, the MUST encrypt
> RTCP, and the MUST implement RFC 6904 and use it to encrypt the CaptureID
> header extension. Please be explicit and clear in the CLUE level document on
> what security solutions that needs to be implemented and use.
> 
> Reasons for copying the text, is that there are differences between RTCWeb
> and CLUE, and in addition I think the implementation considerations and
> potential needs to later revise the specification are different. I am not certain
> CLUE will want to be required to follow any changes that RTCWeb does in the
> future.
> 
> I would also note that I think you need at least to put in a short paragraph
> about the CaptureID value. Something like this.
> 
> The construction of the CaptureID value is implementation dependent and is
> not tightly restricted. Therefore there exist a risk that the CaptureID contains
> privacy sensitive information or otherwise revealing information about the
> communication session to third parties. Therefore confidentiality protection
> is always applied to avoid this risk.
> 
> Cheers
> 
> Magnus
> 
> Den 2017-01-18 kl. 10:44, skrev Roni Even:
> > Hi, The text I added to the -11 version "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."
> >
> > Say that  " this SDES item MUST use similar security as the CLUE
> > protocol messages carried in the CLUE data channel." The CLUE data
> > channel document
> > https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-4
> > point at
> > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-
> > 7
> > pointing to
> > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10
> >
> > So we can reference the rtcweb security architecture or use the text I
> > copied from there to define a security profile
> >
> > As for the second item I agree that if we encrypt the content in the
> > CLUE data channel that includes the captureID, we need also to encrypt
> > RTCP with the captureID SDES item and it does not matter how we create
> > the captureID value, so maybe if we mandate encrypting the SDES item
> > there is no strong need for specifying how to create CaptureID . Note
> > that the CaptureID is not use to provide human-readable textual
> > information which is in the description attribute.
> >
> > Roni
> >
> >> -----Original Message----- From: Magnus Westerlund
> >> [mailto:[email-masked]] Sent: יום ד 18 ינואר 2017
> >> 10:45 To: Roni Even; [email-masked] Cc: Jonathan Lennox Subject: Re:
> >> Comments on CaptureID and security
> >>
> >> Hi,
> >>
> >> A comment about the below. I have an issue raised against the below
> >> quoted text from the rtcweb-security-architecture in the RTCWeb WG,
> >> as it fails to specify if RTCP encryption is mandatory to use or not.
> >> There are protection profiles that only have confidentiality
> >> protection for RTP, and not for RTCP. I would recommend requiring
> >> confidentiality protection also of RTCP.
> >>
> >> The second note on the below is that depending on the outcome of the
> >> security requirements for the CaptureID RTP header extension, you
> >> might in addition have to require RFC 6904, implementation and usage
> >> for the CaptureId header extension field. Or rather if you write
> >> nothing it will by default be required if you encrypt RTCP, due to
> >> RFC 7941. But, I really recommend that you are explicit on this
> >> matter. It comes down to what security risks the field entails. What
> >> information will it leak to a third party viewer of the RTP/RTCP
> >> stream they can capture.
> >>
> >> Cheers
> >>
> >> Magnus
> >>
> >> Den 2017-01-18 kl. 09:33, skrev Roni Even:
> >>> 2.       What do we want to say about supported security profile?
> >>> For example does the following directive from
> >>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#secti
> >>> on-5.5
> >>>
> >>>
> looks good for CLUE?
> >>>
> >>>
> >>>
> >>> “Implementations MUST implement SRTP [RFC3711
> >>> <https://tools.ietf.org/html/rfc3711>].  Implementations MUST
> >>>
> >>> implement DTLS [RFC4347 <https://tools.ietf.org/html/rfc4347>]
> >>> and DTLS-SRTP [RFC5763
> >>> <https://tools.ietf.org/html/rfc5763>][RFC5764] for
> >> SRTP
> >>>
> >>> keying.  Implementations MUST implement
> >>>
> >>> [I-D.ietf-tsvwg-sctp-dtls-encaps
> >>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-
> >>> I-
> >>
> >>>
> D.ietf-tsvwg-sctp-dtls-encaps>].
> >>>
> >>>
> >>>
> >>> All media channels MUST be secured via SRTP.  Media traffic MUST NOT
> >>>
> >>> be sent over plain (unencrypted) RTP; that is, implementations MUST
> >>>
> >>> NOT negotiate cipher suites with NULL encryption modes.
> >>> DTLS-SRTP
> >>>
> >>> MUST be offered for every media channel.
> >>>
> >>>
> >>>
> >>> All data channels MUST be secured via DTLS.
> >>>
> >>>
> >>>
> >>> All 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
> >>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-
> >>
> >>>
> FIPS186>].
> >>> The DTLS-SRTP protection profile
> >>>
> >>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP.
> >>>
> >>> Implementations SHOULD implement DTLS 1.2 with the
> >>>
> >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite.
> >>>
> >>> Implementations MUST favor cipher suites which support PFS over
> >>> non-
> >>>
> >>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
> >>>
> >>> “
> >>
> >>
> >> --
> >>
> >> 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]
> >> ---------------------------------------------------------------------
> >> -
> >
> >>
> --
> 
> 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: Roni Even <[email-masked]>
Date: Sun, 12 Feb 2017 09:58:53 +0000

HI Magnus,
I think that the confidentiality  of the RTCP is covered in RFC5764
" Applications using DTLS-SRTP SHOULD coordinate the SRTP Protection
   Profiles between the DTLS-SRTP session that protects an RTP flow and
   the DTLS-SRTP session that protects the associated RTCP flow (in
   those cases in which the RTP and RTCP are not multiplexed over a
   common port).  In particular, identical ciphers SHOULD be used."

Roni

> Sent: יום ד 18 ינואר 2017 10:45
> A comment about the below. I have an issue raised against the below quoted
> text from the rtcweb-security-architecture in the RTCWeb WG, as it fails to
> specify if RTCP encryption is mandatory to use or not. There are protection
> profiles that only have confidentiality protection for RTP, and not for RTCP. I
> would recommend requiring confidentiality protection also of RTCP.
> 
> security requirements for the CaptureID RTP header extension, you might in
> addition have to require RFC 6904, implementation and usage for the
> CaptureId header extension field. Or rather if you write nothing it will by
> default be required if you encrypt RTCP, due to RFC 7941. But, I really
> recommend that you are explicit on this matter. It comes down to what
> security risks the field entails. What information will it leak to a third party
> viewer of the RTP/RTCP stream they can capture.
> 
> Cheers
> 
> Magnus
> 
> > 2.       What do we want to say about supported security profile? For
> > example does the following directive from
> > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#section-5.5
> > looks good for CLUE?
> >
> >
> >
> >    implement DTLS [RFC4347 <https://tools.ietf.org/html/rfc4347>] and
> > DTLS-SRTP [RFC5763 <https://tools.ietf.org/html/rfc5763>][RFC5764] for
> SRTP
> >
> > <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#ref-I-
> >    NOT negotiate cipher suites with NULL encryption modes.  DTLS-SRTP
> >
> >    Implementations MUST favor cipher suites which support PFS over non-
> >

---

From: Roni Even <[email-masked]>
Date: Sun, 12 Feb 2017 10:07:39 +0000

Paul,
From RFC5764
"RTP and RTCP traffic MAY be multiplexed on a single UDP port
   [RFC5761].  In this case, both RTP and RTCP packets may be sent over
   the same DTLS-SRTP session, halving the number of DTLS-SRTP sessions
   needed.  This improves the cryptographic performance of DTLS, but may
   cause problems when RTCP and RTP are subject to different network
   treatment (e.g., for bandwidth reservation or scheduling reasons)."

Roni

> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: יום ד 18 ינואר 2017 18:26
> To: [email-masked]
> Subject: Re: [clue] Comments on CaptureID and security
> 
> I have a side question on this: if RTCP is being multiplexed with RTP, and the
> RTP is being encrypted, is the RTCP also implicitly encrypted, or is it still an
> independently negotiated feature?
> 
> (Yes, I realize that doesn't solve the general problem for CLUE.)
> 
> 	Thanks,
> 	Paul
> 
> On 1/18/17 6:53 AM, Magnus Westerlund wrote:
> > Hi,
> >
> > Yes, I think encrypting the CaptureID avoids the negative impacts that
> > bad construction can have that I can think of. Thus, I support going
> > in that direction.
> >
> > When it comes to the security solution I would recommend copying the
> > text and then make the edits. There is at least two additions, the
> > MUST encrypt RTCP, and the MUST implement RFC 6904 and use it to
> > encrypt the CaptureID header extension. Please be explicit and clear
> > in the CLUE level document on what security solutions that needs to be
> > implemented and use.
> >
> > Reasons for copying the text, is that there are differences between
> > RTCWeb and CLUE, and in addition I think the implementation
> > considerations and potential needs to later revise the specification
> > are different. I am not certain CLUE will want to be required to
> > follow any changes that RTCWeb does in the future.
> >
> > I would also note that I think you need at least to put in a short
> > paragraph about the CaptureID value. Something like this.
> >
> > The construction of the CaptureID value is implementation dependent
> > and is not tightly restricted. Therefore there exist a risk that the
> > CaptureID contains privacy sensitive information or otherwise
> > revealing information about the communication session to third
> > parties. Therefore confidentiality protection is always applied to avoid this
> risk.
> >
> > Cheers
> >
> > Magnus
> >
> >> 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."
> >>
> >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section
> >> -7
> >> pointing to
> >> So we can reference the rtcweb security architecture or use the text
> >> I copied from there to define a security profile
> >>
> >> CLUE data channel that includes the captureID, we need also to
> >> encrypt RTCP with the captureID SDES item and it does not matter how
> >> we create the captureID value, so maybe if we mandate encrypting the
> >> SDES item there is no strong need for specifying how to create
> >> CaptureID . Note that the CaptureID is not use to provide
> >> human-readable textual information which is in the description
> >> attribute.
> >>
> >> Roni
> >>
> >>> as it fails to specify if RTCP encryption is mandatory to use or
> >>> not. There are protection profiles that only have confidentiality
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 12 Feb 2017 14:45:47 -0500

Roni,

>    treatment (e.g., for bandwidth reservation or scheduling reasons)."

My understanding of RTP/RTCP is minimal, so my questions may not make 
any sense. But as best I understand, when RTP/RTCP is run over DTLS it 
isn't sent as DTLS encrypted payload. Rather, it reuses the DTLS 
negotiated keys but then encrypts the RTP/RTCP data independently and 
selectively, so some parts are encrypted and other parts are not.

Based on that, my question is whether, when multiplexing RTP and RTCP 
and running them over DTLS, it is automatic that the RTCP pieces are 
encrypted, or if it is necessary to negotiate something explicit in the 
SDP (apart from what is negotiated for the RTP) to cause the RTCP data 
to be encrypted.

	Thanks,
	Paul

---

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

Paul,
My understanding is Inline
Roni

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: יום א 12 פברואר 2017 21:46
> any sense. But as best I understand, when RTP/RTCP is run over DTLS it isn't
> sent as DTLS encrypted payload. Rather, it reuses the DTLS negotiated keys
> but then encrypts the RTP/RTCP data independently
[Roni Even] using SRTP which defines which part of the RTP / RTCP packets are encrypted
 and selectively, so some
> parts are encrypted and other parts are not.
> 
> Based on that, my question is whether, when multiplexing RTP and RTCP and
> running them over DTLS, it is automatic that the RTCP pieces are encrypted,
[Roni Even] I do not think that it is implied, dtls pass the packets to the srtp layer which decide how to secure the RTP and RTCP
> or if it is necessary to negotiate something explicit in the SDP (apart from
> what is negotiated for the RTP) to cause the RTCP data to be encrypted.
> 
> 	Thanks,
> 	Paul
> 
> > Roni
> >
> >> I have a side question on this: if RTCP is being multiplexed with
> >> RTP, and the RTP is being encrypted, is the RTCP also implicitly
> >> encrypted, or is it still an independently negotiated feature?
> >>
> >>> Yes, I think encrypting the CaptureID avoids the negative impacts
> >>> that bad construction can have that I can think of. Thus, I support
> >>> going in that direction.
> >>>
> >>> in the CLUE level document on what security solutions that needs to
> >>> be implemented and use.
> >>>
> >>>> Hi, The text I added to the -11 version "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."
> >>>>
> >>>> So we can reference the rtcweb security architecture or use the
> >>>> text I copied from there to define a security profile
> >>>>
> >>>> As for the second item I agree that if we encrypt the content in
> >>>> the CLUE data channel that includes the captureID, we need also to
> >>>> encrypt RTCP with the captureID SDES item and it does not matter
> >>>> how we create the captureID value, so maybe if we mandate
> >>>> encrypting the SDES item there is no strong need for specifying how
> >>>> to create CaptureID . Note that the CaptureID is not use to provide
> >>>>> A comment about the below. I have an issue raised against the
> >>>>> below quoted text from the rtcweb-security-architecture in the
> >>>>> RTCWeb WG, as it fails to specify if RTCP encryption is mandatory
> >>>>> to use or not. There are protection profiles that only have
> >>>>> confidentiality protection for RTP, and not for RTCP. I would
> >>>>> recommend requiring confidentiality protection also of RTCP.
> >>>>>
> >>>>> The second note on the below is that depending on the outcome of
> >>>>> the security requirements for the CaptureID RTP header extension,
> >>>>> you might in addition have to require RFC 6904, implementation and
> >>>>> usage for the CaptureId header extension field. Or rather if you
> >>>>> write nothing it will by default be required if you encrypt RTCP,
> >>>>> due to RFC 7941. But, I really recommend that you are explicit on
> >>>>> this matter. It comes down to what security risks the field
> >>>>> entails. What information will it leak to a third party viewer of
> >>>>> the RTP/RTCP stream they can capture.
> >>>>>
> >>>>> Cheers
> >>>>>
> >>>>> Magnus
> >>>>>
> >>>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#se
> >>>>>> ct
> >>>>>> ion-5.5
> >>>>>>
> >>>>>>
> >>>>>>
> >>> looks good for CLUE?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#r
> >>>>>> ef
> >>>>>> -I-
> >>>>>
> >>>>>>
> >>>>>> <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#r
> >>>>>> ef
> >>>>>> -
> >>>>>
> >>>>>>
> >>> FIPS186>].
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> --
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> --
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> --
> >>>>> --
> >>>>
> >>>>>
> >>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 23 Feb 2017 09:32:30 +0100

Hi Roni,

Den 2017-02-12 kl. 10:26, skrev Roni Even:
> Hi Magnus, About the requirement to encrypt the RTCP (do not use NULL
> security profile) I was wondering why it is not mention also on
> RTCPweb, is it because RTP/RTCP multiplexing? I think that it should
> be mentioned also there since there is option to support non
> multiplex RTP/RTCP

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.

Magnus Westerlund