From nobody Mon Jan 11 03:29:41 2016 Return-Path: X-Original-To: straw@ietf.org Delivered-To: straw@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B24021B2C70; Tue, 5 Jan 2016 00:39:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160105083931.28028.33540.idtracker@ietfa.amsl.com> Date: Tue, 05 Jan 2016 00:39:31 -0800 Archived-At: X-Mailman-Approved-At: Mon, 11 Jan 2016 03:29:36 -0800 Cc: ben@nostrum.com, victor.pascual.avila@gmail.com, straw-chairs@ietf.org, straw@ietf.org Subject: [straw] straw - Not having a session at IETF 95 X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2016 08:39:31 -0000 Victor Pascual, a chair of the straw working group, indicated that the straw working group does not plan to hold a session at IETF 95. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Jan 14 14:43:47 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CA01A0158; Thu, 14 Jan 2016 14:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=unavailable 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 hG8r0YPhR_I5; Thu, 14 Jan 2016 14:43:44 -0800 (PST) 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 B6EBA1A015F; Thu, 14 Jan 2016 14:43:44 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u0EMhVNO068765 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 14 Jan 2016 16:43:32 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" Date: Thu, 14 Jan 2016 16:43:32 -0600 Message-ID: In-Reply-To: <01E4CF3B-6C31-4A97-8155-8DC06443A7C2@nostrum.com> References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <1D498CDA-C8B6-4215-A718-7C5302B5CF2D@cooperw.in> <01E4CF3B-6C31-4A97-8155-8DC06443A7C2@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: Ram Mohan R , Alissa Cooper , "straw-chairs@ietf.org" , "straw@ietf.org" , IESG , "christer.holmberg@ericsson.com" Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jan 2016 22:43:46 -0000 Hi, What's the status on an update? Thanks! Ben. On 9 Dec 2015, at 14:25, Ben Campbell wrote: > I had an offline discussion with Alissa and Barry yesterday. I think > we have a proposed way forward to deal with the "big-picture" issues > from Alissa's discuss. This does not necessarily cover every detail of > her (or Stephen's) discuss and comments, but I think we need to deal > with the existential stuff first. > > The draft needs clarifications to the problem statement, the draft > goals and scope, and a clearer separation between normative statements > and non-normative considerations. > > I think that would be easiest with some reorganization. Here's a > proposed outline. (I don't think you need to stick to this outline in > detail, as long as the points are clear) > > Thanks! > > Ben. > ---------------- > > Problem: > > - B2BUAs (especially SBCs) often make e2e dtls-srtp impossible. There > are use cases where they could do their jobs and still allow e2e > dtls-srtp. > - The dtls-srtp dependency on RFC 4474 makes that hard in many cases. > - What do we mean by e2e DTLS-SRTP? (I _think_ we mean from the > perspective of the b2bua, where that b2bua is not a party to the > DTLS-SRTP SA, and doesn't have the session key or private keys for > DTLS cert(s). > > Goals and Scope: > > - Goal is to provide guidance on how b2buas that could possibly do > their jobs without breaking e2e dtls-srtp to do so. > - B2BUAs exist that will still not allow e2e dtls-srtp for various > reasons. These are out-of-scope, and the draft should not attempt to > make value judgements about them. > - Termination of dtls-srtp at the b2bua is out of scope by definition > (it's not e2e). > > Normative rules for B2BUAs to allow e2e DTLS-SRTP: > > - Consider both media signaling layers (including for non-media-path > b2buas) > - Discuss differences for 4474 and 4474bis, including how a b2bua > might tell them apart.(Hopefully 4474 will be obsolete soon, but we > should still discuss it, since it has significant impact on things > like media-latching since it signs the entire SDP payload.) > - Discuss differences if the b2bua acts as a 4474/4474bis > authenticator and/or verifier. > > Implications/considerations for each b2bua type (non-normative): > > - How do the normative requirements in the previous sections impact > the various b2bua types. > > Normal security and privacy considerations. > > > > On 9 Dec 2015, at 12:50, Alissa Cooper wrote: > >>> On Dec 3, 2015, at 1:12 PM, Ben Campbell wrote: >>> >>> On 2 Dec 2015, at 23:17, Alissa Cooper wrote: >>> >>>> Could you articulate the reasons why someone would build a B2BUA >>>> that >>>>>>> follows the recommendations in this draft? >>>> >>>> >>>>> >>>>> B2BUAs used in deployments like the above mentioned scenarios can >>>>> use the >>>>> recommendations in this draft. >>>> >>>> >>>> Ok. What I am still missing is why this draft needs to be published >>>> to make that happen. This is the type of SBC to which the Section >>>> 3.1.1 guidance is directed. How does the behavior of existing >>>> media-latching SBCs differ from what 3.1.1 tells them to do? And if >>>> this type of SBC implementation is the key target audience, >>>> doesn’t that make the 3.1.2 guidance essentially no-ops? >>> >>> Authors: >>> >>> After discussion on today's telechats, and some side discussions >>> with Alissa, I believe this question is the lynch-pin for making any >>> progress. I advise people to work this out first before worrying >>> about the rest of the discussion: Can we articulate how we expect >>> this draft will change implementer and/or operator behavior? >>> >>> Obviously B2BUAs that exist for reasons that require modification of >>> RTP/RTCP, or cleartext access to the encrypted bits of SRTP are not >>> going to conform, and are therefore out of scope. The draft doesn't >>> seem to concern itself with b2buas that are not in the media path at >>> all. (Maybe it should, since there are plenty of purely >>> signaling-plane ways to break dtls-srtp?). >>> >>> That leaves the question of b2buas in the media path that do not >>> require modification or cleartext access to protected bits in >>> srtp--effectively media-relays as described in 3.1.1 Do we believe >>> people do not know how to build or use such devices without breaking >>> dtls-srtp? Are people aware of such devices that break dtls-srtp >>> when they don't need to? Perhaps by misconfiguration, or because >>> they use SBCs designed for more invasive use cases? >> >> As Ben says, I think this draft would add value if it could >> articulate the problem statement, including the kinds of B2BUAs that >> cause the problem, and then articulate a solution that those kinds of >> B2BUAs have a reasonable chance of implementing given what they are >> otherwise designed to do. >> >> Alissa >> >>> >>> Thanks! >>> >>> Ben. > > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Sun Jan 17 19:45:06 2016 Return-Path: X-Original-To: straw@ietfa.amsl.com Delivered-To: straw@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CCE1ACEB1; Sun, 17 Jan 2016 19:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 3pYGlCRlBi8f; Sun, 17 Jan 2016 19:45:00 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39FD61ACEAE; Sun, 17 Jan 2016 19:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5955; q=dns/txt; s=iport; t=1453088700; x=1454298300; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Qg6PHP1BrJ9T8uYy/9eBgbtKa3EUgjL6+glpgKHE/34=; b=Zd7UmBXnDN9OF1hgC3CL1PSL7JLjGgn32tLZMrVgviGIRyPzVvkqR+ki qw4hnsliR2pcz0UO12tPsYe/k9EPfzVrFwJQHBdQeq1qF+QClKLN3aaRA kQsyQXzLMZ5ZlZrHqICu5tnqO2IwAcmg18EA6HjXVscIdnorZHDIE74T3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAgCCX5xW/5ldJa1egzpSbQaIULM1A?= =?us-ascii?q?Q2BYxgKhW0CgR84FAEBAQEBAQGBCoQ0AQEBBAEBAWsLDAQCAQgRAwECASMLJws?= =?us-ascii?q?dCAIEAQ0FG4gADr4AAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVoR+iT0Fh2aGF?= =?us-ascii?q?okeAY1egV6NI4VviG0BIAEBQoJLgUByhhcBgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.22,311,1449532800"; d="scan'208";a="228427173" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jan 2016 03:44:50 +0000 Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u0I3ioDs019232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 18 Jan 2016 03:44:50 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 17 Jan 2016 22:44:49 -0500 Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1104.009; Sun, 17 Jan 2016 22:44:49 -0500 From: "Ram Mohan R (rmohanr)" To: Ben Campbell , "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" Thread-Topic: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) Thread-Index: AQHRUaKU9xeq/Kd1tESzMQjhlgxJ3A== Date: Mon, 18 Jan 2016 03:44:49 +0000 Message-ID: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <1D498CDA-C8B6-4215-A718-7C5302B5CF2D@cooperw.in> <01E4CF3B-6C31-4A97-8155-8DC06443A7C2@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [173.39.64.59] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IESG , "christer.holmberg@ericsson.com" , Alissa Cooper , "straw-chairs@ietf.org" , "straw@ietf.org" Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) X-BeenThere: straw@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Sip Traversal Required for Applications to Work \(STRAW\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 03:45:02 -0000 Hi Ben, We will publish a new revision in the next couple of weeks. Regards, Ram -----Original Message----- From: Ben Campbell Date: Friday, 15 January 2016 at 4:13 AM To: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" Cc: Cisco Employee , Alissa Cooper , "straw-chairs@ietf.org" , "straw@ietf.org" , IESG , "christer.holmberg@ericsson.com" Subject: Re: [straw] Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) >Hi, > >What's the status on an update? > >Thanks! > >Ben. > > >On 9 Dec 2015, at 14:25, Ben Campbell wrote: > >> I had an offline discussion with Alissa and Barry yesterday. I think >> we have a proposed way forward to deal with the "big-picture" issues >> from Alissa's discuss. This does not necessarily cover every detail of >> her (or Stephen's) discuss and comments, but I think we need to deal >> with the existential stuff first. >> >> The draft needs clarifications to the problem statement, the draft >> goals and scope, and a clearer separation between normative statements >> and non-normative considerations. >> >> I think that would be easiest with some reorganization. Here's a >> proposed outline. (I don't think you need to stick to this outline in >> detail, as long as the points are clear) >> >> Thanks! >> >> Ben. >> ---------------- >> >> Problem: >> >> - B2BUAs (especially SBCs) often make e2e dtls-srtp impossible. There >> are use cases where they could do their jobs and still allow e2e >> dtls-srtp. >> - The dtls-srtp dependency on RFC 4474 makes that hard in many cases. >> - What do we mean by e2e DTLS-SRTP? (I _think_ we mean from the >> perspective of the b2bua, where that b2bua is not a party to the >> DTLS-SRTP SA, and doesn't have the session key or private keys for >> DTLS cert(s). >> >> Goals and Scope: >> >> - Goal is to provide guidance on how b2buas that could possibly do >> their jobs without breaking e2e dtls-srtp to do so. >> - B2BUAs exist that will still not allow e2e dtls-srtp for various >> reasons. These are out-of-scope, and the draft should not attempt to >> make value judgements about them. >> - Termination of dtls-srtp at the b2bua is out of scope by definition >> (it's not e2e). >> >> Normative rules for B2BUAs to allow e2e DTLS-SRTP: >> >> - Consider both media signaling layers (including for non-media-path >> b2buas) >> - Discuss differences for 4474 and 4474bis, including how a b2bua >> might tell them apart.(Hopefully 4474 will be obsolete soon, but we >> should still discuss it, since it has significant impact on things >> like media-latching since it signs the entire SDP payload.) >> - Discuss differences if the b2bua acts as a 4474/4474bis >> authenticator and/or verifier. >> >> Implications/considerations for each b2bua type (non-normative): >> >> - How do the normative requirements in the previous sections impact >> the various b2bua types. >> >> Normal security and privacy considerations. >> >> >> >> On 9 Dec 2015, at 12:50, Alissa Cooper wrote: >> >>>> On Dec 3, 2015, at 1:12 PM, Ben Campbell wrote: >>>> >>>> On 2 Dec 2015, at 23:17, Alissa Cooper wrote: >>>> >>>>> Could you articulate the reasons why someone would build a B2BUA >>>>> that >>>>>>>> follows the recommendations in this draft? >>>>> >>>>> >>>>>> >>>>>> B2BUAs used in deployments like the above mentioned scenarios can >>>>>> use the >>>>>> recommendations in this draft. >>>>> >>>>> >>>>> Ok. What I am still missing is why this draft needs to be published >>>>> to make that happen. This is the type of SBC to which the Section >>>>> 3.1.1 guidance is directed. How does the behavior of existing >>>>> media-latching SBCs differ from what 3.1.1 tells them to do? And if >>>>> this type of SBC implementation is the key target audience, >>>>> doesn=B9t that make the 3.1.2 guidance essentially no-ops? >>>> >>>> Authors: >>>> >>>> After discussion on today's telechats, and some side discussions >>>> with Alissa, I believe this question is the lynch-pin for making any >>>> progress. I advise people to work this out first before worrying >>>> about the rest of the discussion: Can we articulate how we expect >>>> this draft will change implementer and/or operator behavior? >>>> >>>> Obviously B2BUAs that exist for reasons that require modification of >>>> RTP/RTCP, or cleartext access to the encrypted bits of SRTP are not >>>> going to conform, and are therefore out of scope. The draft doesn't >>>> seem to concern itself with b2buas that are not in the media path at >>>> all. (Maybe it should, since there are plenty of purely >>>> signaling-plane ways to break dtls-srtp?). >>>> >>>> That leaves the question of b2buas in the media path that do not >>>> require modification or cleartext access to protected bits in >>>> srtp--effectively media-relays as described in 3.1.1 Do we believe >>>> people do not know how to build or use such devices without breaking >>>> dtls-srtp? Are people aware of such devices that break dtls-srtp >>>> when they don't need to? Perhaps by misconfiguration, or because >>>> they use SBCs designed for more invasive use cases? >>> >>> As Ben says, I think this draft would add value if it could >>> articulate the problem statement, including the kinds of B2BUAs that >>> cause the problem, and then articulate a solution that those kinds of >>> B2BUAs have a reasonable chance of implementing given what they are >>> otherwise designed to do. >>> >>> Alissa >>> >>>> >>>> Thanks! >>>> >>>> Ben. >> >> _______________________________________________ >> straw mailing list >> straw@ietf.org >> https://www.ietf.org/mailman/listinfo/straw