Re: [clue] Comments on CaptureID and security

[Magnus Westerlund <[e-mail]>]

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