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

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Mon, 10 Aug 2015 08:46:55 +0000

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. This draft reached version -07 in dispatch and makes a simple proposal, which is a new header field parameter to be used with the header fields introduced by RFC 3329. This header field parameter identifies the security mechanisms listed in the header field as media plane ones, therefore the draft requests a new IANA registry for the mechanism names.

The following bullet points summarize the draft:

- builds on the UA to first-hop proxy security mechanism negotiation in RFC 3329
- RFC 3329 applies to securing the signalling plane, this draft applies to securing the media plane
- the only difference in the negotiation mechanism is that signalling security must be started as early as possible whereas media security is optional and used (or not used) on-the-fly by UA and first-hop proxy
- the draft does not add any UA procedures to those in RFC 3329 or any other RFC, the only impact is the new header field parameter and to create a new IANA registry for media plane security mechanism names
- the draft contains many signalling examples (clause 6) with the aim of making use of the proposed new header field parameter clear

Comments on this draft would be appreciated as it would help 3GPP to have an IANA registry for the media plane security mechanisms used in its specifications.

Thanks and best regards,
Peter

---

From: <[email-masked]>
Date: Tue, 11 Aug 2015 14:06:47 +0200

Hi Peter,
thank you for pointing to this draft.
We are very interested in this since we want to use and implement this parameter.
Thus we fully support this draft and would be happy to proceed with it.

Best Regards

Roland

Von: sipcore [mailto:[email-masked]] Im Auftrag von Dawes, Peter, Vodafone Group
Gesendet: Montag, 10. August 2015 10:47
An: [email-masked]
Betreff: [sipcore] draft-dawes-sipcore-mediasec-parameter-02

Hello All,

Thanks and best regards,
Peter

---

From: Adam Roach <[email-masked]>
Date: Wed, 12 Aug 2015 16:55:29 -0500

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