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

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