From nobody Tue Dec 1 08:11:08 2015 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 E6F881A6F52; Mon, 30 Nov 2015 20:58:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> Date: Mon, 30 Nov 2015 20:58:18 -0800 Archived-At: X-Mailman-Approved-At: Tue, 01 Dec 2015 08:11:06 -0800 Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, straw@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com Subject: [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 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, 01 Dec 2015 04:58:19 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-straw-b2bua-dtls-srtp-09: Discuss 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-straw-b2bua-dtls-srtp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) I have a fairly fundamental concern about this document that I'd like to discuss. My impression is that most B2BUAs in the market today that handle DTLS-SRTP do so with the explicit purpose of accessing the media. That is, if I need a box that doesn't access the media I use a SIP proxy, and if I need one that does access it I use a B2BUA. I realize that there are more flavors of B2BUA defined in RFC 7092, but in terms of how real SBCs work, it seems to me that they break DTLS-SRTP intentionally if they do so at all. If that's the case, the question then arises about the value of writing down normative recommendations that are more than likely to be ignored. Perhaps this document would have made more sense as informational, offering a non-normative explanation of what a B2BUA should do if it does not want to break e2e security. Even as an informational document it's still not obvious to me that there is much at all to say here for media-aware B2BUAs that isn't entirely reductive -- "don't terminate DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an informational document it wouldn't be suggesting normative requirements that are out of sync with real deployments. Could you articulate the reasons why someone would build a B2BUA that follows the recommendations in this draft? I note that the draft says nothing about using a TURN server as a media relay, which seems like it would be more common than using a B2BUA for the same purpose. Aren't B2BUAs typically deployed *because* they are media-aware? (2) Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement for inspection B2BUAs without explaining what the exception cases are, and 3.1.2.2 creates no normative requirements for modification B2BUAs. It's not even clear to me why the distinction is being drawn between the two kinds of B2BUAs if the bottom line is that in both cases the recommendation is to not terminate DTLS-SRTP. But this brings us back to the above comment. The problem here seems to be that what the WG and the IETF would want to say here is that B2BUAs MUST NOT terminate DTLS-SRTP to man-in-the-middle the media, but that is what B2BUAs generally do, so instead the text waffles and the recommendations are watered down and unclear. (3) The characterization of the RFC 4474 mechanism seems to contradict the way the mechanism is actually specified. The 4474 mechanism was designed such that intermediaries would be able to provide signatures on behalf of users (e.g., see RFC 4474 Section 3, "This specification allows either a user agent or a proxy server to provide identity services and to verify identities ... in the initial use of this mechanism, it is likely that intermediaries will instantiate the authentication service role"). So the claim that terminating DTLS-SRTP would cause 4474 identity and integrity checks to fail isn't true, because an SBC can decrypt and re-sign the request itself. A B2BUA that bridges two administrative domains can check the validity of the signature in the domain on on side as authorization to form a new signature that is valid in the domain in the other side. The fact that user-provided identity assertions are not guaranteed to persist end-to-end is one key reason for the ongoing work in the STIR WG. The work there and elsewhere shows that it's fairly widely acknowledged that 4474 has not seen the deployment that was hoped for when it was specified. Making its use a normative requirement here again seems out of sync with deployment reality. I would encourage you to review draft-ietf-stir-rfc4474bis and reconsider what security mechanism should form the basis of the recommendations in this draft. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.1.1: Is there anything new being specified here that isn't already specified in other SIP documents? Section 3.2: Is this saying anything that RFC 5763 doesn't already say? From nobody Tue Dec 1 10:40:38 2015 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 474201B2ECE; Tue, 1 Dec 2015 10:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbOwH6NOiZjZ; Tue, 1 Dec 2015 10:40:32 -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 2C7411B2ECC; Tue, 1 Dec 2015 10:40:32 -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 tB1IeO7r008320 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2015 12:40:24 -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: "Alissa Cooper" Date: Tue, 01 Dec 2015 12:40:23 -0600 Message-ID: In-Reply-To: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, christer.holmberg@ericsson.com, The IESG , 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: Tue, 01 Dec 2015 18:40:34 -0000 (Commenting on discuss items 1 and 2. See separate email for comments on 3). I think items 1 and 2 come down to having a clear scope and purpose. This version actually made progress in that direction (see section 1.2), but clearly didn't reach the goal. Normally, I I would favor making this informational, and removing the normative language. But on reflection, I see that the straw charter calls for describing normative requirements to make certain features work. In this case, the "certain feature" is e2e dtls-srtp. Alissa: Would it help if we clarified the scope along the following lines: - This draft defines certain behaviors that a b2bua needs to engage (or not engage) in in order to allow the "feature" of e2e dtls-srtp. - Define what we mean by e2e. I _think_ we are talking about end-user devices, and that we don't want to leave room for semantic games along the line of calling a b2bua an "end". (This would change the arguments around certain requirements, e.g."don't terminate srtp".) - Recognize that there are b2buas that intentionally do not allow e2e protection. We cannot stop those, and we don't need to get wrapped around reasons why or whether that's good or bad. We would also need to be more consistent with the use of 2119 keywords. Authors/Shepherd/Chairs: Please indicate your thoughts. It would be really nice to have an idea of the way forward by Thursday's telechat. Thanks! Ben. On 30 Nov 2015, at 22:58, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-straw-b2bua-dtls-srtp-09: Discuss > > 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-straw-b2bua-dtls-srtp/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > (1) > I have a fairly fundamental concern about this document that I'd like > to > discuss. My impression is that most B2BUAs in the market today that > handle DTLS-SRTP do so with the explicit purpose of accessing the > media. > That is, if I need a box that doesn't access the media I use a SIP > proxy, > and if I need one that does access it I use a B2BUA. I realize that > there > are more flavors of B2BUA defined in RFC 7092, but in terms of how > real > SBCs work, it seems to me that they break DTLS-SRTP intentionally if > they > do so at all. > > If that's the case, the question then arises about the value of > writing > down normative recommendations that are more than likely to be > ignored. > Perhaps this document would have made more sense as informational, > offering a non-normative explanation of what a B2BUA should do if it > does > not want to break e2e security. Even as an informational document it's > still not obvious to me that there is much at all to say here for > media-aware B2BUAs that isn't entirely reductive -- "don't terminate > DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an > informational document it wouldn't be suggesting normative > requirements > that are out of sync with real deployments. > > Could you articulate the reasons why someone would build a B2BUA that > follows the recommendations in this draft? I note that the draft says > nothing about using a TURN server as a media relay, which seems like > it > would be more common than using a B2BUA for the same purpose. Aren't > B2BUAs typically deployed *because* they are media-aware? > > (2) > Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are > problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement > for > inspection B2BUAs without explaining what the exception cases are, and > 3.1.2.2 creates no normative requirements for modification B2BUAs. > It's > not even clear to me why the distinction is being drawn between the > two > kinds of B2BUAs if the bottom line is that in both cases the > recommendation is to not terminate DTLS-SRTP. But this brings us back > to > the above comment. The problem here seems to be that what the WG and > the > IETF would want to say here is that B2BUAs MUST NOT terminate > DTLS-SRTP > to man-in-the-middle the media, but that is what B2BUAs generally do, > so > instead the text waffles and the recommendations are watered down and > unclear. > > (3) > The characterization of the RFC 4474 mechanism seems to contradict the > way the mechanism is actually specified. The 4474 mechanism was > designed > such that intermediaries would be able to provide signatures on behalf > of > users (e.g., see RFC 4474 Section 3, "This specification allows either > a > user agent or a proxy server to provide identity services and to > verify > identities ... in the initial use of this mechanism, it is likely that > intermediaries will instantiate the authentication service role"). So > the > claim that terminating DTLS-SRTP would cause 4474 identity and > integrity > checks to fail isn't true, because an SBC can decrypt and re-sign the > request itself. A B2BUA that bridges two administrative domains can > check > the validity of the signature in the domain on on side as > authorization > to form a new signature that is valid in the domain in the other side. > > The fact that user-provided identity assertions are not guaranteed to > persist end-to-end is one key reason for the ongoing work in the STIR > WG. > The work there and elsewhere shows that it's fairly widely > acknowledged > that 4474 has not seen the deployment that was hoped for when it was > specified. Making its use a normative requirement here again seems out > of > sync with deployment reality. I would encourage you to review > draft-ietf-stir-rfc4474bis and reconsider what security mechanism > should > form the basis of the recommendations in this draft. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3.1.1: > > Is there anything new being specified here that isn't already > specified > in other SIP documents? > > Section 3.2: > > Is this saying anything that RFC 5763 doesn't already say? From nobody Tue Dec 1 15:30:22 2015 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 AB53C1B2A3D; Tue, 1 Dec 2015 15:30:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201233019.30384.79009.idtracker@ietfa.amsl.com> Date: Tue, 01 Dec 2015 15:30:19 -0800 Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, straw@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com Subject: [straw] Stephen Farrell'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 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, 01 Dec 2015 23:30:19 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-straw-b2bua-dtls-srtp-09: Discuss 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-straw-b2bua-dtls-srtp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I wonder if you've gotten wrapped around the axle here knowing that we won't standardise a (D)TLS MitM, but yet trying to describe things that basically are often deployed as MitMs. Anyway, while I do agree with Alissa's discuss, I also have some additional points to raise, some of which I think came up when we had some mail exchanges about an earlier version of this draft back in January of this year. (1) Alissa is correct that the unqualified SHOULD NOT "terminate" DTLS is insufficient, but in addition to her call for qualification of that, (or I guess moving to a MUST NOT,) I would like to chat about the consequences should one (for whatever reason) ignore that SHOULD NOT. Whether or not this discuss point is worth talking about depends on how Alissa's discuss on this is resolved. It seems to me (as I said back in January) that keeping the SHOULD NOT would mean that any UA that is able to inter-operate with a B2BUA that does "terminate" DTLS (because it fits with whatever qualifiers you end up adding to the SHOULD NOT) can never ever be confident of the identity of any DTLS peer (since it has code that lets the call happen regardless of the DTLS-layer peer identity). I can't see how that wouldn't make the Internet worse, hence the discuss. (2) In the introduction you say "B2BUAs terminating DTLS-SRTP session are outside the scope of this document." yet if you keep the SHOULD NOT and don't move that to a MUST NOT (which was an option we discussed back in Jan, I assume the WG didn't like that?), then you are in fact including those are within the scope of this document and therefore you would need to specify how to "terminate" a DTLS or DTLS-SRTP session when one is a B2BUA but yet respect RFC2804. I just can't see how one might do that to be honest. (3) 3.1.2 says: "There are two types of media-aware relays, those that merely inspect the RTP headers and unencrypted portions of RTCP packets, and those that inspect and modify the RTP headers and unencrypted portions of RTCP packets." Logically, those are not the only options, as one can modify the encrypted portions too. (Hopefully resulting in the integrity checking causing the packets to be dropped.) I think this particular lack of clarity does raise to the level of a DISCUSS as it's crucial for this document to be clear about not standardising a MitM. ("Sins of omission" are probably not a good idea here:-) (4) 3.1.2.2 says: "This security and privacy problem can be mitigated by having different keys for protecting RTP header integrity and encrypting the RTP payload. For example, the approach discussed in [I-D.jones-perc-private-media-reqts] can be used." I have two issues with that. First, where is having different keys documented? If only in the draft referenced, then what is the status of that? And secondly, doesn't perc require a KMS to exist? In which case I can't see how this specification works for calls between UAs (via a B2BUA) where there is no KMS. I think there are both security and interop (and hence also process) issues with what you're saying here. (5) 3.2 says: "the ClientHello message from a B2BUA (acting as DTLS client)" I don't see how a B2BUA can send it's own ClientHello (as opposed to forwarding a UA's) unless it is a MitM. Since we do not standardise MitM (cf. RFC2804) this text must be wrong or out of place? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I don't see what Figure2 is trying to tell me, though the preceding text is clear enough. I'd recommend maybe dropping that figure or else making it a full ladder diagram of (most of) the messages involved. - There's a repetition of the "SHOULD NOT" problem that affects my point (1) above and Alissa's discuss points in the security considerations when you say "Attempting to cover media-aware relay modifying RTP headers and media termination scenarios involving secure sessions (like DTLS-SRTP) will inevitably lead to the B2BUA acting as a man-in-the-middle, and hence it is RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session." - As with Alissa, I think the reliance on 4474, especially if that is not deployed, is odd. It would be bad if that were read as encouragement to not check DTLS client/server certs unless one implements 4474. (But this is covered in Alissa's discuss so is just a comment here.) From nobody Wed Dec 2 06:07:15 2015 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 5AF511A904E for ; Wed, 2 Dec 2015 06:07:13 -0800 (PST) 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=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 vIsgNDaiLtGn for ; Wed, 2 Dec 2015 06:07:09 -0800 (PST) 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 4C0691A9050 for ; Wed, 2 Dec 2015 06:07:06 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 70E6120B6D for ; Wed, 2 Dec 2015 09:07:05 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute6.internal (MEProxy); Wed, 02 Dec 2015 09:07:05 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=JU8ifJFvH6ELIpmaGfSEYYXIXPw=; b=PVBUob Ke4McQM6C09NpErOP4sqKNpg9pbzLNkjOEPgGrke4f14iS1AX8bDbtYI83rOWAyd YnL/9yFEeTd2Yc0X1FfTGdfS4i909NMvOlcWSS6NYXaweEMkA6hIaGtj1O6rbhaF aPI2NfWN6LxCr7poX4vBYpk5pdcXs9yM1GJCg= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=JU8ifJFvH6ELIpm aGfSEYYXIXPw=; b=hel4UO1V3jzfoVlZoQ5Evu9WNcJkFKNk0oJ337Z0PxTi5Me f5UY7zW70XSKok2Iq0T9V9mLGVWCiyHUP2NZCsBfoAtD/h4LOUJCZqKGO5hkbXUc /TfpKvHQSjlcBKl9LpCB+X+fFXQXwBYjAjvhLxUaqdMVuXTufdegbcrdZOqM= X-Sasl-enc: kh9wxJj4a4hPHeCDrqQ2rMZ741lMyk0/TjZJQlQbJ8Yw 1449065224 Received: from [192.168.1.203] (c-24-6-61-198.hsd1.ca.comcast.net [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 3281CC016DA; Wed, 2 Dec 2015 09:07:04 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 2 Dec 2015 06:07:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, christer.holmberg@ericsson.com, IESG , 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: Wed, 02 Dec 2015 14:07:13 -0000 > On Dec 1, 2015, at 10:40 AM, Ben Campbell wrote: >=20 > (Commenting on discuss items 1 and 2. See separate email for comments = on 3). >=20 > I think items 1 and 2 come down to having a clear scope and purpose. = This version actually made progress in that direction (see section 1.2), = but clearly didn't reach the goal. >=20 > Normally, I I would favor making this informational, and removing the = normative language. But on reflection, I see that the straw charter = calls for describing normative requirements to make certain features = work. In this case, the "certain feature" is e2e dtls-srtp. >=20 > Alissa: Would it help if we clarified the scope along the following = lines: >=20 > - This draft defines certain behaviors that a b2bua needs to engage = (or not engage) in in order to allow the "feature" of e2e dtls-srtp. I think the underlying question is, if such a document were written, = would it say anything that isn=E2=80=99t entirely reductive, obvious, or = already documented elsewhere? As I inquired about in my comments, it = seems as though the substance of 3.1.1 and 3.2 may already be documented = elsewhere. Presumably 3.1.2 would disappear in the approach you suggest, = since the behavior amounts to =E2=80=9Cdon=E2=80=99t do anything=E2=80=9D = or =E2=80=9Cbe a proxy,=E2=80=9D roughly. >=20 > - Define what we mean by e2e. I _think_ we are talking about end-user = devices, and that we don't want to leave room for semantic games along = the line of calling a b2bua an "end". (This would change the arguments = around certain requirements, e.g."don't terminate srtp=E2=80=9D.) Yes, that was my assumption in reading the document. >=20 > - Recognize that there are b2buas that intentionally do not allow e2e = protection. We cannot stop those, and we don't need to get wrapped = around reasons why or whether that's good or bad. >=20 > We would also need to be more consistent with the use of 2119 = keywords. >=20 > Authors/Shepherd/Chairs: Please indicate your thoughts. It would be = really nice to have an idea of the way forward by Thursday's telechat. Yep, I=E2=80=99d like to understand where people see the value in = publishing this or what impact they expect it to have on existing B2BUA = implementations. Thanks, Alissa >=20 > Thanks! >=20 > Ben. >=20 >=20 > On 30 Nov 2015, at 22:58, Alissa Cooper wrote: >=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-straw-b2bua-dtls-srtp-09: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> (1) >> I have a fairly fundamental concern about this document that I'd like = to >> discuss. My impression is that most B2BUAs in the market today that >> handle DTLS-SRTP do so with the explicit purpose of accessing the = media. >> That is, if I need a box that doesn't access the media I use a SIP = proxy, >> and if I need one that does access it I use a B2BUA. I realize that = there >> are more flavors of B2BUA defined in RFC 7092, but in terms of how = real >> SBCs work, it seems to me that they break DTLS-SRTP intentionally if = they >> do so at all. >>=20 >> If that's the case, the question then arises about the value of = writing >> down normative recommendations that are more than likely to be = ignored. >> Perhaps this document would have made more sense as informational, >> offering a non-normative explanation of what a B2BUA should do if it = does >> not want to break e2e security. Even as an informational document = it's >> still not obvious to me that there is much at all to say here for >> media-aware B2BUAs that isn't entirely reductive -- "don't terminate >> DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an >> informational document it wouldn't be suggesting normative = requirements >> that are out of sync with real deployments. >>=20 >> Could you articulate the reasons why someone would build a B2BUA that >> follows the recommendations in this draft? I note that the draft says >> nothing about using a TURN server as a media relay, which seems like = it >> would be more common than using a B2BUA for the same purpose. Aren't >> B2BUAs typically deployed *because* they are media-aware? >>=20 >> (2) >> Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 = are >> problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement = for >> inspection B2BUAs without explaining what the exception cases are, = and >> 3.1.2.2 creates no normative requirements for modification B2BUAs. = It's >> not even clear to me why the distinction is being drawn between the = two >> kinds of B2BUAs if the bottom line is that in both cases the >> recommendation is to not terminate DTLS-SRTP. But this brings us back = to >> the above comment. The problem here seems to be that what the WG and = the >> IETF would want to say here is that B2BUAs MUST NOT terminate = DTLS-SRTP >> to man-in-the-middle the media, but that is what B2BUAs generally do, = so >> instead the text waffles and the recommendations are watered down and >> unclear. >>=20 >> (3) >> The characterization of the RFC 4474 mechanism seems to contradict = the >> way the mechanism is actually specified. The 4474 mechanism was = designed >> such that intermediaries would be able to provide signatures on = behalf of >> users (e.g., see RFC 4474 Section 3, "This specification allows = either a >> user agent or a proxy server to provide identity services and to = verify >> identities ... in the initial use of this mechanism, it is likely = that >> intermediaries will instantiate the authentication service role"). So = the >> claim that terminating DTLS-SRTP would cause 4474 identity and = integrity >> checks to fail isn't true, because an SBC can decrypt and re-sign the >> request itself. A B2BUA that bridges two administrative domains can = check >> the validity of the signature in the domain on on side as = authorization >> to form a new signature that is valid in the domain in the other = side. >>=20 >> The fact that user-provided identity assertions are not guaranteed to >> persist end-to-end is one key reason for the ongoing work in the STIR = WG. >> The work there and elsewhere shows that it's fairly widely = acknowledged >> that 4474 has not seen the deployment that was hoped for when it was >> specified. Making its use a normative requirement here again seems = out of >> sync with deployment reality. I would encourage you to review >> draft-ietf-stir-rfc4474bis and reconsider what security mechanism = should >> form the basis of the recommendations in this draft. >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 3.1.1: >>=20 >> Is there anything new being specified here that isn't already = specified >> in other SIP documents? >>=20 >> Section 3.2: >>=20 >> Is this saying anything that RFC 5763 doesn't already say? From nobody Wed Dec 2 07:07:53 2015 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 D91C21ACE85 for ; Wed, 2 Dec 2015 07:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 GN5u4Sv1TAaX for ; Wed, 2 Dec 2015 07:07:50 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BC11ACD8D for ; Wed, 2 Dec 2015 07:07:46 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-12v.sys.comcast.net with comcast id of671r00157bBgG01f7lMw; Wed, 02 Dec 2015 15:07:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-13v.sys.comcast.net with comcast id of7k1r00Z3KdFy101f7l13; Wed, 02 Dec 2015 15:07:45 +0000 To: straw@ietf.org References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <565F0940.5010506@alum.mit.edu> Date: Wed, 2 Dec 2015 10:07:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1449068865; bh=fzaL5wYiQLZvtzcEuYlRKHnsrgz1OBgCw04coqBoShM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WE2LmKZVuDnHIAp+kZ0yzzzDqSCua5bnrPIsE/UPa1T1D78rE4JwdWERYvN9hGrmM WkMxl/jbprnV+IFNVoxtsTVQ8yJ1oWAWPvHPjx1NnrfZJZFvZwpq9vqoSIAXKYZBbo itzm9Mlh9p6FmRTvvNGtHEThZYb8WUEvJmMK5QEAAnbSpjITIk38lQ4JO9ldJ04bXS gjIOZLMtiGm6B0ZLb9JHv0VAM2OGrzZ9aS3XtXx4oo9oBouNYCii8lFKcaYP5mfAwZ u39Mv9Hd6W5ffVJG6ncVEjMxY2KAbkFvn6Zy2eee5K+MNsq3nX9fVyoOG76XJqts8v UuhaLYK5ZCOkQ== Archived-At: Subject: [straw] What is an "end"? 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: Wed, 02 Dec 2015 15:07:51 -0000 On 12/1/15 1:40 PM, Ben Campbell wrote: > - Define what we mean by e2e. I _think_ we are talking about end-user > devices, and that we don't want to leave room for semantic games along > the line of calling a b2bua an "end". (This would change the arguments > around certain requirements, e.g."don't terminate srtp".) I think this is important! And I think it goes beyond this draft or perhaps even this WG. ISTM that the definition of "end" is a matter of control. I may have a server somewhere (maybe in a cloud), as well as one or more local devices. As long as I control it and am aware of its behavior it can be considered an *end* representing me, and carry my identity in the signaling. And this can be true even if it is not an "end" in the overall topology of a call. For instance, I could have a B2BUA (application server) between my phone and the "other" party in a call. It might record the call (on my behalf) or otherwise process the media. It could serve as the hub for a decomposed endpoint. OTOH, a "traditional" SBC is typically *not* entirely under my control. It may well have policies that I disagree with, but can't avoid. I would like to ensure that it can't access the content of my media. This gets tricky when my SP provides application services to me in a shared server. It may give me some configuration options to influence the behavior of that server. But it may also have other policies of its own that it doesn't allow me to control. Thanks, Paul From nobody Wed Dec 2 07:17:51 2015 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 75CDE1A0117 for ; Wed, 2 Dec 2015 07:17:48 -0800 (PST) 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=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 7SPArqjCllYs for ; Wed, 2 Dec 2015 07:17:45 -0800 (PST) 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 999B51A00F3 for ; Wed, 2 Dec 2015 07:17:41 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 060B2207D8 for ; Wed, 2 Dec 2015 10:17:41 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Wed, 02 Dec 2015 10:17:41 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=2CaF9T4iOmk5XcNlxWQmuSDhxHk=; b=R0i9vZ +i/2abgnkn6RTEp9/NQgrabqNfdsO0kqYMLEizkIDaWJUvDvyUcxsd6/DMCr+fvp B7mzEMHPd/PQdDI/h8ft6/WBqF1bhyy8Q5RkMY2bjocSy/S3859VMPn9SENH4n9o h3QHmu1k8ugIWwLdFxLW1a6Je85nch/likzL4= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=2CaF9T4iOmk5XcN lxWQmuSDhxHk=; b=A+19NoA7KEpAKB/VgTtyjoscMVOUGOIkvBNmx4EvVrE/Kdw +UJUAXGTihRcW5iv2jy9fosF+kEdzDvN+sVH/ICtmuhQJsT5YVKk6/ehLUPuQVjH dLW10x2HilvdheJPsRm9VuzcE/zploRd1SXhc1/blcZYUthjuqzTHDjrEElg= X-Sasl-enc: 7i3nHCPxpCtsQqUKESD0iDLSpJvG0/3i5YXgIfOyhC0J 1449069460 Received: from sjc-alcoop-8815.cisco.com (unknown [128.107.241.163]) by mail.messagingengine.com (Postfix) with ESMTPA id DEC1E6801D8; Wed, 2 Dec 2015 10:17:39 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: <4823C88F-6158-453D-A3EE-4AB7CEF055AA@nostrum.com> Date: Wed, 2 Dec 2015 07:17:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <4823C88F-6158-453D-A3EE-4AB7CEF055AA@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, christer.holmberg@ericsson.com, IESG , 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: Wed, 02 Dec 2015 15:17:48 -0000 > On Nov 30, 2015, at 9:31 PM, Ben Campbell wrote: >=20 > A couple of quick comments on your discuss item 3 below. (I will leave = it to the authors to respond to the rest) >=20 > On 30 Nov 2015, at 22:58, Alissa Cooper wrote: >=20 >> Alissa Cooper has entered the following ballot position for >> draft-ietf-straw-b2bua-dtls-srtp-09: Discuss >>=20 >> 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.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> (1) >> I have a fairly fundamental concern about this document that I'd like = to >> discuss. My impression is that most B2BUAs in the market today that >> handle DTLS-SRTP do so with the explicit purpose of accessing the = media. >> That is, if I need a box that doesn't access the media I use a SIP = proxy, >> and if I need one that does access it I use a B2BUA. I realize that = there >> are more flavors of B2BUA defined in RFC 7092, but in terms of how = real >> SBCs work, it seems to me that they break DTLS-SRTP intentionally if = they >> do so at all. >>=20 >> If that's the case, the question then arises about the value of = writing >> down normative recommendations that are more than likely to be = ignored. >> Perhaps this document would have made more sense as informational, >> offering a non-normative explanation of what a B2BUA should do if it = does >> not want to break e2e security. Even as an informational document = it's >> still not obvious to me that there is much at all to say here for >> media-aware B2BUAs that isn't entirely reductive -- "don't terminate >> DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an >> informational document it wouldn't be suggesting normative = requirements >> that are out of sync with real deployments. >>=20 >> Could you articulate the reasons why someone would build a B2BUA that >> follows the recommendations in this draft? I note that the draft says >> nothing about using a TURN server as a media relay, which seems like = it >> would be more common than using a B2BUA for the same purpose. Aren't >> B2BUAs typically deployed *because* they are media-aware? >>=20 >> (2) >> Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 = are >> problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement = for >> inspection B2BUAs without explaining what the exception cases are, = and >> 3.1.2.2 creates no normative requirements for modification B2BUAs. = It's >> not even clear to me why the distinction is being drawn between the = two >> kinds of B2BUAs if the bottom line is that in both cases the >> recommendation is to not terminate DTLS-SRTP. But this brings us back = to >> the above comment. The problem here seems to be that what the WG and = the >> IETF would want to say here is that B2BUAs MUST NOT terminate = DTLS-SRTP >> to man-in-the-middle the media, but that is what B2BUAs generally do, = so >> instead the text waffles and the recommendations are watered down and >> unclear. >>=20 >> (3) >> The characterization of the RFC 4474 mechanism seems to contradict = the >> way the mechanism is actually specified. The 4474 mechanism was = designed >> such that intermediaries would be able to provide signatures on = behalf of >> users (e.g., see RFC 4474 Section 3, "This specification allows = either a >> user agent or a proxy server to provide identity services and to = verify >> identities ... in the initial use of this mechanism, it is likely = that >> intermediaries will instantiate the authentication service role"). So = the >> claim that terminating DTLS-SRTP would cause 4474 identity and = integrity >> checks to fail isn't true, because an SBC can decrypt and re-sign the >> request itself. A B2BUA that bridges two administrative domains can = check >> the validity of the signature in the domain on on side as = authorization >> to form a new signature that is valid in the domain in the other = side. >>=20 >> The fact that user-provided identity assertions are not guaranteed to >> persist end-to-end is one key reason for the ongoing work in the STIR = WG. >> The work there and elsewhere shows that it's fairly widely = acknowledged >> that 4474 has not seen the deployment that was hoped for when it was >> specified. Making its use a normative requirement here again seems = out of >> sync with deployment reality. I would encourage you to review >> draft-ietf-stir-rfc4474bis and reconsider what security mechanism = should >> form the basis of the recommendations in this draft. >=20 > There was discussion that a b2bua could terminate dtls-srtp if it = provided an identity service, or acted in collusion with an identity = service. My understanding is that the authors felt that delving into = special cases where it might be "okay" for a b2bua to terminate = dtls-srtp would add too much complexity to the point. (There's also the = fact that dtls-srtp says you SHOULD use 4474, not MUST). If you look at this through the lens of 4474 deployment, it isn=E2=80=99t = really a special case, since neither case is in much use. I think the = complexity arises because the document is trying to make = recommendations. If it were to just describe the implications of what = would happen if B2BUAs in various scenarios encountered 4474 signatures, = then at least it could be made to be a correct description of the = behaviors one could theoretically encounter. >=20 > I tend to agree on the complexity--but I think it would make sense to = clarify this to say that a b2bua that is not also providing an identity = service is likely to break things. I think the underlying problem here gets back to the question about = whether this draft is making recommendations that anyone implementing a = B2BUA is likely to follow, or whether it is making recommendations for = the sake of writing them down and attaching an RFC number to them. = Because if it=E2=80=99s the former, it doesn=E2=80=99t make much sense = for the basis of this to be 4474. >=20 > As far as 4474bis is concerned--they originally referenced 4474bis, = and I suggested that they not do so. My reasoning was that both 4474 and = 4474bis (as written at that time) protected the fingerprint, which was = the important bit here--and that since 4474bis was expected to obsolete = 4474, a reference to 4474 would "self upgrade", so to speak. Do you = disagree with that? (But to be totally honest, my concern was entirely = about avoiding an extended stay in MISSREF land. Maybe that's not as big = of a concern now?) I think when we=E2=80=99re at the point where we spun up a working group = for the purpose of replacing the original document, we=E2=80=99re better = off not normatively requiring use of the original. But again here I = question whether it=E2=80=99s appropriate for this document, which is = nominally about B2BUA behavior, to be putting any requirements on = endpoints in the first place. The STIR work is advancing and there is demand for it to get done, so I = wouldn=E2=80=99t be worried about 4474bis not finishing. Alissa >=20 >=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Section 3.1.1: >>=20 >> Is there anything new being specified here that isn't already = specified >> in other SIP documents? >>=20 >> Section 3.2: >>=20 >> Is this saying anything that RFC 5763 doesn't already say? From nobody Wed Dec 2 08:11:15 2015 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 D76CE1ACDA7; Tue, 1 Dec 2015 08:13:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151201161310.23712.7265.idtracker@ietfa.amsl.com> Date: Tue, 01 Dec 2015 08:13:10 -0800 Archived-At: X-Mailman-Approved-At: Wed, 02 Dec 2015 08:11:10 -0800 Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, straw@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com Subject: [straw] Kathleen Moriarty's No Objection on draft-ietf-straw-b2bua-dtls-srtp-09: (with COMMENT) 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, 01 Dec 2015 16:13:11 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-straw-b2bua-dtls-srtp-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-straw-b2bua-dtls-srtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I like the idea of documenting the methods used for MiTM to provide ways to avoid that in practice, but support Alyssa'a discuss points to make this point more clear (purpose of this documentation) and her concerns about what happens in actual implementations. I'd like to hear more on whether this should be standards track or informational as well and will follow along with her discuss thread. From nobody Wed Dec 2 08:14:54 2015 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 E25BB1AD36E; Wed, 2 Dec 2015 08:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 tGR276BribXS; Wed, 2 Dec 2015 08:14:45 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E8131AD1F5; Wed, 2 Dec 2015 08:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8441; q=dns/txt; s=iport; t=1449072878; x=1450282478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qbGO+wXvgmz7jllBvbMdJ/PCm3d0PACkAURE717yb1g=; b=l+ladHXq+7DT+kr0wQoaxq84wSkE+AlnCPorYfDbVQgQtqc0LUS2sbNw 1yTsgrhkc2NWIHTniTEztNNSsp3l/ibQMfsNOGi/8plVUSaYky4v6Q8O3 LZMFblKRd8PXRscLwJlBgh723vNrBmwLz1eb2akC98PkUVwXitn3yxl3E 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgDoF19W/5JdJa1VCYM6U28Gu2uCG?= =?us-ascii?q?gENgW4hhW0CgUw4FAEBAQEBAQGBCoQ0AQEBAwE6PwwEAgEIEQMBAgEVCRAyHQg?= =?us-ascii?q?CBAENBYgnCA3ADAEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlWEfIQgCQEHCgEGS?= =?us-ascii?q?w2EHwWHTY8PAYUrgnKFHYFbhEOSWoNxAR8BAUKCRIFAcgGELTqBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,373,1444694400"; d="scan'208";a="50095175" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2015 16:14:36 +0000 Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tB2GEaCP011163 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 16:14:36 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 11:14:35 -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.000; Wed, 2 Dec 2015 11:14:35 -0500 From: "Ram Mohan R (rmohanr)" To: Ben Campbell , Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) Thread-Index: AQHRLRyJEtYKcKD0DUqqycGO4Nm1MQ== Date: Wed, 2 Dec 2015 16:14:35 +0000 Message-ID: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.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.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.78.101] Content-Type: text/plain; charset="us-ascii" Content-ID: <232CE171F2F17D489B47DEE6622308EA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" , "christer.holmberg@ericsson.com" , The IESG , "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: Wed, 02 Dec 2015 16:14:53 -0000 Please see inline for few responses. -----Original Message----- From: Ben Campbell Date: Wednesday, 2 December 2015 at 12:10 AM To: Alissa Cooper Cc: The IESG , "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" , "straw@ietf.org" , "straw-chairs@ietf.org" , "christer.holmberg@ericsson.com" Subject: Re: Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) >(Commenting on discuss items 1 and 2. See separate email for comments on >3). > >I think items 1 and 2 come down to having a clear scope and purpose. >This version actually made progress in that direction (see section 1.2), >but clearly didn't reach the goal. > >Normally, I I would favor making this informational, and removing the >normative language. But on reflection, I see that the straw charter >calls for describing normative requirements to make certain features >work. In this case, the "certain feature" is e2e dtls-srtp. > >Alissa: Would it help if we clarified the scope along the following >lines: > >- This draft defines certain behaviors that a b2bua needs to engage (or >not engage) in in order to allow the "feature" of e2e dtls-srtp. > >- Define what we mean by e2e. I _think_ we are talking about end-user >devices, and that we don't want to leave room for semantic games along >the line of calling a b2bua an "end". (This would change the arguments >around certain requirements, e.g."don't terminate srtp".) Ok. We can add text like what Ben is suggesting to the draft if its going to make it clearer. > >- Recognize that there are b2buas that intentionally do not allow e2e >protection. We cannot stop those, and we don't need to get wrapped >around reasons why or whether that's good or bad. Agree. OTOH there are B2BUAs that do allow DTLS-SRTP end-to-end. See below for some points on this. > >We would also need to be more consistent with the use of 2119 keywords. > >Authors/Shepherd/Chairs: Please indicate your thoughts. It would be >really nice to have an idea of the way forward by Thursday's telechat. > >Thanks! > >Ben. > > >On 30 Nov 2015, at 22:58, Alissa Cooper wrote: > >> Alissa Cooper has entered the following ballot position for >> draft-ietf-straw-b2bua-dtls-srtp-09: Discuss >> >> 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=20 >> 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-straw-b2bua-dtls-srtp/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> (1) >> I have a fairly fundamental concern about this document that I'd like >> to >> discuss. My impression is that most B2BUAs in the market today that >> handle DTLS-SRTP do so with the explicit purpose of accessing the >> media. >> That is, if I need a box that doesn't access the media I use a SIP >> proxy, >> and if I need one that does access it I use a B2BUA. I realize that >> there >> are more flavors of B2BUA defined in RFC 7092, but in terms of how >> real >> SBCs work, it seems to me that they break DTLS-SRTP intentionally if >> they >> do so at all. I am aware of B2BUAs that pass-through SRTP (in this case DTLS-SRTP) end to end as well. In several deployments B2BUAs/SBCs are used for address hiding / media latching (as described in https://tools.ietf.org/html/rfc7362). In these scenarios the B2BUAs will be in media path as well but it just changes the UDP/IP headers and relay the UDP payload as is with out inspecting/modifying payload. >> >> If that's the case, the question then arises about the value of >> writing >> down normative recommendations that are more than likely to be >> ignored. >> Perhaps this document would have made more sense as informational, >> offering a non-normative explanation of what a B2BUA should do if it >> does >> not want to break e2e security. Even as an informational document it's >> still not obvious to me that there is much at all to say here for >> media-aware B2BUAs that isn't entirely reductive -- "don't terminate >> DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as an >> informational document it wouldn't be suggesting normative >> requirements >> that are out of sync with real deployments. >> >> 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. >>I note that the draft says >> nothing about using a TURN server as a media relay, which seems like >> it >> would be more common than using a B2BUA for the same purpose. Not all endpoints support ICE yet which is one of the reasons B2BUAs are used for simple media latching as well (described in RFC7362). >> Aren't >> B2BUAs typically deployed *because* they are media-aware? They can be media-aware or can just switch the media with out being aware of media as well. Regards, Ram >> >> (2) >> Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 are >> problematic. 3.1.2.1 creates a normative SHOULD NOT-level requirement >> for >> inspection B2BUAs without explaining what the exception cases are, and >> 3.1.2.2 creates no normative requirements for modification B2BUAs. >> It's >> not even clear to me why the distinction is being drawn between the >> two >> kinds of B2BUAs if the bottom line is that in both cases the >> recommendation is to not terminate DTLS-SRTP. But this brings us back >> to >> the above comment. The problem here seems to be that what the WG and >> the >> IETF would want to say here is that B2BUAs MUST NOT terminate >> DTLS-SRTP >> to man-in-the-middle the media, but that is what B2BUAs generally do, >> so >> instead the text waffles and the recommendations are watered down and >> unclear. >> >> (3) >> The characterization of the RFC 4474 mechanism seems to contradict the >> way the mechanism is actually specified. The 4474 mechanism was >> designed >> such that intermediaries would be able to provide signatures on behalf >> of >> users (e.g., see RFC 4474 Section 3, "This specification allows either >> a >> user agent or a proxy server to provide identity services and to >> verify >> identities ... in the initial use of this mechanism, it is likely that >> intermediaries will instantiate the authentication service role"). So >> the >> claim that terminating DTLS-SRTP would cause 4474 identity and >> integrity >> checks to fail isn't true, because an SBC can decrypt and re-sign the >> request itself. A B2BUA that bridges two administrative domains can >> check >> the validity of the signature in the domain on on side as >> authorization >> to form a new signature that is valid in the domain in the other side. >> >> The fact that user-provided identity assertions are not guaranteed to >> persist end-to-end is one key reason for the ongoing work in the STIR >> WG. >> The work there and elsewhere shows that it's fairly widely >> acknowledged >> that 4474 has not seen the deployment that was hoped for when it was >> specified. Making its use a normative requirement here again seems out >> of >> sync with deployment reality. I would encourage you to review >> draft-ietf-stir-rfc4474bis and reconsider what security mechanism >> should >> form the basis of the recommendations in this draft. >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Section 3.1.1: >> >> Is there anything new being specified here that isn't already >> specified >> in other SIP documents? >> >> Section 3.2: >> >> Is this saying anything that RFC 5763 doesn't already say? From nobody Wed Dec 2 08:23:33 2015 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 D6BA31B2A84 for ; Wed, 2 Dec 2015 08:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 7DtJouD7XPeZ for ; Wed, 2 Dec 2015 08:23:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBA01B2A51 for ; Wed, 2 Dec 2015 08:23:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2364; q=dns/txt; s=iport; t=1449073409; x=1450283009; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Hn4I9UendGuiQoDLnuDbUGwHBQZllMV0H1hELvDfVBw=; b=lXaSK9laR1nesBISmP0RE0NVBnv/TYT343TOUEikopWjcfnZtgIuDdJR hU2Fu3AEtw8nJzAsLak87PTFqqEWEAlm3GV71zK7RCg74k0C1hUiqZXNv 8+zEvN8e8V+WFNs3QHrxaT+OgEOgRGcvqP7cojvPs/ec9XQKJWj8rgxmC w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgDJGV9W/40NJK1VCQ6DLFNvBr4FA?= =?us-ascii?q?Q2BbhcKhW0CgUw4FAEBAQEBAQGBCoQ0AQEBBAEBAWsXBAIBCA4DAwECAS4nCx0?= =?us-ascii?q?IAgQBEogvDcAJAQEBAQEBAQEBAQEBAQEBAQEBARYEhlWEfIQxEReEYAWNXoh+A?= =?us-ascii?q?Y06nGkBHwEBQoNGPnKEaIEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,373,1444694400"; d="scan'208";a="51986742" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2015 16:23:29 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tB2GNSDW030647 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Dec 2015 16:23:29 GMT Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 11:23:27 -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.000; Wed, 2 Dec 2015 11:23:28 -0500 From: "Ram Mohan R (rmohanr)" To: Paul Kyzivat , "straw@ietf.org" Thread-Topic: [straw] What is an "end"? Thread-Index: AQHRLR3G8SKnsCDjrki4kF41uwtRVQ== Date: Wed, 2 Dec 2015 16:23:28 +0000 Message-ID: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <565F0940.5010506@alum.mit.edu> In-Reply-To: <565F0940.5010506@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.8.151023 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.78.101] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <59D31B1CA2E6444FB3C87AD1EE819CD7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [straw] What is an "end"? 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: Wed, 02 Dec 2015 16:23:32 -0000 Hi Paul, -----Original Message----- From: straw on behalf of Paul Kyzivat Date: Wednesday, 2 December 2015 at 8:37 PM To: "straw@ietf.org" Subject: [straw] What is an "end"? >On 12/1/15 1:40 PM, Ben Campbell wrote: > >> - Define what we mean by e2e. I _think_ we are talking about end-user >> devices, and that we don't want to leave room for semantic games along >> the line of calling a b2bua an "end". (This would change the arguments >> around certain requirements, e.g."don't terminate srtp".) > >I think this is important! And I think it goes beyond this draft or >perhaps even this WG. > >ISTM that the definition of "end" is a matter of control. I may have a >server somewhere (maybe in a cloud), as well as one or more local >devices. As long as I control it and am aware of its behavior it can be >considered an *end* representing me, and carry my identity in the >signaling. > >And this can be true even if it is not an "end" in the overall topology >of a call. For instance, I could have a B2BUA (application server) >between my phone and the "other" party in a call. It might record the >call (on my behalf) or otherwise process the media. It could serve as >the hub for a decomposed endpoint. > >OTOH, a "traditional" SBC is typically *not* entirely under my control. >It may well have policies that I disagree with, but can't avoid. I would >like to ensure that it can't access the content of my media. Agree with all the above. I don=B9t see a way by which one endpoint can kno= w if the peer is a endpoint/B2BUA or SBC. If both peers are using rfc4474 it can verify the identity of the peer but it will still not tell whether that is the final destination for the call or if the call goes beyond that device(like in the case of B2BUA/SBC). I don=B9t see a way to solve this with existing mechanisms. Ram > >This gets tricky when my SP provides application services to me in a >shared server. It may give me some configuration options to influence >the behavior of that server. But it may also have other policies of its >own that it doesn't allow me to control. > > Thanks, > Paul > >_______________________________________________ >straw mailing list >straw@ietf.org >https://www.ietf.org/mailman/listinfo/straw From nobody Wed Dec 2 10:56:56 2015 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 75DAD1ACE9B for ; Wed, 2 Dec 2015 10:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_64=0.6, SPF_SOFTFAIL=0.665] autolearn=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 uHnPgu3C7SJX for ; Wed, 2 Dec 2015 10:56:54 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B4C1ACE9A for ; Wed, 2 Dec 2015 10:56:53 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-04v.sys.comcast.net with comcast id oiwp1r0012EPM3101iwt33; Wed, 02 Dec 2015 18:56:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-07v.sys.comcast.net with comcast id oiws1r00S3KdFy101iws8r; Wed, 02 Dec 2015 18:56:53 +0000 To: "Ram Mohan R (rmohanr)" , "straw@ietf.org" References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <565F0940.5010506@alum.mit.edu> From: Paul Kyzivat Message-ID: <565F3EF4.2000006@alum.mit.edu> Date: Wed, 2 Dec 2015 13:56:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1449082613; bh=F4vNeboruUJKLm1FnS84DaBXY7Mi3zf406BYhZCzff4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OL/x4rk8kpJ+FaD5THY5VZ7KlAZ+OSxAD6w0vfkCcUuVmd9rimYipaeYrEjFeSZbj zzJdu9BW03k+i9tdC+8LsN6TiPle3eYY42dsl5YYbAYCCHD4KuqeBfyEe1cQw5Mry+ LDVRDmMmj2RYG8Pd5W7C4twq+diE8OKzlhw/PrAXo9iBy14dT5EU745C7LZKsGcb+k wuZeiMcIp2F+vxleEvqHhypIW2ogxBCuei6mBgqJ0QEbSkfgo6/0yaFPF+cHGo+q4F 6KJh9m/TqXcMKz+REZZ2HOSCk93YYug3T6lMmJzTtyIuuNYYHNVoTOQQ1feyy0DrB5 zU9ZmQSYrjxeg== Archived-At: Subject: Re: [straw] What is an "end"? 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: Wed, 02 Dec 2015 18:56:55 -0000 On 12/2/15 11:23 AM, Ram Mohan R (rmohanr) wrote: > > Hi Paul, > > -----Original Message----- > From: straw on behalf of Paul Kyzivat > > Date: Wednesday, 2 December 2015 at 8:37 PM > To: "straw@ietf.org" > Subject: [straw] What is an "end"? > >> On 12/1/15 1:40 PM, Ben Campbell wrote: >> >>> - Define what we mean by e2e. I _think_ we are talking about end-user >>> devices, and that we don't want to leave room for semantic games along >>> the line of calling a b2bua an "end". (This would change the arguments >>> around certain requirements, e.g."don't terminate srtp".) >> >> I think this is important! And I think it goes beyond this draft or >> perhaps even this WG. >> >> ISTM that the definition of "end" is a matter of control. I may have a >> server somewhere (maybe in a cloud), as well as one or more local >> devices. As long as I control it and am aware of its behavior it can be >> considered an *end* representing me, and carry my identity in the >> signaling. >> >> And this can be true even if it is not an "end" in the overall topology >> of a call. For instance, I could have a B2BUA (application server) >> between my phone and the "other" party in a call. It might record the >> call (on my behalf) or otherwise process the media. It could serve as >> the hub for a decomposed endpoint. >> >> OTOH, a "traditional" SBC is typically *not* entirely under my control. >> It may well have policies that I disagree with, but can't avoid. I would >> like to ensure that it can't access the content of my media. > > Agree with all the above. I don¹t see a way by which one endpoint can know > if the peer is a endpoint/B2BUA or SBC. No, it can't. > If both peers are using rfc4474 it can verify the identity of the peer but > it will still not tell whether that is the final destination > for the call or if the call goes beyond that device(like in the case of > B2BUA/SBC). Yes, > I don¹t see a way to solve this with existing mechanisms. I don't think it is something to *solve*. But it is a distinction that may be worth making when doing security analysis and review. And it is a distinction that would be good to make in product documentation. If a user has an intermediary server that he puts into his calls, then I think he should be able to permit it to terminate the media for his calls. Maybe such things should have a different name that just B2BUA. Thanks, Paul > Ram > >> >> This gets tricky when my SP provides application services to me in a >> shared server. It may give me some configuration options to influence >> the behavior of that server. But it may also have other policies of its >> own that it doesn't allow me to control. >> >> Thanks, >> Paul >> >> _______________________________________________ >> straw mailing list >> straw@ietf.org >> https://www.ietf.org/mailman/listinfo/straw > > From nobody Wed Dec 2 15:26:15 2015 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 918E81A908C; Wed, 2 Dec 2015 15:26:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvLwcS9gcrxR; Wed, 2 Dec 2015 15:26:11 -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 CA61D1A1B1F; Wed, 2 Dec 2015 15:26:11 -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 tB2NQ4Lk071897 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 2 Dec 2015 17:26:05 -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: "Alissa Cooper" Date: Wed, 02 Dec 2015 17:26:04 -0600 Message-ID: <273F968A-84B6-4516-A83F-15BA9CE6C815@nostrum.com> In-Reply-To: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <4823C88F-6158-453D-A3EE-4AB7CEF055AA@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: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, straw@ietf.org, IESG , straw-chairs@ietf.org, 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: Wed, 02 Dec 2015 23:26:13 -0000 On 2 Dec 2015, at 9:17, Alissa Cooper wrote: >> On Nov 30, 2015, at 9:31 PM, Ben Campbell wrote: >> >> A couple of quick comments on your discuss item 3 below. (I will >> leave it to the authors to respond to the rest) >> >> On 30 Nov 2015, at 22:58, Alissa Cooper wrote: >> >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-straw-b2bua-dtls-srtp-09: Discuss >>> [...] >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- [...] >>> >>> (3) >>> The characterization of the RFC 4474 mechanism seems to contradict >>> the >>> way the mechanism is actually specified. The 4474 mechanism was >>> designed >>> such that intermediaries would be able to provide signatures on >>> behalf of >>> users (e.g., see RFC 4474 Section 3, "This specification allows >>> either a >>> user agent or a proxy server to provide identity services and to >>> verify >>> identities ... in the initial use of this mechanism, it is likely >>> that >>> intermediaries will instantiate the authentication service role"). >>> So the >>> claim that terminating DTLS-SRTP would cause 4474 identity and >>> integrity >>> checks to fail isn't true, because an SBC can decrypt and re-sign >>> the >>> request itself. A B2BUA that bridges two administrative domains can >>> check >>> the validity of the signature in the domain on on side as >>> authorization >>> to form a new signature that is valid in the domain in the other >>> side. >>> >>> The fact that user-provided identity assertions are not guaranteed >>> to >>> persist end-to-end is one key reason for the ongoing work in the >>> STIR WG. >>> The work there and elsewhere shows that it's fairly widely >>> acknowledged >>> that 4474 has not seen the deployment that was hoped for when it was >>> specified. Making its use a normative requirement here again seems >>> out of >>> sync with deployment reality. I would encourage you to review >>> draft-ietf-stir-rfc4474bis and reconsider what security mechanism >>> should >>> form the basis of the recommendations in this draft. >> >> There was discussion that a b2bua could terminate dtls-srtp if it >> provided an identity service, or acted in collusion with an identity >> service. My understanding is that the authors felt that delving into >> special cases where it might be "okay" for a b2bua to terminate >> dtls-srtp would add too much complexity to the point. (There's also >> the fact that dtls-srtp says you SHOULD use 4474, not MUST). > > If you look at this through the lens of 4474 deployment, it isn’t > really a special case, since neither case is in much use. I think the > complexity arises because the document is trying to make > recommendations. If it were to just describe the implications of what > would happen if B2BUAs in various scenarios encountered 4474 > signatures, then at least it could be made to be a correct description > of the behaviors one could theoretically encounter. > >> >> I tend to agree on the complexity--but I think it would make sense to >> clarify this to say that a b2bua that is not also providing an >> identity service is likely to break things. > > I think the underlying problem here gets back to the question about > whether this draft is making recommendations that anyone implementing > a B2BUA is likely to follow, or whether it is making recommendations > for the sake of writing them down and attaching an RFC number to them. > Because if it’s the former, it doesn’t make much sense for the > basis of this to be 4474. > >> >> As far as 4474bis is concerned--they originally referenced 4474bis, >> and I suggested that they not do so. My reasoning was that both 4474 >> and 4474bis (as written at that time) protected the fingerprint, >> which was the important bit here--and that since 4474bis was expected >> to obsolete 4474, a reference to 4474 would "self upgrade", so to >> speak. Do you disagree with that? (But to be totally honest, my >> concern was entirely about avoiding an extended stay in MISSREF land. >> Maybe that's not as big of a concern now?) > > I think when we’re at the point where we spun up a working group for > the purpose of replacing the original document, we’re better off not > normatively requiring use of the original. But again here I question > whether it’s appropriate for this document, which is nominally about > B2BUA behavior, to be putting any requirements on endpoints in the > first place. The document shouldn't be making recommendations (especially normative ones) about client behavior here. (I thought we had taken that out, but obviously missed an instance.) > > The STIR work is advancing and there is demand for it to get done, so > I wouldn’t be worried about 4474bis not finishing. I'm confident it will get done. At the time I recommended 4474 rather than 4474bis, I was concerned it might take a while. I feel better about that after Yokohama :-). But in any case, we should think about wether this can be demoted to an informational reference, if we remove the attempt to specify endpoint behavior. Thanks! Ben. From nobody Wed Dec 2 20:28:51 2015 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 6C6931B2FEA; Wed, 2 Dec 2015 20:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UkmD7jh3QHXe; Wed, 2 Dec 2015 20:28:45 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657F81B2FEB; Wed, 2 Dec 2015 20:28:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8872; q=dns/txt; s=iport; t=1449116925; x=1450326525; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=KtafC0ib34YfNkm5PSq7lMgfIJIT/EQ9Ln5WBnQQobI=; b=lSn6vRf0QGGQHdgrPQat0ShnMl8rFFbLmSxAKN0/TXawjO4NptOz/ljZ NlBidDyXGto07f+L2m6krIPckC/ICAKCoJHMwxY+kXVzmLxVEAX6vU0s0 eYSa4qfTzLBev3mggn0XjNYCoAqlrk3CqLYfBPqZtHEBW0Zr9AS84Tsms w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DyAQD6w19W/5pdJa1VCRkBAQEBDwEBA?= =?us-ascii?q?QGDCoFBBrtDghkBDYFihg4CHIEoOBQBAQEBAQEBgQqENAEBAQECASMRRQwGAQg?= =?us-ascii?q?RBAEBAQICIwMCBDAUAQgJAQQBDQUIiB8Ir3aRIAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARiBAYVUhH2EMRGDNYFEBYdPhViJOQGNMoFikjiEaoNxAR8BAUKCRIFAcoR?= =?us-ascii?q?lgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,376,1444694400"; d="scan'208";a="214525733" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2015 04:28:44 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tB34Sink008157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 04:28:44 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 22:28:43 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.000; Wed, 2 Dec 2015 22:28:43 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Ben Campbell , Alissa Cooper Thread-Topic: Alissa Cooper's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) Thread-Index: AdEtgxQzzgZLzyRUSrWmpUQBsJwk6g== Date: Thu, 3 Dec 2015 04:28:43 +0000 Message-ID: <2d0efa42bd154357aec72ecf83d5c80c@XCH-RCD-017.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.69.199] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" , "straw@ietf.org" , IESG , "straw-chairs@ietf.org" , "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, 03 Dec 2015 04:28:47 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCZW4gQ2FtcGJlbGwgW21haWx0 bzpiZW5Abm9zdHJ1bS5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwMywgMjAxNSA0 OjU2IEFNDQo+IFRvOiBBbGlzc2EgQ29vcGVyDQo+IENjOiBkcmFmdC1pZXRmLXN0cmF3LWIyYnVh LWR0bHMtc3J0cEBpZXRmLm9yZzsNCj4gY2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tOyBJ RVNHOyBzdHJhdy1jaGFpcnNAaWV0Zi5vcmc7DQo+IHN0cmF3QGlldGYub3JnDQo+IFN1YmplY3Q6 IFJlOiBBbGlzc2EgQ29vcGVyJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXN0cmF3LWIyYnVhLWR0 bHMtc3J0cC0wOToNCj4gKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNCj4gDQo+IE9uIDIgRGVj IDIwMTUsIGF0IDk6MTcsIEFsaXNzYSBDb29wZXIgd3JvdGU6DQo+IA0KPiA+PiBPbiBOb3YgMzAs IDIwMTUsIGF0IDk6MzEgUE0sIEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPiB3cm90ZToN Cj4gPj4NCj4gPj4gQSBjb3VwbGUgb2YgcXVpY2sgY29tbWVudHMgb24geW91ciBkaXNjdXNzIGl0 ZW0gMyBiZWxvdy4gKEkgd2lsbA0KPiA+PiBsZWF2ZSBpdCB0byB0aGUgYXV0aG9ycyB0byByZXNw b25kIHRvIHRoZSByZXN0KQ0KPiA+Pg0KPiA+PiBPbiAzMCBOb3YgMjAxNSwgYXQgMjI6NTgsIEFs aXNzYSBDb29wZXIgd3JvdGU6DQo+ID4+DQo+ID4+PiBBbGlzc2EgQ29vcGVyIGhhcyBlbnRlcmVk IHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiA+Pj4gZHJhZnQtaWV0Zi1zdHJh dy1iMmJ1YS1kdGxzLXNydHAtMDk6IERpc2N1c3MNCj4gPj4+DQo+IA0KPiBbLi4uXQ0KPiANCj4g Pj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4gPj4+IERJU0NVU1M6DQo+ID4+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+Pj4gLS0NCj4gDQo+IFsuLi5dDQo+IA0KPiA+Pj4NCj4gPj4+ICgzKQ0K PiA+Pj4gVGhlIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIFJGQyA0NDc0IG1lY2hhbmlzbSBzZWVt cyB0byBjb250cmFkaWN0DQo+ID4+PiB0aGUgd2F5IHRoZSBtZWNoYW5pc20gaXMgYWN0dWFsbHkg c3BlY2lmaWVkLiBUaGUgNDQ3NCBtZWNoYW5pc20gd2FzDQo+ID4+PiBkZXNpZ25lZCBzdWNoIHRo YXQgaW50ZXJtZWRpYXJpZXMgd291bGQgYmUgYWJsZSB0byBwcm92aWRlDQo+ID4+PiBzaWduYXR1 cmVzIG9uIGJlaGFsZiBvZiB1c2VycyAoZS5nLiwgc2VlIFJGQyA0NDc0IFNlY3Rpb24gMywgIlRo aXMNCj4gPj4+IHNwZWNpZmljYXRpb24gYWxsb3dzIGVpdGhlciBhIHVzZXIgYWdlbnQgb3IgYSBw cm94eSBzZXJ2ZXIgdG8NCj4gPj4+IHByb3ZpZGUgaWRlbnRpdHkgc2VydmljZXMgYW5kIHRvIHZl cmlmeSBpZGVudGl0aWVzIC4uLiBpbiB0aGUNCj4gPj4+IGluaXRpYWwgdXNlIG9mIHRoaXMgbWVj aGFuaXNtLCBpdCBpcyBsaWtlbHkgdGhhdCBpbnRlcm1lZGlhcmllcyB3aWxsDQo+ID4+PiBpbnN0 YW50aWF0ZSB0aGUgYXV0aGVudGljYXRpb24gc2VydmljZSByb2xlIikuDQo+ID4+PiBTbyB0aGUN Cj4gPj4+IGNsYWltIHRoYXQgdGVybWluYXRpbmcgRFRMUy1TUlRQIHdvdWxkIGNhdXNlIDQ0NzQg aWRlbnRpdHkgYW5kDQo+ID4+PiBpbnRlZ3JpdHkgY2hlY2tzIHRvIGZhaWwgaXNuJ3QgdHJ1ZSwg YmVjYXVzZSBhbiBTQkMgY2FuIGRlY3J5cHQgYW5kDQo+ID4+PiByZS1zaWduIHRoZSByZXF1ZXN0 IGl0c2VsZi4gQSBCMkJVQSB0aGF0IGJyaWRnZXMgdHdvIGFkbWluaXN0cmF0aXZlDQo+ID4+PiBk b21haW5zIGNhbiBjaGVjayB0aGUgdmFsaWRpdHkgb2YgdGhlIHNpZ25hdHVyZSBpbiB0aGUgZG9t YWluIG9uIG9uDQo+ID4+PiBzaWRlIGFzIGF1dGhvcml6YXRpb24gdG8gZm9ybSBhIG5ldyBzaWdu YXR1cmUgdGhhdCBpcyB2YWxpZCBpbiB0aGUNCj4gPj4+IGRvbWFpbiBpbiB0aGUgb3RoZXIgc2lk ZS4NCj4gPj4+DQo+ID4+PiBUaGUgZmFjdCB0aGF0IHVzZXItcHJvdmlkZWQgaWRlbnRpdHkgYXNz ZXJ0aW9ucyBhcmUgbm90IGd1YXJhbnRlZWQNCj4gPj4+IHRvIHBlcnNpc3QgZW5kLXRvLWVuZCBp cyBvbmUga2V5IHJlYXNvbiBmb3IgdGhlIG9uZ29pbmcgd29yayBpbiB0aGUNCj4gPj4+IFNUSVIg V0cuDQo+ID4+PiBUaGUgd29yayB0aGVyZSBhbmQgZWxzZXdoZXJlIHNob3dzIHRoYXQgaXQncyBm YWlybHkgd2lkZWx5DQo+ID4+PiBhY2tub3dsZWRnZWQgdGhhdCA0NDc0IGhhcyBub3Qgc2VlbiB0 aGUgZGVwbG95bWVudCB0aGF0IHdhcyBob3BlZA0KPiA+Pj4gZm9yIHdoZW4gaXQgd2FzIHNwZWNp ZmllZC4gTWFraW5nIGl0cyB1c2UgYSBub3JtYXRpdmUgcmVxdWlyZW1lbnQNCj4gPj4+IGhlcmUg YWdhaW4gc2VlbXMgb3V0IG9mIHN5bmMgd2l0aCBkZXBsb3ltZW50IHJlYWxpdHkuIEkgd291bGQN Cj4gPj4+IGVuY291cmFnZSB5b3UgdG8gcmV2aWV3IGRyYWZ0LWlldGYtc3Rpci1yZmM0NDc0Ymlz IGFuZCByZWNvbnNpZGVyDQo+ID4+PiB3aGF0IHNlY3VyaXR5IG1lY2hhbmlzbSBzaG91bGQgZm9y bSB0aGUgYmFzaXMgb2YgdGhlIHJlY29tbWVuZGF0aW9ucw0KPiA+Pj4gaW4gdGhpcyBkcmFmdC4N Cj4gPj4NCj4gPj4gVGhlcmUgd2FzIGRpc2N1c3Npb24gdGhhdCBhIGIyYnVhIGNvdWxkIHRlcm1p bmF0ZSBkdGxzLXNydHAgaWYgaXQNCj4gPj4gcHJvdmlkZWQgYW4gaWRlbnRpdHkgc2VydmljZSwg b3IgYWN0ZWQgaW4gY29sbHVzaW9uIHdpdGggYW4gaWRlbnRpdHkNCj4gPj4gc2VydmljZS4gIE15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgYXV0aG9ycyBmZWx0IHRoYXQgZGVsdmluZyBpbnRv DQo+ID4+IHNwZWNpYWwgY2FzZXMgd2hlcmUgaXQgbWlnaHQgYmUgIm9rYXkiIGZvciBhIGIyYnVh IHRvIHRlcm1pbmF0ZQ0KPiA+PiBkdGxzLXNydHAgd291bGQgYWRkIHRvbyBtdWNoIGNvbXBsZXhp dHkgdG8gdGhlIHBvaW50LiAoVGhlcmUncyBhbHNvDQo+ID4+IHRoZSBmYWN0IHRoYXQgZHRscy1z cnRwIHNheXMgeW91IFNIT1VMRCB1c2UgNDQ3NCwgbm90IE1VU1QpLg0KPiA+DQo+ID4gSWYgeW91 IGxvb2sgYXQgdGhpcyB0aHJvdWdoIHRoZSBsZW5zIG9mIDQ0NzQgZGVwbG95bWVudCwgaXQgaXNu 4oCZdA0KPiA+IHJlYWxseSBhIHNwZWNpYWwgY2FzZSwgc2luY2UgbmVpdGhlciBjYXNlIGlzIGlu IG11Y2ggdXNlLiBJIHRoaW5rIHRoZQ0KPiA+IGNvbXBsZXhpdHkgYXJpc2VzIGJlY2F1c2UgdGhl IGRvY3VtZW50IGlzIHRyeWluZyB0byBtYWtlDQo+ID4gcmVjb21tZW5kYXRpb25zLiBJZiBpdCB3 ZXJlIHRvIGp1c3QgZGVzY3JpYmUgdGhlIGltcGxpY2F0aW9ucyBvZiB3aGF0DQo+ID4gd291bGQg aGFwcGVuIGlmIEIyQlVBcyBpbiB2YXJpb3VzIHNjZW5hcmlvcyBlbmNvdW50ZXJlZCA0NDc0DQo+ ID4gc2lnbmF0dXJlcywgdGhlbiBhdCBsZWFzdCBpdCBjb3VsZCBiZSBtYWRlIHRvIGJlIGEgY29y cmVjdCBkZXNjcmlwdGlvbg0KPiA+IG9mIHRoZSBiZWhhdmlvcnMgb25lIGNvdWxkIHRoZW9yZXRp Y2FsbHkgZW5jb3VudGVyLg0KDQpZZXMsIHRoZSBkcmFmdCBhbHJlYWR5IGRpc2N1c3NlcyB0aGF0 IEIyQlVBIG11c3Qgbm90IHRhbXBlciB0aGUgNDQ3NCBzaWduYXR1cmVzLCBvdGhlcndpc2UgdGhl IGlkZW50aXR5IGludGVncmF0aW9uIHByb2NlZHVyZSB3aWxsIGZhaWwuIFdlIGNhbiB1cGRhdGUg dGhlIGRyYWZ0IHRvIHBvaW50IHRvIDQ0NzRiaXMgKEluIGZhY3QgdGhlIGRvYyB3YXMgcG9pbnRp bmcgdG8gNDQ3NGJpcyBpbiB0aGUgcHJldmlvdXMgdmVyc2lvbnMpLg0KDQo+ID4NCj4gPj4NCj4g Pj4gSSB0ZW5kIHRvIGFncmVlIG9uIHRoZSBjb21wbGV4aXR5LS1idXQgSSB0aGluayBpdCB3b3Vs ZCBtYWtlIHNlbnNlIHRvDQo+ID4+IGNsYXJpZnkgdGhpcyB0byBzYXkgdGhhdCBhIGIyYnVhIHRo YXQgaXMgbm90IGFsc28gcHJvdmlkaW5nIGFuDQo+ID4+IGlkZW50aXR5IHNlcnZpY2UgaXMgbGlr ZWx5IHRvIGJyZWFrIHRoaW5ncy4NCj4gPg0KPiA+IEkgdGhpbmsgdGhlIHVuZGVybHlpbmcgcHJv YmxlbSBoZXJlIGdldHMgYmFjayB0byB0aGUgcXVlc3Rpb24gYWJvdXQNCj4gPiB3aGV0aGVyIHRo aXMgZHJhZnQgaXMgbWFraW5nIHJlY29tbWVuZGF0aW9ucyB0aGF0IGFueW9uZSBpbXBsZW1lbnRp bmcNCj4gPiBhIEIyQlVBIGlzIGxpa2VseSB0byBmb2xsb3csIG9yIHdoZXRoZXIgaXQgaXMgbWFr aW5nIHJlY29tbWVuZGF0aW9ucw0KPiA+IGZvciB0aGUgc2FrZSBvZiB3cml0aW5nIHRoZW0gZG93 biBhbmQgYXR0YWNoaW5nIGFuIFJGQyBudW1iZXIgdG8gdGhlbS4NCj4gPiBCZWNhdXNlIGlmIGl0 4oCZcyB0aGUgZm9ybWVyLCBpdCBkb2VzbuKAmXQgbWFrZSBtdWNoIHNlbnNlIGZvciB0aGUgYmFz aXMNCj4gPiBvZiB0aGlzIHRvIGJlIDQ0NzQuDQoNCkl0J3MgbWFraW5nIHJlY29tbWVuZGF0aW9u cyBmb3IgdGhlIGltcGxlbWVudGVycyBvZiBCMkJVQSB0byBmb2xsb3cuDQoNCj4gPg0KPiA+Pg0K PiA+PiBBcyBmYXIgYXMgNDQ3NGJpcyBpcyBjb25jZXJuZWQtLXRoZXkgb3JpZ2luYWxseSByZWZl cmVuY2VkIDQ0NzRiaXMsDQo+ID4+IGFuZCBJIHN1Z2dlc3RlZCB0aGF0IHRoZXkgbm90IGRvIHNv LiBNeSByZWFzb25pbmcgd2FzIHRoYXQgYm90aCA0NDc0DQo+ID4+IGFuZCA0NDc0YmlzIChhcyB3 cml0dGVuIGF0IHRoYXQgdGltZSkgcHJvdGVjdGVkIHRoZSBmaW5nZXJwcmludCwNCj4gPj4gd2hp Y2ggd2FzIHRoZSBpbXBvcnRhbnQgYml0IGhlcmUtLWFuZCB0aGF0IHNpbmNlIDQ0NzRiaXMgd2Fz IGV4cGVjdGVkDQo+ID4+IHRvIG9ic29sZXRlIDQ0NzQsIGEgcmVmZXJlbmNlIHRvIDQ0NzQgd291 bGQgInNlbGYgdXBncmFkZSIsIHNvIHRvDQo+ID4+IHNwZWFrLiBEbyB5b3UgZGlzYWdyZWUgd2l0 aCB0aGF0PyAoQnV0IHRvIGJlIHRvdGFsbHkgaG9uZXN0LCBteQ0KPiA+PiBjb25jZXJuIHdhcyBl bnRpcmVseSBhYm91dCBhdm9pZGluZyBhbiBleHRlbmRlZCBzdGF5IGluIE1JU1NSRUYgbGFuZC4N Cj4gPj4gTWF5YmUgdGhhdCdzIG5vdCBhcyBiaWcgb2YgYSBjb25jZXJuIG5vdz8pDQo+ID4NCj4g PiBJIHRoaW5rIHdoZW4gd2XigJlyZSBhdCB0aGUgcG9pbnQgd2hlcmUgd2Ugc3B1biB1cCBhIHdv cmtpbmcgZ3JvdXAgZm9yDQo+ID4gdGhlIHB1cnBvc2Ugb2YgcmVwbGFjaW5nIHRoZSBvcmlnaW5h bCBkb2N1bWVudCwgd2XigJlyZSBiZXR0ZXIgb2ZmIG5vdA0KPiA+IG5vcm1hdGl2ZWx5IHJlcXVp cmluZyB1c2Ugb2YgdGhlIG9yaWdpbmFsLiBCdXQgYWdhaW4gaGVyZSBJIHF1ZXN0aW9uDQo+ID4g d2hldGhlciBpdOKAmXMgYXBwcm9wcmlhdGUgZm9yIHRoaXMgZG9jdW1lbnQsIHdoaWNoIGlzIG5v bWluYWxseSBhYm91dA0KPiA+IEIyQlVBIGJlaGF2aW9yLCB0byBiZSBwdXR0aW5nIGFueSByZXF1 aXJlbWVudHMgb24gZW5kcG9pbnRzIGluIHRoZQ0KPiA+IGZpcnN0IHBsYWNlLg0KPiANCj4gVGhl IGRvY3VtZW50IHNob3VsZG4ndCBiZSBtYWtpbmcgcmVjb21tZW5kYXRpb25zIChlc3BlY2lhbGx5 IG5vcm1hdGl2ZQ0KPiBvbmVzKSBhYm91dCBjbGllbnQgYmVoYXZpb3IgaGVyZS4gDQoNClllcy4N Cg0KPiAoSSB0aG91Z2h0IHdlIGhhZCB0YWtlbiB0aGF0IG91dCwgYnV0DQo+IG9idmlvdXNseSBt aXNzZWQgYW4gaW5zdGFuY2UuKQ0KDQpPb3BzLiBXZSBtaXNzZWQgdXBkYXRpbmcgdGhlIFNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gdG8gcmVtb3ZlIHRoZSBub3JtYXRpdmUgcmVmZXJl bmNlLCB3aWxsIGNvcnJlY3QgaW4gdGhlIG5leHQgdXBkYXRlLg0KDQo+IA0KPiA+DQo+ID4gVGhl IFNUSVIgd29yayBpcyBhZHZhbmNpbmcgYW5kIHRoZXJlIGlzIGRlbWFuZCBmb3IgaXQgdG8gZ2V0 IGRvbmUsIHNvDQo+ID4gSSB3b3VsZG7igJl0IGJlIHdvcnJpZWQgYWJvdXQgNDQ3NGJpcyBub3Qg ZmluaXNoaW5nLg0KPiANCj4gSSdtIGNvbmZpZGVudCBpdCB3aWxsIGdldCBkb25lLiBBdCB0aGUg dGltZSBJIHJlY29tbWVuZGVkIDQ0NzQgcmF0aGVyDQo+IHRoYW4gNDQ3NGJpcywgSSB3YXMgY29u Y2VybmVkIGl0IG1pZ2h0IHRha2UgYSB3aGlsZS4gSSBmZWVsIGJldHRlciBhYm91dA0KPiB0aGF0 IGFmdGVyIFlva29oYW1hIDotKS4gQnV0IGluIGFueSBjYXNlLCB3ZSBzaG91bGQgdGhpbmsgYWJv dXQgd2V0aGVyDQo+IHRoaXMgY2FuIGJlIGRlbW90ZWQgdG8gYW4gaW5mb3JtYXRpb25hbCByZWZl cmVuY2UsIGlmIHdlIHJlbW92ZSB0aGUNCj4gYXR0ZW1wdCB0byBzcGVjaWZ5IGVuZHBvaW50IGJl aGF2aW9yLg0KDQpXb3JrcyBmb3IgbWUsIHRoaXMgZHJhZnQgY2FuIHBvaW50IHRvIDQ0NzRiaXMg aW5zdGVhZCBvZiA0NDc0IGFuZCA0NDc0YmlzIGNhbiBiZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5j ZS4NCg0KLVRpcnUNCg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gQmVuLg0K From nobody Wed Dec 2 20:38:06 2015 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 3DA9D1B3013; Wed, 2 Dec 2015 20:38:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151203043805.17795.2459.idtracker@ietfa.amsl.com> Date: Wed, 02 Dec 2015 20:38:05 -0800 Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, straw@ietf.org, straw-chairs@ietf.org, christer.holmberg@ericsson.com Subject: [straw] Barry Leiba's No Objection on draft-ietf-straw-b2bua-dtls-srtp-09: (with COMMENT) 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: Thu, 03 Dec 2015 04:38:05 -0000 Barry Leiba has entered the following ballot position for draft-ietf-straw-b2bua-dtls-srtp-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-straw-b2bua-dtls-srtp/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support at least some of Alissa's and Stephen's DISCUSS points. In particular, I'm not fully in agreement with Alissa on her point 1: We do sometimes (and should) make normative statements about how protocols should work and should be used, even with knowledge that those statements may (will) be ignored. Sometimes it's to keep the protocol tight; sometimes it's to provide a lever ("The IETF has a standard that says that what you're doing is wrong!"). Because of that, Alissa's point 2 is particularly important: We have to stop the general practice of watering down normative statement in protocols as a way of mollifying people who don't like them. If the right thing is to say "MUST do X", we should not say "SHOULD do X" because we know that some implementations don't and won't do X. In particular, here, if there's any value in this, it's necessary to be strict and clear to expose that value. From nobody Wed Dec 2 21:27:35 2015 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 878D91B30B8 for ; Wed, 2 Dec 2015 21:27:34 -0800 (PST) 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=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 R92z6x39F--R for ; Wed, 2 Dec 2015 21:27:32 -0800 (PST) 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 C08B71B30B7 for ; Wed, 2 Dec 2015 21:27:32 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DC1CF2075D for ; Thu, 3 Dec 2015 00:17:47 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 03 Dec 2015 00:17:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=uWD5sRuez6oPF560ZYyPUkHcpKc=; b=rSL8VX bi+yAynQ9AAZlP5I1qrTN4UvDuc5T0RLkJ3k4c+AlWsk8RMXySFT4qmqI76S+O/9 wlT0Ew9Ed3s23p72QPcwmckamX9X6Ea9TjR5CIoQWE5khNUjSHJ8sLet/NFm2fVq QzgQr1lw8ES3mCYkmJ61UYC1RtJoMj4RseZXA= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=uWD5sRuez6oPF56 0ZYyPUkHcpKc=; b=kghXDpV1NaD2vQ9dHOb14Uc/gzY5xAQ7ILvR0BFMr7eMEle AWTfrm6od9TNEVuRuaGJDEGmelqZ07fHxDB+L93HMMq2hW2Kanh/HhHJE4oubPoi MLdudmnzACsJlRPiL9k3QkktbesYRiQZvcKo9UOWTmap/7gZhRtpy8UjHSkc= X-Sasl-enc: RiLhQNYJ8URJfYIEiDrwhwdVJBRqRLUeeScpfIEWFPHJ 1449119867 Received: from sjc-alcoop-8815.cisco.com (unknown [128.107.241.176]) by mail.messagingengine.com (Postfix) with ESMTPA id 71E72C016DB; Thu, 3 Dec 2015 00:17:46 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 2 Dec 2015 21:17:45 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> To: "Ram Mohan R (rmohanr)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ben Campbell , "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" , "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, 03 Dec 2015 05:27:34 -0000 > On Dec 2, 2015, at 8:14 AM, Ram Mohan R (rmohanr) = wrote: >>=20 >>=20 >> On 30 Nov 2015, at 22:58, Alissa Cooper wrote: >>=20 >>> Alissa Cooper has entered the following ballot position for >>> draft-ietf-straw-b2bua-dtls-srtp-09: Discuss >>>=20 >>> 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.) >>>=20 >>>=20 >>> Please refer to=20 >>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>>=20 >>>=20 >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ >>>=20 >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>> (1) >>> I have a fairly fundamental concern about this document that I'd = like >>> to >>> discuss. My impression is that most B2BUAs in the market today that >>> handle DTLS-SRTP do so with the explicit purpose of accessing the >>> media. >>> That is, if I need a box that doesn't access the media I use a SIP >>> proxy, >>> and if I need one that does access it I use a B2BUA. I realize that >>> there >>> are more flavors of B2BUA defined in RFC 7092, but in terms of how >>> real >>> SBCs work, it seems to me that they break DTLS-SRTP intentionally if >>> they >>> do so at all. >=20 > I am aware of B2BUAs that pass-through SRTP (in this case DTLS-SRTP) = end to > end as well. In several deployments B2BUAs/SBCs are used for address > hiding / media latching (as described in > https://tools.ietf.org/html/rfc7362). > In these scenarios the B2BUAs will be in media path as well but it = just > changes the UDP/IP headers and relay the UDP payload as is with out > inspecting/modifying payload. >=20 >=20 >>>=20 >>> If that's the case, the question then arises about the value of >>> writing >>> down normative recommendations that are more than likely to be >>> ignored. >>> Perhaps this document would have made more sense as informational, >>> offering a non-normative explanation of what a B2BUA should do if it >>> does >>> not want to break e2e security. Even as an informational document = it's >>> still not obvious to me that there is much at all to say here for >>> media-aware B2BUAs that isn't entirely reductive -- "don't terminate >>> DTLS-SRTP if you don't want to break DTLS-SRTP" -- but at least as = an >>> informational document it wouldn't be suggesting normative >>> requirements >>> that are out of sync with real deployments. >>>=20 >>> Could you articulate the reasons why someone would build a B2BUA = that >>> follows the recommendations in this draft? >=20 > 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=E2=80=99t that make the = 3.1.2 guidance essentially no-ops? Alissa >=20 >=20 >>> I note that the draft says >>> nothing about using a TURN server as a media relay, which seems like >>> it >>> would be more common than using a B2BUA for the same purpose. >=20 > Not all endpoints support ICE yet which is one of the reasons > B2BUAs are used for simple media latching as well (described in = RFC7362). >=20 >=20 >>> Aren't >>> B2BUAs typically deployed *because* they are media-aware? >=20 > They can be media-aware or can just switch the media with out being = aware > of media as well. >=20 > Regards, > Ram >=20 >>>=20 >>> (2) >>> Taking into account the above comment, I think 3.1.2.1 and 3.1.2.2 = are >>> problematic. 3.1.2.1 creates a normative SHOULD NOT-level = requirement >>> for >>> inspection B2BUAs without explaining what the exception cases are, = and >>> 3.1.2.2 creates no normative requirements for modification B2BUAs. >>> It's >>> not even clear to me why the distinction is being drawn between the >>> two >>> kinds of B2BUAs if the bottom line is that in both cases the >>> recommendation is to not terminate DTLS-SRTP. But this brings us = back >>> to >>> the above comment. The problem here seems to be that what the WG and >>> the >>> IETF would want to say here is that B2BUAs MUST NOT terminate >>> DTLS-SRTP >>> to man-in-the-middle the media, but that is what B2BUAs generally = do, >>> so >>> instead the text waffles and the recommendations are watered down = and >>> unclear. >>>=20 >>> (3) >>> The characterization of the RFC 4474 mechanism seems to contradict = the >>> way the mechanism is actually specified. The 4474 mechanism was >>> designed >>> such that intermediaries would be able to provide signatures on = behalf >>> of >>> users (e.g., see RFC 4474 Section 3, "This specification allows = either >>> a >>> user agent or a proxy server to provide identity services and to >>> verify >>> identities ... in the initial use of this mechanism, it is likely = that >>> intermediaries will instantiate the authentication service role"). = So >>> the >>> claim that terminating DTLS-SRTP would cause 4474 identity and >>> integrity >>> checks to fail isn't true, because an SBC can decrypt and re-sign = the >>> request itself. A B2BUA that bridges two administrative domains can >>> check >>> the validity of the signature in the domain on on side as >>> authorization >>> to form a new signature that is valid in the domain in the other = side. >>>=20 >>> The fact that user-provided identity assertions are not guaranteed = to >>> persist end-to-end is one key reason for the ongoing work in the = STIR >>> WG. >>> The work there and elsewhere shows that it's fairly widely >>> acknowledged >>> that 4474 has not seen the deployment that was hoped for when it was >>> specified. Making its use a normative requirement here again seems = out >>> of >>> sync with deployment reality. I would encourage you to review >>> draft-ietf-stir-rfc4474bis and reconsider what security mechanism >>> should >>> form the basis of the recommendations in this draft. >>>=20 >>>=20 >>> = ---------------------------------------------------------------------- >>> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> Section 3.1.1: >>>=20 >>> Is there anything new being specified here that isn't already >>> specified >>> in other SIP documents? >>>=20 >>> Section 3.2: >>>=20 >>> Is this saying anything that RFC 5763 doesn't already say? >=20 From nobody Wed Dec 2 21:36:39 2015 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 B3D4F1B3131; Wed, 2 Dec 2015 21:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 l-q21Zr-sjnP; Wed, 2 Dec 2015 21:36:36 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1304E1B312B; Wed, 2 Dec 2015 21:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7320; q=dns/txt; s=iport; t=1449120996; x=1450330596; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=yFIJ4LVaxw4OM5VJEQKuB4z1k5ZyUuzu/I84WseIgp0=; b=F4Uk2pKFpjM1IkWY96puNP8KUEUoXrf1fNoBJT38B9nvis11F2UI7B0d 0E8JJfH2aXN5GbBe1gXZMmhNsJW+bPLdzhcNbx0ZQ6GubtpUX2dsZEDfT zoIJkZzYrg4DbgLbYE2EbNyDVqhGxnv1YjN+IVQpITl7HTBsXWx4nNP/B E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFBQAb1F9W/4MNJK1VCRkBAQEBDwEBA?= =?us-ascii?q?QGDClNuBr1qgVsHFwqFbQKBSToSAQEBAQEBAYEKhDQBAQEBAgEBAQEaHTQLBQc?= =?us-ascii?q?GAQgRBAEBHwUELgsUCQkBBAENBQiIHwgNwR8BAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEUBIZVhH2EKgcJAgEFS4QuBYdPiyaDawGFK4gHgWKEQ4Mmik+IWwEoDC+CER0?= =?us-ascii?q?WgUByAYRkgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,376,1444694400"; d="scan'208";a="50202060" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2015 05:36:34 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tB35aYHE025193 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2015 05:36:34 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 2 Dec 2015 23:36:34 -0600 Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1104.000; Wed, 2 Dec 2015 23:36:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Stephen Farrell , The IESG Thread-Topic: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-dtls-srtp-09: (with DISCUSS and COMMENT) Thread-Index: AdEtjI7DRpb0DVv0RhC7hOnbeCeYJQ== Date: Thu, 3 Dec 2015 05:36:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.69.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" , "christer.holmberg@ericsson.com" , "straw@ietf.org" , "straw-chairs@ietf.org" Subject: Re: [straw] Stephen Farrell'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, 03 Dec 2015 05:36:38 -0000 Hi Stephen, Thanks for the comments, Please see inline > -----Original Message----- > From: straw [mailto:straw-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Wednesday, December 02, 2015 5:00 AM > To: The IESG > Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org; straw@ietf.org; straw- > chairs@ietf.org; christer.holmberg@ericsson.com > Subject: [straw] Stephen Farrell's Discuss on draft-ietf-straw-b2bua-dtls= -srtp- > 09: (with DISCUSS and COMMENT) >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-straw-b2bua-dtls-srtp-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-straw-b2bua-dtls-srtp/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 >=20 > I wonder if you've gotten wrapped around the axle here knowing that we > won't standardise a (D)TLS MitM, but yet trying to describe things that > basically are often deployed as MitMs. Anyway, while I do agree with Ali= ssa's > discuss, I also have some additional points to raise, some of which I thi= nk > came up when we had some mail exchanges about an earlier version of this > draft back in January of this year. >=20 > (1) Alissa is correct that the unqualified SHOULD NOT "terminate" > DTLS is insufficient, but in addition to her call for qualification of th= at, (or I > guess moving to a MUST NOT,) I would like to chat about the consequences > should one (for whatever reason) ignore that SHOULD NOT. Whether or not > this discuss point is worth talking about depends on how Alissa's discuss= on > this is resolved. It seems to me (as I said back in January) that keepin= g the > SHOULD NOT would mean that any UA that is able to inter-operate with a > B2BUA that does "terminate" DTLS (because it fits with whatever qualifier= s > you end up adding to the SHOULD NOT) can never ever be confident of the > identity of any DTLS peer (since it has code that lets the call happen > regardless of the DTLS-layer peer identity). I can't see how that wouldn'= t > make the Internet worse, hence the discuss. Agreed, will change to "MUST NOT" >=20 > (2) In the introduction you say "B2BUAs terminating DTLS-SRTP session are > outside the scope of this document." yet if you keep the SHOULD NOT and > don't move that to a MUST NOT (which was an option we discussed back in > Jan, I assume the WG didn't like that?) Will make it normative. > , then you are in fact including those > are within the scope of this document and therefore you would need to > specify how to "terminate" a DTLS or DTLS-SRTP session when one is a B2BU= A > but yet respect RFC2804. I just can't see how one might do that to be ho= nest. >=20 > (3) 3.1.2 says: "There are two types of media-aware relays, those that me= rely > inspect the RTP headers and unencrypted portions of RTCP packets, and > those that inspect and modify the RTP headers and unencrypted portions of > RTCP packets." Logically, those are not the only options, as one can modi= fy > the encrypted portions too. > (Hopefully resulting in the integrity checking causing the packets to be > dropped.) I think this particular lack of clarity does raise to the level= of a > DISCUSS as it's crucial for this document to be clear about not standardi= sing a > MitM. ("Sins of omission" are probably not a good idea here:-) We can add the following text for clarify that if B2BUA acts MitM it will b= e detected by the endpoint: If B2BUA modifies unencrypted or encrypted portions of the RTP or RTCP pack= ets then the integrity check will fail and the packet will be dropped by th= e endpoint. The unencrypted or encrypted portions of the RTP or RTCP packe= ts are integrity protected using the HMAC algorithm negotiated during DTLS = handshake (discussed in section 4.1.2 of [RFC5764]). >=20 > (4) 3.1.2.2 says: "This security and privacy problem can be mitigated by > having different keys for protecting RTP header integrity and encrypting = the > RTP payload. For example, the approach discussed in [I-D.jones-perc- > private-media-reqts] can be used." I have two issues with that. First, wh= ere is > having different keys documented? If only in the draft referenced, then w= hat > is the status of that?=20 Yes, different keys are discussed in [I-D.jones-perc-private-media-reqts] d= raft and it's an individual document.=20 > And secondly, doesn't perc require a KMS to exist?=20 Yup, Perc requires KMS. > In which case I can't see how this specification works for calls between = UAs (via > a B2BUA) where there is no KMS. I think there are both security and inter= op > (and hence also process) issues with what you're saying here. Agreed, will remove all discussions related to Perc and different keys. >=20 > (5) 3.2 says: "the ClientHello message from a B2BUA (acting as DTLS clien= t)" I > don't see how a B2BUA can send it's own ClientHello (as opposed to > forwarding a UA's) unless it is a MitM. Since we do not standardise MitM= (cf. > RFC2804) this text must be wrong or out of place? Yes, it's wrong. We will fix that in the next revision, B2BUA is just forwa= rding the DTLS handshake messages from the UA.=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - I don't see what Figure2 is trying to tell me, though the preceding tex= t is > clear enough. I'd recommend maybe dropping that figure or else making it = a > full ladder diagram of (most of) the messages involved. Figure 2 is added to aid the example of Alice request getting forked. >=20 > - There's a repetition of the "SHOULD NOT" problem that affects my point = (1) > above and Alissa's discuss points in the security considerations when you= say > "Attempting to cover media-aware relay modifying RTP headers and media > termination scenarios involving secure sessions (like DTLS-SRTP) will > inevitably lead to the B2BUA acting as a man-in-the-middle, and hence it = is > RECOMMENDED that B2BUAs do not terminate DTLS-SRTP session." NEW: These B2BUAs MUST NOT terminate DTLS-SRTP session. >=20 > - As with Alissa, I think the reliance on 4474, especially if that is not= deployed, > is odd. It would be bad if that were read as encouragement to not check D= TLS > client/server certs unless one implements 4474. (But this is covered in > Alissa's discuss so is just a comment here.) We will update the draft to point to 4474bis. -Tiru >=20 >=20 > _______________________________________________ > straw mailing list > straw@ietf.org > https://www.ietf.org/mailman/listinfo/straw From nobody Thu Dec 3 12:51:06 2015 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 0529C1AC3F4; Thu, 3 Dec 2015 12:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hpziPD4Q7eJ; Thu, 3 Dec 2015 12:50:57 -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 5AABF1AC405; Thu, 3 Dec 2015 12:50:57 -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 tB3KomWE016462 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Dec 2015 14:50:49 -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: "Barry Leiba" Date: Thu, 03 Dec 2015 14:50:48 -0600 Message-ID: In-Reply-To: <20151203043805.17795.2459.idtracker@ietfa.amsl.com> References: <20151203043805.17795.2459.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, christer.holmberg@ericsson.com, The IESG , straw-chairs@ietf.org, straw@ietf.org Subject: Re: [straw] Barry Leiba's No Objection on draft-ietf-straw-b2bua-dtls-srtp-09: (with 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, 03 Dec 2015 20:50:59 -0000 On 2 Dec 2015, at 22:38, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-straw-b2bua-dtls-srtp-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-straw-b2bua-dtls-srtp/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support at least some of Alissa's and Stephen's DISCUSS points. > > In particular, I'm not fully in agreement with Alissa on her point 1: > We > do sometimes (and should) make normative statements about how > protocols > should work and should be used, even with knowledge that those > statements > may (will) be ignored. Sometimes it's to keep the protocol tight; > sometimes it's to provide a lever ("The IETF has a standard that says > that what you're doing is wrong!"). > > Because of that, Alissa's point 2 is particularly important: We have > to > stop the general practice of watering down normative statement in > protocols as a way of mollifying people who don't like them. If the > right thing is to say "MUST do X", we should not say "SHOULD do X" > because we know that some implementations don't and won't do X. In > particular, here, if there's any value in this, it's necessary to be > strict and clear to expose that value. What do you think about using non-2119 language for this sort of thing? E.d. "If you do/don't do X, the following bad things will happen..."? As an individual, I favor that approach for cases where we want to give people reasons to change behavior, and don't expect the 2119 stick to work. From nobody Thu Dec 3 13:00:30 2015 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 3DEDD1AC42B; Thu, 3 Dec 2015 13:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 K2CxaTMsDdaE; Thu, 3 Dec 2015 13:00:27 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 2D6291AC429; Thu, 3 Dec 2015 13:00:23 -0800 (PST) Received: by vkha189 with SMTP id a189so53410285vkh.2; Thu, 03 Dec 2015 13:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=EzE7S2fgSQ1xkcBTQCl2qUwQVWqcduC9S/siuFic6NM=; b=a0xgid1FHiRM0GyslvVfQ6r+mV2kORkACFL8Da5TPI+i7bUFLCLWlsmxfrsz3V/TQK bM8bSuMyL+dMpblIExJnX03DjDPYw0oSvWfEEOz1LXWcEZDjOXPDU++NzZFsZrLxupvm hNmg/7XtRGRVxyL+UhOVa+DQcIVVoVPXIp/K+XDipiU7UzoJYmN6Su9J/lSZTpL8fEN4 1V9kbuYbse1mUjcEp5zp0NIM+MsDXCnGfrJdkSJ+alXlqhvAQy0M6x1FxYaMqfKHbwE4 nJ2d6B3Ehgn/yYSnQkT1WSJoX0ChbWu23zW0EwoJACuVZAiuOMDQ/jBBFkLQ3/D5RMUd E7Ow== MIME-Version: 1.0 X-Received: by 10.31.140.199 with SMTP id o190mr7570496vkd.63.1449176422343; Thu, 03 Dec 2015 13:00:22 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.31.182.135 with HTTP; Thu, 3 Dec 2015 13:00:22 -0800 (PST) In-Reply-To: References: <20151203043805.17795.2459.idtracker@ietfa.amsl.com> Date: Thu, 3 Dec 2015 16:00:22 -0500 X-Google-Sender-Auth: mBVrMGVxsqM2XaQNtzN4nhPRqY8 Message-ID: From: Barry Leiba To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-straw-b2bua-dtls-srtp@ietf.org, straw@ietf.org, The IESG , straw-chairs@ietf.org, Christer Holmberg Subject: Re: [straw] Barry Leiba's No Objection on draft-ietf-straw-b2bua-dtls-srtp-09: (with 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, 03 Dec 2015 21:00:28 -0000 >> Because of that, Alissa's point 2 is particularly important: We have to >> stop the general practice of watering down normative statement in >> protocols as a way of mollifying people who don't like them. If the >> right thing is to say "MUST do X", we should not say "SHOULD do X" >> because we know that some implementations don't and won't do X. In >> particular, here, if there's any value in this, it's necessary to be >> strict and clear to expose that value. > > What do you think about using non-2119 language for this sort of thing? E.d. > "If you do/don't do X, the following bad things will happen..."? As an > individual, I favor that approach for cases where we want to give people > reasons to change behavior, and don't expect the 2119 stick to work. It depends, I guess, on what the aim is. If the aim is to write an informational document, that's fine -- and then we have to decide whether there's enough value in that. If the aim is to *say* how the protocol should work, then we should write a proper applicability statement with the proper MUSTs and MUST NOTs. As this document is currently written, it looks like it intends to be the latter, but isn't quite there. Barry From nobody Thu Dec 3 13:12:24 2015 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 E1FFF1ACD42; Thu, 3 Dec 2015 13:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 AjMSn-VJE0O5; Thu, 3 Dec 2015 13:12:20 -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 156091ACD35; Thu, 3 Dec 2015 13:12:20 -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 tB3LCBGN018644 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 3 Dec 2015 15:12:12 -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, 03 Dec 2015 15:12:11 -0600 Message-ID: In-Reply-To: References: <20151201045818.23491.19134.idtracker@ietfa.amsl.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, 03 Dec 2015 21:12:21 -0000 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? Thanks! Ben. From nobody Wed Dec 9 10:50:55 2015 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 130301B2CF6 for ; Wed, 9 Dec 2015 10:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 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 1bpRhpjoYUpl for ; Wed, 9 Dec 2015 10:50:52 -0800 (PST) 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 461FC1B2D15 for ; Wed, 9 Dec 2015 10:50:52 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5C8DA213DB for ; Wed, 9 Dec 2015 13:50:51 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Wed, 09 Dec 2015 13:50:51 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=0m1vrQMEwtiRdBXJCT8GAk8lS0M=; b=dkJl2L M8WG9KdzqV5zEuhgK+YOdtoM6Z6OtFI5mtcajSbfs1lItGBjeDBw77FSS5UIb+OW Ee6uCdgTPWcI5JzNel0UkHLf8f5QAYuFzxcOe8WFd/IRtUxp/SSASMe4ptGMNjIU QOUoez395DOSKTxBc0dihnG8kb924yyAudDtg= DKIM-Signature: v=1; a=rsa-sha1; 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-sasl-enc:x-sasl-enc; s=smtpout; bh=0m1vrQMEwtiRdBX JCT8GAk8lS0M=; b=l36DoGU/qzXVBr91IpFgpb/WlCGcHjbXiM8VvJlfUJ1Mx5/ elG0R4yr8V+MqbcTxCbu9RR1VtTIFnm++ooc1n0b4KrzqmW0T4gN45LvQi1czrAR tvpSTFRKt5YqDEHOBm3dYsBAMcgzE/Ex1cUxNFcV/gF8guOTYC8u78z+DePA= X-Sasl-enc: ZkgkA/BzSfWwLGKMwFmA/9UarFpxMcno2VLGe7ET1LH3 1449687051 Received: from dhcp-171-68-20-179.cisco.com (dhcp-171-68-20-179.cisco.com [171.68.20.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 7033EC016D5; Wed, 9 Dec 2015 13:50:50 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 9 Dec 2015 10:50:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1D498CDA-C8B6-4215-A718-7C5302B5CF2D@cooperw.in> References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> To: Ben Campbell X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ram Mohan R , "draft-ietf-straw-b2bua-dtls-srtp@ietf.org" , "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: Wed, 09 Dec 2015 18:50:54 -0000 > On Dec 3, 2015, at 1:12 PM, Ben Campbell wrote: >=20 > On 2 Dec 2015, at 23:17, Alissa Cooper wrote: >=20 >> Could you articulate the reasons why someone would build a B2BUA that >>>>> follows the recommendations in this draft? >>=20 >>=20 >>>=20 >>> B2BUAs used in deployments like the above mentioned scenarios can = use the >>> recommendations in this draft. >>=20 >>=20 >> 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=E2=80=99t that make the = 3.1.2 guidance essentially no-ops? >=20 > Authors: >=20 > 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? >=20 > 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?). >=20 > 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 >=20 > Thanks! >=20 > Ben. From nobody Wed Dec 9 12:25:20 2015 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 2CD381A1B12; Wed, 9 Dec 2015 12:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 G9nmtuCO8YFh; Wed, 9 Dec 2015 12:25:16 -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 004D71A1B30; Wed, 9 Dec 2015 12:25:15 -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 tB9KP5TX037804 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Dec 2015 14:25:06 -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: Wed, 09 Dec 2015 14:25:05 -0600 Message-ID: <01E4CF3B-6C31-4A97-8155-8DC06443A7C2@nostrum.com> In-Reply-To: <1D498CDA-C8B6-4215-A718-7C5302B5CF2D@cooperw.in> References: <20151201045818.23491.19134.idtracker@ietfa.amsl.com> <1D498CDA-C8B6-4215-A718-7C5302B5CF2D@cooperw.in> 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: Wed, 09 Dec 2015 20:25:17 -0000 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.