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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 16 Jun 2016 04:10:46 -0700

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.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 20 Jun 2016 10:42:14 +0000

Hi Stephen,

Please see my replies inline. 

BR,
Rachel

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, June 16, 2016 7:11 PM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07:
> (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> (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.
"
> 
> (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.
"

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 20 Jun 2016 11:58:57 +0100

Hiya,

On 20/06/16 11:42, Huangyihong (Rachel) wrote:
> BR, Rachel
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] Sent: Thursday, June 16, 2016
>> 7:11 PM To: The IESG Cc:
>> [email-masked];
>> [email-masked]; [email-masked]; [email-masked] 
>> Subject: Stephen Farrell's Discuss on
>> draft-ietf-avtext-splicing-notification-07: (with DISCUSS and
>> COMMENT)
>> 
>> 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.
>> 
>> 
>> 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.
> 
> 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.
"

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

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

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 21 Jun 2016 01:21:29 +0000

Hi Stephen,

Please see inline.

BR,
Rachel

> Sent: Monday, June 20, 2016 6:59 PM
> To: Huangyihong (Rachel); The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Stephen Farrell's Discuss on
> draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)
> 
> 
> Hiya,
> 

[Rachel]: Looks better than mine^^.
> 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.
"

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