Re: [clue] Comments on CaptureID and security

[Roni Even <[e-mail]>]

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

> -----Original Message-----
> From: Magnus Westerlund [mailto:[e-mail]]
> Sent: יום ד 18 ינואר 2017 10:45
> To: Roni Even; [e-mail]
> 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#section-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  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------