From fluffy@cisco.com Mon Aug 1 12:48:00 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F10221F8B00 for ; Mon, 1 Aug 2011 12:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.586 X-Spam-Level: X-Spam-Status: No, score=-103.586 tagged_above=-999 required=5 tests=[AWL=-0.987, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmoeBlKKgbmN for ; Mon, 1 Aug 2011 12:48:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0174721F8AC3 for ; Mon, 1 Aug 2011 12:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=659; q=dns/txt; s=iport; t=1312228084; x=1313437684; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Rhp/TnHULkIlk1NfNMpru+WN7DWa86UTmffxuIkHOzg=; b=Nm7onoXq9mAwksGC1DECt87tWVuCmjt6iPsWYLMWr6lLSUSKbVHsNM4Y BojE0niSlTwlKuQMx86idoeVV0MiYYhWOYpc75VlpISZxClu1oYxGZGcd 6cgT+X0B65FARRGec7LI/3fNw2ScmDZ2OJOIOCf7la/FlxyB2uUAmutsM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALcBN06rRDoJ/2dsb2JhbABBp193gUABAQEBAgESASc/EAtGVwY1h0qhWQGeaoVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,301,1309737600"; d="scan'208";a="8548830" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-6.cisco.com with ESMTP; 01 Aug 2011 19:48:03 +0000 Received: from [10.21.72.33] ([10.21.72.33]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p71Jm3IO019328; Mon, 1 Aug 2011 19:48:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 1 Aug 2011 12:48:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 19:48:00 -0000 old reply in my drafts folder ... On May 26, 2011, at 3:46 AM, Christer Holmberg wrote: >=20 > In sessmatch mode the troughput for MSRP packets is line-interface = wirespeed, while in MSRP B2BUA mode the maximum throughput for MSRP = packets is much lower. I'm pretty confused on how dealing with the SIP need to look at the path = or just modify the SDP has an impact on the speed or sending MSRP = packets once the session is set up. Of course I support the goal of = rapid forwarding of MSRP packets once the session is set up. I can't see = any problem with archiving wireline speed forwarding of packets = thorough an MSRP relay.=20 From christer.holmberg@ericsson.com Mon Aug 1 15:19:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789DF1F0C4C for ; Mon, 1 Aug 2011 15:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOAnE93fwAM8 for ; Mon, 1 Aug 2011 15:19:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E5BAE1F0C49 for ; Mon, 1 Aug 2011 15:18:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ea-4e37265a228e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CD.01.09774.A56273E4; Tue, 2 Aug 2011 00:19:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 2 Aug 2011 00:19:06 +0200 From: Christer Holmberg To: Cullen Jennings Date: Tue, 2 Aug 2011 00:19:04 +0200 Thread-Topic: [Simple] Sessmatch products Thread-Index: AcxQg+6qd1J0+X/JT2+sot5fkg4PpQAFJ5nA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB65009A6@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:19:01 -0000 Hi Cullen,=20 >>In sessmatch mode the troughput for MSRP packets is=20 >>line-interface wirespeed, while in MSRP B2BUA mode the=20 >>maximum throughput for MSRP packets is much lower. >=20 >I'm pretty confused on how dealing with the SIP need to look=20 >at the path or just modify the SDP has an impact on the speed=20 >or sending MSRP packets once the session is set up. Of course=20 >I support the goal of rapid forwarding of MSRP packets once=20 >the session is set up. I can't see any problem with=20 >archiving wireline speed forwarding of packets thorough an=20 >MSRP relay.=20 I am not sure I understood you correctly, but yhe impact comes when a middl= ebox needs to modify the MSRP messages (MSRP B2BUA mode), rather than simpl= y forwarding them. Regards, Christer From ben@nostrum.com Mon Aug 1 17:58:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A807521F8C8C for ; Mon, 1 Aug 2011 17:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYBxYYU5y+Lo for ; Mon, 1 Aug 2011 17:58:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 408C821F8C8A for ; Mon, 1 Aug 2011 17:58:40 -0700 (PDT) Received: from [192.168.0.169] (modemcable038.117-70-69.static.videotron.ca [69.70.117.38]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p720wYmV094273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2011 19:58:36 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB65009A6@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 1 Aug 2011 20:58:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CB3D876-29B5-4277-BDF5-96982C749E93@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB65009A6@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 69.70.117.38 is authenticated by a trusted mechanism) Cc: Cullen Jennings , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 00:58:43 -0000 I think the confusion was around the term "MSRP B2BUA". Christer has = agreed to define this in the next revision of the draft. Thanks! Ben. On Aug 1, 2011, at 6:19 PM, Christer Holmberg wrote: >=20 > Hi Cullen,=20 >=20 >>> In sessmatch mode the troughput for MSRP packets is=20 >>> line-interface wirespeed, while in MSRP B2BUA mode the=20 >>> maximum throughput for MSRP packets is much lower. >>=20 >> I'm pretty confused on how dealing with the SIP need to look=20 >> at the path or just modify the SDP has an impact on the speed=20 >> or sending MSRP packets once the session is set up. Of course=20 >> I support the goal of rapid forwarding of MSRP packets once=20 >> the session is set up. I can't see any problem with=20 >> archiving wireline speed forwarding of packets thorough an=20 >> MSRP relay.=20 >=20 > I am not sure I understood you correctly, but yhe impact comes when a = middlebox needs to modify the MSRP messages (MSRP B2BUA mode), rather = than simply forwarding them. >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From fluffy@cisco.com Tue Aug 2 13:26:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1318921F877F for ; Tue, 2 Aug 2011 13:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h7BB+YiR3Dp for ; Tue, 2 Aug 2011 13:26:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5A30921F87C6 for ; Tue, 2 Aug 2011 13:26:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1111; q=dns/txt; s=iport; t=1312316826; x=1313526426; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4yiAPONK1Fz9Kr3v1veyEFZFadl7EZTulCZ8e92m18M=; b=AZAP4V3cQOP9EFOPth0XHtqdwOFkJ9hhU1YgXyjJ+dNh9+ci1joUUK3D 2H2mrWUhvN9jxo0hR/Ade8d4QIFpOdc4oa4hZ/hKn4YDt4x3hSEyxz+AC pP3HBW23RywH4puvOUVE1tFYeAW0ZwyWoiLAMUsfJUTk++ZG/bBtfdvVT M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAI9cOE6rRDoI/2dsb2JhbABCp2h3gUABAQEBAgESASc/EAtGVwY1h0qhNgGeWIVjXwSHWoshkQQ X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="8951409" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2011 20:27:06 +0000 Received: from dhcp-171-68-21-98.cisco.com (dhcp-171-68-21-98.cisco.com [171.68.21.98]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p72KR5c9007434; Tue, 2 Aug 2011 20:27:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB65009A6@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 2 Aug 2011 13:27:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB65009A6@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 20:26:57 -0000 On Aug 1, 2011, at 15:19 , Christer Holmberg wrote: >=20 > Hi Cullen,=20 >=20 >>> In sessmatch mode the troughput for MSRP packets is=20 >>> line-interface wirespeed, while in MSRP B2BUA mode the=20 >>> maximum throughput for MSRP packets is much lower. >>=20 >> I'm pretty confused on how dealing with the SIP need to look=20 >> at the path or just modify the SDP has an impact on the speed=20 >> or sending MSRP packets once the session is set up. Of course=20 >> I support the goal of rapid forwarding of MSRP packets once=20 >> the session is set up. I can't see any problem with=20 >> archiving wireline speed forwarding of packets thorough an=20 >> MSRP relay.=20 >=20 > I am not sure I understood you correctly, but yhe impact comes when a = middlebox needs to modify the MSRP messages (MSRP B2BUA mode), rather = than simply forwarding them. >=20 Well, what modifications are we talking about here and how much time do = we think it will take? I'm not looking for exact measurements or = anything but lets just work through how hard this is to do at wireline = speeds.=20 From ben@nostrum.com Fri Aug 5 13:19:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E65C11E80B2 for ; Fri, 5 Aug 2011 13:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.134 X-Spam-Level: X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zoob6EEy2loI for ; Fri, 5 Aug 2011 13:19:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEAD21F865B for ; Fri, 5 Aug 2011 13:19:22 -0700 (PDT) Received: from dn3-227.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p75KJcmD019880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Aug 2011 15:19:38 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Aug 2011 15:19:37 -0500 Message-Id: <111182F4-D00B-4D2E-8A1E-ACB8396DDA06@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] Draft Minutes from SIMPLE@IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:19:24 -0000 The following are draft minutes from the SIMPLE meeting in Quebec. = Please send any corrections as soon as possible. Thanks! Ben. = --------------------------------------------------------------------------= --------------------------- [DRAFT] Minutes - SIMPLE IETF 81 - Friday 29 July 2011 - Quebec, QC, CA Summary: -- Status:=20 Only 3 remaining work items: draft-ietf-simple-chat, = draft-ietf-simple-simple, draft-ietf-simple-msrp-sessmatch. We expect to = pubreq the chat draft soon. Simple-simple is waiting completion of the = other drafts, but should finish quickly. Msrp-sessmatch to be discussed = in this meeting. -- draft-ietf-simple-msrp-sessmatch Christer presented changes. The latest version is a significant = departure from previous versions. The primary changes (use of C and M = lines rather than MSRP URI for connection management) appear to have = support on the list and in the room. Eric Burger and Christer Holmberg = will spin a new revisions, which will be followed by a WGLC. The AD = suggested changing the draft name to reflect the new approach. The = chairs will encourage people who have expressed issues with previous = revisions to speak up quickly if they still have issues with the new = version. Raw notes follow: Notes from Christian Schmidt: ------------------------------------------ IETF 81 Quebec, 23.-29. 07.2011 Fr 28.07.2011, 14:15-15:15 SIMPLE Chairs: Ben Campbell=20 Minutes taken by Christian Schmidt Three remaining work items for SIMPLE: - draft-ietf-simple-chat-09, ready for publication request? - draft-ietf-simple-msrp-sessmatch-13, discussion today -draft-ietf-simple-simple-06, WGLC done without feedback, expired Christer Holmberg presented updates of draft-ietf-simple-msrp-sessmatch-13.txt. Main advantage, it works with TLS name based authentication. Eric Burger: Is there a reason to include topology hiding in the draft? Christer Holmberg: Not meant to be included in the draft, only reflecting mail-discussions. Christer Holmberg: Do we need to mandate usage of TLS when communication with middleboxes? Proposal: When CEMA Uas communicate, they MUST use TLS for MSRP. Ben Campbell: RFC4976 requires TLS between relay and endpoint. It is not required between relays.=20 Hadrial Kaplan: It is somehow requiring SRTP, which is a much bigger hurdle. Ben Campbell: The TLS requirement could be problematic. Hadrial Kaplan: TLS would not work in this situation. Christer Holmberg: Perhaps we do not mandate TLS, but we can make strong recommendations to use. Ben Campbell (Individual): Just reference to security considerations in RFC4976. Perhaps a hint to use finger prints would be useful. We should not mandate TLS. Ben Campbell (Individual): I want to see a table, when middlebox have to be B2BUA. I am worried about complexity for middleboxes. Christer Holmberg: We do not request new functionality for middlebox. They just decide functionality according the CEMA paramater. Ben Campbell: If this approach is similar complex as RFC4976, then this makes no sense. Christer Holmberg: If this would be the case, I would make the same statement, but that is not the case. Eric Burger: This is not about making things easier for middleboxes. It is about to overcome a failure in middleboxes. And it makes implementations for middleboxes much simpler. I am willing to spend a small increse of complexity now for this purpose. Ben Campbell: Keep in mind, we make no normative statements, how middleboxes work. We can not force middleboxes to implement MSRP B2BUA.=20= Eric Burger: This is the reason, why this draft is important. Ben Campbell: 3GPP can make requirements for middleboxes.=20 Hadrial Kaplan: Start WGLC Ben Campbell: Likely we will have this, but people with fundamental concerns are currently in SPLICES. Gonzalo Camarillo: Anything decided here will be backuped by mailing list anyway. This conflict was not to avoid. Ben Campbell: Sometime very soon, we will summarize on the list, what we are thinking. Then we will go to WGLC. Gonzalo Camarillo: I have officially the token. I would like to see a WGLC for this document. Perhaps a new filename would be a good idea. Andrew Allen: People could listen to the audio file of this session for preparation. Ben Campbell: We have done. ------------------------------------------ Notes from Martin Thomson: ------------------------------------ [Note: BC =3D Ben Campbell, HK =3D Hadriel Kaplan, EB =3D Eric Burger, = AD =3D Gonzalo Camarillo (Area Director), AA =3D Andrew Allen ] Agenda: Christer on CEMA (Short aside noting that the WG is almost done) Review of (big) changes to the draft with CEMA Discussion on potential erratum on 4976: where the c/m-line is assumed = to include the address of the UA (not the relay) On topology hiding: how many SBCs need to look at or change the MSRP = messages? HK: None identified. EB: suggests that being silent on = topology hiding might be good. BC: Agrees, operators will find other = reasons to use B2BUA. On mandatory TLS:=20 BC: 4976 requires TLS between UA and relay, which includes crypto and = authent. =20 HK: TLS is going end to end. =20 BC: more secure. =20 HK: but there wont be certs =20 EB: you know about the presence of intermediary when you use TLS HK: not true, even with certs this depends on the SIP layer, you might = be told to go to evil.com and if evil.com has a cert, then you think its = OK HK: TCP splicing is commonly used, but that doesn't work with TLS = because both peers think that they are the client =20 EB: the certificate problem seems insurmountable BC: suggests referencing 4975 security considerations, but the = fingerprint stuff in there might cause problems Conclusion: won't require TLS, will try to strongly encourage it EB: I'm not happy, make me happen Martin [Dolly] Editorial discussion regarding DNS names and IP addresses in a=3Dpath, = etc... Asking for WGLC BC: Need to be able to describe when the middlebox needs to be a B2BUA. = (?Need to describe how a CEMA UA can interact with a non-CEMA UA.) EB: this is not about making middleboxes easier. This is about = fixing/working around the fatal flaw where signaling gets into payloads. = The benefit for simpler middleboxes is a secondary benefit. Looking for = a utopian ideal where there is nothing like signaling in the payload and = there is a cryptographic assurance that the media is being exchanged = with the expected peer BC: EB, you gave me heartburn. We can't make statements about = middleboxes, but we need to make the things that people really do = possible (mentions OMA). Nothing we do should depend on having = middlebox developers heed our advice. EB: Yes. [[some clear, concise and evocative argument.]] BC: Agrees. BC: Unless we secure this all the way down, we have no security. TLS = doesn't help, even if we can get certs, but this depends on the security = on the signaling channel. And by definition, the signaling is not = secure end to end because we rely on middleboxes mucking with the SDP. EB: -11 was insidious. End-to-end relies on trust with the = intermediaries. -11 assumed that the signaling and MSRP went through = the very same box. There was a chance of knowing that signaling was = altered, but not media. HK: agrees with BC on premise. SAS option from DTLS-SRTP could be used = in the future here. EB: does this help us get there? HK: yes EB: baby steps are OK BC: this is based on a model like the HTTP proxy, but it's now more of a = policy enforcement point HK: yes, but it shouldn't be; if I want to enforce policy, I will B2BUA BC: if a middlebox chooses to be a B2BUA, you can't find out if they = don't want you to On WGLC: *Chair: we will likely go to WGLC once the draft is reviewed, but there = is a concern that some of the people in splices have big concerns about = this, we don't want to get blindsided later *AD: we will have to confirm this on the mailing list Chair: will encourage haters to hate fast EB: how can you be against there being more security on the internet? *Chair: soon EB: proposes one more spin *AD: expects that this is more like a new work item going through the = draft - following the normal process AA: suggests that those outside the group are pointed at the MP3 stream From eburger@standardstrack.com Fri Aug 5 13:43:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCD911E80C5 for ; Fri, 5 Aug 2011 13:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-uYTS9dqt3L for ; Fri, 5 Aug 2011 13:43:55 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 515FA11E80C1 for ; Fri, 5 Aug 2011 13:43:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=1s6hCkJzZ8yajz5zrhIB0NSBlula17vACHM4orrGIuN6CaT0SedhNcBtkQPoiv3zAANxfaWzUU1vHYLkFVL7JH0CN5BDGsn7QTSxYWI2Wmpn1Hs7JzovnqBI2l1vXk12; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QpRFb-00077O-OD; Fri, 05 Aug 2011 13:44:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-79--737599986; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <111182F4-D00B-4D2E-8A1E-ACB8396DDA06@nostrum.com> Date: Fri, 5 Aug 2011 16:44:08 -0400 Message-Id: <0DD3B559-018F-4F86-B410-BCFDA34223CA@standardstrack.com> References: <111182F4-D00B-4D2E-8A1E-ACB8396DDA06@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] Draft Minutes from SIMPLE@IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 20:43:56 -0000 --Apple-Mail-79--737599986 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii inline On Aug 5, 2011, at 4:19 PM, Ben Campbell wrote: [snip] > Ben Campbell (Individual): I want to see a table, when middlebox have > to be B2BUA. I am worried about complexity for middleboxes. > Christer Holmberg: We do not request new functionality for middlebox. > They just decide functionality according the CEMA paramater. > Ben Campbell: If this approach is similar complex as RFC4976, then this > makes no sense. > Christer Holmberg: If this would be the case, I would make the same > statement, but that is not the case. > Eric Burger: This is not about making things easier for middleboxes. It > is about to overcome a failure in middleboxes. And it makes s/overcome a failure in middleboxes/overcome a failure in MSRP/ > implementations for middleboxes much simpler. I am willing to spend a > small increse of complexity now for this purpose. > Ben Campbell: Keep in mind, we make no normative statements, how > middleboxes work. We can not force middleboxes to implement MSRP B2BUA. > Eric Burger: This is the reason, why this draft is important. > Ben Campbell: 3GPP can make requirements for middleboxes. [snip] --Apple-Mail-79--737599986 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MDUyMDQ0MDlaMCMGCSqGSIb3DQEJ BDEWBBQl4JDHUsA+xLetBEExmh7hxc94tzCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAKVhrUhdR12+Kkvo58UiO+AJQtcT2NHGR4ZoE1xvBnFeNy2J vmoBx8J/u1WVb6A7FAjf/9+kU8IKGpQ5IGfIc84wk/SvhPitsktZVe7jawMIYxwbtT36JgVM4COc N+mU1lGCUZCMnHyVAqchBPStpDNRMfSU/shUwddkFIOV3ITpSZHQ+aFWpSjkRmifx1qrUeHGgrlN Qe0VxKirRp7fzUMhn7g26PKzd9vffhtpSCgcZ6wyIt1G7nqsCNmBByUa1XJCtEhyRKVYlW0JjBKk t4Hs6ONEy9WLRg4m+/eKjX/wBJTtS5xBGmS92yrya2k3hxAlHOwCa9K/o9c3fqScV6EAAAAAAAA= --Apple-Mail-79--737599986-- From saul@ag-projects.com Mon Aug 8 00:28:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1A021F86D8 for ; Mon, 8 Aug 2011 00:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.568 X-Spam-Level: X-Spam-Status: No, score=-1.568 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXJ5sKwMAZIe for ; Mon, 8 Aug 2011 00:28:36 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 07C0F21F86B1 for ; Mon, 8 Aug 2011 00:28:35 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id A0D0DB0196; Mon, 8 Aug 2011 09:28:58 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2ACDFB017C; Mon, 8 Aug 2011 09:28:58 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <111182F4-D00B-4D2E-8A1E-ACB8396DDA06@nostrum.com> Date: Mon, 8 Aug 2011 09:28:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6E9C4F96-306F-41B3-A316-7B94910C3DDA@ag-projects.com> References: <111182F4-D00B-4D2E-8A1E-ACB8396DDA06@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Draft Minutes from SIMPLE@IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 07:28:36 -0000 On Aug 5, 2011, at 10:19 PM, Ben Campbell wrote: > The following are draft minutes from the SIMPLE meeting in Quebec. = Please send any corrections as soon as possible. >=20 Looks like the session was recorded, right? If so, can someone point em = to the audio file? Thanks! -- Sa=FAl Ibarra Corretg=E9 AG Projects From ben@nostrum.com Tue Aug 9 14:02:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C4421F8B72 for ; Tue, 9 Aug 2011 14:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFe5p+GeGLHS for ; Tue, 9 Aug 2011 14:02:26 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4563721F8B4A for ; Tue, 9 Aug 2011 14:02:26 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p79L2nbd036122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Aug 2011 16:02:51 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: <6E9C4F96-306F-41B3-A316-7B94910C3DDA@ag-projects.com> Date: Tue, 9 Aug 2011 16:02:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0AADAB6D-0DCE-4B08-8541-B2DF8825C041@nostrum.com> References: <111182F4-D00B-4D2E-8A1E-ACB8396DDA06@nostrum.com> <6E9C4F96-306F-41B3-A316-7B94910C3DDA@ag-projects.com> To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Draft Minutes from SIMPLE@IETF81 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:02:26 -0000 On Aug 8, 2011, at 2:28 AM, Sa=FAl Ibarra Corretg=E9 wrote: >=20 > On Aug 5, 2011, at 10:19 PM, Ben Campbell wrote: >=20 >> The following are draft minutes from the SIMPLE meeting in Quebec. = Please send any corrections as soon as possible. >>=20 >=20 > Looks like the session was recorded, right? If so, can someone point = em to the audio file? >=20 https://www.ietf.org/audio/ietf81/ietf81-204b-20110729-1256-pm.mp3 . = That's for the whole afternoon. The SIMPLE meeting starts at about 1:19 Thanks! Ben. > Thanks! >=20 > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Wed Aug 10 05:50:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C53B21F8782 for ; Wed, 10 Aug 2011 05:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmn75fxrMySj for ; Wed, 10 Aug 2011 05:50:49 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7080A21F876F for ; Wed, 10 Aug 2011 05:50:48 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7ACpHxk022547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 10 Aug 2011 07:51:19 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 10 Aug 2011 07:51:20 -0500 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Subject: [Simple] Test Message, Please Ignore X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 12:50:52 -0000 No Content From eburger@standardstrack.com Mon Aug 22 09:36:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89C21F8BBC for ; Mon, 22 Aug 2011 09:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXolbT0jYdXt for ; Mon, 22 Aug 2011 09:36:37 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3021F8BA0 for ; Mon, 22 Aug 2011 09:36:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Content-Type:Subject:Date:Message-Id:To:Mime-Version:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=WaHuapro/L5Lj9emehovkpxxvft5H42pDabc0mdbyB+ZISI37MGyAT2148MiKFB8nGIbgC9kpY82RI47GVafe8KDRa0t+rsswM5jupiW6eem1KIfiUA0uYGyGO1dtBUk; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QvXVN-0008RX-3X for simple@ietf.org; Mon, 22 Aug 2011 09:37:42 -0700 From: Eric Burger Content-Type: multipart/signed; boundary=Apple-Mail-86-716408973; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 22 Aug 2011 12:37:37 -0400 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 16:36:38 -0000 --Apple-Mail-86-716408973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The CEMA draft, the latest incarnation of session matching, is almost = ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. Because the purpose of CEMA is enabling end-to-end encryption, there has = been some debate as to whether, when two CEMA-endpoints are negotiating, = TLS is mandatory or optional. On the optional side are the following arguments: o TLS consumes resources, more so than TCP o TLS requires certificates in the end point o Non-CEMA endpoints have only a MAY requirement for TLS, and thus few = if any implement TLS o TLS does not provide bullet-proof security, due to vulnerabilities = from self-signed certificates or alternate root certificate hijacking On the mandatory side are the following arguments: o While TLS consumes resources, most mobile devices have more than = enough compute and battery resources to do TLS. o TLS does not impact middleboxes whatsoever o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, all = endpoints have rooted, trusted certificates. o Communicating with an endpoint with a self-signed certificate, while = not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. Comments welcome. We really are just one MUST versus MAY away from = getting this finished. Thanks.= --Apple-Mail-86-716408973 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjIxNjM3MzhaMCMGCSqGSIb3DQEJ BDEWBBQvNT0remEvDleBxtU7j6SYEzNFaDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAAHPaTL0YSfeoba8SQD0/yZvqp2L9uI8YJH6kNrhebw6lErY 5o8jFOp1aBJ34QH+3dehCmeglWwREl9pXuyQLAuAq3Qo7dK9GsJUydIVPTzEWCDBDscwAbNitbwz DY/eUIXp7wiDraYdk+DJ/sGvbxTDyZMEu9bFlrN+BzJ09F//mJE9OeGqQVIsA+Kv8+b1YuJnph3H X+QjzwWQIXlRvAczXD5QeOP+faFrdiBYsmUsPQcrkUGN4Ldbw9UyLQeyEjjRSmro1aNc3UX6E+4u gCbmTnhd09NNCieWchK0mbWvIZLAVJGdDdJ+W0eUTCnxqsVO5h70/91bo0FBgG19p9oAAAAAAAA= --Apple-Mail-86-716408973-- From ag@ag-projects.com Mon Aug 22 10:05:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7BB21F8B85 for ; Mon, 22 Aug 2011 10:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGf7U-xqU5Jn for ; Mon, 22 Aug 2011 10:05:05 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9064121F8B8C for ; Mon, 22 Aug 2011 10:05:03 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B79F2B01A0; Mon, 22 Aug 2011 19:06:07 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 2BDDEB019A; Mon, 22 Aug 2011 19:05:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: Date: Mon, 22 Aug 2011 19:05:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33C6F689-E91B-44F3-A649-5D6C50E556D5@ag-projects.com> References: To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:05:06 -0000 Comments inline, On Aug 22, 2011, at 6:37 PM, Eric Burger wrote: > The CEMA draft, the latest incarnation of session matching, is almost = ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >=20 > Because the purpose of CEMA is enabling end-to-end encryption, there = has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >=20 > On the optional side are the following arguments: >=20 > o TLS consumes resources, more so than TCP This is not a valid argument. I have more CPU power in my Android phone today than I had 8 years in = half a rack full full of servers in the data center. By the time this = drafts passes, we will have 4x 1GHz CPU cores in every end-user device = as standard. If you do MSRP, then your do at least WEB browsing and TLS = for it anyway. > o TLS requires certificates in the end point This is not a valid argument. It is the server that must have a certificate as per usual. Same as in = e-commerce, is the server that needs to prove who is to the client and = not vice-versa. Once the TLS connection is established, then the client = authenticates itself using an in-band mechanism with his credentials. >=20 > o Non-CEMA endpoints have only a MAY requirement for TLS, and thus = few if any implement TLS This is not a valid argument. All MSRP end-points must implement TLS as per standard. And all MSRP = end-points I know of, they do implement TLS by default. Search the Mac = App Store for MSRP clients to confirm this.=20 >=20 > o TLS does not provide bullet-proof security, due to vulnerabilities = from self-signed certificates or alternate root certificate hijacking. This is not a valid argument. If it is, than the whole World Wide Web has the same issue. This is = problem of PKIs is general and not how they defend their CA. > On the mandatory side are the following arguments: >=20 > o While TLS consumes resources, most mobile devices have more than = enough compute and battery resources to do TLS. >=20 > o TLS does not impact middleboxes whatsoever >=20 > o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, = all endpoints have rooted, trusted certificates. >=20 > o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >=20 > o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >=20 > o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >=20 > Comments welcome. We really are just one MUST versus MAY away from = getting this finished. >=20 > Thanks._______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Mon Aug 22 10:20:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA221F8B61 for ; Mon, 22 Aug 2011 10:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.487 X-Spam-Level: X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=1.112, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL4TmLkGMlt3 for ; Mon, 22 Aug 2011 10:20:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBD0B21F8B5C for ; Mon, 22 Aug 2011 10:20:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 22 Aug 2011 13:21:44 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Mon, 22 Aug 2011 13:21:45 -0400 From: Hadriel Kaplan To: Eric Burger Date: Mon, 22 Aug 2011 13:21:41 -0400 Thread-Topic: [Simple] TLS or Not for CEMA Thread-Index: Acxg7/b48w8YD8ZNSzWQ1O1LBAAaHQ== Message-ID: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFT Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:20:41 -0000 I don't understand how one can mandate TLS be used, since it would break ba= ckwards-compatibility=85 for which this whole thing has taken all this time= . To use TLS, the m=3D line must indicate it, and the "msrps" scheme path is = used. (well, the latter is not as clear as the former) Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can use it = in its offer to communicate with RFC 4975 UAS. =20 -hadriel On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: > The CEMA draft, the latest incarnation of session matching, is almost rea= dy for submission. As you may recall from the list and live discussion in = Quebec City (archived and minuted), the point of CEMA is not to make life e= asy for middleboxes. The point is to make it *possible* for end-to-end enc= ryption to occur in the common topology where there happen to be middleboxe= s. A side effect is life is a lot easier for middleboxes, which one could = consider the carrot to get the middlebox manufacturers and service provider= s to adopt CEMA, is it makes life easier for them. >=20 > Because the purpose of CEMA is enabling end-to-end encryption, there has = been some debate as to whether, when two CEMA-endpoints are negotiating, TL= S is mandatory or optional. >=20 > On the optional side are the following arguments: >=20 > o TLS consumes resources, more so than TCP >=20 > o TLS requires certificates in the end point >=20 > o Non-CEMA endpoints have only a MAY requirement for TLS, and thus few = if any implement TLS >=20 > o TLS does not provide bullet-proof security, due to vulnerabilities fr= om self-signed certificates or alternate root certificate hijacking >=20 >=20 > On the mandatory side are the following arguments: >=20 > o While TLS consumes resources, most mobile devices have more than enou= gh compute and battery resources to do TLS. >=20 > o TLS does not impact middleboxes whatsoever >=20 > o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, all = endpoints have rooted, trusted certificates. >=20 > o Communicating with an endpoint with a self-signed certificate, while = not offering a defense against man-in-the-middle attacks, is an improvement= over plaintext TCP. Plaintext TCP is subject to eavesdropping attacks. M= oreover, mandating TLS raises the bar for man-in-the-middle attacks or alte= ration attacks, as the attacker much generate the appropriate certificates,= potentially on the fly. >=20 > o Mandating TLS puts the structure in place for true, end-to-end securi= ty with the deployment of an ubiquitous PKI, such as PGP or DANE. >=20 > o Not mandating TLS means CEMA perpetuates the invitation for downgrade= attacks. This would be a structural problem that the deployment of a ubiq= uitous PKI would not fix. >=20 > Comments welcome. We really are just one MUST versus MAY away from getti= ng this finished. >=20 > Thanks. From ag@ag-projects.com Mon Aug 22 10:39:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340AD21F8AE4 for ; Mon, 22 Aug 2011 10:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.988 X-Spam-Level: X-Spam-Status: No, score=-3.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4WmcmfDuYYt for ; Mon, 22 Aug 2011 10:39:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C85B21F8AE1 for ; Mon, 22 Aug 2011 10:39:50 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 51D3AB01A1; Mon, 22 Aug 2011 19:40:53 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id D6AC0B0181; Mon, 22 Aug 2011 19:40:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Adrian Georgescu In-Reply-To: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> Date: Mon, 22 Aug 2011 19:40:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7F50182E-F3E9-46B9-840D-85D39C003589@ag-projects.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:39:52 -0000 I believe mandating encryption by default is a civic duty much like = implementing sanitation. It costs more in the long run and is more = unpleasant if you do not have it. Adrian On Aug 22, 2011, at 7:21 PM, Hadriel Kaplan wrote: >=20 > I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. > To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) > Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can = use it in its offer to communicate with RFC 4975 UAS. =20 >=20 > -hadriel >=20 >=20 > On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >=20 >> The CEMA draft, the latest incarnation of session matching, is almost = ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>=20 >> Because the purpose of CEMA is enabling end-to-end encryption, there = has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>=20 >> On the optional side are the following arguments: >>=20 >> o TLS consumes resources, more so than TCP >>=20 >> o TLS requires certificates in the end point >>=20 >> o Non-CEMA endpoints have only a MAY requirement for TLS, and thus = few if any implement TLS >>=20 >> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>=20 >>=20 >> On the mandatory side are the following arguments: >>=20 >> o While TLS consumes resources, most mobile devices have more than = enough compute and battery resources to do TLS. >>=20 >> o TLS does not impact middleboxes whatsoever >>=20 >> o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, = all endpoints have rooted, trusted certificates. >>=20 >> o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>=20 >> o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >>=20 >> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>=20 >> Comments welcome. We really are just one MUST versus MAY away from = getting this finished. >>=20 >> Thanks. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From rbarnes@bbn.com Mon Aug 22 10:54:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADD321F8C33 for ; Mon, 22 Aug 2011 10:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.544 X-Spam-Level: X-Spam-Status: No, score=-107.544 tagged_above=-999 required=5 tests=[AWL=1.055, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwo0OzIgqYOA for ; Mon, 22 Aug 2011 10:54:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4B52821F8C30 for ; Mon, 22 Aug 2011 10:54:31 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:63329) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvYil-0002K5-En; Mon, 22 Aug 2011 13:55:35 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> Date: Mon, 22 Aug 2011 13:55:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1082) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 17:54:32 -0000 This seems like a sensible approach. I don't see why CEMA endpoints = should behave any differently from other SIP endpoints with regard to = the use of secure media. If either party desires or requires the use of = TLS, they can negotiate it in SDP, as Hadriel notes. ISTM that the = traditional "MUST implement / MAY use" pattern applies here. --Richard On Aug 22, 2011, at 1:21 PM, Hadriel Kaplan wrote: >=20 > I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. > To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) > Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can = use it in its offer to communicate with RFC 4975 UAS. =20 >=20 > -hadriel >=20 >=20 > On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >=20 >> The CEMA draft, the latest incarnation of session matching, is almost = ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>=20 >> Because the purpose of CEMA is enabling end-to-end encryption, there = has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>=20 >> On the optional side are the following arguments: >>=20 >> o TLS consumes resources, more so than TCP >>=20 >> o TLS requires certificates in the end point >>=20 >> o Non-CEMA endpoints have only a MAY requirement for TLS, and thus = few if any implement TLS >>=20 >> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>=20 >>=20 >> On the mandatory side are the following arguments: >>=20 >> o While TLS consumes resources, most mobile devices have more than = enough compute and battery resources to do TLS. >>=20 >> o TLS does not impact middleboxes whatsoever >>=20 >> o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, = all endpoints have rooted, trusted certificates. >>=20 >> o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>=20 >> o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >>=20 >> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>=20 >> Comments welcome. We really are just one MUST versus MAY away from = getting this finished. >>=20 >> Thanks. >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ag@ag-projects.com Mon Aug 22 12:36:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257C821F8C4D for ; Mon, 22 Aug 2011 12:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLKCbNSARYJd for ; Mon, 22 Aug 2011 12:36:17 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7D10C21F8C0F for ; Mon, 22 Aug 2011 12:36:17 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 76C90B01B0; Mon, 22 Aug 2011 21:37:21 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id ED711B019A for ; Mon, 22 Aug 2011 21:37:20 +0200 (CEST) From: Adrian Georgescu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Aug 2011 21:37:19 +0200 Message-Id: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Simple] XCAP clients in the real world X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:36:18 -0000 Hello, I know is too little too late but I am simple peasant born in Romania. Now there is a SIP client with proper XCAP support available in the real = world, you can find it in the Mac App Store if you search for Blink Lite = or Blink Pro.=20 It supports storage of contacts lists using resource-lists and = rls-services documents based on OMA specifications and xcap-diff event = package for synchronizing multiple clients in real time. Regards, Adrian From emcho@sip-communicator.org Mon Aug 22 12:54:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA6B21F8CBB for ; Mon, 22 Aug 2011 12:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDKTpjQ++q6r for ; Mon, 22 Aug 2011 12:54:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B32C21F8C9E for ; Mon, 22 Aug 2011 12:54:27 -0700 (PDT) Received: by vws12 with SMTP id 12so5437703vws.31 for ; Mon, 22 Aug 2011 12:55:31 -0700 (PDT) Received: by 10.52.70.140 with SMTP id m12mr2460910vdu.473.1314042931469; Mon, 22 Aug 2011 12:55:31 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by mx.google.com with ESMTPS id n4sm196695vcv.46.2011.08.22.12.55.29 (version=SSLv3 cipher=OTHER); Mon, 22 Aug 2011 12:55:31 -0700 (PDT) Received: by qyk35 with SMTP id 35so2410069qyk.10 for ; Mon, 22 Aug 2011 12:55:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.195.71 with SMTP id eb7mr1721923qab.390.1314042929255; Mon, 22 Aug 2011 12:55:29 -0700 (PDT) Received: by 10.229.212.20 with HTTP; Mon, 22 Aug 2011 12:55:29 -0700 (PDT) Received: by 10.229.212.20 with HTTP; Mon, 22 Aug 2011 12:55:29 -0700 (PDT) In-Reply-To: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> References: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> Date: Mon, 22 Aug 2011 21:55:29 +0200 Message-ID: From: Emil Ivov To: Adrian Georgescu Content-Type: multipart/alternative; boundary=20cf3005dd1204955b04ab1d7628 Cc: Simple WG Subject: Re: [Simple] XCAP clients in the real world X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 19:54:28 -0000 --20cf3005dd1204955b04ab1d7628 Content-Type: text/plain; charset=ISO-8859-1 Speaking of XCAP implementations, people here would probably be interested in Jitsi too. http://jitsi.org XCAP support for Windows, Mac OS X, and Linux. Entirely open sourced and free (as in beer and as in speech ;) ) Emil -- sent from my mobile On Aug 22, 2011 9:37 PM, "Adrian Georgescu" wrote: > Hello, > > I know is too little too late but I am simple peasant born in Romania. > > Now there is a SIP client with proper XCAP support available in the real world, you can find it in the Mac App Store if you search for Blink Lite or Blink Pro. > > It supports storage of contacts lists using resource-lists and rls-services documents based on OMA specifications and xcap-diff event package for synchronizing multiple clients in real time. > > Regards, > Adrian > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --20cf3005dd1204955b04ab1d7628 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Speaking of XCAP implementations, people here would probably be interest= ed in Jitsi too.

http://jitsi.org

XCAP support for Windows, Mac OS X, and Linux. Entirely open sourced and= free (as in beer and as in speech ;) )

Emil

-- sent from my mobile

On Aug 22, 2011 9:37 PM, "Adrian Georgescu&= quot; <ag@ag-projects.com> = wrote:
> Hello,
>
> I know is too l= ittle too late but I am simple peasant born in Romania.
>
> Now there is a SIP client with proper XCAP support available = in the real world, you can find it in the Mac App Store if you search for B= link Lite or Blink Pro.
>
> It supports storage of contacts l= ists using resource-lists and rls-services documents based on OMA specifica= tions and xcap-diff event package for synchronizing multiple clients in rea= l time.
>
> Regards,
> Adrian
>
>
> ___________= ____________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/lis= tinfo/simple
--20cf3005dd1204955b04ab1d7628-- From ibc@aliax.net Mon Aug 22 13:02:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D09A21F8BE5 for ; Mon, 22 Aug 2011 13:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebkQvOMJR2oQ for ; Mon, 22 Aug 2011 13:02:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B70521F8BA7 for ; Mon, 22 Aug 2011 13:02:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so3998308qwc.31 for ; Mon, 22 Aug 2011 13:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr1642581qce.185.1314043392131; Mon, 22 Aug 2011 13:03:12 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 13:03:12 -0700 (PDT) In-Reply-To: References: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> Date: Mon, 22 Aug 2011 22:03:12 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] XCAP clients in the real world X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 20:02:07 -0000 2011/8/22 Emil Ivov : > Speaking of XCAP implementations, people here would probably be intereste= d > in Jitsi too. > > http://jitsi.org > > XCAP support for Windows, Mac OS X, and Linux. How good is the XCAP support? when I tested it some time ago it was really buggy. For example, I tryed to report the following bug (but was impossible to use Jira web tracker): When Jitsi uploads the resource-list (XCAP PUT) it set a wrong Content-Type= : ----------------------------------------- PUT /resource-lists/users/sip:alice@example.org/index HTTP/1.1' Connection: close' Content-Length: 231' Content-Type: application/xcap-caps+xml' Content-Encoding: UTF-8' Host: example.org:800' User-Agent: Apache-HttpClient/4.0.1 (java 1.5)' Expect: 100-Continue' --------------------------------------- Why is it using "Content-Type: application/xcap-caps+xml"? Such mime type is just for discovering XCAP Server Capabilities: http://tools.ietf.org/html/rfc4825#section-12 The mime type for a resource-lists document must be application/resource-lists+xml: http://tools.ietf.org/html/rfc4826#section-3.4.2 Regards. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Mon Aug 22 13:05:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56CA21F8C80 for ; Mon, 22 Aug 2011 13:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43+MpqPrFUPb for ; Mon, 22 Aug 2011 13:05:12 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E161021F8C30 for ; Mon, 22 Aug 2011 13:05:11 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 5EB3AB01B0; Mon, 22 Aug 2011 22:06:17 +0200 (CEST) Received: from ag-blink.fritz.box (095-097-050-027.static.chello.nl [95.97.50.27]) by mail.sipthor.net (Postfix) with ESMTPSA id 4CDB9B019A; Mon, 22 Aug 2011 22:06:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-10-728926460 From: Adrian Georgescu In-Reply-To: Date: Mon, 22 Aug 2011 22:06:15 +0200 Message-Id: <363CC6F3-6354-45E5-8458-EC1483590364@ag-projects.com> References: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> To: Emil Ivov X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] XCAP clients in the real world X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2011 20:05:12 -0000 --Apple-Mail-10-728926460 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, it would be really nuts to be the only crazy person in town ;-) Adrian On Aug 22, 2011, at 9:55 PM, Emil Ivov wrote: > Speaking of XCAP implementations, people here would probably be = interested in Jitsi too. >=20 > http://jitsi.org >=20 > XCAP support for Windows, Mac OS X, and Linux. Entirely open sourced = and free (as in beer and as in speech ;) ) >=20 > Emil > -- sent from my mobile >=20 > On Aug 22, 2011 9:37 PM, "Adrian Georgescu" = wrote: > > Hello, > >=20 > > I know is too little too late but I am simple peasant born in = Romania. > >=20 > > Now there is a SIP client with proper XCAP support available in the = real world, you can find it in the Mac App Store if you search for Blink = Lite or Blink Pro.=20 > >=20 > > It supports storage of contacts lists using resource-lists and = rls-services documents based on OMA specifications and xcap-diff event = package for synchronizing multiple clients in real time. > >=20 > > Regards, > > Adrian > >=20 > >=20 > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-10-728926460 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Yes, it would be really nuts to be the only crazy person in town ;-)

Adrian

On Aug 22, 2011, at 9:55 PM, Emil Ivov wrote:

Speaking of XCAP implementations, people here would probably be interested in Jitsi too.

http://jitsi.org

XCAP support for Windows, Mac OS X, and Linux. Entirely open sourced and free (as in beer and as in speech ;) )

Emil

-- sent from my mobile

On Aug 22, 2011 9:37 PM, "Adrian Georgescu" <ag@ag-projects.com> wrote:
> Hello,
>
> I know is too little too late but I am simple peasant born in Romania.
>
> Now there is a SIP client with proper XCAP support available in the real world, you can find it in the Mac App Store if you search for Blink Lite or Blink Pro.
>
> It supports storage of contacts lists using resource-lists and rls-services documents based on OMA specifications and xcap-diff event package for synchronizing multiple clients in real time.
>
> Regards,
> Adrian
>
>
> _______________________________________________
> Simple mailing list
> Simple@ietf.org
> https://www.ietf.org/mailman/listinfo/simple

--Apple-Mail-10-728926460-- From eburger@standardstrack.com Tue Aug 23 03:31:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF76B21F87C5 for ; Tue, 23 Aug 2011 03:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.453 X-Spam-Level: X-Spam-Status: No, score=-103.453 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-Rg3pCXzKl5 for ; Tue, 23 Aug 2011 03:31:34 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8A021F87C2 for ; Tue, 23 Aug 2011 03:31:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=sL6Fo04jQPUFiu5eeyylVGN0WMZN97OqoXliQHE62t3SV9KKRcAQuG9V6yXonEnlJGsGmW1nVJE3fUqkjHjeuliNMXljsqIeQ9A4qpD2uujqHmOHOdbcT7ksqbvKlVT1; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QvoHg-0003BG-R2; Tue, 23 Aug 2011 03:32:41 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-18-780907305; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> Date: Tue, 23 Aug 2011 06:32:36 -0400 Message-Id: <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:31:35 -0000 --Apple-Mail-18-780907305 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Right, and since there are no protocol police, MUST implement / MAY use = =3D DO NOT BOTHER. On Aug 22, 2011, at 1:55 PM, Richard L. Barnes wrote: > This seems like a sensible approach. I don't see why CEMA endpoints = should behave any differently from other SIP endpoints with regard to = the use of secure media. If either party desires or requires the use of = TLS, they can negotiate it in SDP, as Hadriel notes. ISTM that the = traditional "MUST implement / MAY use" pattern applies here. >=20 > --Richard >=20 >=20 > On Aug 22, 2011, at 1:21 PM, Hadriel Kaplan wrote: >=20 >>=20 >> I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. >> To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) >> Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can = use it in its offer to communicate with RFC 4975 UAS. =20 >>=20 >> -hadriel >>=20 >>=20 >> On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >>=20 >>> The CEMA draft, the latest incarnation of session matching, is = almost ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>>=20 >>> Because the purpose of CEMA is enabling end-to-end encryption, there = has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>>=20 >>> On the optional side are the following arguments: >>>=20 >>> o TLS consumes resources, more so than TCP >>>=20 >>> o TLS requires certificates in the end point >>>=20 >>> o Non-CEMA endpoints have only a MAY requirement for TLS, and thus = few if any implement TLS >>>=20 >>> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>>=20 >>>=20 >>> On the mandatory side are the following arguments: >>>=20 >>> o While TLS consumes resources, most mobile devices have more than = enough compute and battery resources to do TLS. >>>=20 >>> o TLS does not impact middleboxes whatsoever >>>=20 >>> o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, = all endpoints have rooted, trusted certificates. >>>=20 >>> o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>>=20 >>> o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >>>=20 >>> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>>=20 >>> Comments welcome. We really are just one MUST versus MAY away from = getting this finished. >>>=20 >>> Thanks. >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail-18-780907305 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjMxMDMyMzZaMCMGCSqGSIb3DQEJ BDEWBBS/zm2Su4SLkaaV25LsarW+ZclqkDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAJpPtWoJyR/0On6qfg6VkaEXb4zUK7Sfuz1jSkN1KPgko4Qb w4DBVWkBFg3JI5Lql09VThstEN0kxFuyB/E5QdbzD7fJl9eBhc0HGtIqXfjuIObf4EuKaRR3ryEo atqT7nlxZpApH3DkJmyjjD2G2LCCOr0sKcTF8kHGXxh3EwVKYG1+9Ch0x47QfoHG6CCO72QKloTB xhXik0uaG1JJ2whMshVZsPgCsDc7IW05ae4pQxf+PTRQTUNz4W4SwiKAbfJoTJcqtjwfxfC2qdep /ldE/AbNgY203dv7xT5UDhWpqqSaQQxfFJG4qQytVWESqhJIxTfFUmNRR135I2gu0jwAAAAAAAA= --Apple-Mail-18-780907305-- From eburger@standardstrack.com Tue Aug 23 03:37:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4142521F8B06 for ; Tue, 23 Aug 2011 03:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zLcTlxw92MC for ; Tue, 23 Aug 2011 03:37:25 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 42A8721F87D9 for ; Tue, 23 Aug 2011 03:37:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=aUB7NVwP1i3SLKXy5KNwZG9L90wozEAjDC5QQOYi8YISLCLkckZxDSZWokp11alSDe8mEmjaIGcNwBq0rc9RrwFCDsBtWVmE50X/7tyIeYav8dsRFYHn6ho0w0qamon+; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QvoNJ-0002P8-Le; Tue, 23 Aug 2011 03:38:30 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-19-781246108; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> Date: Tue, 23 Aug 2011 06:38:14 -0400 Message-Id: <2807335E-77CD-49B1-9436-3DCB9B72D5B2@standardstrack.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:37:26 -0000 --Apple-Mail-19-781246108 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 It does not break backwards-compatibilitiy. A CEMA peer contacting a = CEMA peer MUST use TLS. Not a problem, because the remote CEMA peer is = a CEMA peer and thus is guaranteed to use TLS. A CEMA peer contacting a RFC 4975 UAS uses RFC 4975. RFC 4975 says MUST = implement TLS. Not a problem; all we are doing is moving from PROBABLY = USE TCP to MUST use TLS. Interestingly, RFC 4975 also points out what I said earlier. msrp: could = use TLS; msrps: must use TLS. I don't have any issue with mandating = msrps: if that is the issue with mandating use of TLS for CEMA. On Aug 22, 2011, at 1:21 PM, Hadriel Kaplan wrote: >=20 > I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. > To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) > Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can = use it in its offer to communicate with RFC 4975 UAS. =20 >=20 > -hadriel >=20 >=20 > On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >=20 >> The CEMA draft, the latest incarnation of session matching, is almost = ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>=20 >> Because the purpose of CEMA is enabling end-to-end encryption, there = has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>=20 >> On the optional side are the following arguments: >>=20 >> o TLS consumes resources, more so than TCP >>=20 >> o TLS requires certificates in the end point >>=20 >> o Non-CEMA endpoints have only a MAY requirement for TLS, and thus = few if any implement TLS >>=20 >> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>=20 >>=20 >> On the mandatory side are the following arguments: >>=20 >> o While TLS consumes resources, most mobile devices have more than = enough compute and battery resources to do TLS. >>=20 >> o TLS does not impact middleboxes whatsoever >>=20 >> o The primary market for CEMA initially is 3GPP IMS. In 3GPP IMS, = all endpoints have rooted, trusted certificates. >>=20 >> o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>=20 >> o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >>=20 >> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>=20 >> Comments welcome. We really are just one MUST versus MAY away from = getting this finished. >>=20 >> Thanks. >=20 --Apple-Mail-19-781246108 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjMxMDM4MTVaMCMGCSqGSIb3DQEJ BDEWBBTANov2WsO5nxVCKIInhbkWrb/lXTCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBADfXU4aqlJFLinH9ggyb4Ys25lIHsAc7rrAJVxCGEhjQhqns ioi7xr0SQyUYrKArU66epODJTYCx4GmciCqzSjXOVYLZyyhc42mQ7IzPyf/WOCMuHMwEeP//y0Dh X8/j70pJAp/15aG1e6RiM4VBaKarlh0QuSurKY7+UNKhjvil7/LylsujGSRc7ym2idjSej5r2Jlx gZVmdNX4c82elT4AdFOLAefQz79ht0TKKCyzPIMCSJH1FBLvw4ItrAF/pB5GH0vt1jpIF8yIi6SC ZK8Oaui+mxuP+rpUr0YRNsXywDs0p931MQ7IQsE+xTPJ61XGNRUhxkdEEzGzNL99egIAAAAAAAA= --Apple-Mail-19-781246108-- From ibc@aliax.net Tue Aug 23 04:05:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BF021F85C4 for ; Tue, 23 Aug 2011 04:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+8V-t+UrE19 for ; Tue, 23 Aug 2011 04:05:38 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 986A221F8574 for ; Tue, 23 Aug 2011 04:05:38 -0700 (PDT) Received: by qyk35 with SMTP id 35so2734119qyk.10 for ; Tue, 23 Aug 2011 04:06:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr2123419qce.185.1314097605927; Tue, 23 Aug 2011 04:06:45 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 04:06:45 -0700 (PDT) In-Reply-To: <4E538785.4000208@jitsi.org> References: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> <4E538785.4000208@jitsi.org> Date: Tue, 23 Aug 2011 13:06:45 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Emil Ivov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] XCAP clients in the real world X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 11:05:39 -0000 2011/8/23 Emil Ivov : >> How good is the XCAP support? > > Good enough I suppose. We are using it with OpenXCAP on a daily basis > without any issues and we've had success reports for other impls too. Good to know :) >> when I tested it some time ago it was >> really buggy. For example, I tryed to report the following bug >> (but was impossible to use Jira web tracker): > > I couldn't find your report on our mailing lists (which is where we take > them) so feel free to post there: > > http://jitsi.org/mailinglists Well, the bug report is exactly what I've pasted in my previous mail and it exists regardless I subscribe or not to that maillist (a really hard task in my previous attempt, I didn't receive confirmation until long days after requesting the subscription). So, if it's ok for you I prefer not to subscribe (the bug report is exactly my previous mail). Regards. --=20 I=C3=B1aki Baz Castillo From rbarnes@bbn.com Tue Aug 23 06:27:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66A021F8B06 for ; Tue, 23 Aug 2011 06:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.566 X-Spam-Level: X-Spam-Status: No, score=-107.566 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIzwjJ-OMVSr for ; Tue, 23 Aug 2011 06:27:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F83521F8ADC for ; Tue, 23 Aug 2011 06:27:39 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:50056) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qvr26-000ENj-To; Tue, 23 Aug 2011 09:28:47 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> Date: Tue, 23 Aug 2011 09:28:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1082) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 13:27:40 -0000 A MUST here gets enforced just like any other MUST in the IETF -- by = people asking for it. Conformance tests, RFPs, etc. --Richard On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: > Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. >=20 > On Aug 22, 2011, at 1:55 PM, Richard L. Barnes wrote: >=20 >> This seems like a sensible approach. I don't see why CEMA endpoints = should behave any differently from other SIP endpoints with regard to = the use of secure media. If either party desires or requires the use of = TLS, they can negotiate it in SDP, as Hadriel notes. ISTM that the = traditional "MUST implement / MAY use" pattern applies here. >>=20 >> --Richard >>=20 >>=20 >> On Aug 22, 2011, at 1:21 PM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. >>> To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) >>> Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can = use it in its offer to communicate with RFC 4975 UAS. =20 >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >>>=20 >>>> The CEMA draft, the latest incarnation of session matching, is = almost ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>>>=20 >>>> Because the purpose of CEMA is enabling end-to-end encryption, = there has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>>>=20 >>>> On the optional side are the following arguments: >>>>=20 >>>> o TLS consumes resources, more so than TCP >>>>=20 >>>> o TLS requires certificates in the end point >>>>=20 >>>> o Non-CEMA endpoints have only a MAY requirement for TLS, and = thus few if any implement TLS >>>>=20 >>>> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>>>=20 >>>>=20 >>>> On the mandatory side are the following arguments: >>>>=20 >>>> o While TLS consumes resources, most mobile devices have more = than enough compute and battery resources to do TLS. >>>>=20 >>>> o TLS does not impact middleboxes whatsoever >>>>=20 >>>> o The primary market for CEMA initially is 3GPP IMS. In 3GPP = IMS, all endpoints have rooted, trusted certificates. >>>>=20 >>>> o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>>>=20 >>>> o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >>>>=20 >>>> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>>>=20 >>>> Comments welcome. We really are just one MUST versus MAY away from = getting this finished. >>>>=20 >>>> Thanks. >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 From emil@sip-communicator.org Tue Aug 23 03:56:05 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07D721F86FF for ; Tue, 23 Aug 2011 03:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQDU+nkVQ6U9 for ; Tue, 23 Aug 2011 03:56:05 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C41A221F86E0 for ; Tue, 23 Aug 2011 03:56:04 -0700 (PDT) Received: by fxe6 with SMTP id 6so181506fxe.31 for ; Tue, 23 Aug 2011 03:57:11 -0700 (PDT) Received: by 10.223.28.89 with SMTP id l25mr3540854fac.34.1314097031622; Tue, 23 Aug 2011 03:57:11 -0700 (PDT) Received: from camionet.local ([2a01:e35:2437:3250:45f4:416:214a:8699]) by mx.google.com with ESMTPS id b14sm38453fab.19.2011.08.23.03.57.09 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Aug 2011 03:57:10 -0700 (PDT) Message-ID: <4E538785.4000208@jitsi.org> Date: Tue, 23 Aug 2011 12:57:09 +0200 From: Emil Ivov Organization: Jitsi User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; bg; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <3DE981A1-0984-4476-BE60-7B0C31C8C7D1@ag-projects.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 23 Aug 2011 06:51:28 -0700 Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] XCAP clients in the real world X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 10:56:05 -0000 Hey I=C3=B1aki, =D0=9D=D0=B0 22.08.11 22:03, I=C3=B1aki Baz Castillo =D0=BD=D0=B0=D0=BF=D0= =B8=D1=81=D0=B0: > 2011/8/22 Emil Ivov : >> Speaking of XCAP implementations, people here would probably be intere= sted >> in Jitsi too. >> >> http://jitsi.org >> >> XCAP support for Windows, Mac OS X, and Linux. >=20 > How good is the XCAP support?=20 Good enough I suppose. We are using it with OpenXCAP on a daily basis without any issues and we've had success reports for other impls too. > when I tested it some time ago it was > really buggy. For example, I tryed to report the following bug > (but was impossible to use Jira web tracker): I couldn't find your report on our mailing lists (which is where we take them) so feel free to post there: http://jitsi.org/mailinglists Cheers, Emil > When Jitsi uploads the resource-list (XCAP PUT) it set a wrong Content-= Type: >=20 >=20 > ----------------------------------------- > PUT /resource-lists/users/sip:alice@example.org/index HTTP/1.1' > Connection: close' > Content-Length: 231' > Content-Type: application/xcap-caps+xml' > Content-Encoding: UTF-8' > Host: example.org:800' > User-Agent: Apache-HttpClient/4.0.1 (java 1.5)' > Expect: 100-Continue' >=20 > xmlns=3D"urn:ietf:params:xml:ns:resource-lists"> name=3D"RootGroup"> uri=3D"sip:bob@example.org"/> > --------------------------------------- >=20 >=20 > Why is it using "Content-Type: application/xcap-caps+xml"? Such mime > type is just for discovering XCAP Server Capabilities: > http://tools.ietf.org/html/rfc4825#section-12 >=20 > The mime type for a resource-lists document must be > application/resource-lists+xml: > http://tools.ietf.org/html/rfc4826#section-3.4.2 >=20 > Regards. From eburger@standardstrack.com Tue Aug 23 12:57:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7AA21F8CEF for ; Tue, 23 Aug 2011 12:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=1.076, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCgmAgDHIn+3 for ; Tue, 23 Aug 2011 12:57:38 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3238521F8CEB for ; Tue, 23 Aug 2011 12:57:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=cHq+yPDyIAgX9ca2YbnameHcE7N6aVhCxWzlZZnEStgAgNN8xrRFrcIDDlcegCOdFv5eN7dhnFtj+xZF+K/7MP2yzF9R4L7m9hUIr+AfF4pcenFy6jsh3YUk1elC/YHT; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qvx7V-0006WI-2l; Tue, 23 Aug 2011 12:58:45 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-41-814873489; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Tue, 23 Aug 2011 15:58:42 -0400 Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> To: Richard L. Barnes X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:57:39 -0000 --Apple-Mail-41-814873489 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Right, and if it is not mandated by the RFC it does not get on the = request list. On Aug 23, 2011, at 9:28 AM, Richard L. Barnes wrote: > A MUST here gets enforced just like any other MUST in the IETF -- by = people asking for it. Conformance tests, RFPs, etc. >=20 > --Richard >=20 >=20 >=20 > On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >=20 >> Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. >>=20 >> On Aug 22, 2011, at 1:55 PM, Richard L. Barnes wrote: >>=20 >>> This seems like a sensible approach. I don't see why CEMA endpoints = should behave any differently from other SIP endpoints with regard to = the use of secure media. If either party desires or requires the use of = TLS, they can negotiate it in SDP, as Hadriel notes. ISTM that the = traditional "MUST implement / MAY use" pattern applies here. >>>=20 >>> --Richard >>>=20 >>>=20 >>> On Aug 22, 2011, at 1:21 PM, Hadriel Kaplan wrote: >>>=20 >>>>=20 >>>> I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. >>>> To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) >>>> Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it can = use it in its offer to communicate with RFC 4975 UAS. =20 >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >>>>=20 >>>>> The CEMA draft, the latest incarnation of session matching, is = almost ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>>>>=20 >>>>> Because the purpose of CEMA is enabling end-to-end encryption, = there has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>>>>=20 >>>>> On the optional side are the following arguments: >>>>>=20 >>>>> o TLS consumes resources, more so than TCP >>>>>=20 >>>>> o TLS requires certificates in the end point >>>>>=20 >>>>> o Non-CEMA endpoints have only a MAY requirement for TLS, and = thus few if any implement TLS >>>>>=20 >>>>> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>>>>=20 >>>>>=20 >>>>> On the mandatory side are the following arguments: >>>>>=20 >>>>> o While TLS consumes resources, most mobile devices have more = than enough compute and battery resources to do TLS. >>>>>=20 >>>>> o TLS does not impact middleboxes whatsoever >>>>>=20 >>>>> o The primary market for CEMA initially is 3GPP IMS. In 3GPP = IMS, all endpoints have rooted, trusted certificates. >>>>>=20 >>>>> o Communicating with an endpoint with a self-signed certificate, = while not offering a defense against man-in-the-middle attacks, is an = improvement over plaintext TCP. Plaintext TCP is subject to = eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>>>>=20 >>>>> o Mandating TLS puts the structure in place for true, end-to-end = security with the deployment of an ubiquitous PKI, such as PGP or DANE. >>>>>=20 >>>>> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>>>>=20 >>>>> Comments welcome. We really are just one MUST versus MAY away = from getting this finished. >>>>>=20 >>>>> Thanks. >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >=20 --Apple-Mail-41-814873489 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjMxOTU4NDJaMCMGCSqGSIb3DQEJ BDEWBBSyP0G9Drmo63ctR0pRxqY7Zu2LQzCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAF2Txbb2b2bC9zpQYjxSVu/DRpMiQXSu6PEs6PgseJcc8QHf JCjnY1SF/fo3yArsWJCgMHMm5CzTQYX59xzumL7W2Pvlbqxrm4jkskqjlY5Ul6tZlqOY5e73GVpe BtZpU6m12NwM77/+DmHAEp6g1V4d22oSUe3VVAb51e9qf4wnF/iFpFAWzaDgn5PtNPYu9aUjrsv9 l/iie4tI2ZaTzCWn4QBac63gSONYRTLS0yGuPcCOOdeagjOOJdiOSpblSpvaSQJ2LseMZM4XZM9B h7YRjuqBrgAnoRouwRtUPxg+URJxPyKVaSfEEJccnBcMStTBnmx2oNc3uyLP51OUyJ8AAAAAAAA= --Apple-Mail-41-814873489-- From rbarnes@bbn.com Tue Aug 23 13:00:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F30B21F8D01 for ; Tue, 23 Aug 2011 13:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.585 X-Spam-Level: X-Spam-Status: No, score=-107.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04FnR29fAR0f for ; Tue, 23 Aug 2011 13:00:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 594CF21F8D00 for ; Tue, 23 Aug 2011 13:00:14 -0700 (PDT) Received: from dhcp89-089-029.bbn.com ([128.89.89.29]:52421) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1QvxA2-000KUV-B8; Tue, 23 Aug 2011 16:01:22 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "Richard L. Barnes" In-Reply-To: Date: Tue, 23 Aug 2011 16:01:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1082) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:00:15 -0000 Ok, so what's the disagreement here? Implementation is mandated by the = RFC, so it goes in the request list, so it's available for users who MAY = use it. Not sure how you get from there to DO NOT BOTHER. HTTPS usage is not required by RFC 2818, but all the browsers do it = anyway. --Richard On Aug 23, 2011, at 3:58 PM, Eric Burger wrote: > Right, and if it is not mandated by the RFC it does not get on the = request list. >=20 > On Aug 23, 2011, at 9:28 AM, Richard L. Barnes wrote: >=20 >> A MUST here gets enforced just like any other MUST in the IETF -- by = people asking for it. Conformance tests, RFPs, etc. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>=20 >>> Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. >>>=20 >>> On Aug 22, 2011, at 1:55 PM, Richard L. Barnes wrote: >>>=20 >>>> This seems like a sensible approach. I don't see why CEMA = endpoints should behave any differently from other SIP endpoints with = regard to the use of secure media. If either party desires or requires = the use of TLS, they can negotiate it in SDP, as Hadriel notes. ISTM = that the traditional "MUST implement / MAY use" pattern applies here. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>> On Aug 22, 2011, at 1:21 PM, Hadriel Kaplan wrote: >>>>=20 >>>>>=20 >>>>> I don't understand how one can mandate TLS be used, since it would = break backwards-compatibility=85 for which this whole thing has taken = all this time. >>>>> To use TLS, the m=3D line must indicate it, and the "msrps" scheme = path is used. (well, the latter is not as clear as the former) >>>>> Since RFC 4975 did not mandate TLS, a CEMA UAC cannot assume it = can use it in its offer to communicate with RFC 4975 UAS. =20 >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>>=20 >>>>> On Aug 22, 2011, at 12:37 PM, Eric Burger wrote: >>>>>=20 >>>>>> The CEMA draft, the latest incarnation of session matching, is = almost ready for submission. As you may recall from the list and live = discussion in Quebec City (archived and minuted), the point of CEMA is = not to make life easy for middleboxes. The point is to make it = *possible* for end-to-end encryption to occur in the common topology = where there happen to be middleboxes. A side effect is life is a lot = easier for middleboxes, which one could consider the carrot to get the = middlebox manufacturers and service providers to adopt CEMA, is it makes = life easier for them. >>>>>>=20 >>>>>> Because the purpose of CEMA is enabling end-to-end encryption, = there has been some debate as to whether, when two CEMA-endpoints are = negotiating, TLS is mandatory or optional. >>>>>>=20 >>>>>> On the optional side are the following arguments: >>>>>>=20 >>>>>> o TLS consumes resources, more so than TCP >>>>>>=20 >>>>>> o TLS requires certificates in the end point >>>>>>=20 >>>>>> o Non-CEMA endpoints have only a MAY requirement for TLS, and = thus few if any implement TLS >>>>>>=20 >>>>>> o TLS does not provide bullet-proof security, due to = vulnerabilities from self-signed certificates or alternate root = certificate hijacking >>>>>>=20 >>>>>>=20 >>>>>> On the mandatory side are the following arguments: >>>>>>=20 >>>>>> o While TLS consumes resources, most mobile devices have more = than enough compute and battery resources to do TLS. >>>>>>=20 >>>>>> o TLS does not impact middleboxes whatsoever >>>>>>=20 >>>>>> o The primary market for CEMA initially is 3GPP IMS. In 3GPP = IMS, all endpoints have rooted, trusted certificates. >>>>>>=20 >>>>>> o Communicating with an endpoint with a self-signed = certificate, while not offering a defense against man-in-the-middle = attacks, is an improvement over plaintext TCP. Plaintext TCP is subject = to eavesdropping attacks. Moreover, mandating TLS raises the bar for = man-in-the-middle attacks or alteration attacks, as the attacker much = generate the appropriate certificates, potentially on the fly. >>>>>>=20 >>>>>> o Mandating TLS puts the structure in place for true, = end-to-end security with the deployment of an ubiquitous PKI, such as = PGP or DANE. >>>>>>=20 >>>>>> o Not mandating TLS means CEMA perpetuates the invitation for = downgrade attacks. This would be a structural problem that the = deployment of a ubiquitous PKI would not fix. >>>>>>=20 >>>>>> Comments welcome. We really are just one MUST versus MAY away = from getting this finished. >>>>>>=20 >>>>>> Thanks. >>>>>=20 >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>=20 >>>=20 >>=20 >=20 From HKaplan@acmepacket.com Tue Aug 23 14:10:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DC821F8D4A for ; Tue, 23 Aug 2011 14:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXOLrdSSnJn5 for ; Tue, 23 Aug 2011 14:10:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0A721F8D2D for ; Tue, 23 Aug 2011 14:10:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 23 Aug 2011 17:11:27 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 23 Aug 2011 17:11:27 -0400 From: Hadriel Kaplan To: Eric Burger Date: Tue, 23 Aug 2011 17:11:24 -0400 Thread-Topic: [Simple] TLS or Not for CEMA Thread-Index: Acxh2ThzpBReJrBdQKi4N8DIrALQAQ== Message-ID: <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> In-Reply-To: <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 21:10:28 -0000 On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: > Right, and since there are no protocol police, MUST implement / MAY use = =3D DO NOT BOTHER. >=20 If there's demand for it, people will do it. If there isn't demand, we sho= uldn't be in the business of creating an artificial one. We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, etc. -hadriel From eburger@standardstrack.com Tue Aug 23 20:04:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4905321F8B64 for ; Tue, 23 Aug 2011 20:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5uR9K7f173P for ; Tue, 23 Aug 2011 20:04:57 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 81DC921F8B4C for ; Tue, 23 Aug 2011 20:04:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=c+WN1J/F7p76xXzFpXs2HXTxhyFyuVMdspFvPi3YCj70lf9B+ZuGkhyeQopTM9dbAQE6KV0pIgZTzCayrky/6okP1ef6AY6sJKWwU6atuW23s33AEz9515wpO/nmcBQJ; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qw3n2-00010z-G4; Tue, 23 Aug 2011 20:06:05 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-4-840510573; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> Date: Tue, 23 Aug 2011 23:05:59 -0400 Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 03:04:58 -0000 --Apple-Mail-4-840510573 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii THANK YOU FOR THE OPENING!!! Let's see. TLS was published in January, 1999. Let's look at the other = references: SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. So, if only TLS was invented twenty years earlier, are you saying we = would not have this problem? I will venture to be politically incorrect here: are what we are saying = is that we always had slavery, but in the past some folks MAY be free, = so it is fine to say people SHOULD be free today, because people were = not free in the past? I think most folks would say people MUST be free, = especially *because* people were not free in the past. Remember the = obligation to repair the world. Let us not fall down in our duty. On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >=20 > On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >=20 >> Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. >>=20 >=20 > If there's demand for it, people will do it. If there isn't demand, = we shouldn't be in the business of creating an artificial one. > We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, = etc. >=20 > -hadriel >=20 --Apple-Mail-4-840510573 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjQwMzA1NTlaMCMGCSqGSIb3DQEJ BDEWBBQzLibgZCrYLaopVkwLdN5yxaLPcDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBABYzISWnmg37jgw6M8JNxxBg7P0+XJo3xYfjISpHbFUHDG15 jEf/rfsMTH0cflnS9m1F76BIdM9AwoKUs6MMoOfXla4HIv8QjPO6n/dkAHWZ7dAYoMAZKLyV2zec DKjHANfBpf9ER5hkM++v/aG9ql4eIOXtIgYpYRqDZbqcwSSmwg/DcLRJSe3nwxqc5kOiVMeYNzgJ XVmWHcwbbPxWyHCvuFbEUj0W7YiuHnu0F5IZMVQxez8pzKtzuUkK96v+BarkuB+UCGwUfLch4V8A 4AbKjproRO3yCDz9xtE1Cip1ap9Nh9OeY1XYiRBGfl1ZeNsV1HgxReS7WkP2NhDnH7UAAAAAAAA= --Apple-Mail-4-840510573-- From rbarnes@bbn.com Tue Aug 23 20:46:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1788D21F8596 for ; Tue, 23 Aug 2011 20:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.604 X-Spam-Level: X-Spam-Status: No, score=-106.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYQEBpcclHDZ for ; Tue, 23 Aug 2011 20:46:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6C76121F8586 for ; Tue, 23 Aug 2011 20:46:24 -0700 (PDT) Received: from [128.89.255.107] (port=54330 helo=[192.168.1.12]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qw4RA-000ODT-Ct; Tue, 23 Aug 2011 23:47:33 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Tue, 23 Aug 2011 23:47:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <466B57A8-F72E-4292-8873-607BDB29CA40@bbn.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> To: Eric Burger X-Mailer: Apple Mail (2.1082) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 03:46:25 -0000 This is the IETF. We could have revved those protocols to require TLS = at any point in the 12 years that TLS has been around. All of those = protocols have active standardization work, and somehow nobody has found = that adding "MUST USE" TLS requirement was something that would be = useful. In any case, let's get real here. TLS does not "just work". In order = for TLS to work between two endpoints, they needs to be some key = agreement -- some way for them to recognize each other, usually a = mutually trusted PKIX trust anchor. Unless you have a solution for = key/cert management, requiring TLS as a "MUST USE" doesn't help = anything; it will just cause sessions to fail. =20 The one example that we have of a protocol that has "MUST USE TLS" is = RELOAD, and the only reason that works is that RELOAD explicitly defines = a certificate management model, via the enrollment server. In order to = make "MUST USE TLS" work for this application, you would have to define = a similar model for SIP. RFC 6072 is out there, but as far as I know, = it's not widely used. Can you point to any prior art that show that "MUST USE TLS" would = actually have any positive impact? --Richard On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: > THANK YOU FOR THE OPENING!!! >=20 > Let's see. TLS was published in January, 1999. Let's look at the = other references: >=20 > SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >=20 > Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >=20 > RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >=20 > POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >=20 > SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >=20 > HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >=20 >=20 > So, if only TLS was invented twenty years earlier, are you saying we = would not have this problem? >=20 > I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >=20 >=20 > On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >=20 >>=20 >> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>=20 >>> Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. >>>=20 >>=20 >> If there's demand for it, people will do it. If there isn't demand, = we shouldn't be in the business of creating an artificial one. >> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, = etc. >>=20 >> -hadriel >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Wed Aug 24 01:44:00 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C98621F8B06 for ; Wed, 24 Aug 2011 01:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EWcR+oN0A8J for ; Wed, 24 Aug 2011 01:43:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E43D21F8AFE for ; Wed, 24 Aug 2011 01:43:59 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 24 Aug 2011 04:45:05 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 24 Aug 2011 04:45:04 -0400 From: Hadriel Kaplan To: Eric Burger Date: Wed, 24 Aug 2011 04:45:04 -0400 Thread-Topic: [Simple] TLS or Not for CEMA Thread-Index: AcxiOh6ZP/RhWEjrSTWsG02d+IJLhw== Message-ID: <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 08:44:00 -0000 Are you seriously comparing mandating TLS with human rights??? Wow. I think you need to step away from the computer and go on a vacation = with human beings and get some perspective. ;) As to your other points - I don't know what we'd do today for those protoco= ls - given the behavior of the IETF we'd probably never publish any of them= today. (seriously) IMO that's a problem with the IETF rather than a probl= em with the protocols. Instead of just publishing RFCs for the purpose of = interoperating while giving us freedom to make our own decisions, it's abou= t enslaving us to holier-than-thou Commandments. Live free or die! -hadriel On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: > THANK YOU FOR THE OPENING!!! >=20 > Let's see. TLS was published in January, 1999. Let's look at the other = references: >=20 > SMTP: published August, 1982. 17 years before TLS came out. Older than = some IETF participants. As published today, requirers it. >=20 > Telnet: published May, 1983. 16 years before TLS came out. If publishe= d today, would undoubtably require it. >=20 > RTP: published January, 1996. Doesn't run over TCP, so red herring. Ho= wever, lots of effort to make SRTP, DTLS, ZRTP, et al. work today. Lots of= folks wish there was a single way of doing secure RTP, key exchange, and s= ecure key exchange signaling. [BTW, if anyone on the list is interested in= doing this kind of work, please send me an email off-list.] >=20 > POP3: published May, 1996. 13 years before TLS came out. If published t= oday, would undoubtably require it. See IMAP for the existence proof. >=20 > SIP: published March, 1999. Suggested one use this new thing called TLS= . Who knew if TLS was going to work. It does. Let us get on the bus. >=20 > HTTP: published June, 1999. Suggested one use this new thing called TLS= . Fast forward 12 years. Industry wishes everything was TLS. Market is s= tarting to push that way. >=20 >=20 > So, if only TLS was invented twenty years earlier, are you saying we woul= d not have this problem? >=20 > I will venture to be politically incorrect here: are what we are saying i= s that we always had slavery, but in the past some folks MAY be free, so it= is fine to say people SHOULD be free today, because people were not free i= n the past? I think most folks would say people MUST be free, especially *= because* people were not free in the past. Remember the obligation to repa= ir the world. Let us not fall down in our duty. >=20 >=20 > On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >=20 >>=20 >> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>=20 >>> Right, and since there are no protocol police, MUST implement / MAY use= =3D DO NOT BOTHER. >>>=20 >>=20 >> If there's demand for it, people will do it. If there isn't demand, we = shouldn't be in the business of creating an artificial one. >> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, etc= . >>=20 >> -hadriel >>=20 >=20 From fluffy@cisco.com Thu Aug 25 17:18:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E49121F8BCD for ; Thu, 25 Aug 2011 17:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.422 X-Spam-Level: X-Spam-Status: No, score=-103.422 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ikNNG3EBTMS for ; Thu, 25 Aug 2011 17:18:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A282A21F8BBC for ; Thu, 25 Aug 2011 17:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3643; q=dns/txt; s=iport; t=1314318009; x=1315527609; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=uugixZJfroIAbYCpOTd5o5xhi3UIj9RIDieFQo0IHa0=; b=Q6YR7baRFXgjHK8zYgzylZB1qXnsUrt3MwScGsVnqAiQdRmBxKFvHDmN xcr4MST5ijdeUkopF19iG2QmelraLNF3+IY3vkzRviXn1ccBtr4gldu84 pmiVBF2yddHzMOyPp5/G58sB/1w0Diq19gyApE3o65HPZKRRvCWwT8c7e w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKHlVk6rRDoJ/2dsb2JhbABDqBB3gUABAQEBAgEBAQEPASc0GwsYLicwBhMih1AEmyABnw+FbGAEh2GLOIUNjA0 X-IronPort-AV: E=Sophos;i="4.68,283,1312156800"; d="scan'208";a="16626928" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-5.cisco.com with ESMTP; 26 Aug 2011 00:20:09 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7Q0K7PM003887 for ; Fri, 26 Aug 2011 00:20:08 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> Date: Thu, 25 Aug 2011 18:20:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 00:18:55 -0000 Uh, wow - looks like we are getting closer to consensus on this draft. = Let me know when it get's published. I think this current thread is = fairly crazy. I'm pretty sure I disagree with at least half the folks on = this thread but I'll wait to read the draft first.=20 On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >=20 > Are you seriously comparing mandating TLS with human rights??? > Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >=20 > As to your other points - I don't know what we'd do today for those = protocols - given the behavior of the IETF we'd probably never publish = any of them today. (seriously) IMO that's a problem with the IETF = rather than a problem with the protocols. Instead of just publishing = RFCs for the purpose of interoperating while giving us freedom to make = our own decisions, it's about enslaving us to holier-than-thou = Commandments. >=20 > Live free or die! >=20 > -hadriel >=20 >=20 > On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >=20 >> THANK YOU FOR THE OPENING!!! >>=20 >> Let's see. TLS was published in January, 1999. Let's look at the = other references: >>=20 >> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>=20 >> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>=20 >> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>=20 >> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>=20 >> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>=20 >> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>=20 >>=20 >> So, if only TLS was invented twenty years earlier, are you saying we = would not have this problem? >>=20 >> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>=20 >>=20 >> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>=20 >>>> Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. >>>>=20 >>>=20 >>> If there's demand for it, people will do it. If there isn't demand, = we shouldn't be in the business of creating an artificial one. >>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, = etc. >>>=20 >>> -hadriel >>>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From HKaplan@acmepacket.com Fri Aug 26 01:07:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AA621F8B16 for ; Fri, 26 Aug 2011 01:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hFUQlqfppSW for ; Fri, 26 Aug 2011 01:07:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E912121F8AF8 for ; Fri, 26 Aug 2011 01:07:50 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 26 Aug 2011 04:09:01 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 26 Aug 2011 04:09:01 -0400 From: Hadriel Kaplan To: Simple WG Date: Fri, 26 Aug 2011 04:09:00 -0400 Thread-Topic: [Simple] TLS or Not for CEMA Thread-Index: Acxjx2lvBvsnWNN3QfecNCXprmPHwQ== Message-ID: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> In-Reply-To: <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 08:07:51 -0000 It occurs to me my statements below may sound angry or threatening to those= who don't know me or some background. The phrase "Live free or die" is the State motto and written on every licen= se plate of the US State of New Hampshire, where I live, and Eric used to l= ive for many years. So I knew Eric would get the reference. I did not lit= erally mean it as a challenge to perish. -hadriel p.s. sometimes my attempt at humor/levity falls flat. :( > On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >=20 >>=20 >> Are you seriously comparing mandating TLS with human rights??? >> Wow. I think you need to step away from the computer and go on a vacati= on with human beings and get some perspective. ;) >>=20 >> As to your other points - I don't know what we'd do today for those prot= ocols - given the behavior of the IETF we'd probably never publish any of t= hem today. (seriously) IMO that's a problem with the IETF rather than a pr= oblem with the protocols. Instead of just publishing RFCs for the purpose = of interoperating while giving us freedom to make our own decisions, it's a= bout enslaving us to holier-than-thou Commandments. >>=20 >> Live free or die! >>=20 >> -hadriel >>=20 From christer.holmberg@ericsson.com Fri Aug 26 02:36:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429321F8B39 for ; Fri, 26 Aug 2011 02:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvT-uAw3d6s1 for ; Fri, 26 Aug 2011 02:36:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4F23B21F8B27 for ; Fri, 26 Aug 2011 02:36:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-6e-4e57695feef2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5E.93.20773.F59675E4; Fri, 26 Aug 2011 11:37:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 26 Aug 2011 11:37:35 +0200 From: Christer Holmberg To: Cullen Jennings , Simple WG Date: Fri, 26 Aug 2011 11:36:28 +0200 Thread-Topic: [Simple] TLS or Not for CEMA Thread-Index: AcxjhezFmF+rNLk1QJWF3WiZzHf8RAATbTHH Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> In-Reply-To: <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 09:36:21 -0000 Cullen, If you have an opinion on the specific topic currently being discussed, I t= hink it would be helpful if you could give it before a new draft is availab= le... Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Cullen= Jennings [fluffy@cisco.com] Sent: Friday, August 26, 2011 3:20 AM To: Simple WG Subject: Re: [Simple] TLS or Not for CEMA Uh, wow - looks like we are getting closer to consensus on this draft. Let = me know when it get's published. I think this current thread is fairly craz= y. I'm pretty sure I disagree with at least half the folks on this thread b= ut I'll wait to read the draft first. On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: > > Are you seriously comparing mandating TLS with human rights??? > Wow. I think you need to step away from the computer and go on a vacatio= n with human beings and get some perspective. ;) > > As to your other points - I don't know what we'd do today for those proto= cols - given the behavior of the IETF we'd probably never publish any of th= em today. (seriously) IMO that's a problem with the IETF rather than a pro= blem with the protocols. Instead of just publishing RFCs for the purpose o= f interoperating while giving us freedom to make our own decisions, it's ab= out enslaving us to holier-than-thou Commandments. > > Live free or die! > > -hadriel > > > On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: > >> THANK YOU FOR THE OPENING!!! >> >> Let's see. TLS was published in January, 1999. Let's look at the other= references: >> >> SMTP: published August, 1982. 17 years before TLS came out. Older = than some IETF participants. As published today, requirers it. >> >> Telnet: published May, 1983. 16 years before TLS came out. If pub= lished today, would undoubtably require it. >> >> RTP: published January, 1996. Doesn't run over TCP, so red herring= . However, lots of effort to make SRTP, DTLS, ZRTP, et al. work today. Lo= ts of folks wish there was a single way of doing secure RTP, key exchange, = and secure key exchange signaling. [BTW, if anyone on the list is interest= ed in doing this kind of work, please send me an email off-list.] >> >> POP3: published May, 1996. 13 years before TLS came out. If publis= hed today, would undoubtably require it. See IMAP for the existence proof. >> >> SIP: published March, 1999. Suggested one use this new thing calle= d TLS. Who knew if TLS was going to work. It does. Let us get on the bus= . >> >> HTTP: published June, 1999. Suggested one use this new thing calle= d TLS. Fast forward 12 years. Industry wishes everything was TLS. Market= is starting to push that way. >> >> >> So, if only TLS was invented twenty years earlier, are you saying we wou= ld not have this problem? >> >> I will venture to be politically incorrect here: are what we are saying = is that we always had slavery, but in the past some folks MAY be free, so i= t is fine to say people SHOULD be free today, because people were not free = in the past? I think most folks would say people MUST be free, especially = *because* people were not free in the past. Remember the obligation to rep= air the world. Let us not fall down in our duty. >> >> >> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >> >>> >>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>> >>>> Right, and since there are no protocol police, MUST implement / MAY us= e =3D DO NOT BOTHER. >>>> >>> >>> If there's demand for it, people will do it. If there isn't demand, we= shouldn't be in the business of creating an artificial one. >>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, et= c. >>> >>> -hadriel >>> >> > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From eburger@standardstrack.com Fri Aug 26 03:01:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A55821F85C0 for ; Fri, 26 Aug 2011 03:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeCV0p095CQj for ; Fri, 26 Aug 2011 03:01:01 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id DC3CE21F85AA for ; Fri, 26 Aug 2011 03:01:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=pwWcB+K6cMcdlw6g8RWHIzwR09zxcJu04p/D10E7LYduVlVNJbVUWG05ym/zZ02YnDb0GvoOFVjdIKtHBab+UKANhhhGjc5EHVGmo0JUln8Uq4QKPNxfAki/wpv7RZ0v; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QwtEv-00025A-4O for simple@ietf.org; Fri, 26 Aug 2011 03:02:17 -0700 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-28-1038285476; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 26 Aug 2011 06:02:14 -0400 In-Reply-To: To: Simple WG References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> Message-Id: <2730FA79-B85D-4272-8905-D5DB93FD6BDB@standardstrack.com> X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 10:01:02 -0000 --Apple-Mail-28-1038285476 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At least *I* got it. Of course, given the motorcycle helmet laws, which = are pretty much "please take them off when you cross the border into New = Hampshire," we tended to say the state motto was "Live Free AND Die." On Aug 26, 2011, at 4:09 AM, Hadriel Kaplan wrote: >=20 > It occurs to me my statements below may sound angry or threatening to = those who don't know me or some background. >=20 > The phrase "Live free or die" is the State motto and written on every = license plate of the US State of New Hampshire, where I live, and Eric = used to live for many years. So I knew Eric would get the reference. I = did not literally mean it as a challenge to perish. >=20 > -hadriel > p.s. sometimes my attempt at humor/levity falls flat. :( >=20 >=20 >> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> Are you seriously comparing mandating TLS with human rights??? >>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>=20 >>> As to your other points - I don't know what we'd do today for those = protocols - given the behavior of the IETF we'd probably never publish = any of them today. (seriously) IMO that's a problem with the IETF = rather than a problem with the protocols. Instead of just publishing = RFCs for the purpose of interoperating while giving us freedom to make = our own decisions, it's about enslaving us to holier-than-thou = Commandments. >>>=20 >>> Live free or die! >>>=20 >>> -hadriel >>>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-28-1038285476 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjYxMDAyMTRaMCMGCSqGSIb3DQEJ BDEWBBTNBtWfHwUAw3MonYL+9TdRMqKxNTCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAAKpcFJqH/0NY27xqUPyeJFcMcgXLhIn+qXwWwVBsUIv9s+W yAFPFD1ie849kfuS++NBIZW+SA+NNVLpeFfRHUqJHsLCfnbY2tBwkHre1XvJVhfg/UXJ/zgpnQw/ TBLPbjmWvJl4k+eypcCzoQ0/5EFnDCfBHj0F2GYEDeC17b9iiyKn8U+MU5KNoFjSJovhG/B+9lOb 9efy9uGyr+kndDcwPhiyc+QHPscLO22VHkF3H0eGpyPypM3SWsGnkGIvwlUMtyuHDiDPUZrVzKx3 yiRzZ+uZWa4xRx6gtsrb1Hf9LxOZiUTlfjO2lTb+tb7aIL08FjgxtH0lo3DFDUmiQ4EAAAAAAAA= --Apple-Mail-28-1038285476-- From fluffy@cisco.com Fri Aug 26 05:55:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB5621F85C6 for ; Fri, 26 Aug 2011 05:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.412 X-Spam-Level: X-Spam-Status: No, score=-103.412 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh-6mpEzXGDs for ; Fri, 26 Aug 2011 05:55:49 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1054021F853E for ; Fri, 26 Aug 2011 05:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=594; q=dns/txt; s=iport; t=1314363425; x=1315573025; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VV0ACtAfeglQPtvSNL1HYNfKoDbOvAHkTDlrUdCcI+U=; b=drrGKFDdlHOmT2RgvhRPyUKhGwn/9n/pRm7Y+vQMULfJ0yYIZHPbU3EI 1Y0dsqnTIt2YKAA/lgMRCAxHJL1UUgmibTRr4qd5GmQ8g3o5MeQ8Y6sva u1ZKJCd19OZeihjMQ5vQrQRkisPVEzqV46WGWMas4y4s+zGJou8sGLcQa k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMSXV06rRDoI/2dsb2JhbABCqBh3gUABAQEBAgESASc/BQsLDjhXBjWHUJtcAZ8WhWxgBIdiiziFDYwS X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16784491" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2011 12:57:05 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7QCv3Fd020011; Fri, 26 Aug 2011 12:57:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <2730FA79-B85D-4272-8905-D5DB93FD6BDB@standardstrack.com> Date: Fri, 26 Aug 2011 06:57:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <341DE1CD-8F00-42E4-B305-AEADF50FE29A@cisco.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <2730FA79-B85D-4272-8905-D5DB93FD6BDB@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 12:55:50 -0000 On Aug 26, 2011, at 4:02 AM, Eric Burger wrote: > At least *I* got it. Of course, given the motorcycle helmet laws, = which are pretty much "please take them off when you cross the border = into New Hampshire," we tended to say the state motto was "Live Free AND = Die." It's good to have a goal where at least half of it is very likely to be = achieved. I note that even in New Hampshire, cars MUST implement a seat = belt and users can choose to use them or not with some economic = incentives one way or the other. I guess I could have said "brakes" = instead of "seatbelt" From eburger@standardstrack.com Fri Aug 26 05:57:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C0A21F8B6C for ; Fri, 26 Aug 2011 05:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU-qt6n2xvbE for ; Fri, 26 Aug 2011 05:57:35 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6A21F8B5B for ; Fri, 26 Aug 2011 05:57:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=WQUBatt43LH/T+IOPSWEbDVAwW+vTq/vO4/ffhTW+jky4elo1oYCSVcGfcoa8vSayVcIQu0OxfIpo+GbOz1OtQKMJmzJlnMMKQqVoU6n5Hx8NrmOmh7s3TIR+oXjWKYV; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qwvzk-0000Ef-I7; Fri, 26 Aug 2011 05:58:50 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-58-1048879007; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <341DE1CD-8F00-42E4-B305-AEADF50FE29A@cisco.com> Date: Fri, 26 Aug 2011 08:58:47 -0400 Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com> <5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com> <7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com> <0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com> <9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com> <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <2730FA79-B85D-4272-8905-D5DB93FD6BDB@standardstrack.com> <341DE1CD-8F00-42E4-B305-AEADF50FE29A@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 12:57:35 -0000 --Apple-Mail-58-1048879007 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NH: Mandatory to use for human < 18 years old. On Aug 26, 2011, at 8:57 AM, Cullen Jennings wrote: >=20 > On Aug 26, 2011, at 4:02 AM, Eric Burger wrote: >=20 >> At least *I* got it. Of course, given the motorcycle helmet laws, = which are pretty much "please take them off when you cross the border = into New Hampshire," we tended to say the state motto was "Live Free AND = Die." >=20 > It's good to have a goal where at least half of it is very likely to = be achieved. I note that even in New Hampshire, cars MUST implement a = seat belt and users can choose to use them or not with some economic = incentives one way or the other. I guess I could have said "brakes" = instead of "seatbelt" >=20 --Apple-Mail-58-1048879007 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjYxMjU4NDhaMCMGCSqGSIb3DQEJ BDEWBBQAjElmmXYKnIc+BVhFRZkMEyVy/zCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAFzhlWL6//LUzgBTrjzB/TzuSI25ywB0ADhY1N5VrV35IU5y NnqDiW67WTnyHs563n8TZ6ehkjRO1LPGhfiEjf0Qi2hF4qtnX6P1u0gb8zYECIjn3DiLnItO7J1k QU/wmjOdFvdke7m29jNz7X5t6Edi41BCGmbl4Jbw+n151bdGunp20DQChw/A4jkl9Hq4+DjiOkEE 3eR7wRyFICaB7pzjWVDrYuOMzzqRI4nHdb+JFKhtxIS1Alw9FIVf5x9WAJHHfZfmljQzF3cNi2q0 o4gVxcTgevH3p7sVbXY0gwBAhPzuYtmNVD/NJ0mahrHyEEuA8U665iDVNYrLMkbwUs4AAAAAAAA= --Apple-Mail-58-1048879007-- From fluffy@cisco.com Fri Aug 26 06:07:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EC021F86B1 for ; Fri, 26 Aug 2011 06:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.402 X-Spam-Level: X-Spam-Status: No, score=-103.402 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noCVSlXykYWW for ; Fri, 26 Aug 2011 06:07:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA9621F85E3 for ; Fri, 26 Aug 2011 06:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4656; q=dns/txt; s=iport; t=1314364151; x=1315573751; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=OiWPouhhMhGiV1+QKaDKo3PFjZptvfanqx7EqrLzirU=; b=MvB5jNjihRDNOn8jktsKkNwPf/45qppsquOgwnUmF6fBHM71EymLb49s JGbJZGngJqTxxh3seI6FVzh/RmdpIHxZzpldMzNyiciejsCoWMU4F2/nJ YxrqhcH0e+hGORTVUaakbN0zs6uDE153EWfK3hJRHP9faeawPaShNWuwM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEAACiaV06rRDoG/2dsb2JhbABCmDuPXXeBQAEBAQECAQEBAQ8BJzQLBQsLEQQBAQEuJygIBhMih1AEm1UBnxmFbGAEh2KLOIUNjBI X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16784557" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-2.cisco.com with ESMTP; 26 Aug 2011 13:09:11 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7QD992n028787; Fri, 26 Aug 2011 13:09:10 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 26 Aug 2011 07:09:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:07:56 -0000 Yes, my opinion is more or less that until someone changes BCP 61, IETF = work needs to meet BCP 61. Richard more or less summarized BCP 61 for = you and needless to say it roughly says "MUST implement" and explains = why it is not "MUST use" On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: > Cullen, >=20 > If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Cullen Jennings [fluffy@cisco.com] > Sent: Friday, August 26, 2011 3:20 AM > To: Simple WG > Subject: Re: [Simple] TLS or Not for CEMA >=20 > Uh, wow - looks like we are getting closer to consensus on this draft. = Let me know when it get's published. I think this current thread is = fairly crazy. I'm pretty sure I disagree with at least half the folks on = this thread but I'll wait to read the draft first. >=20 >=20 >=20 > On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >=20 > > > > Are you seriously comparing mandating TLS with human rights??? > > Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) > > > > As to your other points - I don't know what we'd do today for those = protocols - given the behavior of the IETF we'd probably never publish = any of them today. (seriously) IMO that's a problem with the IETF = rather than a problem with the protocols. Instead of just publishing = RFCs for the purpose of interoperating while giving us freedom to make = our own decisions, it's about enslaving us to holier-than-thou = Commandments. > > > > Live free or die! > > > > -hadriel > > > > > > On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: > > > >> THANK YOU FOR THE OPENING!!! > >> > >> Let's see. TLS was published in January, 1999. Let's look at the = other references: > >> > >> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. > >> > >> Telnet: published May, 1983. 16 years before TLS came out. = If published today, would undoubtably require it. > >> > >> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] > >> > >> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. > >> > >> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. > >> > >> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. > >> > >> > >> So, if only TLS was invented twenty years earlier, are you saying = we would not have this problem? > >> > >> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. > >> > >> > >> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: > >> > >>> > >>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: > >>> > >>>> Right, and since there are no protocol police, MUST implement / = MAY use =3D DO NOT BOTHER. > >>>> > >>> > >>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. > >>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. > >>> > >>> -hadriel > >>> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Fri Aug 26 06:10:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DEC21F8B6B for ; Fri, 26 Aug 2011 06:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxmVhuBuvNPI for ; Fri, 26 Aug 2011 06:10:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 61D9321F8B5F for ; Fri, 26 Aug 2011 06:10:19 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-00-4e579b75144e Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 32.B2.20773.57B975E4; Fri, 26 Aug 2011 15:11:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 26 Aug 2011 15:11:17 +0200 From: Christer Holmberg To: 'Cullen Jennings' Date: Fri, 26 Aug 2011 15:11:16 +0200 Thread-Topic: [Simple] TLS or Not for CEMA Thread-Index: Acxj8VpIp6GDJ8orT+esmt/TP1QrNwAAECAg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45F88@ESESSCMS0356.eemea.ericsson.se> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> In-Reply-To: <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:10:20 -0000 Thanks! :) Regards, Christer=20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: 26. elokuuta 2011 16:09 To: Christer Holmberg Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA Yes, my opinion is more or less that until someone changes BCP 61, IETF wor= k needs to meet BCP 61. Richard more or less summarized BCP 61 for you and = needless to say it roughly says "MUST implement" and explains why it is not= "MUST use" On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: > Cullen, >=20 > If you have an opinion on the specific topic currently being discussed, I= think it would be helpful if you could give it before a new draft is avail= able... >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of=20 > Cullen Jennings [fluffy@cisco.com] > Sent: Friday, August 26, 2011 3:20 AM > To: Simple WG > Subject: Re: [Simple] TLS or Not for CEMA >=20 > Uh, wow - looks like we are getting closer to consensus on this draft. Le= t me know when it get's published. I think this current thread is fairly cr= azy. I'm pretty sure I disagree with at least half the folks on this thread= but I'll wait to read the draft first. >=20 >=20 >=20 > On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >=20 > > > > Are you seriously comparing mandating TLS with human rights??? > > Wow. I think you need to step away from the computer and go on a=20 > > vacation with human beings and get some perspective. ;) > > > > As to your other points - I don't know what we'd do today for those pro= tocols - given the behavior of the IETF we'd probably never publish any of = them today. (seriously) IMO that's a problem with the IETF rather than a p= roblem with the protocols. Instead of just publishing RFCs for the purpose= of interoperating while giving us freedom to make our own decisions, it's = about enslaving us to holier-than-thou Commandments. > > > > Live free or die! > > > > -hadriel > > > > > > On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: > > > >> THANK YOU FOR THE OPENING!!! > >> > >> Let's see. TLS was published in January, 1999. Let's look at the oth= er references: > >> > >> SMTP: published August, 1982. 17 years before TLS came out. Olde= r than some IETF participants. As published today, requirers it. > >> > >> Telnet: published May, 1983. 16 years before TLS came out. If p= ublished today, would undoubtably require it. > >> > >> RTP: published January, 1996. Doesn't run over TCP, so red=20 > >> herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al.=20 > >> work today. Lots of folks wish there was a single way of doing=20 > >> secure RTP, key exchange, and secure key exchange signaling. [BTW,=20 > >> if anyone on the list is interested in doing this kind of work,=20 > >> please send me an email off-list.] > >> > >> POP3: published May, 1996. 13 years before TLS came out. If publ= ished today, would undoubtably require it. See IMAP for the existence proo= f. > >> > >> SIP: published March, 1999. Suggested one use this new thing cal= led TLS. Who knew if TLS was going to work. It does. Let us get on the b= us. > >> > >> HTTP: published June, 1999. Suggested one use this new thing cal= led TLS. Fast forward 12 years. Industry wishes everything was TLS. Mark= et is starting to push that way. > >> > >> > >> So, if only TLS was invented twenty years earlier, are you saying we w= ould not have this problem? > >> > >> I will venture to be politically incorrect here: are what we are sayin= g is that we always had slavery, but in the past some folks MAY be free, so= it is fine to say people SHOULD be free today, because people were not fre= e in the past? I think most folks would say people MUST be free, especiall= y *because* people were not free in the past. Remember the obligation to r= epair the world. Let us not fall down in our duty. > >> > >> > >> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: > >> > >>> > >>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: > >>> > >>>> Right, and since there are no protocol police, MUST implement / MAY = use =3D DO NOT BOTHER. > >>>> > >>> > >>> If there's demand for it, people will do it. If there isn't demand, = we shouldn't be in the business of creating an artificial one. > >>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, Telnet, = etc. > >>> > >>> -hadriel > >>> > >> > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From internet-drafts@ietf.org Fri Aug 26 07:00:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C8C21F8B92; Fri, 26 Aug 2011 07:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQiiT5zGF-3r; Fri, 26 Aug 2011 07:00:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 805E621F8B7B; Fri, 26 Aug 2011 07:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110826140025.18306.14880.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2011 07:00:25 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-cema-00.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 14:00:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Eric Burger Filename : draft-ietf-simple-msrp-cema-00.txt Pages : 17 Date : 2011-08-26 This document defines an Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). MSRP endpoints implement this extension to enable secure, end-to-end MSRP communication in networks where Middleboxes anchor the MSRP connection. CEMA eliminates the need for Middleboxes to modify MSRP messages. Modifying MSRP messages requires the Middlebox to read the message in plain text, exposing the message to attack. The document also defines a Session Description Protocol (SDP) attribute, a=3Dmsrp- cema, that MSRP endpoints use to indicate support of the CEMA extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-00.txt From eburger@standardstrack.com Fri Aug 26 07:01:03 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE48E21F8B1F for ; Fri, 26 Aug 2011 07:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi7p5UoACMwW for ; Fri, 26 Aug 2011 07:01:02 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8F01621F86E0 for ; Fri, 26 Aug 2011 07:01:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=TzPrAYrraF65rDF/gGuUI7jc0GN3hMq6CZAJuqeb1rJYY9Cjp23f61dRrt4mMx+t8xOspKoyiShd0C5b8oGQXymMucClsCib+442qnJsDxSar7DwfHIhS4j4kDwA38GS; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QwwzB-0001Al-RV; Fri, 26 Aug 2011 07:02:18 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-61-1052685924; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> Date: Fri, 26 Aug 2011 10:02:14 -0400 Message-Id: <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 14:01:03 -0000 --Apple-Mail-61-1052685924 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >=20 > Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >=20 >=20 > On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >=20 >> Cullen, >>=20 >> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>=20 >> Regards, >>=20 >> Christer >>=20 >> ________________________________________ >> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Cullen Jennings [fluffy@cisco.com] >> Sent: Friday, August 26, 2011 3:20 AM >> To: Simple WG >> Subject: Re: [Simple] TLS or Not for CEMA >>=20 >> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>=20 >>=20 >>=20 >> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> Are you seriously comparing mandating TLS with human rights??? >>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>=20 >>> As to your other points - I don't know what we'd do today for those = protocols - given the behavior of the IETF we'd probably never publish = any of them today. (seriously) IMO that's a problem with the IETF = rather than a problem with the protocols. Instead of just publishing = RFCs for the purpose of interoperating while giving us freedom to make = our own decisions, it's about enslaving us to holier-than-thou = Commandments. >>>=20 >>> Live free or die! >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>=20 >>>> THANK YOU FOR THE OPENING!!! >>>>=20 >>>> Let's see. TLS was published in January, 1999. Let's look at the = other references: >>>>=20 >>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>=20 >>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>=20 >>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>=20 >>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>=20 >>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>=20 >>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>=20 >>>>=20 >>>> So, if only TLS was invented twenty years earlier, are you saying = we would not have this problem? >>>>=20 >>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>=20 >>>>=20 >>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>=20 >>>>>=20 >>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>=20 >>>>>> Right, and since there are no protocol police, MUST implement / = MAY use =3D DO NOT BOTHER. >>>>>>=20 >>>>>=20 >>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-61-1052685924 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjYxNDAyMTVaMCMGCSqGSIb3DQEJ BDEWBBRrdJKf/GHFururloFg5gLwshtNSDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAHoEVFoTpsxeKciCvURpcd7J8sfy+0By4Z8s6uyizn0L1JRK 6a85IpBQlN7jnuQyeAtQzsnWrw8Bgldu0119jFN7UKxKVwICpcdxH73jT+5QgZipXrV0ivl9/Bp7 f2T44RAdTOKQ+c5uL/KTcin/GO1LvBDFXsCQwRNWs4dhNQTuKtCOT4TiE1a6vRgnnA/HR1Ui1Ruu tVMyk4vvC9e5GDikLi79A7dfCVCQwGNH/5bv3QR470POlzlhX+vN0T4LtUb5B2e9FlqxcBYryfZD ZAf9XAJrcnUp09JeSKafiNgvesYESKZQ9k6pFdo78z8wC9XXbxL4zZ7RFcyxQ+r0++0AAAAAAAA= --Apple-Mail-61-1052685924-- From fluffy@cisco.com Fri Aug 26 07:09:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B05821F8BAD for ; Fri, 26 Aug 2011 07:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.392 X-Spam-Level: X-Spam-Status: No, score=-103.392 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-HfgrIUWx3I for ; Fri, 26 Aug 2011 07:09:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 7E36321F8B51 for ; Fri, 26 Aug 2011 07:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5586; q=dns/txt; s=iport; t=1314367830; x=1315577430; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=w0F0HYaizKuzQihUkVAW7nk7eVJ1PzFpUarXZTD2StA=; b=bhdAj4wwEZ8Pc8oSbRKkMvvj8KiEsipUqfhGqZbyQqo/N1O1zntBl8be 0k0ljQCDa0IKIoOAmyCzMbGEBHySgukuElI5XRLf8zvyO7+o7jsTFBb1M 9B4kPy6P3R+Mg2FQ4WHZ/cMNFVvqEeYmsosew+dtyEoetuUNXsXY5Er/7 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEAAC6oV06rRDoJ/2dsb2JhbABCmDuPXXeBQAEBAQECAQEBAQ8BJzQLBQsLDgMEAQEBLicoCAYTIodQBJpzAZ8ZhWxgBIdiiziFDYwS X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16807350" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2011 14:10:29 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7QEASLF032706; Fri, 26 Aug 2011 14:10:28 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> Date: Fri, 26 Aug 2011 08:10:27 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 14:09:14 -0000 Are you seriously saying no one would ever use MSRP in an enterprise = network?=20 On Aug 26, 2011, at 8:02 AM, Eric Burger wrote: > In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. >=20 > On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >=20 >>=20 >> Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >>=20 >>=20 >> On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >>=20 >>> Cullen, >>>=20 >>> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> ________________________________________ >>> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Cullen Jennings [fluffy@cisco.com] >>> Sent: Friday, August 26, 2011 3:20 AM >>> To: Simple WG >>> Subject: Re: [Simple] TLS or Not for CEMA >>>=20 >>> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>>=20 >>>=20 >>>=20 >>> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>>=20 >>>>=20 >>>> Are you seriously comparing mandating TLS with human rights??? >>>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>>=20 >>>> As to your other points - I don't know what we'd do today for those = protocols - given the behavior of the IETF we'd probably never publish = any of them today. (seriously) IMO that's a problem with the IETF = rather than a problem with the protocols. Instead of just publishing = RFCs for the purpose of interoperating while giving us freedom to make = our own decisions, it's about enslaving us to holier-than-thou = Commandments. >>>>=20 >>>> Live free or die! >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>>=20 >>>>> THANK YOU FOR THE OPENING!!! >>>>>=20 >>>>> Let's see. TLS was published in January, 1999. Let's look at the = other references: >>>>>=20 >>>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>>=20 >>>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>>=20 >>>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>>=20 >>>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>>=20 >>>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>>=20 >>>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>>=20 >>>>>=20 >>>>> So, if only TLS was invented twenty years earlier, are you saying = we would not have this problem? >>>>>=20 >>>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>>=20 >>>>>=20 >>>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>>=20 >>>>>>=20 >>>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>>=20 >>>>>>> Right, and since there are no protocol police, MUST implement / = MAY use =3D DO NOT BOTHER. >>>>>>>=20 >>>>>>=20 >>>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 From ben@nostrum.com Fri Aug 26 07:20:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931C21F8B75 for ; Fri, 26 Aug 2011 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItNcwhJEPEUU for ; Fri, 26 Aug 2011 07:20:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC7121F8B63 for ; Fri, 26 Aug 2011 07:20:22 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7QELbwT021284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2011 09:21:38 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> Date: Fri, 26 Aug 2011 09:21:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 14:20:25 -0000 (as individual) On Aug 26, 2011, at 9:02 AM, Eric Burger wrote: > In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. >=20 I think section 7 in BCP 61 is pretty explicit in saying the opposite. = It's MUST implement vs MUST use because of the assumption that any = internet protocol _might_ be used in a walled garden, and it's the = gardener's right to make the decision on whether or not to use. it. As far as MSRP being intended for the wider Internet--the point of BCP = 61 is to say that _all_ IETF protocols are effectively intended for the = wider Internet. (I.e. even if the designers don't intend that, they are = likely to "escape". That doesn't seem to imply any "more Internety" = property for MSRP. > On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >=20 >>=20 >> Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >>=20 >>=20 >> On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >>=20 >>> Cullen, >>>=20 >>> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>> ________________________________________ >>> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Cullen Jennings [fluffy@cisco.com] >>> Sent: Friday, August 26, 2011 3:20 AM >>> To: Simple WG >>> Subject: Re: [Simple] TLS or Not for CEMA >>>=20 >>> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>>=20 >>>=20 >>>=20 >>> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>>=20 >>>>=20 >>>> Are you seriously comparing mandating TLS with human rights??? >>>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>>=20 >>>> As to your other points - I don't know what we'd do today for those = protocols - given the behavior of the IETF we'd probably never publish = any of them today. (seriously) IMO that's a problem with the IETF = rather than a problem with the protocols. Instead of just publishing = RFCs for the purpose of interoperating while giving us freedom to make = our own decisions, it's about enslaving us to holier-than-thou = Commandments. >>>>=20 >>>> Live free or die! >>>>=20 >>>> -hadriel >>>>=20 >>>>=20 >>>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>>=20 >>>>> THANK YOU FOR THE OPENING!!! >>>>>=20 >>>>> Let's see. TLS was published in January, 1999. Let's look at the = other references: >>>>>=20 >>>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>>=20 >>>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>>=20 >>>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>>=20 >>>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>>=20 >>>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>>=20 >>>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>>=20 >>>>>=20 >>>>> So, if only TLS was invented twenty years earlier, are you saying = we would not have this problem? >>>>>=20 >>>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>>=20 >>>>>=20 >>>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>>=20 >>>>>>=20 >>>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>>=20 >>>>>>> Right, and since there are no protocol police, MUST implement / = MAY use =3D DO NOT BOTHER. >>>>>>>=20 >>>>>>=20 >>>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Fri Aug 26 07:34:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04A821F8B82 for ; Fri, 26 Aug 2011 07:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn2Bj9nD0Nry for ; Fri, 26 Aug 2011 07:34:43 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD621F8B62 for ; Fri, 26 Aug 2011 07:34:43 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7QEZvWe022598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 26 Aug 2011 09:35:59 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 09:36:01 -0500 Message-Id: <1E36555C-B8C6-4795-8827-36EF88F09DC2@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Subject: [Simple] Chair note on CEMA TLS discussion thread X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 14:34:43 -0000 (as chair) The recent TLS thread on use of TLS in CEMA includes some posts = suggesting that CEMA is now more about security than about middleboxes. = Please keep in mind that we are not currently chartered to work on MSRP = security improvements, however desirably they might be. That doesn't = mean that the CEMA work can't have side effects that improve security, = just that if that becomes an explicit goal of the work, we may need to = take another look at where the work occurs. That doesn't mean such work = absolutely can't happen in SIMPLE, but it would require rechartering. = (Our charter is pretty explicit about new work.) That being said, in my opinion, the question of whether CEMA has evolved = into a security draft of not depends a lot on the ongoing thread about = whether TLS should be MUST use vs MUST implement. Therefore, we = encourage that discussion to continue, and will likely make a consensus = call on the subject once people have had a few days to read the latest = draft version (published this morning as = draft-ietf-simple-msrp-cema-00). Thanks! Ben.= From eburger@standardstrack.com Fri Aug 26 08:00:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9834221F8593 for ; Fri, 26 Aug 2011 08:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDHasU1Ommpp for ; Fri, 26 Aug 2011 08:00:42 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id B016221F8591 for ; Fri, 26 Aug 2011 08:00:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=Zph2n27RAqdw03g4k2QuJt22znYFAYW7k20t7eRnurrwDITn39GW80wVyQWReMU/CQBmZVGxThqFpHll+SGXph+iJ3mwbKV3Xj3OvtlfMLEQe+rI7MHwyotdznTelnDO; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qwxuv-0001SF-N2; Fri, 26 Aug 2011 08:01:58 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-63-1056266507; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Fri, 26 Aug 2011 11:01:55 -0400 Message-Id: <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:00:43 -0000 --Apple-Mail-63-1056266507 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Naah. They use XMPP :-) Oops - I forgot - that's all TLS. On Aug 26, 2011, at 10:10 AM, Cullen Jennings wrote: >=20 > Are you seriously saying no one would ever use MSRP in an enterprise = network?=20 >=20 >=20 > On Aug 26, 2011, at 8:02 AM, Eric Burger wrote: >=20 >> In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. >>=20 >> On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >>=20 >>>=20 >>> Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >>>=20 >>>=20 >>> On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >>>=20 >>>> Cullen, >>>>=20 >>>> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> ________________________________________ >>>> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf = Of Cullen Jennings [fluffy@cisco.com] >>>> Sent: Friday, August 26, 2011 3:20 AM >>>> To: Simple WG >>>> Subject: Re: [Simple] TLS or Not for CEMA >>>>=20 >>>> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>>>=20 >>>>=20 >>>>=20 >>>> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>>>=20 >>>>>=20 >>>>> Are you seriously comparing mandating TLS with human rights??? >>>>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>>>=20 >>>>> As to your other points - I don't know what we'd do today for = those protocols - given the behavior of the IETF we'd probably never = publish any of them today. (seriously) IMO that's a problem with the = IETF rather than a problem with the protocols. Instead of just = publishing RFCs for the purpose of interoperating while giving us = freedom to make our own decisions, it's about enslaving us to = holier-than-thou Commandments. >>>>>=20 >>>>> Live free or die! >>>>>=20 >>>>> -hadriel >>>>>=20 >>>>>=20 >>>>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>>>=20 >>>>>> THANK YOU FOR THE OPENING!!! >>>>>>=20 >>>>>> Let's see. TLS was published in January, 1999. Let's look at = the other references: >>>>>>=20 >>>>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>>>=20 >>>>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>>>=20 >>>>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>>>=20 >>>>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>>>=20 >>>>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>>>=20 >>>>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>>>=20 >>>>>>=20 >>>>>> So, if only TLS was invented twenty years earlier, are you saying = we would not have this problem? >>>>>>=20 >>>>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>>>=20 >>>>>>=20 >>>>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>>>=20 >>>>>>>> Right, and since there are no protocol police, MUST implement / = MAY use =3D DO NOT BOTHER. >>>>>>>>=20 >>>>>>>=20 >>>>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>>>=20 >>>>>>> -hadriel >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>>=20 >>>=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 --Apple-Mail-63-1056266507 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjYxNTAxNTVaMCMGCSqGSIb3DQEJ BDEWBBS1Pogbv5x/1fL2Jn3N478hp9YCNDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAF6SXonrmVj48Bwg+EXgfFqUnhaZ05mj0fDeTNiYPviyZzzx 5CAIg5zogzgsKI28PPSwjG4UIMzJDSe0YFqLQQPRbuGzbyr4Mc8X1HMja89NSUT9oqXyqxoFXTiH cUdwuqCtDKSmCAg8Pn+8EDzhUIu2y68HecfafhtQhJHP7EBP/tv6CayohYRCePv7dxHn9Tvdr/C4 XCu2G6zQmhgJBLrqx88HrReJJ4riBXKjxSaz/NxQzjbSB3bZM03XJYcupIVJBXzC1IPtCw7DCxXD wyNFNjlTME5QNzJA/OYcK3QGclTYNktx9Ibvy6PRnIlEzPnMkHV9EIeNaUdRj6GjCnQAAAAAAAA= --Apple-Mail-63-1056266507-- From ben@nostrum.com Fri Aug 26 08:10:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6BC21F8BD7 for ; Fri, 26 Aug 2011 08:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34nqAgr73QAJ for ; Fri, 26 Aug 2011 08:10:23 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C658521F8B5F for ; Fri, 26 Aug 2011 08:10:22 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7QFBaqC025791 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Aug 2011 10:11:38 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> Date: Fri, 26 Aug 2011 10:11:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C203779-35C8-44DF-8649-DD12E24551CE@nostrum.com> References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:10:24 -0000 (as individual) On Aug 26, 2011, at 10:01 AM, Eric Burger wrote: > Naah. They use XMPP :-) >=20 > Oops - I forgot - that's all TLS. TLS is "MUST support" in XMPP. >=20 > On Aug 26, 2011, at 10:10 AM, Cullen Jennings wrote: >=20 >>=20 >> Are you seriously saying no one would ever use MSRP in an enterprise = network?=20 >>=20 >>=20 >> On Aug 26, 2011, at 8:02 AM, Eric Burger wrote: >>=20 >>> In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. >>>=20 >>> On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >>>=20 >>>>=20 >>>> Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >>>>=20 >>>>=20 >>>> On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >>>>=20 >>>>> Cullen, >>>>>=20 >>>>> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> ________________________________________ >>>>> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf = Of Cullen Jennings [fluffy@cisco.com] >>>>> Sent: Friday, August 26, 2011 3:20 AM >>>>> To: Simple WG >>>>> Subject: Re: [Simple] TLS or Not for CEMA >>>>>=20 >>>>> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>>>>=20 >>>>>>=20 >>>>>> Are you seriously comparing mandating TLS with human rights??? >>>>>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>>>>=20 >>>>>> As to your other points - I don't know what we'd do today for = those protocols - given the behavior of the IETF we'd probably never = publish any of them today. (seriously) IMO that's a problem with the = IETF rather than a problem with the protocols. Instead of just = publishing RFCs for the purpose of interoperating while giving us = freedom to make our own decisions, it's about enslaving us to = holier-than-thou Commandments. >>>>>>=20 >>>>>> Live free or die! >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>>=20 >>>>>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>>>>=20 >>>>>>> THANK YOU FOR THE OPENING!!! >>>>>>>=20 >>>>>>> Let's see. TLS was published in January, 1999. Let's look at = the other references: >>>>>>>=20 >>>>>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>>>>=20 >>>>>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>>>>=20 >>>>>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>>>>=20 >>>>>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>>>>=20 >>>>>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>>>>=20 >>>>>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>>>>=20 >>>>>>>=20 >>>>>>> So, if only TLS was invented twenty years earlier, are you = saying we would not have this problem? >>>>>>>=20 >>>>>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>>>>=20 >>>>>>>>> Right, and since there are no protocol police, MUST implement = / MAY use =3D DO NOT BOTHER. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>>>>=20 >>>>>>>> -hadriel >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From fluffy@cisco.com Fri Aug 26 09:25:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986FC21F8C35 for ; Fri, 26 Aug 2011 09:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.383 X-Spam-Level: X-Spam-Status: No, score=-103.383 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+RiJErpKY8c for ; Fri, 26 Aug 2011 09:25:43 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 85AE921F8C47 for ; Fri, 26 Aug 2011 09:25:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=6158; q=dns/txt; s=iport; t=1314376020; x=1315585620; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cLFxvrQyBhKMfE+afUC6t8Jyx9cvr5zH2Hqc+nIHeOA=; b=Nte+OSNYLjSXf+0x+1yTBvx7Fzo12E8qovkJkr9AcGnZ9P/lGlpxAjtw OERK2j8FDaBwkDSem4Kt5SNi4iYiJFqfy5G98i4fvWThAIQD4qFNyGA1X NkUtikYQwMzKptWGZHWqNhkNfdVetGoDk65/XC75CKvrH9ao7AAqnPUuk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIAAHXIV06rRDoG/2dsb2JhbABCmEWPXXeBQAEBAQECAQEBAQ8BJzQLBQsLDgMEAQEBLicoCAYTIodQBJs/AZ8ahWxgBIdiiziFDYwS X-IronPort-AV: E=Sophos;i="4.68,285,1312156800"; d="scan'208";a="16854376" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-1.cisco.com with ESMTP; 26 Aug 2011 16:26:59 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7QGQwbg024786; Fri, 26 Aug 2011 16:26:58 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> Date: Fri, 26 Aug 2011 10:26:57 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:25:44 -0000 well that gets to the real issues, one approach to improve = interoperability would be to say all MSRP clients MUST use XMPP but may = implement MSRP :-) On Aug 26, 2011, at 9:01 AM, Eric Burger wrote: > Naah. They use XMPP :-) >=20 > Oops - I forgot - that's all TLS. >=20 > On Aug 26, 2011, at 10:10 AM, Cullen Jennings wrote: >=20 >>=20 >> Are you seriously saying no one would ever use MSRP in an enterprise = network?=20 >>=20 >>=20 >> On Aug 26, 2011, at 8:02 AM, Eric Burger wrote: >>=20 >>> In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. >>>=20 >>> On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >>>=20 >>>>=20 >>>> Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >>>>=20 >>>>=20 >>>> On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >>>>=20 >>>>> Cullen, >>>>>=20 >>>>> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> ________________________________________ >>>>> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf = Of Cullen Jennings [fluffy@cisco.com] >>>>> Sent: Friday, August 26, 2011 3:20 AM >>>>> To: Simple WG >>>>> Subject: Re: [Simple] TLS or Not for CEMA >>>>>=20 >>>>> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>>>>=20 >>>>>>=20 >>>>>> Are you seriously comparing mandating TLS with human rights??? >>>>>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>>>>=20 >>>>>> As to your other points - I don't know what we'd do today for = those protocols - given the behavior of the IETF we'd probably never = publish any of them today. (seriously) IMO that's a problem with the = IETF rather than a problem with the protocols. Instead of just = publishing RFCs for the purpose of interoperating while giving us = freedom to make our own decisions, it's about enslaving us to = holier-than-thou Commandments. >>>>>>=20 >>>>>> Live free or die! >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>>=20 >>>>>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>>>>=20 >>>>>>> THANK YOU FOR THE OPENING!!! >>>>>>>=20 >>>>>>> Let's see. TLS was published in January, 1999. Let's look at = the other references: >>>>>>>=20 >>>>>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>>>>=20 >>>>>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>>>>=20 >>>>>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>>>>=20 >>>>>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>>>>=20 >>>>>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>>>>=20 >>>>>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>>>>=20 >>>>>>>=20 >>>>>>> So, if only TLS was invented twenty years earlier, are you = saying we would not have this problem? >>>>>>>=20 >>>>>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>>>>=20 >>>>>>>>> Right, and since there are no protocol police, MUST implement = / MAY use =3D DO NOT BOTHER. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>>>>=20 >>>>>>>> -hadriel >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >=20 From christer.holmberg@ericsson.com Sun Aug 28 09:56:16 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC8E21F86F6 for ; Sun, 28 Aug 2011 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dkid4aeh4dvE for ; Sun, 28 Aug 2011 09:56:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B654421F85B9 for ; Sun, 28 Aug 2011 09:56:15 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-37-4e5a7381e4ff Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.EE.20773.1837A5E4; Sun, 28 Aug 2011 18:57:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 28 Aug 2011 18:57:36 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG Date: Sun, 28 Aug 2011 18:57:36 +0200 Thread-Topic: [Simple] Chair note on CEMA TLS discussion thread Thread-Index: Acxj/Xuq/IhWpZPJTYqqo7lyASVIVgBpZ9qA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233CD63AA@ESESSCMS0356.eemea.ericsson.se> References: <1E36555C-B8C6-4795-8827-36EF88F09DC2@nostrum.com> In-Reply-To: <1E36555C-B8C6-4795-8827-36EF88F09DC2@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Chair note on CEMA TLS discussion thread X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 16:56:16 -0000 Hi, The intention is NOT to turn CEMA into a security draft - only to better de= scribe the security related advantage, that CEMA allows for an end-to-end T= LS connection to be established even when Middleboxes (as defined by the dr= aft) are present. Regards, Christer =20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Ben Campbell Sent: 26. elokuuta 2011 17:36 To: Simple WG Subject: [Simple] Chair note on CEMA TLS discussion thread (as chair) The recent TLS thread on use of TLS in CEMA includes some posts suggesting = that CEMA is now more about security than about middleboxes. Please keep in= mind that we are not currently chartered to work on MSRP security improvem= ents, however desirably they might be. That doesn't mean that the CEMA work= can't have side effects that improve security, just that if that becomes a= n explicit goal of the work, we may need to take another look at where the = work occurs. That doesn't mean such work absolutely can't happen in SIMPLE,= but it would require rechartering. (Our charter is pretty explicit about n= ew work.) That being said, in my opinion, the question of whether CEMA has evolved in= to a security draft of not depends a lot on the ongoing thread about whethe= r TLS should be MUST use vs MUST implement. Therefore, we encourage that di= scussion to continue, and will likely make a consensus call on the subject = once people have had a few days to read the latest draft version (published= this morning as draft-ietf-simple-msrp-cema-00). Thanks! Ben. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From rik_gonther@yahoo.com Sun Aug 28 22:38:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCD521F86EE for ; Sun, 28 Aug 2011 22:38:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.943 X-Spam-Level: *** X-Spam-Status: No, score=3.943 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_99=3.5, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqxM0hYJI35u for ; Sun, 28 Aug 2011 22:38:55 -0700 (PDT) Received: from nm18.bullet.mail.bf1.yahoo.com (nm18.bullet.mail.bf1.yahoo.com [98.139.212.177]) by ietfa.amsl.com (Postfix) with SMTP id A4A7B21F86BE for ; Sun, 28 Aug 2011 22:38:55 -0700 (PDT) Received: from [98.139.212.145] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2011 05:40:16 -0000 Received: from [98.139.212.196] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2011 05:40:16 -0000 Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 29 Aug 2011 05:40:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 640706.10108.bm@omp1005.mail.bf1.yahoo.com Received: (qmail 95122 invoked by uid 60001); 29 Aug 2011 05:40:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1314596416; bh=Oaa7b5uUU19DHIy4JZn3EN4ErgLeBAacO7T1DmxxjIY=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=C8zfmn+gyh4ox1sjKRceOx1R63tI/UPuPV4Z4ASci3qXQZgNXvTrAvjzFdcPJnR0/qD/vGSPoqoDsVUFO9g7l5Z5hyQYVlDPG+uw6mWLHAs/DhaVzMgxBCutG8akN0Ez2bU8eFw/S33Ml0h8NujklmrWY+Sug9TbAB0iaAKQDLw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=6JESl0rMqGv9dr8SggOdBztFGeCx61EPIQLjre7URaKuQYQWIQM6yFMAkzujEtBFcPjta2o1GyD/ELA0O+pIYRKwgT/ruDhzHIbEE+zaVVSuExFoppvB1Ig7mKbYcJK8OEUK1iFiZunurkCeJWiOQBMz2sDDuQXk+0HRmN1yzNE=; X-YMail-OSG: SUnNyRIVM1k0A4Z36YUwjoMbbCtdkjy94pC1GQbQ.4Zlhen VMHY0IBeJimUSQ2nTxMHwDFPU5TMKTRCAnzFeyhyUlWkHfEh3o_aMNFcZkN. RIk4i8LgMXBfM7AaJsXYguIWXermNan3wIDVdVVBudIezj3lNfePkCLeHaIw _IzROuF8UPiOn.sb_6ZrD8g7M_b9Df_u_2sXLbQ_4.ejekaGZDL4Z0jWknde zm2XhPctDszwi9pOF4IwQsXEp6MJcRd63vGKu8LDUjfbKhBd9VD37ZeaUts4 JziDwlLrF0l9VW7wvVblo3RmfYfLGSlEmg8puEUB2QI2G01pBsz2bGiixAI3 wes7KbKSOly6FIE_Nd0agxfggDkev0IgMle8XzosQLXFkhC8ze.4vHvQ3YuK Yu1ZtWRghHf9yrMAF4mQxyoAulCj8czmqz5A9cd.QUFFES4o4mjYzfw-- Received: from [202.153.32.146] by web161614.mail.bf1.yahoo.com via HTTP; Sun, 28 Aug 2011 22:40:16 PDT X-Mailer: YahooMailWebService/0.8.113.315625 Message-ID: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> Date: Sun, 28 Aug 2011 22:40:16 -0700 (PDT) From: gonther rik To: "Simple@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-53372568-1314596416=:94588" Subject: [Simple] are you aware of any documentation to implement MMS using MSRP? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gonther rik List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 05:38:56 -0000 --0-53372568-1314596416=:94588 Content-Type: text/plain; charset=us-ascii Hello Group, could you please guide me to an rfc or some documentation mentioning how to implement MMS using MSRP Thanks & Regards -Rik --0-53372568-1314596416=:94588 Content-Type: text/html; charset=us-ascii
Hello Group,
could you please guide me to an rfc or some documentation mentioning how to implement MMS using MSRP

Thanks & Regards
-Rik
--0-53372568-1314596416=:94588-- From internet-drafts@ietf.org Sun Aug 28 23:51:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABE021F855A; Sun, 28 Aug 2011 23:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JWqhqxDYCb9; Sun, 28 Aug 2011 23:51:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABC121F854E; Sun, 28 Aug 2011 23:51:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110829065140.13301.15639.idtracker@ietfa.amsl.com> Date: Sun, 28 Aug 2011 23:51:40 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-cema-01.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 06:51:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Connection Establishment for Media Anchoring (CEMA) for = the Message Session Relay Protocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Eric Burger Filename : draft-ietf-simple-msrp-cema-01.txt Pages : 16 Date : 2011-08-28 This document defines an Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of the extension is optional. The extension allows Middleboxes to anchor the MSRP connection, without the need for Middleboxes to modify the MSRP messages, and thus also enables a secure end-to-end MSRP communication in networks where such Middleboxes are deployed. The document also defines a Session Description Protocol (SDP) attribute, a=3Dmsrp-cema, that MSRP endpoints use to indicate support of the CEMA extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-cema-01.txt From christer.holmberg@ericsson.com Mon Aug 29 00:01:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DD721F8565 for ; Mon, 29 Aug 2011 00:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41fwOcGZx-Ji for ; Mon, 29 Aug 2011 00:01:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BDF9B21F8828 for ; Mon, 29 Aug 2011 00:01:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c47ae000000b17-e1-4e5b399234e2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.E5.02839.2993B5E4; Mon, 29 Aug 2011 09:02:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 29 Aug 2011 09:02:42 +0200 From: Christer Holmberg To: Simple WG Date: Mon, 29 Aug 2011 09:02:40 +0200 Thread-Topic: CEMA -01 Thread-Index: AcxmGaRWNU/6NF4FQd+M5trNRcVKsQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D64737@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852233D64737ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] CEMA -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 07:01:20 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852233D64737ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a new version (-01) of the CEMA draft, as there were changes= that didn't make it into the previous version. Also, any "MUST-use-TLS" text has been removed, as there is yet no WG agree= ment to mandate that. Sorry for the mess. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852233D64737ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I've submitted a new version (-01) of the CEMA draft,= as there were changes that didn't make it into the previous version.
 
Also, any "MUST-use-TLS" text has been remo= ved, as there is yet no WG agreement to mandate that.
 
Sorry for the mess.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852233D64737ESESSCMS0356e_-- From saul@ag-projects.com Mon Aug 29 00:17:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD07121F8829 for ; Mon, 29 Aug 2011 00:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEgxV+kKXL4h for ; Mon, 29 Aug 2011 00:17:49 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A276321F85C6 for ; Mon, 29 Aug 2011 00:17:47 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6B261B01B9; Mon, 29 Aug 2011 09:19:08 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E958BB017D; Mon, 29 Aug 2011 09:19:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> Date: Mon, 29 Aug 2011 09:19:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AE56672-C478-4D84-BBA4-DC6B8413FC28@ag-projects.com> References: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> To: gonther rik X-Mailer: Apple Mail (2.1084) Cc: "Simple@ietf.org" Subject: Re: [Simple] are you aware of any documentation to implement MMS using MSRP? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 07:17:49 -0000 On Aug 29, 2011, at 7:40 AM, gonther rik wrote: > Hello Group, > could you please guide me to an rfc or some documentation mentioning = how to implement MMS using MSRP >=20 I'm not aware of a standard of that kind. You can use MSRP to send = text/html content type, which may suit your needs. -- Sa=FAl Ibarra Corretg=E9 AG Projects From eburger@standardstrack.com Mon Aug 29 05:22:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A7021F8B1B for ; Mon, 29 Aug 2011 05:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNSvZia5zTpX for ; Mon, 29 Aug 2011 05:22:40 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 42C8B21F8B1D for ; Mon, 29 Aug 2011 05:22:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=CpzeF09VIOF5uwDC0KiymPAI0Jo9uyYmbVQGItb5TQ4aYD/lZmwrWwhDuryPTTvN8AFJ4V5tjbSXJL4OsJRnUETGWAef4lByo2o0mpRyJu1lECY1uGQ95awztSA/FNQ8; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.141]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qy0sl-0003UF-Oz for simple@ietf.org; Mon, 29 Aug 2011 05:24:04 -0700 From: Eric Burger Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-152--841493548; protocol="application/pkcs7-signature"; micalg=sha1 Date: Mon, 29 Aug 2011 08:23:58 -0400 In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D64737@ESESSCMS0356.eemea.ericsson.se> To: Simple WG References: <7F2072F1E0DE894DA4B517B93C6A05852233D64737@ESESSCMS0356.eemea.ericsson.se> Message-Id: <5BEE70B3-0E66-40BB-828B-A8D5F342DF90@standardstrack.com> X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [Simple] CEMA -01 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:22:41 -0000 --Apple-Mail-152--841493548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I take full responsibility for the mess. Thanks Christer for mopping up! -- - Eric On Aug 29, 2011, at 3:02 AM, Christer Holmberg wrote: > =20 > Hi, > =20 > I've submitted a new version (-01) of the CEMA draft, as there were = changes that didn't make it into the previous version. > =20 > Also, any "MUST-use-TLS" text has been removed, as there is yet no WG = agreement to mandate that. > =20 > Sorry for the mess. > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-152--841493548 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA4MjkxMjIzNTlaMCMGCSqGSIb3DQEJ BDEWBBTqUVw0mBjsoqfYrnZnkZBoR5oq6zCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAIBbeiCzIWY9P19WpZWJKgSaKQnD6t655CE2SkY2N3oh7M9x ZkUsw5B75AwCyaSR+Dq42VBkBHcidcNl8cMlU9ploCOiFObcfb9exFeSzQlRTier1QxSRW08Ncqr lqPRdu9EDkmDAsAnHf55iUf2wgynE5XudCbCIYdNmMfVdRjbsalUpOb6cBsVZhMf/zXlXz7l09ag 715SDBKSYpkLsZRrM+1HSqFBCWIGVZXKpMUe6Kqr8Nh4GyDFets39lYFLdZUnB3iuN2v1jdMonSu qVEQXqYHUFdHFWqQlWmCZHXHughaVbP1iWf4xa+P6c3gEwj+3DVm8h6d93fVJhzNLDgAAAAAAAA= --Apple-Mail-152--841493548-- From ben@nostrum.com Mon Aug 29 05:52:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A5E21F8B27 for ; Mon, 29 Aug 2011 05:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.106 X-Spam-Level: X-Spam-Status: No, score=-102.106 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-KJ8EFQfW-k for ; Mon, 29 Aug 2011 05:52:42 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3E47521F8B29 for ; Mon, 29 Aug 2011 05:52:41 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p7TCs1RD096832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Aug 2011 07:54:01 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_1551958E-914D-4F54-B1BC-6E6C9A53E877" From: Ben Campbell In-Reply-To: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> Date: Mon, 29 Aug 2011 07:54:22 -0500 Message-Id: <58DB2CE4-76BE-46BE-B38B-633A0C5AA7A2@nostrum.com> References: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> To: gonther rik X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: "Simple@ietf.org" Subject: Re: [Simple] are you aware of any documentation to implement MMS using MSRP? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 12:52:42 -0000 --Apple-Mail=_1551958E-914D-4F54-B1BC-6E6C9A53E877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am not aware of any such document from the IETF. You might take a look = at the OMA CPM or GSMA RCS specs to see if they have anything that meets = your needs. On Aug 29, 2011, at 12:40 AM, gonther rik wrote: > Hello Group, > could you please guide me to an rfc or some documentation mentioning = how to implement MMS using MSRP >=20 > Thanks & Regards > -Rik > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail=_1551958E-914D-4F54-B1BC-6E6C9A53E877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello = Group,
could you please guide me to an rfc or = some documentation mentioning how to implement MMS using = MSRP

Thanks & Regards
-Rik
______________________________________= _________
Simple mailing list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail=_1551958E-914D-4F54-B1BC-6E6C9A53E877-- From rbarnes@bbn.com Mon Aug 29 07:19:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE121F8B12 for ; Mon, 29 Aug 2011 07:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8ZwgGY7dGRc for ; Mon, 29 Aug 2011 07:19:14 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB4721F8B10 for ; Mon, 29 Aug 2011 07:19:13 -0700 (PDT) Received: from ros-dhcp192-1-51-76.bbn.com ([192.1.51.76]:56069) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Qy2hT-000Avl-NV; Mon, 29 Aug 2011 10:20:31 -0400 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> Date: Mon, 29 Aug 2011 10:20:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5432F54A-8775-473B-80B9-184DB6C11C70@acmepacket.com><5528DFB6-D0D8-4225-A197-86FC024E22AA@bbn.com><7D28B138-9538-4935-A7BF-B4B337306724@standardstrack.com><0284123E-9B5A-4B89-AB41-4C75D2EFE840@acmepacket.com><9B05F449-2E8B-400B-8E75-7100DCA84587@acmepacket.com>, <4A6976F5-FBE9-430A-9F7E-BAF474D4560C@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7A4@ESESSCMS0356.eemea.ericsson.se> <588C0E69-7E27-4C7B-9FB7-61E498718558@cisco.com> <026A0CE0-9E12-4A8F-8965-21B246384871@standardstrack.com> <07735785-7341-4165-982D-07D47F7745FA@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1082) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] TLS or Not for CEMA X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 14:19:15 -0000 Not all XMPP is over TLS, otherwise we wouldn't need = draft-ietf-xmpp-dna. If RFC 3921 had made TLS a MUST USE, then XMPP = (e.g., Google Apps) would not have been feasible. On Aug 26, 2011, at 11:01 AM, Eric Burger wrote: > Naah. They use XMPP :-) >=20 > Oops - I forgot - that's all TLS. >=20 > On Aug 26, 2011, at 10:10 AM, Cullen Jennings wrote: >=20 >>=20 >> Are you seriously saying no one would ever use MSRP in an enterprise = network?=20 >>=20 >>=20 >> On Aug 26, 2011, at 8:02 AM, Eric Burger wrote: >>=20 >>> In this context, I would offer BCP 61 indicates MUST use. The MUST = implement versus MUST use construct of BCP 61 is for walled garden = environments. Last I looked, SIMPLE and MSRP's target is the wider = Internet. Moreover, it is for person-to-person, PRIVATE, communication. = That is not something where there is a presumption of publication. >>>=20 >>> On Aug 26, 2011, at 9:09 AM, Cullen Jennings wrote: >>>=20 >>>>=20 >>>> Yes, my opinion is more or less that until someone changes BCP 61, = IETF work needs to meet BCP 61. Richard more or less summarized BCP 61 = for you and needless to say it roughly says "MUST implement" and = explains why it is not "MUST use" >>>>=20 >>>>=20 >>>> On Aug 26, 2011, at 3:36 AM, Christer Holmberg wrote: >>>>=20 >>>>> Cullen, >>>>>=20 >>>>> If you have an opinion on the specific topic currently being = discussed, I think it would be helpful if you could give it before a new = draft is available... >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> ________________________________________ >>>>> From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf = Of Cullen Jennings [fluffy@cisco.com] >>>>> Sent: Friday, August 26, 2011 3:20 AM >>>>> To: Simple WG >>>>> Subject: Re: [Simple] TLS or Not for CEMA >>>>>=20 >>>>> Uh, wow - looks like we are getting closer to consensus on this = draft. Let me know when it get's published. I think this current thread = is fairly crazy. I'm pretty sure I disagree with at least half the folks = on this thread but I'll wait to read the draft first. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Aug 24, 2011, at 2:45 AM, Hadriel Kaplan wrote: >>>>>=20 >>>>>>=20 >>>>>> Are you seriously comparing mandating TLS with human rights??? >>>>>> Wow. I think you need to step away from the computer and go on a = vacation with human beings and get some perspective. ;) >>>>>>=20 >>>>>> As to your other points - I don't know what we'd do today for = those protocols - given the behavior of the IETF we'd probably never = publish any of them today. (seriously) IMO that's a problem with the = IETF rather than a problem with the protocols. Instead of just = publishing RFCs for the purpose of interoperating while giving us = freedom to make our own decisions, it's about enslaving us to = holier-than-thou Commandments. >>>>>>=20 >>>>>> Live free or die! >>>>>>=20 >>>>>> -hadriel >>>>>>=20 >>>>>>=20 >>>>>> On Aug 23, 2011, at 11:05 PM, Eric Burger wrote: >>>>>>=20 >>>>>>> THANK YOU FOR THE OPENING!!! >>>>>>>=20 >>>>>>> Let's see. TLS was published in January, 1999. Let's look at = the other references: >>>>>>>=20 >>>>>>> SMTP: published August, 1982. 17 years before TLS came out. = Older than some IETF participants. As published today, requirers it. >>>>>>>=20 >>>>>>> Telnet: published May, 1983. 16 years before TLS came out. If = published today, would undoubtably require it. >>>>>>>=20 >>>>>>> RTP: published January, 1996. Doesn't run over TCP, so red = herring. However, lots of effort to make SRTP, DTLS, ZRTP, et al. work = today. Lots of folks wish there was a single way of doing secure RTP, = key exchange, and secure key exchange signaling. [BTW, if anyone on the = list is interested in doing this kind of work, please send me an email = off-list.] >>>>>>>=20 >>>>>>> POP3: published May, 1996. 13 years before TLS came out. If = published today, would undoubtably require it. See IMAP for the = existence proof. >>>>>>>=20 >>>>>>> SIP: published March, 1999. Suggested one use this new thing = called TLS. Who knew if TLS was going to work. It does. Let us get on = the bus. >>>>>>>=20 >>>>>>> HTTP: published June, 1999. Suggested one use this new thing = called TLS. Fast forward 12 years. Industry wishes everything was TLS. = Market is starting to push that way. >>>>>>>=20 >>>>>>>=20 >>>>>>> So, if only TLS was invented twenty years earlier, are you = saying we would not have this problem? >>>>>>>=20 >>>>>>> I will venture to be politically incorrect here: are what we are = saying is that we always had slavery, but in the past some folks MAY be = free, so it is fine to say people SHOULD be free today, because people = were not free in the past? I think most folks would say people MUST be = free, especially *because* people were not free in the past. Remember = the obligation to repair the world. Let us not fall down in our duty. >>>>>>>=20 >>>>>>>=20 >>>>>>> On Aug 23, 2011, at 5:11 PM, Hadriel Kaplan wrote: >>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Aug 23, 2011, at 6:32 AM, Eric Burger wrote: >>>>>>>>=20 >>>>>>>>> Right, and since there are no protocol police, MUST implement = / MAY use =3D DO NOT BOTHER. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> If there's demand for it, people will do it. If there isn't = demand, we shouldn't be in the business of creating an artificial one. >>>>>>>> We don't mandate TLS be used for SMTP, POP3, HTTP, SIP, RTP, = Telnet, etc. >>>>>>>>=20 >>>>>>>> -hadriel >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Simple mailing list >>>>>> Simple@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>> _______________________________________________ >>>>> Simple mailing list >>>>> Simple@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/simple >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Simple mailing list >>>> Simple@ietf.org >>>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From hans.rohnert@nsn.com Mon Aug 29 16:43:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4990121F8C21 for ; Mon, 29 Aug 2011 16:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxPe1B5FT1uc for ; Mon, 29 Aug 2011 16:43:50 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1AC21F8C1F for ; Mon, 29 Aug 2011 16:43:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p7TNjCWC020898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Aug 2011 01:45:12 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p7TNjBwa017753; Tue, 30 Aug 2011 01:45:12 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 01:43:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC66A5.6DC31486" Date: Tue, 30 Aug 2011 01:43:16 +0200 Message-ID: <9AF73DDF1D71944E8B2A94C48743BDF402CD999B@DEMUEXC035.nsn-intra.net> In-Reply-To: <58DB2CE4-76BE-46BE-B38B-633A0C5AA7A2@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] are you aware of any documentation to implement MMSusing MSRP? Thread-Index: AcxmSuNMnwcwUXg9TWiD1iirVpK9WAAWaKAA References: <1314596416.94588.YahooMailNeo@web161614.mail.bf1.yahoo.com> <58DB2CE4-76BE-46BE-B38B-633A0C5AA7A2@nostrum.com> From: "Rohnert, Hans (NSN - DE/Munich)" To: "ext Ben Campbell" , "gonther rik" X-OriginalArrivalTime: 29 Aug 2011 23:43:19.0825 (UTC) FILETIME=[6E9BE810:01CC66A5] Cc: Simple@ietf.org Subject: Re: [Simple] are you aware of any documentation to implement MMSusing MSRP? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 23:43:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC66A5.6DC31486 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OMA CPM and GSMA RCS do not do exactly "implement MMS using MSRP". Rather the following: =20 GSMA RCS uses MMS as is for messaging needs (however, there are multiple GSMA RCS versions differing in their respective messaging capabilities and means, and you would need to take a closer look here before making generic statements about GSMA RCS).=20 =20 OMA CPM is its own messaging enabler, leveraging on different IETF facilities (e.g. SIP MESSAGE and MSRP) for constructing and sending "CPM messages". Also, CPM defines an interworking between CPM messages and MMS messages. There, it is described how one kind of message can be translated into the other. =20 Hope this helps, Hans Rohnert =20 From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of ext Ben Campbell Sent: Monday, August 29, 2011 5:54 AM To: gonther rik Cc: Simple@ietf.org Subject: Re: [Simple] are you aware of any documentation to implement MMSusing MSRP? =20 I am not aware of any such document from the IETF. You might take a look at the OMA CPM or GSMA RCS specs to see if they have anything that meets your needs. =20 On Aug 29, 2011, at 12:40 AM, gonther rik wrote: Hello Group, could you please guide me to an rfc or some documentation mentioning how to implement MMS using MSRP =20 Thanks & Regards -Rik _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple =20 ------_=_NextPart_001_01CC66A5.6DC31486 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OMA CPM and GSMA RCS do not do exactly “implement MMS using = MSRP”. Rather the following:

 

GSMA RCS uses MMS as is for messaging needs (however, there are = multiple GSMA RCS versions differing in their respective messaging = capabilities and means, and you would need to take a closer look here = before making generic statements about GSMA RCS). =

 

OMA CPM is its own messaging enabler, leveraging on different IETF = facilities (e.g. SIP MESSAGE and MSRP) for constructing and sending = “CPM messages”. Also, CPM defines an interworking between = CPM messages and MMS messages. There, it is described how one kind of = message can be translated into the other.

 

Hope this helps,

Hans Rohnert

 

From:= = simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of = ext Ben Campbell
Sent: Monday, August 29, 2011 5:54 = AM
To: gonther rik
Cc: = Simple@ietf.org
Subject: Re: [Simple] are you aware of any = documentation to implement MMSusing = MSRP?

 

I am = not aware of any such document from the IETF. You might take a look at = the OMA CPM or GSMA RCS specs to see if they have anything that meets = your needs.

 

On = Aug 29, 2011, at 12:40 AM, gonther rik wrote:



Hello Group,

could you please guide = me to an rfc or some documentation mentioning how to implement MMS using = MSRP

 

Thanks & = Regards

-Rik

_______________________________________________
Simp= le mailing list
Simple@ietf.org
https://www.ietf.o= rg/mailman/listinfo/simple

 

------_=_NextPart_001_01CC66A5.6DC31486--