Re: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)

[Alissa Cooper <[e-mail]>]

A couple of thoughts here:

- RTP middleboxes do all kinds of things to cleartext media that they receive. Of course people have realized the security drawbacks of this, which is why we have developed security technologies designed to prevent media manipulation and why we have other WGs working on extending that model to conferencing and defining best practices for how to secure media end-to-end.

- I agree that the MUST NOT forward language is ill-advised, and it’s also unnecessary. But even if this document said MUST forward, there is nothing in the protocol semantics that would require implementations to do that, so I imagine that splicers that do not want to forward this information (whether to prevent detection or to reduce overhead) won’t forward it. Similarly, I would imagine that at least some of the payload-specific mechanisms used for this purpose have the same property, so even if systems rely on those mechanisms rather than RTP because the RTP spec says MUST forward, there is no guarantee that the splicing information will reach the receiver.

Alissa

> On Jun 14, 2016, at 2:59 PM, Alia Atlas <[e-mail]> wrote:
> 
> Alia Atlas has entered the following ballot position for
> draft-ietf-avtext-splicing-notification-07: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I believe this is more  a discussion for the IESG.
> 
> First, this is way out of my area and I'm not particularly commenting on
> the details - but 
> I do agree with Mirja's discuss about
> "- The following action does not seem to be appropriate for a
> specification of an end-to-end protocol:
> "And if the splicer wishes to prevent the downstream receivers from
> detecting splicing, it MUST
>   NOT forward the message.""
> 
> The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts
> the RTCP splicing notification message,
>   it SHOULD NOT forward the message to the down-stream receivers in
>   order to reduce RTCP bandwidth consumption. And if the splicer wishes
>   to prevent the downstream receivers from detecting splicing, it MUST
>   NOT forward the message."
> 
> Even more specifically to me, superficially this seems to me to be a way
> to change what is in the
> stream that a receiver has requested or subscribed to without permission
> or notification.   In that light,
> the idea that the splicer is able to prevent downstream receivers from
> detecting the splicing does
> not sound good.
> 
> Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP
> header extension and derives the
>   Splicing Interval, it will generate its own stream and SHOULD NOT
>   include the RTP header extension in outgoing packets to reduce header
>   overhead."
> 
> This looks like another example of making the choice to hide information
> from the receiver.
> 
> I realize that there is probably an technical arms-race going on - of
> inserting advertisements and
> building receivers to block undesired advertisements.  I am  not seeing a
> balanced solution that
> considers the receivers as well as the senders.
> 
> I am startled that there is no consideration of the impact of this
> extension on the receivers 
> in the security considerations.
> 
> The only reference I see in the Security Considerations further assumes
> that it is appropriate to have an undetectable splicing.
> 
> " A malicious endpoint may also break an undetectable splicing. To
>   mitigate this effect, the splicer SHOULD NOT forward the splicing
>   time information RTP header extension defined in Section 4.1 to the
>   receivers. And it MUST NOT forward this header extension when
>   considering an undetectable splicing. "
> 
> At a minimum, I feel like there should be a very clear consideration of
> the
> pros and cons - including from the viewpoint of a receiver. 
> 
> If we end up with this biased technology, then it should be clearly
> stated
> - not hidden in assumptions.
> 
> 
> 
>