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

["Ben Campbell" <[e-mail]>]

On 8 Apr 2015, at 14:38, Derek Atkins wrote:

> Ben,
>
> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
>>
>>> On Wed, April 8, 2015 10:35 am, Colin Perkins wrote:
>>> [snip]
>>>>
>>>> And as I keep saying, I believe that is inappropriate, since it's
>>>> recommending SRTP which is not suitable for many applications. The
>>>> rtp-howto draft suggests the following text:
>>>>
>>> [sniped and added below]
>>>>
>>>> (The two drafts referenced are what became RFCs 7201 and 7202).
>>>>
>>>> If you want to augment that with a "strong security SHOULD/MUST be
>>>> used",
>>>> then I certainly don't object. However, a payload format really
>>>> shouldn't
>>>> be trying to recommend use of a particular RTP security solution,
>>>> such as
>>>> SRTP.
>>>
>>> Okay, so if you want to change the text completely (which I'm fine
>>> with),
>>> how about just adding a single sentence to the end of what you have:
>>>
>>> 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 implement at least one of the strong security
>>> measures suggested by those references.
>>
>> I'm okay with using the rtp-howto text. But 
>> _strictly_as_an_individual_,
>> I'd prefer not to add the last sentence, for 2 reasons:
>>
>> 1) This effectively creates a normative downref to informational RFCs
>> (7201/7202). That's mainly a process issue, and we can do that if 
>> it's
>> the right thing to do. But...
>
> It's technically not a downref because the referred documents are 
> guidance
> and not protocols.  So I don't think there would be any issue.  There 
> is
> already precedent for that.

As I said, it's just process.

>
>> 2) ... I still don't think a payload format is the right place to put
>> this sort of thing (that is, the last sentence.) Now, if our plan is 
>> to
>> put that text into all future payload formats, that's not quite as 
>> bad.
>> But unless we plan to revise legacy formats, it still creates 
>> confusing
>> inconsistency between formats.
>
> I'll point out, again, that the original draft *already did this*, so 
> you
> should be talking to the working group about that and not to me.  From
> where I sit, I saw the "MAY encrypt" and said "please change that from 
> MAY
> to SHOULD."  That's where this all started.
>
> Now, you could say (possibly even correctly -- I wont make that 
> judgement
> call) that the WG made a mistake putting that sentence into the 
> Security
> Considerations at all in the first place, but they did.  Clearly the 
> WG
> decided it was worthwhile to mention that; I'm just suggesting to make 
> the
> mention stronger than what was there in -08.

I'm not convinced. SHOULD is considerably more constraining that MAY.

>
>> For an extreme example, having that sentence in Codec format A and 
>> not
>> format B could lead to implementor decisions on the order of "I don't
>> want to bother with crypto, so I will choose codec B because it has
>> lighter requirements" might appear to make sense to someone not 
>> steeped
>> in this argument.
>>
>> What I'd _really_ like to do is take the energy in this thread and 
>> apply
>> it to creating a standards-track security document for RTP unicast
>> applications.
>
> Are you willing to hold up this document until that work is done so it 
> can
> refer to the (yet-to-be-written) protocol security update draft?  I'm 
> fine
> with that approach and I'm willing to review whatever draft you guys
> produce if that's how you'd like to proceed.

No, I will go with the consensus on this one. I note that several WG 
participants objected to the orignally proposed SHOULD. I am pointing 
out that this SHOULD is not much different, but I will go with what 
people want to do.

OTOH, what I would like to do would fix the problem for this, and all 
other codec payload formats, after the fact if we do it right (since it 
would apply to the application)

>
> Or you can hold your nose and live with the "UGGH" of it based on what 
> the
> WG original created in -08 and move forward for now, knowing that you 
> can
> (and should) correct it "right" later.

The work group did not put in a SHOULD. I think this is more of a 
question of whether people are willing to hold there collective noses 
about the lack of _normative_ privacy guidance for RTP in general, and 
if they are willing to let payload formats continue to progress while 
that is being worked out.

>
> I have no skin in that decision :)
>
> -derek
> -- 
>      Derek Atkins                 617-623-3745
>      [e-mail]             www.ihtfp.com
>      Computer and Internet Security Consultant