Re: [AVTCORE] Last Call: <draft-ietf-avt-srtp-not-mandatory-14.txt> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single Media Security Solution) to Informational RFC

On Dec 5, 2013, at 4:12 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

> Cullen,
> Let's say hypothetically that the AVTcore WG will propose and get consensus
> that for RTCweb usage the security mechanism MUST use SDES for key exchange,
> do you see this as a binding recommendation for RTCweb? The selection was
> done by RTCweb and not by AVTcore.

I was pushing more on the privacy / confidentiality for RTP vs the keying, so more SRTP than SDES. 

> 
> The document does not say that there should be no security but says that it
> is up to the usage or a for a decision. The security option document provide
> the information about the different security options available and where
> they are used.
> 
> Roni Even
> 
>> -----Original Message-----
>> From: avt [mailto:avt-bounces@ietf.org] On Behalf Of Cullen Jennings
> (fluffy)
>> Sent: 05 December, 2013 6:57 PM
>> To: ietf@ietf.org
>> Cc: avt@ietf.org WG
>> Subject: Re: [AVTCORE] Last Call:
> <draft-ietf-avt-srtp-not-mandatory-14.txt>
>> (Securing the RTP Protocol Framework: Why RTP Does Not Mandate a Single
>> Media Security Solution) to Informational RFC
>> 
>> 
>> Given the hum in the IETF plenary at the last IETF, I no longer think this
>> document represents IETF consensus. Given the hum in RTCWeb working group,
>> I doubt this represents the consensus of the RAI area either.
>> 
>> I think I would be tempted to resolve this by saying for each different
> scenario
>> RTP is used in (SIP, RTSP, Mulitcast etc) exactly how it needs to be
> secured and
>> for scenarios not listed such as new usages, what the requirements are.
> For
>> something like SIP, having just one way to secure RTP is much better than
>> having many ways.
>> 
>> 
>> 
>> On Nov 22, 2013, at 3:07 PM, The IESG <iesg-secretary@ietf.org> wrote:
>> 
>>> 
>>> The IESG has received a request from the Audio/Video Transport Core
>>> Maintenance WG (avtcore) to consider the following document:
>>> - 'Securing the RTP Protocol Framework: Why RTP Does Not Mandate a
> Single
>>>  Media Security Solution'
>>> <draft-ietf-avt-srtp-not-mandatory-14.txt> as Informational RFC
>>> 
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to the
>>> ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may
>>> be sent to iesg@ietf.org instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>> 
>>> Abstract
>>> 
>>> 
>>>  This memo discusses the problem of securing real-time multimedia
>>>  sessions, and explains why the Real-time Transport Protocol (RTP),
>>>  and the associated RTP Control Protocol (RTCP), do not mandate a
>>>  single media security mechanism.  Guidelines for designers and
>>>  reviewers of future RTP extensions are provided, to ensure that
>>>  appropriate security mechanisms are mandated, and that any such
>>>  mechanisms are specified in a manner that conforms with the RTP
>>>  architecture.
>>> 
>>> 
>>> 
>>> 
>>> The file can be obtained via
>>> http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/
>>> 
>>> IESG discussion can be tracked via
>>> http://datatracker.ietf.org/doc/draft-ietf-avt-srtp-not-mandatory/ball
>>> ot/
>>> 
>>> 
>>> No IPR declarations have been submitted directly on this I-D.
>>> 
>>> 
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>> 
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
> 