From turners@ieca.com Mon Sep 13 13:41:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D60C3A6ABF for ; Mon, 13 Sep 2010 13:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 ALFh-S3nlnVI for ; Mon, 13 Sep 2010 13:41:46 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id 1A8BF3A6AA5 for ; Mon, 13 Sep 2010 13:41:23 -0700 (PDT) Received: (qmail 8180 invoked from network); 13 Sep 2010 20:41:35 -0000 Received: from thunderfish.local (turners@96.241.1.67 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 13 Sep 2010 13:41:35 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: WUq0jkUVM1nDOYacXfLRIQTI5Ayi_NltlayZsnJnTXD4gFX s.efYkr6oa_GuHtFQ5pcnhe7yOIVPV7SKiFKHM31H9l5wo1Pj9NyhO3i5Hjk cGwc1grhnhBqnLMQ01PxxeHw0CAxXxcO.10Phpu2Mfm9kShpT3LRNhJqTFKd jfjqcesf4ZJ9EQGxnm1ay7cQBwo.rU6mK6AN_JupheqIIL7c08Rtu5sPIpqv EvoeoUcgiQmtsZe9nTMx_NBd2Y4inipQwqlMUIcN.ATatQCqxM.5R1dZr7HY Mc9US27j9GZAspXFaW21jCaI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8E8C7E.1080101@ieca.com> Date: Mon, 13 Sep 2010 16:41:34 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Call for SAAG presentations topics X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 20:41:49 -0000 Folks, Tim and I are putting together the SAAG agendas for Beijing and Prague. The agenda traditionally includes one or two invited presentations after the working group reports. We would appreciate submission of presentation topics that you believe would be of interest to the community. If you can identify an appropriate presenter (not necessarily yourself) that would be helpful. Also, please indicate whether you'd prefer Beijing or Prague. Thanks, spt From sob@harvard.edu Mon Sep 13 16:30:50 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C3163A6824 for ; Mon, 13 Sep 2010 16:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.622 X-Spam-Level: X-Spam-Status: No, score=-100.622 tagged_above=-999 required=5 tests=[AWL=-0.623, 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 ATyNd7S8UfVS for ; Mon, 13 Sep 2010 16:30:46 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 943333A681D for ; Mon, 13 Sep 2010 16:30:46 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id AEDD932CB17; Mon, 13 Sep 2010 19:31:06 -0400 (EDT) To: saag@ietf.org Message-Id: <20100913233110.AEDD932CB17@newdev.eecs.harvard.edu> Date: Mon, 13 Sep 2010 19:31:06 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: Re: [saag] Feedback solicited for Privacy and Identity Management Terminology X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 23:30:50 -0000 sorry for the belated comment in this ID imo - this ID does get around to providing some reasonable definitions for useful privacy and identity management terminology but it takes a long time to get there. This ID is written in the style of an academic conference or journal paper rather than an IETF terminology document. I suggest that most of the ID be tweaked slightly and submitted to a relevant journal. I do think that it would be good for the IETF to have a clear and easy to understand BCP defining privacy and identity management terms but I do not think this is the document (even if some of the actual definitions seem OK). A much shorter document with clear short definitions with a paragraph or two of discussion would be quite useful. Scott From hallam@gmail.com Sat Sep 4 14:12:06 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA5A23A6892 for ; Sat, 4 Sep 2010 14:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[AWL=-0.459, 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 aJuBc1KobZt0 for ; Sat, 4 Sep 2010 14:12:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 5006F3A68A2 for ; Sat, 4 Sep 2010 14:12:04 -0700 (PDT) Received: by iwn3 with SMTP id 3so3099636iwn.31 for ; Sat, 04 Sep 2010 14:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=cdX63rvC4BTDjknHPiJAG6eBZuOk4ozIVQ+ltS60aiU=; b=hyU8RX30EovxAtbwCowbkmHQY7WVunhHrypFX3b3H7MJ0CbRiEOacBkABXbq58FIp5 aKZm2kHdlmVfsAIDbXWJXL+4SUlrLbAcC8VT1v0z65F1at5BQUQ/12zR5FQQfjPwqCvT +esHnC5T2eS8BsjGpP8CtJChGAJ3cySaqYhJI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cEU7dvF6p3cc7Sij31dr0sDs4o8hbBsNqtBOLUqY6r0VHUS6yr0Hdr/HkVZBXdhNv+ knNs+3RoXduoNFPpYcFVAV6IcWYmx86Yur77mlOIGgVDr0w8zi120lY5JCQU0qyp7JLK H1epCba/uzvE9y+/207v6qlJ09Q9q5U6/oEpE= MIME-Version: 1.0 Received: by 10.231.79.77 with SMTP id o13mr3429041ibk.36.1283634753271; Sat, 04 Sep 2010 14:12:33 -0700 (PDT) Received: by 10.231.35.70 with HTTP; Sat, 4 Sep 2010 14:12:33 -0700 (PDT) In-Reply-To: <4C7AF467.6000103@gondrom.org> References: <4C78103A.3090000@ieca.com> <4C7AF467.6000103@gondrom.org> Date: Sat, 4 Sep 2010 17:12:33 -0400 Message-ID: From: Phillip Hallam-Baker To: Tobias Gondrom Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 14 Sep 2010 09:08:20 -0700 Cc: saag@ietf.org Subject: Re: [saag] Cipher suite proliferation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2010 21:12:06 -0000 It is certainly a problem. What happens when someone comes along wanting to show how to use BROKEN with S/MIME. Do we really want a standards track RFC to issue? Like it or not, a standards track RFC is an endorsement of the algorithm. Some of these crypto requests are for vanity crypto. Others have serious political and/or business rationales. There are good reasons for stating how to use the crypto but we are in no position to evaluate its strength. Another related problem we have is that a lot of our standards mandate the crypto algorithms of the date they were specified rather than contemporary standards. I would like it to have as few obstacles as possible put in the path of people proposing to use SHA-2 or the new SHA-3 with legacy algorithms. I would also like to have a general statement that protocols should regard 2048 bits as a minimum for RSA and that they should support AES. Unless there is something weird in the protocol definition, an algorithm specification should not be much more than specifying a code point and giving some examples. If it takes anything more we have problems. One point to consider is whether we need 16 documents per algorithm, one for each major protocol or if some or most of these documents could be combined. I suggest that we recognize the fact that the IETF has adopted a set of core cryptographic algorithms that are generally regarded as MUST for the protocols currently being agreed and have a way to backdate them to prior standards. Only core algorithms and algorithms discussed in WGs would (ordinarily) be eligible for standards track documents. From turners@ieca.com Tue Sep 14 13:30:49 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5F33A6B1C for ; Tue, 14 Sep 2010 13:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 1UWbs0VxIsSl for ; Tue, 14 Sep 2010 13:30:30 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 889D73A6AAD for ; Tue, 14 Sep 2010 13:30:27 -0700 (PDT) Received: (qmail 85028 invoked from network); 14 Sep 2010 20:30:50 -0000 Received: from thunderfish.local (turners@96.231.127.24 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 14 Sep 2010 13:30:50 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: mAJYXzYVM1kDUl9KEJoz7bpHmDF0N1b95uQFSF9_D1GNFmL W903fSQYyhK.XiEdacnV2P9E7Xgqqa0KqCDprjgwScDiJMFc1g4wUIflGOVt sNcm8.XwwGf.UHBlQg_2IGzpdor315bK44l7kx7VMAtLdaxMz7IkuaAYVBvB Nonmgi90sgHi.aFMioNlokxjTbTKJ2GR.oOFDDKEShsOaR0Ljw9M_OCwKaYQ 5MvNhX2mGsGItM9MiJaiVo01kkhPQm3.b2WVRp2lH5AG6pHZaZ4u1Y0uANob JHB2pWQAPW6y81RwxAXrzn79F1vNT0_2gp6y.L3i_04lNK7ZzBbfon1bPA20 3SiOjqICPphjDdzyG0CmYZceuYXBoQP.X7bbZ7yGf0KvLyLjkSOv6gqSgRNJ SX56gmslS7CpjrzWNapqxrQC3weYiEaj3qqImiWiawWYdx3stjSrMW2xw X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8FDB7A.6080909@ieca.com> Date: Tue, 14 Sep 2010 16:30:50 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] [Fwd: New Non-WG Mailing List: scap_interest -- Discussion List for IETFers interested in the Security Content Automation Protocol (SCAP)] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 20:30:49 -0000 In case you are not on the IETF announce list. -------- Original Message -------- Subject: New Non-WG Mailing List: scap_interest -- Discussion List for IETFers interested in the Security Content Automation Protocol (SCAP) Date: Tue, 14 Sep 2010 13:28:21 -0700 (PDT) From: IETF Secretariat To: IETF Announcement list CC: dave.waltermire@nist.gov, scap_interest@ietf.org A new IETF non-working group email list has been created. List address: scap_interest@ietf.org Archive: http://www.ietf.org/mail-archive/web/scap_interest/ To subscribe: https://www.ietf.org/mailman/listinfo/scap_interest Description: This list is for discussions relating to the applicability of the SCAP content formats to current and emerging IETF protocols. Current SCAP specifications and Internet use scenarios are in scope for this discussion list. Current SCAP specifications include the Common Configuration Enumeration (CCE), Common Vulnerability Evaluation (CVE), Common Platform Enumeration (CPM), Open Vulnerability and Assessment Language (OVAL), and Extensible Configuration Checklist Description Format (XCCDF). 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 hannes.tschofenig@gmx.net Thu Sep 23 08:44:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 190273A698C for ; Thu, 23 Sep 2010 08:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, MANGLED_WRLDWD=2.3, 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 AxsKCWAkb3kO for ; Thu, 23 Sep 2010 08:44:44 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 3749C3A6810 for ; Thu, 23 Sep 2010 08:44:42 -0700 (PDT) Received: (qmail invoked by alias); 23 Sep 2010 15:45:11 -0000 Received: from unknown (EHLO [10.254.0.174]) [192.100.123.77] by mail.gmx.net (mp046) with SMTP; 23 Sep 2010 17:45:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GNRxJ0r4GHTMxurYY+rczWBGfcaw/tdQFg6Uk6Y E32DiEZ+DMEUiL Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Thu, 23 Sep 2010 18:45:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100920210002.96EF53A6876@core3.amsl.com> To: saag@ietf.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [saag] Fwd: Internet Privacy Workshop: 8 and 9 December 2010 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 15:44:47 -0000 Hi all,=20 I believe that this workshop is relevant to this group. You may consider = submitting a position paper.=20 Ciao Hannes Begin forwarded message: > From: IETF Secretariat > Date: September 21, 2010 12:00:02 AM GMT+03:00 > To: ietf-announce@ietf.org > Subject: Internet Privacy Workshop: 8 and 9 December 2010=20 >=20 > The Internet Architecture Board (IAB), World Wide Web Consortium = (W3C), > Internet Society (ISOC) and Massachusetts Institute of Technology = (MIT) > will hold a joint Internet privacy workshop on 8 and 9 December 2010 = at > MIT, Cambridge, Massachusetts on the question: >=20 > "How Can Technology Help to Improve Privacy on the Internet?" >=20 > Information about who we are, what we own, what we have experienced, = how > we behave, where we are located, and how we can be reached are among = the > most personal pieces of information about us. This information is > increasingly being made more easily available electronically via the > Internet, often without the consent of the subject. >=20 > The question for the workshop therefore is: How can we ensure that > architectures and technologies for the Internet, including the World > Wide Web, are developed in ways that respects users=82 intentions = about > their privacy? >=20 > This workshop aims to explore the experience and approaches taken by > developers of Internet including Web technology, when designing = privacy > into these protocols and architectures. Engineers know that many = design > considerations need to be taken into account when developing = solutions. > Balancing between the conflicting goals of openness, privacy, = economics, > and security is often difficult, as illustrated by Clark, et al. in > "Tussle in Cyberspace: Defining Tomorrow's Internet", see > http://groups.csail.mit.edu/ana/Publications/PubPDFs/Tussle2002.pdf >=20 > As a member of the technical community, we invite you to share your > experiences by participating in this important workshop. Workshop > participants will focus on the core privacy challenges, the approaches > taken to deal with them, and the status of the work in the field. The > objective is to draw a relationship with other application areas and > other privacy work in an effort to discuss how specific approaches can > be generalized. >=20 > Interested parties must submit a brief contribution describing their > work or approach as it relates to the workshop theme. We welcome > visionary ideas for how to tackle Internet privacy problems, as well = as > write-ups of existing concepts, deployed technologies, and > lessons-learned from successful or failed attempts at deploying = privacy > technologies. Contributions are not required to be original in = content. >=20 > Submitters of accepted position papers will be invited to the = workshop. > The workshop will be structured as a series of working sessions, > punctuated by invited speakers, who will present relevant background > information or controversial ideas that will motivate participants to > reach a deeper understanding of the subject. The organizing committee > may ask submitters of particularly topical papers to present their = ideas > and experiences to the workshop. >=20 > We will publish submitted position papers and slides together with a > summary report of the workshop. >=20 > There are no plans for any remote participation in this workshop. >=20 > To be invited to the workshop, please submit position papers to > privacy@iab.org by November, 5th 2010. >=20 > More detailed information about the workshop, including further = details > about the position paper requirements, is available at: > http://www.iab.org/about/workshops/privacy/ >=20 > We look forward to your input, > Bernard Aboba (IAB), Trent Adams (ISOC), Daniel Appelquist (W3C), = Karen > O'Donoghue (ISOC), Jon Peterson (IAB), Thomas Roessler (W3C), Karen > Sollins (MIT), Hannes Tschofenig (IAB) > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce