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

Hi,
I support what Colin says about SRTP being a security tool for unicast
telephony but other applications including multicast and broadcast that use
RTP may use other security mechanism.
Defining security for media in a specific application may be done when
defining the application like in RTCweb
(https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-23 section 4.2)
Roni Even

> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: 09 April, 2015 12:58 PM
> To: Ben Campbell
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; Kathleen
Moriarty;
> iesg@ietf.org; payload-chairs@tools.ietf.org; koenvos74@gmail.com; Derek
> Atkins
> Subject: Re: [payload] [secdir] sec-dir review of
draft-ietf-payload-rtp-opus-08
> 
> On 8 Apr 2015, at 20:49, Ben Campbell <ben@nostrum.com> wrote:
> > On 8 Apr 2015, at 14:38, Derek Atkins wrote:
> >>
> >> On Wed, April 8, 2015 2:52 pm, Ben Campbell wrote:
> >>> On 8 Apr 2015, at 9:42, Derek Atkins wrote:
> ...snip...
> >>> 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.
> 
> I think "SHOULD use an appropriate strong security mechanism" is quite
> different to "SHOULD use SRTP", since we know of cases where SRTP isn't
> suitable. That was my objection to the original text.
> 
> > 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.
> 
> One of the things RFC 7202 tries to convey is that "normative privacy
guidance
> for RTP in general" is not possible. The privacy requirements, for
example, of
> broadcast TV are different to those for a phone call, but both can use
RTP.
> 
> A document giving normative security guidance for unicast SIP-based
telephony
> using RTP is something we need, I agree. I'm happy to help reviewing such
a
> thing, but it should be authored by someone more familiar with the
deployed
> security mechanisms.
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload