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

[Colin Perkins <[e-mail]>]

On 10 Apr 2015, at 07:52, Magnus Westerlund <[e-mail]> wrote:
> 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.

+1 no objections


-- 
Colin Perkins
https://csperkins.org/