From nobody Mon Aug 10 01:47:07 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E51B335A for ; Mon, 10 Aug 2015 01:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzM566r7-aI3 for ; Mon, 10 Aug 2015 01:47:01 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FE41B3360 for ; Mon, 10 Aug 2015 01:47:00 -0700 (PDT) Received: from [85.158.138.179] by server-3.bemta-3.messagelabs.com id C9/91-01753-30568C55; Mon, 10 Aug 2015 08:46:59 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-12.tower-169.messagelabs.com!1439196418!20308351!1 X-Originating-IP: [195.232.244.136] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5392 invoked from network); 10 Aug 2015 08:46:58 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.244.136) by server-12.tower-169.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Aug 2015 08:46:58 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout04.vodafone.com (Postfix) with ESMTP id 3mqWBB3Fs1znTYV for ; Mon, 10 Aug 2015 10:46:58 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3mqWBB23qMzxPZj for ; Mon, 10 Aug 2015 10:46:58 +0200 (CEST) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3mqWBB1kHDzxPJ1 for ; Mon, 10 Aug 2015 10:46:58 +0200 (CEST) Received: from VOEXC10W.internal.vodafone.com (145.230.101.30) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 10 Aug 2015 10:46:56 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.43]) by VOEXC10W.internal.vodafone.com ([145.230.101.30]) with mapi id 14.03.0224.002; Mon, 10 Aug 2015 10:46:56 +0200 From: "Dawes, Peter, Vodafone Group" To: "sipcore@ietf.org" Thread-Topic: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 Thread-Index: AdDTSMpMyYypWxRFRBO/IBP5AFvgsQ== Date: Mon, 10 Aug 2015 08:46:55 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FF@VOEXM31W.internal.vodafone.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FFVOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Subject: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 08:47:06 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FFVOEXM31Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-02.txt was d= ispatch-ed to the sipcore working group over a year ago (see From: Cullen J= ennings , To: "dispatch at ietf.org list" , Date: Tue, 5 Nov 2013 16:40:39 -0800) and I would like to try to m= ove 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 plan= e 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 secur= ity 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 othe= r RFC, the only impact is the new header field parameter and to create a ne= w IANA registry for media plane security mechanism names - the draft contains many signalling examples (clause 6) with the aim of ma= king use of the proposed new header field parameter clear Comments on this draft would be appreciated as it would help 3GPP to have a= n IANA registry for the media plane security mechanisms used in its specifi= cations. Thanks and best regards, Peter --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FFVOEXM31Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 simpl= e proposal, which is a new header field parameter to be used with the heade= r fields introduced by RFC 3329. This header field parameter identifies the security mechanisms listed in t= he header field as media plane ones, therefore the draft requests a new IAN= A registry for the mechanism names.

 

The following bullet points summarize the draft:

 

- builds on the UA to first-hop proxy security mecha= nism 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 i= s that signalling security must be started as early as possible whereas med= ia security is optional and used (or not used) on-the-fly by UA and first-h= op 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 param= eter and to create a new IANA registry for media plane security mechanism n= ames

- the draft contains many signalling examples (claus= e 6) with the aim of making use of the proposed new header field parameter = clear 

 

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

 

Thanks and best regards,

Peter

--_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FFVOEXM31Winterna_-- From nobody Tue Aug 11 05:07:06 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0A11A88DC for ; Tue, 11 Aug 2015 05:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.859 X-Spam-Level: X-Spam-Status: No, score=-3.859 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhJbbTWaEm1u for ; Tue, 11 Aug 2015 05:07:02 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89A31A88E4 for ; Tue, 11 Aug 2015 05:07:01 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail41.telekom.de with ESMTP; 11 Aug 2015 14:06:49 +0200 X-IronPort-AV: E=Sophos;i="5.15,652,1432591200"; d="scan'208,217";a="722287514" Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 11 Aug 2015 14:06:48 +0200 Received: from HE113667.emea1.cds.t-internal.com ([fe80::c943:1394:e86e:fce3]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 11 Aug 2015 14:06:48 +0200 From: To: , Date: Tue, 11 Aug 2015 14:06:47 +0200 Thread-Topic: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 Thread-Index: AdDTSMpMyYypWxRFRBO/IBP5AFvgsQAtvMgg Message-ID: <058CE00BD4D6B94FAD033A2439EA1E4B01F48FE5AA0A@HE113667.emea1.cds.t-internal.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FF@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FF@VOEXM31W.internal.vodafone.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_058CE00BD4D6B94FAD033A2439EA1E4B01F48FE5AA0AHE113667eme_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 12:07:04 -0000 --_000_058CE00BD4D6B94FAD033A2439EA1E4B01F48FE5AA0AHE113667eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, thank you for pointing to this draft. We are very interested in this since we want to use and implement this para= meter. Thus we fully support this draft and would be happy to proceed with it. Best Regards Roland Von: sipcore [mailto:sipcore-bounces@ietf.org] Im Auftrag von Dawes, Peter,= Vodafone Group Gesendet: Montag, 10. August 2015 10:47 An: sipcore@ietf.org Betreff: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 Hello All, https://www.ietf.org/id/draft-dawes-sipcore-mediasec-parameter-02.txt was d= ispatch-ed to the sipcore working group over a year ago (see From: Cullen J= ennings , To: "dispatch at ietf.org list" , Date: Tue, 5 Nov 2013 16:40:39 -0800) and I would like to try to m= ove 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 plan= e 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 secur= ity 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 othe= r RFC, the only impact is the new header field parameter and to create a ne= w IANA registry for media plane security mechanism names - the draft contains many signalling examples (clause 6) with the aim of ma= king use of the proposed new header field parameter clear Comments on this draft would be appreciated as it would help 3GPP to have a= n IANA registry for the media plane security mechanisms used in its specifi= cations. Thanks and best regards, Peter --_000_058CE00BD4D6B94FAD033A2439EA1E4B01F48FE5AA0AHE113667eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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 wo= uld be happy to proceed with it.

=  

Best Regards

 

Roland

<= span lang=3DEN-US style=3D'color:#1F497D'> 

 

Von: sipcore [mailto:sipcore-b= ounces@ietf.org] Im Auftrag von Dawes, Peter, Vodafone Group
G= esendet: Montag, 10. August 2015 10:47
An: sipcor= e@ietf.org
Betreff: [sipcore] draft-dawes-sipcore-mediasec-parame= ter-02

 

He= llo 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: Cu= llen 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 th= e 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:<= /span>

 <= /p>

- builds on the UA to first-hop = proxy security mechanism negotiation in RFC 3329

- RFC 3329 applies to securing the signa= lling 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-th= e-fly by UA and first-hop proxy

<= span lang=3DEN-GB>- the draft does not add any UA procedures to those in RF= C 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<= o:p>

- the draft co= ntains many signalling examples (clause 6) with the aim of making use of th= e 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 securit= y mechanisms used in its specifications.

 

Thanks and best regards,

Peter

= --_000_058CE00BD4D6B94FAD033A2439EA1E4B01F48FE5AA0AHE113667eme_-- From nobody Wed Aug 12 14:55:35 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79D0D1ACE56 for ; Wed, 12 Aug 2015 14:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6yT4boS60RF for ; Wed, 12 Aug 2015 14:55:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CD9F1ACE55 for ; Wed, 12 Aug 2015 14:55:32 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7CLtUlN035278 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Aug 2015 16:55:31 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <55CBC0D1.5050901@nostrum.com> Date: Wed, 12 Aug 2015 16:55:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Dawes, Peter, Vodafone Group" , "sipcore@ietf.org" References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FF@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FF@VOEXM31W.internal.vodafone.com> Content-Type: multipart/alternative; boundary="------------010907010103060306000601" Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , "art-ads@tools.ietf.org" Subject: Re: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 21:55:34 -0000 This is a multi-part message in MIME format. --------------010907010103060306000601 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 , To: "dispatch at ietf.org > list" , 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 --------------010907010103060306000601 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
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
--------------010907010103060306000601-- From nobody Fri Aug 14 17:28:26 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D9C1B2ACF; Fri, 14 Aug 2015 17:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgRDv7sWRLn2; Fri, 14 Aug 2015 17:28:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD1F1B2AF1; Fri, 14 Aug 2015 17:28:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 74D86180205; Fri, 14 Aug 2015 17:28:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150815002811.74D86180205@rfc-editor.org> Date: Fri, 14 Aug 2015 17:28:11 -0700 (PDT) Archived-At: Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7621 on A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Aug 2015 00:28:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7621 Title: A Clarification on the Use of Globally Routable User Agent URIs (GRUUs) in the SIP Event Notification Framework Author: A.B. Roach Status: Standards Track Stream: IETF Date: August 2015 Mailbox: adam@nostrum.com Pages: 4 Characters: 6891 Updates: RFC 6665 I-D Tag: draft-ietf-sipcore-6665-clarification-00.txt URL: https://www.rfc-editor.org/info/rfc7621 DOI: http://dx.doi.org/10.17487/RFC7621 Experience since the publication of the most recent SIP Events framework (in July 2012) has shown that there is room for interpretation around the use of Globally Routable User Agent URIs in that specification. This document clarifies the intended behavior. This document updates RFC 6665. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed Aug 26 11:49:15 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42DD1B30A5; Wed, 26 Aug 2015 11:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGe7Bro-bTkW; Wed, 26 Aug 2015 11:49:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C63D81B3099; Wed, 26 Aug 2015 11:49:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B3866180473; Wed, 26 Aug 2015 11:48:50 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150826184850.B3866180473@rfc-editor.org> Date: Wed, 26 Aug 2015 11:48:50 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7614 on Explicit Subscriptions for the REFER Method X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 18:49:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7614 Title: Explicit Subscriptions for the REFER Method Author: R. Sparks Status: Standards Track Stream: IETF Date: August 2015 Mailbox: rjsparks@nostrum.com Pages: 14 Characters: 32358 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-refer-explicit-subscription-03.txt URL: https://www.rfc-editor.org/info/rfc7614 DOI: http://dx.doi.org/10.17487/RFC7614 The Session Initiation Protocol (SIP) REFER request, as defined by RFC 3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible and complicates avoiding SIP dialog sharing. This document defines extensions to REFER that remove the implicit subscription and, if desired, replace it with an explicit one. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC