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

[Magnus Westerlund <[e-mail]>]

Hi,

Looking at the update in the draft-12:

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

I don't find this sufficient. First of all, there is no clarify of what 
the security treats to the CaptureId are. Secondly, the similar security 
here is far from trivial as the SCTPoDTLS data channel uses DTLS while 
RTP/RTCP security is the combination of the DTLS-SRTP and SRTP 
mechanisms in use. Note that from part of the security aspects DTLS-SRTP 
and DTLS is actually quite different.

I will note that I still haven't found the equivalent the RTCWeb 
security architecture document. Which actually discusses what protection 
profiles to support.

CLUE-Framework:

  In
    addition, the media MUST be secured. DTLS/SRTP MUST be supported
    and SHOULD be used unless the media, which is based on RTP, is
    secured by other means (see [RFC7201] [RFC7202]).  Media security
    is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue-
    rtp-mapping].

In signalling this is also not specified:

All CLUE-
    controlled RTP "m" lines must be secured and implemented using
    mechanisms such as SRTP [RFC3711]; no specific security mechanisms
    are made mandatory to use due to the issues addressed in [RFC7202].

I would note, that the point of RFC 7202, is that "solutions" like CLUE 
is the one that shall make mandatory to implement choices. So that CLUE 
WG attempts to dodge that aspect is very worrying.

Then RTP-mapping:

    The Extended Secure RTP Profile for Real-time Transport Control
    Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides
    handling of fundamental issues by offering confidentiality, integrity
    and partial source authentication.  CLUE endpoints MUST support RTP/
    SAVPF and DTLS-SRTP keying [RFC5764].


This part is actually good, but it needs additional sentences saying 
which DTLS algorithms and which DTLS-SRTP protection profiles that needs 
to be supported. And then we arrive back at the question. Does this 
document needs to mandate implementation of RFC6904? And does that 
actually provide equivalent security. Which all comes back to what may 
the CaptureID value contain. Is that privacy sensitive?

I am sorry press you about the security aspects and the need for 
analysis and understanding of what choices implies. Yes, choosing the 
right things are difficult. The RTCWeb Security Architecture document 
(https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12) still 
has a rather large number of issues: 
https://github.com/rtcweb-wg/security-arch/issues


Cheers

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