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


> -----Original Message-----
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: 06 April, 2015 9:50 PM
> To: Robert Sparks
> Cc: secdir@ietf.org; payload@ietf.org; jspittka@gmail.com; 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 6 Apr 2015, at 19:44, Robert Sparks <rjsparks@nostrum.com> wrote:
> > inline (particularly for Derek)
> > On 4/6/15 11:13 AM, Ben Campbell wrote:
> >> On 6 Apr 2015, at 11:09, Derek Atkins wrote:
> >>
> >>> "Timothy B. Terriberry" <tterribe@xiph.org> writes:
> >>>
> >>>> Ben Campbell wrote:
> >>>>>> So my suggestion would be something more to the effect of:
> >>>>>>
> >>>>>> "Opus does not provide any built-in confidentiality or integrity
> >>>>>> protection. Protection requirements vary between RTP applications.
> >>>>>> See RFC 7201 and RFC 7202 for a discussion.
> >>>>
> >>>> This seems like reasonable text to me. I agree with the rationale
> >>>> that preceded it. As much as I want to see encryption everywhere, a
> >>>> payload format is not the right place to mandate it.
> >>>
> >>> As was stated already in this thread, the expected follow up drafts
> >>> for MTI security have not been written.
> >>>
> >>> I leave it up to the Security ADs who have the real power here, but
> >>> I still prefer my original wording (including the SHOULD).
> >>>
> >>> I understand your reluctance because it's a codec, but it's the
> >>> first codec to get through the process since the Perpass work, which
> >>> basically says "everything should be encrypted."  Since you cannot
> >>> go back in time to modify the existing RFCs, you can augment them
> >>> going forward by other additions.
> >>>
> >>> As for the concern about "different security requirements for
> >>> different codecs", frankly I don't buy that argument.  Either your
> >>> RTP application supports security or it doesn't.  Once it does, it
> >>> should be able to negotiate that along side the codec negotitation.
> >>> So I don't see the concern -- we're not mandating a specific
> >>> security technology, just that you SHOULD use one.  Well, that's
> >>> true regardless of the codec, isn't it?
> >>>
> >>> Or are you really saying "We don't care about security.  We just
> >>> want to be able to use this codec in existing, insecure RTP
> >>> applications without adding new securty measures"?
> >>
> >> I'm saying this is the wrong layer to solve the problem.
> >>
> >> We had some work planned to better specify this in general for RTP. I
think
> the right answer is finish that work. If we do that right, it should apply
> regardless of codec.
> >>
> > That's exactly right.
> >
> > We've had this conversation several times before. The individual payload
> documents are not the place to add the kind of guidance Derek is asking
for.
> They should be about how you put things in RTP, not how applications use
(and
> secure RTP), unless there's something unique about the payload that
interacts
> with the general mechanics for using and securing RTP.
> >
> > Stephen will remember that we've queued up work on a document that would
> describe securing unicast RTP set up with SDP (capturing the outcome of
the
> rtpsec bof at IETF68). The last I heard on the subject Dan Wing was taking
the
> token to work on that document, but it's been awhile. That's where the
effort
> should focus - an individual payload document is not the right place.
> 
> +1
> 
> As Robert, and others, say, RTP payload format documents are not the right
> place to mandate security mechanisms. This is the point of RFC7202, which
is
> about how strong security can best be defined for classes of RTP
applications.
> This is not in conflict with the perpass work, since the goal of RFC7202
is to
> show how to provide strong security.
[Roni Even] What Colin says +1

> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload