Re: [rtcweb] BUNDLE: Attempting to resolve security consideration

I certainly think we have to remove the 14.1 reference. Other comments
below.
With these comments, I would find this text acceptable.

16.  Security Considerations

   The security considerations defined in [RFC3264] and [RFC5888] apply
   to the BUNDLE extension.  Bundle does not change which information
   flows over the network but only changes which addresses and ports
   that information is flowing on and thus has very little impact on the
   security of the RTP sessions.

   When the BUNDLE extension is used, a single set of security
   credentials might be used for all media streams specified by a BUNDLE
   group.

Isn't this actually required? Both a=fingerprint and a=crypto are
of type TRANSPORT.


   When the BUNDLE extension is used, the number of SSRC values within a
   single RTP session increases, which increases the risk of SSRC
   collision.  [RFC4568] describes how SSRC collision may weaken SRTP
   and SRTCP encryption in certain situations.

This seems like it's only true in a very limited sense of situations.
In both SDES and DTLS-SRTP, keys are directional, so an SSRC collision
would require that one direction generate colliding SSRCs. That's
certainly possible, but should be straightforward to avoid in most
architectures. In any case, the base rate SSRC collision is far to
high to rely on statistics to prevent it.


   The identfication-tag, when included in the RTP MID SDES item,

This is at typo.

   independent of transport, RTCP SDES packet or RTP header extension,
   can expose the value to parties beyond the signaling chain.
   Therefore, the identification-tag MUST NOT contain any user related
   information.

You should just use the JSEP language here.

   o  An "a=mid" line, as specified in [RFC5888], Section 4.  All MID
      values MUST be generated in a fashion that does not leak user
      information, e.g., randomly or using a per-PeerConnection counter,
      and SHOULD be 3 bytes or less, to allow them to efficiently fit
      into the RTP header extension defined in

   However, the implementation's method for generating
   identfication-tags could enable fingerprinting of the implementation

typo in "identification"


   making it vulnerable to targeted attacks.  The identication-tag is
   exposed on the RTP stream level when included in the RTP header
   extensions, however what it reveals of the RTP media stream structure
   of the endpoint and application was already possible to deduct from

I assume you mean "deduce"

   the RTP streams without the MID SDES header extensions.  As the
   identification-tag is also used to route the media stream to the
   right application functionality it is also important that the value
   received is the one intended by the sender, thus integrity and the
   authenticity of the source are important to prevent denial of service
   on the application.

Is there any condition when you are using SRTP that these values are
not integrity protected? If not, what is the issue here?


   At least to prevent third parties from modifying
   the identification-tag value.

This is not a sentence.

   To avoid the security risks associated with tracking of
   implementations, there is RECOMMENDED algorithm for generating
   identification-tags in Section 14.1.

See above.

   "RTP Header Extension for the
   RTP Control Protocol (RTCP) Source Description Items" [RFC7941]
   security consideration requires that when RTCP is confidentiality
   protected that any SDES RTP header extension carrying an SDES item,
   like the MID RTP header extension, is also protected using
   commensurate strength algorithms.  However, assuming the above
   requirements and recommendations are followed there are no known
   significant security risks with leaving the MID RTP header extension
   without confidentiality protection.  Thus, the requirements in RFC
   7941 MAY be ignored for the MID RTP header extension.  Security
   mechanisms for RTP/RTCP are discussed in Options for Securing RTP
   Sessions [RFC7201], for example SRTP [RFC3711] can provide the
   necessary security functions of ensuring the integrity and source
   authenticity.



On Fri, Mar 3, 2017 at 7:06 AM, Magnus Westerlund <
[email protected]> wrote:

> Den 2017-03-03 kl. 14:49, skrev Eric Rescorla:
>
>>
>>
>> On Fri, Mar 3, 2017 at 8:24 AM, Magnus Westerlund
>> <[email protected] <mailto:[email protected]>>
>>
>> wrote:
>>
>>     Hi,
>>
>>     Last IETF meeting we had discussions regarding the security
>>     considerations for the MID RTP header extensions regarding the need
>>     for encrypting the RTP header. On Christer's request I have
>>     attempted to capture what I believed was the outcome of this
>>     discussion into a text proposal.
>>
>>     So the intention of the text is to capture the security
>>     considerations, i.e. known risks and what we believe is necessary to
>>     mitigate these risks. The conclusion of the discussion was that
>>     encrypting the MID in RTP header extensions is not necessary, and
>>     thus we have a conflict with the requirements in RFC 7941. I have
>>     attempted to motivate and on that basis wavier this requirement for
>>     this particular RTP SDES header extension. This is captured in last
>>     paragraph of section 16.
>>
>>     The risk of implementation tracking lead us into a discussion around
>>     a algorithm for generating MID Values. I have drafted a proposal for
>>     such an algorithm in a new Section 14.1 inserted prior to the
>>     existing one.
>>
>>     I note that in RTCWeb WG we did discuss that the encryption wavier
>>     would be done in the security architecture. However, I believe in
>>     retrospect that not covering this in BUNDLE in a common fashion
>>     would be confusing and likely cause questions in regards to the
>>     requirements of RFC 7941 when BUNDLE is used in other context than
>>     WebRTC.
>>
>>     So please review and provide feedback. I know Christer wants to
>>     close this issue.
>>
>>
>>     14.1.  Generating Identification-tags
>>
>>        The identification-tag is exposed on the network layer due to the
>>        SDES item and RTP header extension defined below.  As this exposes
>>        the identification-tag beyond contexts where it is normally
>> exposed,
>>        i.e.  signalling layer additional potential for implementation
>>        identification exists.  To avoid such risks a RECOMMENDED to be
>> used
>>        algorithm for how the identification-tag value is generated is
>>        specified below.  Using this one will ensure that one can't
>> identify
>>        which of the implementations using this algorithm it is.
>>
>>
>> If you mean which stack, I do not believe that this is actually that
>> useful a design
>> consideration. There are going to be a very large number of ways to
>> fingerprint
>> stacks. As the rest of the text seems predicated on that design
>> objective, I do
>> not think we should make this change.
>>
>>
> Okay, what is your view on Section 16, if we remove the first sentence of
> the last paragraph that references 14.1?
>
> We need to get the security considerations in BUNDLE into reasonable shape
> so that we actually can get BUNDLE published.
>
> Cheers
>
>
> 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 protected]
> ----------------------------------------------------------------------
>
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic