Cullen,
That is absolutely not the intent of the document. From the Introduction, 2nd
paragraph:
The IETF policy on Strong Security Requirements for IETF Standard
Protocols [RFC3365] (the so-called "Danvers Doctrine") states that
"we MUST implement strong security in all protocols to provide for
the all too frequent day when the protocol comes into widespread use
in the global Internet". The security mechanisms defined for use
with RTP allow these requirements to be met. However, since RTP is a
protocol framework that is suitable for a wide variety of use cases,
there is no single security mechanism that is suitable for every
scenario. This memo outlines why this is the case, and discusses how
users of RTP can meet the requirement for strong security.
You will note that last sentence "This memo...discusses how users of RTP can
meet the requirement for strong security". Experience has shown that just
saying "use SRTP" is not sufficient: SRTP is not suitable to secure all uses of
RTP, and the keying mechanisms needed are wildly different across different use
domains. The draft explains in more detail why this is the case, and makes the
case that we need -- as you suggest -- drafts explaining how to secure each
class of applications using RTP (telephony, WebRTC, IPTV, etc.). It doesn't
actually specify security, that it true. Rather is references to
draft-ietf-avtcore-rtp-security-options (also in IETF last call) which
describes the available security options, and refers to the drafts that do
define mandatory-to-implement security for different application domains (e.g.,
the WebRTC security architecture).
If some part of the draft is unclear about this, and can possibly be
interpreted to allow insecure use of RTP, please explain what, and we will fix
it.
Colin
On 9 Dec 2013, at 23:24, Cullen Jennings (fluffy) <fluffy(_at_)cisco(_dot_)com>
wrote:
This document says RTP does not need to specify a security mechanisms and
that's OK. Note this document could says you must do A or B depending on the
situation but it does not. It just says it is ok not to specify anything.
My read of the consensus at last plenary was that the IETF had decided it was
going to stop doing that. I don't care about if this draft is published as it
or not as I think this draft will have zero impact to what is deployed. I do
think it is worth us being consistent on what security we expect to have in
RFC going forward.
All I am asking is the IESG be consistent about how they judge consensus on
this and if they decide to publish it, provide some guidance on when they
think it is fine to not have security and when they think it is not fine.
On Dec 6, 2013, at 4:40 AM, Colin Perkins <csp(_at_)csperkins(_dot_)org>
wrote:
Cullen,
On 5 Dec 2013, at 16:56, Cullen Jennings (fluffy)
<fluffy(_at_)cisco(_dot_)com> wrote:
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.
I'm confused about your objection, since this draft states that we need to
do exactly as you propose.
Colin
--
Colin Perkins
http://csperkins.org/
_______________________________________________
Audio/Video Transport Core Maintenance
avt(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/avt