On Dec 5, 2013, at 4:12 PM, Roni Even <ron.even.tlv@xxxxxxxxx> 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@xxxxxxxx] On Behalf Of Cullen Jennings > (fluffy) >> Sent: 05 December, 2013 6:57 PM >> To: ietf@xxxxxxxx >> Cc: avt@xxxxxxxx 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@xxxxxxxx> 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@xxxxxxxx mailing lists by 2013-12-06. Exceptionally, comments may >>> be sent to iesg@xxxxxxxx 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@xxxxxxxx >>> https://www.ietf.org/mailman/listinfo/avt >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/avt >