From sm@elandsys.com Wed Aug 4 12:19:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4843A6831; Wed, 4 Aug 2010 12:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.649 X-Spam-Level: X-Spam-Status: No, score=-100.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, USER_IN_WHITELIST=-100] 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 Hgh-hFBDTZ3G; Wed, 4 Aug 2010 12:19:51 -0700 (PDT) Received: from mail.elandsys.com (mail.elandsys.com [208.69.177.125]) by core3.amsl.com (Postfix) with ESMTP id 6D5CA3A67E2; Wed, 4 Aug 2010 12:19:51 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.237.145]) (authenticated bits=0) by mail.elandsys.com (8.13.8/8.13.8) with ESMTP id o74JK9JV022751; Wed, 4 Aug 2010 12:20:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=elandsys.com; s=mail; t=1280949620; bh=EFzSCV/lL1/C1w9LFGeD30TyVv4=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type; b=lbS72L98inXGZMyQnj/Q3yclFIc92zOhvRPaUQUtyn/NCDiVyalpKRYrJDhD1sjN8 QmNDsIE50GvaQzdmbVmwRwzBilBHnpSliTCE441Pd7bNIah6T24lmuTwxE8Lc2DxGY ZDVHkcH5cFd33poZfoQlRR4FL7aweL7D16SvgG9I= Message-Id: <6.2.5.6.2.20100804115729.0cd8c080@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 04 Aug 2010 12:19:54 -0700 To: apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Review Team Report for July 2010 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 19:19:59 -0000 Hello, The Applications Area Review Team provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The members of the team are selected from the IETF community, especially from among active participants and recognized experts in the Applications Area. We have two new members, Carsten Bormann and Joseph Yee. The following reviews have been performed in July 2010: draft-ietf-ecrit-lost-servicelistboundary-03 was reviewed by Joshua Bell. Pending reviews: draft-ietf-netmod-dsdl-map-05 assigned to Aaron Stone draft-ietf-ecrit-lost-sync-08 assigned to Aaron Stone Aaron Stone kindly agreed to do these two reviews. The previously assigned reviewers had a busy workload. Regards, S. Moonesamy On behalf of the Apps Review Team http://www.apps.ietf.org/content/applications-area-review-team From mnot@mnot.net Wed Aug 4 23:10:58 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7A03A6842 for ; Wed, 4 Aug 2010 23:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.607 X-Spam-Level: X-Spam-Status: No, score=-105.607 tagged_above=-999 required=5 tests=[AWL=-3.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 DV0d32rmwXQk for ; Wed, 4 Aug 2010 23:10:55 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 784C23A68EF for ; Wed, 4 Aug 2010 23:10:55 -0700 (PDT) Received: from chancetrain-lm.mnot.net (unknown [118.209.94.161]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6982922E1F3; Thu, 5 Aug 2010 02:11:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/mixed; boundary=Apple-Mail-10--113695646 From: Mark Nottingham Date: Thu, 5 Aug 2010 16:11:38 +1000 Message-Id: <1B74F7DA-3AB5-44E2-ABB6-0EB103BFF4DB@mnot.net> References: <20100805060002.8684F3A6884@core3.amsl.com> To: HTTP Working Group X-Mailer: Apple Mail (2.1081) Cc: Apps Discuss Subject: [apps-discuss] Fwd: I-D Action:draft-nottingham-http-portal-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: HTTP Working Group List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 06:10:58 -0000 --Apple-Mail-10--113695646 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [ reply-to http list ] FYI. There was an old discussion about this on the HTTP list, starting = at = , = and I think it's time to do something about it. =20 Feedback appreciated. My intent is to engage with folks who are using = captive portals (have already made some small headway there) and = register a new status code if a) feedback here and there is good and b) = they indicate willingness to implement. Cheers, Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 5 August 2010 4:00:02 PM AEST > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nottingham-http-portal-00.txt=20 > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Considerations for Captive Portals in HTTP > Author(s) : M. Nottingham > Filename : draft-nottingham-http-portal-00.txt > Pages : 6 > Date : 2010-08-04 >=20 > "Captive portals" are a commonly-deployed means of obtaining access > credentials and/or payment for a network. This memo discusses issues > of their use for HTTP applications, and proposes one possible > mitigation strategy. >=20 > This memo should be discussed on the ietf-http-wg@w3.org mailing > list, although it is not a work item of the HTTPbis WG. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-nottingham-http-portal-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-10--113695646 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2010-08-04225453.I-D@ietf.org>

--Apple-Mail-10--113695646 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Mark Nottingham http://www.mnot.net/ --Apple-Mail-10--113695646-- From dhc@dcrocker.net Sun Aug 8 08:54:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124443A6858; Sun, 8 Aug 2010 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.918 X-Spam-Level: X-Spam-Status: No, score=-5.918 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, J_CHICKENPOX_51=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 YHV4tBsbhuvo; Sun, 8 Aug 2010 08:54:52 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 147D43A69AA; Sun, 8 Aug 2010 08:54:52 -0700 (PDT) Received: from [192.168.1.102] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o78FtJmr002665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Aug 2010 08:55:24 -0700 Message-ID: <4C5ED362.4080902@dcrocker.net> Date: Sun, 08 Aug 2010 08:55:14 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Apps Discuss , draft-gennai-smime-cnipa-pec@tools.ietf.org References: <4C594FD9.2050605@isode.com> In-Reply-To: <4C594FD9.2050605@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 08 Aug 2010 08:55:25 -0700 (PDT) Cc: iesg Subject: [apps-discuss] [apps-review] Review of: Certified Electronic Mail (draft-gennai-smime-cnipa-pec-07) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 15:54:54 -0000 (re-posted to apps-discuss, as the venue for follow-up discussion. /d) Review of: Certified Electronic Mail Gennai, Shahin, Petrucci, Vinciarelli draft-gennai-smime-cnipa-pec-08 Reviewed by: D. Crocker dcrocker@bbiw.net 8 August 2010 This is a summary review, with a focus on design goals and systems-level issues. Based on my reading of the specification, much more in-depth reviews of this specification are appropriate and required, to consider the fine-grained details which could be problematic. However, this deeper review should wait for resolution of the more basic problems with the design and specification. The specification is for security-related enhancements to Internet Mail[1], for a service using the acronym PEC. The covered security functions are: "...sender identity, message integrity, confidentiality, and non-repudiation of origin." Each of these is a well-understood technical capability, in terms of underlying algorithms. The challenges, then, are in clarity about: 1) The "social" purposes for using these features. 2) The overall systems design for scalable and efficient operations, and use. 3) The differences from prior work that make success more likely for the current service than has been achieved by those earlier efforts. Different usage intent can make the provided features more or less appropriate. In particular, identity and repudiation are security-related functions that are significantly sensitive to usage confusion and varying goals. The specification does not indicate the uses for which this service is appropriate and those for which it is not. For example, there is a considerable difference in the technical demands for a service ensuring that a personal message is really from a friend, versus a company's honoring a contract based on certification of the contract's authorship, versus treating a government directive as duly authorized. The specification must indicate and justify the boundaries of its use. "Sender identity" and "non-repudiation of origin" are particularly challenging services to understand and provide in complex and open environments. Even the meaning of "sender identity" is subject to some choice, depending upon the particular uses of what is being validated. The specification does not define its meaning -- it does not even define identity -- although the identity is certified through a strict x.509 model as applied to the address identifier in an email's author From: header field. Presumably this is to assert a formal association between this online identifier and some sort of nationally-certified identity. The specification needs to define the identifier to be used, its association with an identity, and the justification for these choices. This will permit and constrain possible usage scenarios for this service. Of the listed component services, non-repudiation is the one technical capability that has a particularly limited history of deployment. It's most simple implementation is through a trusted and accountable transmission service, as provided for decades by EDI Value-Added Networks[13]. This is a form of "channel" security, with the carriage service doing the vouching. Transport-independent object-oriented non-repudiation is accomplished with cryptographic tools that wrap information around a message. For this the core requirement is an external, trusted time-stamping service based on the relevant identifier and a hash of the relevant content. The triple of [actor identifier, content hash, and timestamp] provide a basis for later proof of authorship. Although often provided as part of message relaying, this can be implemented by an external agent service that is merely provided the identifier and hash, but does not directly touch the actual message. (For example, this is the basis of the Goodmail[10] design.) Typical, paper-based postal certified mail provides non-repudiation of origin, but not of author. That is, it validates information about the place of origin, but does nothing to certify the identity of the purported author. The current specification appears to assert non-repudiation of authorship. Typical postal certification can include non-repudiation of receipt. The current service does not provide that. For Internet Mail, each of the target functions has twenty years of Internet history, at least dating back to Privacy Enhanced Mail[2] and more recently with OpenPGP[14] and S/MIME[3]. More generally, efforts for public services of these types date back at least thirty years, notably with X.400[7]. In each case, they have at best achieved very modest success, and even then only within carefully controlled or constrained environments. To limit the level of expertise required by end users, the specification cites a distinctive design goal of using "...applications running on servers to digitally sign messages, thus avoiding the complexity end-to-end systems bring about." However the specification indicates that signatures are to be verified in email clients. This is an example of the goal and design confusion in the specification. From the specification, it is not clear where work is performed within the service architecture, or why. This is indicative of the more general lack of a complete architectural description. A detailed listing and review of the design's assumptions and conflicts needs to be made and documented, with particular attention to operations and end-user usability. Their efficacy also needs to be considered in a substantive, documented manner, beyond simple guessing. Usability is an empirical design specialty. The design is built upon a base of existing Internet Mail format and exchange protocols, as well as S/MIME[3] for security-oriented message encoding, TLS[4] for internal channel security, X.509[5] for trust-based certificates and LDAP[6] for database queries. In every case of using these technologies, the specification defines constraints, enhancements or usage profiles to them. The specification does not make clear when it is modifying or enhancing or profiling an underlying component technology or service. It needs to be explicit about labeling the places and ways in which it is doing this. Equally, the specification needs to make clear what modifications are required for existing email functionality, such as to MUAs, MSAs, MTAs and MDAs. This is essential for assessing the adoption and incremental operations effort. The specification uses the terms "message" and "envelope" in a confusing manner. Message refers both to an electronic mail message and to a "PEC" system control message. Envelope is a reserved term in email but is also used in the specification to refer to a PEC "transport" control message, apparently as distinct from other types of PEC control messages. The term "transport" might also engender confusion, given its industry use to refer various to TCP and SMTP. In general, the vocabulary chosen for the specification is confusing and needs to be modified and clarified. The system description is based on Section 2.2 "Basic Structure". The sole diagram in the specification shows users at either end, with sending and receiving certified electronic mail (PEC) providers depicted in between. The specification does not discuss the security and trust requirements that must be in satisfied by PEC providers. This is a critical omission from the specification and must be rectified. A sending provider is shown as having an: a) Access Point, for interaction with the user. Apparently this is for a posting sequence, per the MUA-MSA interaction per [1]; if so, the connection is unidirectional. b) Incoming Point, for interaction between PEC providers; for typical message flows, this is unidirectional. c) Delivery Point, which "forwards [messages] to the final recipient"; this appears to make no distinction between relaying from one provider to another, versus the typical meaning of email delivery, which is from a provider to a recipient's mailbox. The receiving provider does not have the Access Point. The relationship between an an Access Point and an Incoming Point is not described. Neither is the relationship between Incoming Point and a Delivery Point. Given that these latter two apparently both conduct external interactions "towards" the recipient, the definitions of these two functions appear to be in conflict. The specification needs to clarify the relationships between an Access Point and an Incoming point, and between an Incoming Point and a Delivery Point. Within a PEC provider box the diagram is generic, in that the relationships among the depicted functions of a provider are not indicated. The diagram shows bidirectional exchanges taking place between the a user and their provider and between PEC providers. The diagram does not indicate the types of interactions taking place between a user and a provider. There is no depiction of the overall flow for actual email, unless that is meant to be implied within the one diagram in the document. Even then, the fact that all connections are shown as bi-directional means that sequential "flow" is not indicated at all. It appears that bi-directionality of the links is meant to indicate the chatter of underlying request/response protocol conversations. It would be far more helpful to have the diagram indicate overall information flow, to achieve an end-to-end posting and delivery sequence. No other diagrams are present in the specification, and particularly none showing such flow(s). This is a critical omission from the specification. The specification mandates that an email message have the same Sender: header field address as the From: field. No rationale is provided, nor is there discussion of the significant restriction this imposes on email behaviors that otherwise would be legitimate. Given sufficient rationale and specification of appropriate usage scenarios, this constraint might be warranted. Given the current documentation it seems merely arbitrary. The specification, or a companion document, must justify the choices. The specification mandates having the X.509 certificate's identifier match the address in the From: header field. This is asserted to be necessary for verifying the signature, but that assertion is not obviously correct and is more probably incorrect. More likely is the belief that this validates an assertion of authorship. As a semantic enhancement to email, it can be reasonable to assert that a match between a X.509 identifier and the verified From: field address of a message validates authorship. However this enhancement needs to be specified explicitly and thoroughly. The specification calls for modifying a From: header field to eliminate the author-supplied "display" name, replacing it with the original author email address and a prefatory string "On behalf of", using a PEC address in the From: header field's email address. These changes are claimed to improve message usability. The meaning of usability, in this case, is not provided. In terms of user interface design, the premise of the change to the From: header field is empirically invalid. In fact for typical recipients their understanding of message authorship will be greatly reduced. Comments: The many efforts to deploy this type of functionality -- including recent commercial efforts such as PostX[9], Tumbleweed[8] and Goodmail[10] -- have all achieved no better than modest success and arguably not even that. Utility in large scale, for a broad market, remains elusive. There appear to be several core barriers to adoption, operation and use. The current proposal does not clearly and directly address any of them. The authors need to document a careful review of prior work and explain what is different in the current work, as well as the theoretical and empirical bases for believing that these differences will make success more likely for the current work. The first priority for this specification is to properly document its architecture, probably in a separate document. This requires clear and complete diagrams and data flow, and carefully selected vocabulary. For example, the design apparently intends to offload some security functions to external servers, rather than perform them in their usually venue of the MUA. This is cited as improving usability; however the details and rationale for this are not clearly supplied. (For reference, note that offloading was attempted for organization-to-organization security during initial testing of PEM, by Trusted Information Systems. Another variant is typically performed for DKIM[11] with server-to-server authentication, albeit for much more modest security functions.) It is widely -- and I believe correctly -- held that the primary barriers to success for this class of service are matters of operational and end-user usability. Problems with security-related usability design, systems administration, user interface design, user cognitive models for computer, network and email security, suffer a very poor state of the art, and remain open research topics. There is an extremely poor record for mass-market security products and only a slightly better record in research. For example see SOUPS[12]. While government mandate can force products to be produced, it cannot guarantee usability. The primary effect of government mandate about poor technology service design is expenditure for products that are not used that remain limited to very constrained environments. (X.400 and OSI in general supplied a powerful demonstration of this fact.) The goals of the specification appear to be reasonable and even laudable. Unfortunately, the likely success of this design is not promising. d/ -------- [1] Internet Mail Architecture, [2] Privacy Enhanced Mail, [3] S/MIME, [4] TLS, [5] X.509, [6] LDAP, [7] X.400, [8] Tumbleweed, [9] PostX,m [10] Goodmail, [11] DKIM, [12] SOUPS, [13] EDI VAN, [14] OpenPGP, -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sun Aug 8 09:37:19 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34D93A6858; Sun, 8 Aug 2010 09:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.926 X-Spam-Level: X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, J_CHICKENPOX_51=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 Cvrx6sxjrYyi; Sun, 8 Aug 2010 09:37:17 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id A8AB03A67EF; Sun, 8 Aug 2010 09:37:17 -0700 (PDT) Received: from [192.168.1.102] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o78Gbh9c004867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Aug 2010 09:37:50 -0700 Message-ID: <4C5EDD52.6080103@dcrocker.net> Date: Sun, 08 Aug 2010 09:37:38 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: discuss@apps.ietf.org, draft-gennai-smime-cnipa-pec@tools.ietf.org References: <4C594FD9.2050605@isode.com> In-Reply-To: <4C594FD9.2050605@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 08 Aug 2010 09:37:51 -0700 (PDT) Cc: iesg Subject: [apps-discuss] Review of: Certified Electronic Mail (draft-gennai-smime-cnipa-pec-08) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 16:37:19 -0000 (Re-posted to discuss@apps.ietf.org as the venue for follow-up discussion, with apologies for the earlier postings to other addresses. The review was requested by Alexey. /d) Review of: Certified Electronic Mail Gennai, Shahin, Petrucci, Vinciarelli draft-gennai-smime-cnipa-pec-08 Reviewed by: D. Crocker dcrocker@bbiw.net 8 August 2010 This is a summary review, with a focus on design goals and systems-level issues. Based on my reading of the specification, much more in-depth reviews of this specification are appropriate and required, to consider the fine-grained details which could be problematic. However, this deeper review should wait for resolution of the more basic problems with the design and specification. The specification is for security-related enhancements to Internet Mail[1], for a service using the acronym PEC. The covered security functions are: "...sender identity, message integrity, confidentiality, and non-repudiation of origin." Each of these is a well-understood technical capability, in terms of underlying algorithms. The challenges, then, are in clarity about: 1) The "social" purposes for using these features. 2) The overall systems design for scalable and efficient operations, and use. 3) The differences from prior work that make success more likely for the current service than has been achieved by those earlier efforts. Different usage intent can make the provided features more or less appropriate. In particular, identity and repudiation are security-related functions that are significantly sensitive to usage confusion and varying goals. The specification does not indicate the uses for which this service is appropriate and those for which it is not. For example, there is a considerable difference in the technical demands for a service ensuring that a personal message is really from a friend, versus a company's honoring a contract based on certification of the contract's authorship, versus treating a government directive as duly authorized. The specification must indicate and justify the boundaries of its use. "Sender identity" and "non-repudiation of origin" are particularly challenging services to understand and provide in complex and open environments. Even the meaning of "sender identity" is subject to some choice, depending upon the particular uses of what is being validated. The specification does not define its meaning -- it does not even define identity -- although the identity is certified through a strict x.509 model as applied to the address identifier in an email's author From: header field. Presumably this is to assert a formal association between this online identifier and some sort of nationally-certified identity. The specification needs to define the identifier to be used, its association with an identity, and the justification for these choices. This will permit and constrain possible usage scenarios for this service. Of the listed component services, non-repudiation is the one technical capability that has a particularly limited history of deployment. It's most simple implementation is through a trusted and accountable transmission service, as provided for decades by EDI Value-Added Networks[13]. This is a form of "channel" security, with the carriage service doing the vouching. Transport-independent object-oriented non-repudiation is accomplished with cryptographic tools that wrap information around a message. For this the core requirement is an external, trusted time-stamping service based on the relevant identifier and a hash of the relevant content. The triple of [actor identifier, content hash, and timestamp] provide a basis for later proof of authorship. Although often provided as part of message relaying, this can be implemented by an external agent service that is merely provided the identifier and hash, but does not directly touch the actual message. (For example, this is the basis of the Goodmail[10] design.) Typical, paper-based postal certified mail provides non-repudiation of origin, but not of author. That is, it validates information about the place of origin, but does nothing to certify the identity of the purported author. The current specification appears to assert non-repudiation of authorship. Typical postal certification can include non-repudiation of receipt. The current service does not provide that. For Internet Mail, each of the target functions has twenty years of Internet history, at least dating back to Privacy Enhanced Mail[2] and more recently with OpenPGP[14] and S/MIME[3]. More generally, efforts for public services of these types date back at least thirty years, notably with X.400[7]. In each case, they have at best achieved very modest success, and even then only within carefully controlled or constrained environments. To limit the level of expertise required by end users, the specification cites a distinctive design goal of using "...applications running on servers to digitally sign messages, thus avoiding the complexity end-to-end systems bring about." However the specification indicates that signatures are to be verified in email clients. This is an example of the goal and design confusion in the specification. From the specification, it is not clear where work is performed within the service architecture, or why. This is indicative of the more general lack of a complete architectural description. A detailed listing and review of the design's assumptions and conflicts needs to be made and documented, with particular attention to operations and end-user usability. Their efficacy also needs to be considered in a substantive, documented manner, beyond simple guessing. Usability is an empirical design specialty. The design is built upon a base of existing Internet Mail format and exchange protocols, as well as S/MIME[3] for security-oriented message encoding, TLS[4] for internal channel security, X.509[5] for trust-based certificates and LDAP[6] for database queries. In every case of using these technologies, the specification defines constraints, enhancements or usage profiles to them. The specification does not make clear when it is modifying or enhancing or profiling an underlying component technology or service. It needs to be explicit about labeling the places and ways in which it is doing this. Equally, the specification needs to make clear what modifications are required for existing email functionality, such as to MUAs, MSAs, MTAs and MDAs. This is essential for assessing the adoption and incremental operations effort. The specification uses the terms "message" and "envelope" in a confusing manner. Message refers both to an electronic mail message and to a "PEC" system control message. Envelope is a reserved term in email but is also used in the specification to refer to a PEC "transport" control message, apparently as distinct from other types of PEC control messages. The term "transport" might also engender confusion, given its industry use to refer various to TCP and SMTP. In general, the vocabulary chosen for the specification is confusing and needs to be modified and clarified. The system description is based on Section 2.2 "Basic Structure". The sole diagram in the specification shows users at either end, with sending and receiving certified electronic mail (PEC) providers depicted in between. The specification does not discuss the security and trust requirements that must be in satisfied by PEC providers. This is a critical omission from the specification and must be rectified. A sending provider is shown as having an: a) Access Point, for interaction with the user. Apparently this is for a posting sequence, per the MUA-MSA interaction per [1]; if so, the connection is unidirectional. b) Incoming Point, for interaction between PEC providers; for typical message flows, this is unidirectional. c) Delivery Point, which "forwards [messages] to the final recipient"; this appears to make no distinction between relaying from one provider to another, versus the typical meaning of email delivery, which is from a provider to a recipient's mailbox. The receiving provider does not have the Access Point. The relationship between an an Access Point and an Incoming Point is not described. Neither is the relationship between Incoming Point and a Delivery Point. Given that these latter two apparently both conduct external interactions "towards" the recipient, the definitions of these two functions appear to be in conflict. The specification needs to clarify the relationships between an Access Point and an Incoming point, and between an Incoming Point and a Delivery Point. Within a PEC provider box the diagram is generic, in that the relationships among the depicted functions of a provider are not indicated. The diagram shows bidirectional exchanges taking place between the a user and their provider and between PEC providers. The diagram does not indicate the types of interactions taking place between a user and a provider. There is no depiction of the overall flow for actual email, unless that is meant to be implied within the one diagram in the document. Even then, the fact that all connections are shown as bi-directional means that sequential "flow" is not indicated at all. It appears that bi-directionality of the links is meant to indicate the chatter of underlying request/response protocol conversations. It would be far more helpful to have the diagram indicate overall information flow, to achieve an end-to-end posting and delivery sequence. No other diagrams are present in the specification, and particularly none showing such flow(s). This is a critical omission from the specification. The specification mandates that an email message have the same Sender: header field address as the From: field. No rationale is provided, nor is there discussion of the significant restriction this imposes on email behaviors that otherwise would be legitimate. Given sufficient rationale and specification of appropriate usage scenarios, this constraint might be warranted. Given the current documentation it seems merely arbitrary. The specification, or a companion document, must justify the choices. The specification mandates having the X.509 certificate's identifier match the address in the From: header field. This is asserted to be necessary for verifying the signature, but that assertion is not obviously correct and is more probably incorrect. More likely is the belief that this validates an assertion of authorship. As a semantic enhancement to email, it can be reasonable to assert that a match between a X.509 identifier and the verified From: field address of a message validates authorship. However this enhancement needs to be specified explicitly and thoroughly. The specification calls for modifying a From: header field to eliminate the author-supplied "display" name, replacing it with the original author email address and a prefatory string "On behalf of", using a PEC address in the From: header field's email address. These changes are claimed to improve message usability. The meaning of usability, in this case, is not provided. In terms of user interface design, the premise of the change to the From: header field is empirically invalid. In fact for typical recipients their understanding of message authorship will be greatly reduced. Comments: The many efforts to deploy this type of functionality -- including recent commercial efforts such as PostX[9], Tumbleweed[8] and Goodmail[10] -- have all achieved no better than modest success and arguably not even that. Utility in large scale, for a broad market, remains elusive. There appear to be several core barriers to adoption, operation and use. The current proposal does not clearly and directly address any of them. The authors need to document a careful review of prior work and explain what is different in the current work, as well as the theoretical and empirical bases for believing that these differences will make success more likely for the current work. The first priority for this specification is to properly document its architecture, probably in a separate document. This requires clear and complete diagrams and data flow, and carefully selected vocabulary. For example, the design apparently intends to offload some security functions to external servers, rather than perform them in their usually venue of the MUA. This is cited as improving usability; however the details and rationale for this are not clearly supplied. (For reference, note that offloading was attempted for organization-to-organization security during initial testing of PEM, by Trusted Information Systems. Another variant is typically performed for DKIM[11] with server-to-server authentication, albeit for much more modest security functions.) It is widely -- and I believe correctly -- held that the primary barriers to success for this class of service are matters of operational and end-user usability. Problems with security-related usability design, systems administration, user interface design, user cognitive models for computer, network and email security, suffer a very poor state of the art, and remain open research topics. There is an extremely poor record for mass-market security products and only a slightly better record in research. For example see SOUPS[12]. While government mandate can force products to be produced, it cannot guarantee usability. The primary effect of government mandate about poor technology service design is expenditure for products that are not used that remain limited to very constrained environments. (X.400 and OSI in general supplied a powerful demonstration of this fact.) The goals of the specification appear to be reasonable and even laudable. Unfortunately, the likely success of this design is not promising. d/ -------- [1] Internet Mail Architecture, [2] Privacy Enhanced Mail, [3] S/MIME, [4] TLS, [5] X.509, [6] LDAP, [7] X.400, [8] Tumbleweed, [9] PostX,m [10] Goodmail, [11] DKIM, [12] SOUPS, [13] EDI VAN, [14] OpenPGP, -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Aug 11 13:54:08 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7763A67EC for ; Wed, 11 Aug 2010 13:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.433 X-Spam-Level: X-Spam-Status: No, score=-103.433 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Fvw6RT8nBaLq for ; Wed, 11 Aug 2010 13:54:07 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 620393A67DA for ; Wed, 11 Aug 2010 13:54:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 11 Aug 2010 13:54:40 -0700 From: "Murray S. Kucherawy" To: "Apps-Discuss@ietf.org" Date: Wed, 11 Aug 2010 13:54:39 -0700 Thread-Topic: New Non-WG Mailing List: domainrep -- Domain Reputation Thread-Index: Acs0yoo3h73SMhPlT/aXqQ0tP5q1hQEzNsng Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [apps-discuss] FW: New Non-WG Mailing List: domainrep -- Domain Reputation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:54:08 -0000 Rm9yIHRob3NlIGludGVyZXN0ZWQuLi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IElFU0cgU2VjcmV0YXJ5IFttYWlsdG86aWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmddIA0KU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAwNSwgMjAxMCAxMToxOCBBTQ0KVG86IElFVEYgQW5ub3VuY2Vt ZW50IGxpc3QNCkNjOiBkb21haW5yZXBAaWV0Zi5vcmc7IE11cnJheSBTLiBLdWNoZXJhd3k7IGpk ZmFsay1saXN0c0BjeWJlcm5vdGhpbmcub3JnDQpTdWJqZWN0OiBOZXcgTm9uLVdHIE1haWxpbmcg TGlzdDogZG9tYWlucmVwIC0tIERvbWFpbiBSZXB1dGF0aW9uIA0KDQpBIG5ldyBJRVRGIG5vbi13 b3JraW5nIGdyb3VwIGVtYWlsIGxpc3QgaGFzIGJlZW4gY3JlYXRlZC4NCg0KTGlzdCBhZGRyZXNz OiBkb21haW5yZXBAaWV0Zi5vcmcNCkFyY2hpdmU6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9kb21haW5yZXAvDQpUbyBzdWJzY3JpYmU6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG9tYWlucmVwDQoNCkRlc2NyaXB0aW9uOiBUaGlzIGxpc3QgaXMg Zm9yIGRpc2N1c3Npb25zIHJlbGF0aW5nIHRvIGRldmVsb3BtZW50IGFuZA0KZGVwbG95bWVudCBv ZiBkb21haW4gcmVwdXRhdGlvbiBldmFsdWF0aW9uIGFuZCBjb21tdW5pY2F0aW9uLCBhIG5hdHVy YWwNCm9mZnNob290IG9mIHRoZSB3b3JrIGRvbmUgYnkgdGhlIERLSU0gd29ya2luZyBncm91cCBi dXQgc3BlY2lmaWNhbGx5DQpvdXRzaWRlIG9mIGl0cyBjaGFydGVyLiAgDQoNCkZvciBhZGRpdGlv bmFsIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCB0aGUgbGlzdCBhZG1pbmlzdHJhdG9ycy4N Cg== From stpeter@stpeter.im Tue Aug 17 13:29:05 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1A93A68CE for ; Tue, 17 Aug 2010 13:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3cMDRoAS6DWt for ; Tue, 17 Aug 2010 13:29:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A4D553A67D9 for ; Tue, 17 Aug 2010 13:29:04 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E929F40074 for ; Tue, 17 Aug 2010 14:31:19 -0600 (MDT) Message-ID: <4C6AF132.3010700@stpeter.im> Date: Tue, 17 Aug 2010 14:29:38 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] Fwd: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 20:29:05 -0000 Perhaps of interest here... -------- Original Message -------- Subject: New Non-WG Mailing List: keyassure -- Key Assurance With DNSSEC Date: Tue, 17 Aug 2010 11:36:02 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list CC: ondrej.sury@nic.cz, keyassure@ietf.org A new IETF non-working group email list has been created. List address: keyassure@ietf.org Archive: http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html To subscribe: https://www.ietf.org/mailman/listinfo/keyassure Description: This list is for discussion relating to using DNSSEC-protected DNS queries to get greater assurance for keys and certificates that are passed in existing IETF protocols. The main idea is that a relying party can get additional information about a domain name to eliminate the need for using a certificate in a protocol, to eliminate the need for sending certificates in the protocol if they are optional, and/or to assure that the certificate given in a protocol is associated with the domain name used by the application. In all three cases, the application associates the key or key fingerprint securely retrieved from the DNS with the domain name that was used in the DNS query. For additional information, please contact the list administrators. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dave@cridland.net Tue Aug 17 15:53:45 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B45173A6869 for ; Tue, 17 Aug 2010 15:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 3yvy5ycWzmcr for ; Tue, 17 Aug 2010 15:53:44 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 58E8D3A6828 for ; Tue, 17 Aug 2010 15:53:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id C644E116809F for ; Tue, 17 Aug 2010 23:54:18 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (localhost.localdomain [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXK5OLoJTD69 for ; Tue, 17 Aug 2010 23:54:17 +0100 (BST) Received: from puncture (puncture [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 8E803116809E for ; Tue, 17 Aug 2010 23:54:14 +0100 (BST) MIME-Version: 1.0 Message-Id: <2276.1282085654.582002@puncture> Date: Tue, 17 Aug 2010 23:54:14 +0100 From: Dave Cridland To: General discussion of application-layer protocols Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: [apps-discuss] Security hash algorithms and MTIs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 22:53:45 -0000 Over in the XSF, there's some talk (mostly, I admit, by me) about unifying the MTI recommendations we make concerning hash algorithms into a single specification. I've similarly muttered in various places about unifying MTI recommendations for SASL, too, and I note that something similar applies to TLS cipher suites. Currently, each application protocol defines an MTI authentication mechanism, which is mandated (by IAB fiat, I presume) to have certain characteristics. Similarly, application protocol designers are expected to know what a sensible range of TLS cipher suites to mandate is, this week. Even HTTP-based protocols need to go through the entire song and dance, too, rather than delegating to HTTP. Inevitably, we're a bit out of date on these things, being in, to paraphrase, the nose-bleed section. On the other hand, we tend to have definite ideas about what's most likely to be realistically deployable. Sadly, though, these things change - with the result that the protocols specify our best compromises, frozen at a point in time. Worse, different protocols mandate different combinations, making multiprotocol clients (such as email clients) more complicated than it needs to be. So, is there any interest in putting together a specification (or more likely set of them) which provides MTI recommendations for specific use-cases, such that a protocol spec can say "MUST implement TLS ciphers from BCP XYZ §4.2, MUST implement SASL mechanisms as described in §3.2", and "The hash used for this calculation is the current recommended signature hash from BCP XYZ"? Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From hbahadili@gmail.com Sun Aug 29 15:21:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BAB3A67DA for ; Sun, 29 Aug 2010 15:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_20=-0.74, 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 Ayo7Y+O8arud for ; Sun, 29 Aug 2010 15:21:44 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F121A3A6405 for ; Sun, 29 Aug 2010 15:21:43 -0700 (PDT) Received: by wyi11 with SMTP id 11so6446333wyi.31 for ; Sun, 29 Aug 2010 15:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4xPwfEeGLEQRvLcnQDZyQDWN09S+VvG7qO+27r5Qrug=; b=PTk7X0twhiFiduzTBmsFA4JrEp/j6PUpcokIGAEKlPLxKSWjT3pZb3dwoS2OwQU9Vo 4Chzfojh3p1MByFoLt6GgBhAKq3Vga14XSz2vqHKlDH8QjDMDziM78M6KUd6YNM4rzjA zqLS5Jfaspj+S7E5e/bbjZSSk1iOXNOlQv26s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=KEnFMfB9tVJjpW+WQ6ULlTZrxSsPbxq1PJifM7yA5J+PMyQJfc84Rwgn6x9lul0sKx Ei46yolT8Y4a9dUc07U6v/949voNnu8GMm8MYSJru36ZvdjQZ8rNHLhe9jXdx09C4TZX WgO74PlcvvMhps+XIi9u3RsmPOt+EyiKTOIHk= MIME-Version: 1.0 Received: by 10.216.231.97 with SMTP id k75mr4092322weq.4.1283120534483; Sun, 29 Aug 2010 15:22:14 -0700 (PDT) Received: by 10.216.234.146 with HTTP; Sun, 29 Aug 2010 15:22:14 -0700 (PDT) Date: Mon, 30 Aug 2010 01:22:14 +0300 Message-ID: From: Hussein Al-Bahadili To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=000e0cd485aca9715a048efdc78f Subject: [apps-discuss] CFC - Simulation in Computer Network Design and Modeling: Use and Analysis X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 22:21:46 -0000 --000e0cd485aca9715a048efdc78f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Simulation in Computer Network Design and Modeling: Use and Analysis Editor: Hussein Al-Bahadili, The Arab Academy for Banking & Financial Sciences, hbahadili@gmail.com Publisher: IGI Global (formerly Idea Group Inc.), www.igi-global.com Call for Chapters: Proposals submission deadline: June 30, 2010 (August 31, 2010) (Extended Deadline) Full chapters submission deadline: October 30, 2010 Introduction Prospective authors are invited to submit manuscripts for possible publication in Simulation in Computer Network Design and Modeling: Use and Analysis. This book will publish original material concerned with all aspects of simulation on computer network design, modeling, analysis, management, security, and performance evaluation. The primary mission of th= e book is to be influential in the improvement and development of the theory and practice of computer network design and modeling, appealing to academics, researchers, and professionals. In the information technology ag= e and with tremendous advancement in computer and communication technologies, computer networks have become an integral part of many organizations. It is our further aim to provide enough examples to educate organizations on how they can benefit from simulation to design, evaluate the performance, and manage these valuable resources. Computer simulation is widely-used in investigating the performance of existing and proposed computer networks designs, protocols, algorithms, models, etc. The application of computer simulation can potentially improve the quality and effectiveness of the network design and modeling. It is generally unfeasible to implement a computer network design, protocol, algorithm, or model before valid tests are performed to evaluate their performance. It is clear that testing and evaluating such implementations with real hardware is quite hard, in terms of the manpower, time, and other resources. The preferred alternative is to model these algorithms in a detailed simulator and then perform various scenarios to measure their performance for various patterns of realistic computer networks environment= s (e.g., connection media, node densities, node mobility, transmission range, size of traffic, etc.). The main challenge to simulation is to model the process as close as possible to reality; otherwise it could produce entirel= y different performance characteristics from the ones discovered during actua= l use. In addition, the simulation study must be repeatable, unbiased, realistic, statistically sound, and cost-effective. Objectives of the Book The main objectives of this book is to: present state-of-the-art methodologies in computer networks simulation and modeling; illustrate the benefits of simulation in computer networks design, modeling, and analysis; Identify the main issues that face efficient and effective computer network simulation; demonstrate by example how the performance of computer networks can be evaluated; provide cutting edge research on the simulation and modeling of computer networks; present the trends in computer networks simulation and modeling; discuss the main features of current simulation languages; point-out the main trends in simulation languages and tools; introduce the most popular academic and professional computer networks simulators; and finally provide a complete compilation of the problems whic= h arise during the use of simulation in computer network design and modeling, and the solutions which are applied to them. Recommended Topics Recommended topics include, but are not limited to, the following: =95 Simulations techniques =95 Simulation in design and modeling of - Wireless PANs, LANs, MANs, WANs - Access point and mobile ad hoc networks - Wireless intelligent networks - Mesh networks - Wireless network algorithms and protocols - Integrated wired/wireless systems - Wireless multimedia systems - QoS provisioning in wireless and mobile networks - Security and privacy of mobile/wireless systems - Algorithms and protocols for energy-efficiency and power control - Cellular networks =95 Computer networks simulators =95 Formal simulation and analysis of wireless systems =95 Simulation languages and tools for wireless systems =95 Mobility modeling and simulation =95 RF channel modeling, simulation, and analysis for different types of wireless networks =95 Models and protocols for cognitive radio networks =95 Capacity, coverage, and connectivity modeling and analysis =95 Model and protocols for next generation networking =95 Performance evaluation of computer networks =95 Performance and resource management of computer networks =95 Performance and management of wireless multimedia systems =95 Performance and Management of broadband wireless management =95 Resource allocation in computer and cellular networks =95 Traffic measurement and analysis (wireless TCP, etc.) =95 Wireless security management =95 Interoperability and performance of heterogeneous wireless networks of different standards =95 Correctness, survivability and reliability evaluation Target Audience The intended audience includes academics, researchers, post-graduate students, developers, professionals, network designers, network analysts, telecommunication system designers, technology specialists, practitioners, and people who are interested in using simulation in computer network desig= n and modeling. Another projected audience is the under-graduate students studying at departments of computer science, computer engineering, computer networks, computer information systems, data communication systems. The boo= k is designed to be first choice reference at libraries at universities, academic institutions, research and development centers, information technology centers, and any institutions interested in using, design, modeling, and analysis of computer networks. The book is designed to be use= d as a textbook for courses teaching computer networks simulation and modelin= g for under/post graduate students Submission Procedure Individuals interested in submitting chapters on the above-suggested topics or other related topics should submit a 2-3 page chapter proposal clearly explaining the mission and objectives of the proposed chapter to Hussein Al-Bahadili, editor, at hbahadili@gmail.com, by no later than June 30, 2010 (August 31, 2010 Extended Dealine). We strongly encourage other topics that have not been listed in our suggested list, particularly if the topic is related to the research area in which you have expertise. Upon acceptance o= f your proposal, you will have until October 30, 2010, to prepare your full chapter of 8,000-10,000 words and 7-10 related terms and their appropriate definitions. Guidelines for preparing your paper and terms and definitions will be sent to you upon acceptance of your proposal. All full chapters wil= l undergo a double blind review process and chapter authors may be used as reviewers. Publisher This book is scheduled to be published by IGI Global (formerly Idea Group Inc.), publisher of the =93Information Science Reference=94 (formerly Idea = Group Reference), =93Medical Information Science Reference,=94 =93Business Scienc= e Reference,=94 and =93Engineering Science Reference=94 imprints. For additio= nal information regarding the publisher, please visit www.igi-global.com. This publication is scheduled to be released in 2011. Important Dates =95 Proposals submission deadline: June 30, 2010 (August 31, 2010) =95 Notification of proposals acceptance: September 15, 2010 =95 Full chapter submission deadline: October 30, 2010 =95 Review results to authors: January 15, 2011 =95 Revised chapter submission deadline: February 15, 2011 =95 Final acceptance notifications: February 28, 2011 =95 Submission of Final Chapters deadline: March 15, 2011 Inquiries and submissions can be forwarded electronically (Word document): Dr. Hussein Al-Bahadili The Arab Academy for Banking and Financial Sciences P. O. Box 13190, Amman 11942, Jordan Phone: +962 6 550 2900 (Ext. 318) Mobile: +962 796523978 Fax: +962 6 5105176 Email: hbahadili@gmail.com --000e0cd485aca9715a048efdc78f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Simulation in Computer Network Design and Modeling: Use= and Analysis

Editor: Hussein Al-Bahadili, The Arab Academy for Banking & Financia= l Sciences, hbahadili@gmail.com= =A0

Publisher: IGI Global (formerly Idea Group Inc.), www.igi-global.com

Call for Chapters:
Proposals submission deadline: June 30, 2010 (Aug= ust 31, 2010) (Extended Deadline)
Full chapters submission deadline: Oct= ober 30, 2010

Introduction
Prospective authors are invited to submit manuscripts fo= r possible publication in Simulation in Computer Network Design and Modelin= g: Use and Analysis. This book will publish original material concerned wit= h all aspects of simulation on computer network design, modeling, analysis,= management, security, and performance evaluation. The primary mission of t= he book is to be influential in the improvement and development of the theo= ry and practice of computer network design and modeling, appealing to acade= mics, researchers, and professionals. In the information technology age and= with tremendous advancement in computer and communication technologies, co= mputer networks have become an integral part of many organizations. It is o= ur further aim to provide enough examples to educate organizations on how t= hey can benefit from simulation to design, evaluate the performance, and ma= nage these valuable resources.

Computer simulation is widely-used in investigating the performance of e= xisting and proposed computer networks designs, protocols, algorithms, mode= ls, etc. The application of computer simulation can potentially improve the= quality and effectiveness of the network design and modeling. It is genera= lly unfeasible to implement a computer network design, protocol, algorithm,= or model before valid tests are performed to evaluate their performance. I= t is clear that testing and evaluating such implementations with real hardw= are is quite hard, in terms of the manpower, time, and other resources. The= preferred alternative is to model these algorithms in a detailed simulator= and then perform various scenarios to measure their performance for variou= s patterns of realistic computer networks environments (e.g., connection me= dia, node densities, node mobility, transmission range, size of traffic, et= c.). The main challenge to simulation is to model the process as close as p= ossible to reality; otherwise it could produce entirely different performan= ce characteristics from the ones discovered during actual use. In addition,= the simulation study must be repeatable, unbiased, realistic, statisticall= y sound, and cost-effective.
=A0
Objectives of the Book
The main objectives of this book is to: pr= esent state-of-the-art methodologies in computer networks simulation and mo= deling; illustrate the benefits of simulation in computer networks design, = modeling, and analysis; Identify the main issues that face efficient and ef= fective computer network simulation; demonstrate by example how the perform= ance of computer networks can be evaluated; provide cutting edge research o= n the simulation and modeling of computer networks; present the trends in c= omputer networks simulation and modeling; discuss the main features of curr= ent simulation languages; point-out the main trends in simulation languages= and tools; introduce the most popular academic and professional computer n= etworks simulators; and finally provide a complete compilation of the probl= ems which arise during the use of simulation in computer network design and= modeling, and the solutions which are applied to them.
=A0

Recommended Topics
Recommended topics include, but are not limited to= , the following:
=95=A0Simulations techniques
=95=A0Simulation in des= ign and modeling of=A0
-=A0Wireless PANs, LANs, MANs, WANs
-=A0Acces= s point and mobile ad hoc networks
-=A0Wireless intelligent networks
-=A0Mesh networks
-=A0Wireless netw= ork algorithms and protocols
-=A0Integrated wired/wireless systems
-= =A0Wireless multimedia systems
-=A0QoS provisioning in wireless and mobi= le networks
-=A0Security and privacy of mobile/wireless systems
-=A0Algorithms and p= rotocols for energy-efficiency and power control
-=A0Cellular networks =
=95=A0Computer networks simulators
=95=A0Formal simulation and analy= sis of wireless systems
=95=A0Simulation languages and tools for wireless systems
=95=A0Mobility= modeling and simulation
=95=A0RF channel modeling, simulation, and ana= lysis for different types of wireless networks
=95=A0Models and protocol= s for cognitive radio networks
=95=A0Capacity, coverage, and connectivity modeling and analysis
=95=A0= Model and protocols for next generation networking
=95=A0Performance eva= luation of computer networks
=95=A0Performance and resource management o= f computer networks
=95=A0Performance and management of wireless multimedia systems
=95=A0Pe= rformance and Management of broadband wireless management
=95=A0Resourc= e allocation in computer and cellular networks
=95=A0Traffic measurement= and analysis (wireless TCP, etc.)
=95=A0Wireless security management
=95=A0Interoperability and performanc= e of heterogeneous wireless networks of different standards
=95=A0Correc= tness, survivability and reliability evaluation

Target Audience
The intended audience includes academics, researchers= , post-graduate students, developers, professionals, network designers, net= work analysts, telecommunication system designers, technology specialists, = practitioners, and people who are interested in using simulation in compute= r network design and modeling. Another projected audience is the under-grad= uate students studying at departments of computer science, computer enginee= ring, computer networks, computer information systems, data communication s= ystems. The book is designed to be first choice reference at libraries at u= niversities, academic institutions, research and development centers, infor= mation technology centers, and any institutions interested in using, design= , modeling, and analysis of computer networks. The book is designed to be u= sed as a textbook for courses teaching computer networks simulation and mod= eling for under/post graduate students

Submission Procedure
Individuals interested in submitting chapters on= the above-suggested topics or other related topics should submit a 2-3 pag= e chapter proposal clearly explaining the mission and objectives of the pro= posed chapter to Hussein Al-Bahadili, editor, at hbahadili@gmail.com, by no later than June 30, 2010 (Augus= t 31, 2010 Extended Dealine). We strongly encourage other topics that have = not been listed in our suggested list, particularly if the topic is related= to the research area in which you have expertise. Upon acceptance of your = proposal, you will have until October 30, 2010, to prepare your full chapte= r of 8,000-10,000 words and 7-10 related terms and their appropriate defini= tions. Guidelines for preparing your paper and terms and definitions will b= e sent to you upon acceptance of your proposal. All full chapters will unde= rgo a double blind review process and chapter authors may be used as review= ers.

Publisher
This book is scheduled to be published by IGI Global (forme= rly Idea Group Inc.), publisher of the =93Information Science Reference=94 = (formerly Idea Group Reference), =93Medical Information Science Reference,= =94 =93Business Science Reference,=94 and =93Engineering Science Reference= =94 imprints. For additional information regarding the publisher, please vi= sit www.igi-global.com. This pub= lication is scheduled to be released in 2011.

Important Dates
=95=A0Proposals submission deadline: June 30, 2010 (A= ugust 31, 2010)
=95=A0Notification of proposals acceptance: September 15= , 2010
=95=A0Full chapter submission deadline: October 30, 2010
=95= =A0Review results to authors: January 15, 2011
=95=A0Revised chapter submission deadline: February 15, 2011
=95=A0Final= acceptance notifications: February 28, 2011
=95=A0Submission of Final C= hapters deadline: March 15, 2011

Inquiries and submissions can be forwarded electronically (Word document= ):
Dr. Hussein Al-Bahadili
The Arab Academy for Banking and Financia= l Sciences
P. O. Box 13190, Amman 11942, Jordan
Phone: +962 6 550 290= 0 (Ext. 318)
Mobile: +962 796523978
Fax: +962 6 5105176
Email: hbahadili@gmail.com

--000e0cd485aca9715a048efdc78f-- From brian.e.carpenter@gmail.com Mon Aug 30 16:25:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12873A68DD for ; Mon, 30 Aug 2010 16:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XGzb6LZw5+mo for ; Mon, 30 Aug 2010 16:25:37 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id B0C233A68DA for ; Mon, 30 Aug 2010 16:25:37 -0700 (PDT) Received: by qyk1 with SMTP id 1so3439170qyk.10 for ; Mon, 30 Aug 2010 16:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=HqjEO+2MREvA3FagMv3b+MFaA140740mVVkNL4knfSY=; b=FkVmjSMCFyZxRnU57ItfBd0clwQQuTX5j/73I3hHju44HoWB7+Eg+lLR78zICtORAd 5KAFGeyHRel5Mr0K9KMCzM6eraEYnb/saL7Tyf0Lc3V59XlTYOXOeVISLt7B5u7ezu7T qQi9oTx8OeGavWHxkrimGyDleKludGDn1yG1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; b=dws2wdqP9Tc0Ut3oBzGue4sDcPjSZzdQAacYFvAkDF2gcY0Ps0R0F0ncj/labTvG79 5725YlrSEqxPgfFCmuyv4obuAqOxDWA3YACKWrros1E+4xdBXkKQDT0pcdjU2ktsk0h9 PY7dBcmXZsX3h1N5selabajb/wNrrMx4UH1Uo= Received: by 10.220.158.11 with SMTP id d11mr277602vcx.91.1283210768475; Mon, 30 Aug 2010 16:26:08 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id i23sm2676654vcr.34.2010.08.30.16.26.06 (version=SSLv3 cipher=RC4-MD5); Mon, 30 Aug 2010 16:26:08 -0700 (PDT) Message-ID: <4C7C3E0C.1070402@gmail.com> Date: Tue, 31 Aug 2010 11:26:04 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: apps-discuss@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: zhouboyj@gmail.com, Sheng Jiang Subject: [apps-discuss] [Fwd: I-D Action:draft-carpenter-referral-ps-01.txt] X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 23:25:38 -0000 Hi, A few people believe that the problem of 3rd party referrals really does need to be tackled in a generic way. We've backed off from proposing a solution (as in the GROBJ BOF at IETF 76), since the BOF showed strong consensus that the topic is worth working on, and strong consensus that the requirements need to be clarified first. As the first step in that, here's an update of the problem statement. Comments and discussion welcome, preferably on the ad hoc GROBJ mailing list. https://www.ietf.org/mailman/listinfo/grobj Regards Brian Carpenter Sheng Jiang Bo Zhou -------- Original Message -------- From: Date: Mon, Aug 30, 2010 at 1:15 PM Subject: I-D Action:draft-carpenter-referral-ps-01.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Problem Statement for Referral Author(s) : B. Carpenter, et al. Filename : draft-carpenter-referral-ps-01.txt Pages : 14 Date : 2010-08-29 The purpose of a referral is to enable a given entity in a multiparty Internet application to pass information to another party. It enables a communication initiator to be aware of relevant information of its destination entity before launching the communication. This memo discusses the problems involved in referral scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-referral-ps-01.txt