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

["Stephen Farrell" <[e-mail]>]

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.

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

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


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