From nobody Wed May 1 04:35:47 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A5B120041; Wed, 1 May 2019 04:35:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipbrandy@ietf.org Message-ID: <155671053889.950.13922716498900044582@ietfa.amsl.com> Date: Wed, 01 May 2019 04:35:38 -0700 Archived-At: Subject: [Sipbrandy] I-D Action: draft-ietf-sipbrandy-osrtp-09.txt X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 11:35:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Best-practice Recommendations Against Network Dangers to privacY WG of the IETF. Title : An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) Authors : Alan Johnston Bernard Aboba Andrew Hutton Roland Jesske Thomas Stach Filename : draft-ietf-sipbrandy-osrtp-09.txt Pages : 9 Date : 2019-05-01 Abstract: Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP does not require SDP extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for SRTP. OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-09 https://datatracker.ietf.org/doc/html/draft-ietf-sipbrandy-osrtp-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipbrandy-osrtp-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 1 04:40:01 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FD3120103; Wed, 1 May 2019 04:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cugHlk4B74o1; Wed, 1 May 2019 04:39:56 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 770031200F1; Wed, 1 May 2019 04:39:56 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id 88so5743884uau.6; Wed, 01 May 2019 04:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xfi2VbJr9NNxxXxvnqqX4O6JLNse7G4LF/o0ACCGVuo=; b=gT0aYBPeIpRVu6qcRnl2RldA3w96ZnEg9T4Caa20vNiZAjEOACOqnb4datEF3Rbxlo THEv3b1wFXsYV9IcCKqI1DhtPqPgiWma7ODwxVnG6j8sikarKcjWtPCFFV/K/JPNwG/L z1wlR2xaZMtuBdnT2CHnAJuhJozzwhgscQ4hY7eyrn9UjC4BvhNzecGTH159PKLtepIZ xeXk8Qw/GuaXooLh0Tsi/VBLPY0vGZmYGBGBLHpWIP8AeIPgbUL3Ve487QeBEaYpmg7I qY+u29nO/RsdJXN/YzGrda20n4t5j0dJIGABRLirST05C5Z1LO1ydjqvU1Lp9w0od6H1 4RNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xfi2VbJr9NNxxXxvnqqX4O6JLNse7G4LF/o0ACCGVuo=; b=TmQk3Cp3D6RIYzcUa2xQTZs13Y6yOhIiQkXC/FR7JFpJb2k6NKGSWZHpqFLqOmQvqT HEKnghZfvu+974dtZ3Tx/r7OVks1bbNA7zOIcsIN/vi0shJMNohe+Lkw4GqJojBlwpv7 tU+8lyq/+jpR9AzBJvZHiNQ1fodxCM8CQAJqMG+6a7NpXHOUnhcKJgYlljEDmpSg5mjr Cf7YJrLjvkHNRl1TblbeufPPUysA2lOnFs1LBvFVMoFgTbxoJiibLx2Q+WUZTQ5EYT9h JAQ8Lyq1kyJD8mPCEs2QzSSl+zyC1e9hFgkRjw679nxSLMkL9YCbIOj6JZNM+ljQn5ae f2ww== X-Gm-Message-State: APjAAAVogXendiBn1hD73qNVAD6TKKMGr99gtQgBbZhnOZooTJP8diYV Sbx9yDIyFTuhKO0VuDB27HP/5QHeikOesDw94O7/ltZhqgo= X-Google-Smtp-Source: APXvYqyWWXohK+OnYQS6nUd9fJgTE0V6i/RgzwldjOuEz9qTnrX72NgOAyCwe7yF6vq41FoVnPp065KSYHI4wZ/T58Y= X-Received: by 2002:ab0:25cc:: with SMTP id y12mr3597909uan.113.1556710795403; Wed, 01 May 2019 04:39:55 -0700 (PDT) MIME-Version: 1.0 References: <72C42C63-D5C4-403D-A895-429CB2238AC3@nostrum.com> <741719ee-bbc6-adaf-a036-8fdd655e470f@ericsson.com> <8a1ab85c-0dd3-7db8-57ff-c7e76fffde62@ericsson.com> In-Reply-To: <8a1ab85c-0dd3-7db8-57ff-c7e76fffde62@ericsson.com> From: Andy Hutton Date: Wed, 1 May 2019 12:39:44 +0100 Message-ID: To: Gonzalo Camarillo Cc: Ben Campbell , "sipbrandy@ietf.org" , "draft-ietf-sipbrandy-osrtp.all@ietf.org" , ART ADs Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Sipbrandy] AD Evaluation of draft-ietf-sipbrandy-osrtp-07 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 11:40:00 -0000 Done. The -09 draft has been submitted with text suggested by Ben, with minor tweaks from me, in the security considerations section. https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-09 Regards Andy On Fri, 26 Apr 2019 at 11:45, Gonzalo Camarillo wrote: > > Hi Andy, > > yes, please, go ahead revise the draft so that Ben's AD review is > addressed. Alexey will take it from there. > > Cheers, > > Gonzalo > > On 25-Apr-19 14:07, Andy Hutton wrote: > > Thanks Ben for suggesting text. > > > > I would be happy to add the text Ben suggested to the security > > considerations section if that is what is needed to get this done. > > > > Regards > > Andy > > > > > > > > On Tue, 23 Apr 2019 at 22:25, Ben Campbell wrote: > >> > >> (Please keep in mind I am no longer an AD; at this point my concern sh= ould be treated like last call feedback.) > >> > >> The issue with SDES is that, while SDES says messages with =E2=80=9Ca= =3Dcrypto=E2=80=9D SHOULD be protected end-to-end, and that hop-by-hop thin= gs such as TLS and IPSec SHOULD NOT be used across with intermediaries, in = practice that SHOULD and SHOULD NOT are routinely ignored. > >> > >> I don=E2=80=99t think this requires a huge change. I propose adding a = paragraph to the effect of the following before the current last paragraph = in section 4: > >> > >> =E2=80=9CWhile OSRTP does not require authentication of the key-agreem= ent mechanism, it does need them to avoid exposing > >> SRTP keys to eavesdroppers, since this could enable passive attacks ag= ainst SRTP. Section 8.3 of [RFC4568] requires that any messages that conta= in SRTP keys be encrypted, and further says that encryption =E2=80=9CSHOULD= =E2=80=9D provide end-to-end confidentiality protection if intermediaries = that could inspect the SDP message are present. At the time of this writing= , that =E2=80=9CSHOULD=E2=80=9D is commonly ignored. Therefore, if OSRTP is= used with Security Descriptions, any such intermediaries (e.g., SIP proxie= s) must be assumed to have access to the SRTP keys.=E2=80=9D > >> > >> Thanks! > >> > >> Ben. > >> > >> > >> > >>> On Apr 8, 2019, at 5:47 AM, Andy Hutton w= rote: > >>> > >>> I looked at this again and I am not convinced that any further change= s > >>> to the draft are needed but if someone wants to suggest text then I > >>> can include it in the draft. > >>> > >>> In the case of SDES the security considerations states that an > >>> encrypted signalling channel must still be used so this draft changes > >>> nothing with respect to intermediaries and the SDES (RFC 4568) > >>> security considerations still apply. > >>> > >>> Regards > >>> Andy > >>> > >>> On Tue, 2 Apr 2019 at 14:56, Gonzalo Camarillo > >>> wrote: > >>>> > >>>> Hi Andy, > >>>> > >>>> Ben's response below indicates that his main substantive comment was= not > >>>> addressed in the revision you submitted last week. Could you please = look > >>>> into it and get back to Ben? Thanks! > >>>> > >>>>>> With regard to Ben's comment on the relaxing of the authentication > >>>>>> requirement then this is consistent with the Opportunistic > >>>>>> Security RFC 7435 and I added a reference to this as > >>>>>> clarification. > >>>>> > >>>>> If I recall correctly, RFC 7435 does not discuss scenarios with > >>>>> separate signaling and media channels, and how OS applies to each > >>>>> channel. I was looking more for something about the impacts of this > >>>>> =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scenarios w= ith dtls-srtp and > >>>>> sdes, and resulting assurances. > >>>>> > >>>>> For example, dtls-srtp with no authentication does not give you > >>>>> assurances about who you are talking to, but it still allows > >>>>> encryption. SDES without encryption lets an eavesdropper potentiall= y > >>>>> learn the encryption keys, etc. SDES with transport level protectio= n > >>>>> (e.g. SIPS) protects from off-path eavesdroppers, but allows proxie= s > >>>>> and b2bua=E2=80=99s in the signaling path to learn the encryption k= eys. > >>>> > >>>> > >>>> Cheers, > >>>> > >>>> Gonzalo > >>>> > >>>> On 02-Apr-19 16:50, Andy Hutton wrote: > >>>>> I believe all Ben's points are addressed in the draft I submitted > >>>>> last week https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > >>>>> > >>>>> Regards Andy > >>>>> > >>>>> On Tue, 2 Apr 2019 at 12:03, Gonzalo Camarillo > >>>>> wrote: > >>>>>> > >>>>>> Hi Andy, authors, > >>>>>> > >>>>>> could you please let Alexey when he should expect a new revision o= f > >>>>>> this draft that addresses Ben's point below? > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Gonzalo > >>>>>> > >>>>>> On 26-Mar-19 18:10, Ben Campbell wrote: > >>>>>>> (+Alexey, who will take over SIPBRANDY when I step down as AD) > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Thanks for the response. This does not quite address my main > >>>>>>> substantive comment. It does address everything else :-) > >>>>>>> > >>>>>>> Please see comment in line. > >>>>>>> > >>>>>>> Thanks! > >>>>>>> > >>>>>>> Ben. > >>>>>>> > >>>>>>>> On Mar 26, 2019, at 11:58 AM, Andy Hutton > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>> I submitted an update in response to Ben's comments - > >>>>>>>> https://tools.ietf.org/html/draft-ietf-sipbrandy-osrtp-08 > >>>>>>>> > >>>>>>>> With regard to Ben's comment on the relaxing of the > >>>>>>>> authentication requirement then this is consistent with the > >>>>>>>> Opportunistic Security RFC 7435 and I added a reference to this > >>>>>>>> as clarification. > >>>>>>> > >>>>>>> If I recall correctly, RFC 7435 does not discuss scenarios with > >>>>>>> separate signaling and media channels, and how OS applies to each > >>>>>>> channel. I was looking more for something about the impacts of > >>>>>>> this =E2=80=9Crelaxation=E2=80=9D specific to these sorts of scen= arios with > >>>>>>> dtls-srtp and sdes, and resulting assurances. > >>>>>>> > >>>>>>> For example, dtls-srtp with no authentication does not give you > >>>>>>> assurances about who you are talking to, but it still allows > >>>>>>> encryption. SDES without encryption lets an eavesdropper > >>>>>>> potentially learn the encryption keys, etc. SDES with transport > >>>>>>> level protection (e.g. SIPS) protects from off-path > >>>>>>> eavesdroppers, but allows proxies and b2bua=E2=80=99s in the sign= aling > >>>>>>> path to learn the encryption keys. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Hopefully we can get this to RFC status now. > >>>>>>>> > >>>>>>>> Regards Andy > >>>>>>>> > >>>>>>>> On Mon, 25 Mar 2019 at 22:26, Andy Hutton > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Sorry about the delay. > >>>>>>>>> > >>>>>>>>> See below. > >>>>>>>>> > >>>>>>>>> I will update the draft. > >>>>>>>>> > >>>>>>>>> Andy > >>>>>>>>> > >>>>>>>>> On Fri, 15 Feb 2019 at 08:46, Gonzalo Camarillo > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Thanks for the quick review, Ben! > >>>>>>>>>> > >>>>>>>>>> Authors, please address Ben's comments below. > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> > >>>>>>>>>> Gonzalo > >>>>>>>>>> > >>>>>>>>>> On 14-Feb-19 22:46, Ben Campbell wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> This is my AD Evaluation of > >>>>>>>>>>> draft-ietf-sipbrandy-osrtp-07. > >>>>>>>>>>> > >>>>>>>>>>> Thank you for a readable and easy to understand > >>>>>>>>>>> document.There is one comment I would like to resolve > >>>>>>>>>>> prior to IETF LC. The others can be resolved along with > >>>>>>>>>>> any last call feedback. > >>>>>>>>>>> > >>>>>>>>>>> *** Please resolve prior to IETF LC *** > >>>>>>>>>>> > >>>>>>>>>>> =C2=A74: The relaxation of authentication requirements for > >>>>>>>>>>> DTLS-SRTP and SDES could use some elaboration on why this > >>>>>>>>>>> acceptable. I _think_ the answer is that, since OSRTP > >>>>>>>>>>> doesn=E2=80=99t guaranty authentication, there=E2=80=99s no n= eed for such > >>>>>>>>>>> a guaranty from the signaling channel. Is that correct? > >>>>>>>>>>> > >>>>>>>>>>> OTOH, =C2=A71 says "third mode for security between > >>>>>>>>>>> "cleartext=E2=80=9D and "comprehensive protection" that allow= s > >>>>>>>>>>> encryption and authentication to be used if supported=E2=80= =A6=E2=80=9D. > >>>>>>>>>>> That suggests that that authentication is sometimes > >>>>>>>>>>> provided. Is there a distinction between the > >>>>>>>>>>> authenticated case and unauthenticated case that should > >>>>>>>>>>> be mentioned somewhere? (For example, is there a need to > >>>>>>>>>>> indicate the distinction to the user?) > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> $1 should I think say "allows encryption and authenticated > >>>>>>>>> media" but I cannot remember why we said the signalling > >>>>>>>>> authentication requirements are relaxed this has been in the > >>>>>>>>> draft from day 1 and I guess it is consistent with the best > >>>>>>>>> effort approach. > >>>>>>>>> > >>>>>>>>> Anyone else want to comment? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>>> *** Other Substantive Comments *** > >>>>>>>>>>> > >>>>>>>>>>> =C2=A72: Please use the new boilerplate from RFC 8174. > >>>>>>>>> > >>>>>>>>> Will do. > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> =C2=A73.1: Please clarify that that the offer can contain mor= e > >>>>>>>>>>> than one key management attribute. This is mentioned in > >>>>>>>>>>> =C2=A73.1, but not actually in the section on generating the > >>>>>>>>>>> offer. > >>>>>>>>> > >>>>>>>>> Will do. > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> *** Editorial Comments *** > >>>>>>>>>>> > >>>>>>>>>>> =C2=A73: "As discussed in [RFC7435], this is the > >>>>>>>>>>> "comprehensive protection" for media mode.=E2=80=9D s/this/th= at > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> =C2=A73.4: "meaning that the decision to create an OSRTP type > >>>>>>>>>>> offer or something else should not be influenced=E2=80=9D Tha= t=E2=80=99s > >>>>>>>>>>> referring to the decision to create a _new_ offer, right? > >>>>>>>>>>> Not the original offer? > >>>>>>>>> > >>>>>>>>> Correct. > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> _______________________________________________ Sipbrandy > >>>>>>>>>>> mailing list Sipbrandy@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ Sipbrandy > >>>>>>>>>> mailing list Sipbrandy@ietf.org > >>>>>>>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>>>> > >>>>>> > >>>>> > >>>>> _______________________________________________ Sipbrandy mailing > >>>>> list Sipbrandy@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipbrandy > >>>>> > >> From nobody Thu May 2 05:38:17 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1B1200E6; Thu, 2 May 2019 05:38:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: sipbrandy@ietf.org, sipbrandy-chairs@ietf.org, draft-ietf-sipbrandy-osrtp@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo , alexey.melnikov@isode.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155680069018.24689.11460797108726433366.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 05:38:10 -0700 Archived-At: Subject: [Sipbrandy] Last Call: (An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)) to Informational RFC X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 12:38:10 -0000 The IESG has received a request from the SIP Best-practice Recommendations Against Network Dangers to privacY WG (sipbrandy) to consider the following document: - 'An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)' 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@ietf.org mailing lists by 2019-05-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in RFC 7435, applied to Real-time Transport Protocol (RTP). OSRTP allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP does not require SDP extensions or features and is fully backwards compatible with existing implementations using encrypted and authenticated media and implementations that do not encrypt or authenticate media packets. OSRTP is not specific to any key management technique for SRTP. OSRTP is a transitional approach useful for migrating existing deployments of real-time communications to a fully encrypted and authenticated state. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu May 2 17:06:34 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD59B12003F; Thu, 2 May 2019 17:06:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sipbrandy-rtpsec@ietf.org, Gonzalo Camarillo , sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155684199270.24901.13362661443332019003.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2019 17:06:32 -0700 Archived-At: Subject: [Sipbrandy] Benjamin Kaduk's No Objection on draft-ietf-sipbrandy-rtpsec-08: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 00:06:33 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipbrandy-rtpsec-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for resolving my Discuss point! From nobody Tue May 14 09:10:23 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14A120059; Tue, 14 May 2019 09:10:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , sipbrandy@ietf.org, sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, Gonzalo Camarillo , draft-ietf-sipbrandy-rtpsec@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155785020833.30210.6396763074128249678.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2019 09:10:08 -0700 Archived-At: Subject: [Sipbrandy] Protocol Action: 'Best Practices for Securing RTP Media Signaled with SIP' to Best Current Practice (draft-ietf-sipbrandy-rtpsec-08.txt) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 16:10:09 -0000 The IESG has approved the following document: - 'Best Practices for Securing RTP Media Signaled with SIP' (draft-ietf-sipbrandy-rtpsec-08.txt) as Best Current Practice This document is the product of the SIP Best-practice Recommendations Against Network Dangers to privacY Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-rtpsec/ Technical Summary: Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including both comprehensive protection solutions which bind the media to SIP-layer identities as well as opportunistic security solutions. Working Group Summary: There is consensus in the WG around this document. Document Quality: While parts of the specification have been implemented, we are not aware of any implementation that implements all of it. In fact, the goal with publishing this RFC is to get more implementations out there. Personnel: Gonzalo Camarillo is the Document Shepherd. Ben Campbell is the responsible AD. From nobody Thu May 16 15:13:53 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E7F120049; Thu, 16 May 2019 15:13:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies via Datatracker To: Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Elwyn Davies Message-ID: <155804481707.19586.13843111552522558644@ietfa.amsl.com> Date: Thu, 16 May 2019 15:13:37 -0700 Archived-At: Subject: [Sipbrandy] Genart last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 22:13:37 -0000 Reviewer: Elwyn Davies Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-sipbrandy-osrtp-09 Reviewer: Elwyn Davies Review Date: 2019-05-16 IETF LC End Date: 2019-05-16 IESG Telechat date: Not scheduled for a telechat Summary: Ready with nits.  Thanks for an easy to read document.  I am not sure about whether it is acceptable to point to an expired (and effectively totally dead) draft (draft-kaplan...) for signuficant motivation (see minor issues).  Please consult with higher authorities. Major issues: None Minor issues: S1, para 2: The discussion and motivation for the introduction of OSRTP is at least partially derived from the motivation explained in Section 1 of draft-kaplan-mmusic-best-effort-srtp.  This is a long expired draft (2007) which is not going to become an RFC.  Given this, I wonder if the text ought to be reproduced here, perhaps as an appendix? Nits/Editorial comments: Abstract: s./applied to Real-time/applied to the Real-time/ Abstract: expand SDP on first use. Abstract: expand SRTP on first use (Secure RTP). S1:  The sentences expanding the meaning of cleartext and secure media could do with a little expansion to make it clear that we are talking about media streams even if that is what RTP is supposed to be about. Suggest: OLD: In terms of secure media, cleartext is RTP [RFC3550] media which is negotiated with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile [RFC4585]. Comprehensive protection is Secure RTP [RFC3711], negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. NEW: In the context of transport of secure media streams using RTP and its secured derivatives, cleartext is represented by an RTP [RFC3550] media stream which is negotiated with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF profile [RFC4585], whereas comprehensive protection is represented by a Secure RTP [RFC3711] stream, negotiated with a secure profile, such as SAVP or SAVPF [RFC5124]. ENDS (I note that SAVP and SAVPF aren't acronyms and don't need expansion.  OTOH AVPF probably does.) S3: The terminology used in RFC 4566 and elsewhere seems to be m= sections rather than m-  sections.  Suggest s/m-/m=/g (4 places) S3.4, last sentence:  the backward reference to Section 3.1 is not in RFC format. s/section [3.1]/Section 3.1/ S4, para 3:  I think the 'must' here is normative. s/ an encrypted signaling channel must still be used./ an encrypted signaling channel MUST still be used./ S6: The note to the RFC Editor should also note that the referenceventries SIPCONNECT, RFC6982 and IMTC-SIP in s8 should also be removed. From nobody Thu May 16 20:47:55 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62880120347; Thu, 16 May 2019 20:47:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Allison Mankin via Datatracker To: Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org, allison.mankin@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Allison Mankin Message-ID: <155806486830.19511.11021785086259621978@ietfa.amsl.com> Date: Thu, 16 May 2019 20:47:48 -0700 Archived-At: Subject: [Sipbrandy] Tsvart last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 03:47:48 -0000 Reviewer: Allison Mankin Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This document doesn't raise any specifically transport-focused questions for me. I appreciated the clear discussion of the types of security arrangements that can be made by Offer-Answer SIP and I found the draft a valuable read. The implementation section is quite interesting. I have a couple of issues with Section 4, though they are not about transport. So I'm going to mention them, but defer to the Security Area beyond just flagging them. Hence, I've marked the draft Ready with Nits rather than Ready with Issues. 1. I find the two sentences below inconsistent with each other, with a small-m "must" and a cited "SHOULD" for the same issue: For SDP Security Descriptions key agreement [RFC4568], an authenticated signaling channel does not need to be used with OSRTP if it is not available, although an encrypted signaling channel must still be used. Section 8.3 of [RFC7435] requires that any messages that contain SRTP keys be encrypted, and further says that encryption "SHOULD" provide end-to- end confidentiality protection if intermediaries that could inspect the SDP message are present. Also, there isn't a section 8.3 of RFC7435. Is this an incorrect reference or a reference to a pre-publication version of RFC7435? 2. I feel the sentence below misrepresents RFC7435 with its wording "requirement for end-to-end confidentiality." RFC7435 has a preference for confidentiality of authentication if there is authentication, but TOFU means there isn't a requirement. The sentence is too general. At the time of this writing, it is understood that the [RFC7435] requirement for end-to-end confidentiality protection is commonly ignored. Editorial/Nits The section 4 reference to section 8.3 of RFC7435 needs to be fixed. From nobody Wed May 22 10:34:06 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7941201D2; Wed, 22 May 2019 10:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-sipbrandy-osrtp@ietf.org, Gonzalo Camarillo , sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155854644315.11139.1539053719256698071.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2019 10:34:03 -0700 Archived-At: Subject: [Sipbrandy] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_d?= =?utf-8?q?raft-ietf-sipbrandy-osrtp-09=3A_=28with_COMMENT=29?= X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 17:34:03 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-sipbrandy-osrtp-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is the intended status informational? Unfortunately, this is not further explained in the shepherd write-up. What was the discussion in the group and why was informational decided? As this is a protocol specification, informational does not seem appropriate. Except this is meant to only document an existing deployment but then the document should say so. I think it should rather be experimental. From nobody Mon May 27 19:15:17 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC64A120096; Mon, 27 May 2019 19:15:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sean Turner Message-ID: <155900970362.650.8194184838834826261@ietfa.amsl.com> Date: Mon, 27 May 2019 19:15:03 -0700 Archived-At: Subject: [Sipbrandy] Secdir last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 02:15:04 -0000 Reviewer: Sean Turner Review result: Has Issues I had a read of the draft as well as the GENART and TSVART reviews (to avoid duplicating comments). Summary: Ready with (minor) issues Issues: 0) I assume that the mismatch the TSVART refers to in the security considerations has to do with 1) changing 4568 to require encryption but not fail if authentication is not available, 2) pointing out that 4568's requirement is routinely ignore for end-to-end encryption because using TLS with intermediaries won't protect the SDP key, and 3) and reference errors (see the next issue). On 1, that's kind the point of OSRTP - take the encryption you can get. On 2, because it's the security considerations this document is just saying don't expect to get end-to-end. Assuming, I've interpreted this I think this draft is okay. 1) I think these are just reference errors, but it would be good to double check these (and I hadn't seen a response yet - might have missed it): S4: Not sure about these references too RFC7435. Maybe they should be to RFC 4568 instead? s/The security considerations of [RFC7435] apply to OSRTP, /The security considerations of [RFC4568] apply to OSRTP, s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568] s/understood that the [RFC7435]/understood that the [RFC4568] Bikesheds: 0) The fact that it's Informational struck me as odd. 1) The fact there are no updates listed also strikes me as odd. Nits: 0) s2: Nits reports an error with the para. I think it's: s/RFC 2119 [RFC2119] RFC 8174 [RFC8174] /RFC 2119 [RFC2119] [RFC8174] 1) s1, 2nd para: s/[RFC5939] ./[RFC5939]. From nobody Tue May 28 02:53:40 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 503A812008A; Tue, 28 May 2019 02:53:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-sipbrandy-osrtp@ietf.org, Gonzalo Camarillo , sipbrandy-chairs@ietf.org, sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2019 02:53:32 -0700 Archived-At: Subject: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 09:53:33 -0000 Barry Leiba has entered the following ballot position for draft-ietf-sipbrandy-osrtp-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the question of why this is Informational and why the shepherd writeup doesn't explain (the writeup says little more than "yes" and "no"). From nobody Tue May 28 08:04:21 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B86C120229; Tue, 28 May 2019 08:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 5zWx6PREeW3W; Tue, 28 May 2019 08:04:10 -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 697791201F3; Tue, 28 May 2019 08:04:03 -0700 (PDT) Received: from bens-macbook.lan (cpe-66-25-20-105.tx.res.rr.com [66.25.20.105]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x4SF3sZs043397 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 28 May 2019 10:03:55 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1559055837; bh=j/RFRi4KLrw9T5n9DLtPrFGhXkd+spA5LWK1cZV/94k=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=T4toj53/tRfPf1O2Evsd94N4OHinCSohqTyMBH24Mdrt4eavclPdXu/7jQy5V/+gV 2/rFZHd6RnUkLVRMBzd+mxwGrSFuePAQ2dYymxxZJIX8nqT9vqI03Nsybw4wOZiS09 MGsI9TftmHVW6jn5pUEV6ofRa7fYO4Dqr7Pf9DEQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-20-105.tx.res.rr.com [66.25.20.105] claimed to be bens-macbook.lan From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F02A078A-34C5-43A8-A3AD-17DEB40D4A34"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 28 May 2019 10:03:48 -0500 In-Reply-To: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> Cc: The IESG , draft-ietf-sipbrandy-osrtp@ietf.org, sipbrandy@ietf.org, sipbrandy-chairs@ietf.org, Gonzalo Camarillo To: Barry Leiba References: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 15:04:12 -0000 --Apple-Mail=_F02A078A-34C5-43A8-A3AD-17DEB40D4A34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 28, 2019, at 4:53 AM, Barry Leiba via Datatracker = wrote: >=20 >=20 [=E2=80=A6] >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I share the question of why this is Informational and why the shepherd = writeup > doesn't explain (the writeup says little more than "yes" and "no"). >=20 This was discussed quite a bit in the WG and prior to chartering. The = reasoning for =E2=80=9Cinformational=E2=80=9D was two-fold: 1) The draft does not (or was not supposed to) define new or modify = existing protocols. It talks about how one can assemble existing = building blocks to make the right things happen, not how to build new = blocks. So it seemed like the most appropriate status was either = =E2=80=9Cinformational=E2=80=9D or =E2=80=9CBCP" 2) Two of those =E2=80=9Cexisting protocols=E2=80=9D, namely ZRTP = [RFC6189] and SDP Security Descriptions [RFC4568] are not particularly = well regarded among some of our security experts, who indicated = objections to using them in a new standards track document or BCP. =46rom a strictly historical perspective, the WG originally thought it = needed to make a normative update to RFC5124. This was to be done is a = separate tightly-scoped draft to progress in MMUSIC, since SIPBRANDY was = not chartered to make normative changes to anything. However, later = discussion suggested such a change was not necessary, and the separate = draft was abandoned. I agree that the shepherd report or (my preference) the draft itself = should make this more clear. Perhaps some words could be added to section 1.1? Thanks! Ben (who has no unexpired hats relevant to this conversation). --Apple-Mail=_F02A078A-34C5-43A8-A3AD-17DEB40D4A34 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlztTdQACgkQgFZKbJXz 1A1BnQ/+KdYjtKNcpo3NI6kI/4GP8vOjG7zk8Gq3PeFKDLNhtvteT5184/MZi11X JxmE6H2moZw3/TEibmSHw+N/nWLJIKCJfFstA0H8ubjo/eANpw3xAt/h7RpR7fzF A24RllUeTwIAeQbGXQPT+fVuIvoWUgO6UPSQFWSXyvZdKGfzXE6rk8TwU0avR/aB F8X1/U0tQFG3ZN03Frqsau2flBHAkdrkY5KXARHXVMOaeHUwik6lxyO9ez1d7uQ5 z0aoCD4SKwnUlmhQrOSOFk3QQ0yI9oLDPVWcquAFR2yv7sDC4Lvs9AkyMyeHyGBT iFDuOlNeWqG2XKqJ+q9VBkhvEWe66ThLdGbThRulc9/AaQOeW5pqgTNJ0pATLWRT mfbSht+/Za9VNLH8tE9+81eYrNqQC6TVV/+2N2fJtv1h2fcINBbq5IfuDObxD86V IJx/4vDHqdeQuiI5aW7Gj7KuAxtoO/nyTjKduA8QnAhX0uQzRyIDjm/G2v6Onqz3 nz8z/01lbBLs1Bf+r0ZT3FxZhmZ+hETFFYHLhvdY65ukuGjH+tojpl+SsZoL9eZ/ u1WhAo3p68ySa0s/L9Unxs5KMsQUZDz344rNQJjBgFnD9RsJHmcVzwQg1iK7ni4j pRl1/oEK2BRSNFxywiVWOwkoF30+ocERddMvJ7zHdV1NiKF36Ck= =LQWY -----END PGP SIGNATURE----- --Apple-Mail=_F02A078A-34C5-43A8-A3AD-17DEB40D4A34-- From nobody Tue May 28 12:15:40 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D971200B4; Tue, 28 May 2019 12:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 TJAXQR7M7kCi; Tue, 28 May 2019 12:15:29 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 52521120041; Tue, 28 May 2019 12:15:29 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4SJFOMm021832; Tue, 28 May 2019 15:15:25 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x4SJFOMm021832 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559070925; bh=xbkT7EmHnkPys1QlKjik+NMUyxrLr6LOMW64oK7u3lQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MV7LqWuLFSNgcjyD5+EQ+21yMr0JV5atjFWgupvBSmh8PLd3QinxWjMaqEZD1Hj2e Zxp9sS8h8xuJod2OObEcVXGNpbEVZas8j/0bkEdBhBpAW87iR4VtVDd52WtfiMzUW2 WcfSnnGtI7HpvnT+p6OCsC1Zz2T0LkRXlgcYYXQ0= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4SJFNk8048384; Tue, 28 May 2019 15:15:23 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Tue, 28 May 2019 15:15:23 -0400 From: Roman Danyliw To: Ben Campbell , Barry Leiba CC: "draft-ietf-sipbrandy-osrtp@ietf.org" , "sipbrandy@ietf.org" , "sipbrandy-chairs@ietf.org" , The IESG , Gonzalo Camarillo Thread-Topic: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) Thread-Index: AQHVFTs5gBVapXo2mUObzGrF9bezW6aA5bIA///Uo+A= Date: Tue, 28 May 2019 19:15:22 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon> References: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 19:15:31 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVzZyBbbWFpbHRvOmll c2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBDYW1wYmVsbA0KPiBTZW50OiBU dWVzZGF5LCBNYXkgMjgsIDIwMTkgMTE6MDQgQU0NCj4gVG86IEJhcnJ5IExlaWJhIDxiYXJyeWxl aWJhQGNvbXB1dGVyLm9yZz4NCj4gQ2M6IGRyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwQGlldGYu b3JnOyBzaXBicmFuZHlAaWV0Zi5vcmc7IHNpcGJyYW5keS0NCj4gY2hhaXJzQGlldGYub3JnOyBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IEdvbnphbG8gQ2FtYXJpbGxvDQo+IDxnb256YWxvLmNh bWFyaWxsb0Blcmljc3Nvbi5jb20+DQo+IFN1YmplY3Q6IFJlOiBbU2lwYnJhbmR5XSBCYXJyeSBM ZWliYSdzIFllcyBvbiBkcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0wOToNCj4gKHdpdGggQ09N TUVOVCkNCj4gDQo+IA0KPiANCj4gPiBPbiBNYXkgMjgsIDIwMTksIGF0IDQ6NTMgQU0sIEJhcnJ5 IExlaWJhIHZpYSBEYXRhdHJhY2tlcg0KPiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+ID4N Cj4gPg0KPiANCj4gDQo+IFvigKZdDQo+IA0KPiA+DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IENP TU1FTlQ6DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ID4gSSBzaGFyZSB0aGUgcXVlc3Rpb24g b2Ygd2h5IHRoaXMgaXMgSW5mb3JtYXRpb25hbCBhbmQgd2h5IHRoZSBzaGVwaGVyZA0KPiA+IHdy aXRldXAgZG9lc24ndCBleHBsYWluICh0aGUgd3JpdGV1cCBzYXlzIGxpdHRsZSBtb3JlIHRoYW4g InllcyIgYW5kICJubyIpLg0KPiA+DQo+IA0KPiBUaGlzIHdhcyBkaXNjdXNzZWQgcXVpdGUgYSBi aXQgaW4gdGhlIFdHIGFuZCBwcmlvciB0byBjaGFydGVyaW5nLiBUaGUNCj4gcmVhc29uaW5nIGZv ciDigJxpbmZvcm1hdGlvbmFs4oCdIHdhcyB0d28tZm9sZDoNCj4gDQo+IDEpIFRoZSBkcmFmdCBk b2VzIG5vdCAob3Igd2FzIG5vdCBzdXBwb3NlZCB0bykgZGVmaW5lIG5ldyBvciBtb2RpZnkgZXhp c3RpbmcNCj4gcHJvdG9jb2xzLiBJdCB0YWxrcyBhYm91dCBob3cgb25lIGNhbiBhc3NlbWJsZSBl eGlzdGluZyBidWlsZGluZyBibG9ja3MgdG8NCj4gbWFrZSB0aGUgcmlnaHQgdGhpbmdzIGhhcHBl biwgbm90IGhvdyB0byBidWlsZCBuZXcgYmxvY2tzLiBTbyBpdCBzZWVtZWQgbGlrZQ0KPiB0aGUg bW9zdCBhcHByb3ByaWF0ZSBzdGF0dXMgd2FzIGVpdGhlciDigJxpbmZvcm1hdGlvbmFs4oCdIG9y IOKAnEJDUCINCj4gDQo+IDIpIFR3byBvZiB0aG9zZSDigJxleGlzdGluZyBwcm90b2NvbHPigJ0s IG5hbWVseSBaUlRQIFtSRkM2MTg5XSBhbmQgU0RQDQo+IFNlY3VyaXR5IERlc2NyaXB0aW9ucyBb UkZDNDU2OF0gYXJlIG5vdCBwYXJ0aWN1bGFybHkgd2VsbCByZWdhcmRlZCBhbW9uZw0KPiBzb21l IG9mIG91ciBzZWN1cml0eSBleHBlcnRzLCB3aG8gaW5kaWNhdGVkIG9iamVjdGlvbnMgdG8gdXNp bmcgdGhlbSBpbiBhDQo+IG5ldyBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgb3IgQkNQLg0KDQpX YXMgdGhlcmUgYSByZWFzb24gdGhlIFdHIGRpZG4ndCBpbmNsdWRlIHRoZXNlIHJlZmVyZW5jZXMv Y2F2ZWF0cyB0byB0aGUgWlJUUCBhbmQgU1NEUCBTRCBnaXZlbiBhbiBpbXByb3ZlZCB1bmRlcnN0 YW5kaW5nIG9mIHRoZWlyIHNlY3VyaXR5IHByb3BlcnRpZXMgc2luY2UgdGhleSB3ZXJlIHB1Ymxp c2hlZD8NCg0KUm9tYW4NCg0KPiBGcm9tIGEgc3RyaWN0bHkgaGlzdG9yaWNhbCBwZXJzcGVjdGl2 ZSwgdGhlIFdHIG9yaWdpbmFsbHkgdGhvdWdodCBpdCBuZWVkZWQgdG8NCj4gbWFrZSBhIG5vcm1h dGl2ZSB1cGRhdGUgdG8gUkZDNTEyNC4gVGhpcyB3YXMgdG8gYmUgZG9uZSBpcyBhIHNlcGFyYXRl DQo+IHRpZ2h0bHktc2NvcGVkIGRyYWZ0IHRvIHByb2dyZXNzIGluIE1NVVNJQywgc2luY2UgU0lQ QlJBTkRZIHdhcyBub3QNCj4gY2hhcnRlcmVkIHRvIG1ha2Ugbm9ybWF0aXZlIGNoYW5nZXMgdG8g YW55dGhpbmcuIEhvd2V2ZXIsIGxhdGVyIGRpc2N1c3Npb24NCj4gc3VnZ2VzdGVkIHN1Y2ggYSBj aGFuZ2Ugd2FzIG5vdCBuZWNlc3NhcnksIGFuZCB0aGUgc2VwYXJhdGUgZHJhZnQgd2FzDQo+IGFi YW5kb25lZC4NCj4gDQo+IEkgYWdyZWUgdGhhdCB0aGUgc2hlcGhlcmQgcmVwb3J0IG9yIChteSBw cmVmZXJlbmNlKSB0aGUgZHJhZnQgaXRzZWxmIHNob3VsZA0KPiBtYWtlIHRoaXMgbW9yZSBjbGVh ci4gUGVyaGFwcyBzb21lIHdvcmRzIGNvdWxkIGJlIGFkZGVkIHRvIHNlY3Rpb24gMS4xPw0KPiAN Cj4gVGhhbmtzIQ0KPiANCj4gQmVuICh3aG8gaGFzIG5vIHVuZXhwaXJlZCBoYXRzIHJlbGV2YW50 IHRvIHRoaXMgY29udmVyc2F0aW9uKS4NCg== From nobody Tue May 28 12:22:37 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079C2120090 for ; Tue, 28 May 2019 12:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com 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 U1edT_rUr4xF for ; Tue, 28 May 2019 12:22:33 -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 B6F1E120004 for ; Tue, 28 May 2019 12:22:33 -0700 (PDT) Received: from [IPv6:2607:fb90:44e8:816b:b53e:2a97:874b:3c9] ([172.58.105.25]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x4SJMUus085664 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 28 May 2019 14:22:32 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1559071353; bh=ANHw/RTzjyiipl9qLU3zfY2Uv1obhMzExbS2LqedBDk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Q3utyI3uIQ1+Rqu4zCFRgystofjnQ8/kU0jF3mGX6vRkFYHZxUoykcN7oGs8/8p+v S1vvcCLtoSJV1zNs2FDav5qGDAlOHS6qxWBHlShvGZaVFpsYdbuBY+mZUATvjR6Hmu wI9xd++t9q5wThNDBidZSFaeZXYaNDmu+LPPGsGc= X-Authentication-Warning: raven.nostrum.com: Host [172.58.105.25] claimed to be [IPv6:2607:fb90:44e8:816b:b53e:2a97:874b:3c9] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Adam Roach X-Mailer: iPhone Mail (16E227) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon> Date: Tue, 28 May 2019 14:22:24 -0500 Cc: Ben Campbell , Barry Leiba , "draft-ietf-sipbrandy-osrtp@ietf.org" , "sipbrandy@ietf.org" , "sipbrandy-chairs@ietf.org" , The IESG , Gonzalo Camarillo Content-Transfer-Encoding: quoted-printable Message-Id: <87605986-BBD8-46B6-9E4D-E24CB823DBEF@nostrum.com> References: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon> To: Roman Danyliw Archived-At: Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 19:22:35 -0000 The esteem in which ZRTP is currently held is approximately the same esteem i= n which it was held when it was initially published. /a > On May 28, 2019, at 14:15, Roman Danyliw wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Tuesday, May 28, 2019 11:04 AM >> To: Barry Leiba >> Cc: draft-ietf-sipbrandy-osrtp@ietf.org; sipbrandy@ietf.org; sipbrandy- >> chairs@ietf.org; The IESG ; Gonzalo Camarillo >> >> Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-= 09: >> (with COMMENT) >>=20 >>=20 >>=20 >>> On May 28, 2019, at 4:53 AM, Barry Leiba via Datatracker >> wrote: >>>=20 >>>=20 >>=20 >>=20 >> [=E2=80=A6] >>=20 >>>=20 >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>>=20 >>> I share the question of why this is Informational and why the shepherd >>> writeup doesn't explain (the writeup says little more than "yes" and "no= "). >>>=20 >>=20 >> This was discussed quite a bit in the WG and prior to chartering. The >> reasoning for =E2=80=9Cinformational=E2=80=9D was two-fold: >>=20 >> 1) The draft does not (or was not supposed to) define new or modify exist= ing >> protocols. It talks about how one can assemble existing building blocks t= o >> make the right things happen, not how to build new blocks. So it seemed l= ike >> the most appropriate status was either =E2=80=9Cinformational=E2=80=9D or= =E2=80=9CBCP" >>=20 >> 2) Two of those =E2=80=9Cexisting protocols=E2=80=9D, namely ZRTP [RFC618= 9] and SDP >> Security Descriptions [RFC4568] are not particularly well regarded among >> some of our security experts, who indicated objections to using them in a= >> new standards track document or BCP. >=20 > Was there a reason the WG didn't include these references/caveats to the Z= RTP and SSDP SD given an improved understanding of their security properties= since they were published? >=20 > Roman >=20 >> =46rom a strictly historical perspective, the WG originally thought it ne= eded to >> make a normative update to RFC5124. This was to be done is a separate >> tightly-scoped draft to progress in MMUSIC, since SIPBRANDY was not >> chartered to make normative changes to anything. However, later discussio= n >> suggested such a change was not necessary, and the separate draft was >> abandoned. >>=20 >> I agree that the shepherd report or (my preference) the draft itself shou= ld >> make this more clear. Perhaps some words could be added to section 1.1? >>=20 >> Thanks! >>=20 >> Ben (who has no unexpired hats relevant to this conversation). From nobody Wed May 29 08:53:36 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819BF120148; Wed, 29 May 2019 08:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8cghSSHRtftK; Wed, 29 May 2019 08:53:22 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 10090120162; Wed, 29 May 2019 08:53:21 -0700 (PDT) Received: from prolepsis.kaduk.org (c-24-16-119-19.hsd1.wa.comcast.net [24.16.119.19]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x4TFrGjE017484 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 May 2019 11:53:19 -0400 Date: Wed, 29 May 2019 08:53:16 -0700 From: Benjamin Kaduk To: Sean Turner Cc: secdir@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Message-ID: <20190529155316.GC1875@prolepsis.kaduk.org> References: <155900970362.650.8194184838834826261@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155900970362.650.8194184838834826261@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Sipbrandy] [secdir] Secdir last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 15:53:23 -0000 On Mon, May 27, 2019 at 07:15:03PM -0700, Sean Turner via Datatracker wrote: > Reviewer: Sean Turner > Review result: Has Issues > > I had a read of the draft as well as the GENART and TSVART reviews (to avoid > duplicating comments). > > Summary: Ready with (minor) issues > > Issues: > > 0) I assume that the mismatch the TSVART refers to in the security > considerations has to do with 1) changing 4568 to require encryption but not > fail if authentication is not available, 2) pointing out that 4568's > requirement is routinely ignore for end-to-end encryption because using TLS > with intermediaries won't protect the SDP key, and 3) and reference errors (see > the next issue). On 1, that's kind the point of OSRTP - take the encryption > you can get. On 2, because it's the security considerations this document is > just saying don't expect to get end-to-end. Assuming, I've interpreted this I > think this draft is okay. Thanks for doing the cross-reference to the other reviews and thinking about the raised issues. > 1) I think these are just reference errors, but it would be good to double > check these (and I hadn't seen a response yet - might have missed it): > > S4: Not sure about these references too RFC7435. Maybe they should be to RFC > 4568 instead? > > s/The security considerations of [RFC7435] apply to OSRTP, > /The security considerations of [RFC4568] apply to OSRTP, > > s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568] > > s/understood that the [RFC7435]/understood that the [RFC4568] > > Bikesheds: > > 0) The fact that it's Informational struck me as odd. > > 1) The fact there are no updates listed also strikes me as odd. > > Nits: > > 0) s2: Nits reports an error with the para. I think it's: > > s/RFC 2119 [RFC2119] RFC 8174 [RFC8174] > /RFC 2119 [RFC2119] [RFC8174] The snippet in RFC 8174 has "BCP 14 [RFC2119] [RFC8174]" in this role. -Ben > > 1) s1, 2nd para: s/[RFC5939] ./[RFC5939]. From nobody Wed May 29 11:46:14 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A683120048; Wed, 29 May 2019 11:46:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-sipbrandy-osrtp@ietf.org, Gonzalo Camarillo , sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155915556449.5543.7586926853633549137.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 11:46:04 -0700 Archived-At: Subject: [Sipbrandy] Alissa Cooper's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 18:46:05 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-sipbrandy-osrtp-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. In Section 3, please add a reference for SDP (presumably draft-ietf-mmusic-rfc4566bis). From nobody Wed May 29 11:47:37 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37404120096; Wed, 29 May 2019 11:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=QxuhFkUm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rUBPIKk5 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 VXO4g9BPYk3K; Wed, 29 May 2019 11:47:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4753120048; Wed, 29 May 2019 11:47:29 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ED03421AD2; Wed, 29 May 2019 14:47:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 29 May 2019 14:47:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=s CCg/o2i9cYgan35dfmHntQk/zJhT+61FvkVan4FO6k=; b=QxuhFkUmAx0g14e9C zHEc8LZ2yxUvNz5bLCVb9POjZKt8tmMWlcb+1nbNlST+pl68E4Y+iKi4BMOv0ofj Il0S+VMJxHghJfVkOF5rp2AFmsh2bBFhtRqISAuSRoU1/T6Wggc+yXmHGgAT/APR CerEAbSBEhTSLA0Zl/7Uk6R2LLkubdeq6kA1YhHgbzwmQ0Ah8WHVzKNAickqeiP8 jg5O4Z97S/hhmGwxwOwdtubhKO/lE4oZbm+efW3q3g5wjgpZAyNW4S5w9hWt/RYw 7UNQOurRPDBPMm8X6iMfXn1bG7i2JiAEZEzIO34eCg6Asmpr/wAdKX5lEz5rUwcL 8YIgg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=sCCg/o2i9cYgan35dfmHntQk/zJhT+61FvkVan4FO 6k=; b=rUBPIKk5zypsmT+YiTiyuKFMNTeioWQrRi+aYcL+xljiynXjPHDdxrLOg UGqs/2olSGhv/lDBOSrrLCE4jkTqvIuyNMDZheYg41Ya577wlm2fjrzdrW8puVg2 KrKfIlUeeQUyqa+cdX2I/f5Ecft1ilPu/O0QbgNRbOe6Aeg5h4xbmKgLN1+8/BfK 9m2m+5dt55GsYQ1LgwmTJstmlOnRcm0L7VDIGIKxIz2vFAzlIaVX/bDrDjUoOJQW Fc/P70tr6yFpsx+SbjfyyiJLCQ70bjfVXlSV9mU2uuU6b8nZkRVbJfNyr/vv/N5a pURBEvxLCywTRK//ulslQhL6gC2LA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvjedgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrdekfeenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.83]) by mail.messagingengine.com (Postfix) with ESMTPA id 2CCA380059; Wed, 29 May 2019 14:47:26 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155804481707.19586.13843111552522558644@ietfa.amsl.com> Date: Wed, 29 May 2019 14:47:24 -0400 Cc: gen-art@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9E1DC17C-8674-4AA5-A10B-EC9907675061@cooperw.in> References: <155804481707.19586.13843111552522558644@ietfa.amsl.com> To: Elwyn Davies X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Sipbrandy] [Gen-art] Genart last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 18:47:35 -0000 Elwyn, thanks for your review. I entered a Yes ballot. One comment = below. > On May 16, 2019, at 6:13 PM, Elwyn Davies via Datatracker = wrote: >=20 > Reviewer: Elwyn Davies > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-sipbrandy-osrtp-09 > Reviewer: Elwyn Davies > Review Date: 2019-05-16 > IETF LC End Date: 2019-05-16 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready with nits. Thanks for an easy to read document. I am = not sure > about whether it is acceptable to point to an expired (and effectively = totally > dead) draft (draft-kaplan...) for signuficant motivation (see minor = issues).=20 > Please consult with higher authorities. >=20 > Major issues: > None >=20 > Minor issues: >=20 > S1, para 2: The discussion and motivation for the introduction of = OSRTP is at > least partially derived from the motivation explained in Section 1 of > draft-kaplan-mmusic-best-effort-srtp. This is a long expired draft = (2007) > which is not going to become an RFC. Given this, I wonder if the text = ought to > be reproduced here, perhaps as an appendix? I think the reference to the draft is ok. It=E2=80=99s a stable = reference. Alissa >=20 > Nits/Editorial comments: >=20 > Abstract: s./applied to Real-time/applied to the Real-time/ >=20 > Abstract: expand SDP on first use. >=20 > Abstract: expand SRTP on first use (Secure RTP). >=20 > S1: The sentences expanding the meaning of cleartext and secure media = could do > with a little expansion to make it clear that we are talking about = media > streams even if that is what RTP is supposed to be about. Suggest: >=20 > OLD: > In terms of secure media, cleartext is RTP [RFC3550] media which is = negotiated > with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF = profile > [RFC4585]. Comprehensive protection is Secure RTP [RFC3711], = negotiated with a > secure profile, such as SAVP or SAVPF [RFC5124]. NEW: In the context = of > transport of secure media streams using RTP and its secured = derivatives, > cleartext is represented by an RTP [RFC3550] media stream which is = negotiated > with the RTP/AVP (Audio Video Profile) [RFC3551] or the RTP/AVPF = profile > [RFC4585], whereas comprehensive protection is represented by a Secure = RTP > [RFC3711] stream, negotiated with a secure profile, such as SAVP or = SAVPF > [RFC5124]. ENDS >=20 > (I note that SAVP and SAVPF aren't acronyms and don't need expansion. = OTOH > AVPF probably does.) >=20 > S3: The terminology used in RFC 4566 and elsewhere seems to be m=3D = sections > rather than m- sections. Suggest s/m-/m=3D/g (4 places) >=20 > S3.4, last sentence: the backward reference to Section 3.1 is not in = RFC > format. s/section [3.1]/Section 3.1/ >=20 > S4, para 3: I think the 'must' here is normative. s/ an encrypted = signaling > channel must still be used./ an encrypted signaling channel MUST still = be used./ >=20 > S6: The note to the RFC Editor should also note that the = referenceventries > SIPCONNECT, RFC6982 and IMTC-SIP in s8 should also be removed. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed May 29 12:11:22 2019 Return-Path: X-Original-To: sipbrandy@ietfa.amsl.com Delivered-To: sipbrandy@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C7120114; Wed, 29 May 2019 12:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org 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 OS1gJ-wcl6Al; Wed, 29 May 2019 12:11:18 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 19BCA12014E; Wed, 29 May 2019 12:11:18 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4TJBD5t008024; Wed, 29 May 2019 15:11:14 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x4TJBD5t008024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1559157074; bh=g0BiV4B6MC1+HDgVX5QPiBI91CbnDAPyEM1+qGBC+sU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JXY1WHDJl/UOuxl5r1mHu9VXwZwPauCTI5ziJ2+quRmpx4mX1E+GFbpWM6st8BKS2 A0tIhnl8Q0vshMFwxJO8cF6QUZIuhwT6mCPCeKCAuwZkpAobytHzyIhZo0YW+W7Psv 2c8kFMjU3Kf99/O6pSQvp32jtQTmFpiMNJuk5Ri8= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4TJB9hl032592; Wed, 29 May 2019 15:11:09 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Wed, 29 May 2019 15:11:08 -0400 From: Roman Danyliw To: Adam Roach CC: Ben Campbell , Barry Leiba , "draft-ietf-sipbrandy-osrtp@ietf.org" , "sipbrandy@ietf.org" , "sipbrandy-chairs@ietf.org" , The IESG , Gonzalo Camarillo Thread-Topic: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) Thread-Index: AQHVFTs5gBVapXo2mUObzGrF9bezW6aA5bIA///Uo+CAAHOdAP//vT8Q Date: Wed, 29 May 2019 19:11:07 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B337C1C3@marathon> References: <155903721225.25618.16702710214584112001.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3379F4D@marathon> <87605986-BBD8-46B6-9E4D-E24CB823DBEF@nostrum.com> In-Reply-To: <87605986-BBD8-46B6-9E4D-E24CB823DBEF@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Sipbrandy] Barry Leiba's Yes on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 19:11:21 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWRhbSBSb2FjaCBbbWFp bHRvOmFkYW1Abm9zdHJ1bS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAyOCwgMjAxOSAzOjIy IFBNDQo+IFRvOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQo+IENjOiBCZW4gQ2FtcGJl bGwgPGJlbkBub3N0cnVtLmNvbT47IEJhcnJ5IExlaWJhDQo+IDxiYXJyeWxlaWJhQGNvbXB1dGVy Lm9yZz47IGRyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwQGlldGYub3JnOw0KPiBzaXBicmFuZHlA aWV0Zi5vcmc7IHNpcGJyYW5keS1jaGFpcnNAaWV0Zi5vcmc7IFRoZSBJRVNHIDxpZXNnQGlldGYu b3JnPjsNCj4gR29uemFsbyBDYW1hcmlsbG8gPGdvbnphbG8uY2FtYXJpbGxvQGVyaWNzc29uLmNv bT4NCj4gU3ViamVjdDogUmU6IFtTaXBicmFuZHldIEJhcnJ5IExlaWJhJ3MgWWVzIG9uIGRyYWZ0 LWlldGYtc2lwYnJhbmR5LW9zcnRwLTA5Og0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4gVGhlIGVz dGVlbSBpbiB3aGljaCBaUlRQIGlzIGN1cnJlbnRseSBoZWxkIGlzIGFwcHJveGltYXRlbHkgdGhl IHNhbWUNCj4gZXN0ZWVtIGluIHdoaWNoIGl0IHdhcyBoZWxkIHdoZW4gaXQgd2FzIGluaXRpYWxs eSBwdWJsaXNoZWQuDQoNCk9uIG15IHJlYWRpbmcgbGlzdCBhcmUgdGhlIGZvbGxvd2luZyBhY2Fk ZW1pYyBwdWJzIHdobydzIGFic3RyYWN0IHN1Z2dlc3QgbmV3IGluc2lnaHQgaW50byBaUlRQJ3Mg c2VjdXJpdHkgcHJvcGVydGllcyAuLi4NCg0KQmhhcmdhdmFuLCBLLiwgZXQgYWwuICBEb3duZ3Jh ZGUgUmVzaWxpZW5jZSBpbiBLZXkgRXhjaGFuZ2UgUHJvdG9jb2xzLiAgMjAxNiBJRUVFIFN5bXBv c2l1bSBvbiBTZWN1cml0eSBhbmQgUHJpdmFjeS4NCmh0dHBzOi8vaWVlZXhwbG9yZS5pZWVlLm9y Zy9zdGFtcC9zdGFtcC5qc3A/dHA9JmFybnVtYmVyPTc1NDY1MjAmdGFnPTENCg0KU2h1cm1hbm4s IEQuICBldCBhbC4gIFdpcmV0YXBwaW5nIEVuZC10by1FbmQgRW5jcnlwdGVkIFZvSVAgQ2FsbHM6 IFJlYWwtV29ybGQgQXR0YWNrcyBvbiBaUlRQLiAgUHJvY2VlZGluZ3Mgb24gUHJpdmFjeSBFbmhh bmNpbmcgVGVjaG5vbG9naWVzLCAyMDE3ICgzKToxLTE3Lg0KaHR0cHM6Ly9wZXRzeW1wb3NpdW0u b3JnLzIwMTcvcGFwZXJzL2lzc3VlMy9wYXBlcjAxLTIwMTctMy1zb3VyY2UucGRmDQoNClJvbWFu DQogDQoNCj4gL2ENCj4gDQo+ID4gT24gTWF5IDI4LCAyMDE5LCBhdCAxNDoxNSwgUm9tYW4gRGFu eWxpdyA8cmRkQGNlcnQub3JnPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogaWVzZyBbbWFpbHRvOmllc2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBDYW1wYmVsbA0KPiA+PiBTZW50OiBUdWVzZGF5LCBN YXkgMjgsIDIwMTkgMTE6MDQgQU0NCj4gPj4gVG86IEJhcnJ5IExlaWJhIDxiYXJyeWxlaWJhQGNv bXB1dGVyLm9yZz4NCj4gPj4gQ2M6IGRyYWZ0LWlldGYtc2lwYnJhbmR5LW9zcnRwQGlldGYub3Jn OyBzaXBicmFuZHlAaWV0Zi5vcmc7DQo+ID4+IHNpcGJyYW5keS0gY2hhaXJzQGlldGYub3JnOyBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IEdvbnphbG8NCj4gPj4gQ2FtYXJpbGxvIDxnb256YWxv LmNhbWFyaWxsb0Blcmljc3Nvbi5jb20+DQo+ID4+IFN1YmplY3Q6IFJlOiBbU2lwYnJhbmR5XSBC YXJyeSBMZWliYSdzIFllcyBvbiBkcmFmdC1pZXRmLXNpcGJyYW5keS1vc3J0cC0NCj4gMDk6DQo+ ID4+ICh3aXRoIENPTU1FTlQpDQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+PiBPbiBNYXkgMjgsIDIw MTksIGF0IDQ6NTMgQU0sIEJhcnJ5IExlaWJhIHZpYSBEYXRhdHJhY2tlcg0KPiA+PiA8bm9yZXBs eUBpZXRmLm9yZz4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4NCj4gPj4NCj4gPj4gW+KApl0N Cj4gPj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4gPj4+IENPTU1FTlQ6 DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4gPj4+DQo+ID4+PiBJIHNoYXJlIHRoZSBx dWVzdGlvbiBvZiB3aHkgdGhpcyBpcyBJbmZvcm1hdGlvbmFsIGFuZCB3aHkgdGhlDQo+ID4+PiBz aGVwaGVyZCB3cml0ZXVwIGRvZXNuJ3QgZXhwbGFpbiAodGhlIHdyaXRldXAgc2F5cyBsaXR0bGUg bW9yZSB0aGFuDQo+ICJ5ZXMiIGFuZCAibm8iKS4NCj4gPj4+DQo+ID4+DQo+ID4+IFRoaXMgd2Fz IGRpc2N1c3NlZCBxdWl0ZSBhIGJpdCBpbiB0aGUgV0cgYW5kIHByaW9yIHRvIGNoYXJ0ZXJpbmcu IFRoZQ0KPiA+PiByZWFzb25pbmcgZm9yIOKAnGluZm9ybWF0aW9uYWzigJ0gd2FzIHR3by1mb2xk Og0KPiA+Pg0KPiA+PiAxKSBUaGUgZHJhZnQgZG9lcyBub3QgKG9yIHdhcyBub3Qgc3VwcG9zZWQg dG8pIGRlZmluZSBuZXcgb3IgbW9kaWZ5DQo+ID4+IGV4aXN0aW5nIHByb3RvY29scy4gSXQgdGFs a3MgYWJvdXQgaG93IG9uZSBjYW4gYXNzZW1ibGUgZXhpc3RpbmcNCj4gPj4gYnVpbGRpbmcgYmxv Y2tzIHRvIG1ha2UgdGhlIHJpZ2h0IHRoaW5ncyBoYXBwZW4sIG5vdCBob3cgdG8gYnVpbGQgbmV3 DQo+ID4+IGJsb2Nrcy4gU28gaXQgc2VlbWVkIGxpa2UgdGhlIG1vc3QgYXBwcm9wcmlhdGUgc3Rh dHVzIHdhcyBlaXRoZXINCj4g4oCcaW5mb3JtYXRpb25hbOKAnSBvciDigJxCQ1AiDQo+ID4+DQo+ ID4+IDIpIFR3byBvZiB0aG9zZSDigJxleGlzdGluZyBwcm90b2NvbHPigJ0sIG5hbWVseSBaUlRQ IFtSRkM2MTg5XSBhbmQgU0RQDQo+ID4+IFNlY3VyaXR5IERlc2NyaXB0aW9ucyBbUkZDNDU2OF0g YXJlIG5vdCBwYXJ0aWN1bGFybHkgd2VsbCByZWdhcmRlZA0KPiA+PiBhbW9uZyBzb21lIG9mIG91 ciBzZWN1cml0eSBleHBlcnRzLCB3aG8gaW5kaWNhdGVkIG9iamVjdGlvbnMgdG8gdXNpbmcNCj4g Pj4gdGhlbSBpbiBhIG5ldyBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQgb3IgQkNQLg0KPiA+DQo+ ID4gV2FzIHRoZXJlIGEgcmVhc29uIHRoZSBXRyBkaWRuJ3QgaW5jbHVkZSB0aGVzZSByZWZlcmVu Y2VzL2NhdmVhdHMgdG8gdGhlDQo+IFpSVFAgYW5kIFNTRFAgU0QgZ2l2ZW4gYW4gaW1wcm92ZWQg dW5kZXJzdGFuZGluZyBvZiB0aGVpciBzZWN1cml0eQ0KPiBwcm9wZXJ0aWVzIHNpbmNlIHRoZXkg d2VyZSBwdWJsaXNoZWQ/DQo+ID4NCj4gPiBSb21hbg0KPiA+DQo+ID4+IEZyb20gYSBzdHJpY3Rs eSBoaXN0b3JpY2FsIHBlcnNwZWN0aXZlLCB0aGUgV0cgb3JpZ2luYWxseSB0aG91Z2h0IGl0DQo+ ID4+IG5lZWRlZCB0byBtYWtlIGEgbm9ybWF0aXZlIHVwZGF0ZSB0byBSRkM1MTI0LiBUaGlzIHdh cyB0byBiZSBkb25lIGlzDQo+ID4+IGEgc2VwYXJhdGUgdGlnaHRseS1zY29wZWQgZHJhZnQgdG8g cHJvZ3Jlc3MgaW4gTU1VU0lDLCBzaW5jZQ0KPiA+PiBTSVBCUkFORFkgd2FzIG5vdCBjaGFydGVy ZWQgdG8gbWFrZSBub3JtYXRpdmUgY2hhbmdlcyB0byBhbnl0aGluZy4NCj4gPj4gSG93ZXZlciwg bGF0ZXIgZGlzY3Vzc2lvbiBzdWdnZXN0ZWQgc3VjaCBhIGNoYW5nZSB3YXMgbm90IG5lY2Vzc2Fy eSwNCj4gPj4gYW5kIHRoZSBzZXBhcmF0ZSBkcmFmdCB3YXMgYWJhbmRvbmVkLg0KPiA+Pg0KPiA+ PiBJIGFncmVlIHRoYXQgdGhlIHNoZXBoZXJkIHJlcG9ydCBvciAobXkgcHJlZmVyZW5jZSkgdGhl IGRyYWZ0IGl0c2VsZg0KPiA+PiBzaG91bGQgbWFrZSB0aGlzIG1vcmUgY2xlYXIuIFBlcmhhcHMg c29tZSB3b3JkcyBjb3VsZCBiZSBhZGRlZCB0bw0KPiBzZWN0aW9uIDEuMT8NCj4gPj4NCj4gPj4g VGhhbmtzIQ0KPiA+Pg0KPiA+PiBCZW4gKHdobyBoYXMgbm8gdW5leHBpcmVkIGhhdHMgcmVsZXZh bnQgdG8gdGhpcyBjb252ZXJzYXRpb24pLg0KDQo= From nobody Wed May 29 14:23:18 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E791201D1; Wed, 29 May 2019 14:23:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sipbrandy-osrtp@ietf.org, Gonzalo Camarillo , sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155916498999.5364.15981943360298533577.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 14:23:09 -0700 Archived-At: Subject: [Sipbrandy] Benjamin Kaduk's No Objection on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 21:23:10 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipbrandy-osrtp-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If ZRTP is already an OS method, and there are no changes to the ZRTP usage or security considerations as part of OSRTP, why do we need to cover ZRTP in this document at all (other than a pointer to "this other OS mechanism exists")? I could also see someone subscribing to an "attractive nuisance" theory that obliges us to put a stronger disclaimer against secdes and/or ZRTP usage, since we mention them in this document. Perhaps something about how they are generally considered to not be reasonable solutions for "comprehensive protection" solutions but can still be useful in OS environments? Abstract Opportunistic Secure Real-time Transport Protocol (OSRTP) is an implementation of the Opportunistic Security mechanism, as defined in nit: maybe s/implementation/application/? Section 1 OSRTP allows SRTP to be negotiated with the RTP/AVP profile, with fallback to RTP if SRTP is not supported. nit: Given the preceding context, I don't see a way to read this other than OSRTP using RTP/AVP and disallowing RTP/AVPF. I don't know whether an "RFP/AVP(F)" notation is at all conventional (we do "(D)TLS" and "(EC)DHE" a lot in the security area) or they would need to both be written out. I agree with the directorate reviewer that inlining a substantial portion of the "motivation and requirements for opportunistic secure media" from draft-kaplan-mmusic-best-effort-srtp into this document would be appropriate (while still acknowledging the prior effort). OSRTP requires no additional extensions to SDP or new attributes and is defined independently of the key agreement mechanism used. [...] The "defined independently" part seems to only mostly be true; see, e.g., the security considerations where we override the need for authenticated signaling for DTLS-SRTP OSRTP. Section 2 Please use the boilerplate from RFC 8174 (in particular, just the "BCP 14 [RFC2119] [RFC8174]" label+references is fine). Section 3 nit: I think most recent documents going by use "m=" rather than "m-". It is important to note that OSRTP makes no changes, and has no effect on media sessions in which the offer contains a secure profile nit: comma after "no effect on" -- the current text is saying that OSRTP makes no changes at all, globally, without scoping to media sessions in which the offer contains a secure profile (which I presume to be the intent). I think we also need to add "to" in "makes no changes to". Section 4 While OSRTP does not require authentication of the key-agreement mechanism, it does need to avoid exposing SRTP keys to eavesdroppers, since this could enable passive attacks against SRTP. Section 8.3 of [RFC7435] requires that any messages that contain SRTP keys be As already noted, this is probably supposed to be an RFC 4568 reference. Yet that is specific to secdes and not a generic SRTP consideration. encrypted, and further says that encryption "SHOULD" provide end-to- end confidentiality protection if intermediaries that could inspect the SDP message are present. At the time of this writing, it is understood that the [RFC7435] requirement for end-to-end confidentiality protection is commonly ignored. Therefore, if OSRTP As noted, this is not an RFC 7435 requirement, and 4568 seems to be the most likely interpretation. FWIW, my reading of 4568 is that it requires end-to-end authentication as well as confidentiality. (And yes, we attempt to relax that above.) Finally, the tsvart reviewer's concerns might be alleviated if we say "end-to-end (as opposed to just hop-by-hop) confidentiality protection". Also, it might be nice to give some reference for the "commonly ignored" statement, if such is readily available. is used with SDP Security Descriptions, any such intermediaries (e.g., SIP proxies) must be assumed to have access to the SRTP keys. Given that all of this paragraph (except potentially the first sentence) seems to be secdes-specific, I'd suggest breaking it out into a new paragraph and explicitly scoping to RFC 4568, and possibly even using a subsection to indicate the scope. Also, we should probably have another sentence or two to mention what the potential consequences of intermediate access to keys are. As discussed in [RFC7435], OSRTP is used in cases where support for encryption by the other party is not known in advance, and not required. [...] nit: 7435 does not discuss OS*RTP*'s use at all. So some rewording seems in order, like, "As discussed in [RFC7435], opportunistic security in general, and thus OSRTP specifically, is used" or "Per the discussion in [RFC7435], OSRTP is used", etc. Section 6 There are implementations of [I-D.kaplan-mmusic-best-effort-srtp] in deployed products by Microsoft and Unify. The IMTC "Best Practices for SIP Security" document [IMTC-SIP] recommends this approach. The SIP Forum planned to include support in the SIPconnect 2.0 SIP trunking recommendation [SIPCONNECT]. There are many deployments of ZRTP [RFC6189]. nit: I know this is to be removed before publication, but "recommends this approach" is a bit ambiguous about whether the kaplan approach or this document is being recommended. From nobody Wed May 29 19:11:55 2019 Return-Path: X-Original-To: sipbrandy@ietf.org Delivered-To: sipbrandy@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A94120148; Wed, 29 May 2019 19:11:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-sipbrandy-osrtp@ietf.org, Gonzalo Camarillo , sipbrandy-chairs@ietf.org, gonzalo.camarillo@ericsson.com, sipbrandy@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <155918230667.684.16793002550036245477.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 19:11:46 -0700 Archived-At: Subject: [Sipbrandy] Roman Danyliw's No Objection on draft-ietf-sipbrandy-osrtp-09: (with COMMENT) X-BeenThere: sipbrandy@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIPBRANDY working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 02:11:47 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-sipbrandy-osrtp-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipbrandy-osrtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Section 1.1. Per “It is only to be used in existing deployments which are attempting to transition to fully secure communications. New applications and new deployments will not use OSRTP.”, I was expecting RFC2119 words for the second sentence on the order of “New application … should not …”. (2) Section 3.1. Is there any value in creating a registry to manage the possible “a=xxx” offer types? (3) Editorial Nits: Section 1.0. Extra space. s/[RFC5939] ./[RFC5939]./ Section 1.0. Expand OSRTP acronym on first use. (done in title and abstract but not in text) Section 3. Typo. s/oportunistic/opportunistic/