Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

["Huangyihong (Rachel)" <[e-mail]>]

Hi Stephen,

Please see inline.

BR,
Rachel


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Monday, June 20, 2016 6:59 PM
> To: Huangyihong (Rachel); The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Stephen Farrell's Discuss on
> draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)
> 
> 
> Hiya,
> 
> On 20/06/16 11:42, Huangyihong (Rachel) wrote:
> > Hi Stephen,
> >
> > Please see my replies inline.
> >
> > BR, Rachel
> >
> >> -----Original Message----- From: Stephen Farrell
> >> [mailto:[e-mail]] Sent: Thursday, June 16, 2016
> >> 7:11 PM To: The IESG Cc:
> >> [e-mail];
> >> [e-mail]; [e-mail]; [e-mail]
> >> Subject: Stephen Farrell's Discuss on
> >> draft-ietf-avtext-splicing-notification-07: (with DISCUSS and
> >> COMMENT)
> >>
> >> Stephen Farrell 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:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> >>
> (1) Section 7, 3rd para: Saying that "splicer works as a trusted entity"
> seems
> >> wrong - you need to say who trusts whom for what I think. I also
> >> don't get what you mean by saying there'll be a security
> >> association between the splicer and the receiver, nor how that
> >> might ever be possible if the splicer wants to hide what it's
> >> doing.  I think what you're after is some general statement that
> >> splicing breaks all security unless all the parties involved share
> >> the same security association. IIRC there is text like that in
> >> other RTP documents that might be copied but I forget the detail.
> >
> > [Rachel]: Are you looking for such sentences?
> >
> > OLD " Since splicer works as a trusted entity, any RTP-level or
> > outside security mechanism, such as IPsec[RFC4301] or Datagram
> > Transport Layer Security [RFC6347], will use a security association
> > between the splicer and the receiver. When using the Secure Real-Time
> > Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned
> > with the same security association as the main RTP sender. " NEW "
> > Since the splicer breaks RTP-level end-to-end security, it need to be
> > a trusted device that is part of the signaling context and get the
> > necessary security associations (e.g., SRTP crypto contexts)
> > established with its RTP session participants. When using the Secure
> > Real-Time Transport Protocol (SRTP) [RFC3711], the splicer could be
> > provisioned with the same security association as the main RTP
> > sender. "
> 
> That's better yes, but I'd still recommend not saying "trusted
> device" at all since that calls into question who is trusting it
> for what and in this case the ultimate receiver doesn't usually
> know the splicer is there at all and hence cannot trust it in
> any meaningful sense. So I'd suggest:
> 
> NEW:
> 
> "
> Since the splicer breaks RTP-level end-to-end security, it needs to
> be part of the signaling context and be a part of the
> necessary security associations (e.g., SRTP crypto contexts)
> established for the RTP session participants. When using the Secure
> Real-Time Transport Protocol (SRTP) [RFC3711], the splicer would
> have to be
> provisioned with the same security association as the main RTP
> sender.
> "

[Rachel]: Looks better than mine^^.
> 
> >>
> >> (2) Section 7, 4th para: You say there is a case where header
> >> extension encryption SHOULD be used - how would that work? If
> >> there's a clear way to do it that'd get interop, then why is that
> >> not described? If there are ways in which might or might not work,
> >> or if some proprietary arrangements might be needed then how is it
> >> ok to have a SHOULD there? I suspect that the right thing here may
> >> be to not pretend that that can be done but to just stick with
> >> saying that splicing is inherently not going to work if you use any
> >> real security mechanisms, or something similar.
> >
> > [Rachel]: Yes. I agree. So we should use "MUST" here.
> >
> > OLD: " If there is a concern about the confidentiality of the
> > splicing time information, header extension encryption [RFC6904]
> > SHOULD be used. "
> >
> > NEW:
> >
> > " If there is a concern about the confidentiality of the splicing
> > time information, header extension encryption [RFC6904] MUST be
> > used. "
> 
> That's clearer than a SHOULD, yes. I'm still not clear if this
> MUST is something that just works or not though, can you clarify
> that? (In general, I'd not recommend we add any MUST or SHOULD
> at all if we're not confident that an implementer will actually
> write and test that code and that it'd work.)
> 

[Rachel]: Sorry, I misunderstood your point. I think you're right since actually I can't clarify that [RFC6904] is the only way to do this. So here's my new proposal:

"
If there is a concern about the confidentiality of the splicing time information, the header extension defined in this document MUST be also protected, for example, header extension encryption [RFC6904] can be used in this case.
"

> >
> >>
> >> (3) In discussion of RFC6828 there was some concern about possible
> >> creation of loops. I forget the issues though, but wanted to check
> >> this in case it also applies here.  (See 4.5 of 6828 maybe or the
> >> history for that RFC in the tracker.)
> >>
> >>
> >
> > [Rachel]: Yes, you're right. How about adding a new paragraph in
> > Section 7 to discuss loops?
> >
> > " When implementing undetectable splicing, CSRC list, which can be
> > used to detect RTP-level forwarding loops as defined in Section 8.2
> > of [RFC3550], may be removed to prevent receivers from detecting the
> > splicing occurrence. Hence, loops could occur to cause packets to
> > loop back to upstream of the splicer and may form a serious
> > denial-of-service threat. In such a case, non-RTP means MUST be used
> > to detect and resolve loops if the splicer does not add a CSRC list
> > when forwarding the RTP packet. "
> 
> That does look right to me, but since I don't understand it really,
> I'll just believe you that it's ok:-) Are the "non-RTP means" that
> could be used something that'd be clear to an implementer? If so,
> then that'd be fine. If not, maybe you need to say what that means?

[Rachel]: Sure. See following proposal

" In such a case, non-RTP means, e.g., signaling among all the participants, MUST be used to detect and resolve loops if the splicer does not add a CSRC list when forwarding the RTP packet."

> 
> >
> >> ----------------------------------------------------------------------
> >>
> >>
> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >>
> >>
> >>
> >>
> - I agree with Alia's discuss, but suspect the ship has sailed.
> >> (Sadly IMO, but sailed nonetheless.)
> >>
> >> - The security considerations here are similar to but not quite the
> >> same as those in RFC6828 which I think was the last time a similar
> >> document was before the IESG. I wondered if those differences were
> >> significant or not, it might be no harm to commpare the two (if
> >> that's not already been done) since they really ought be pretty
> >> much the same.
> >>
> >
> > [Rachel]: Not quite the same. This draft is about defining messages.
> > And RFC6828 is one option scenario where these messages can be used.
> > But people may use other models. But as suggested by Mirja, it's good
> > to add some words to described what RFC 6828 is about.
> 
> Fair enough,
> Cheers,
> S.
> 
> 
> >