From turners@ieca.com Wed Oct 5 09:34:27 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3171F0C49 for ; Wed, 5 Oct 2011 09:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.277 X-Spam-Level: X-Spam-Status: No, score=-101.277 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_20=-0.74, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPqQ4hOVTmdq for ; Wed, 5 Oct 2011 09:34:27 -0700 (PDT) Received: from nm16.bullet.mail.sp2.yahoo.com (nm16.bullet.mail.sp2.yahoo.com [98.139.91.86]) by ietfa.amsl.com (Postfix) with SMTP id 62ED11F0C48 for ; Wed, 5 Oct 2011 09:34:27 -0700 (PDT) Received: from [98.139.91.61] by nm16.bullet.mail.sp2.yahoo.com with NNFMP; 05 Oct 2011 16:37:30 -0000 Received: from [98.139.91.14] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 05 Oct 2011 16:37:30 -0000 Received: from [127.0.0.1] by omp1014.mail.sp2.yahoo.com with NNFMP; 05 Oct 2011 16:37:30 -0000 X-Yahoo-Newman-Id: 839340.70081.bm@omp1014.mail.sp2.yahoo.com Received: (qmail 11048 invoked from network); 5 Oct 2011 16:37:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317832650; bh=n3OIDR7EowGRjp3KD6MNCfnL8Bm9jhD2vesVd67Ba9k=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=cqC1xrhw6Z5DJ/UQWSGztFwSi5fnc9cTKRYfySVSWnE+oH0TI45DqGEOi2pDQXGlaxfQwDuOGvRQP9t9EvEOdmYR6TlJ6MJPZY42aaDFS5xd/22N/3xz72ewCMfGBfYpHemuJC7APoDZYN6/xtIaCoxVgWCknEhshHGh29x5BAI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YnDHvUAVM1lvuc5_Ulkbxued3_EhduQgGPNCfWW40IgUw1k .kn7xtFzuVPdlfIhx0fchrLZp9UHeh0dao4cacldsO78y1w9FFPYiTNdTEby P7MHl7.rOc60G2BqcuYyW0fQfT9Yo2lv2k.tpcFApHX0uzh3Tax_ETCNYMhP MvF54gzWfUKL9rJJL_kGHm.UBzJF6bngRensForj.tAuS3eXKYUhMGsUms9l zUFK3wbaDzQgTNn6vbq7G2W6.pqRkdAItl8i8pf6AUSIq9KJEf9dXoz_f38B OKBwZKHnAY57PhkP06by6AFqQpE3KlSZwJnb9Gd1BG97TrOk8bqQHOdspJEV eq4XEapxOxuxdgHBRXtUEDqLqkIEt_0vnGYKQtOSilh3P3eQGEaVlFao_bsy 5JkZVFWoQWu0fgt9Q0Typ6rk3RaQCJ0G4SNc- X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@71.191.1.163 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 05 Oct 2011 09:37:30 -0700 PDT Message-ID: <4E8C87C9.1030801@ieca.com> Date: Wed, 05 Oct 2011 12:37:29 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: saag@ietf.org References: <4E675CA0.6090001@ieca.com> In-Reply-To: <4E675CA0.6090001@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Call for SAAG presentation topics for IETF 82 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 16:34:27 -0000 Sending out the call again. spt On 9/7/11 7:59 AM, Sean Turner wrote: > All, > > Stephen and I are putting together the SAAG agenda for Taipei. > > The agenda traditionally includes one or two invited presentations after > the working group reports. If you believe a topic would be of interest > to the community, then please suggest it to us. > > If you can identify an appropriate presenter (not necessarily yourself) > that would be helpful. > > Thanks, > > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From stpeter@stpeter.im Wed Oct 5 10:08:43 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A8121F8CDA for ; Wed, 5 Oct 2011 10:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvzgZzAPVMiK for ; Wed, 5 Oct 2011 10:08:43 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECDEE21F8CD9 for ; Wed, 5 Oct 2011 10:08:42 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E7184E84CC; Wed, 5 Oct 2011 11:16:06 -0600 (MDT) Message-ID: <4E8C8FD5.2070603@stpeter.im> Date: Wed, 05 Oct 2011 11:11:49 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sean Turner References: <4E675CA0.6090001@ieca.com> <4E8C87C9.1030801@ieca.com> In-Reply-To: <4E8C87C9.1030801@ieca.com> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Call for SAAG presentation topics for IETF 82 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:08:43 -0000 I'm still interested in getting feedback about internationalized passwords and draft-ietf-precis-framework. (Marc Blanchet and I will update I-D that before IETF 82 to incorporate feedback received on the SAAG list a while back, but I think we might need to present about this in person to gather more feedback.) On 10/5/11 10:37 AM, Sean Turner wrote: > Sending out the call again. > > spt > > On 9/7/11 7:59 AM, Sean Turner wrote: >> All, >> >> Stephen and I are putting together the SAAG agenda for Taipei. >> >> The agenda traditionally includes one or two invited presentations after >> the working group reports. If you believe a topic would be of interest >> to the community, then please suggest it to us. >> >> If you can identify an appropriate presenter (not necessarily yourself) >> that would be helpful. >> >> Thanks, >> >> spt >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> From Jeff.Hodges@KingsMountain.com Sat Oct 8 15:01:35 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD2D21F8B49 for ; Sat, 8 Oct 2011 15:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.144 X-Spam-Level: X-Spam-Status: No, score=-99.144 tagged_above=-999 required=5 tests=[AWL=-1.249, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQiacW+qIozq for ; Sat, 8 Oct 2011 15:01:34 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 92B6421F8B47 for ; Sat, 8 Oct 2011 15:01:34 -0700 (PDT) Received: (qmail 23431 invoked by uid 0); 8 Oct 2011 22:04:50 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 8 Oct 2011 22:04:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=JaCVpT8rCC+8QCAmYS72uNPWjM7NBsRmKGAfgIwPesU=; b=Czwn9RhNcGV+gtg/N8q+za5p5vZi9763nXQagio637S7VTH6hi+QLiaq6Giu0wZlGFm6lZPclhjavx4xiNCqZnH63cpISToNqgaznjIi6OuA7X0rVaVRY19uC4aDnrV4; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RCf0j-0006a5-VT for saag@ietf.org; Sat, 08 Oct 2011 16:04:50 -0600 Message-ID: <4E90C900.9060507@KingsMountain.com> Date: Sat, 08 Oct 2011 15:04:48 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: IETF Security Area Advisory Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [saag] fyi: Control System Cyber Security - State of the State X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 22:01:35 -0000 Of possible interest, this talk will be @stanford, most of the time the talks in this series are also webcast, see for details... Subject: [EE CS Colloq] Control System Cyber Security - State of the State * 4:15PM, Wed Oct 12, 2011 in Skilling Auditorium From: "Dennis Allison" Date: Thu, 6 Oct 2011 07:00:29 -0700 (PDT) To: colloq@cs.stanford.edu Stanford EE Computer Systems Colloquium 4:15PM, Wednesday, Oct 12, 2011 Skilling Auditorium, Stanford Campus http://ee380.stanford.edu[1] Topic: Control System Cyber Security - State of the State Speaker: Joe Weiss Applied Control Solutions, LLC About the talk: Industrial control systems are used in electric power, water, pipelines, etc. These systems were designed for performance and safety considerations, not security. Traditional IT security technologies, policies, and testing may not apply to these systems. Moreover, there is currently no university with an interdisciplinary program accross multiple engineering disciplines to address control system cyber security. There have already been more than 200 actual control system cyber incidents to date, though most have not been identified as cyber. In the US alone, there have been 4 control system cyber incidents that have killed people, 3 major cyber-related electric outages, 2 nuclear plants shut down from full power, etc. With the advent of Stuxnet, cyber has been introduced as an offensive weapon. The purpose of this presentation is to provide a state-of-the-state view of control system cyber security. Resources: Book: Joe Weiss, Protecting Industrial Control Systems from Electrionic Threats[2] CNN video: Idaho 'ground zero' in cyber-terror war[3] Slides: There is no downloadable version of the slides for this talk available at this time. About the speaker: (image) Joseph Weiss[4] is an industry expert on control systems and electronic security of control systems, with more than 35 years of experience in the energy industry. Mr. Weiss spent more than 14 years at the Electric Power Research Institute (EPRI) where he led a variety of programs including the Nuclear Plant Instrumentation and Diagnostics Program, the Fossil Plant Instrumentation & Controls Program, the Y2K Embedded Systems Program and, the cyber security for digital control systems. Contact information: Joe Weiss Applied Control Solutions, LLC (408) 253-7934 (408) 253-7974 Fax (408) 832-5396 Cell joe (dot) weiss (at) realtimeacss (dot) com http://www.realtimeacs.com[5] blog: http:www.controlglobal.com/unfettered[6] Book: http://www.momentumpress.net/books/protecting-industrial-control-systems-electronic-threats[7] Embedded Links: [ 1 ] http://ee380.stanford.edu [ 2 ] http://www.momentumpress.net/books/protecting-industrial-control-systems-electronic-threats [ 3 ] http://www.cnn.com/video/#/video/tech/2011/09/30/simon-point-click-destroy.cnn?iref=allsearch [ 4 ] http://ee380.stanford.edu/Abstracts/111012-extbio.html [ 5 ] http://www.realtimeacs.com [ 6 ] http://www.controlglobal.com/unfettered [ 7 ] http://www.momentumpress.net/books/protecting-industrial-control-systems-electronic-threats ABOUT THE COLLOQUIUM: See the Colloquium website, http://ee380.stanford.edu, for scheduled speakers, FAQ, and additional information. Stanford and SCPD students can enroll in EE380 for one unit of credit. Anyone is welcome to attend; talks are webcast live and archived for on-demand viewing over the web. WHERE IN THE WORLD IS SKILLING AUDITORIUM: The Colloquium meets in Skilling Auditorium on the Stanford Campus. A map to help you find Skilling Auditorium and parking can be found at http://ee380.stanford.edu/Skilling-Map.png. Parking in most lots is free and unrestricted after 4PM. MAILING LIST INFORMATION: This announcement is sent to multiple mailing lists. If you are signed up on our private EE380 list you can remove yourself using the widget at the upper left hand corner of the Colloquium web page. Other lists have other management protocols. From Jeff.Hodges@KingsMountain.com Sat Oct 8 15:06:59 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF3621F87E2 for ; Sat, 8 Oct 2011 15:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.978 X-Spam-Level: X-Spam-Status: No, score=-98.978 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTx1n2oFQ1sP for ; Sat, 8 Oct 2011 15:06:58 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id C2CDD21F8487 for ; Sat, 8 Oct 2011 15:06:58 -0700 (PDT) Received: (qmail 5365 invoked by uid 0); 8 Oct 2011 22:10:15 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 8 Oct 2011 22:10:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=X0dRpxjLpUsIEvU1uWRa3oNvN3wnlsgqwGE9oPec9gs=; b=QCwZh4HfqYgbyLok0GQ+dB2EUWTduqGT3ZOO/Y/if5FkdocCFWnFW9JpONzvKGLADjX2j/NeVtRkO5b4VwWJVfFPwo+Nifir20//DUDuyi8gtJF/8gAzHR97iZxyxRWc; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RCf5y-0002CX-UT; Sat, 08 Oct 2011 16:10:15 -0600 Message-ID: <4E90CA45.7000608@KingsMountain.com> Date: Sat, 08 Oct 2011 15:10:13 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: IETF Security Area Advisory Group , IETF Privacy discussion list , W3C Privacy Interest Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [saag] fyi: Smart Grid Security and Privacy, and a Case Example in AMI Networks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 22:06:59 -0000 of possible interest, this talk will be at Cal Berkeley... Subject: [Trustseminar] TRUST Seminar: Alvaro Cardenas, (TODAY) 10/6 - 1 = PM From: "Aimee Tabor" Date: Thu, 6 Oct 2011 11:48:00 -0700 To: , Description: Alvaro Cardenas Smart Grid Security and Privacy, and a Case Example in AMI Networks Alvaro Cardenas , Fujit= su Laboratories of America Thursday, October 6, 2011 at 1:00 PM Soda Hall, Wozniak Lounge Abstract. The smart grid refers to multiple efforts around the globe to modernize aging power grid infrastructures with new technologies, enablin= g a more intelligently networked automated system. The goal of a smart grid i= s to deliver energy with greater efficiency, reliability, security and prov= ide more transparency and choice, to electricity consumers. While the smart g= rid promises many benefits, it raises many new security and privacy challenge= s with its large-scale deployment of ubiquitous, remotely accessible networ= ked devices, and their fine-grained data collection. The first part of this talk will give a broad view on the security and privacy landscape of the industry and the current efforts by several grou= ps (like the NIST CSWG, NERC CIP, and state regulators) to secure it and som= e of the current gaps. The second part of the talk will focus on a security= study of smart meters and propose attack-detection countermeasures by tim= e series analysis of smart meter data. Alvaro Cardenas is a research staff engineer at Fujitsu Laboratories of America. His research focuses on smart grid, machine learning and statistical methods applied to security, cyber-physical systems security = and wireless communications for embedded systems and the Internet of Things. = He has received numerous awards for his research including a best paper awar= d from the U.S. Army Research Office, a best presentation award from the IE= EE, a fellowship from the University of Maryland, and a Distinguished Assistantship from the Institute of Systems Research. Alvaro holds M.S. a= nd Ph.D. degrees from the University of Maryland, College Park, and a B.S. f= rom Universidad de los Andes. He was a postdoctoral fellow at the University = of California, Berkeley before joining Fujitsu Labs. He was also an invited visiting professor at the University of Cagliari. ---- Aim=E9e Tabor Program Manager TRUST Science & Technology Center 337 E Cory Hall Berkeley, CA 94720-1774 Phone: (510) 643-5883 Fax: (510) 642-2718 www.truststc.org From turners@ieca.com Wed Oct 12 19:57:06 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BB121F8C22 for ; Wed, 12 Oct 2011 19:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.723 X-Spam-Level: X-Spam-Status: No, score=-102.723 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYKCLpueCqFv for ; Wed, 12 Oct 2011 19:57:05 -0700 (PDT) Received: from nm30-vm0.access.bullet.mail.mud.yahoo.com (nm30-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.86]) by ietfa.amsl.com (Postfix) with SMTP id 647D721F8C1A for ; Wed, 12 Oct 2011 19:57:05 -0700 (PDT) Received: from [66.94.237.195] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2011 02:57:02 -0000 Received: from [98.139.221.60] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 13 Oct 2011 02:57:02 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 13 Oct 2011 02:57:02 -0000 X-Yahoo-Newman-Id: 585793.18063.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: vzAWcQgVM1kt.6gmHLOpuAFqWdRmN8lLCZl_B.Hyg.sPSI9 jE9LWQWGqPMRb4OWbkejCeX2agxPgiV9NNQV0KKYotlPjsM.2tj.x2Vfh4Z8 Fc4IIHT4YJPbEN8RCv44q0pwTh9d6b75wWFJB1iBiKsFR3_DlDmWj1hj9UEW q6E4uZocbnemk5xBxKyLp4jX1VQEnRfR0rmKxpBJ_05d5jZjWdHAg6ZfE70U aF_EHUPfpH4MPk2meFDy2UgNjDRapefrpSFeato9iFje8tQjMqgUQuTR4rJD mjIVg6VY_9psXOWy3rgeSh9NEfj9JKsbktAxrQk98BBVhGyTAOGoQa8_R767 MoEiyr.eTw6MjDtTU66nKZ_bC7dLjIY6dXTP8uARq9iUYG2LV0qZq9J1Gl2F f.OuQGhojYqQ7gmFc2iKun63bWaIh X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@71.191.1.163 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 12 Oct 2011 19:57:02 -0700 PDT Message-ID: <4E96537D.3050408@ieca.com> Date: Wed, 12 Oct 2011 22:57:01 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: saag@ietf.org References: <20111011162608.90A4A21F8E1F@ietfa.amsl.com> In-Reply-To: <20111011162608.90A4A21F8E1F@ietfa.amsl.com> X-Forwarded-Message-Id: <20111011162608.90A4A21F8E1F@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: WG Review: Managed Incident Lightweight Exchange (mile) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 02:57:06 -0000 FYI ... -------- Original Message -------- Subject: WG Review: Managed Incident Lightweight Exchange (mile) Date: Tue, 11 Oct 2011 09:26:08 -0700 (PDT) From: IESG Secretary Reply-To: iesg@ietf.org To: IETF Announcement list CC: mile@ietf.org A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, October 18, 2011. Managed Incident Lightweight Exchange (mile) -------------------------------------------- Status: Proposed Working Group Charter Last Updated: 2011-09-21 Chairs: TBD Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing Lists: General Discussion: mile@ietf.org To Subscribe: http://www.ietf.org/mailman/listinfo/mile Archive: http://www.ietf.org/mail-archive/web/mile Description: The Managed Incident Lightweight Exchange (MILE) working group will develop standards and extensions for the purpose of improving incident information sharing and handling capabilities based on the work developed in the IETF Extended INCident Handling (INCH) working group. The Incident Object Description Exchange Format (IODEF) in RFC5070 and Real-time Inter-network Defense (RID) in RFC6045 were developed in the INCH working group by international Computer Security Incident Response Teams (CSIRTs) and industry to meet the needs of a global community interested in sharing, handling, and exchanging incident information. The extensions and guidance created by the MILE working group assists with the daily operations of CSIRTs at an organization, service provider, law enforcement, and at the country level. The application of IODEF and RID to interdomain incident information cooperative exchange and sharing has recently expanded and the need for extensions has become more important. Efforts continue to deploy IODEF and RID, as well as to extend them to support specific use cases covering reporting and mitigation of current threats such as anti-phishing extensions. An incident could be a benign configuration issue, IT incident, an infraction to a service level agreement (SLA), a system compromise, socially engineered phishing attack, or a denial-of-service (DoS) attack, etc. When an incident is detected, the response may include simply filing a report, notification to the source of the incident, a request to a third party for resolution/mitigation, or a request to locate the source. IODEF defines a data representation that provides a standard format for sharing information commonly exchanged about computer security incidents. RID enables the secure exchange of incident related information in an IODEF format providing options for security, privacy, and policy setting. MILE leverages collaboration and sharing experiences with the work developed in the INCH working group which includes the data model detailed in the IODEF, existing extensions to the IODEF for Anti-phishing (RFC5901), and RID (RFC6045, RFC6046) for the secure exchange of information. MILE will also leverage the experience gained in using IODEF and RID in operational contexts. Related work, drafted outside of INCH will also be reviewed and includes RFC5941, Sharing Transaction Fraud Data. The MILE working group provides coordination for these various extension efforts to improve the capabilities for exchanging incident information. MILE has several objectives with the first being a description a subset of IODEF focused on ease of deployment and applicability to current information security data sharing use cases. MILE also describes a generalization of RID for secure exchange of other security-relevant XML formats. MILE produces additional guidance needed for the successful exchange of incident information for new use cases according to policy, security, and privacy requirements. Finally, MILE produces a document template with guidance for defining IODEF extensions to be followed when producing extensions to IODEF as appropriate, for: * labeling incident reports with data protection, data retention, and other policies, regulations, and laws restricting the handling of those reports * referencing structured security information from within incident reports * reporting forensic data generated during an incident investigation (computer or accounting) The WG will produce the following: * An informational document on IODEF Guidance. * A Standards Track document specifying the Real-time Inter-network Defense (RID). * A Standards Track document specifying the transport for RID. * An informational template for extensions to IODEF. * A Standards Track document for IODEF Extensions in IANA XML Registry. * A Standards Track document for IODEF Extension to support structured cybersecurity information. * A Standards Track document for Labeling for data protection, retention, policies, and regulations. * A Standards Track document for GRC Report Exchange. * A Standards Track document for IODEF Extension to support forensics. The drafts under consideration as WG items include: * Real-time Inter-network Defense (RID) bis: draft-moriarty-mile-rfc6045-bis-01 * Transport of Real-time Inter-network Defense (RID) Messages bis: draft-trammell-mile-rfc6046-bis-00 * Template for extensions to IODEF: draft-trammell-mile-template-01.txt * IODEF Extensions in IANA XML Registry: draft-trammell-mile-iodef-xmlreg-00.txt * GRC Report Exchange (Generalized RID for XML reports/documents): draft-moriarty-mile-grc-exchange-00.txt * IODEF-extension to support structured cybersecurity information: draft-takahashi-mile-sci-00.txt Milestones WGLC = Working Group Last Call 2011-11 - WGLC Real-time Inter-network Defense (RID) 2011-11 - WGLC Transport for Real-time Inter-network Defense (RID) 2011-12 - Submit Real-time Inter-network Defense (RID) to IESG for consideration as Standards Track document 2011-12 - Submit Transport Real-time Inter-network Defense (RID) to IESG for consideration as Standards Track document 2011-12 - WGLC Template for extensions to IODEF 2011-12 - WGLC IODEF Extensions in IANA XML Registry 2011-12 - WGLC IODEF Extension to support structured cybersecurity information 2012-02 - Submit Template for extensions to IODEF to IESG for consideration as Informational document 2012-02 - Submit IODEF Extensions in IANA XML Registry to IESG for consideration as Standards Track document 2012-02 - Submit IODEF Extension to support structured cybersecurity information to IESG for consideration as Standards Track document 2012-03 - WGLC IODEF Extension Labeling for data protection, retention, policies, and regulations 2012-03 - WGLC IODEF Guidance 2012-04 - Submit IODEF Extension Labeling for data protection, retention, policies, and regulations to IESG for consideration as Standards Track document 2012-04 - Submit WGLC IODEF Guidance to IESG for consideration as Informational document 2012-05 - WGLC GRC Report Exchange 2012-06 - Submit GRC Report Exchange to IESG for consideration as Standards Track document 2012-06 - WGLC Forensics extension 2012-07 - Submit IODEF Forensics extension to IESG for consideration as Standards Track document _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From openpgp@brainhub.org Thu Oct 13 17:42:51 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4546921F8AD6 for ; Thu, 13 Oct 2011 17:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKsx2-u3-yl3 for ; Thu, 13 Oct 2011 17:42:50 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id B8F9821F8AC9 for ; Thu, 13 Oct 2011 17:42:50 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta10.emeryville.ca.mail.comcast.net with comcast id kQeE1h0021u4NiLAAQijns; Fri, 14 Oct 2011 00:42:43 +0000 Received: from [127.0.0.1] ([98.234.252.65]) by omta21.emeryville.ca.mail.comcast.net with comcast id kQqX1h00F1RRS8a8hQqX66; Fri, 14 Oct 2011 00:50:32 +0000 Message-ID: <4E964FA6.1070206@brainhub.org> Date: Wed, 12 Oct 2011 19:40:38 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Standardizing NSA Suite B public key algorithms (Elliptic curve NIST curves) with OpenPGP format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:43:36 -0000 Hello SAAG, May I ask for an advice on what is the best way to advance a personal draft into an IETF standard? Here is the latest version of the draft: http://www.ietf.org/id/draft-jivsov-openpgp-ecc-08.txt . Please refer to http://sites.google.com/site/brainhub/pgp for up-to-date details. There are now two inter-operable implementation from different code base that implement this format, for example, GnuPG 2.1.0 beta. The major design goal of the document was simplicity. ECDSA is straighforward and maps trivially to what was already defined for DSA over modp field. Encryption capability needed new format definitions to comply with NIST-blessed guidelines. As a result, the document uses ECDH per SP800-56A with AES WRAP. I believe that all described methods in the document are in public domain. It would be great if an AD would help with sponsoring this document. Any comment is appreciated. Thank you in advance. From ynir@checkpoint.com Thu Oct 13 22:08:13 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8488221F8C26 for ; Thu, 13 Oct 2011 22:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLX319m54u+d for ; Thu, 13 Oct 2011 22:08:12 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 26F5B21F8C0F for ; Thu, 13 Oct 2011 22:08:11 -0700 (PDT) X-CheckPoint: {4E97C381-10002-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p9E57nJ0025305; Fri, 14 Oct 2011 07:08:08 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 14 Oct 2011 07:07:49 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 14 Oct 2011 07:07:50 +0200 From: Yoav Nir To: Andrey Jivsov , "saag@ietf.org" Date: Fri, 14 Oct 2011 07:07:47 +0200 Thread-Topic: [saag] Standardizing NSA Suite B public key algorithms (Elliptic curve NIST curves) with OpenPGP format Thread-Index: AcyKLzfwZI7+tAH5QvaBDsf15uLDeg== Message-ID: In-Reply-To: <4E964FA6.1070206@brainhub.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [saag] Standardizing NSA Suite B public key algorithms (Elliptic curve NIST curves) with OpenPGP format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 05:08:13 -0000 Hi Andrey. The best way is to contact one of the security ADs (Sean Turner or Stephen Farrell) and ask for this to more forward as an individual submission. Hope this helps Yoav On 10/13/11 4:40 AM, "Andrey Jivsov" wrote: >Hello SAAG, > >May I ask for an advice on what is the best way to advance a personal >draft into an IETF standard? > >Here is the latest version of the draft: >http://www.ietf.org/id/draft-jivsov-openpgp-ecc-08.txt . Please refer to >http://sites.google.com/site/brainhub/pgp for up-to-date details. > >There are now two inter-operable implementation from different code base >that implement this format, for example, GnuPG 2.1.0 beta. > >The major design goal of the document was simplicity. ECDSA is >straighforward and maps trivially to what was already defined for DSA >over modp field. Encryption capability needed new format definitions to >comply with NIST-blessed guidelines. As a result, the document uses ECDH >per SP800-56A with AES WRAP. I believe that all described methods in the >document are in public domain. > >It would be great if an AD would help with sponsoring this document. > >Any comment is appreciated. Thank you in advance. >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag > >Scanned by Check Point Total Security Gateway. From rstruik.ext@gmail.com Fri Oct 14 13:55:20 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0280C21F8D55 for ; Fri, 14 Oct 2011 13:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBw5i57AFYAI for ; Fri, 14 Oct 2011 13:55:19 -0700 (PDT) Received: from mail-yx0-f179.google.com (mail-yx0-f179.google.com [209.85.213.179]) by ietfa.amsl.com (Postfix) with ESMTP id 269AA21F8D51 for ; Fri, 14 Oct 2011 13:55:19 -0700 (PDT) Received: by yxn35 with SMTP id 35so1517741yxn.38 for ; Fri, 14 Oct 2011 13:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=Up+/6nh2hHW1K2PcK+/mhdiDNJGHKhZLulLVNCU7oRY=; b=AxB0kW782rJSk5nPYfSBy4wdrpFcnhnJz0+46WeUS1+updMTBJf1OOP103I3UjuM4C lTwgZxeFLYC/g3xDfW2HuFE4VDQZ59rKsgt+KiVSImaxrllxWxj/Pgm1MQQ1v0o69KYs oRv1bzGYoaUOHo5/4mqiLGVZhisAadb4Aw6RU= Received: by 10.150.164.17 with SMTP id m17mr10178283ybe.4.1318625718383; Fri, 14 Oct 2011 13:55:18 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id a2sm12695909ank.3.2011.10.14.13.55.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 14 Oct 2011 13:55:17 -0700 (PDT) Message-ID: <4E98A1A6.2000804@gmail.com> Date: Fri, 14 Oct 2011 16:55:02 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Andrey Jivsov References: <4E964FA6.1070206@brainhub.org> In-Reply-To: <4E964FA6.1070206@brainhub.org> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Standardizing NSA Suite B public key algorithms (Elliptic curve NIST curves) with OpenPGP format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 20:55:20 -0000 Hi Andrey: I had a quick look at your draft ; please see my preliminary notes below. I hope this helps. Best regards, Rene == Comments on draft-jivsov-openpgp-ecc-08: Clause 6 (conversion routines): (T-1) This clause suggests a fixed format for octet representation of elliptic curve points (l. 8), thus hampering future extensibility (suggested in the last para). Moreover, this seems to conflict the format in SEC1 (since there if B0 = 0x00, then one has the point at infinity). I would suggest specifying the format B0 || x || y only if the leftmost octet B0 is the octet 0x04 (affine point representation) and leaving other options for B0 (bar 0x00, 0x02, 0x03) for future extensibility (the exception set corresponding to point at infinity (0x00), resp. compressed points (0x02, 0x03), as defined in SEC1). (T-2) The remark on extensibility (last para) seems to suggest forward compatibility (which more or less kills extensibility prospects). Wouldn't the proper approach be that one parses the string B0 || .... and then simply rejects unrecognized B0 values. With the specification here this would mean that one rejects the representation if the leftmost octet is not equal to the string 0x04. This is a far less harsh requirement on getting a foot in the door with potentially new conversions, while not hampering proper operation at all. (E-3) The encoding of elliptic curve points is an octet encoding, so the output size would be in units of octets. Thus, B0 || x || y has octet size 2*octet size of the underlying field + 1 (for B0=0x04). The text suggests 2*curve size + 3 bits, which is not an integer number of octets; moreover, the curve size (more accurately, the octet size of the curve) is not necessarily the same as the octet size of the underlying field. (With NIST prime curves P-256, P-384, P-521 it is, since #E(Fp) < p and p is just smaller than a power of two, but generally this may not be the case.) Clause 7 (key derivation function): (T-4) The suggested kdf format does not seem to entirely satisfy the requirements stipulated with NIST SP 800-56a, Section 5.8.1: there, the kdf has the format kdf(Z, keydatalen, OtherInfo), where Z is the x-coordinate of the ECDH key, keydatalen the size of the shared key, and the OtherInfo element includes {Algorithm Id, PartyUInfo, PartyVInfo}, where PartyUInfo and PartyVInfo explicitly includes the Ids of the correspondents engaged in the key agreement scheme (see 800-56a, Section 5.8.1, (3.3) and (3.4)). With the kdf in the draft, PartyUInfo seems to be independent of the sender (since set to "anonymous"), whereas PartyVInfo is set to a key "fingerprint" (as I distilled from Clause 8). Moreover, with the draft, Z seems to be set to the (x,y) coordinates of the computed ECDH key, although - admittedly, it may be the x-coordinate only {the pseudo-code of Clause 7 refers to P for both the key P:=(x,y) and for "parameters", which is ambiguous}. Since the x-coordinate of the ECDH key K:= a(Qb) = b(Qa) does not require the y-coordinate of inputs Qb or Qa, it would be a pity if one would just need that as input to the kdf, without much benefit (after all, the y-coordinate only adds 1 bit of entropy here). I presume this confusion is just caused by ambiguity in the text and could easily be taken away. Clause 8 (ECDH): (E-5) With the 2nd para, it is suggested that ECDH (or: C(1,1, ECC CDH)) in NIST SP 800-56a is modified, to always assume that the co-factor h of the curve always assumes the value h=-1. This does not seem a modification at all, since the only curves defined with this draft are the NIST prime curves P-256, P-384, and P-521, which do have h=1. Thus, any instantiation of the draft with the specified curves leaves the NIST SP 800-56a as is. (E-6) Third bullet, l. 2: replace "the corresponding filed" by "the corresponding field". (T-7) Third bullet, last sub-bullet: shouldn't the size of the fingerprint be consistent with the cryptographic key strength? (e.g., for top secret info (Clause 12.2.2), one would have a 384-bit fingerprint, rather than a 160-bit entry). Clause 9 (Encoding of Public and Private Keys) I presume the hash function Id and the algorithm Id are specified elsewhere (could not immediately find those). == On 12/10/2011 10:40 PM, Andrey Jivsov wrote: > Hello SAAG, > > May I ask for an advice on what is the best way to advance a personal > draft into an IETF standard? > > Here is the latest version of the draft: > http://www.ietf.org/id/draft-jivsov-openpgp-ecc-08.txt . Please refer > to http://sites.google.com/site/brainhub/pgp for up-to-date details. > > There are now two inter-operable implementation from different code > base that implement this format, for example, GnuPG 2.1.0 beta. > > The major design goal of the document was simplicity. ECDSA is > straighforward and maps trivially to what was already defined for DSA > over modp field. Encryption capability needed new format definitions > to comply with NIST-blessed guidelines. As a result, the document uses > ECDH per SP800-56A with AES WRAP. I believe that all described methods > in the document are in public domain. > > It would be great if an AD would help with sponsoring this document. > > Any comment is appreciated. Thank you in advance. > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 From openpgp@brainhub.org Fri Oct 14 16:16:27 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6BD21F8B3E for ; Fri, 14 Oct 2011 16:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=-1.549, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, FRT_BELOW2=2.154, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4sGb2AQ84F1 for ; Fri, 14 Oct 2011 16:16:26 -0700 (PDT) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6321F8B77 for ; Fri, 14 Oct 2011 16:16:26 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta04.emeryville.ca.mail.comcast.net with comcast id km5F1h0071Y3wxoA4nGAHb; Fri, 14 Oct 2011 23:16:10 +0000 Received: from [127.0.0.1] ([98.234.252.65]) by omta15.emeryville.ca.mail.comcast.net with comcast id knP01h00N1RRS8a8bnP1uU; Fri, 14 Oct 2011 23:23:01 +0000 Message-ID: <4E9819F2.5010401@brainhub.org> Date: Fri, 14 Oct 2011 04:16:02 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 MIME-Version: 1.0 To: Rene Struik References: <4E964FA6.1070206@brainhub.org> <4E98A1A6.2000804@gmail.com> In-Reply-To: <4E98A1A6.2000804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Standardizing NSA Suite B public key algorithms (Elliptic curve NIST curves) with OpenPGP format X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 23:16:27 -0000 Hello Rene. Thank you for your comments. On 10/14/2011 01:55 PM, Rene Struik wrote: > Hi Andrey: > > I had a quick look at your draft ; please see my preliminary notes > below. I hope this helps. > > Best regards, Rene > > == > > Comments on draft-jivsov-openpgp-ecc-08: > > Clause 6 (conversion routines): > > (T-1) This clause suggests a fixed format for octet representation of > elliptic curve points (l. 8), thus hampering future extensibility > (suggested in the last para). Moreover, this seems to conflict the > format in SEC1 (since there if B0 = 0x00, then one has the point at > infinity). I would suggest specifying the format B0 || x || y only if > the leftmost octet B0 is the octet 0x04 (affine point representation) > and leaving other options for B0 (bar 0x00, 0x02, 0x03) for future > extensibility (the exception set corresponding to point at infinity > (0x00), resp. compressed points (0x02, 0x03), as defined in SEC1). I could not identify a conflict. The draft says to use uncompressed version with the tag value 0x04. > > (T-2) The remark on extensibility (last para) seems to suggest forward > compatibility (which more or less kills extensibility prospects). > Wouldn't the proper approach be that one parses the string B0 || .... > and then simply rejects unrecognized B0 values. With the specification > here this would mean that one rejects the representation if the leftmost > octet is not equal to the string 0x04. This is a far less harsh > requirement on getting a foot in the door with potentially new > conversions, while not hampering proper operation at all. > The draft doesn't prohibit other values. An application that implements the draft need only support the uncompressed point. This is the easiest route to establish inter-operability base. A future companion RFC can define other storage-efficient format. What this future storage-efficient format will be is yet unclear. In the context of OpenPGP the storage efficiency is most beneficial with encrypted messages (which can have multiple recipients). It's more acceptable to have slightly larger public keys. ECDSA signatures don't contain points. This leaves us with ECDH as the most relevant target. There is a method noted in 1985 by Miller for ECDH, documented in RFC6090, that doesn't require any compression. It simply irrecoverably drops the y coordinate. Given that OpenPGP ECC draft, per NIST guideline, uses only x coordinate to calculate the shared secret, this method offers another alternative you didn't mention for storage efficiency. In this case B0 is neither 0x2 nor 0x3, although it can be fixed at any some of these values for inter-operability. In any case, this is a subject for another document. > (E-3) The encoding of elliptic curve points is an octet encoding, so the > output size would be in units of octets. Thus, B0 || x || y has octet > size 2*octet size of the underlying field + 1 (for B0=0x04). The text > suggests 2*curve size + 3 bits, which is not an integer number of > octets; moreover, the curve size (more accurately, the octet size of the > curve) is not necessarily the same as the octet size of the underlying > field. (With NIST prime curves P-256, P-384, P-521 it is, since #E(Fp)< > p and p is just smaller than a power of two, but generally this may not > be the case.) OpenPGP MPI size encoding counts in bits, not bytes. Binary representation of 0x04 adds 3 bits. The following is a point representation: MPI_HEADER 4 x y MPI_HEADER occupies 2 bytes and contains the size of the following large integer in bits, which highest octet is 04. Thank you for pointing the concern for the underlying filed v.s. curve size. Since OpenPGP RFC 4880 is a storage format (as opposed to a policy), by curve size I meant the underlying field size, i.e. the size needed to store an x or an y. I will review the document for consistency in this respect. So far the interest in OpenPGP community was for NIST Suite B curves and German Brainpool curves. For there uses the terms are essentially synonyms. > > Clause 7 (key derivation function): > > (T-4) The suggested kdf format does not seem to entirely satisfy the > requirements stipulated with NIST SP 800-56a, Section 5.8.1: there, the > kdf has the format > kdf(Z, keydatalen, OtherInfo), where Z is the x-coordinate of the ECDH > key, keydatalen the size of the shared key, and the OtherInfo element > includes {Algorithm Id, PartyUInfo, PartyVInfo}, where PartyUInfo and > PartyVInfo explicitly includes the Ids of the correspondents engaged in > the key agreement scheme (see 800-56a, Section 5.8.1, (3.3) and (3.4)). > > With the kdf in the draft, PartyUInfo seems to be independent of the > sender (since set to "anonymous"), whereas PartyVInfo is set to a key > "fingerprint" (as I distilled from Clause 8). The key's fingerprint is the identity in OpenPGP. This is what identifies a recipient. A fingerprint is what binds a signer to a signed message. An OpenPGP key typically contains multiple UserIDs (one per e-mail address), but they are not bound to a signed message. Same with public key certifications. Anonymous encryption is a typical use of OpenPGP. Messages can be further signed, but the encryption is anonymous. In the context of a DH scheme with a static recipient key and an ephemeral sender's key, one can argue that the recipient is communicating with an Anonymous sender. There is no expectation of origin authentication with encrypted-only messages in OpenPGP. As a practical matter, requiring sender binding in OpenPGP encryption will be difficult to achieve in practice. Users/automated agents may have multiple keys on their local keyrings and requiring them to select a key will not fit into variety of application use models. Users/automated agents, when acting as senders, may have no keys at all. In fact, the sender's identity as defined in SP 800-56a is not cryptographically proven, allowing no more security than simply putting "Anonymous" as a sender. > Moreover, with the draft, > Z seems to be set to the (x,y) coordinates of the computed ECDH key, > although - admittedly, it may be the x-coordinate only {the pseudo-code > of Clause 7 refers to P for both the key P:=(x,y) and for "parameters", > which is ambiguous}. > > Since the x-coordinate of the ECDH key K:= a(Qb) = b(Qa) does not > require the y-coordinate of inputs Qb or Qa, it would be a pity if one > would just need that as input to the kdf, without much benefit (after > all, the y-coordinate only adds 1 bit of entropy here). I presume this > confusion is just caused by ambiguity in the text and could easily be > taken away. > Only x contributes to the shared key. Section 7 defines the KDF. It contains the text "extract the x portion from". > Clause 8 (ECDH): > > (E-5) With the 2nd para, it is suggested that ECDH (or: C(1,1, ECC CDH)) > in NIST SP 800-56a is modified, to always assume that the co-factor h of > the curve always assumes the value h=-1. This does not seem a > modification at all, since the only curves defined with this draft are > the NIST prime curves P-256, P-384, and P-521, which do have h=1. Thus, > any instantiation of the draft with the specified curves leaves the NIST > SP 800-56a as is. One of reasons for this is that by fixing the co-factors at 1 this document signals to the applications to not worry about cofactor-related attacks and the difference in on-the-wire format for cofactor != 1. > (E-6) Third bullet, l. 2: replace "the corresponding filed" by "the > corresponding field". Thank you, noted. > > (T-7) Third bullet, last sub-bullet: shouldn't the size of the > fingerprint be consistent with the cryptographic key strength? (e.g., > for top secret info (Clause 12.2.2), one would have a 384-bit > fingerprint, rather than a 160-bit entry). Fingerprints are hardwired to be SHA-1 in OpenPGP. (SHA-1 is bellow the minimum requirement of the draft) > > Clause 9 (Encoding of Public and Private Keys) > > I presume the hash function Id and the algorithm Id are specified > elsewhere (could not immediately find those). These IDs are from the main document, OpenPGP RFC4880. This draft request ID 18 for ECDH. 19 was already reserved for ECDSA, and this draft uses the 19 with the ECDSA public key format. We are not aware of any deployed applications that were using ID 19 before. Thank you. > > == > > On 12/10/2011 10:40 PM, Andrey Jivsov wrote: >> Hello SAAG, >> >> May I ask for an advice on what is the best way to advance a personal >> draft into an IETF standard? >> >> Here is the latest version of the draft: >> http://www.ietf.org/id/draft-jivsov-openpgp-ecc-08.txt . Please refer >> to http://sites.google.com/site/brainhub/pgp for up-to-date details. >> >> There are now two inter-operable implementation from different code >> base that implement this format, for example, GnuPG 2.1.0 beta. >> >> The major design goal of the document was simplicity. ECDSA is >> straighforward and maps trivially to what was already defined for DSA >> over modp field. Encryption capability needed new format definitions >> to comply with NIST-blessed guidelines. As a result, the document uses >> ECDH per SP800-56A with AES WRAP. I believe that all described methods >> in the document are in public domain. >> >> It would be great if an AD would help with sponsoring this document. >> >> Any comment is appreciated. Thank you in advance. >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > From stpeter@stpeter.im Tue Oct 18 10:51:43 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9F421F8B8C for ; Tue, 18 Oct 2011 10:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.801 X-Spam-Level: X-Spam-Status: No, score=-102.801 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoePCuM1oyU6 for ; Tue, 18 Oct 2011 10:51:41 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5F10921F8B3F for ; Tue, 18 Oct 2011 10:51:41 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 62D5641E49; Tue, 18 Oct 2011 11:56:34 -0600 (MDT) Message-ID: <4E9DBCAC.90009@stpeter.im> Date: Tue, 18 Oct 2011 11:51:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Mouse References: <4E6682A9.5030002@stpeter.im> <4E668AE5.7080700@gmail.com> <4E668FC2.6080809@stpeter.im> <201109070445.AAA23563@Sparkle.Rodents-Montreal.ORG> In-Reply-To: <201109070445.AAA23563@Sparkle.Rodents-Montreal.ORG> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] internationalized passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:51:43 -0000 On 9/6/11 10:45 PM, Mouse wrote: >>> it's quite obvious to me that Unicode must be supported. >> I'm happy to hear it. :) > > I'm not entirely clear what the context here is, but you might want to > at least consider that you'd be repeating the ssh mistake if you make > this a MUST. (ssh, as specified, is unimplementable on some Unix > variants, and quite possibly other OSes, because some things which the > RFCs say MUST be in UTF-8, such as usernames or passwords, exist in the > system as octet strings rather than character strings and thus > inherently cannot be recoded. That ssh comes as close to working as it > does is a testament to ASCII's ubiquity.) As I see it, the PRECIS WG is not mandating, and could not mandate, that any given application technology MUST support non-ASCII passwords. Instead, it's giving protocol designers a common tool for preparing and comparing passwords (and other strings) containing Unicode characters, if they choose to support such things. Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Tue Oct 18 12:42:51 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7B21F8DD0 for ; Tue, 18 Oct 2011 12:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmEPrCpdWKvg for ; Tue, 18 Oct 2011 12:42:50 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2521F8DCE for ; Tue, 18 Oct 2011 12:42:49 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id C61B42F4081 for ; Tue, 18 Oct 2011 12:42:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=A+xWxP/gw2QDSRiPvWuK8 IS+5K8DRPRLsrpPDEvGvz2Fg+6LLQNRbvLKkaeXFPfMTyiFlFZannfESFIkNQxRd Q6HZ+1qwSXv3zEM8gy2MtOqo7mHiwnATZzEYXw9ZR3cBmxRqOD/5/hmiKmmDRm1n VXsrx637qhytBzjwt1L8Vw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=JDQVakmM13IC131PF2K2 li8IxfM=; b=GaNk6KMh6PPMQtWVjq370q5AW7GziTBFMW0KwjPo//vD7c0lyLxI X93y1BlhLUOZs7HHRvcqfN2r4W960BPbcSIbWBhMYXSHdRJ69smqXeLkiy6gbQsw /3smA/MYPdoIHrplEiUfnEiqQnNVROrSXnRjmzqT1cPSFWhz2Yn6fH0= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id A373D2F408E for ; Tue, 18 Oct 2011 12:42:04 -0700 (PDT) Received: by pzk34 with SMTP id 34so2499366pzk.9 for ; Tue, 18 Oct 2011 12:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr1872188pbj.92.1318966923112; Tue, 18 Oct 2011 12:42:03 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:42:03 -0700 (PDT) In-Reply-To: <4E668AE5.7080700@gmail.com> References: <4E6682A9.5030002@stpeter.im> <4E668AE5.7080700@gmail.com> Date: Tue, 18 Oct 2011 14:42:03 -0500 Message-ID: From: Nico Williams To: Yaron Sheffer Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] internationalized passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:42:51 -0000 On Tue, Sep 6, 2011 at 4:04 PM, Yaron Sheffer wrote: > it's quite obvious to me that Unicode must be supported. Agreed. I think it will be a long time yet before users can reliably enter non-ASCII passwords on all their operating systems and applications on all their devices. But that's no reason not to specify how compliant implementations would achieve this. Nico -- From nico@cryptonector.com Tue Oct 18 12:47:33 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C9321F8DAC for ; Tue, 18 Oct 2011 12:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ne-zSFVXtxHb for ; Tue, 18 Oct 2011 12:47:32 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 9318F21F8D87 for ; Tue, 18 Oct 2011 12:47:32 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 29BB58806B for ; Tue, 18 Oct 2011 12:47:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=pPZDD+NEujEVXxPYuTH7raqVpQgMucdPMehyIGYUpMwp bA+hbGv08kmzK3xYkA+fjlH3slcqrxdAC+/3bomLnwdqOQ24kjsV1IBEPy3Bnp1h 1WQCUrdgLZfuAZrOTQWgyHFb8Aioj6jYVTetfX7xwZYdDiUchIeTU55fXU4OKtM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=IAVD7HXTow99t2CsmuNMlptuB6o=; b=P49eyOs1BbB c8uXveaz/4i2fA79O0eC39+i7edm6S6+Rje1p9luAvNh9VAwefOP2EeSG8pOUF6B WemtelgRh4Ti87BV5D7/ZDUwU8JElAt6U6lMmO9YqyXmUQo6iYoRtyxpwzZB5b4Y DEFidtlSUgmegrEh1wT1V7e5ykZ19VKU= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPSA id 0F75F88063 for ; Tue, 18 Oct 2011 12:47:32 -0700 (PDT) Received: by pzk34 with SMTP id 34so2510903pzk.9 for ; Tue, 18 Oct 2011 12:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.24.200 with SMTP id w8mr6965492pbf.109.1318967251709; Tue, 18 Oct 2011 12:47:31 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:47:31 -0700 (PDT) In-Reply-To: <201109070445.AAA23563@Sparkle.Rodents-Montreal.ORG> References: <4E6682A9.5030002@stpeter.im> <4E668AE5.7080700@gmail.com> <4E668FC2.6080809@stpeter.im> <201109070445.AAA23563@Sparkle.Rodents-Montreal.ORG> Date: Tue, 18 Oct 2011 14:47:31 -0500 Message-ID: From: Nico Williams To: Mouse Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] internationalized passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:47:33 -0000 On Tue, Sep 6, 2011 at 11:45 PM, Mouse wrote: >>> it's quite obvious to me that Unicode must be supported. >> I'm happy to hear it. :) > > I'm not entirely clear what the context here is, but you might want to > at least consider that you'd be repeating the ssh mistake if you make > this a MUST. =C2=A0(ssh, as specified, is unimplementable on some Unix > variants, and quite possibly other OSes, because some things which the > RFCs say MUST be in UTF-8, such as usernames or passwords, exist in the > system as octet strings rather than character strings and thus > inherently cannot be recoded. =C2=A0That ssh comes as close to working as= it > does is a testament to ASCII's ubiquity.) I see nothing wrong with a protocol spec saying that passwords MUST be UTF-8 with such and such processing. Sure, some implementations will fail to comply, but applications that cannot handle Unicode as specified should a) just never allow non-ASCII passwords to be set, b) otherwise just-use-8 (so as to help interop, if accidentally, with implementations that do support Unicode as specified and where users have non-ASCII passwords set. Nico -- From nico@cryptonector.com Tue Oct 18 12:52:26 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050F021F8D49 for ; Tue, 18 Oct 2011 12:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pnp3-G2hHMK5 for ; Tue, 18 Oct 2011 12:52:24 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCF621F8D48 for ; Tue, 18 Oct 2011 12:52:24 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 2CB01428078 for ; Tue, 18 Oct 2011 12:52:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nKA/Y60q/j55yjck1DN4t EXCv2o3rRbtWoDdpDcgYNx1as4MaLh4TkJhkDCvLueqmZbnP9HMbf5aGrs97CZNN UNbHEHOnP0pm9rrQCAe88XprWHhkfdxf6KSenskFEg7P2BhXNO59t0nbpULdaZck isxgcwqcV0uGBuXZ9kO11M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=f+ulYTZf3iQI4mmVzBob wkq3PEQ=; b=dayRCWtnH5HHr42CAzTqkPh4jLdJLXd+uEg0l1HymcAMPGExDKcF n0N/2H/IJCZPUN+qGnbNt8iaSB3xGPmd19qMXSsRaK3keeVqyXTlXCP6lb/EN7YD 25aLeu6G2CXngxPrIjBOZpaDEUOMiemDwqXIAUxau2RDdTjtp0zhWYg= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 13F1B428075 for ; Tue, 18 Oct 2011 12:52:24 -0700 (PDT) Received: by pzk34 with SMTP id 34so2521521pzk.9 for ; Tue, 18 Oct 2011 12:52:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.13.135 with SMTP id h7mr6973097pbc.75.1318967543769; Tue, 18 Oct 2011 12:52:23 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 12:52:23 -0700 (PDT) In-Reply-To: <4E668FC2.6080809@stpeter.im> References: <4E6682A9.5030002@stpeter.im> <4E668AE5.7080700@gmail.com> <4E668FC2.6080809@stpeter.im> Date: Tue, 18 Oct 2011 14:52:23 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: saag@ietf.org Subject: Re: [saag] internationalized passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:52:26 -0000 On Tue, Sep 6, 2011 at 4:25 PM, Peter Saint-Andre wrote: > On 9/6/11 3:04 PM, Yaron Sheffer wrote: >> And one feedback (I am not an I18N expert by any means, although I can >> write both LTR and RTL :-): how can you disallow space characters >> (presumably including ASCII SPACE) from the Secret Class? > > That was one point of contention. You're probably right that spaces are > needed to suppose pass phrases instead of just pass *words*. Map all space codepoints to ASCII 0x20 space. Spaces are required for passphrases. Sure, you could also map them out, meaning that that "foo bar" would be the same as "foobar", but I think that would be rather surprising, whereas the equivalence of "foo\tbar" with "foo bar" would likely go entirely unnoticed (ditto other spacing marks). Nico -- From aland@deployingradius.com Tue Oct 18 12:59:42 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7B21F8AF7 for ; Tue, 18 Oct 2011 12:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.67 X-Spam-Level: X-Spam-Status: No, score=-100.67 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ck5NS1BsW1X7 for ; Tue, 18 Oct 2011 12:59:42 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id A32FA21F8ACA for ; Tue, 18 Oct 2011 12:59:40 -0700 (PDT) Message-ID: <4E9DDA90.90005@deployingradius.com> Date: Tue, 18 Oct 2011 21:59:12 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Nico Williams References: <4E6682A9.5030002@stpeter.im> <4E668AE5.7080700@gmail.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] internationalized passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 19:59:42 -0000 Nico Williams wrote: > I think it will be a long time yet before users can reliably enter > non-ASCII passwords on all their operating systems and applications on > all their devices. I'd change the word "reliably" to "consistently". Users can enter passwords everywhere. *Something* will get sent over the wire. Whether it's consistent from one OS / application to another is different story. In my experience, I've seen very, very, few problems with end-users entering passwords. The historical approach has been to insist on ASCII. Recently, i18n passwords have become more widely used. But all that's required is consistency. The user enters what he thinks is the "same" password, and gets authenticated. That's proof it works for him. The availability of commercial && open source authentication systems means that de-facto standards exist. Everyone tests against everyone elses systems, and end-users test even more combinations. It all Just Works. I'm sometimes still surprised that it does work, tho. Alan DeKok. From nico@cryptonector.com Tue Oct 18 13:57:46 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE34F21F8B9E for ; Tue, 18 Oct 2011 13:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.048 X-Spam-Level: X-Spam-Status: No, score=-0.048 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_PROFIT1=3.858] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuwLIwvNHkLI for ; Tue, 18 Oct 2011 13:57:46 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4D221F8B9D for ; Tue, 18 Oct 2011 13:57:46 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id DE161BC040 for ; Tue, 18 Oct 2011 13:57:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=vf8STVcfuLMUZQkOZon8FMHvJ7Vt2kRVCnRF7O9OivGm yEFJRO4hgfQ2H2bD0oO9npcr54zrDxN7hzVwN2+vX8My9pYN5R5anO6M0lLi0jO6 wMzu9RgcBGTay3Wb3Ke7RbR3o9BruaBvZyHe1BUxhZw8HPmTm+2nzzdmoHyPBoY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FUAa8dM/32vC7zQkq96XvGWN9Fo=; b=Z+/WO9NYoLp 7ftlv0rKe1CgD343RgvdoaMVm9Nmzlso5H9HDNOg6HO6JnhDD8lTvcMDVR6XyJ5P T1d0ktVFNjdiuZmdkkRXCMdh0cop+i5s15CcmRcOg7nZHGpTLw9hY2l5/5XzWdxD AQJsjjKvuCpdJ8bf7cYQUofdxQvuSpko= Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id AC525BC049 for ; Tue, 18 Oct 2011 13:57:45 -0700 (PDT) Received: by qyk31 with SMTP id 31so934528qyk.10 for ; Tue, 18 Oct 2011 13:57:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.231 with SMTP id l7mr7432512pbj.41.1318971464494; Tue, 18 Oct 2011 13:57:44 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 13:57:44 -0700 (PDT) In-Reply-To: <4E9DDA90.90005@deployingradius.com> References: <4E6682A9.5030002@stpeter.im> <4E668AE5.7080700@gmail.com> <4E9DDA90.90005@deployingradius.com> Date: Tue, 18 Oct 2011 15:57:44 -0500 Message-ID: From: Nico Williams To: Alan DeKok Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: saag@ietf.org Subject: Re: [saag] internationalized passwords X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 20:57:47 -0000 On Tue, Oct 18, 2011 at 2:59 PM, Alan DeKok wro= te: > Nico Williams wrote: >> I think it will be a long time yet before users can reliably enter >> non-ASCII passwords on all their operating systems and applications on >> all their devices. > > =C2=A0I'd change the word "reliably" to "consistently". =C2=A0Users can e= nter > passwords everywhere. =C2=A0*Something* will get sent over the wire. =C2= =A0Whether > it's consistent from one OS / application to another is different story. I don't agree. We, and I would say also *users* want consistency, but we can't get that unless we also aim for reliability. Put differently, if all implementations just-send-8 then there's a high risk that we'll end up with only ASCII working consistently. If all implementations just-send-UTF-8 then there's a high risk that we'll end up with only a subset of Unicode working consistently (e.g., that subset which doesn't require normalization, or perhaps only that subset for which input methods reliably produce the same form). > =C2=A0In my experience, I've seen very, very, few problems with end-users > entering passwords. =C2=A0The historical approach has been to insist on > ASCII. =C2=A0Recently, i18n passwords have become more widely used. I've never even tried. The main problem is that I have no idea what input method is available on any login screen, with the main exception -oddly enough- being smartphones and tablets, oddly enough, because on-screen keyboards and tiny keyboards typically make it easy [for sighted people anyways] to enter non-ASCII, at least for Latin scripts. > =C2=A0But all that's required is consistency. =C2=A0The user enters what = he > thinks is the "same" password, and gets authenticated. =C2=A0That's proof= it > works for him. Yes, but since that is also desired going forwards, we need a standard. A standard calls for more than consistency even if we're turning a de facto standard into de jure -- a standard calls for reliability. > =C2=A0The availability of commercial && open source authentication system= s > means that de-facto standards exist. =C2=A0Everyone tests against everyon= e > elses systems, and end-users test even more combinations. =C2=A0It all Ju= st > Works. > > =C2=A0I'm sometimes still surprised that it does work, tho. I'm not surprised. Most input methods (on Windows, Mac OS, Linux, Solaris, ...) reliably produce NFC for Latin scripts. I'm not sure if most input methods reliably produce one form or another for Korean or other non-Latin scripts that require normalization. "Consistency" might be available, but perhaps only for a small subset of users. Even the MacOS X input methods produces NFC for Latin scripts even though HFS applies NFD on create and reads back NFD (strange, I know). The hard part is knowing what input method is in effect. US-International keyboard, or compose sequences? At the login screen, who knows? I guess MacOS X allows one to enter non-ASCII at the login screen, but for Windows I'd be less sure without trying it. And then, all these input methods require different key combinations for things lik á. (I find compose sequences to be the most straightforward and obvious, particularly after I understood their background.) As a user who often has to enter non-ASCII, I'd not brave the non-ASCII password waters myself. Nico -- From nico@cryptonector.com Tue Oct 18 15:06:33 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7270D21F8B10 for ; Tue, 18 Oct 2011 15:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jriQJU194DgQ for ; Tue, 18 Oct 2011 15:06:32 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E09B021F8B0F for ; Tue, 18 Oct 2011 15:06:32 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 0AC60350109 for ; Tue, 18 Oct 2011 15:06:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=uqcaa9EoR9TphRUxoDhchVc/apFCl6gS0JiE3LJH2+xE udxbwQW3WELhiYfYsmULKHsCdl9t0eTF5mUbrhX4+Rm+A2ZS0losynbPwlEgaovl eJec+LyHvnvUyXjaGPZEhHNmA537q6a12NsYLMt8UqkamYLPMbIUpfCoqLGsKfo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=iEY8kcZyy2aywVjzczSMcV6UblE=; b=gRgsNRLnktk xIlLWhpzS7pjet6Td68LV96vt93CInHwZu7qme8kXYCXvszUrWyDXcXEedowJgfE vWu8Y53ynAL87jp1TucxJ42V2zWL/ibW8XIIUunP+AQ+oYlRme/D18RiPAL77KFn Nft8ZS7M2ZJP0feUf75xCf1KeETqDS+A= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 3B15D3501EE for ; Tue, 18 Oct 2011 14:45:52 -0700 (PDT) Received: by ywa8 with SMTP id 8so1253311ywa.31 for ; Tue, 18 Oct 2011 14:45:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr7784307pbq.7.1318974343850; Tue, 18 Oct 2011 14:45:43 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 14:45:43 -0700 (PDT) Date: Tue, 18 Oct 2011 16:45:43 -0500 Message-ID: From: Nico Williams To: saag@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [saag] Survey of I18N input method characteristics? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:06:33 -0000 Is there any survey of input method characteristics regarding I18N? Here's what *I* know from experience: - Solaris, Linux, Windows, MacOS X -- all produce composed for Latin script characters in UTF-8 locales. I'm pretty sure that at least some of these OSes' input methods produce composed output, but not necessarily NFC, or at least they make no effort to normalize (it's one thing to produce composed codepoints for things like á and another to normalize raw Unicode codepoints entered by the user as such). - The details of how to enter non-ASCII characters vary widely by operating system, and often there are multiple choices of input methods. - Solaris and Linux tend to allow choice of locale at the login screen. MacOS X Lion and Windows 7 XP Home do not, at least not in the default setup. It's unclear whether or how one can enable one or another input method at the login screen. - Android makes non-ASCII Latin character input quite easy, and it too seems to output composed sequences. I suspect this is generally the case for all smartphone/tablet OSes. I expect that iOS' input method also produces composed output -- for Latin characters at least. What I don't know: - Whether the same holds for other scripts. E.g., is Hangul (Korean) generally output [by input methods] in composed or decomposed form? What about other non-Latin scripts that require normalization? - Whether input methods are more consistent at least regarding how one enters non-ASCII for non-Latin scripts. It seems to me that a more complete survey would be useful. Perhaps we can have people report what their I18N input method experiences are beyond mine? What would be a good way to run such a survey? Nico --