From junglecat@orchidseed.org Sat Sep 5 01:18:17 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1FBD3A6850 for ; Sat, 5 Sep 2009 01:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SPEC_LEO_LINE03f=0.612] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GAj1r+FmZAig for ; Sat, 5 Sep 2009 01:18:17 -0700 (PDT) Received: from mail-yx0-f190.google.com (mail-yx0-f190.google.com [209.85.210.190]) by core3.amsl.com (Postfix) with ESMTP id DC44A3A6784 for ; Sat, 5 Sep 2009 01:18:16 -0700 (PDT) Received: by yxe28 with SMTP id 28so1628010yxe.19 for ; Sat, 05 Sep 2009 01:18:36 -0700 (PDT) Received: by 10.91.192.14 with SMTP id u14mr9042441agp.2.1252138716546; Sat, 05 Sep 2009 01:18:36 -0700 (PDT) Received: from ?10.0.1.8? (ip68-5-30-57.oc.oc.cox.net [68.5.30.57]) by mx.google.com with ESMTPS id 7sm1376954aga.27.2009.09.05.01.18.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Sep 2009 01:18:35 -0700 (PDT) From: jc Content-Type: multipart/alternative; boundary=Apple-Mail-1--1046394413 Date: Sat, 5 Sep 2009 01:18:32 -0700 Message-Id: To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Mailman-Approved-At: Mon, 07 Sep 2009 09:39:23 -0700 Subject: [P2PSIP] 10.3. Credentials draft-ietf-p2psip-base.txt revision 3698 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 08:18:17 -0000 --Apple-Mail-1--1046394413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed I assume this is to say "the server generates and returns a"? 6312 the requested user name is acceptable, the server and returns a Julian --Apple-Mail-1--1046394413 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I assume = this is to say "the server generates and returns a"? =

6312 the requested user name is acceptable, the server and returns = a

Julian
<= /html>= --Apple-Mail-1--1046394413-- From neil.young@freenet.de Tue Sep 8 10:43:52 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07B828C2AD for ; Tue, 8 Sep 2009 10:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajmkNTzBR6t3 for ; Tue, 8 Sep 2009 10:43:51 -0700 (PDT) Received: from mout4.freenet.de (mout4.freenet.de [IPv6:2001:748:100:40::2:6]) by core3.amsl.com (Postfix) with ESMTP id DAD6528C1F8 for ; Tue, 8 Sep 2009 10:43:50 -0700 (PDT) Received: from [195.4.92.11] (helo=1.mx.freenet.de) by mout4.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1Ml4jr-0001uW-MM for p2psip@ietf.org; Tue, 08 Sep 2009 19:44:19 +0200 Received: from p54bd982b.dip0.t-ipconnect.de ([84.189.152.43]:55118 helo=[192.168.178.38]) by 1.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1Ml4jr-0004BW-Gj for p2psip@ietf.org; Tue, 08 Sep 2009 19:44:19 +0200 Message-ID: <4AA697F5.1000803@freenet.de> Date: Tue, 08 Sep 2009 19:44:21 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: multipart/alternative; boundary="------------090509040602050708040004" Subject: [P2PSIP] What is the state of RELOAD? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2009 17:45:11 -0000 This is a multi-part message in MIME format. --------------090509040602050708040004 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hello group, could anybody give me a brief info about the status of RELOAD? Is there already any commercial/open source implementation out? Kind regards --------------090509040602050708040004 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Hello group,

could anybody give me a brief info about the status of RELOAD? Is there already any commercial/open source implementation out?

Kind regards

--------------090509040602050708040004-- From neil.young@freenet.de Wed Sep 9 05:42:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 309BF28C428 for ; Wed, 9 Sep 2009 05:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.204 X-Spam-Level: X-Spam-Status: No, score=-1.204 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKLV4k+JAor1 for ; Wed, 9 Sep 2009 05:42:50 -0700 (PDT) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by core3.amsl.com (Postfix) with ESMTP id 3A27D28C433 for ; Wed, 9 Sep 2009 05:42:46 -0700 (PDT) Received: from [195.4.92.10] (helo=0.mx.freenet.de) by mout1.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1MlMW5-0006KI-0U for p2psip@ietf.org; Wed, 09 Sep 2009 14:43:17 +0200 Received: from p54bd9a8e.dip0.t-ipconnect.de ([84.189.154.142]:57330 helo=[192.168.178.38]) by 0.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1MlMW4-0005bI-1C for p2psip@ietf.org; Wed, 09 Sep 2009 14:43:16 +0200 Message-ID: <4AA7A2E6.3030005@freenet.de> Date: Wed, 09 Sep 2009 14:43:18 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: p2psip@ietf.org References: <4AA697F5.1000803@freenet.de> <15A45571-A5BD-4C25-A049-F6269E1C0B66@orchidseed.org> In-Reply-To: <15A45571-A5BD-4C25-A049-F6269E1C0B66@orchidseed.org> Content-Type: multipart/alternative; boundary="------------040509060001090208040908" Subject: Re: [P2PSIP] What is the state of RELOAD? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 12:42:51 -0000 This is a multi-part message in MIME format. --------------040509060001090208040908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit OK. Really, that many responses... Pessimistic view: RELOAD is dead Optimistic view: Thousands of people are working in the dark, hiding their results from each other. What might be the truth? I don't want to bet on a dead horse, that's for sure... Regards >> Hello group, >> >> could anybody give me a brief info about the status of RELOAD? Is >> there already any commercial/open source implementation out? >> >> Kind regards >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip --------------040509060001090208040908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit OK. Really, that many responses...

Pessimistic view: RELOAD is dead
Optimistic view: Thousands of people are working in the dark, hiding their results from each other.

What might be the truth? I don't want to bet on a dead horse, that's for sure...

Regards


Hello group,

could anybody give me a brief info about the status of RELOAD? Is there already any commercial/open source implementation out?

Kind regards

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
--------------040509060001090208040908-- From br@brianrosen.net Wed Sep 9 08:25:29 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A5923A6960 for ; Wed, 9 Sep 2009 08:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOFO0VbbVxX5 for ; Wed, 9 Sep 2009 08:25:28 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 16FF33A68F3 for ; Wed, 9 Sep 2009 08:25:28 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.201.57]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MlP3Q-0006Vc-Pe for p2psip@ietf.org; Wed, 09 Sep 2009 10:25:52 -0500 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Wed, 09 Sep 2009 11:25:57 -0400 From: Brian Rosen To: Message-ID: Thread-Topic: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Thread-Index: AcoxYdPjeopQfO4tWkOviuicNgywNg== In-Reply-To: <20090909143800.E2CD928C13E@core3.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: [P2PSIP] FW: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 15:25:29 -0000 Please consider the following, it's important Brian ------ Forwarded Message From: Mary Barnes Date: Wed, 9 Sep 2009 07:37:59 -0700 (PDT) To: IETF Announcement list Cc: Subject: Nomcom 2009-10: Important Reminder: Call for Nominations, Local Office hours, Nominee Questionnaires available Hi all, This is a 2nd reminder of the Call for Nominations that is underway. We *really* need more nominations in order to properly execute the task of selecting candidates for the open positions. At this time, the number of nominations for all the positions is about 1/2 of what is necessary for the Nomcom to do a conscientious job of evaluating the nominees and we are over 2/3 of the way through the nominations period. Nomcom cannot do their job without this important input from the community. So, please consider making nominations for the open positions - it takes just a few minutes of your time - the details are below. Right now, we just need the names/email addresses for the nominees - we'll be soliciting feedback later. Also, consider that over 1/2 the nominees are not able to accept the nominations for a variety of reasons - e.g., lack of funding, lack of sponsor support, etc. Thus, please consider nominating more than one individual for each of the positions. As well as the reminder for the call for nominations, this email also serves as a reminder for: 2) Local Office Hours 3) Questionnaires available for nominees Best Regards, Mary Barnes nomcom-chair@ietf.org mary.h.barnes@gmail.com mary.barnes@nortel.com ========================================================================= 1) Call for Nominations ------------------------ The nomination period ends in less than 2 weeks on Sept. 18th, 2009. We appreciate the folks that have taken the time to make nominations thus far. But, we do need more nominations. Please use the online tool to nominate - it's fast, easy and secure: https://wiki.tools.ietf.org/group/nomcom/09/nominate Details on the open positions, as well as other details and options for making nominations are available on the Nomcom homepage: https://wiki.tools.ietf.org/group/nomcom/09/ Please consider that the sooner you make the nominations, the more time your nominee(s) will have to complete the necessary questionnaire (item 3 below). As well, please consider nominating more than one person for a particular position. You will have the opportunity to provide additional feedback later and it's important to consider that not all nominees will be able to accept the nomination. 2) Local office hours ----------------------- In order facilitate additional feedback, the Nomcom has decided to make themselves available for office areas at various geographic locations for 3 weeks in September, starting on the 8th. Below please find the list of locations where Nomcom members will be available for these f2f meetings . Unless dates are identified below, the Nomcom member is generally available for part of the day during the weeks of Sept 8-11, Sept 14-18 and Sept 21-25. Also, languages other than English in which the Nomcom member is fluent are identfied. Please contact a Nomcom member in a specific geographic location to arrange a convenient meeting time and place. Most Nomcom members are flexible as to meeting locations - i.e., we can travel to your office, meet at our offices or somewhere in between. As a reminder folks can always contact any Nomcom member to provide feedback at anytime - i.e., you don't need to participate in these f2f sessions to provide feedback. Belgium: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 21-25) (Languages: French) Boston, Mass, USA: Stephen Kent - kent@bbn.com (Sept 16-18) Boulder, CO, USA: Wassim Haddad - wmhaddad@gmail.com (Sept 14-18) Dallas/Ft. Worth, TX, USA: Mary Barnes - mary.h.barnes@gmail.com Lucy Yong - lucyyong@huawei.com (Languages: Chinese) Helsinki, Finland: Simo Veikkolainen - simo.veikkolainen@nokia.com (Languages: Finnish) Ithaca, NY, USA: Scott Brim - scott.brim@gmail.com Montevideo, Uruguay: Roque Gagliano - roque@lacnic.net (Sept 14-18, 21-25) (Languages: Spanish, Portuguese) Montreal, Quebec, Canada Wassim Haddad - wmhaddad@gmail.com (Sept 8-11) -- Can also be available in Ottawa if folks are interested Paris, France: Dimitri Papadimitriou - dimitri.papadimitriou@alcatel-lucent.be (Sept 15-18) (Languages: French) San Diego, CA, USA: Randall Gellens - rg+ietf@qualcomm.com Dave Crocker - dcrocker@bbiw.net (Sept 16-18) Silicon Valley/SF Bay, CA, USA: Dave Crocker - dcrocker@bbiw.net (Sept 8-11, Sept 14-15, Sept 21-25) Dorothy Gellert - Dorothy.gellert@gmail.com 3) Questionnaires available for nominees: For folks that have been notified that they have been nominated for any of the positions, the questionnaires are now available on the Nomcom09 tools website: https://wiki.tools.ietf.org/group/nomcom/09/iab-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iaoc-questionnaire https://wiki.tools.ietf.org/group/nomcom/09/iesg-questionnaire If you have any questions, please let me know. I will be contacting everyone individually, as well as sending reminders. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ------ End of Forwarded Message From julian@orchidseed.org Thu Sep 10 03:53:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53463A6830 for ; Thu, 10 Sep 2009 03:53:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9JtF3kvU56J for ; Thu, 10 Sep 2009 03:53:58 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id D347A3A6A17 for ; Thu, 10 Sep 2009 03:53:58 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:39840 helo=[10.0.1.8]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MlhIN-0007so-Mv for p2psip@ietf.org; Thu, 10 Sep 2009 03:54:33 -0700 From: jc Content-Type: multipart/alternative; boundary=Apple-Mail-6--605035541 Date: Thu, 10 Sep 2009 03:54:31 -0700 Message-Id: <1A87218C-3C7F-4D84-AD8B-A009615A083C@orchidseed.org> To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] Section 3.5.2 and 10.5 Discrepancies X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 10:53:59 -0000 --Apple-Mail-6--605035541 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, From subversion(04) draft: 3.5.2. Joining, Leaving, and Maintenance Overview The first thing the peer needs to do is form a connection to some "bootstrap node". 10.5. Contacting a Bootstrap Peer When contacting a bootstrap peer, the joining peer sends a Ping request to the bootstrap peer's known IP address with the destination Node-ID set to the joining peer's Node-ID When the requester peer finally does receive a response from some responding peer, it can note the Node-ID in the response and use this Node-ID to start sending requests to join the Overlay Instance as described in There are two problems here, the first is simply terminology. 3.5.2 uses "bootstrap node" 10.5 uses "bootstrap peer" The second, 10.5 does not mention forming a connection and looks as if it was based on a UDP bootstrap mechanism or the multicast bootstrap (10.4). Am I correct that 10.5 is attempting to refer to 3.5.2 and that 10.5 should clear up the fact that your forming a connection to a bootstrap peer and not simply sending a datagram to bootstrap nodes and waiting for responses? REgaRDs, Julian --Apple-Mail-6--605035541 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii





When contacting a bootstrap = peer, the joining peer sends a Ping request to the bootstrap peer's = known IP address with the destination Node-ID set to the joining peer's = Node-ID



node"
10.5 uses = "bootstrap peer"

REgaRDs,
Julian
= --Apple-Mail-6--605035541-- From julian@orchidseed.org Thu Sep 10 04:03:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A9F3A6A1E for ; Thu, 10 Sep 2009 04:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPmsfDc6YPxF for ; Thu, 10 Sep 2009 04:03:43 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id A09983A69B7 for ; Thu, 10 Sep 2009 04:03:41 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:39759 helo=[10.0.1.8]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MlhRm-0002rh-QB for p2psip@ietf.org; Thu, 10 Sep 2009 04:04:16 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 Sep 2009 04:04:14 -0700 Message-Id: <2EA3FE06-E2DF-4F55-9029-C2E91E98FA63@orchidseed.org> To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 12.5.4. Residual Attacks && 12.6.5. Residual Attacks X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 11:03:44 -0000 Hi, There are two subsections in section 12 named "Residual Attacks". Julian From ekr@rtfm.com Thu Sep 10 06:45:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 177603A6AC0 for ; Thu, 10 Sep 2009 06:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.581 X-Spam-Level: X-Spam-Status: No, score=-1.581 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4oYdtfTUn4D for ; Thu, 10 Sep 2009 06:45:48 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 3443F3A6A8C for ; Thu, 10 Sep 2009 06:45:48 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so38972anc.4 for ; Thu, 10 Sep 2009 06:46:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.234.26 with SMTP id g26mr1625541anh.54.1252590380507; Thu, 10 Sep 2009 06:46:20 -0700 (PDT) In-Reply-To: <2EA3FE06-E2DF-4F55-9029-C2E91E98FA63@orchidseed.org> References: <2EA3FE06-E2DF-4F55-9029-C2E91E98FA63@orchidseed.org> Date: Thu, 10 Sep 2009 06:46:20 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: multipart/alternative; boundary=001636b42ebdade2530473396c04 Cc: p2psip WG Subject: Re: [P2PSIP] 12.5.4. Residual Attacks && 12.6.5. Residual Attacks X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 13:45:49 -0000 --001636b42ebdade2530473396c04 Content-Type: text/plain; charset=ISO-8859-1 Yes, that's intentional. 12.5.4 is about routing security and 12.6.5 is aboutstorage security -Ekr On Thu, Sep 10, 2009 at 4:04 AM, jc wrote: > Hi, > There are two subsections in section 12 named "Residual Attacks". > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --001636b42ebdade2530473396c04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, that's intentional. 12.5.4 is about routing security and 12.6.5 is= about
storage security

-Ekr

On Thu, Sep 10, 2009 at 4:04 AM, jc <julian@orchidseed.= org> wrote:
Hi,
There are two subsections in section 12 named "Residual Attacks".=

Julian
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org = https://www.ietf.org/mailman/listinfo/p2psip

--001636b42ebdade2530473396c04-- From julian@orchidseed.org Fri Sep 11 17:51:02 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500BC3A6879 for ; Fri, 11 Sep 2009 17:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.066 X-Spam-Level: X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S45vL3imQsw for ; Fri, 11 Sep 2009 17:51:01 -0700 (PDT) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id 9159A3A683F for ; Fri, 11 Sep 2009 17:51:01 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:46574 helo=[10.0.1.8]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MmGq2-0007fF-6S for p2psip@ietf.org; Fri, 11 Sep 2009 17:51:39 -0700 From: jc Content-Type: multipart/alternative; boundary=Apple-Mail-1--468411159 Date: Fri, 11 Sep 2009 17:51:35 -0700 Message-Id: To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] =?iso-8859-1?q?10=2E1=2E=A0_Overlay_Configuration_-_draf?= =?iso-8859-1?q?t_version_04?= X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 00:51:02 -0000 --Apple-Mail-1--468411159 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, "required-kinds This element indicates the kinds that members must support. It has three attributes:" This is incorrect and there are some attributes/elements missing. I have broken this down below: Attributes: kind.name - Not mentioned but in xml. kind.id - Not mentioned but in xml. Elements: kind-block - Not Mentioned but in xml. kind data-model max-count max-size kind-signature - Not mentioned but in xml. max-node-multiple - Not always used. access-control Also chord-reload-update-frequency && chord-reload-ping-frequency do not properly represent themselves within the xml. It is "chord:" when it should be at least IMHO "chord:reload:". Julian --Apple-Mail-1--468411159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
This = element indicates the kinds that members must support. It has three = attributes:"

This is incorrect and there = are some attributes/elements missing. I have broken this down = below:
    
Attributes:
kind.name - Not mentioned but in = xml.
kind.id - Not mentioned but in = xml.

Elements:
kind-block - Not = Mentioned but in = xml.
kind
data-model
max-count
max= -size
kind-signature - Not mentioned but in = xml.
max-node-multiple - Not always = used.
access-control

Also = chord-reload-update-frequency && chord-reload-ping-frequency do = not  properly represent themselves within the xml. It is "chord:" = when it should be at least IMHO = "chord:reload:".

Julian
= --Apple-Mail-1--468411159-- From julian@orchidseed.org Fri Sep 11 22:15:24 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFAAD3A67EB for ; Fri, 11 Sep 2009 22:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCr8DA45xmLY for ; Fri, 11 Sep 2009 22:15:24 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id 046883A672E for ; Fri, 11 Sep 2009 22:15:23 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:46132 helo=[10.0.1.8]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MmKxt-0003Uv-AB for p2psip@ietf.org; Fri, 11 Sep 2009 22:16:02 -0700 From: jc Content-Type: multipart/alternative; boundary=Apple-Mail-1--452551001 Date: Fri, 11 Sep 2009 22:15:55 -0700 Message-Id: <4BE1B9C2-2AD7-48D0-BA50-A3683E2E075E@orchidseed.org> To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1075.2) X-Mailer: Apple Mail (2.1075.2) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 10.4. Searching for a Bootstrap Peer X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2009 05:15:25 -0000 --Apple-Mail-1--452551001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Hi, This section states: If no cached bootstrap peers are available and the config file has an broadcast-peers element ...however there is no "broadcast-peers" element. Also the draft doesn't mention anywhere that all nodes must subscribe to the multicast group "multicast-bootstrap" if it is found in the configuration file. I assume the later is the intended to be there but simply missing? Julian --Apple-Mail-1--452551001 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi,
This section states:

If no cached bootstrap peers are available and the config file has an broadcast-peers element

...however there is no "broadcast-peers" element. Also the draft doesn't mention anywhere that all nodes must subscribe to the multicast group "multicast-bootstrap"
if it is found in the configuration file. I assume the later is the intended to be there but simply missing?

Julian

--Apple-Mail-1--452551001-- From T.Kluge@gmx.com Wed Sep 16 02:34:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987413A67AB for ; Wed, 16 Sep 2009 02:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQXx3enwQ2lc for ; Wed, 16 Sep 2009 02:34:56 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id EFB943A67F3 for ; Wed, 16 Sep 2009 02:34:55 -0700 (PDT) Received: (qmail invoked by alias); 16 Sep 2009 09:35:43 -0000 Received: from unknown (EHLO Thomas) [141.39.41.76] by mail.gmx.net (mp064) with SMTP; 16 Sep 2009 11:35:43 +0200 X-Authenticated: #22022137 X-Provags-ID: V01U2FsdGVkX19yP11iWh9yW6EUHETbFeMhcz4CipTHNFXBAygWqL 7+T5zXjRfT1G8O Message-ID: <3BE49FFF2994498CA09906C42ED01CC5@Thomas> From: "Thomas Kluge" To: Date: Wed, 16 Sep 2009 11:35:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Y-GMX-Trusted: 0 X-FuHaFi: 0.67 Subject: [P2PSIP] Successor via Ping? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 09:38:36 -0000 Section 9.5. Joining states: "In order to populate its neighbor table, JP sends a Ping via the bootstrap node directed at Resource-ID n+1 (directly after its own Resource-ID). This allows it to discover its own successor." I have no idea how this could be accomplished. I would start from the Joining Peer side with a Forwarding Header filled with a Destination List containing the Resource-ID n+1, where I understand the ressource ID is my hashed node id +1. So far so good, I send that to the bootstrap- node. My intention would be to get the node id from my admitting peer (successor). But Ping will only return failure or a little PingAns struct with no information about the node id where it comes from. The Via lists would be empty as stated in 3.3. Routing. So I see no header information which could give me the needed information. What is my error in reasoning here? TIA Thomas From ekr@rtfm.com Wed Sep 16 05:12:45 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E60C3A69ED for ; Wed, 16 Sep 2009 05:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqIJfwn3Jh6a for ; Wed, 16 Sep 2009 05:12:45 -0700 (PDT) Received: from mail-yx0-f194.google.com (mail-yx0-f194.google.com [209.85.210.194]) by core3.amsl.com (Postfix) with ESMTP id DBCF13A697A for ; Wed, 16 Sep 2009 05:12:44 -0700 (PDT) Received: by yxe32 with SMTP id 32so949281yxe.5 for ; Wed, 16 Sep 2009 05:13:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.135.36 with SMTP id m36mr8978386ann.49.1253103211076; Wed, 16 Sep 2009 05:13:31 -0700 (PDT) In-Reply-To: <3BE49FFF2994498CA09906C42ED01CC5@Thomas> References: <3BE49FFF2994498CA09906C42ED01CC5@Thomas> Date: Wed, 16 Sep 2009 05:13:31 -0700 Message-ID: From: Eric Rescorla To: Thomas Kluge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Successor via Ping? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 12:12:45 -0000 All messages are signed and this includes the signer identity. -Ekr On Wed, Sep 16, 2009 at 2:35 AM, Thomas Kluge wrote: > > Section 9.5. Joining states: > "In order to populate its neighbor table, JP sends a Ping via the > =A0bootstrap node directed at Resource-ID n+1 (directly after its own > =A0Resource-ID). =A0This allows it to discover its own successor." > > > I have no idea how this could be accomplished. I would start from the > Joining Peer side with a Forwarding Header filled with a Destination List > containing the Resource-ID n+1, where I understand the ressource ID > is my hashed node id +1. So far so good, I send that to the bootstrap- > node. My intention would be to get the node id from my admitting peer > (successor). But Ping will only return failure or a little PingAns struct > with > no information about the node id where it comes from. The Via lists would > be empty as stated in 3.3. Routing. So I see no header information which > could give me the needed information. > > What is my error in reasoning here? > > TIA > Thomas > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Wed Sep 16 22:29:54 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8753A67A7 for ; Wed, 16 Sep 2009 22:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxRHsZAq+NQj for ; Wed, 16 Sep 2009 22:29:53 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id E39133A6840 for ; Wed, 16 Sep 2009 22:29:53 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:34653 helo=[10.0.1.8]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mo9Zr-0001oR-9Q for p2psip@ietf.org; Wed, 16 Sep 2009 22:30:44 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Wed, 16 Sep 2009 22:30:39 -0700 Message-Id: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 05:29:55 -0000 Hi, States "MAY contain any user name of the user choice", this is subjectAltName? Julian From julian@orchidseed.org Thu Sep 17 02:07:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78F1D28C174 for ; Thu, 17 Sep 2009 02:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu5bzxgCRlie for ; Thu, 17 Sep 2009 02:07:46 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id 9E38A28C0CE for ; Thu, 17 Sep 2009 02:07:46 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:38923 helo=[10.0.1.8]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MoCyi-0007kc-Ab for p2psip@ietf.org; Thu, 17 Sep 2009 02:08:37 -0700 From: jc Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1--6598394 Date: Thu, 17 Sep 2009 02:08:28 -0700 In-Reply-To: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> To: p2psip WG References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> Message-Id: X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 09:07:47 -0000 --Apple-Mail-1--6598394 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes I looked at some other areas and the problem is the draft doesn't clearly state fields that X509 certificates MUST contain or misrepresents them case-wise. For instance: 7. Certificate Store Usage user name Node-ID 12.5.1. Authorization User name Node-ID Serial There are several other references as well. Since this is a string variable inside of an X509 certificate the names need to be case normalized. Julian On Sep 16, 2009, at 10:30 PM, jc wrote: > Hi, > States "MAY contain any user name of the user choice", this is > subjectAltName? User name or user name? > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --Apple-Mail-1--6598394 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I looked at some other areas = and the problem is the draft doesn't clearly state fields that X509 = certificates MUST contain or misrepresents them case-wise.

For = instance:

7.  Certificate Store Usage
user = name
Node-ID

12.5.1. Authorization
User = name
Node-ID
Serial

There are several other references as = well. Since this is a string variable inside of an X509 certificate the = names need to be case normalized.

Julian

On = Sep 16, 2009, at 10:30 PM, jc wrote:

Hi,
States "MAY contain any user name of the user = choice",  this is = subjectAltName?

User name or user = name?


Julian
______________________________________________= _
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.or= g/mailman/listinfo/p2psip

= --Apple-Mail-1--6598394-- From ekr@rtfm.com Thu Sep 17 06:50:12 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEFA43A69EC for ; Thu, 17 Sep 2009 06:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t929UfduZnq6 for ; Thu, 17 Sep 2009 06:50:12 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id D710B3A692C for ; Thu, 17 Sep 2009 06:50:10 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c5so155174anc.4 for ; Thu, 17 Sep 2009 06:50:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.17.27 with SMTP id 27mr69681anq.199.1253195459499; Thu, 17 Sep 2009 06:50:59 -0700 (PDT) In-Reply-To: References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> Date: Thu, 17 Sep 2009 06:50:59 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 13:50:13 -0000 These aren't fields in the certificate. The relevant field is either DN or subjectAltName (I don't have the draft in front of me to remember what we decided). -Ekr On Thu, Sep 17, 2009 at 2:08 AM, jc wrote: > I looked at some other areas and the problem is the draft doesn't clearly > state fields that X509 certificates MUST contain or misrepresents them > case-wise. > > For instance: > > 7. =A0Certificate Store Usage > user name > Node-ID > 12.5.1. Authorization > User name > Node-ID > Serial > > There are several other references as well. Since this is a string variab= le > inside of an X509 certificate the names need to be case normalized. > Julian > > On Sep 16, 2009, at 10:30 PM, jc wrote: > > Hi, > States "MAY contain any user name of the user choice", =A0this is > subjectAltName? > > User name or user name? > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From julian@orchidseed.org Thu Sep 17 10:52:32 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADBA33A6993 for ; Thu, 17 Sep 2009 10:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrQJ+FrBgX79 for ; Thu, 17 Sep 2009 10:52:32 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 10A713A6992 for ; Thu, 17 Sep 2009 10:52:31 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:33721 helo=[10.0.1.8]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MoLAX-0000QQ-Kf for p2psip@ietf.org; Thu, 17 Sep 2009 10:53:23 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Thu, 17 Sep 2009 10:53:11 -0700 Message-Id: To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 3.1 Security and Identification X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 17:52:32 -0000 "RELOAD supports two certificate issuance models." This should state "Three", central enrollment, self-signed and shared key. Julian From julian@orchidseed.org Thu Sep 17 14:07:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8931D3A6902 for ; Thu, 17 Sep 2009 14:07:22 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCy39taqBPUx for ; Thu, 17 Sep 2009 14:07:21 -0700 (PDT) Received: from n13.c05.mtsvc.net (n13.c05.mtsvc.net [70.32.68.13]) by core3.amsl.com (Postfix) with ESMTP id D611D3A6821 for ; Thu, 17 Sep 2009 14:07:21 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:44294 helo=[10.0.1.8]) by n13.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MoOD5-0001HS-Jm; Thu, 17 Sep 2009 14:08:14 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: Date: Thu, 17 Sep 2009 14:08:07 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:07:22 -0000 If it is simply subjectAltName then I guess the question is how is data stored here? It may hold multiple Node-ID's, a single user name, and other elements so it MUST be a dictionary or key/value pairs or some other storage. Julian On Sep 17, 2009, at 6:50 AM, Eric Rescorla wrote: > These aren't fields in the certificate. The relevant field is either > DN or > subjectAltName (I don't have the draft in front of me to remember what > we decided). > > -Ekr > From ekr@rtfm.com Thu Sep 17 14:09:09 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92113A6A38 for ; Thu, 17 Sep 2009 14:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tV8eAW7dAI5 for ; Thu, 17 Sep 2009 14:09:07 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 5C4CA3A6AB2 for ; Thu, 17 Sep 2009 14:08:53 -0700 (PDT) Received: by pxi3 with SMTP id 3so335128pxi.31 for ; Thu, 17 Sep 2009 14:09:40 -0700 (PDT) Received: by 10.114.164.4 with SMTP id m4mr808127wae.172.1253221780220; Thu, 17 Sep 2009 14:09:40 -0700 (PDT) Received: from ?10.156.93.236? ([166.205.134.45]) by mx.google.com with ESMTPS id 20sm506716pxi.0.2009.09.17.14.09.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 14:09:39 -0700 (PDT) References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> Message-Id: From: Eric Rescorla To: jc In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Date: Thu, 17 Sep 2009 14:09:29 -0700 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:09:09 -0000 Certs can have multiple SAN fields Ek On Sep 17, 2009, at 2:08 PM, jc wrote: > If it is simply subjectAltName then I guess the question is how is > data stored here? It may hold multiple Node-ID's, a single user > name, and other elements so it MUST be a dictionary or key/value > pairs or some other storage. > > Julian > > On Sep 17, 2009, at 6:50 AM, Eric Rescorla wrote: > >> These aren't fields in the certificate. The relevant field is >> either DN or >> subjectAltName (I don't have the draft in front of me to remember >> what >> we decided). >> >> -Ekr >> > From julian@orchidseed.org Thu Sep 17 14:21:06 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76DD33A6941 for ; Thu, 17 Sep 2009 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQwWFUTmVOkY for ; Thu, 17 Sep 2009 14:21:05 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id B724C3A68D5 for ; Thu, 17 Sep 2009 14:21:05 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:40056 helo=[10.0.1.8]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MoOQO-0005te-Oy; Thu, 17 Sep 2009 14:21:58 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: Date: Thu, 17 Sep 2009 14:21:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <3572A849-FAFC-43AE-A4B5-84417CC9E54B@orchidseed.org> References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:21:06 -0000 Right thanks, however these SAN fields aren't in the draft and MUST be for implementation. Certificate example: NID_subject_alt_name "node_id:0123456789" NID_subject_alt_name "node_id:0123456987" NID_subject_alt_name "user_name:foo@bar.com" Julian On Sep 17, 2009, at 2:09 PM, Eric Rescorla wrote: > Certs can have multiple SAN fields > > Ek > > On Sep 17, 2009, at 2:08 PM, jc wrote: > >> If it is simply subjectAltName then I guess the question is how is >> data stored here? It may hold multiple Node-ID's, a single user >> name, and other elements so it MUST be a dictionary or key/value >> pairs or some other storage. >> >> Julian >> >> On Sep 17, 2009, at 6:50 AM, Eric Rescorla wrote: >> >>> These aren't fields in the certificate. The relevant field is >>> either DN or >>> subjectAltName (I don't have the draft in front of me to remember >>> what >>> we decided). >>> >>> -Ekr >>> >> From ekr@rtfm.com Thu Sep 17 14:43:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7673A69B4 for ; Thu, 17 Sep 2009 14:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhSHyT-FxP1Z for ; Thu, 17 Sep 2009 14:43:03 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id EB12E3A6A7E for ; Thu, 17 Sep 2009 14:42:55 -0700 (PDT) Received: by pxi3 with SMTP id 3so354643pxi.31 for ; Thu, 17 Sep 2009 14:43:29 -0700 (PDT) Received: by 10.115.114.7 with SMTP id r7mr915049wam.72.1253223809498; Thu, 17 Sep 2009 14:43:29 -0700 (PDT) Received: from ?10.156.93.236? ([166.205.134.45]) by mx.google.com with ESMTPS id 23sm520623pxi.9.2009.09.17.14.43.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 17 Sep 2009 14:43:28 -0700 (PDT) References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <3572A849-FAFC-43AE-A4B5-84417CC9E54B@orchidseed.org> Message-Id: <6EDCBF46-37E0-4491-9103-5BC1FA3DBA0E@rtfm.com> From: Eric Rescorla To: jc In-Reply-To: <3572A849-FAFC-43AE-A4B5-84417CC9E54B@orchidseed.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Date: Thu, 17 Sep 2009 14:43:20 -0700 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 21:43:07 -0000 It is in the draft in s 10.3. nodeids are expressed as Uris. User names are rfc822names Ekr On Sep 17, 2009, at 2:21 PM, jc wrote: > Right thanks, however these SAN fields aren't in the draft and MUST > be for implementation. > > Certificate example: > > NID_subject_alt_name "node_id:0123456789" > NID_subject_alt_name "node_id:0123456987" > NID_subject_alt_name "user_name:foo@bar.com" > > Julian > > On Sep 17, 2009, at 2:09 PM, Eric Rescorla wrote: > >> Certs can have multiple SAN fields >> >> Ek >> >> On Sep 17, 2009, at 2:08 PM, jc wrote: >> >>> If it is simply subjectAltName then I guess the question is how is >>> data stored here? It may hold multiple Node-ID's, a single user >>> name, and other elements so it MUST be a dictionary or key/value >>> pairs or some other storage. >>> >>> Julian >>> >>> On Sep 17, 2009, at 6:50 AM, Eric Rescorla wrote: >>> >>>> These aren't fields in the certificate. The relevant field is >>>> either DN or >>>> subjectAltName (I don't have the draft in front of me to remember >>>> what >>>> we decided). >>>> >>>> -Ekr >>>> >>> > From wwwrun@core3.amsl.com Thu Sep 17 09:26:16 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 674DD28C2BB; Thu, 17 Sep 2009 09:26:16 -0700 (PDT) To: even.roni@huawei.com, dbryan@ethernot.org, jiang.x.f@huawei.com, melodysong@huawei.com From: IETF Secretariat Message-Id: <20090917162616.674DD28C2BB@core3.amsl.com> Date: Thu, 17 Sep 2009 09:26:16 -0700 (PDT) X-Mailman-Approved-At: Fri, 18 Sep 2009 14:09:03 -0700 Cc: p2psip@ietf.org, ipr-announce@ietf.org Subject: [P2PSIP] Posting of IPR Disclosure related to HUAWEI TECHNOLOGIES CO., LTD 's Statement about IPR related to draft-ietf-p2psip-diagnostics-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2009 16:26:16 -0000 Dear Roni Even, David Bryan, XingFeng Jiang, Song Yongchao: An IPR disclosure that pertains to your Internet-Draft entitled "P2PSIP Overlay Diagnostics" (draft-ietf-p2psip-diagnostics) was submitted to the IETF Secretariat on 2009-09-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1190/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD 's Statement about IPR related to draft-ietf-p2psip-diagnostics-01." The IETF Secretariat From wwwrun@core3.amsl.com Fri Sep 18 12:12:16 2009 Return-Path: X-Original-To: p2psip@ietf.org Delivered-To: p2psip@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9528F3A6B73; Fri, 18 Sep 2009 12:12:16 -0700 (PDT) To: ekr@networkresonance.com, fluffy@cisco.com, salman@cs.columbia.edu, hgs@cs.columbia.edu, bbl@lowekamp.net From: IETF Secretariat Message-Id: <20090918191216.9528F3A6B73@core3.amsl.com> Date: Fri, 18 Sep 2009 12:12:16 -0700 (PDT) X-Mailman-Approved-At: Fri, 18 Sep 2009 14:09:04 -0700 Cc: p2psip@ietf.org, ipr-announce@ietf.org Subject: [P2PSIP] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-ietf-p2psip-base-03 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 19:12:16 -0000 Dear Eric Rescorla, Cullen Jennings, Salman Baset, Henning Schulzrinne, Bruce Lowekamp: An IPR disclosure that pertains to your Internet-Draft entitled "REsource LOcation And Discovery (RELOAD) Base Protocol" (draft-ietf-p2psip-base) was submitted to the IETF Secretariat on 2009-09-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1191/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-p2psip-base-03." The IETF Secretariat From julian@orchidseed.org Fri Sep 18 17:16:42 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D79DB3A6A36 for ; Fri, 18 Sep 2009 17:16:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daMZ8A-ZRPbJ for ; Fri, 18 Sep 2009 17:16:42 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 3621A3A63CB for ; Fri, 18 Sep 2009 17:16:42 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:39934 helo=[10.0.1.8]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mondv-0003HJ-RB for p2psip@ietf.org; Fri, 18 Sep 2009 17:17:37 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Fri, 18 Sep 2009 17:17:33 -0700 Message-Id: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 00:16:42 -0000 Hi, "If authentication is required, there is a URL parameter of "password" and..." It's not possible to send URL parameters with a POST with a content- type of application/pkix-cert. Julian From ekr@rtfm.com Fri Sep 18 17:30:33 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 492EB3A6861 for ; Fri, 18 Sep 2009 17:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wE4+iCaaRjF for ; Fri, 18 Sep 2009 17:30:32 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id B41CC3A6855 for ; Fri, 18 Sep 2009 17:30:27 -0700 (PDT) Received: by yxe30 with SMTP id 30so1604953yxe.29 for ; Fri, 18 Sep 2009 17:31:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.8.10 with SMTP id 10mr1434310agh.114.1253320269803; Fri, 18 Sep 2009 17:31:09 -0700 (PDT) In-Reply-To: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> Date: Fri, 18 Sep 2009 17:31:09 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 00:30:33 -0000 Hmm... I'm not sure that's actually true. I just skimmed through the relevant sections of RFC 2616 and I actually don't see a prohibition on using query parameters with POST. What section do you believe prohibits this? -Ekr On Fri, Sep 18, 2009 at 5:17 PM, jc wrote: > Hi, > > "If authentication is required, there is a URL parameter of "password" > and..." > > It's not possible to send URL parameters with a POST with a content-type of > application/pkix-cert. > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From theo@crazygreek.co.uk Fri Sep 18 17:37:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9513A68C2 for ; Fri, 18 Sep 2009 17:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLtCn5S8Yq-D for ; Fri, 18 Sep 2009 17:37:15 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by core3.amsl.com (Postfix) with SMTP id E89383A6824 for ; Fri, 18 Sep 2009 17:37:14 -0700 (PDT) Received: from source ([209.85.218.219]) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKSrQn8Q++BkoFL6YRWLmqBjmmC322xy2i@postini.com; Fri, 18 Sep 2009 17:38:11 PDT Received: by bwz19 with SMTP id 19so1137029bwz.35 for ; Fri, 18 Sep 2009 17:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.1.18 with SMTP id 18mr534334fad.90.1253320689082; Fri, 18 Sep 2009 17:38:09 -0700 (PDT) In-Reply-To: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> From: Theo Zourzouvillys Date: Fri, 18 Sep 2009 17:37:49 -0700 Message-ID: <167dfb9b0909181737x331fc2f3s5f668b2d3699051@mail.gmail.com> To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 00:37:16 -0000 On Fri, Sep 18, 2009 at 5:17 PM, jc wrote: > It's not possible to send URL parameters with a POST with a content-type of > application/pkix-cert. Yes, it is possible - and a totally valid thing to do. ~ Theo From julian@orchidseed.org Fri Sep 18 17:52:16 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAF683A68B1 for ; Fri, 18 Sep 2009 17:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqGaF2TYCbte for ; Fri, 18 Sep 2009 17:52:16 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id EEAAE3A67FB for ; Fri, 18 Sep 2009 17:52:15 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:40373 helo=[10.0.1.8]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MooCI-00032l-Su; Fri, 18 Sep 2009 17:53:08 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: Date: Fri, 18 Sep 2009 17:53:00 -0700 Content-Transfer-Encoding: 7bit Message-Id: <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 00:52:16 -0000 If content-type = application/pkix-cert in the request then the server application won't be able to pull these out. Example: $_POST["password"] would be null in php because application/x- www-form-urlencoded is NOT the content-type. Julian On Sep 18, 2009, at 5:31 PM, Eric Rescorla wrote: > Hmm... I'm not sure that's actually true. > > I just skimmed through the relevant sections of RFC 2616 and I > actually > don't see a prohibition on using query parameters with POST. What > section do you believe prohibits this? > > -Ekr > > > On Fri, Sep 18, 2009 at 5:17 PM, jc wrote: >> Hi, >> >> "If authentication is required, there is a URL parameter of >> "password" >> and..." >> >> It's not possible to send URL parameters with a POST with a content- >> type of >> application/pkix-cert. >> >> Julian >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> From theo@crazygreek.co.uk Fri Sep 18 17:56:34 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDFB3A68B1 for ; Fri, 18 Sep 2009 17:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.827 X-Spam-Level: X-Spam-Status: No, score=-5.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJLZkYec+gLg for ; Fri, 18 Sep 2009 17:56:32 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with SMTP id A73CD3A6816 for ; Fri, 18 Sep 2009 17:56:31 -0700 (PDT) Received: from source ([209.85.220.211]) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKSrQsdh/opRLwY8XcgUehf70gxStY3cUx@postini.com; Fri, 18 Sep 2009 17:57:27 PDT Received: by fxm7 with SMTP id 7so1036701fxm.34 for ; Fri, 18 Sep 2009 17:57:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.21.15 with SMTP id h15mr578133fab.15.1253321846098; Fri, 18 Sep 2009 17:57:26 -0700 (PDT) In-Reply-To: <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> From: Theo Zourzouvillys Date: Fri, 18 Sep 2009 17:57:06 -0700 Message-ID: <167dfb9b0909181757w1f6aae96m782ecfdc3801afe7@mail.gmail.com> To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 00:56:34 -0000 On Fri, Sep 18, 2009 at 5:53 PM, jc wrote: > If content-type = application/pkix-cert in the request then the server > application won't be able to pull these out. > > Example: $_POST["password"] would be null in php because > application/x-www-form-urlencoded is NOT the content-type. > POST to http://moo.com/cows.php?password=udder if ($_GET['password'] != 'udder') ... ~ Theo -- Sent from Brisbane, California, United States From julian@orchidseed.org Fri Sep 18 18:01:41 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ADEA3A68B1 for ; Fri, 18 Sep 2009 18:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bN+zkAUVMyR4 for ; Fri, 18 Sep 2009 18:01:40 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id A10D43A6816 for ; Fri, 18 Sep 2009 18:01:40 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:34194 helo=[10.0.1.8]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MooLR-0008Jt-Li; Fri, 18 Sep 2009 18:02:35 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <167dfb9b0909181757w1f6aae96m782ecfdc3801afe7@mail.gmail.com> Date: Fri, 18 Sep 2009 18:02:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: <853E23B0-E237-41AA-9FE8-0FBEF1B2C8D7@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> <167dfb9b0909181757w1f6aae96m782ecfdc3801afe7@mail.gmail.com> To: Theo Zourzouvillys X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 01:01:41 -0000 That was my point to begin with. You cannot do a POST with URL parameters without a GET. Julian On Sep 18, 2009, at 5:57 PM, Theo Zourzouvillys wrote: > On Fri, Sep 18, 2009 at 5:53 PM, jc wrote: >> If content-type = application/pkix-cert in the request then the >> server >> application won't be able to pull these out. >> >> Example: $_POST["password"] would be null in php because >> application/x-www-form-urlencoded is NOT the content-type. >> > > POST to http://moo.com/cows.php?password=udder > > if ($_GET['password'] != 'udder') > ... > > ~ Theo > > -- > > Sent from Brisbane, California, United States From julian@orchidseed.org Fri Sep 18 18:12:21 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A721C3A6836 for ; Fri, 18 Sep 2009 18:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0SEKd+Y2WBU for ; Fri, 18 Sep 2009 18:12:20 -0700 (PDT) Received: from n20.c05.mtsvc.net (n20.c05.mtsvc.net [70.32.68.20]) by core3.amsl.com (Postfix) with ESMTP id C4A753A67D2 for ; Fri, 18 Sep 2009 18:12:20 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:34272 helo=[10.0.1.8]) by n20.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MooVm-000591-5H; Fri, 18 Sep 2009 18:13:15 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <167dfb9b0909181757w1f6aae96m782ecfdc3801afe7@mail.gmail.com> Date: Fri, 18 Sep 2009 18:13:12 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> <167dfb9b0909181757w1f6aae96m782ecfdc3801afe7@mail.gmail.com> To: Theo Zourzouvillys X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 01:12:21 -0000 Thanks for pointing out that it's ok to do this in php. It seemed like a hack to me because i've simply never seen it done. Working fine with my nodes and credential server, all happy. :-) Julian On Sep 18, 2009, at 5:57 PM, Theo Zourzouvillys wrote: > On Fri, Sep 18, 2009 at 5:53 PM, jc wrote: >> If content-type = application/pkix-cert in the request then the >> server >> application won't be able to pull these out. >> >> Example: $_POST["password"] would be null in php because >> application/x-www-form-urlencoded is NOT the content-type. >> > > POST to http://moo.com/cows.php?password=udder > > if ($_GET['password'] != 'udder') > ... > > ~ Theo > > -- > > Sent from Brisbane, California, United States From theo@crazygreek.co.uk Fri Sep 18 18:13:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D49133A6816 for ; Fri, 18 Sep 2009 18:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFjhHpmZpll8 for ; Fri, 18 Sep 2009 18:13:09 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by core3.amsl.com (Postfix) with SMTP id 427AD3A67A5 for ; Fri, 18 Sep 2009 18:13:09 -0700 (PDT) Received: from source ([209.85.218.209]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKSrQwXN2LEFWph+5vN7UupZnrxgS0tlYM@postini.com; Fri, 18 Sep 2009 18:14:05 PDT Received: by bwz5 with SMTP id 5so1342773bwz.27 for ; Fri, 18 Sep 2009 18:14:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.74.91 with SMTP id t27mr528257faj.62.1253322842994; Fri, 18 Sep 2009 18:14:02 -0700 (PDT) In-Reply-To: <853E23B0-E237-41AA-9FE8-0FBEF1B2C8D7@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> <167dfb9b0909181757w1f6aae96m782ecfdc3801afe7@mail.gmail.com> <853E23B0-E237-41AA-9FE8-0FBEF1B2C8D7@orchidseed.org> From: Theo Zourzouvillys Date: Fri, 18 Sep 2009 18:13:42 -0700 Message-ID: <167dfb9b0909181813j76bd870cp6c34b522b643b843@mail.gmail.com> To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 01:13:10 -0000 On Fri, Sep 18, 2009 at 6:02 PM, jc wrote: > That was my point to begin with. You cannot do a POST with URL parameters > without a GET. > huu? # telnet moo.cows 80 -> POST /cows.php?password=udder HTTP/1.0 -> Host: cows.com -> Content-Type: aplpication/pkix -> Content-Length: xxx ->... -> -> [some data] # cat cows.php X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 206963A6821 for ; Fri, 18 Sep 2009 19:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ew5o43Beo5lO for ; Fri, 18 Sep 2009 19:24:08 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 3B5DC28C105 for ; Fri, 18 Sep 2009 19:24:03 -0700 (PDT) Received: by yxe30 with SMTP id 30so1672176yxe.29 for ; Fri, 18 Sep 2009 19:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.19.26 with SMTP id w26mr1527325agi.17.1253327093582; Fri, 18 Sep 2009 19:24:53 -0700 (PDT) In-Reply-To: <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> References: <6F780DD4-F04E-4C8D-B7FF-8ACA85729B76@orchidseed.org> <908B95ED-C8E7-4D06-ACDE-9C66331257F5@orchidseed.org> Date: Fri, 18 Sep 2009 19:24:53 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3 Credentials - URL Paramaters Not Possible X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 02:24:09 -0000 On Fri, Sep 18, 2009 at 5:53 PM, jc wrote: > If content-type = application/pkix-cert in the request then the server > application won't be able to pull these out. > > Example: $_POST["password"] would be null in php because > application/x-www-form-urlencoded is NOT the content-type. What does PHP have to do with anything? The server proper has the URI and the body available to it. If there is some language that doesn't allow access to that data, that's a deficiency in the language, not a protocol issue. -Ekr From michaelc@idssoftware.com Thu Sep 24 07:24:31 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011243A69F3 for ; Thu, 24 Sep 2009 07:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urDH8Wq+u7NA for ; Thu, 24 Sep 2009 07:24:29 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id C714D3A6881 for ; Thu, 24 Sep 2009 07:24:29 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MqpGM-0008J5-4a; Thu, 24 Sep 2009 10:25:38 -0400 Message-ID: <4ABB82AD.7030201@idssoftware.com> Date: Thu, 24 Sep 2009 07:31:09 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> In-Reply-To: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94087cf038a96fdd509c211df891e0b886e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 14:24:31 -0000 Julian, In our implementation, we search for rfc822Name format in all X509 fields in the following order: CN emailAddress Placing the "name@domain" in the CN of the certificate yields smaller X509 structure that uses no V3 extensions, and it defines both the overlay name ("domain" part) and the AoR. It's perfect for a small self-sign certificate. --Michael jc wrote: > Hi, > States "MAY contain any user name of the user choice", this is > subjectAltName? > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From ekr@rtfm.com Thu Sep 24 08:05:56 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 161283A6842 for ; Thu, 24 Sep 2009 08:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWw-J1a1eI5Q for ; Thu, 24 Sep 2009 08:05:55 -0700 (PDT) Received: from mail-px0-f173.google.com (mail-px0-f173.google.com [209.85.216.173]) by core3.amsl.com (Postfix) with ESMTP id 702F73A682E for ; Thu, 24 Sep 2009 08:05:55 -0700 (PDT) Received: by pxi3 with SMTP id 3so2165042pxi.31 for ; Thu, 24 Sep 2009 08:07:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.69.19 with SMTP id r19mr5389025waa.117.1253804821895; Thu, 24 Sep 2009 08:07:01 -0700 (PDT) In-Reply-To: <4ABB82AD.7030201@idssoftware.com> References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> Date: Thu, 24 Sep 2009 08:07:01 -0700 Message-ID: From: ekr To: Michael Chen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 15:05:56 -0000 On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen wr= ote: > Julian, > > In our implementation, we search for rfc822Name format in all X509 fields= in > the following order: > > =A0CN This seems like it is not compliant with the current draft. > =A0emailAddress This is definitely not compliant and I don't see why it would be OK under any circumstances. -Ekr From davidbryan@gmail.com Thu Sep 24 09:48:28 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF1C428C159 for ; Thu, 24 Sep 2009 09:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zIZ7VLXPG57 for ; Thu, 24 Sep 2009 09:48:28 -0700 (PDT) Received: from mail-yx0-f174.google.com (mail-yx0-f174.google.com [209.85.210.174]) by core3.amsl.com (Postfix) with ESMTP id 0B11928C121 for ; Thu, 24 Sep 2009 09:48:27 -0700 (PDT) Received: by yxe4 with SMTP id 4so2113520yxe.32 for ; Thu, 24 Sep 2009 09:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=gLH1fR7sSY4kh6q0ZXSxjXDqONhchjAHIIXQ6E7fsvM=; b=vZ2y5RUXLdMqDt2dOyFVx+8tzEeKNep/xUvFLgvh65UR5wN7nd34w5KrRl5wqmFdt5 v0g1RBdBZyTAajTecxMHruT+JOlr2UObv7UQxMHJhAvtU3z5NQSzoTS9Pp61rSH/73Wn viusyTRnr9iOh2qQjd94DwclOQFR7FbAOx//E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=d526FCkwerX4/jElmwNHBPurmTIvC3/1/0XxfgQELGIPSbJ/WRc21an8VS0yTBH8Oa 4ztHJvE34YgLkLBmG87AAI5BPE4YTu4O2Qc9ULtrmWMORmHtLPXYhU/X+t4U+pq1/1M2 YiZbmhWtg27ep7wStdz9lx5DEl5ARJa6naFRM= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.253.11 with SMTP id a11mr327040ybi.81.1253810974425; Thu, 24 Sep 2009 09:49:34 -0700 (PDT) In-Reply-To: References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> Date: Thu, 24 Sep 2009 12:49:34 -0400 X-Google-Sender-Auth: 384356d9b704f321 Message-ID: <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> From: "David A. Bryan" To: ekr Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 16:48:29 -0000 Michael, I haven't had a chance to go back and reread the section in RELOAD or fully think about this particular issue too much yet (so I certainly have no opinions about the "right" way), but since this decision is coming from an actual implementation, can you share a bit why you made the decision you did? Was it motivated by a problem with the proposal in the draft? An optimization to improve the current draft after trying the other way? Or was it just that you did it that way before the draft, etc.? Obviously since we are still working on getting things right with the draft, nothing is set in stone quite yet, and it's always good to hear from implementors about why they made the decisions they did when they differ from the draft, so that we make sure we really are getting the best ideas. (especially here, where it seems, unfortunately, that there are only a few folks trying to implement RELOAD, or at least willing to talk about their implementation experience) Also, anything else you have done differently/found awkward/etc. in the current draft? It's not really so much a question of "compliance" with the current draft right now -- now is the time to discuss differences and find and address as many shortcomings in the current draft proposal as possible, so we get as many ideas as possible and the best protocol, then move it forward... My 2 cents David (as individual) On Thu, Sep 24, 2009 at 11:07 AM, ekr wrote: > On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen wrote: >> Julian, >> >> In our implementation, we search for rfc822Name format in all X509 fields in >> the following order: >> >> CN > > This seems like it is not compliant with the current draft. > >> emailAddress > > This is definitely not compliant and I don't see why it would be OK under > any circumstances. > > > -Ekr > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Thu Sep 24 12:35:10 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21D23A67D3 for ; Thu, 24 Sep 2009 12:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+yjHS+TXply for ; Thu, 24 Sep 2009 12:35:10 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id F35843A690D for ; Thu, 24 Sep 2009 12:35:09 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:35056 helo=[10.0.1.10]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mqu6z-0007ox-LM; Thu, 24 Sep 2009 12:36:18 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <4ABB82AD.7030201@idssoftware.com> Date: Thu, 24 Sep 2009 12:36:13 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 19:35:10 -0000 On Sep 24, 2009, at 7:31 AM, Michael Chen wrote: > Julian, > > In our implementation, we search for rfc822Name format in all X509 > fields in the following order: > > CN > emailAddress > > > Placing the "name@domain" in the CN of the certificate yields > smaller X509 structure that uses no V3 extensions, and it defines > both the overlay name ("domain" part) and the AoR. It's perfect for > a small self-sign certificate. > The "emailAddress" field is non-compliant with the draft. Why are you referring to X509 v3 extensions? Would you care to share the whats and whys of your usage? Thanks, Julian > --Michael > > jc wrote: >> Hi, >> States "MAY contain any user name of the user choice", this is >> subjectAltName? >> >> Julian >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> From neil.young@freenet.de Thu Sep 24 14:00:53 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 717C23A6916 for ; Thu, 24 Sep 2009 14:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRN3BiQKypKR for ; Thu, 24 Sep 2009 14:00:52 -0700 (PDT) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by core3.amsl.com (Postfix) with ESMTP id CCBAD3A690F for ; Thu, 24 Sep 2009 14:00:51 -0700 (PDT) Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout1.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #92) id 1MqvRu-0004OD-Uq for p2psip@ietf.org; Thu, 24 Sep 2009 23:01:58 +0200 Received: from p54bd8f1d.dip0.t-ipconnect.de ([84.189.143.29]:50463 helo=[192.168.178.38]) by 5.mx.freenet.de with esmtpa (ID roland.klabunde@freenet.de) (port 25) (Exim 4.69 #94) id 1MqvRu-0001tP-Jo for p2psip@ietf.org; Thu, 24 Sep 2009 23:01:58 +0200 Message-ID: <4ABBDE47.8090505@freenet.de> Date: Thu, 24 Sep 2009 23:01:59 +0200 From: "neil.young" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: p2psip WG References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> In-Reply-To: <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------040703080502080606070700" Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: neil.young@freenet.de List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 21:00:53 -0000 This is a multi-part message in MIME format. --------------040703080502080606070700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Probably the discussion you raised is worth a separate thread. I'm currently in the situation to evaluate whether RELOAD is the way to go or not (for our project). The scattered postings in this group may lead to the conclusion, that RELOAD has no relevance at all. I would be glad to hear, that this isn't the case. Regards David A. Bryan schrieb: > Michael, > > I haven't had a chance to go back and reread the section in RELOAD or > fully think about this particular issue too much yet (so I certainly > have no opinions about the "right" way), but since this decision is > coming from an actual implementation, can you share a bit why you made > the decision you did? Was it motivated by a problem with the proposal > in the draft? An optimization to improve the current draft after > trying the other way? Or was it just that you did it that way before > the draft, etc.? > > Obviously since we are still working on getting things right with the > draft, nothing is set in stone quite yet, and it's always good to hear > from implementors about why they made the decisions they did when they > differ from the draft, so that we make sure we really are getting the > best ideas. (especially here, where it seems, unfortunately, that > there are only a few folks trying to implement RELOAD, or at least > willing to talk about their implementation experience) > > Also, anything else you have done differently/found awkward/etc. in > the current draft? It's not really so much a question of "compliance" > with the current draft right now -- now is the time to discuss > differences and find and address as many shortcomings in the current > draft proposal as possible, so we get as many ideas as possible and > the best protocol, then move it forward... > > My 2 cents > > David (as individual) > > On Thu, Sep 24, 2009 at 11:07 AM, ekr wrote: > >> On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen wrote: >> >>> Julian, >>> >>> In our implementation, we search for rfc822Name format in all X509 fields in >>> the following order: >>> >>> CN >>> >> This seems like it is not compliant with the current draft. >> >> >>> emailAddress >>> >> This is definitely not compliant and I don't see why it would be OK under >> any circumstances. >> >> >> -Ekr >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > --------------040703080502080606070700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Probably the discussion you raised is worth a separate thread. I'm currently in the situation to evaluate whether RELOAD is the way to go or not (for our project). The scattered postings in this group may lead to the conclusion, that RELOAD has no relevance at all. I would be glad to hear, that this isn't the case.

Regards


David A. Bryan schrieb:
Michael,

I haven't had a chance to go back and reread the section in RELOAD or
fully think about this particular issue too much yet (so I certainly
have no opinions about the "right" way), but since this decision is
coming from an actual implementation, can you share a bit why you made
the decision you did? Was it motivated by a problem with the proposal
in the draft? An optimization to improve the current draft after
trying the other way? Or was it just that you did it that way before
the draft, etc.?

Obviously since we are still working on getting things right with the
draft, nothing is set in stone quite yet, and it's always good to hear
from implementors about why they made the decisions they did when they
differ from the draft, so that we make sure we really are getting the
best ideas. (especially here, where it seems, unfortunately, that
there are only a few folks trying to implement RELOAD, or at least
willing to talk about their implementation experience)

Also, anything else you have done differently/found awkward/etc. in
the current draft? It's not really so much a question of "compliance"
with the current draft right now -- now is the time to discuss
differences and find and address as many shortcomings in the current
draft proposal as possible, so we get as many ideas as possible and
the best protocol, then move it forward...

My 2 cents

David (as individual)

On Thu, Sep 24, 2009 at 11:07 AM, ekr <ekr@rtfm.com> wrote:
  
On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen <michaelc@idssoftware.com> wrote:
    
Julian,

In our implementation, we search for rfc822Name format in all X509 fields in
the following order:

 CN
      
This seems like it is not compliant with the current draft.

    
 emailAddress
      
This is definitely not compliant and I don't see why it would be OK under
any circumstances.


-Ekr
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip

    
_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www.ietf.org/mailman/listinfo/p2psip
  
--------------040703080502080606070700-- From michaelc@idssoftware.com Thu Sep 24 21:28:58 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758273A6820 for ; Thu, 24 Sep 2009 21:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPDa6TRWsv3n for ; Thu, 24 Sep 2009 21:28:57 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 3D45D3A67D1 for ; Thu, 24 Sep 2009 21:28:57 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mr2RY-0005D1-C1; Fri, 25 Sep 2009 00:30:04 -0400 Message-ID: <4ABC4897.2090501@idssoftware.com> Date: Thu, 24 Sep 2009 21:35:35 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "David A. Bryan" References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> In-Reply-To: <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9407556e904b47ba5ca07a7b180b8974118350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 04:28:58 -0000 David, It all started way way back in late 2007 with this section of the draft: http://www.p2psip.org/drafts/draft-bryan-p2psip-reload-02.html#sec-cert-security The contents of the certificate include: * A public key provided by the user. * Zero, one, or more user names that the DHT is allowing this user to use. For example, "alice@example.org". Typically a certificate will have one name. In the SIP usage, this name corresponds to the AOR. Nothing explicit about which part of the X509 certificate should hold the AOR, just "name". As a convenient, we used JDK program keytool to generate self-signed certs instead of the more confusing openssl. It just so happens that JDK keytool encodes only DN (common name, etc), no X509 v3 extensions fields like subjectAltName and emailAddress (it is still this way with JDK 6). We simply put the AOR in the "least inappropriate" field, Common Name. Then we moved on and never thought about it much. I believe it will remove a great deal of confusion if you guys create a sample self-signed cert and put the output of the following OpenSSL command in the appendix: openssl x509 -text -in my_sip_cert.pem I also want to point out that even with the most simple encoding (JDK keytool), a 1024 bit RSA public key certificate takes up 619 bytes. A production strength 2048 bit RSA cert is 880 bytes. If a peer can only be reached via UDP, the overhead of DTLS + Reload Signature on message leaves very little room for the relevant data fragment (e.g. 1500 packet size), which means UDP transport may be very inefficient. Transport overhead should be a separate discussion thread. Thanks --Michael David A. Bryan wrote: > Michael, > > I haven't had a chance to go back and reread the section in RELOAD or > fully think about this particular issue too much yet (so I certainly > have no opinions about the "right" way), but since this decision is > coming from an actual implementation, can you share a bit why you made > the decision you did? Was it motivated by a problem with the proposal > in the draft? An optimization to improve the current draft after > trying the other way? Or was it just that you did it that way before > the draft, etc.? > > Obviously since we are still working on getting things right with the > draft, nothing is set in stone quite yet, and it's always good to hear > from implementors about why they made the decisions they did when they > differ from the draft, so that we make sure we really are getting the > best ideas. (especially here, where it seems, unfortunately, that > there are only a few folks trying to implement RELOAD, or at least > willing to talk about their implementation experience) > > Also, anything else you have done differently/found awkward/etc. in > the current draft? It's not really so much a question of "compliance" > with the current draft right now -- now is the time to discuss > differences and find and address as many shortcomings in the current > draft proposal as possible, so we get as many ideas as possible and > the best protocol, then move it forward... > > My 2 cents > > David (as individual) > > On Thu, Sep 24, 2009 at 11:07 AM, ekr wrote: > >> On Thu, Sep 24, 2009 at 7:31 AM, Michael Chen wrote: >> >>> Julian, >>> >>> In our implementation, we search for rfc822Name format in all X509 fields in >>> the following order: >>> >>> CN >>> >> This seems like it is not compliant with the current draft. >> >> >>> emailAddress >>> >> This is definitely not compliant and I don't see why it would be OK under >> any circumstances. >> >> >> -Ekr >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> >> > > > From julian@orchidseed.org Thu Sep 24 23:03:03 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 383D728C119 for ; Thu, 24 Sep 2009 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCuBoyzXuKD3 for ; Thu, 24 Sep 2009 23:03:00 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 1857728C0D7 for ; Thu, 24 Sep 2009 23:03:00 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:48102 helo=[10.0.1.10]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mr3ua-0001ES-F3; Thu, 24 Sep 2009 23:04:10 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1-673534834 From: jc In-Reply-To: <4ABC4897.2090501@idssoftware.com> Date: Thu, 24 Sep 2009 23:04:01 -0700 Message-Id: References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABC4897.2090501@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 06:03:03 -0000 --Apple-Mail-1-673534834 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 24, 2009, at 9:35 PM, Michael Chen wrote: > I also want to point out that even with the most simple encoding > (JDK keytool), a 1024 bit RSA public key certificate takes up 619 > bytes. A production strength 2048 bit RSA cert is 880 bytes. If a > peer can only be reached via UDP, the overhead of DTLS + Reload > Signature on message leaves very little room for the relevant data > fragment (e.g. 1500 packet size), which means UDP transport may be > very inefficient. Transport overhead should be a separate > discussion thread. In my RELOAD implementation a 2048 bit RSA public key is 691 bytes long, see output below. Do you have statistics that show the current fragmentation algorithm to be sub-optimal? Julian Running 1 test case... ......................+++ ........................+++ debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating RSA key. ..............................+++ ..............+++ debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating RSA key. debug: X509_NAME* junglecat::x509::allocate_common_name(const char*): Allocated debug: X509_NAME* junglecat::x509::allocate_common_name(const char*): Allocated debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, const char*, const char*, unsigned int, const EVP_MD*): Success Certificate: Data: Version: 3 (0x2) Serial Number: 1253857645 (0x4abc596d) Signature Algorithm: sha1WithRSAEncryption Issuer: CN=common_name_issuer Validity Not Before: Sep 25 05:47:25 2009 GMT Not After : Sep 25 06:47:25 2009 GMT Subject: CN=common_name Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02: 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0: aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14: aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4: da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f: d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7: e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44: 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e: 46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f: a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94: 66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd: 01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7: 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef: b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca: d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b: cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d: 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa: 0a:d3 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52: dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9: 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1: 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d: af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9: f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7: b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff: 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52: ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0: cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17: 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e: 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c: 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f: d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5: 8d:2a:7b:21 X509 structure size: 92 RSA structure size: 88 len:691 *** No errors detected --Apple-Mail-1-673534834 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
I also want to point out = that even with the most simple encoding (JDK keytool), a 1024 bit RSA = public key certificate takes up 619 bytes. A production strength 2048 = bit RSA cert is 880 bytes. If a peer can only be reached via UDP, the = overhead of DTLS + Reload Signature on message leaves very little room = for the relevant data fragment (e.g. 1500 packet size), which means UDP = transport may be very inefficient.  Transport overhead should be a = separate discussion thread.

In = my RELOAD implementation a 2048 bit RSA public key is  691 bytes = long, see output below. Do you have statistics that show the current = fragmentation algorithm to be = sub-optimal?
Julian

debug: RSA* = junglecat::rsa::generate_key_pair(): Succeeded generating RSA = key.
..............................+++
debug: RSA* = junglecat::rsa::generate_key_pair(): Succeeded generating RSA = key.
debug: X509_NAME* = junglecat::x509::allocate_common_name(const char*): = Allocated
debug: X509_NAME* = junglecat::x509::allocate_common_name(const char*): = Allocated
debug: X509* = junglecat::x509::generate_certificate(RSA*, RSA*, const char*, const = char*, unsigned int, const EVP_MD*): Success
    Data:
        Signature Algorithm: = sha1WithRSAEncryption
        = Issuer: CN=3Dcommon_name_issuer
        = Validity
            Not = Before: Sep 25 05:47:25 2009 GMT
          =   Not After : Sep 25 06:47:25 2009 GMT
            RSA = Public Key: (2048 bit)
          =       Modulus (2048 bit):
              =   Exponent: 65537 (0x10001)
    Signature Algorithm: = sha1WithRSAEncryption
        = 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:

X509 structure size: = 92
RSA structure size: 88

*** = No errors = detected
= --Apple-Mail-1-673534834-- From julian@orchidseed.org Sun Sep 27 00:45:59 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B65E03A682D for ; Sun, 27 Sep 2009 00:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.435 X-Spam-Level: X-Spam-Status: No, score=-1.435 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4mre0xK+tKH for ; Sun, 27 Sep 2009 00:45:59 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 296863A680C for ; Sun, 27 Sep 2009 00:45:59 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:47468 helo=[10.0.1.10]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MroTQ-0003hY-Og for p2psip@ietf.org; Sun, 27 Sep 2009 00:47:14 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 27 Sep 2009 00:47:06 -0700 Message-Id: To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] 15.1. Normative References draft-ietf-mmusic-ice-tcp-07 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 07:45:59 -0000 404 not found, should be http://tools.ietf.org/id/draft-ietf-mmusic-ice-tcp-07.txt From julian@orchidseed.org Sun Sep 27 02:57:47 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F13B3A6858 for ; Sun, 27 Sep 2009 02:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIH9v1czPJ5E for ; Sun, 27 Sep 2009 02:57:46 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 7532C3A6849 for ; Sun, 27 Sep 2009 02:57:46 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:34408 helo=[10.0.1.10]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MrqWy-00023L-Da for p2psip@ietf.org; Sun, 27 Sep 2009 02:59:01 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 27 Sep 2009 02:58:54 -0700 Message-Id: To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 09:57:47 -0000 Hi, Because every node is a STUN client/server and DTLS is required this breaks rfc5389 compliance. I assume this is an oversight in rfc5389 considering rfc4347 came first. Julian From ekr@rtfm.com Sun Sep 27 07:42:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395D83A68A5 for ; Sun, 27 Sep 2009 07:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9O31qdbAoCW for ; Sun, 27 Sep 2009 07:42:55 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 6ACD93A685F for ; Sun, 27 Sep 2009 07:42:55 -0700 (PDT) Received: by yxe30 with SMTP id 30so5178578yxe.29 for ; Sun, 27 Sep 2009 07:44:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.54.22 with SMTP id g22mr2250277agk.80.1254062647632; Sun, 27 Sep 2009 07:44:07 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Sep 2009 07:44:07 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 14:42:57 -0000 How does it break RFC 5389 compliance? -Ekr On Sun, Sep 27, 2009 at 2:58 AM, jc wrote: > Hi, > Because every node is a STUN client/server and DTLS is required this breaks > rfc5389 compliance. I assume this is an oversight in rfc5389 considering > rfc4347 came first. > > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From julian@orchidseed.org Sun Sep 27 11:40:44 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6E33A65A6 for ; Sun, 27 Sep 2009 11:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dolQxryTYwZd for ; Sun, 27 Sep 2009 11:40:43 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 93F723A680F for ; Sun, 27 Sep 2009 11:40:43 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:48161 helo=[10.0.1.10]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mryh4-0006HL-7I; Sun, 27 Sep 2009 11:41:59 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: Date: Sun, 27 Sep 2009 11:41:51 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 18:40:44 -0000 On Sep 27, 2009, at 7:44 AM, Eric Rescorla wrote: > How does it break RFC 5389 compliance? There is no section describing TLS over UDP(DTLS). "7.2.1. Sending over UDP ...................................13" "7.2.2. Sending over TCP or TLS-over-TCP ...................14" and rfc5389 clearly states: "Note that only "tcp" is defined with "stuns" at this time." and: "In addition, IANA has assigned port number 5349 for the "stuns" service, defined over TCP and UDP. The UDP port is not currently defined; however, it is reserved for future use." How is RELOAD compliant with rfc5389? Julian > > -Ekr > > > On Sun, Sep 27, 2009 at 2:58 AM, jc wrote: >> Hi, >> Because every node is a STUN client/server and DTLS is required >> this breaks >> rfc5389 compliance. I assume this is an oversight in rfc5389 >> considering >> rfc4347 came first. >> >> Julian >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> From ekr@rtfm.com Sun Sep 27 11:47:07 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADDBA3A6852 for ; Sun, 27 Sep 2009 11:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3yUZns-qFls for ; Sun, 27 Sep 2009 11:47:07 -0700 (PDT) Received: from mail-yw0-f188.google.com (mail-yw0-f188.google.com [209.85.211.188]) by core3.amsl.com (Postfix) with ESMTP id F1ABA3A684C for ; Sun, 27 Sep 2009 11:47:06 -0700 (PDT) Received: by ywh26 with SMTP id 26so2546822ywh.29 for ; Sun, 27 Sep 2009 11:48:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.217.11 with SMTP id p11mr2390018agg.82.1254077300543; Sun, 27 Sep 2009 11:48:20 -0700 (PDT) In-Reply-To: References: Date: Sun, 27 Sep 2009 11:48:20 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: text/plain; charset=ISO-8859-1 Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 18:47:07 -0000 On Sun, Sep 27, 2009 at 11:41 AM, jc wrote: > > On Sep 27, 2009, at 7:44 AM, Eric Rescorla wrote: > >> How does it break RFC 5389 compliance? > > There is no section describing TLS over UDP(DTLS). > > "7.2.1. Sending over UDP ...................................13" > "7.2.2. Sending over TCP or TLS-over-TCP ...................14" > > and rfc5389 clearly states: > > "Note that only "tcp" is defined with "stuns" at this time." > > and: > > "In addition, IANA has assigned port number 5349 for the "stuns" service, > defined over TCP and UDP. The UDP port is not currently defined; however, it > is reserved for future use." > > How is RELOAD compliant with rfc5389? STUN isn't being used over TLS (or DTLS) in RELOAD. Rather, it's being used in the context of ICE for the purposes of connectivity checks. As far as I know, there's no issue here. -Ekr From julian@orchidseed.org Sun Sep 27 12:13:55 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 672623A685B for ; Sun, 27 Sep 2009 12:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.207 X-Spam-Level: X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxeafqHQndw6 for ; Sun, 27 Sep 2009 12:13:54 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 8D36F3A679F for ; Sun, 27 Sep 2009 12:13:54 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:42031 helo=[10.0.1.10]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MrzDB-0003Yu-Br; Sun, 27 Sep 2009 12:15:10 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: Date: Sun, 27 Sep 2009 12:15:06 -0700 Content-Transfer-Encoding: 7bit Message-Id: <26676C78-A4C5-4B40-8F39-E47D15F9571D@orchidseed.org> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 19:13:55 -0000 On Sep 27, 2009, at 11:48 AM, Eric Rescorla wrote: > On Sun, Sep 27, 2009 at 11:41 AM, jc wrote: >> >> On Sep 27, 2009, at 7:44 AM, Eric Rescorla wrote: >> >>> How does it break RFC 5389 compliance? >> >> There is no section describing TLS over UDP(DTLS). >> >> "7.2.1. Sending over UDP ...................................13" >> "7.2.2. Sending over TCP or TLS-over-TCP ...................14" >> >> and rfc5389 clearly states: >> >> "Note that only "tcp" is defined with "stuns" at this time." >> >> and: >> >> "In addition, IANA has assigned port number 5349 for the "stuns" >> service, >> defined over TCP and UDP. The UDP port is not currently defined; >> however, it >> is reserved for future use." >> >> How is RELOAD compliant with rfc5389? > > STUN isn't being used over TLS (or DTLS) in RELOAD. Rather, it's being > used in the context of ICE for the purposes of connectivity checks. As > far as I know, there's no issue here. Every time you perform an Attach in RELOAD it uses either DTLS or TLS with STUN to perform ICE connectivity checks(done by TLS/DTLS hand- hake in ice-lite) towards the remote candidates. Is this fact or fiction? Julian > > -Ekr From ekr@rtfm.com Sun Sep 27 12:25:37 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E00E3A67AF for ; Sun, 27 Sep 2009 12:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrNoM4bgcMy7 for ; Sun, 27 Sep 2009 12:25:36 -0700 (PDT) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by core3.amsl.com (Postfix) with ESMTP id D05963A677C for ; Sun, 27 Sep 2009 12:25:36 -0700 (PDT) Received: by pzk4 with SMTP id 4so2072227pzk.32 for ; Sun, 27 Sep 2009 12:26:50 -0700 (PDT) Received: by 10.114.138.2 with SMTP id l2mr4242470wad.163.1254079609970; Sun, 27 Sep 2009 12:26:49 -0700 (PDT) Received: from ?10.26.166.39? ([166.205.130.252]) by mx.google.com with ESMTPS id 23sm1895449pxi.13.2009.09.27.12.26.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 27 Sep 2009 12:26:49 -0700 (PDT) References: <26676C78-A4C5-4B40-8F39-E47D15F9571D@orchidseed.org> Message-Id: From: Eric Rescorla To: jc In-Reply-To: <26676C78-A4C5-4B40-8F39-E47D15F9571D@orchidseed.org> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Date: Sun, 27 Sep 2009 12:26:40 -0700 Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 19:25:37 -0000 On Sep 27, 2009, at 12:15 PM, jc wrote: > > On Sep 27, 2009, at 11:48 AM, Eric Rescorla wrote: > >> On Sun, Sep 27, 2009 at 11:41 AM, jc wrote: >>> >>> On Sep 27, 2009, at 7:44 AM, Eric Rescorla wrote: >>> >>>> How does it break RFC 5389 compliance? >>> >>> There is no section describing TLS over UDP(DTLS). >>> >>> "7.2.1. Sending over UDP ...................................13" >>> "7.2.2. Sending over TCP or TLS-over-TCP ...................14" >>> >>> and rfc5389 clearly states: >>> >>> "Note that only "tcp" is defined with "stuns" at this time." >>> >>> and: >>> >>> "In addition, IANA has assigned port number 5349 for the "stuns" >>> service, >>> defined over TCP and UDP. The UDP port is not currently defined; >>> however, it >>> is reserved for future use." >>> >>> How is RELOAD compliant with rfc5389? >> >> STUN isn't being used over TLS (or DTLS) in RELOAD. Rather, it's >> being >> used in the context of ICE for the purposes of connectivity checks. >> As >> far as I know, there's no issue here. > > Every time you perform an Attach in RELOAD it uses either DTLS or > TLS with STUN to perform ICE connectivity checks(done by TLS/DTLS > hand-hake in ice-lite) towards the remote candidates. Is this fact > or fiction? It's fact but you're confusing two meanings of the word "with". In this case tls/dtls is multiplexed with stun over tcp/udp, therefore there is no need to define stun over dtls. The stun over tls you are pointing to is not used with ice, but rather for other stun-using applications such as turn Ekr > Julian > > > > >> >> -Ekr > From julian@orchidseed.org Sun Sep 27 13:11:51 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6FDA3A6850 for ; Sun, 27 Sep 2009 13:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTJkDirHx+49 for ; Sun, 27 Sep 2009 13:11:51 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 2AF033A6890 for ; Sun, 27 Sep 2009 13:11:51 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:42490 helo=[10.0.1.10]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Ms07F-0005tW-W3; Sun, 27 Sep 2009 13:13:07 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-1-897274589 From: jc In-Reply-To: Date: Sun, 27 Sep 2009 13:13:01 -0700 Message-Id: <15F49AFE-1C8D-4971-BF6F-4DCC3D40D3B2@orchidseed.org> References: <26676C78-A4C5-4B40-8F39-E47D15F9571D@orchidseed.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 20:11:52 -0000 --Apple-Mail-1-897274589 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 27, 2009, at 12:26 PM, Eric Rescorla wrote: >> >> Every time you perform an Attach in RELOAD it uses either DTLS or >> TLS with STUN to perform ICE connectivity checks(done by TLS/DTLS >> hand-hake in ice-lite) towards the remote candidates. Is this fact >> or fiction? > > It's fact but you're confusing two meanings of the word "with". In > this case tls/dtls is multiplexed with stun over tcp/udp, therefore > there is no need to define stun over dtls. The stun over tls you are > pointing to is not used with ice, but rather for other stun-using > applications such as turn > I've built out my transports so that the lowest layer is UDP/TCP the next is DTLS/TLS and the next demultiplexes STUN, RELOAD and APP. In other words DTLS and TLS are completely transparent to the ICE transport. I don't demultiplex any TLS or DTLS packets because when the SSL state is acquired everything else can only be upper layer messages. What you've stated indicates to me that you may receive a STUN message on the UDP/TCP layer because you've mentioned having to "multiplex tls/dtls" with stun over tcp/udp". Does my implementation sound correct to you? > Ekr > >> Julian >> >> >> >> >>> >>> -Ekr >> --Apple-Mail-1-897274589 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Every = time you perform an Attach in RELOAD it uses either DTLS or TLS =  with STUN to perform ICE connectivity checks(done by TLS/DTLS = hand-hake in ice-lite) towards the remote candidates. Is this fact or = fiction?

It's fact but you're confusing two meanings = of the word "with". In this case tls/dtls is multiplexed with stun over = tcp/udp, therefore there is no need to define stun over dtls. The stun = over tls you are pointing to is not used with ice, but rather for other = stun-using applications such as = turn


I've built out my = transports so that the lowest layer is UDP/TCP the next is DTLS/TLS and = the next demultiplexes STUN, RELOAD and APP. In other words DTLS and TLS = are completely transparent to the ICE transport. I don't demultiplex any = TLS or DTLS packets because when the SSL state is acquired everything = else can only be upper layer messages. What you've stated indicates to = me that you may receive a STUN message on the UDP/TCP layer because = you've mentioned having to "multiplex tls/dtls" with stun over tcp/udp". = Does my implementation sound correct to you?

Ekr

Julian





-Ekr


= --Apple-Mail-1-897274589-- From julian@orchidseed.org Sun Sep 27 13:17:25 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2493A6911 for ; Sun, 27 Sep 2009 13:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z16KkIHURyo1 for ; Sun, 27 Sep 2009 13:17:24 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 6FCD03A68F1 for ; Sun, 27 Sep 2009 13:17:24 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:40177 helo=[10.0.1.10]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Ms0Cd-0006MB-AE for p2psip@ietf.org; Sun, 27 Sep 2009 13:18:40 -0700 From: jc Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 27 Sep 2009 13:18:38 -0700 Message-Id: To: p2psip WG Mime-Version: 1.0 (Apple Message framework v1076) X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Subject: [P2PSIP] Reference implementation - Interoperability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 20:17:25 -0000 Hi, I will be releasing a cross platform c++ based reference implementation of the "complete" draft Q1 of 2010. Is there anybody here that "may" have a reference implementation available to run interoperability tests against Q1 of 2010? Cheers, Julian From ekr@rtfm.com Sun Sep 27 14:08:49 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 389613A6922 for ; Sun, 27 Sep 2009 14:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k7npnHAJovWE for ; Sun, 27 Sep 2009 14:08:48 -0700 (PDT) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 2A7143A6816 for ; Sun, 27 Sep 2009 14:08:48 -0700 (PDT) Received: by yxe30 with SMTP id 30so5430593yxe.29 for ; Sun, 27 Sep 2009 14:10:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.21.25 with SMTP id y25mr2457736agi.66.1254085802139; Sun, 27 Sep 2009 14:10:02 -0700 (PDT) In-Reply-To: <15F49AFE-1C8D-4971-BF6F-4DCC3D40D3B2@orchidseed.org> References: <26676C78-A4C5-4B40-8F39-E47D15F9571D@orchidseed.org> <15F49AFE-1C8D-4971-BF6F-4DCC3D40D3B2@orchidseed.org> Date: Sun, 27 Sep 2009 14:10:02 -0700 Message-ID: From: Eric Rescorla To: jc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 21:08:49 -0000 On Sun, Sep 27, 2009 at 1:13 PM, jc wrote: > > On Sep 27, 2009, at 12:26 PM, Eric Rescorla wrote: > > Every time you perform an Attach in RELOAD it uses either DTLS or TLS =A0= with > STUN to perform ICE connectivity checks(done by TLS/DTLS hand-hake in > ice-lite) towards the remote candidates. Is this fact or fiction? > > It's fact but you're confusing two meanings of the word "with". In this c= ase > tls/dtls is multiplexed with stun over tcp/udp, therefore there is no nee= d > to define stun over dtls. The stun over tls you are pointing to is not us= ed > with ice, but rather for other stun-using applications such as turn > > > I've built out my transports so that the lowest layer is UDP/TCP the next= is > DTLS/TLS and the next demultiplexes STUN, RELOAD and APP. In other words > DTLS and TLS are completely transparent to the ICE transport. I don't > demultiplex any TLS or DTLS packets because when the SSL state is acquire= d > everything else can only be upper layer messages. What you've stated > indicates to me that you may receive a STUN message on the UDP/TCP layer > because you've mentioned having to "multiplex tls/dtls" with stun over > tcp/udp". Does my implementation sound correct to you? No, this doesn't sound right. The idea here is that ICE provides a fast connectivity check and then you only establish TLS/DTLS connections over the single channel that ICE successfully establishes. If you do things the other way (TLS first, then ICE), then you end up trying to establish a zillion independent (D)TLS connections (which would be really slow even if it worked, which it won't) and then running ICE, which is pointless since you can't establish a (D)TLS connection unless you have two-way connectivity. -Ekr From julian@orchidseed.org Sun Sep 27 14:24:57 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369243A688B for ; Sun, 27 Sep 2009 14:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQrx3eIpORqP for ; Sun, 27 Sep 2009 14:24:56 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id 578423A6838 for ; Sun, 27 Sep 2009 14:24:56 -0700 (PDT) Received: from ip68-5-30-57.oc.oc.cox.net ([68.5.30.57]:39249 helo=[10.0.1.10]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Ms1Fz-00020i-B2; Sun, 27 Sep 2009 14:26:12 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: multipart/alternative; boundary=Apple-Mail-3-901657016 From: jc In-Reply-To: Date: Sun, 27 Sep 2009 14:26:03 -0700 Message-Id: <667D5BF9-C965-4B24-9AD4-0BAE938C9A5F@orchidseed.org> References: <26676C78-A4C5-4B40-8F39-E47D15F9571D@orchidseed.org> <15F49AFE-1C8D-4971-BF6F-4DCC3D40D3B2@orchidseed.org> To: Eric Rescorla X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] rfc5389 + DTLS (implementor detail resolved) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2009 21:24:57 -0000 --Apple-Mail-3-901657016 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes On Sep 27, 2009, at 2:10 PM, Eric Rescorla wrote: > > No, this doesn't sound right. > > The idea here is that ICE provides a fast connectivity check and then > you only establish TLS/DTLS connections over the single channel > that ICE successfully establishes. If you do things the other way > (TLS first, then ICE), then you end up trying to establish a zillion > independent (D)TLS connections (which would be really slow even > if it worked, which it won't) and then running ICE, which is pointless > since you can't establish a (D)TLS connection unless you have two-way > connectivity. This is literarily a few lines of code I have to change to run non- encrypted ICE. This isn't very clear in the draft because the MUST's pertaining to DTLS and TLS seem to overlap the ICE implementation. This resolves the topic since rfc5389 and DTLS aren't used in conjunction in the draft. Thanks for the clarification on that, Julian > > -Ekr --Apple-Mail-3-901657016 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

No, this doesn't = sound right.

The idea here is that ICE provides a fast = connectivity check and then
you only establish TLS/DTLS connections = over the single channel
that ICE successfully establishes. If you do = things the other way
(TLS first, then ICE), then you end up trying to = establish a zillion
independent (D)TLS connections (which would be = really slow even
if it worked, which it won't) and then running ICE, = which is pointless
since you can't establish a (D)TLS connection = unless you have = two-way
connectivity.

This = is literarily a few lines of code I have to change to run non-encrypted = ICE. This isn't very clear in the draft because the MUST's pertaining to = DTLS and TLS seem to overlap the ICE implementation. This resolves the = topic since rfc5389 and DTLS aren't used in conjunction in the = draft.

Thanks for the clarification on = that,
Julian


-Ekr

= --Apple-Mail-3-901657016-- From dyork@voxeo.com Mon Sep 28 14:30:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295F53A63EC for ; Mon, 28 Sep 2009 14:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMyRKT1YfE66 for ; Mon, 28 Sep 2009 14:30:29 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with ESMTP id C38243A69E4 for ; Mon, 28 Sep 2009 14:30:28 -0700 (PDT) Received: from [66.65.229.48] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 51410967 for p2psip@ietf.org; Mon, 28 Sep 2009 21:31:40 +0000 Message-Id: <0838EA1B-5800-41AB-8EC8-5CEFA65D21D7@voxeo.com> From: Dan York To: "p2psip@ietf.org WG" Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 28 Sep 2009 17:31:38 -0400 X-Mailer: Apple Mail (2.936) Subject: [P2PSIP] New "-00" of P2PSIP Security Overview submitted - RFC 2119 ref removed X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 21:30:30 -0000 P2PSIP working group members, At IETF 75, we were given the direction to remove the RFC 2119 language from the document and move it from being a normative doc to a purely informational doc. I have now started this and made a number of other changes, including most notably the name change from "p2psip- security-requirements" to "p2psip-security-overview": http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt Chairs, per the discussion that apparently happened at IETF75, we would like to ask for this to be considered as a working group document. Please note... I made a mistake in the submission process and also submitted this as: http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt They are IDENTICAL except for the name change. Thank you for your consideration, Dan -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo From michaelc@idssoftware.com Wed Sep 30 09:19:11 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DCDB3A68D8 for ; Wed, 30 Sep 2009 09:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5YIb2snvnkO for ; Wed, 30 Sep 2009 09:19:10 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 8E3593A67BE for ; Wed, 30 Sep 2009 09:19:10 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mt1ur-0005th-Bh; Wed, 30 Sep 2009 12:20:33 -0400 Message-ID: <4AC386A2.20502@idssoftware.com> Date: Wed, 30 Sep 2009 09:26:10 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94058e5fee3c1e394757358feb3a23f6160350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: p2psip WG Subject: Re: [P2PSIP] Reference implementation - Interoperability X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 16:19:11 -0000 Julian, We should be able to join the interop tests Q1 of 2010. Thanks --Michael jc wrote: > Hi, > I will be releasing a cross platform c++ based reference > implementation of the "complete" draft Q1 of 2010. Is there anybody > here that "may" have a reference implementation available to run > interoperability tests against Q1 of 2010? > > Cheers, > Julian > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > > From davidbryan@gmail.com Wed Sep 30 09:24:36 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB4C3A685F for ; Wed, 30 Sep 2009 09:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.708 X-Spam-Level: X-Spam-Status: No, score=-1.708 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP5lxjcJWnFS for ; Wed, 30 Sep 2009 09:24:35 -0700 (PDT) Received: from mail-yw0-f202.google.com (mail-yw0-f202.google.com [209.85.211.202]) by core3.amsl.com (Postfix) with ESMTP id BB2DF3A681B for ; Wed, 30 Sep 2009 09:24:35 -0700 (PDT) Received: by ywh40 with SMTP id 40so6575185ywh.32 for ; Wed, 30 Sep 2009 09:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=xSCfSkAk21lCsdxcO8rR2kxUbrdnZcL79ZVFOQvcUqg=; b=L8BFMlcHoZQJFYs4GOv5zyGhy75dvf0KipZ1OSGlUzM/563pSUObfeJSe1SVMB/u72 +ZZYvf06Aq8ULbiuzvv45JzaorBtoWPjheEm3brm5j/36453a9AjpOQQteNiyNHk5VqT wzIFBU0NmTVmi3D02Iz77y5kppMuRnJV81p40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=Af46oZM+YPbs4OR2VX4RYzdJUsqzffITiwug7QHGRPlSPWRsktxQZZCFq6VzUiPPhz TC199bvbYmQeOHnVvkNE7QZ7uOwiIY1gRkTgzuoJGewtLhJTbev2y61K9BtJ4QZw4Srl XadKttWNEm0CVfbqR7ZE5uKS80nkHJQcfd2bU= MIME-Version: 1.0 Sender: davidbryan@gmail.com Received: by 10.150.237.10 with SMTP id k10mr255909ybh.112.1254327956468; Wed, 30 Sep 2009 09:25:56 -0700 (PDT) Date: Wed, 30 Sep 2009 12:25:56 -0400 X-Google-Sender-Auth: 75299fc611e9ca31 Message-ID: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> From: "David A. Bryan" To: P2PSIP WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 16:24:36 -0000 As Dan mentions below, there was a call in Stockholm to (pending the changes requested) adopt this work as a WG item: http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt As the authors feel they have made the requested changes, I'd like to ask folks on list to confirm this consensus. Please send comments about adoption to the list, and we'll make a call after there has been time to review and comment (at least a week). Thanks, David (as chair) On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: > P2PSIP working group members, > > At IETF 75, we were given the direction to remove the RFC 2119 language from > the document and move it from being a normative doc to a purely > informational doc. I have now started this and made a number of other > changes, including most notably the name change from > "p2psip-security-requirements" to "p2psip-security-overview": > > http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt > > Chairs, per the discussion that apparently happened at IETF75, we would like > to ask for this to be considered as a working group document. > > Please note... I made a mistake in the submission process and also submitted > this as: > > http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt > > They are IDENTICAL except for the name change. > > Thank you for your consideration, > Dan > > -- > Dan York, Director of Conversations > Voxeo Corporation http://www.voxeo.com dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork > > Join the Voxeo conversation: > Blogs: http://blogs.voxeo.com > Twitter: http://twitter.com/voxeo http://twitter.com/danyork > Facebook: http://www.facebook.com/voxeo > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip > From michaelc@idssoftware.com Wed Sep 30 10:43:30 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 798EF3A6864 for ; Wed, 30 Sep 2009 10:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.784 X-Spam-Level: X-Spam-Status: No, score=-0.784 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4u0h5mutjYA for ; Wed, 30 Sep 2009 10:43:28 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id AFE5A3A68C7 for ; Wed, 30 Sep 2009 10:43:28 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Mt3ER-00033N-QE; Wed, 30 Sep 2009 13:44:51 -0400 Message-ID: <4AC39A64.7030601@idssoftware.com> Date: Wed, 30 Sep 2009 10:50:28 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: jc References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABC4897.2090501@idssoftware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9403cb89c0f66ee05725fab68c9be50f452350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 17:43:30 -0000 Julian, I have no scientific data, just a personal concern. Consider a Reload STORE request with your 691 byte cert, the total fat (non-payload) on the wire for a UDP/DTLS transport is: DTLS header (13 bytes) Reload header Forward header (38 bytes) Destination list (18 bytes, single hop) Reload Message STORE (SIP_REGISTRATION) AOR RSA Signature (256 bytes) Reload Security Block Certificates (691 bytes) Signer ID (20+ bytes) RSA Signature (256 bytes) DTSL MAC and padding (20+ bytes) These are rough numbers, and it total 1292 bytes excluding the AOR. It is very close to the 1500 byte network packet size (MTU). --Michael jc wrote: > > On Sep 24, 2009, at 9:35 PM, Michael Chen wrote: > >> I also want to point out that even with the most simple encoding (JDK >> keytool), a 1024 bit RSA public key certificate takes up 619 bytes. A >> production strength 2048 bit RSA cert is 880 bytes. If a peer can >> only be reached via UDP, the overhead of DTLS + Reload Signature on >> message leaves very little room for the relevant data fragment (e.g. >> 1500 packet size), which means UDP transport may be very inefficient. >> Transport overhead should be a separate discussion thread. > > In my RELOAD implementation a 2048 bit RSA public key is 691 bytes > long, see output below. Do you have statistics that show the current > fragmentation algorithm to be sub-optimal? > Julian > > * > * > *Running 1 test case...* > *......................+++* > *........................+++* > *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating > RSA key.* > *..............................+++* > *..............+++* > *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded generating > RSA key.* > *debug: X509_NAME* junglecat::x509::allocate_common_name(const char*): > Allocated* > *debug: X509_NAME* junglecat::x509::allocate_common_name(const char*): > Allocated* > *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, const > char*, const char*, unsigned int, const EVP_MD*): Success* > *Certificate:* > * Data:* > * Version: 3 (0x2)* > * Serial Number: 1253857645 (0x4abc596d)* > * Signature Algorithm: sha1WithRSAEncryption* > * Issuer: CN=common_name_issuer* > * Validity* > * Not Before: Sep 25 05:47:25 2009 GMT* > * Not After : Sep 25 06:47:25 2009 GMT* > * Subject: CN=common_name* > * Subject Public Key Info:* > * Public Key Algorithm: rsaEncryption* > * RSA Public Key: (2048 bit)* > * Modulus (2048 bit):* > * 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02:* > * 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0:* > * aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14:* > * aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4:* > * da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f:* > * d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7:* > * e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44:* > * 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e:* > * 46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f:* > * a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94:* > * 66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd:* > * 01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7:* > * 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef:* > * b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca:* > * d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b:* > * cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d:* > * 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa:* > * 0a:d3* > * Exponent: 65537 (0x10001)* > * Signature Algorithm: sha1WithRSAEncryption* > * 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:* > * dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:* > * 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:* > * 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:* > * af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:* > * f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:* > * b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:* > * 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:* > * ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:* > * cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:* > * 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:* > * 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:* > * 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:* > * d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:* > * 8d:2a:7b:21* > > *X509 structure size: 92* > *RSA structure size: 88* > len:691 > > **** No errors detected* > * > * From julian@orchidseed.org Wed Sep 30 11:08:22 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75CE83A681B for ; Wed, 30 Sep 2009 11:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gn-kkW6jBz6a for ; Wed, 30 Sep 2009 11:08:21 -0700 (PDT) Received: from n12.c05.mtsvc.net (n12.c05.mtsvc.net [70.32.68.12]) by core3.amsl.com (Postfix) with ESMTP id 648C63A6963 for ; Wed, 30 Sep 2009 11:08:21 -0700 (PDT) Received: from [166.205.6.186] (port=49951 helo=[10.100.35.164]) by n12.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1Mt3cT-0002UL-QU; Wed, 30 Sep 2009 11:09:44 -0700 References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABC4897.2090501@idssoftware.com> <4AC39A64.7030601@idssoftware.com> Message-Id: <8B60D024-9EA3-46BD-AD20-2B76656FB8DB@orchidseed.org> From: jc To: Michael Chen In-Reply-To: <4AC39A64.7030601@idssoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7C144) Mime-Version: 1.0 (iPhone Mail 7C144) Date: Wed, 30 Sep 2009 11:09:33 -0700 X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 18:08:22 -0000 This is greater than the MTU of an xbox 360 but less than your averge router at 1492. Doesn't DTLS in OpenSSL already have the real path MTU after the handshake? If not I know it can do this for you. You can use that MTU and fragment your packets. Julian Sent from my iPhone On Sep 30, 2009, at 10:50 AM, Michael Chen wrote: > Julian, > > I have no scientific data, just a personal concern. Consider a > Reload STORE request with your 691 byte cert, the total fat (non- > payload) on the wire for a UDP/DTLS transport is: > > DTLS header (13 bytes) > Reload header > Forward header (38 bytes) > Destination list (18 bytes, single hop) > Reload Message > STORE (SIP_REGISTRATION) > AOR > RSA Signature (256 bytes) > Reload Security Block > Certificates (691 bytes) > Signer ID (20+ bytes) > RSA Signature (256 bytes) > DTSL MAC and padding (20+ bytes) > > These are rough numbers, and it total 1292 bytes excluding the AOR. > It is very close to the 1500 byte network packet size (MTU). > > --Michael > > jc wrote: >> >> On Sep 24, 2009, at 9:35 PM, Michael Chen wrote: >> >>> I also want to point out that even with the most simple encoding >>> (JDK keytool), a 1024 bit RSA public key certificate takes up 619 >>> bytes. A production strength 2048 bit RSA cert is 880 bytes. If a >>> peer can only be reached via UDP, the overhead of DTLS + Reload >>> Signature on message leaves very little room for the relevant data >>> fragment (e.g. 1500 packet size), which means UDP transport may be >>> very inefficient. Transport overhead should be a separate >>> discussion thread. >> >> In my RELOAD implementation a 2048 bit RSA public key is 691 bytes >> long, see output below. Do you have statistics that show the >> current fragmentation algorithm to be sub-optimal? >> Julian >> >> * >> * >> *Running 1 test case...* >> *......................+++* >> *........................+++* >> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >> generating RSA key.* >> *..............................+++* >> *..............+++* >> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >> generating RSA key.* >> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >> char*): Allocated* >> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >> char*): Allocated* >> *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, >> const char*, const char*, unsigned int, const EVP_MD*): Success* >> *Certificate:* >> * Data:* >> * Version: 3 (0x2)* >> * Serial Number: 1253857645 (0x4abc596d)* >> * Signature Algorithm: sha1WithRSAEncryption* >> * Issuer: CN=common_name_issuer* >> * Validity* >> * Not Before: Sep 25 05:47:25 2009 GMT* >> * Not After : Sep 25 06:47:25 2009 GMT* >> * Subject: CN=common_name* >> * Subject Public Key Info:* >> * Public Key Algorithm: rsaEncryption* >> * RSA Public Key: (2048 bit)* >> * Modulus (2048 bit):* >> * 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02:* >> * 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0:* >> * aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14:* >> * aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4:* >> * da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f:* >> * d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7:* >> * e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44:* >> * 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e:* >> * 46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f:* >> * a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94:* >> * 66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd:* >> * 01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7:* >> * 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef:* >> * b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca:* >> * d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b:* >> * cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d:* >> * 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa:* >> * 0a:d3* >> * Exponent: 65537 (0x10001)* >> * Signature Algorithm: sha1WithRSAEncryption* >> * 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:* >> * dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:* >> * 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:* >> * 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:* >> * af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:* >> * f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:* >> * b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:* >> * 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:* >> * ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:* >> * cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:* >> * 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:* >> * 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:* >> * 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:* >> * d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:* >> * 8d:2a:7b:21* >> >> *X509 structure size: 92* >> *RSA structure size: 88* >> len:691 >> >> **** No errors detected* >> * >> * From enrico.marocco@telecomitalia.it Wed Sep 30 14:33:26 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C383A6359 for ; Wed, 30 Sep 2009 14:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.375 X-Spam-Level: X-Spam-Status: No, score=-0.375 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgmRt1a9lqMF for ; Wed, 30 Sep 2009 14:33:25 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 33CB23A6861 for ; Wed, 30 Sep 2009 14:33:25 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.358.0; Wed, 30 Sep 2009 23:34:46 +0200 Received: from [172.16.82.18] (163.162.180.246) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Wed, 30 Sep 2009 23:34:45 +0200 Message-ID: <4AC3CEF4.3000508@telecomitalia.it> Date: Wed, 30 Sep 2009 23:34:44 +0200 From: Enrico Marocco User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "David A. Bryan" References: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> In-Reply-To: <8b2769930909300925g3f61be3r1ff9a8eb4a51a087@mail.gmail.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090408050508040604020701" Cc: P2PSIP WG Subject: Re: [P2PSIP] Consensus call on security draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 21:33:26 -0000 --------------ms090408050508040604020701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The P2P Research Group is publishing a survey on security issues in p2p overlays for realtime communications that I think this draft should in some ways take into consideration, e.g. discussing how the various attacks and possible solutions apply to the very specific P2PSIP case. The survey is draft-irtf-p2prg-rtc-security; IIRC it has passed IRSG review and is now headed to the IESG. Sorry for not pointing this out earlier -- while this was discussed in Stockholm I was probably in a jet lag coma on those fantastic Swedish chairs ;-) Anyways, I support its adoption as WG item. Enrico David A. Bryan wrote: > As Dan mentions below, there was a call in Stockholm to (pending the > changes requested) adopt this work as a WG item: > > http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt > > As the authors feel they have made the requested changes, I'd like to > ask folks on list to confirm this consensus. Please send comments > about adoption to the list, and we'll make a call after there has been > time to review and comment (at least a week). > > Thanks, > > David (as chair) > > On Mon, Sep 28, 2009 at 5:31 PM, Dan York wrote: >> P2PSIP working group members, >> >> At IETF 75, we were given the direction to remove the RFC 2119 language from >> the document and move it from being a normative doc to a purely >> informational doc. I have now started this and made a number of other >> changes, including most notably the name change from >> "p2psip-security-requirements" to "p2psip-security-overview": >> >> http://www.ietf.org/id/draft-matuszewski-p2psip-security-overview-00.txt >> >> Chairs, per the discussion that apparently happened at IETF75, we would like >> to ask for this to be considered as a working group document. >> >> Please note... I made a mistake in the submission process and also submitted >> this as: >> >> http://www.ietf.org/id/draft-matuszewski-p2psip-security-requirements-06.txt >> >> They are IDENTICAL except for the name change. >> >> Thank you for your consideration, >> Dan >> >> -- >> Dan York, Director of Conversations >> Voxeo Corporation http://www.voxeo.com dyork@voxeo.com >> Phone: +1-407-455-5859 Skype: danyork >> >> Join the Voxeo conversation: >> Blogs: http://blogs.voxeo.com >> Twitter: http://twitter.com/voxeo http://twitter.com/danyork >> Facebook: http://www.facebook.com/voxeo >> >> >> >> >> >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip --------------ms090408050508040604020701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJOzCC AvgwggJhoAMCAQICEBtZixsKeF4i2Os0viEP+ncwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMyOTE2Mjg1OVoX DTEwMDMyOTE2Mjg1OVowUTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBALhn5sIqd2hv7B6UBs4823vUHLamD/+tFSXZKQ4Yw5oQ 5hOdPUoJazGMDOyB9tWcqXdJxt0WqHxdgeCeAS0zV85Uf6cQcvkSe//umVkZvPuAYTKWRBJw 8rLfVuYhk9t2KraXyVfWIdoceZP0/v4eIoLyPw2/wQS3AvxujvkyL2N94S7IOmPCP6WXZmmW zNRzabSLLl50UA2jKbcYcWpKfQUFma9B1S3hAZTDiQTvXIJVmRdwYmnuwId9QTsm+7RB7oiy EC7+zeOORQk1Y6NjKinZmLb/C0tq40NIIPpBqNaZ+V6UmQ0jtYIlBQrlG6OpSPgjAS9IWsMg 7mbratVpsNkCAwEAAaM8MDowKgYDVR0RBCMwIYEfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0 YWxpYS5pdDAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADfh68XGwHIccDd0a+Fw D7LEP2QxLEqgP/gR73fsvT6y1COD7vGZY4BkYvryiU5sPkW4ulizN1ASSMJJIVMkQdzzKS+H e4dR5CpiPqz8b1LJdae8G7CUsBZ9KHYN4n6pGpdcq9YsGtfELp1W25MMppJcpKniscResCQF BWmw3EsAMIIC+DCCAmGgAwIBAgIQG1mLGwp4XiLY6zS+IQ/6dzANBgkqhkiG9w0BAQUFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDkwMzI5 MTYyODU5WhcNMTAwMzI5MTYyODU5WjBRMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMS4wLAYJKoZIhvcNAQkBFh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuGfmwip3aG/sHpQGzjzbe9QctqYP/60V JdkpDhjDmhDmE509SglrMYwM7IH21Zypd0nG3RaofF2B4J4BLTNXzlR/pxBy+RJ7/+6ZWRm8 +4BhMpZEEnDyst9W5iGT23YqtpfJV9Yh2hx5k/T+/h4igvI/Db/BBLcC/G6O+TIvY33hLsg6 Y8I/pZdmaZbM1HNptIsuXnRQDaMptxhxakp9BQWZr0HVLeEBlMOJBO9cglWZF3Biae7Ah31B Oyb7tEHuiLIQLv7N445FCTVjo2MqKdmYtv8LS2rjQ0gg+kGo1pn5XpSZDSO1giUFCuUbo6lI +CMBL0hawyDuZutq1Wmw2QIDAQABozwwOjAqBgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAN+HrxcbA chxwN3Rr4XAPssQ/ZDEsSqA/+BHvd+y9PrLUI4Pu8ZljgGRi+vKJTmw+Rbi6WLM3UBJIwkkh UyRB3PMpL4d7h1HkKmI+rPxvUsl1p7wbsJSwFn0odg3ifqkal1yr1iwa18QunVbbkwymklyk qeKxxF6wJAUFabDcSwAwggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYD VQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAY BgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZp Y2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzAp BgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMwNzE3MDAw MDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENv bnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftOucqZWh5o wHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Vaqj9xVsuv PAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e20TxhBEAe ZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDigNqA0 hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4 MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6ot nzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V 2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20CAQEwdjBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBtZixsKeF4i 2Os0viEP+ncwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDkwOTMwMjEzNDQ0WjAjBgkqhkiG9w0BCQQxFgQU8oA+oyz+OWmBitN4 j7NA8juXeTMwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGF BgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6dzCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQG1mLGwp4XiLY6zS+IQ/6 dzANBgkqhkiG9w0BAQEFAASCAQANhXrSFaaYPmEijRAbJpvYd0hGnIhlcx5Qv1PB5STXVle7 xIJpy3Px686Ay2/N//NvorUU0kjo2ZWAITWQ20QgOh5Zv/25Qzb2azAQzUj8CrLty7J2ATg2 hwPKfqA7SHGrJ4TILz2FqDvGOz9VwP9mO91ZHXaDzLH0lOeJlkEZN+RTa3DjsVsc7Dt311GE UUa9kMn1mZP8FC/9MjdlQwBTjSyvYTxK802KJx4UbA9HWzQoJhrsXhbzByMl2h/GbNggK42g 09S4DacUoNbBFzXkJp/ZIf6YYeMuJHD8WxZ4JW28gMAARY5jT9DUSeA6k3HbdSKt3LJyycDa tjzTSvjoAAAAAAAA --------------ms090408050508040604020701-- From michaelc@idssoftware.com Wed Sep 30 19:18:15 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8C93A68D2 for ; Wed, 30 Sep 2009 19:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4F1zri5Nalz for ; Wed, 30 Sep 2009 19:18:14 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 11E193A6A01 for ; Wed, 30 Sep 2009 19:18:13 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MtBGb-0002NH-UE for p2psip@ietf.org; Wed, 30 Sep 2009 22:19:38 -0400 Message-ID: <4AC4130B.3000605@idssoftware.com> Date: Wed, 30 Sep 2009 19:25:15 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 CC: p2psip WG References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABC4897.2090501@idssoftware.com> <4AC39A64.7030601@idssoftware.com> <8B60D024-9EA3-46BD-AD20-2B76656FB8DB@orchidseed.org> In-Reply-To: <8B60D024-9EA3-46BD-AD20-2B76656FB8DB@orchidseed.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da9404b77d87e676d1a7afb90e5e490714f27350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 02:18:15 -0000 Julian, My point is that what's left for Reload payload is 1492-1292 = 200 bytes. Many Reload messages will have to be fragmented. --Michael jc wrote: > This is greater than the MTU of an xbox 360 but less than your averge > router at 1492. Doesn't DTLS in OpenSSL already have the real path MTU > after the handshake? If not I know it can do this for you. You can use > that MTU and fragment your packets. > > Julian > > Sent from my iPhone > > On Sep 30, 2009, at 10:50 AM, Michael Chen > wrote: > >> Julian, >> >> I have no scientific data, just a personal concern. Consider a Reload >> STORE request with your 691 byte cert, the total fat (non-payload) on >> the wire for a UDP/DTLS transport is: >> >> DTLS header (13 bytes) >> Reload header >> Forward header (38 bytes) >> Destination list (18 bytes, single hop) >> Reload Message >> STORE (SIP_REGISTRATION) >> AOR >> RSA Signature (256 bytes) >> Reload Security Block >> Certificates (691 bytes) >> Signer ID (20+ bytes) >> RSA Signature (256 bytes) >> DTSL MAC and padding (20+ bytes) >> >> These are rough numbers, and it total 1292 bytes excluding the AOR. >> It is very close to the 1500 byte network packet size (MTU). >> >> --Michael >> >> jc wrote: >>> >>> On Sep 24, 2009, at 9:35 PM, Michael Chen wrote: >>> >>>> I also want to point out that even with the most simple encoding >>>> (JDK keytool), a 1024 bit RSA public key certificate takes up 619 >>>> bytes. A production strength 2048 bit RSA cert is 880 bytes. If a >>>> peer can only be reached via UDP, the overhead of DTLS + Reload >>>> Signature on message leaves very little room for the relevant data >>>> fragment (e.g. 1500 packet size), which means UDP transport may be >>>> very inefficient. Transport overhead should be a separate >>>> discussion thread. >>> >>> In my RELOAD implementation a 2048 bit RSA public key is 691 bytes >>> long, see output below. Do you have statistics that show the current >>> fragmentation algorithm to be sub-optimal? >>> Julian >>> >>> * >>> * >>> *Running 1 test case...* >>> *......................+++* >>> *........................+++* >>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >>> generating RSA key.* >>> *..............................+++* >>> *..............+++* >>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >>> generating RSA key.* >>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >>> char*): Allocated* >>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >>> char*): Allocated* >>> *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, >>> const char*, const char*, unsigned int, const EVP_MD*): Success* >>> *Certificate:* >>> * Data:* >>> * Version: 3 (0x2)* >>> * Serial Number: 1253857645 (0x4abc596d)* >>> * Signature Algorithm: sha1WithRSAEncryption* >>> * Issuer: CN=common_name_issuer* >>> * Validity* >>> * Not Before: Sep 25 05:47:25 2009 GMT* >>> * Not After : Sep 25 06:47:25 2009 GMT* >>> * Subject: CN=common_name* >>> * Subject Public Key Info:* >>> * Public Key Algorithm: rsaEncryption* >>> * RSA Public Key: (2048 bit)* >>> * Modulus (2048 bit):* >>> * 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02:* >>> * 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0:* >>> * aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14:* >>> * aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4:* >>> * da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f:* >>> * d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7:* >>> * e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44:* >>> * 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e:* >>> * 46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f:* >>> * a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94:* >>> * 66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd:* >>> * 01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7:* >>> * 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef:* >>> * b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca:* >>> * d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b:* >>> * cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d:* >>> * 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa:* >>> * 0a:d3* >>> * Exponent: 65537 (0x10001)* >>> * Signature Algorithm: sha1WithRSAEncryption* >>> * 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:* >>> * dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:* >>> * 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:* >>> * 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:* >>> * af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:* >>> * f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:* >>> * b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:* >>> * 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:* >>> * ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:* >>> * cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:* >>> * 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:* >>> * 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:* >>> * 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:* >>> * d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:* >>> * 8d:2a:7b:21* >>> >>> *X509 structure size: 92* >>> *RSA structure size: 88* >>> len:691 >>> >>> **** No errors detected* >>> * >>> * > > From michaelc@idssoftware.com Wed Sep 30 20:03:18 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DBA3A6802 for ; Wed, 30 Sep 2009 20:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcw1QfF3WZ+D for ; Wed, 30 Sep 2009 20:03:18 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 00A5D3A67F4 for ; Wed, 30 Sep 2009 20:03:17 -0700 (PDT) Received: from [67.58.151.223] (helo=[10.9.0.1]) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MtByE-0002MA-01 for p2psip@ietf.org; Wed, 30 Sep 2009 23:04:42 -0400 Message-ID: <4AC41D9B.1040504@idssoftware.com> Date: Wed, 30 Sep 2009 20:10:19 -0700 From: Michael Chen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94013999e8f9d536f58335fa4873fee5000350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.58.151.223 Subject: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 03:03:18 -0000 Hi, In an earlier thread, David A. Bryan asked about implementation experience of this draft. Two things pop out immediately from my head (they both feel like reinventing the wheel): 1. Digital signature related requirements seem rehashing what's being done in TLS and DTLS. 2. Fragmentation handling seems to be reinventing TCP using UDP. The second one may be unfounded, but I like to toss around an idea while implementing the first. What if this draft mandates the following regarding TLS and DTLS connections: A. Client authentication is required for all TLS and DTLS connections; B. Both parties (peers) in a D/TLS connection uses the same digital credentials (certificates and public/private keys) for the DHT overlay. For example, say peer X connects to peer Y via TLS. X will get Y's overlay certificates and public key during the first part of the TLS handshake. Then Y request X (the 'client') to send its certificates and public key during client authentication. The TLS session will be honored if and only if the overlay information in the certificates are validated on both sides. This is fully supported by TLS and DTLS (plus a few callbacks). The level of trust established this way is equivalent to that provided by the current draft-03. The intend is that with these mandates, the RELOAD protocol itself can be simplified by removing all certificate and signature related requirements. For example, in my earlier post, an overhead of 1292 bytes can be trimmed down to only 69 bytes!!! (removing the security block and the STORE signature). I still need to think about messages forwarded by instead of originated from a peer, but let the discussion begin. Thanks --Michael From julian@orchidseed.org Wed Sep 30 20:07:23 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F12B53A6892 for ; Wed, 30 Sep 2009 20:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDiSKry7TviF for ; Wed, 30 Sep 2009 20:07:23 -0700 (PDT) Received: from n19.c05.mtsvc.net (n19.c05.mtsvc.net [70.32.68.19]) by core3.amsl.com (Postfix) with ESMTP id DA8DB3A67E5 for ; Wed, 30 Sep 2009 20:07:22 -0700 (PDT) Received: from [174.46.231.3] (port=60006 helo=[10.1.3.115]) by n19.c05.mtsvc.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.63) (envelope-from ) id 1MtC29-0004w3-Cc; Wed, 30 Sep 2009 20:08:47 -0700 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: jc In-Reply-To: <4AC4130B.3000605@idssoftware.com> Date: Wed, 30 Sep 2009 21:08:43 -0600 Content-Transfer-Encoding: 7bit Message-Id: <11FF298A-F4CD-4B5A-86BA-A36549748CC1@orchidseed.org> References: <2DCCC1BB-32FB-4FAC-9D04-266AB8607D0B@orchidseed.org> <4ABB82AD.7030201@idssoftware.com> <8b2769930909240949o25600c62hb84a13fdf648faa9@mail.gmail.com> <4ABC4897.2090501@idssoftware.com> <4AC39A64.7030601@idssoftware.com> <8B60D024-9EA3-46BD-AD20-2B76656FB8DB@orchidseed.org> <4AC4130B.3000605@idssoftware.com> To: Michael Chen X-Mailer: Apple Mail (2.1076) X-Authenticated-User: 72798 julian@orchidseed.org Cc: p2psip WG Subject: Re: [P2PSIP] 10.3.1 Self-Generated Credentials X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 03:07:24 -0000 On Sep 30, 2009, at 7:25 PM, Michael Chen wrote: > Julian, > > My point is that what's left for Reload payload is 1492-1292 = 200 > bytes. Many Reload messages will have to be fragmented. I don't see the problem because TLS over TCP will be doing the same. You will most likely be fragmenting 100% of all application level messages and some percentage of RELOAD messages. Also DTLS has a bit better performance than TLS over TCP. > > --Michael > > jc wrote: >> This is greater than the MTU of an xbox 360 but less than your >> averge router at 1492. Doesn't DTLS in OpenSSL already have the >> real path MTU after the handshake? If not I know it can do this for >> you. You can use that MTU and fragment your packets. >> >> Julian >> >> Sent from my iPhone >> >> On Sep 30, 2009, at 10:50 AM, Michael Chen >> wrote: >> >>> Julian, >>> >>> I have no scientific data, just a personal concern. Consider a >>> Reload STORE request with your 691 byte cert, the total fat (non- >>> payload) on the wire for a UDP/DTLS transport is: >>> >>> DTLS header (13 bytes) >>> Reload header >>> Forward header (38 bytes) >>> Destination list (18 bytes, single hop) >>> Reload Message >>> STORE (SIP_REGISTRATION) >>> AOR >>> RSA Signature (256 bytes) >>> Reload Security Block >>> Certificates (691 bytes) >>> Signer ID (20+ bytes) >>> RSA Signature (256 bytes) >>> DTSL MAC and padding (20+ bytes) >>> >>> These are rough numbers, and it total 1292 bytes excluding the >>> AOR. It is very close to the 1500 byte network packet size (MTU). >>> >>> --Michael >>> >>> jc wrote: >>>> >>>> On Sep 24, 2009, at 9:35 PM, Michael Chen wrote: >>>> >>>>> I also want to point out that even with the most simple encoding >>>>> (JDK keytool), a 1024 bit RSA public key certificate takes up >>>>> 619 bytes. A production strength 2048 bit RSA cert is 880 bytes. >>>>> If a peer can only be reached via UDP, the overhead of DTLS + >>>>> Reload Signature on message leaves very little room for the >>>>> relevant data fragment (e.g. 1500 packet size), which means UDP >>>>> transport may be very inefficient. Transport overhead should be >>>>> a separate discussion thread. >>>> >>>> In my RELOAD implementation a 2048 bit RSA public key is 691 >>>> bytes long, see output below. Do you have statistics that show >>>> the current fragmentation algorithm to be sub-optimal? >>>> Julian >>>> >>>> * >>>> * >>>> *Running 1 test case...* >>>> *......................+++* >>>> *........................+++* >>>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >>>> generating RSA key.* >>>> *..............................+++* >>>> *..............+++* >>>> *debug: RSA* junglecat::rsa::generate_key_pair(): Succeeded >>>> generating RSA key.* >>>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >>>> char*): Allocated* >>>> *debug: X509_NAME* junglecat::x509::allocate_common_name(const >>>> char*): Allocated* >>>> *debug: X509* junglecat::x509::generate_certificate(RSA*, RSA*, >>>> const char*, const char*, unsigned int, const EVP_MD*): Success* >>>> *Certificate:* >>>> * Data:* >>>> * Version: 3 (0x2)* >>>> * Serial Number: 1253857645 (0x4abc596d)* >>>> * Signature Algorithm: sha1WithRSAEncryption* >>>> * Issuer: CN=common_name_issuer* >>>> * Validity* >>>> * Not Before: Sep 25 05:47:25 2009 GMT* >>>> * Not After : Sep 25 06:47:25 2009 GMT* >>>> * Subject: CN=common_name* >>>> * Subject Public Key Info:* >>>> * Public Key Algorithm: rsaEncryption* >>>> * RSA Public Key: (2048 bit)* >>>> * Modulus (2048 bit):* >>>> * 00:ab:54:2c:7b:9a:d8:3c:4b:b8:08:46:04:ee:02:* >>>> * 51:8a:94:4c:62:58:d0:ed:50:f8:2f:5a:43:b2:b0:* >>>> * aa:1a:7c:46:32:ad:93:b3:80:1b:dd:62:d7:72:14:* >>>> * aa:0e:43:7c:6b:00:a6:56:f3:62:ed:b5:d4:ff:c4:* >>>> * da:72:6c:ff:8c:75:a2:8a:0c:e9:fb:9d:f0:f3:6f:* >>>> * d8:65:1e:85:7b:7c:91:cc:b3:8a:eb:f7:ff:1d:c7:* >>>> * e0:9f:e5:d3:e0:d4:23:3a:e9:0a:9c:be:f7:fc:44:* >>>> * 59:3f:03:19:65:8c:fd:07:bd:40:c0:40:3c:04:8e:* >>>> * 46:5c:13:1a:85:68:d8:48:01:f9:03:75:98:e9:1f:* >>>> * a7:bb:d7:75:c7:dc:6b:3c:eb:6e:6c:ee:21:73:94:* >>>> * 66:dd:d6:4a:13:79:7b:19:91:75:f8:14:0e:ba:dd:* >>>> * 01:79:83:0e:3f:e1:9a:10:ea:98:cc:ae:d5:41:d7:* >>>> * 2d:33:0e:ab:6c:be:49:d3:cd:dd:fe:f4:5e:0c:ef:* >>>> * b8:cb:ae:bf:80:e4:cf:9e:66:86:42:2a:1c:3a:ca:* >>>> * d0:d5:ab:ad:34:ba:eb:6e:2d:33:86:4e:29:e8:1b:* >>>> * cb:ee:f4:d5:8f:2c:d1:f6:10:a6:84:4b:4f:05:2d:* >>>> * 17:31:09:03:bd:9e:63:32:0f:14:ae:a6:0c:74:aa:* >>>> * 0a:d3* >>>> * Exponent: 65537 (0x10001)* >>>> * Signature Algorithm: sha1WithRSAEncryption* >>>> * 52:2a:cd:4d:f3:cc:c1:94:5e:5e:09:63:34:f6:fb:9b:c0:52:* >>>> * dc:98:90:30:88:44:bd:f6:73:0a:e2:ed:6c:f1:bc:26:f0:d9:* >>>> * 72:c0:a7:d1:79:85:8d:f1:eb:4c:cc:d1:b0:73:fa:8f:de:e1:* >>>> * 81:9d:32:fa:c6:c3:eb:37:5e:7f:30:c6:7e:a2:34:e0:d1:9d:* >>>> * af:a2:e7:00:59:68:eb:7c:f6:c1:6d:18:0e:f5:14:5e:cc:c9:* >>>> * f2:07:f1:60:a3:b4:a3:28:89:23:93:ac:14:d4:1e:69:f5:c7:* >>>> * b8:90:68:b7:f2:bc:70:6c:2b:7e:01:48:34:77:ae:67:b2:ff:* >>>> * 0f:b7:15:c6:42:4c:9f:c6:dd:02:ed:06:9b:04:60:4a:74:52:* >>>> * ee:03:29:0e:e3:75:62:07:92:a3:48:f6:a4:f5:bb:8c:09:b0:* >>>> * cf:71:12:24:63:33:0f:9f:97:d4:ab:01:da:d7:d8:7f:c8:17:* >>>> * 94:0e:70:03:7a:f0:5e:14:8b:ec:c8:11:d9:b4:b4:74:2c:4e:* >>>> * 0c:56:35:c7:0f:b0:9e:6a:df:b2:63:68:3e:05:53:05:86:7c:* >>>> * 45:82:a4:94:93:12:8e:b4:a2:0d:5f:29:d8:7d:52:d3:ab:8f:* >>>> * d4:cf:6f:26:b7:36:f6:5f:a4:c7:64:da:a2:ec:da:74:3b:e5:* >>>> * 8d:2a:7b:21* >>>> >>>> *X509 structure size: 92* >>>> *RSA structure size: 88* >>>> len:691 >>>> >>>> **** No errors detected* >>>> * >>>> * >> >> > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip From ekr@rtfm.com Wed Sep 30 20:56:01 2009 Return-Path: X-Original-To: p2psip@core3.amsl.com Delivered-To: p2psip@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 557A53A6868 for ; Wed, 30 Sep 2009 20:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZlDTBwyGRYR for ; Wed, 30 Sep 2009 20:56:00 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 75E123A68F2 for ; Wed, 30 Sep 2009 20:56:00 -0700 (PDT) Received: by pzk42 with SMTP id 42so5110339pzk.31 for ; Wed, 30 Sep 2009 20:57:22 -0700 (PDT) Received: by 10.115.113.6 with SMTP id q6mr1230858wam.55.1254369442506; Wed, 30 Sep 2009 20:57:22 -0700 (PDT) Received: from ?10.166.145.129? ([166.205.132.114]) by mx.google.com with ESMTPS id 23sm1076945pxi.5.2009.09.30.20.57.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 30 Sep 2009 20:57:21 -0700 (PDT) References: <4AC41D9B.1040504@idssoftware.com> Message-Id: <8BA1841D-F629-4243-8D0B-CDA730BDB942@rtfm.com> From: Eric Rescorla To: Michael Chen In-Reply-To: <4AC41D9B.1040504@idssoftware.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7A400) Mime-Version: 1.0 (iPhone Mail 7A400) Date: Wed, 30 Sep 2009 20:57:13 -0700 Cc: "p2psip@ietf.org" Subject: Re: [P2PSIP] D/TLS with client authentication X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2009 03:56:01 -0000 On Sep 30, 2009, at 8:10 PM, Michael Chen wrote: > Hi, > > In an earlier thread, David A. Bryan asked about implementation > experience of this draft. Two things pop out immediately from my > head (they both feel like reinventing the wheel): > > 1. Digital signature related requirements seem rehashing what's > being done in TLS and DTLS. > 2. Fragmentation handling seems to be reinventing TCP using UDP. > > The second one may be unfounded, but I like to toss around an idea > while implementing the first. What if this draft mandates the > following regarding TLS and DTLS connections: > > A. Client authentication is required for all TLS and DTLS connections; > B. Both parties (peers) in a D/TLS connection uses the same digital > credentials (certificates and public/private keys) for the DHT > overlay. > > For example, say peer X connects to peer Y via TLS. X will get Y's > overlay certificates and public key during the first part of the TLS > handshake. Then Y request X (the 'client') to send its certificates > and public key during client authentication. The TLS session will > be honored if and only if the overlay information in the > certificates are validated on both sides. This is fully supported > by TLS and DTLS (plus a few callbacks). This is already true > The level of trust established this way is equivalent to that > provided by the current draft-03. The intend is that with these > mandates, the RELOAD protocol itself can be simplified by removing > all certificate and signature related requirements. For example, in > my earlier post, an overhead of 1292 bytes can be trimmed down to > only 69 bytes!!! (removing the security block and the STORE > signature). > I still need to think about messages forwarded by instead of > originated from a peer, but let the discussion begin. Uh this is the base case. Which is why the messages have signatures Ekr > Thanks > > --Michael > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www.ietf.org/mailman/listinfo/p2psip