Re: [secdir] [payload] sec-dir review of draft-ietf-payload-rtp-opus-08

[Magnus Westerlund <[e-mail]>]

On 2015-04-09 16:19, Derek Atkins wrote:
> 
> On Thu, April 9, 2015 10:07 am, Ben Campbell wrote:
>> On 9 Apr 2015, at 9:00, Derek Atkins wrote:
>>
>>> Ben,
>>>
> [snip]
>>> So you're suggesting (and would be okay with) this text:
>>>
>>>  RTP packets using the payload format defined in this specification
>>>  are subject to the security considerations discussed in the RTP
>>>  specification RFC3550, and in any applicable RTP profile such as
>>>  RTP/AVP [RFC3551], RTP/AVPF [RFC4585], RTP/SAVP [RFC3711] or RTP/
>>>  SAVPF [RFC5124].  However, as "Securing the RTP Protocol Framework:
>>>  Why RTP Does Not Mandate a Single Media Security Solution"
>>>  [I-D.ietf-avt-srtp-not-mandatory] discusses it is not an RTP payload
>>>  formats responsibility to discuss or mandate what solutions are used
>>>  to meet the basic security goals like confidentiality, integrity and
>>>  source authenticity for RTP in general.  This responsibility lays on
>>>  anyone using RTP in an application.  They can find guidance on
>>>  available security mechanisms and important considerations in Options
>>>  for Securing RTP Sessions [I-D.ietf-avtcore-rtp-security-options].
>>>  Applications SHOULD use an appropriate strong security mechanism.
>>>
>>
>> I am okay with that text.
>>
>>> I think I'm okay with this.  (I kind of prefer my previous wording,
>>> "Applications SHOULD implement at least one of the strong security
>>> measures suggested by those references" only because it suggests that
>>> multiple mechanisms are okay, whereas this new wording seems to imply
>>> choosing only one).
>>
>> How about "Applications SHOULD use one or more strong security
>> mechanisms, as appropriate"?
> 
> Clearly now we're just getting down to wordsmithing..  :)
> 
> How about "Applications SHOULD use one or more appropriate strong security
> mechanisms"?  (The subclause "as apporpriate" feels to me like it could be
> ignored, as in "well, using a strong security mechanism isn't
> appropriate").  I think the goal is to make sure that "appropriate"
> modifies the "strong security mechanism" and not the "SHOULD use"  ;)
> 
> What say you?

Yes, I think that is fine. I don't see this contradicting RFC7202, and
are happy to include this in draft-ietf-payload-rtp-howto's template
text. I will wait a week before submitting an update version of the
HOWTO with this text and updated references. I will send an separate
email to the list and IESG to make clear that we are proposing this
change. I note that the document is approved by IESG and thus I like to
ensure that we still have consensus on this.

I hope that other RTP Payload format authors are paying attention to
this. The template text is fairly carefully constructed  to be clear and
not blur the lines of responsibility in this matter. The point of the
above paragraph of template is to avoid this type of discussions.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------