Subject: Re: [sipcore] draft-dawes-sipcore-mediasec-parameter-02

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Wed, 9 Sep 2015 16:06:04 +0000

Hello Adam,
Thanks very much for the clear guidance and comments on procedure and technical issues with  https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-02.txt. It seems that the first step is to find the correct working group to discuss this draft. In case it influences which IETF working group is appropriate, I should point out that the header field parameter introduced by this draft originates from 3GPP specifications and related procedures and header field values are also described in 3GPP specifications. The purpose of this draft is to name the header field parameter, give several illustrative examples to make it clear how it is used, and set up an IANA registry for existing and future values. The draft does not propose that IETF defines any new security setup procedures, ciphering, integrity protection etc. Should I post again to the dispatch list, or is it now a sipcore decision whether the draft belongs in sipcore or somewhere else?
I realise that the nontrivial issues you identify below probably need to be explored and (if possible) resolved. I can respond here on the sipcore list but I guess that discussion might happen elsewhere.

Regards,
Peter

From: Adam Roach [mailto:[email-masked]]
Sent: 12 August 2015 22:55
To: Dawes, Peter, Vodafone Group; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [sipcore] draft-dawes-sipcore-mediasec-parameter-02

On 8/10/15 03:46, Dawes, Peter, Vodafone Group wrote:
Hello All,
https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-02.txt was dispatch-ed to the sipcore working group over a year ago (see From: Cullen Jennings <fluffy at iii.ca>, To: "dispatch at ietf.org list" <dispatch at ietf.org>, Date: Tue, 5 Nov 2013 16:40:39 -0800) and I would like to try to move it towards a conclusion.

[as chair]

Peter:

Thanks for bringing this to our attention. I did miss the original DISPATCH decision to send it to SIPCORE; typically, proponents of dispatched work will bring the work to the attention of the working group that they have been sent to in relatively short order.

Unfortunately, SIPCORE is not the correct venue for this work unless we elect to recharter. The fundamental statement of SIPCORE's purpose is described in its charter as:
The SIPCore working group will concentrate on specifications that
update or replace the core SIP specifications. In this context,
"update" means replacing or modifying protocol elements in the above
listed RFCs in ways that would affect most or all implementations of
those RFCs alone. Extensions to SIP that add new functionality that
would not be required of all implementations will be done outside of
this WG.
As much as I hate this kind of redirection, I fear that this work is going to need to be redispatched either to a different group (perhaps SAAG?) or sponsored by an area director.

Beyond the issue of venue, I think there are some nontrivial issues with the document as it is currently formulated. As you correctly point out, RFC3329 deals with issues of signaling ("metadata"), while this proposal deals with media (actual user content). These have very different security considerations associated with them, and I do not believe that the RFC3329 framework security analysis contemplated its extension to the media plane.

I also note that this document seems to be attempting to subvert the registration policy defined in RFC3329, which requires "mechanism-name" values to be IANA registered according to the policy called "IETF Consensus." Section 9.1 of draft-dawes-sipcore-mediasec-parameter-02 attempts to redefine mechanism-name registrations to instead use the much more lax policy of "Specification Required" for security mechanisms that use the "mediasec" parameter. This kind of policy change would minimally require the document to explicitly update RFC3329; and, in order to do so, it would need to be Standards Track.

Any document that changes an IANA registration policy, as this one does, also needs a discussion of why the the analysis that lead to WG consensus around the original registration policy was incorrect.

Finally, on a personal note, I believe that the overarching goal of defining new mechanisms to deploy SDES-SRTP (which is clearly the sole purpose of this document) runs counter to the prevailing security practices in the IETF, as evidenced by (a) the rejection of SDES-SRTP for use in RTCWEB; (b) the publication of RFC 2804; and (c) the publication of RFC 7258. I suspect that a full deprecation of SDES-SRTP is likely to happen in the foreseeable future, and certainly see no value in investing new work in promoting its use.

/a