From nobody Sun Jun 15 06:01:45 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845FD1B28F6 for ; Sun, 15 Jun 2014 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PGcA7Put0aZ for ; Sun, 15 Jun 2014 06:01:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 536921B28F5 for ; Sun, 15 Jun 2014 06:01:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B85E2BF17 for ; Sun, 15 Jun 2014 14:01:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrLdFH1hIyzz for ; Sun, 15 Jun 2014 14:01:41 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.62.64]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3F369BE50 for ; Sun, 15 Jun 2014 14:01:41 +0100 (IST) Message-ID: <539D9920.7080406@cs.tcd.ie> Date: Sun, 15 Jun 2014 14:01:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> In-Reply-To: <20140504085609.GO27883@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/ol7i0r798ROXSKuvGx1oCjSLHh8 Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 13:01:44 -0000 Folks, I've not seen discussion/progress on Steve K's draft for over a month (perhaps this'll prompt that:-), and I would like to get this topic sorted, so I'd also be interested in whether folks have opinions on Viktor's shorter proposal, visible at [1], not yet an I-D. Please comment... Thanks, S. [1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html On 04/05/14 09:56, Viktor Dukhovni wrote: > On Sun, Apr 27, 2014 at 01:37:40PM +0100, Stephen Farrell wrote: > >> Or even maybe try suggest an alternative for the whole >> thing if you've energy. > > OK. How about the below (removed TOC, BCP 78/79 boilerplate, > pagebreaks, ... leaving just the content). This is quite short, > and to the point, which is I think a significant advantage. Most > of what is left unsaid is I think inessential to the definition. > If the below is a reasonable start, and anyone wants to see some > more words, I am not opposed to reasonable expansion of the text > and/or clarification, provided we keep the separation of the > essential definition from any illustrative examples or properties > that some opportunistic security protocol or other might have. > (XML, HTML, ... available, and I can post a more formal I-D if > this is a reasonable starting point). > From nobody Sun Jun 15 07:59:35 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850F61B285A for ; Sun, 15 Jun 2014 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvBmUmJ-C0ma for ; Sun, 15 Jun 2014 07:59:33 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29731B2844 for ; Sun, 15 Jun 2014 07:59:32 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C8E546D493; Sun, 15 Jun 2014 10:59:27 -0400 (EDT) Message-ID: <539DB4CD.8060800@iang.org> Date: Sun, 15 Jun 2014 15:59:25 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> In-Reply-To: <539D9920.7080406@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/mx9K7730sX1jpu6qYXw0AXttnuk Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 14:59:35 -0000 On 15/06/2014 14:01 pm, Stephen Farrell wrote: > > Folks, > > I've not seen discussion/progress on Steve K's draft for over a month > (perhaps this'll prompt that:-), URL? > and I would like to get this topic > sorted, so I'd also be interested in whether folks have opinions on > Viktor's shorter proposal, visible at [1], not yet an I-D. Please > comment... Viktor's proposal is good. I could quibble, but cannot see how to make it better. > [1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html iang From nobody Sun Jun 15 08:01:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364581B2903 for ; Sun, 15 Jun 2014 08:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOOqvDQKImtv for ; Sun, 15 Jun 2014 08:01:11 -0700 (PDT) Received: from BLU004-OMC4S3.hotmail.com (blu004-omc4s3.hotmail.com [65.55.111.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3761B2844 for ; Sun, 15 Jun 2014 08:01:11 -0700 (PDT) Received: from BLU406-EAS429 ([65.55.111.135]) by BLU004-OMC4S3.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Sun, 15 Jun 2014 08:01:11 -0700 X-TMN: [xZJdyGBK0JLALpVQL9PSlagDKXDBtzM1oggmlUQVbvU=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <539D9920.7080406@cs.tcd.ie> Date: Sun, 15 Jun 2014 08:01:07 -0700 To: Stephen Farrell X-OriginalArrivalTime: 15 Jun 2014 15:01:11.0169 (UTC) FILETIME=[A5091F10:01CF88AA] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/aByo3o_YRTKsX1nMQIu_Pk-1mFw Cc: "saag@ietf.org" Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 15:01:13 -0000 One concern about the draft is the denigration of TOFU. SSH is very widely u= sed and characterizing it as "fragile" does not match my experience, althoug= h key continuity obviously has some drawbacks. The physician's credo "First,= do no harm" should also apply here. > On Jun 15, 2014, at 6:01 AM, "Stephen Farrell" = wrote: >=20 >=20 > Folks, >=20 > I've not seen discussion/progress on Steve K's draft for over a month > (perhaps this'll prompt that:-), and I would like to get this topic > sorted, so I'd also be interested in whether folks have opinions on > Viktor's shorter proposal, visible at [1], not yet an I-D. Please > comment... >=20 > Thanks, > S. >=20 > [1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html >=20 >> On 04/05/14 09:56, Viktor Dukhovni wrote: >>> On Sun, Apr 27, 2014 at 01:37:40PM +0100, Stephen Farrell wrote: >>>=20 >>> Or even maybe try suggest an alternative for the whole >>> thing if you've energy. >>=20 >> OK. How about the below (removed TOC, BCP 78/79 boilerplate, >> pagebreaks, ... leaving just the content). This is quite short, >> and to the point, which is I think a significant advantage. Most >> of what is left unsaid is I think inessential to the definition. >> If the below is a reasonable start, and anyone wants to see some >> more words, I am not opposed to reasonable expansion of the text >> and/or clarification, provided we keep the separation of the >> essential definition from any illustrative examples or properties >> that some opportunistic security protocol or other might have. >> (XML, HTML, ... available, and I can post a more formal I-D if >> this is a reasonable starting point). >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sun Jun 15 08:49:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB2F1A00D1 for ; Sun, 15 Jun 2014 08:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPQZEgKjNltU for ; Sun, 15 Jun 2014 08:49:07 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A10E1A0090 for ; Sun, 15 Jun 2014 08:49:07 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.133.158]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5FFmQGc000483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2014 08:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402847326; x=1402933726; bh=CEOobbe7Nhi95xLiSewiZoMUIW62akuQiAhz3m3nhwo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uFkqZlAL6S0FxBbLv8l00kN7ubxFVHCQd5SB6Fgu0c9RALT5gI8/LvkHf9nSRAfA0 5iXH/MMRNNWLolA+c27BkacgU2/GEj04jjdUx1fsrKo7MhIZ/FpelTmCYaAPhFr4Xl 3VKB4p7wEvB0catoYq80t/Yyhwg+IjilTqL+VDr8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402847326; x=1402933726; i=@elandsys.com; bh=CEOobbe7Nhi95xLiSewiZoMUIW62akuQiAhz3m3nhwo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=muorPrl9vOLovx6I8/hlvyKF0OMRy9q4NIdlwXHpyJopcVGKfrf9i+Tad2YOL70j9 fxZabccoVALdo9zoBLjEEHYLOFZncDwxuC+MHHtB0NMDquJEjgVQUeV0L07Og3zV4F IYDPULZCcyrHSt1WPKP3B/riVJJNkosm53Hn6rZI= Message-Id: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 15 Jun 2014 08:46:09 -0700 To: Watson Ladd , saag@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/6XVLpFN7LNKtNV9WWlb45pKFE-w Cc: Tanja Lange Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 15:49:08 -0000 Hi Watson, [Thread moved to saag@ as requested] At 06:25 15-06-2014, Watson Ladd wrote: >I would like to see an addition to the IETF rules: participants must >fully disclose security issues with the standard they are aware of, in >all standards bodies they participate in, at the time of the Last Call >for a standard. Such disclosure must be to all members of the >committee developing the standard, and, in the event such a security >issue remains post-ratification, public. > >This is motivated by the discovery that Certicom, in particular, >patented a backdoor in Dual EC, and proceeded not to tell anyone. No >doubt I have bumbled the above rule: but I would like to start >discussion of what sort of rule we require to ensure that participants >do not horde vulnerabilities, only to exploit them after the standard >is ratified. It is difficult to assess a specification which is being standardized when there is a lack of candor or when information which might potentially affect the decision is not publicly available. There is the following text in a (IETF) RFC: "However, it is to be noted that there is an expectation that no one shall ever knowingly contribute advice or text that may adversely affect the security of the Internet without describing all known or foreseen risks and threats to potential implementers and users that they are aware of." Regards, S. Moonesamy From nobody Sun Jun 15 09:40:50 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6621B2934 for ; Sun, 15 Jun 2014 09:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJT_vBYgxHGT for ; Sun, 15 Jun 2014 09:40:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D68931A0273 for ; Sun, 15 Jun 2014 09:40:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BC9CFBF04; Sun, 15 Jun 2014 17:40:44 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNa4kFDLdU6u; Sun, 15 Jun 2014 17:40:41 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.62.64]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2B5EBF0D; Sun, 15 Jun 2014 17:40:41 +0100 (IST) Message-ID: <539DCC89.4030004@cs.tcd.ie> Date: Sun, 15 Jun 2014 17:40:41 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <539DB4CD.8060800@iang.org> In-Reply-To: <539DB4CD.8060800@iang.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/XuZUz-8mLD0aDKCoVJ7af-Ac9fU Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 16:40:48 -0000 On 15/06/14 15:59, ianG wrote: > On 15/06/2014 14:01 pm, Stephen Farrell wrote: >> >> Folks, >> >> I've not seen discussion/progress on Steve K's draft for over a month >> (perhaps this'll prompt that:-), > > URL? Ah, sorry. Steve's draft is [1] S. [1] https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ > >> and I would like to get this topic >> sorted, so I'd also be interested in whether folks have opinions on >> Viktor's shorter proposal, visible at [1], not yet an I-D. Please >> comment... > > > Viktor's proposal is good. I could quibble, but cannot see how to make > it better. > > >> [1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html > > > > iang > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Sun Jun 15 09:43:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A121B294D for ; Sun, 15 Jun 2014 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewCf5vY5YihD for ; Sun, 15 Jun 2014 09:43:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B031B2942 for ; Sun, 15 Jun 2014 09:43:34 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 004592AB275; Sun, 15 Jun 2014 16:43:33 +0000 (UTC) Date: Sun, 15 Jun 2014 16:43:33 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140615164333.GM8358@mournblade.imrryr.org> References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sCBaqjDDTr7iSw2Df_YYCWoJdaU Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 16:43:36 -0000 On Sun, Jun 15, 2014 at 08:01:07AM -0700, Bernard Aboba wrote: > One concern about the draft is the denigration of TOFU. SSH is > very widely used and characterizing it as "fragile" does not match > my experience, although key continuity obviously has some drawbacks. > The physician's credo "First, do no harm" should also apply here. Thanks for the feedback. I wrote: Encryption is easy, but key management is difficult. Key management at Internet scale remains an incompletely solved problem. The PKIX ([RFC5280]) key management model introduces costs that not all peers are willing to bear and is also not sufficient to secure communications when the peer reference identity is obtained indirectly over an insecure channel or communicating parties don't agree on a mutually trusted certification authority (CA). DNSSEC is not at this time sufficiently widely adopted to make DANE a viable alternative at scale. Trust on first use (TOFU) key management models (as with saved SSH fingerprints and various certificate pinning approaches) are fragile and require user intervention when key continuity fails. How would you like to express this better? I did not mean to disparage TOFU. SSH works well enough because it is not used to connect to arbitrary hosts, any one user generally only logs in to a relatively small set of systems (as compared with web sites they visit, domains they might send email to, ...). So I am not trying to disparage TOFU, merely suggest that it does not generally scale to authenticating any peer on the Internet. I could remove the two words "are fragile", if they are seen too judgemental and not essential to make the point. -- Viktor. From nobody Sun Jun 15 10:02:58 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C351B296F for ; Sun, 15 Jun 2014 10:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcG6Al3i7j76 for ; Sun, 15 Jun 2014 10:02:56 -0700 (PDT) Received: from Chip.Rodents-Montreal.ORG (Chip.Rodents-Montreal.ORG [216.46.0.66]) by ietfa.amsl.com (Postfix) with ESMTP id EE7951B295E for ; Sun, 15 Jun 2014 10:02:55 -0700 (PDT) Received: (from mouse@localhost) by Chip.Rodents-Montreal.ORG (8.8.8/8.8.8) id NAA26519; Sun, 15 Jun 2014 13:02:53 -0400 (EDT) Date: Sun, 15 Jun 2014 13:02:53 -0400 (EDT) From: Mouse Message-Id: <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Sun, 15 Jun 2014 12:56:33 -0400 (EDT) To: saag@ietf.org In-Reply-To: <20140615164333.GM8358@mournblade.imrryr.org> References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Dp2PTf2n3U4N2VEXTgL7Bev1x9k Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 17:02:57 -0000 > Trust on first use (TOFU) key > management models (as with saved SSH fingerprints and various certificate > pinning approaches) are fragile and require user intervention when key > continuity fails. > How would you like to express this better? I wouldn't say they're _fragile_, exactly, just that they are appropriate to only a relatively restricted set of problems. (That it's what SSH uses merely means that SSH is not an appropriate solution outside that set. That SSH gets used anyway just means that that set, restricted though it is, contains some useful problems.) > So I am not trying to disparage TOFU, merely suggest that it does not > generally scale to authenticating any peer on the Internet. I don't think it's a question of scale; TOFU scales just fine to a very large number of peers. What it won't do is work for problem domains where first use is likely to be attacked - regardless of how large the set of peers in question is. (That is, it may not be suitable for authenticating arm's-length peers over the open Internet, but the reason isn't scale per se.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From nobody Sun Jun 15 10:14:16 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CB61B2965 for ; Sun, 15 Jun 2014 10:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPMqQDg7CAO2 for ; Sun, 15 Jun 2014 10:14:11 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83EE01B2963 for ; Sun, 15 Jun 2014 10:14:11 -0700 (PDT) Received: from BY2PR03MB426.namprd03.prod.outlook.com (10.141.141.140) by BY2PR03MB425.namprd03.prod.outlook.com (10.141.141.139) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sun, 15 Jun 2014 17:14:04 +0000 Received: from BY2PR03MB426.namprd03.prod.outlook.com ([10.141.141.140]) by BY2PR03MB426.namprd03.prod.outlook.com ([10.141.141.140]) with mapi id 15.00.0954.000; Sun, 15 Jun 2014 17:14:04 +0000 From: Christian Huitema To: Mouse , "saag@ietf.org" Thread-Topic: [saag] suggested text for opportunistic definition Thread-Index: AQHPiJn6b+Xc9bn7RkmKizMMP/5QOJtyRBGAgAAcnoCAAAVngIAAAkvA Date: Sun, 15 Jun 2014 17:14:03 +0000 Message-ID: References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> In-Reply-To: <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.16.156.113] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(101416001)(74502001)(66066001)(76482001)(21056001)(81342001)(85852003)(99286001)(31966008)(76176999)(81542001)(54356999)(86612001)(4396001)(64706001)(99396002)(50986999)(74316001)(33646001)(83322001)(20776003)(76576001)(2656002)(79102001)(77982001)(105586001)(74662001)(86362001)(80022001)(46102001)(87936001)(92566001)(83072002)(85306003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB425; H:BY2PR03MB426.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/lgZQ0snTuzgWh0VHQ1KJky0ZaTw Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 17:14:14 -0000 > I wouldn't say they're _fragile_, exactly, just that they are > appropriate to only a relatively restricted set of problems. (That > it's what SSH uses merely means that SSH is not an appropriate solution > outside that set. That SSH gets used anyway just means that that set, > restricted though it is, contains some useful problems.) What about replacing "are fragile" by "are not always appropriate?" Apart from that, I like Viktor's text. It is clear, to the point and easy t= o read. I would vote to adopt and publish. -- Christian Huitema From nobody Sun Jun 15 12:39:46 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5057B1B2918 for ; Sun, 15 Jun 2014 12:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTX8WvbgvsZA for ; Sun, 15 Jun 2014 12:39:43 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89F281A01E7 for ; Sun, 15 Jun 2014 12:39:43 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id C76016D588; Sun, 15 Jun 2014 15:39:38 -0400 (EDT) Message-ID: <539DF679.5020907@iang.org> Date: Sun, 15 Jun 2014 20:39:37 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Stephen Farrell , saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <539DB4CD.8060800@iang.org> <539DCC89.4030004@cs.tcd.ie> In-Reply-To: <539DCC89.4030004@cs.tcd.ie> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/vRi-FVlLnBv8mOJ4lDxE6pCePxU Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 19:39:45 -0000 On 15/06/2014 17:40 pm, Stephen Farrell wrote: >>> I've not seen discussion/progress on Steve K's draft for over a month >>> (perhaps this'll prompt that:-), >> >> Steve's draft is [1] > [1] https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/ Ah, thanks. I think Viktor's at bottom is far superior. It looks forward and upwards, climbing up from no security to a position of some good ol' opportunistic cryptography. Establishes some principles, and leaves it at that. In contrast, IMHO the /Countermeasure/ draft looks downwards, apologetically. It is as if it needs to justify the downgrade from the position of other protocols, and especially prior dogma as to authentication. It's the wrong starting point, we don't need to justify or downgrade, and doing so adds length to little effect, while clouding the principles needed. my 2c, iang >>> and I would like to get this topic >>> sorted, so I'd also be interested in whether folks have opinions on >>> Viktor's shorter proposal, visible at [1], not yet an I-D. Please >>> comment... >> >> >> Viktor's proposal is good. I could quibble, but cannot see how to make >> it better. >>> [1] https://www.ietf.org/mail-archive/web/saag/current/msg04962.html From nobody Sun Jun 15 12:48:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0201B2794 for ; Sun, 15 Jun 2014 12:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsSq9M19Gztj for ; Sun, 15 Jun 2014 12:48:08 -0700 (PDT) Received: from BLU004-OMC1S24.hotmail.com (blu004-omc1s24.hotmail.com [65.55.116.35]) by ietfa.amsl.com (Postfix) with ESMTP id 894B91A0248 for ; Sun, 15 Jun 2014 12:48:08 -0700 (PDT) Received: from BLU181-W4 ([65.55.116.7]) by BLU004-OMC1S24.hotmail.com with Microsoft SMTPSVC(7.5.7601.22701); Sun, 15 Jun 2014 12:48:08 -0700 X-TMN: [V1Ht0NiF9Qia4TUAAMXhuRcPy1x8fkKb] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_65ccdda3-0ea3-4d76-8b19-6830d6278aca_" From: Bernard Aboba To: S Moonesamy , Watson Ladd , "saag@ietf.org" Date: Sun, 15 Jun 2014 12:48:07 -0700 Importance: Normal In-Reply-To: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> References: , <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jun 2014 19:48:08.0539 (UTC) FILETIME=[BB634AB0:01CF88D2] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/pG1jc4Xh98R15nQDRvaZsGEbYmo Cc: Tanja Lange Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 19:48:10 -0000 --_65ccdda3-0ea3-4d76-8b19-6830d6278aca_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > There is the following text in a (IETF) RFC: >=20 > "However=2C it is to be noted that there is an expectation that no one > shall ever knowingly contribute advice or text that may adversely > affect the security of the Internet without describing all known > or foreseen risks and threats to potential implementers and users > that they are aware of." >=20 > Regards=2C > S. Moonesamy=20 [BA] This (existing) advice is a lot more reasonable than Watson's proposal= =2C although it too is obviously limited - it is the unforeseen risks and t= hreats that often are the most problematic. This is particularly true in th= e privacy arena where a practice that might have been passed muster when it= was first proposed (e.g. use of long-lived MAC addresses in protocols) ca= n be recognized as a privacy issue as the state of the art (e.g. MAC-based = geolocation APIs) advances.=20 =20 =20 = --_65ccdda3-0ea3-4d76-8b19-6830d6278aca_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B There is the following te= xt in a (IETF) RFC:
>=3B
>=3B "However=2C it is to be noted t= hat there is an expectation that no one
>=3B shall ever knowingly = contribute advice or text that may adversely
>=3B affect the secur= ity of the Internet without describing all known
>=3B or foreseen = risks and threats to potential implementers and users
>=3B that th= ey are aware of."
>=3B
>=3B Regards=2C
>=3B S. Moonesamy
[BA] This (existing) advice is a lot more reasonable than Watson's pr= oposal=2C although it too is obviously limited - it is the unforeseen risks= and threats that often are the most problematic. This is particularly true= in the privacy arena where a practice that might have been passed muster w= hen it was first proposed (e.g. =3B use of long-lived MAC addresses in = protocols) can be recognized as a =3Bprivacy issue =3Bas the state = of the art (e.g. MAC-based geolocation APIs) advances.
 =3B

=  =3B
= --_65ccdda3-0ea3-4d76-8b19-6830d6278aca_-- From nobody Sun Jun 15 13:02:49 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0298A1A058E for ; Sun, 15 Jun 2014 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIBcOmuC9SkI for ; Sun, 15 Jun 2014 13:02:42 -0700 (PDT) Received: from nk11p14im-asmtp001.me.com (nk11p14im-asmtp001.me.com [17.158.72.160]) by ietfa.amsl.com (Postfix) with ESMTP id 61ACB1B293F for ; Sun, 15 Jun 2014 13:02:38 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_W2EV3QUW0InxPPpg5q09sQ)" Received: from unknown-b8-e8-56-34-a1-fc.home (host86-146-199-11.range86-146.btcentralplus.com [86.146.199.11]) by nk11p14im-asmtp001.me.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0N78006DG7O4HDC0@nk11p14im-asmtp001.me.com> for saag@ietf.org; Sun, 15 Jun 2014 20:02:33 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-06-15_02:2014-06-13,2014-06-15,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406150281 From: David Misell In-reply-to: Date: Sun, 15 Jun 2014 21:02:28 +0100 Message-id: <5FB4E2F0-E830-46AD-8915-8FC5E69FF4AF@icloud.com> References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> To: Bernard Aboba X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7Jh_qqQMamtjgMrgZfL6L0WbG3A Cc: Tanja Lange , Watson Ladd , S Moonesamy , "saag@ietf.org" Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:02:44 -0000 --Boundary_(ID_W2EV3QUW0InxPPpg5q09sQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT The following may be of interest: http://ethics-wg.org/framework.html which bring together ISSA, ISC2 and SANS in it examined GIAC form. As a member of all 3 I am signed up, but the ISC2 Ethical canons seem to hold up best when put under the spotlight. https://www.isc2.org/ethics/default.aspx Code of Ethics Preamble: The safety and welfare of society and the common good, duty to our principals, and to each other, requires that we adhere, and be seen to adhere, to the highest ethical standards of behavior. Therefore, strict adherence to this Code is a condition of certification. Code of Ethics Canons: Protect society, the common good, necessary public trust and confidence, and the infrastructure. Act honorably, honestly, justly, responsibly, and legally. Provide diligent and competent service to principals. Advance and protect the profession. Kind Regards dave On 15 Jun 2014, at 20:48, Bernard Aboba wrote: > > There is the following text in a (IETF) RFC: > > > > "However, it is to be noted that there is an expectation that no one > > shall ever knowingly contribute advice or text that may adversely > > affect the security of the Internet without describing all known > > or foreseen risks and threats to potential implementers and users > > that they are aware of." > > > > Regards, > > S. Moonesamy > > [BA] This (existing) advice is a lot more reasonable than Watson's proposal, although it too is obviously limited - it is the unforeseen risks and threats that often are the most problematic. This is particularly true in the privacy arena where a practice that might have been passed muster when it was first proposed (e.g. use of long-lived MAC addresses in protocols) can be recognized as a privacy issue as the state of the art (e.g. MAC-based geolocation APIs) advances. > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Boundary_(ID_W2EV3QUW0InxPPpg5q09sQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable The = following may be of interest:
http://ethics-wg.org/framewor= k.html which bring together ISSA, ISC2 and SANS in it examined GIAC = form.


As a member of all 3 =  I am signed up, but the ISC2 Ethical canons seem to hold up best = when put under the spotlight.

Code of Ethics Preamble: =   

    The safety and = welfare of society and the common good, duty to our principals, and to = each other, requires that we adhere, and be seen to adhere, to the = highest ethical standards of behavior.
    = Therefore, strict adherence to this Code is a condition of = certification.

Code of Ethics Canons: =   

    Protect society, the = common good, necessary public trust and confidence, and the = infrastructure.
    Act honorably, honestly, justly, = responsibly, and legally.
    Provide diligent and = competent service to principals.
    Advance and = protect the profession.


Kind = Regards

dave

On = 15 Jun 2014, at 20:48, Bernard Aboba <bernard_aboba@hotmail.com>= ; wrote:

> There is the = following text in a (IETF) RFC:
> 
> "However, it is to = be noted that there is an expectation that no one
> shall ever = knowingly contribute advice or text that may adversely
> affect = the security of the Internet without describing all known
> or = foreseen risks and threats to potential implementers and users
> = that they are aware of."
> 
> Regards,
> = S. Moonesamy 

[BA] This = (existing) advice is a lot more reasonable than Watson's proposal, = although it too is obviously limited - it is the unforeseen risks and = threats that often are the most problematic. This is particularly true = in the privacy arena where a practice that might have been passed muster = when it was first proposed (e.g.  use of long-lived MAC addresses = in protocols) can be recognized as a privacy issue as the = state of the art (e.g. MAC-based geolocation APIs) advances. 
 

 
<= /div>_______________________________________________
saag mailing = list
saag@ietf.org
https://www.ietf.org/m= ailman/listinfo/saag

= --Boundary_(ID_W2EV3QUW0InxPPpg5q09sQ)-- From nobody Sun Jun 15 13:06:19 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADF71B2918 for ; Sun, 15 Jun 2014 13:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdgwDMDPBhhI for ; Sun, 15 Jun 2014 13:06:17 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D5991B2961 for ; Sun, 15 Jun 2014 13:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=569; q=dns/txt; s=iport; t=1402862778; x=1404072378; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=0XHodaxQYLSNPYM6RO+udQqTshLgXiAYElNkKfzXTIo=; b=l4dxmgoT4SzUYRfnjV5hsMDLw21eqCf0hBHoWpcByPVRsr+3Y91PyFsF NPQr850MWGPWCvg5TdTGBNs4yBBx843qk+8h9mGAQHttNnnEhB7UJU+Tl NSG9xwB5sZv4QowHg/YGpzGuhbehs/edCair/AghVJb7bAqh3pMswEoEz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0FAEX8nVOtJssW/2dsb2JhbABahyWmeQEBAQEBAQUBmSQBgRp1hAMBAQEEI1URCxgCAgUWCwICCQMCAQIBRQYBDAgBAYg+sFieDxeBKoQ5iRqCd4FMAQOaQ5NYg0I7 X-IronPort-AV: E=Sophos;i="5.01,481,1400025600"; d="scan'208";a="86807648" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 15 Jun 2014 20:06:08 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.173.77]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5FK66Cw030302; Sun, 15 Jun 2014 20:06:07 GMT Message-ID: <539DFCAE.5030908@cisco.com> Date: Sun, 15 Jun 2014 22:06:06 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Mouse , saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> In-Reply-To: <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/d2lgwunhPNmLDCt3aXgOVGU8pxU Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:06:18 -0000 On 6/15/14, 7:02 PM, Mouse wrote: >> Trust on first use (TOFU) key >> management models (as with saved SSH fingerprints and various certificate >> pinning approaches) are fragile and require user intervention when key >> continuity fails. >> How would you like to express this better? > I wouldn't say they're _fragile_, exactly, just that they are > appropriate to only a relatively restricted set of problems. I would suggest a simpler change: just remove the words "are fragile and". Eliot From nobody Sun Jun 15 13:20:03 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FC31B293F for ; Sun, 15 Jun 2014 13:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED58wDLau-g0 for ; Sun, 15 Jun 2014 13:19:58 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF661B293E for ; Sun, 15 Jun 2014 13:19:58 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id q200so3592371ykb.28 for ; Sun, 15 Jun 2014 13:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iDxtVtbMyKa2/WiRWFnr3Yww/2A35MzleULJ7f6yJ+s=; b=HTPXVom5aS48YqVXyYNKtX5KZqqqork+1ODVIrb2BsmqveC3IgwdMYmG6zRiOX7kXQ EbvfgRs2pFS6Z+uJIJXsKZzSRMY+ktBCRJO9lvjm0P2I5BjOn+Pboo689NBFxq+0atUS rXZxD8DxER3dUySz00PBizM29U2rxpaPMl9C5HCZge2NqMbs2+PNiMBhLohtwiKton2j 2Rymm2Yc0hMbvLT946M31JvfdV5EDwKEsfP0eZYCA5kmymRzqcpu17dzIBkF9t2MSgXs x7W+w7eNCOPNGeRzATmM+PWgfcVgdDYrUWwIMA8AT55+NmEGO8/9cglTZtAnREZFIq3s A49w== MIME-Version: 1.0 X-Received: by 10.236.167.103 with SMTP id h67mr5839391yhl.141.1402863597411; Sun, 15 Jun 2014 13:19:57 -0700 (PDT) Received: by 10.170.39.136 with HTTP; Sun, 15 Jun 2014 13:19:57 -0700 (PDT) In-Reply-To: References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> Date: Sun, 15 Jun 2014 17:19:57 -0300 Message-ID: From: Watson Ladd To: Bernard Aboba Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/1LYf-TUL4vR2qmu-nvzlz80fLHA Cc: Tanja Lange , S Moonesamy , "saag@ietf.org" Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:20:00 -0000 On Sun, Jun 15, 2014 at 4:48 PM, Bernard Aboba wrote: >> There is the following text in a (IETF) RFC: >> >> "However, it is to be noted that there is an expectation that no one >> shall ever knowingly contribute advice or text that may adversely >> affect the security of the Internet without describing all known >> or foreseen risks and threats to potential implementers and users >> that they are aware of." >> >> Regards, >> S. Moonesamy > > [BA] This (existing) advice is a lot more reasonable than Watson's proposal, > although it too is obviously limited - it is the unforeseen risks and > threats that often are the most problematic. This is particularly true in > the privacy arena where a practice that might have been passed muster when > it was first proposed (e.g. use of long-lived MAC addresses in protocols) > can be recognized as a privacy issue as the state of the art (e.g. MAC-based > geolocation APIs) advances. We're dealing with the situation where participants recognize a security issue and fail to disclose it. Unrecognized issues are a different ball of wax: nothing short of careful analysis will work, and there is always something missed such as RC4 in TLS. This happened with an ANSI standard: Certicom recognized there was a potential for a backdoor early on, but failed to publicise the issue. When in 2007 it was independently recognized, products based on the flawed standard were deployed. Unforeseen risks will continue to be an issue, but by making clear an expectation that you disclose what you know, we avoid a repeat of the DUAL EC situation. Sincerely, Watson Ladd From nobody Sun Jun 15 13:43:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCCF1B293F for ; Sun, 15 Jun 2014 13:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAdqcK3dlGtB for ; Sun, 15 Jun 2014 13:43:35 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668211B2879 for ; Sun, 15 Jun 2014 13:43:35 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9DF5B2AB275; Sun, 15 Jun 2014 20:43:33 +0000 (UTC) Date: Sun, 15 Jun 2014 20:43:33 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140615204333.GN8358@mournblade.imrryr.org> References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> <539DFCAE.5030908@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <539DFCAE.5030908@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sh6jKXwLc0Fv96Ka5ugMUb5IN1k Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 20:43:36 -0000 On Sun, Jun 15, 2014 at 10:06:06PM +0200, Eliot Lear wrote: > I would suggest a simpler change: > > just remove the words "are fragile and". I'd like to convey two flavours of limitations, one is key continuity failure, the other is of course securing the initial contact (or sufficiently infrequent repeated contact). Since this is not intended to be a draft about TOFU, I'd like to keep it short, so how about: - approaches) are fragile and require user intervention when key - continuity fails. + approaches) don't protect initial contact and require user + intervention when key continuity fails. In any case, I think the question at hand is not whether the draft is finished (I've not even submitted it yet), but whether it is a good start. If the consensus is that this is an acceptable starting point, which repository does saag like to use for work-in-progress documents? I've noticed that the TLS WG now has a git repository, is there anything similar for saag? What should the draft be called? The metadata is tentatively: -- Viktor. From nobody Sun Jun 15 15:57:00 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53C81A029F for ; Sun, 15 Jun 2014 15:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uik9x1OIQcP5 for ; Sun, 15 Jun 2014 15:56:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142471A0289 for ; Sun, 15 Jun 2014 15:56:57 -0700 (PDT) Received: from BY2PR03MB426.namprd03.prod.outlook.com (10.141.141.140) by BY2PR03MB426.namprd03.prod.outlook.com (10.141.141.140) with Microsoft SMTP Server (TLS) id 15.0.954.9; Sun, 15 Jun 2014 22:56:55 +0000 Received: from BY2PR03MB426.namprd03.prod.outlook.com ([10.141.141.140]) by BY2PR03MB426.namprd03.prod.outlook.com ([10.141.141.140]) with mapi id 15.00.0954.000; Sun, 15 Jun 2014 22:56:55 +0000 From: Christian Huitema To: "saag@ietf.org" Thread-Topic: [saag] suggested text for opportunistic definition Thread-Index: AQHPiJn6b+Xc9bn7RkmKizMMP/5QOJtyRBGAgAAcnoCAAAVngIAAMzEAgAAKdoCAACSuYA== Date: Sun, 15 Jun 2014 22:56:54 +0000 Message-ID: References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> <539DFCAE.5030908@cisco.com> <20140615204333.GN8358@mournblade.imrryr.org> In-Reply-To: <20140615204333.GN8358@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.16.156.113] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0243E5FD68 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(199002)(189002)(51704005)(80022001)(4396001)(64706001)(86612001)(81342001)(31966008)(46102001)(21056001)(74662001)(74502001)(76576001)(86362001)(99286001)(83322001)(20776003)(81542001)(2656002)(76176999)(87936001)(99396002)(74316001)(33646001)(50986999)(101416001)(76482001)(66066001)(92566001)(83072002)(93886003)(105586001)(85852003)(77982001)(54356999)(85306003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB426; H:BY2PR03MB426.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/75wyIVwI3L59zPKJIxjvZT6dkcc Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 22:56:58 -0000 > - approaches) are fragile and require user intervention when key > - continuity fails. > + approaches) don't protect initial contact and require user > + intervention when key continuity fails. That's good for me. > What should the draft be called? The metadata is tentatively: > > docName=3D"draft-dukhovni-opportunistic-security-00" > ipr=3D"trust200902"> As good a name as any, although the convention would be "draft-dukhovni-saa= g-opportunistic-security-00." -- Christian Huitema From nobody Sun Jun 15 16:49:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925D21B297A for ; Sun, 15 Jun 2014 16:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFctVz1OrPQq for ; Sun, 15 Jun 2014 16:49:12 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3C61A029F for ; Sun, 15 Jun 2014 16:49:11 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id 2512A6D5AC; Sun, 15 Jun 2014 19:49:08 -0400 (EDT) Message-ID: <539E30F3.1050306@iang.org> Date: Mon, 16 Jun 2014 00:49:07 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> In-Reply-To: <20140615164333.GM8358@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/CF7NAbJUoUde0WMED248mUzFOOQ Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jun 2014 23:49:13 -0000 On 15/06/2014 17:43 pm, Viktor Dukhovni wrote: > On Sun, Jun 15, 2014 at 08:01:07AM -0700, Bernard Aboba wrote: > >> One concern about the draft is the denigration of TOFU. SSH is >> very widely used and characterizing it as "fragile" does not match >> my experience, although key continuity obviously has some drawbacks. >> The physician's credo "First, do no harm" should also apply here. > > Thanks for the feedback. I wrote: > > Encryption is easy, but key management is difficult. Key management at > Internet scale remains an incompletely solved problem. The PKIX ([RFC5280]) > key management model introduces costs that not all peers are willing to > bear and is also not sufficient to secure communications when the peer > reference identity is obtained indirectly over an insecure channel or > communicating parties don't agree on a mutually trusted certification > authority (CA). DNSSEC is not at this time sufficiently widely adopted to > make DANE a viable alternative at scale. Trust on first use (TOFU) key > management models (as with saved SSH fingerprints and various certificate > pinning approaches) are fragile and require user intervention when key > continuity fails. > > How would you like to express this better? I did not mean to > disparage TOFU. SSH works well enough because it is not used to > connect to arbitrary hosts, any one user generally only logs in to > a relatively small set of systems (as compared with web sites they > visit, domains they might send email to, ...). > > So I am not trying to disparage TOFU, merely suggest that it does > not generally scale to authenticating any peer on the Internet. Well, we don't have that in any of the other systems, either. As some might recall, another popular system doesn't scale well beyond credit card holders. > I could remove the two words "are fragile", if they are seen too > judgemental and not essential to make the point. I'm fine with the phrase left in. I understand that the words are a nod and a wink to others who will otherwise kick up a stink. E.g., from the alternate Kent document: SSH ([RFC4251], [RFC4252], [RFC4253]) makes use of a trust on first use (TOFU) approach (aka a leap of faith, see below) for server authentication. But, I agree with other poster, there is nothing 'fragile' about the SSH method, it works stupendously well within its parameters and its purpose space. SSH's record is strong. If TOFU is 'fragile' the same criticism can be levelled at the other mechanisms, which work fine only as long as the system of authentication is working well. In just about all systems of authentication, there are 'leaps of faith' where we'd rather we had better answers. If TOFU is a leap of faith, its competition is a swan dive with blindfold. Let's not let the perfect be the enemy of the good, and let's not let the argument drift to bickering around terms. I vote it forward regardless. iang From nobody Sun Jun 15 21:57:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE9B1B29F9 for ; Sun, 15 Jun 2014 21:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7htLibuqRhl for ; Sun, 15 Jun 2014 21:57:16 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA76E1B2898 for ; Sun, 15 Jun 2014 21:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1301; q=dns/txt; s=iport; t=1402894635; x=1404104235; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+P85aIOx8HuCHIIE9gJk8VB0UTU90bMvzMP72foylfI=; b=QJAzSl/kAkIKqlGZUh518MlFGPWP1V+/D+WDOwPH8Z8mMAVedW4dKEro uE98ntGBPldlO9ADlHpsAqFu9uolElYKBbBkD30qPNIF6cOS2QgjFUXOf saGv2MpSIa+pk4WPFCDQRsBuwX0vPAInDRayIYdxunAmcz434sMl+Y9cE c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFADh4nlOtJssW/2dsb2JhbABahyWmegEBAQMFAZkkAYEgdYQDAQEBAwEjVRELGAICBRYLAgIJAwIBAgFFEwgBAYg2CLB+nWoXgSqEOYkaFoJhgUwBA5pDk1iDQjs X-IronPort-AV: E=Sophos;i="5.01,483,1400025600"; d="scan'208";a="87840141" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 16 Jun 2014 04:57:13 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.203.80]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5G4vCQk012956 for ; Mon, 16 Jun 2014 04:57:13 GMT Message-ID: <539E7928.1040706@cisco.com> Date: Mon, 16 Jun 2014 06:57:12 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <201406151702.NAA26519@Chip.Rodents-Montreal.ORG> <539DFCAE.5030908@cisco.com> <20140615204333.GN8358@mournblade.imrryr.org> In-Reply-To: <20140615204333.GN8358@mournblade.imrryr.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nG2na6_znroVKlt_9sUix53jWBo Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 04:57:19 -0000 On 6/15/14, 10:43 PM, Viktor Dukhovni wrote: > On Sun, Jun 15, 2014 at 10:06:06PM +0200, Eliot Lear wrote: > >> I would suggest a simpler change: >> >> just remove the words "are fragile and". > I'd like to convey two flavours of limitations, one is key continuity > failure, the other is of course securing the initial contact (or > sufficiently infrequent repeated contact). Since this is not > intended to be a draft about TOFU, I'd like to keep it short, so > how about: > > - approaches) are fragile and require user intervention when key > - continuity fails. > + approaches) don't protect initial contact and require user > + intervention when key continuity fails. Fine. > > In any case, I think the question at hand is not whether the draft > is finished (I've not even submitted it yet), but whether it is a > good start. If the consensus is that this is an acceptable starting > point, which repository does saag like to use for work-in-progress > documents? I've noticed that the TLS WG now has a git repository, > is there anything similar for saag? > > What should the draft be called? The metadata is tentatively: > > docName="draft-dukhovni-opportunistic-security-00" > ipr="trust200902"> > Also fine. From nobody Sun Jun 15 22:58:47 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2D1B2A91 for ; Sun, 15 Jun 2014 22:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLfkGujt1iqA for ; Sun, 15 Jun 2014 22:58:43 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8421B2A9A for ; Sun, 15 Jun 2014 22:58:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1506; q=dns/txt; s=iport; t=1402898323; x=1404107923; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=GXlBaAqlBf7NOtCxGxnOZzVulZIiXA2d5zL7cbmmANM=; b=lkxMvcVldBJpfoPO19owMykmcZ0Iq0VIfDuFLMpWeS/MxtQzyfPy1pJJ UvQX8bWWqGZVsNCy5TjkbYamYBKzplpyTh7QssCs/GpXR77hXkVBnr3yn ZHuDceSPxDlva7cho2aLZFxnOK04lHxL2NoAPA61182Ku8SSkh75QuFsR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAEWGnlOtJssW/2dsb2JhbABahyWmewEBAQMFAZYSgxIBgSJ1hAMBAQEDASNVEQsYAgIFFgsCAgkDAgECAUUGAQwIAQEXiB8IsQGdcheBKoQ5iDERAVeCd4FMAQOaQ5NYg0I7gTo X-IronPort-AV: E=Sophos;i="5.01,484,1400025600"; d="scan'208";a="83155245" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 16 Jun 2014 05:58:41 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.203.80]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5G5wfvn030735; Mon, 16 Jun 2014 05:58:41 GMT Message-ID: <539E8791.4070901@cisco.com> Date: Mon, 16 Jun 2014 07:58:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <539E30F3.1050306@iang.org> In-Reply-To: <539E30F3.1050306@iang.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/HfOfDgX0Hmc_xzSF1DGmQIjaQJM Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 05:58:46 -0000 On 6/16/14, 1:49 AM, ianG wrote: > On 15/06/2014 17:43 pm, Viktor Dukhovni wrote: >> How would you like to express this better? I did not mean to >> disparage TOFU. SSH works well enough because it is not used to >> connect to arbitrary hosts, any one user generally only logs in to >> a relatively small set of systems (as compared with web sites they >> visit, domains they might send email to, ...). >> >> So I am not trying to disparage TOFU, merely suggest that it does >> not generally scale to authenticating any peer on the Internet. Just to come back to this point, I like the examination of design space. Here's something to keep in mind: we are increasing the number of devices we have in our homes, and that is an area that at least today is not well served by X.509-based certificates. TOFU or something like it seems more important, because you're not looking for certification that Eliot Lear is THE Eliot Lear who has paid a few bucks for a cert, but just that I happen to be the same guy who wanted to configure the printer/thermostat/refrigerator/... the last time 'round. And add to the mix a lack of DNS, use of mDNS/Bonjour, and it really is its own thing. Even ssh-style TOFU does serve us well there. Now a perfectly reasonable thing to say might be that the fundamental problem is the lack of unified name space, but rather than waiting for that, perhaps a few words around this problem space and appropriate solutions might be useful. Eliot From nobody Sun Jun 15 23:03:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827221B2A98 for ; Sun, 15 Jun 2014 23:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMnzs_2syIcq for ; Sun, 15 Jun 2014 23:03:07 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A7EC1B2A9A for ; Sun, 15 Jun 2014 23:03:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=253; q=dns/txt; s=iport; t=1402898587; x=1404108187; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=gfeHV9gHAF52e/IoTigAxxEyqTSPh1WSRI6fkSUr/0I=; b=J/smN+4P4oqmy/AmukAXAqSmsM+gcW/ufDUKmd5Mer+SAo+xF4JQexu4 UlRhi9TEAyRh0lfb9o5GAc/sKjsCWzEJmio4Fckst+bkul/bmQHAzs7bZ 4F6U4tugrOwmGMbHjr6xS3aKPsWukDV59rOZsptn1s0ask9aKdFVhq+P6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFALCHnlOtJssW/2dsb2JhbABahyWKJJxXAQEBAwUBmSQBgSN1hAMBAQEEI1URCxgCAgUWCwICCQMCAQIBRQYBDAgBAYg+sQWdcheBKoQ5iRqCd4FMAQOaQ5NYg0I7 X-IronPort-AV: E=Sophos;i="5.01,484,1400025600"; d="scan'208";a="83158908" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 16 Jun 2014 06:03:05 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.203.80]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s5G635bN006219; Mon, 16 Jun 2014 06:03:05 GMT Message-ID: <539E8899.5090408@cisco.com> Date: Mon, 16 Jun 2014 08:03:05 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: ianG , saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <539E30F3.1050306@iang.org> <539E8791.4070901@cisco.com> In-Reply-To: <539E8791.4070901@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/7ZaedKIC3-wRrebl_OgBRzOhxS4 Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 06:03:08 -0000 Ahem... On 6/16/14, 7:58 AM, Eliot Lear wrote: > > ....And add to > the mix a lack of DNS, use of mDNS/Bonjour, and it really is its own > thing. Even ssh-style TOFU does serve us well there. That should be "... does NOT serve us well there." From nobody Mon Jun 16 07:00:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB751A0034; Mon, 16 Jun 2014 07:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAYrIuVJwdur; Mon, 16 Jun 2014 07:00:30 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 289641A003A; Mon, 16 Jun 2014 07:00:24 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s5GE0LA6006306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Jun 2014 09:00:23 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s5GE0L1h022215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Jun 2014 16:00:21 +0200 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.240]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 16 Jun 2014 16:00:21 +0200 From: "FOSSATI, Thomas (Thomas)" To: "saag@ietf.org" Thread-Topic: New Version Notification for draft-fossati-dtls-over-gsm-sms-00.txt Thread-Index: AQHPiWOM4hux6nsRm0SbWD3JXkPFcA== Date: Mon, 16 Jun 2014 14:00:20 +0000 Message-ID: References: <20140616130407.11150.52339.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2254E5C2A22F98409DCB62311C88E581@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rWwRdElPb6JfbL9VbjNski-dxXI Cc: "dtls-iot@ietf.org" , "tls@ietf.org" Subject: [saag] Fwd: New Version Notification for draft-fossati-dtls-over-gsm-sms-00.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:00:40 -0000 Hi all, I=92ve just uploaded this new I-D about layering DTLS on top of an SMS bear= er. (Its main use-case is in the OMA Lightweight M2M spec.) Any feedback from you sec folks would be very welcome. TLS and DICE mailing lists have been copied in as well as this may (or may = not) be relevant to those working groups, but I=92d rather let SAAG be the = main collector for comments. Thanks very much, Thomas. Begin forwarded message: > From: > Subject: New Version Notification for draft-fossati-dtls-over-gsm-sms-00.= txt > Date: 16 June 2014 14:04:07 BST > To: Thomas Fossati >=20 >=20 > A new version of I-D, draft-fossati-dtls-over-gsm-sms-00.txt > has been successfully submitted by Thomas Fossati and posted to the > IETF repository. >=20 > Name: draft-fossati-dtls-over-gsm-sms > Revision: 00 > Title: Datagram Transport Layer Security (DTLS) over Global System for M= obile Communications (GSM) Short Message Service (SMS) > Document date: 2014-06-16 > Group: Individual Submission > Pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-fossati-dtls-ov= er-gsm-sms-00.txt > Status: https://datatracker.ietf.org/doc/draft-fossati-dtls-over-= gsm-sms/ > Htmlized: http://tools.ietf.org/html/draft-fossati-dtls-over-gsm-sm= s-00 >=20 >=20 > Abstract: > This document specifies the use of Datagram Transport Layer Security > (DTLS) over the Global System for Mobile Communications (GSM) Short > Message Service (SMS). >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Mon Jun 16 07:42:26 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525811A003B for ; Mon, 16 Jun 2014 07:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6hQnFhagKq9 for ; Mon, 16 Jun 2014 07:42:21 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9FA1A0041 for ; Mon, 16 Jun 2014 07:42:20 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id q8so814435lbi.20 for ; Mon, 16 Jun 2014 07:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RjkuvNn2DSHNN+xXejbZnOnaEToNKxgUo6WMhBo7cc4=; b=gRWKNRi30b/pwmM0zRpDa67rcic+xBM+2kSca5YEhy5GjEAnXmUAvj66pI+8R0zuv7 Bdmn+hm1cM4ou+IoK66yBqmQj+Ods+sU8ez088DpHWla4/Mcy0yeoTP8QXjCsNw8OXpd b5HJKvW0QRDX5V09yXXRjdRYE6o1IUc/skE8nK0WRxLwDgP5vHXpeTP0bi4pdH4zVH3J wPrmwf3fCTr78/1uOaFoTGCXVk5xja94oNdDvoE5YdGKHKZ73BGA6IH/2w5ray9RrAg3 5zC1zw4kPiGHFU50NWy24cJQYKkSZAF5RgX/G3zlw46pWqsQqjn/Nbg0PO5o2Vnwq9aj tZgQ== MIME-Version: 1.0 X-Received: by 10.152.28.194 with SMTP id d2mr14531798lah.25.1402929738867; Mon, 16 Jun 2014 07:42:18 -0700 (PDT) Received: by 10.112.33.36 with HTTP; Mon, 16 Jun 2014 07:42:18 -0700 (PDT) In-Reply-To: <18924.1402682912@sandelman.ca> References: <18924.1402682912@sandelman.ca> Date: Mon, 16 Jun 2014 10:42:18 -0400 Message-ID: From: Kathleen Moriarty To: saag@ietf.org Content-Type: multipart/mixed; boundary=089e0160b420bafe8604fbf508ee Archived-At: http://mailarchive.ietf.org/arch/msg/saag/3aGhe52xTkij8vkBHdBSIZrAemA Subject: [saag] Fwd: third call: NomCom 2014-2015 Call for Volunteers X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:42:24 -0000 --089e0160b420bafe8604fbf508ee Content-Type: multipart/alternative; boundary=089e0160b420bafe8104fbf508ec --089e0160b420bafe8104fbf508ec Content-Type: text/plain; charset=UTF-8 In case you have not seen the NONCOM call for volunteers, I am forwarding it for those that might be interested to put their name in. If you are selected, you wouldn't be eligible to run for one of the positions that will be opening up. Thanks, Kathleen ---------- Forwarded message ---------- From: Michael Richardson Date: Fri, Jun 13, 2014 at 2:08 PM Subject: third call: NomCom 2014-2015 Call for Volunteers To: ietf@ietf.org This is the third call for volunteers. VOLUNTEER NOW: we need to make 200. The DEADLINE is June 26 to volunteer. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). If your name is on the below, then you have volunteered and are qualified. In addition to those who volunteered by email, it also includes those who indicated their willingness to serve on the IETF90 registration form, and whose eligibility has been confirmed. 54 people were confirmed to be eligible, and 70 people were not confirmed based upon the email they have used to register. Those 124 people have been contacted directly. If you have heard from me, but are not on the list, then there is some problem, and you should have gotten a query from me to determine your eligibility. If you have volunteered and not heard from him, then please resend; it got lost. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! We are at 123 volunteers so far, and WE NEED TO HAVE 200!!! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following 4 lines the email body (it is simplest if you just include the info); Your Full Name Emails used to register Telephone Current Primary Affiliation You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org ===== qualified volunteers so far, in alphabetical order by first name ANM Zaheduzzaman Sarker Adam Montville Ari Ker?nen Benson Schliesser Bhumip Khasnabish Bill VerSteeg Carl Williams Carlos Martinez Charles Eckel Charles Perkins Christer Holmberg Craig White DHRUV DHODY Dacheng Zhang Damien Saucez Dapeng Liu Dean Bogdanovic Dimitri Papadimitriou Donald Eastlake Edward Crabbe Emil Ivov Eric Rescorla Eric VYNCKE Fangwei Hu Fatai Zhang Fernando Gont Fred Baker Giles Heron Gonzalo Salgueiro Gregory Mirsky Hannes Gredler Hongyu Li Hosnieh Rafiee Hugo Salgado Hui Deng Iuniana Oprescu Jeff Tantsura John Drake John Jason Brzozowski John Levine John Scudder Jon Hudson Jon Mitchell Karen O'Donoghue Karen Seo Kaveh Ranjbar Klaas Wierenga Larry Masinter Lars Eggert Lee Howard Lei Zhu Li Xue Linda Dunbar Lingli Deng Louis (Lou) Berger Luca Martini Lucy Lynch Lucy Yong Luigi Iannone Mach Chen Marcelo Bagnulo Mark Townsley Matt Lepinski Matthew Bocci Mehmet Ersue Melinda Shore Michael Jones Min Ye Mingui Zhang Ning Zong Ole Troan Pascal Thubert Paul Hoffman Peter Lothberg Peter Yee QIN WU Ralph Droms Ron Bonica Ross Callon Ross Finlayson Russ White Sam K. Aldrin Samuel Weiler Sandeep Kumar Sanjay Mishra Scott Mansfield Sheng JIANG Shucheng Liu Simon Pietro Romano Stan Ratliff Stephan Friedl Stephan Wenger Stephen Kent Stewart Bryant Stig Venaas Suhas Nandakumar Suresh Krishnan Susan Hares Thomas Walsh Tim Wicinski Tissa Senevirathne Toerless Eckert Tony Hansen Ulrich Herberg Varun Singh Wassim Haddad Xiaohu XU Yi Zhao Yizhou Li Yong Cui Yuanlong Jiang Yunfei Zhang Zhaohui Zhang Zhen Cao iuniana oprescu -- Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org -- Best regards, Kathleen --089e0160b420bafe8104fbf508ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In case you have not seen the NONCOM call for volunteers, = I am forwarding it for those that might be interested to put their name in.= =C2=A0If you are selected, you wouldn't be eligible to run for one of = the positions that will be opening up.

Thanks,
Kathleen

---------- Forwarded message ----------
From: Michael Richardson <mcr+nomcom@sandelman.ca>
Date: Fri, Jun 13, 2014 at 2:08 PM
Subject: third call: NomCom 2014-2015= Call for Volunteers
To: ietf@ietf.org<= /a>



This is the third call for volunteers.
VOLUNTEER NOW: we need to make 200.
The DEADLINE is June 26 to volunteer.

The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,=
and the IESG (including IETF Chair).

If your name is on the below, then you have volunteered and are qualified.<= br> In addition to those who volunteered by email, it also includes those who indicated their willingness to serve on the IETF90 registration form, and whose eligibility has been confirmed. =C2=A054 people were confirmed to be<= br> eligible, and 70 people were not confirmed based upon the email they have used to register. =C2=A0 Those 124 people have been contacted directly.

If you have heard from me, but are not on the list, then there is some
problem, and you should have gotten a query from me to determine your
eligibility.

If you have volunteered and not heard from him, then please resend;
it got lost.

Ten voting members for the nomcom are selected in a verifiably random
way from a pool of volunteers. The more volunteers, the better chance we ha= ve
of choosing a random yet representative cross section of the IETF populatio= n.

Let's break the 200 volunteer mark again this year!
We are at 123 volunteers so far, and WE NEED TO HAVE 200!!!

The details of the operation of the nomcom can be found in RFC 3777,
and BCP10/RFC3797 details the selection algorithm.

Volunteers must have attended 3 of the past 5 IETF meetings. =C2=A0As speci= fied in
RFC 3777, that means three out of the five past meetings up to the time thi= s
email announcement goes out to start the solicitation of volunteers.
The five meetings out of which you must have attended *three*
are IETF 85(Atlanta), =C2=A0 =C2=A0 =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A086(Orlando), =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A087(Berlin), =C2=A0 =C2=A0 =C2=A0 =C2=A0 *= ** ANY THREE!
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A088(Vancouver), =C2=A0 =C2=A0 /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A089(London) =C2=A0 =C2=A0 =C2=A0 =C2=A0/
If you qualify, please volunteer. =C2=A0 However, much as we want this, bef= ore you
decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible.

The list of people and posts whose terms end with the March 2015 IETF
meeting, and thus the positions for which this nomcom is responsible, are
IAOC:
To be confirmed

IAB:
Joel Halpern
Russ Housley
Eliot Lear
Xing Li
Andrew Sullivan
Dave Thaler

IESG:
Pete Resnick (Applications)
Ted Lemon (Internet)
Joel Jaeggli (Operations and Management)
Richard Barnes (RAI)
Adrian Farrel* (Routing)
Stephen Farrell (Security)
Spencer Dawkins (Transport)
Jari Arkko (Gen)

(names with * have publically indicated they will not serve another term)
The primary activity for this nomcom will begin in July 2014 and should be<= br> completed in January 2015. =C2=A0 The nomcom will have regularly scheduled<= br> conference calls to ensure progress. (We might dogfood WebRTC)
There will be activities to collect requirements from the community, review=
candidate questionnaires, review feedback from community members about
candidates, and talk to candidates.

Thus, being a nomcom member does require some time commitment; but it is al= so
a very rewarding experience.

It is very important that you be able to attend IETF91 to conduct interview= s.
Being at IETF90 is useful for training. =C2=A0Being at IETF92 is not essent= ial.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours)<= br> June 22, 2013, as follows:

To: nomcom-chair-2014@ietf.or= g
Subject: Nomcom 2014-15 Volunteer

Please include the following 4 lines the email body (it is simplest
if you just include the info);

Your Full Name
Emails used to register
Telephone
Current Primary Affiliation

You should expect an email response from me within 3 business days stating<= br> whether or not you are qualified. =C2=A0If you don't receive this respo= nse,
please re-send your email with the tag "RESEND"" added to th= e subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership of the IETF. =C2=A0Questions by email or voice are welcome.
Volunteering for the nomcom is a great way to contribute to the IETF!

You can find a detailed timeline on the nomcom web site at:
=C2=A0 =C2=A0 https://datatracker.ietf.org/nomcom/2014/

I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process,
within the next couple weeks.

Thank you!
Michael Richardson
mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org

=3D=3D=3D=3D=3D =C2=A0qualified volunteers so far, in alphabetical order by= first name
ANM Zaheduzzaman Sarker
Adam Montville
Ari Ker?nen
Benson Schliesser
Bhumip Khasnabish
Bill VerSteeg
Carl Williams
Carlos Martinez
Charles Eckel
Charles Perkins
Christer Holmberg
Craig White
DHRUV DHODY
Dacheng Zhang
Damien Saucez
Dapeng Liu
Dean Bogdanovic
Dimitri Papadimitriou
Donald Eastlake
Edward Crabbe
Emil Ivov
Eric Rescorla
Eric VYNCKE
Fangwei Hu
Fatai Zhang
Fernando Gont
Fred Baker
Giles Heron
Gonzalo Salgueiro
Gregory Mirsky
Hannes Gredler
Hongyu Li
Hosnieh Rafiee
Hugo Salgado
Hui Deng
Iuniana Oprescu
Jeff Tantsura
John Drake
John Jason Brzozowski
John Levine
John Scudder
Jon Hudson
Jon Mitchell
Karen O'Donoghue
Karen Seo
Kaveh Ranjbar
Klaas Wierenga
Larry Masinter
Lars Eggert
Lee Howard
Lei Zhu
Li Xue
Linda Dunbar
Lingli Deng
Louis (Lou) Berger
Luca Martini
Lucy Lynch
Lucy Yong
Luigi Iannone
Mach Chen
Marcelo Bagnulo
Mark Townsley
Matt Lepinski
Matthew Bocci
Mehmet Ersue
Melinda Shore
Michael Jones
Min Ye
Mingui Zhang
Ning Zong
Ole Troan
Pascal Thubert
Paul Hoffman
Peter Lothberg
Peter Yee
QIN WU
Ralph Droms
Ron Bonica
Ross Callon
Ross Finlayson
Russ White
Sam K. Aldrin
Samuel Weiler
Sandeep Kumar
Sanjay Mishra
Scott Mansfield
Sheng JIANG
Shucheng Liu
Simon Pietro Romano
Stan Ratliff
Stephan Friedl
Stephan Wenger
Stephen Kent
Stewart Bryant
Stig Venaas
Suhas Nandakumar
Suresh Krishnan
Susan Hares
Thomas Walsh
Tim Wicinski
Tissa Senevirathne
Toerless Eckert
Tony Hansen
Ulrich Herberg
Varun Singh
Wassim Haddad
Xiaohu XU
Yi Zhao
Yizhou Li
Yong Cui
Yuanlong Jiang
Yunfei Zhang
Zhaohui Zhang
Zhen Cao
iuniana oprescu


--
Michael Richardson
mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org






--

Best regards,
Kathleen
--089e0160b420bafe8104fbf508ec-- --089e0160b420bafe8604fbf508ee Content-Type: application/pgp-signature Content-Disposition: attachment Content-Transfer-Encoding: base64 X-Attachment-Id: dd79a84fbec698a8_0.1 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIgKEdO VS9MaW51eCkNCg0KaVFFVkF3VUJVNXMrSFlDTGNQdmQwTjFsQVFJU3lnZ0FsamlQZlovaXRDbDIz V0FrTW9pcjlYS0ZkOVRBSFN4cw0KaGIyQmU1azdmZVI1QSszTEVrL3JnSCtCc1RqbnVYOGNjQW1u aVZqTTg4LzE0L1lsTTlxNkhlTnpZckNlZFcwdw0KWDBGeXNoTjAxVXBIeWx3aGd4d2VTMUwyclEx TXl3c0prV3J4K1ROc2xGMk02dEhzL1I5cVdjY0MwK29iRWQrQQ0KY1I2amtnelhiaUFsTnlzR2lt V3FwenhscnRhdWtRa3dHMy9saVZqNDVMRmxNZmlFVjFVV0t1NUtSRnl4NFdSTg0KQXovOTFJRkU2 OUtmTkZKbUxieDFSTGdsWXkreDk0UGpZbXprWFRXN1NJdHdhV1R1L0NvalJvWnE5cXE2VSs0Rg0K OURod00xVTBQNTM5ZDJ4TjBGdFlBTjVKOFZrNi8zYmZUSlFuUjhNSE1HbUU4QVNUNDU1S0F3PT0N Cj0vMFdPDQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0= --089e0160b420bafe8604fbf508ee-- From nobody Mon Jun 16 08:25:31 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14B01A008A for ; Mon, 16 Jun 2014 08:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIcs_riESeEv for ; Mon, 16 Jun 2014 08:25:18 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 982341A007D for ; Mon, 16 Jun 2014 08:25:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5GFOw4d017552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 08:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402932312; x=1403018712; bh=t9ebpFd70OUngVMxA4wM+/yPBAOhpZ+WfC6hlDhyNq8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=uxcdUGV1L+haz6LmdqY1cf/hCEgt0VSRfA0HH4zfE+Rcb4E6lFmzmDtYJLvNa/P+c OXPM2Hv9o2CeCcUJL8oSYcOHna2oc/cMwQFmPTBeHjo4PzVyO7+dbk4IJStrxlITmS Yyan4SnGvkBu/0wZkOjXaxTZo4CfL8/KeY1ijrIU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402932312; x=1403018712; i=@elandsys.com; bh=t9ebpFd70OUngVMxA4wM+/yPBAOhpZ+WfC6hlDhyNq8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=2CJjNN588RvnivNKl+clcwLrPRzK6bMcXxgOnzSzA7epOOvlCzUzODe93t/epnBqz HghC38xe0CRdb2S9fvFLJaTm2xHEE/2PBN23YwZnJJ2AK85wMezL2eNwnENLTg9F7j ulmh3bj9432/dCqLiAdGt7SYFCjweiVzxPpJM8Ls= Message-Id: <6.2.5.6.2.20140616063148.0a909250@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jun 2014 07:11:27 -0700 To: saag@ietf.org From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/wUpsFF8-9VzuNt6n6Vj1xvjbdhM Cc: Watson Ladd , Tanja Lange Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:25:20 -0000 At 13:19 15-06-2014, Watson Ladd wrote: >We're dealing with the situation where participants recognize a >security issue and fail to disclose it. Unrecognized issues are a >different >ball of wax: nothing short of careful analysis will work, and there is >always something missed such as RC4 in TLS. > >This happened with an ANSI standard: Certicom recognized there was a >potential for a backdoor early on, but failed to publicise the issue. >When in 2007 it was independently recognized, products based on the >flawed standard were deployed. > >Unforeseen risks will continue to be an issue, but by making clear an >expectation that you disclose what you know, we avoid a repeat of the >DUAL EC situation. As background information, and to their credit [1], Tanja Lange and Watson Ladd publicly raised the issue on the (IRTF) CRFG mailing list. I'll simplify the issue as: how not to repeat the DUAL EC problem. The alternatives I could think of are: (i) Not to reference ANSI publications in IETF standards (ii) Not to reference CFRG publications in IETF standards (iii) Ignore the issue The rationale for (i) and (ii) might be that the guidelines for companies participating in these bodies are not clear. Regards, S. Moonesamy 1. This is intended as positive From nobody Mon Jun 16 08:39:54 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6FA1A007E for ; Mon, 16 Jun 2014 08:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWMoVCZCH6fH for ; Mon, 16 Jun 2014 08:39:51 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2021A007B for ; Mon, 16 Jun 2014 08:39:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71A8FBF6C; Mon, 16 Jun 2014 16:39:50 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBEFP2lAmfYU; Mon, 16 Jun 2014 16:39:50 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4BEFCBF63; Mon, 16 Jun 2014 16:39:50 +0100 (IST) Message-ID: <539F0FC7.7080809@cs.tcd.ie> Date: Mon, 16 Jun 2014 16:39:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: S Moonesamy , saag@ietf.org References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> <6.2.5.6.2.20140616063148.0a909250@elandnews.com> In-Reply-To: <6.2.5.6.2.20140616063148.0a909250@elandnews.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FchHMA1PEDxZdAjSgi1j_118JLE Cc: Watson Ladd , Tanja Lange Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 15:39:52 -0000 On 16/06/14 15:11, S Moonesamy wrote: > At 13:19 15-06-2014, Watson Ladd wrote: >> We're dealing with the situation where participants recognize a >> security issue and fail to disclose it. Unrecognized issues are a >> different >> ball of wax: nothing short of careful analysis will work, and there is >> always something missed such as RC4 in TLS. >> >> This happened with an ANSI standard: Certicom recognized there was a >> potential for a backdoor early on, but failed to publicise the issue. >> When in 2007 it was independently recognized, products based on the >> flawed standard were deployed. >> >> Unforeseen risks will continue to be an issue, but by making clear an >> expectation that you disclose what you know, we avoid a repeat of the >> DUAL EC situation. > > As background information, and to their credit [1], Tanja Lange and > Watson Ladd publicly raised the issue on the (IRTF) CRFG mailing list. > I'll simplify the issue as: how not to repeat the DUAL EC problem. Well, the IETF hasn't had a DUAL-EC problem really. We don't afaik refer to that in any RFC that I can think of, at least not directly. And when the various extended random proposals were made those were not adopted thankfully. (Which could be our process working well, or could be luck, I doubt we can tell post-facto.) > The > alternatives I could think of are: I'm not at all convinced those are a good set of options. But I do have a comment on (ii). > > (i) Not to reference ANSI publications in IETF standards > > (ii) Not to reference CFRG publications in IETF standards I'd be strongly against (ii). The IRTF operate the same IPR rules as the IETF (by their choice) precisely so that we can transition work from the IRTF to the IETF. > (iii) Ignore the issue > > The rationale for (i) and (ii) might be that the guidelines for > companies participating in these bodies are not clear. Anyway, you referred to RFC 7154 [1] before (and did so nicely modestly:-). Isn't that plus the usual IPR rules about as good as we can do really? Or do folks think there's benefit in being more specific about security or crypto or something there? S. [1] https://tools.ietf.org/html/rfc7154 > > Regards, > S. Moonesamy > > 1. This is intended as positive > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From nobody Mon Jun 16 09:15:30 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09901A0102 for ; Mon, 16 Jun 2014 09:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPnVeP7cekrl for ; Mon, 16 Jun 2014 09:15:26 -0700 (PDT) Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10771A00F0 for ; Mon, 16 Jun 2014 09:15:26 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id q58so6023575wes.30 for ; Mon, 16 Jun 2014 09:15:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M0xOGZ4zi9hkT5d9h8Nt1ZizxoNy5FP4O03Re6Mc6Dk=; b=cUNy6/kX4R4Up/QYPHZEem1+el8O4QCMbmS47gnpJttWq546Qwwq3N6uEEXIR9s79m KZ0GG8WnPPcVF9KcrZKENj+utNPGgXLOt9vMIOmo0ymKYAlbaoTXfuOO6dNGiytwfhiU sGOVt70bMAOsIMNM1oLIz9HVb4rD3EK0ie9opEFfyXCmZL0LX41tvlL7+KKi0wQ4/Iqw CwUKXOGBCp1HMsiA19hlY74qK5n6qtL55mMdNilfYWygkTvpFfEqvuCefcOywMj2A8Bd 4m6HNvaRZX+UgBrF/1VDJvqWLgfVsWiHGngaFN3EVWj1TZ+LIvtVsaqwH6D7zMEs3ZAu ZzIw== X-Gm-Message-State: ALoCoQnpwiryqUKTZ1RvMwO+/+HdgwsgP8mjkuEA94+md17kW1Z1HYTGSLwvlDWG88MCk2KyDIQz MIME-Version: 1.0 X-Received: by 10.180.211.36 with SMTP id mz4mr28951321wic.20.1402935325112; Mon, 16 Jun 2014 09:15:25 -0700 (PDT) Received: by 10.216.155.7 with HTTP; Mon, 16 Jun 2014 09:15:25 -0700 (PDT) X-Originating-IP: [70.36.227.134] In-Reply-To: <539F0FC7.7080809@cs.tcd.ie> References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> <6.2.5.6.2.20140616063148.0a909250@elandnews.com> <539F0FC7.7080809@cs.tcd.ie> Date: Mon, 16 Jun 2014 09:15:25 -0700 Message-ID: From: Trevor Perrin To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zS45RU31ohT8TxM7HSNKnK9iZSc Cc: Tanja Lange , Watson Ladd , S Moonesamy , saag@ietf.org Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:15:29 -0000 On Mon, Jun 16, 2014 at 8:39 AM, Stephen Farrell wrote: > > Well, the IETF hasn't had a DUAL-EC problem really. We don't > afaik refer to that in any RFC that I can think of, at least > not directly. And when the various extended random proposals > were made those were not adopted thankfully. Not true - see RFC 6358: http://www.ietf.org/mail-archive/web/tls/current/msg11753.html Trevor From nobody Mon Jun 16 09:47:50 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98041A0114 for ; Mon, 16 Jun 2014 09:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xp8BRmCVd9TG for ; Mon, 16 Jun 2014 09:47:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 488411A010F for ; Mon, 16 Jun 2014 09:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 11D39BF7C; Mon, 16 Jun 2014 17:47:42 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neNZaphhehLe; Mon, 16 Jun 2014 17:47:40 +0100 (IST) Received: from [10.87.48.12] (unknown [86.45.62.0]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A291BBF4E; Mon, 16 Jun 2014 17:47:40 +0100 (IST) Message-ID: <539F1FAC.8080902@cs.tcd.ie> Date: Mon, 16 Jun 2014 17:47:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Trevor Perrin References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> <6.2.5.6.2.20140616063148.0a909250@elandnews.com> <539F0FC7.7080809@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Gu7a-sOfDsx4Fqq2-O8kh0Ilajk Cc: Tanja Lange , Watson Ladd , S Moonesamy , saag@ietf.org Subject: [saag] RFC6358 (was: Re: Obligations of Candor) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 16:47:47 -0000 On 16/06/14 17:15, Trevor Perrin wrote: > On Mon, Jun 16, 2014 at 8:39 AM, Stephen Farrell > wrote: >> >> Well, the IETF hasn't had a DUAL-EC problem really. We don't >> afaik refer to that in any RFC that I can think of, at least >> not directly. And when the various extended random proposals >> were made those were not adopted thankfully. > > Not true - see RFC 6358: > > http://www.ietf.org/mail-archive/web/tls/current/msg11753.html Ah, I guess yes you're right. Thanks for the correction. Though there's no such extension defined I think, right? In which case there's no actual harm done to the protocol, though perhaps a bit of process harm maybe. Does anyone have a use for 6358 or should we obsolete it or make it historic? S. > > Trevor > > From nobody Mon Jun 16 11:42:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8731A015B for ; Mon, 16 Jun 2014 11:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBB0FHsq7GHm for ; Mon, 16 Jun 2014 11:42:15 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE00D1A014E for ; Mon, 16 Jun 2014 11:42:15 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5GIflah012580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2014 11:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402944122; x=1403030522; bh=pUyvMI+aaouBNdByASIweRJ+yoBBQViPNAvHXNXQJ/k=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qYEuKOu0mdP3Tp+9ef8TK/HWqlwPwPrW7rVrOJCs5sNC/k7DTA+JNNy6LsGqbE9PL gd+rHHk0EsuS+NRRcMn3t8CKG/tYeyN8BsakLg4pB6Ft7UIKmJUppIMYpALTdYArZL yVLkGJHSVeztyp88OLzXULiuc3JqsDjShWhh+BFE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402944122; x=1403030522; i=@elandsys.com; bh=pUyvMI+aaouBNdByASIweRJ+yoBBQViPNAvHXNXQJ/k=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VpunvbXX7n0nbgVQ+Gl20xcdMkoIpR8VwenseTww7fG69loF35nKHPN3YoU6pAXDj jAiVoUFAA/rcNREWp1FOp5up/sqj4cY0mw9AqS3F8SZLCM9msP7+5rhsLTJTybkBP1 QF2aTZp/NX+67AgIAMV6HJWEnbfwW015lYr/31sc= Message-Id: <6.2.5.6.2.20140616095821.0ad04798@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jun 2014 11:37:44 -0700 To: Stephen Farrell , saag@ietf.org From: S Moonesamy In-Reply-To: <539F0FC7.7080809@cs.tcd.ie> References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> <6.2.5.6.2.20140616063148.0a909250@elandnews.com> <539F0FC7.7080809@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/saag/EpP2jGkYevoKamwbKNa-SNsZxr0 Cc: Watson Ladd , Tanja Lange Subject: Re: [saag] Obligations of Candor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 18:42:19 -0000 Hi Stephen, At 08:39 16-06-2014, Stephen Farrell wrote: >Anyway, you referred to RFC 7154 [1] before (and did so >nicely modestly:-). Isn't that plus the usual IPR rules >about as good as we can do really? Or do folks think >there's benefit in being more specific about security >or crypto or something there? I'll be candid. It is very difficult to get IETF agreement on rules. RFC 7154 is simply "please let's try this". There are extensive notes about patents at https://projectbullrun.org/dual-ec/patent.html It is up to the people responsible for IPR rules to see whether those rules are good enough. I honestly don't know whether there is or has been a violation of those rules (in relation to the issue). I'll leave the last question (quoted above) to readers of the mailing list. Regards, S. Moonesamy From nobody Mon Jun 16 13:11:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA7A1A01C9 for ; Mon, 16 Jun 2014 13:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIsK6E_Zuisn for ; Mon, 16 Jun 2014 13:11:36 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326DE1A01C7 for ; Mon, 16 Jun 2014 13:11:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 28411E2035 for ; Mon, 16 Jun 2014 16:11:34 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 17706-08 for ; Mon, 16 Jun 2014 16:11:31 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id B1057E2033 for ; Mon, 16 Jun 2014 16:11:31 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s5GKBUpO028823; Mon, 16 Jun 2014 16:11:30 -0400 From: Derek Atkins To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> Date: Mon, 16 Jun 2014 16:11:30 -0400 In-Reply-To: <20140615164333.GM8358@mournblade.imrryr.org> (Viktor Dukhovni's message of "Sun, 15 Jun 2014 16:43:33 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/BiZFJ1fWzaw9hBYSaEP5nbULlQI Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:11:39 -0000 Viktor Dukhovni writes: > On Sun, Jun 15, 2014 at 08:01:07AM -0700, Bernard Aboba wrote: > >> One concern about the draft is the denigration of TOFU. SSH is >> very widely used and characterizing it as "fragile" does not match >> my experience, although key continuity obviously has some drawbacks. >> The physician's credo "First, do no harm" should also apply here. > > Thanks for the feedback. I wrote: > > Encryption is easy, but key management is difficult. Key management at > Internet scale remains an incompletely solved problem. The PKIX ([RFC5280]) > key management model introduces costs that not all peers are willing to > bear and is also not sufficient to secure communications when the peer > reference identity is obtained indirectly over an insecure channel or > communicating parties don't agree on a mutually trusted certification > authority (CA). DNSSEC is not at this time sufficiently widely adopted to > make DANE a viable alternative at scale. Trust on first use (TOFU) key > management models (as with saved SSH fingerprints and various certificate > pinning approaches) are fragile and require user intervention when key > continuity fails. > > How would you like to express this better? I did not mean to > disparage TOFU. SSH works well enough because it is not used to > connect to arbitrary hosts, any one user generally only logs in to > a relatively small set of systems (as compared with web sites they > visit, domains they might send email to, ...). > > So I am not trying to disparage TOFU, merely suggest that it does > not generally scale to authenticating any peer on the Internet. > > I could remove the two words "are fragile", if they are seen too > judgemental and not essential to make the point. I think that's a good start. I would reword the last sentence to read: Trust on first use (TOFU) key management models (as with saved SSH fingerprints and various certificate pinning approaches) provide key continuity across multiple sessions but require user intervention when key continuity fails. For the record, I have 285 entries in my SSH known hosts file. While not in the millions, it's still a decent sample IMHO. I find I need to change keys.... rarely. And normally only at my own doing so I know to expect it. I think I've had to change keys less than a half-dozen times. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Mon Jun 16 13:33:34 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA9C1A01FB for ; Mon, 16 Jun 2014 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpsZ-Xh_szDd for ; Mon, 16 Jun 2014 13:33:30 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029CC1A01C8 for ; Mon, 16 Jun 2014 13:33:29 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CABB62AB272; Mon, 16 Jun 2014 20:33:28 +0000 (UTC) Date: Mon, 16 Jun 2014 20:33:28 +0000 From: Viktor Dukhovni To: saag@ietf.org Message-ID: <20140616203328.GF8358@mournblade.imrryr.org> References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/e52BVQKfefhCTK5lHze_8OOpN2U Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: saag@ietf.org List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 20:33:32 -0000 On Mon, Jun 16, 2014 at 04:11:30PM -0400, Derek Atkins wrote: > > I could remove the two words "are fragile", if they are seen too > > judgemental and not essential to make the point. > > I think that's a good start. I would reword the last sentence to read: > > Trust on first use (TOFU) key management models (as with saved SSH > fingerprints and various certificate pinning approaches) provide > key continuity across multiple sessions but require user > intervention when key continuity fails. > > For the record, I have 285 entries in my SSH known hosts file. While > not in the millions, it's still a decent sample IMHO. I find I need to > change keys.... rarely. And normally only at my own doing so I know to > expect it. I think I've had to change keys less than a half-dozen > times. I should perhaps emphasize that the goal of this sentence was not to claim that TOFU is a poor fit for SSH, but rather that the approach is not generally suited to all applications. For example, I don't see it working well for email... All in the context of explaining that we don't have a silver-bullet for Internet-scale authentication, and so ubiquitous security needs to make authentication optional. Should I make it explicit that the remark is intended to suggest that TOFU is not *universally* applicable to all application domains? I was hoping to get away with a concise statement for what is a minor point in an argument that is itself deliberately concise. I want to stay on focus and not deep-dive into any tangential topics. -- Viktor. From nobody Tue Jun 17 01:35:44 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9391A0328 for ; Tue, 17 Jun 2014 01:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG6nvVB1jHHq for ; Tue, 17 Jun 2014 01:35:41 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 795541A0326 for ; Tue, 17 Jun 2014 01:35:41 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.141.9]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5H8Z1sb024250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Jun 2014 01:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1402994119; x=1403080519; bh=M28R0Ff9x7oLI+2HcVEVUXsktiB3EQTAFJtUijXgmBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Yd/AS/jci7wwJQaUp4qYxHNL7QdoaRM5ERfE992LUPTPGBJ2quxy7cX3HLC/Mc8dz q7ocUhYpUgorfZi31GuwJ40B4b050oUwlQM/sL60qObFl7yCRRdV5saB/Di1eTlFik tvPcgyWPfXMFKlCobElqoxjhQREh3ptN1LEf41PU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1402994119; x=1403080519; i=@elandsys.com; bh=M28R0Ff9x7oLI+2HcVEVUXsktiB3EQTAFJtUijXgmBE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hnDTsRTjHB85oql3R0WvLX6D//+p9JguhJb6eqEJ+E5h0/8ZwfBDypqq7vN6ZiYKF w2mEIdb59cKfndCf9WcwWTSSRHHhXUiDNEyzbAQRBIEwEM3CCE8GT4jZFE1fCoaC7f HQT6ka0Ol/djoN+dvdlfE/FkG6jGn5AFFDPtbMP8= Message-Id: <6.2.5.6.2.20140616222345.0b852cd8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 16 Jun 2014 22:54:03 -0700 To: Stephen Farrell , Trevor Perrin From: S Moonesamy In-Reply-To: <539F1FAC.8080902@cs.tcd.ie> References: <6.2.5.6.2.20140615082312.0bb5b700@elandnews.com> <6.2.5.6.2.20140616063148.0a909250@elandnews.com> <539F0FC7.7080809@cs.tcd.ie> <539F1FAC.8080902@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/koqYeAhOs41lygn-bt8xrrAWWsU Cc: Watson Ladd , saag@ietf.org, Tanja Lange Subject: Re: [saag] RFC6358 (was: Re: Obligations of Candor) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 08:35:43 -0000 Hi Stephen, At 09:47 16-06-2014, Stephen Farrell wrote: >Though there's no such extension defined I think, right? In which >case there's no actual harm done to the protocol, though perhaps a >bit of process harm maybe. > >Does anyone have a use for 6358 or should we obsolete it or make >it historic? Quoting Page 5 of http://dualec.org/DualECTLS.pdf "There are many extensions to TLS, but we draw attention to four= particular proposed =AD but not standardized =AD extensions. Each of these= extensions has the side effect of removing the most obvious difficulty in= exploiting Dual EC in TLS, namely the limited amount of randomness broadcast to the attacker. One might guess that these extensions make P-256 less= expensive to exploit in TLS by a factor of 65,536 (and make P-384 and P-521= feasible to exploit), if they are actually implemented; our analysis in Section= 4.1 shows that one of these extensions is in fact=20 implemented in BSAFE, although the actual effect on exploitability is more complicated. None of these extensions have been previously described in connection with Dual EC." For what it is worth ISO/IEC JTC 1/SC 27=20 published an advisory note about one of its=20 international standards. There was a message=20 about RFC 6358 to the TLS mailing list (=20 http://www.ietf.org/mail-archive/web/tls/current/msg11742.html ). My short answer would be to move RFC 6358 to Historic. Regards, S. Moonesamy=20 From nobody Tue Jun 17 08:17:10 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF72C1A0179 for ; Mon, 16 Jun 2014 12:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rezypzdy0wgF for ; Mon, 16 Jun 2014 12:36:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494351A018E for ; Mon, 16 Jun 2014 12:36:21 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1191020011 for ; Mon, 16 Jun 2014 15:40:13 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0DC7563B0E; Mon, 16 Jun 2014 15:35:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EFD6763B0A for ; Mon, 16 Jun 2014 15:35:49 -0400 (EDT) From: Michael Richardson To: saag@ietf.org In-Reply-To: References: <18924.1402682912@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/saag/er-iMt4aOtHAhFpTfyq1qh6wPYM X-Mailman-Approved-At: Tue, 17 Jun 2014 08:17:07 -0700 Subject: Re: [saag] Fwd: third call: NomCom 2014-2015 Call for Volunteers X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 19:36:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Kathleen Moriarty wrote: > In case you have not seen the NONCOM call for volunteers, I am forwar= ding it > for those that might be interested to put their name in. =C2=A0If you= are selected, > you wouldn't be eligible to run for one of the positions that will be= opening > up. Or, to put a more life-preserving spin on the second sentence: - if you are selected, nobody will be able to arm twist you into taking on a larger role at the IETF. or even: - if your name isn't on the volunteer list, your colleagues will assume that you want to be nominated, and will begin to twist your arms. :-) =2D- Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBU59HFYCLcPvd0N1lAQJjiAf+NVFusUownuIxQQZZs9RPYmOLj55DXA1R GL/VNuQzlTOk4UA2VPlYwtsksHNjGnWAKlOPpWW8f+TPOG0fmtMi50P3OI0+WVxe n2rGAyPOPr0UHdkIzNKmmtFfM47qyeLu/rK3SipYJM7dnItRKDitPGPXNqnpGrS5 9drQAlcHR5Rm//iw39f7YmrpyleDUihraXdRarcAjznfwbtEbQ7uUwSYoDdks1Mr LaIU9LUBDaaWZ6mnXU7r7G5+GVFqQVOPRRWxNPIWaEKi7beks62C2c91P60jfXiL nfjmVURhMLzNuhkdhSzqSdlo1C82gH1V/eKmVEouGMCqCy6TQQpQZA== =CPJX -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 17 10:38:49 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CA11A03BD for ; Tue, 17 Jun 2014 10:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jthr6TDvtgyR for ; Tue, 17 Jun 2014 10:38:45 -0700 (PDT) Received: from mail2.ihtfp.org (mail2.ihtfp.org [IPv6:2001:4830:143:1::3a11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FCC1A0340 for ; Tue, 17 Jun 2014 10:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id CB2B1E2038 for ; Tue, 17 Jun 2014 13:38:43 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 25349-09 for ; Tue, 17 Jun 2014 13:38:40 -0400 (EDT) Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mocana.ihtfp.org", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id 496B9E2033 for ; Tue, 17 Jun 2014 13:38:40 -0400 (EDT) Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.7/8.14.7/Submit) id s5HHcdkS011435; Tue, 17 Jun 2014 13:38:39 -0400 From: Derek Atkins To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <20140616203328.GF8358@mournblade.imrryr.org> Date: Tue, 17 Jun 2014 13:38:38 -0400 In-Reply-To: <20140616203328.GF8358@mournblade.imrryr.org> (Viktor Dukhovni's message of "Mon, 16 Jun 2014 20:33:28 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: Maia Mailguard 1.0.2a Archived-At: http://mailarchive.ietf.org/arch/msg/saag/kljohQhebaOZnV6ni2eANp1QmAY Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 17:38:47 -0000 Viktor Dukhovni writes: > On Mon, Jun 16, 2014 at 04:11:30PM -0400, Derek Atkins wrote: > >> > I could remove the two words "are fragile", if they are seen too >> > judgemental and not essential to make the point. >> >> I think that's a good start. I would reword the last sentence to read: >> >> Trust on first use (TOFU) key management models (as with saved SSH >> fingerprints and various certificate pinning approaches) provide >> key continuity across multiple sessions but require user >> intervention when key continuity fails. >> >> For the record, I have 285 entries in my SSH known hosts file. While >> not in the millions, it's still a decent sample IMHO. I find I need to >> change keys.... rarely. And normally only at my own doing so I know to >> expect it. I think I've had to change keys less than a half-dozen >> times. > > I should perhaps emphasize that the goal of this sentence was not > to claim that TOFU is a poor fit for SSH, but rather that the > approach is not generally suited to all applications. For example, > I don't see it working well for email... All in the context of > explaining that we don't have a silver-bullet for Internet-scale > authentication, and so ubiquitous security needs to make authentication > optional. > > Should I make it explicit that the remark is intended to suggest > that TOFU is not *universally* applicable to all application domains? > I was hoping to get away with a concise statement for what is a > minor point in an argument that is itself deliberately concise. > > I want to stay on focus and not deep-dive into any tangential topics. Fair enough. I did see another wordsmithing option thrown out (after I sent my suggestion) that also tends to help in the same direction. I'm not trying to bog you down in minutia. Mostly I just want to make sure that TOFU doesn't get thrown out entirely just because it does require manual intervention when key continuity fails and because the the initial contact isn't protected. As you say there are multiple use cases for different solutions, and for some use cases TOFU is "good enough". Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From nobody Tue Jun 17 12:09:05 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1771A00C0 for ; Tue, 17 Jun 2014 12:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WW5qEbjF_x6s for ; Tue, 17 Jun 2014 12:08:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9C51A0176 for ; Tue, 17 Jun 2014 12:08:55 -0700 (PDT) Received: from BL2PR03MB290.namprd03.prod.outlook.com (10.141.68.19) by BL2PR03MB292.namprd03.prod.outlook.com (10.141.68.28) with Microsoft SMTP Server (TLS) id 15.0.959.15; Tue, 17 Jun 2014 19:08:53 +0000 Received: from BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) by BL2PR03MB290.namprd03.prod.outlook.com ([10.141.68.19]) with mapi id 15.00.0959.000; Tue, 17 Jun 2014 19:08:53 +0000 From: "Orit Levin (LCA)" To: Derek Atkins , "saag@ietf.org" Thread-Topic: [saag] suggested text for opportunistic definition Thread-Index: AQHPYa7grbmYuN9Y10+Wmk5CQh3bQZsk4UmAgACGTQCACsJugIBCRmsAgAAheICAAByegIABzIbKgAAGDACAAWGR+oAAFReA Date: Tue, 17 Jun 2014 19:08:53 +0000 Message-ID: <25a2bba2e5a6454bb7d26fabb7854ad2@BL2PR03MB290.namprd03.prod.outlook.com> References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <20140616203328.GF8358@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.231.185.158] x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID: x-forefront-prvs: 0245702D7B x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(189002)(199002)(24454002)(164054003)(377454003)(51444003)(13464003)(15202345003)(87936001)(19580395003)(81542001)(101416001)(2171001)(19580405001)(79102001)(80022001)(2656002)(86612001)(74502001)(74662001)(99286002)(95666004)(31966008)(86362001)(20776003)(83322001)(83072002)(81342001)(92566001)(85852003)(99396002)(74316001)(50986999)(64706001)(76482001)(33646001)(77982001)(76576001)(46102001)(93886003)(76176999)(21056001)(54356999)(15975445006)(66066001)(4396001)(85306003)(105586002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB292; H:BL2PR03MB290.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=oritl@microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/IzQSOMe3hh2YdJUgoskoR4rh1kQ Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 19:09:01 -0000 I think that it IS important to capture in a short paragraph how (1) TOFU d= iffers from "OS" and (2) under what circumstances it is (still) applicable. Just having a statement such as "TOFU is not generally suited to all applic= ations" will raise more questions than provides answers. Since we have the experts, the energy, and a couple of good text suggestion= s, please, let's capture their essence in the document. By doing that we mi= ght avoid repeating this debate again and again. =09 Thanks a lot, Orit. > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Derek Atkins > Sent: Tuesday, June 17, 2014 10:39 AM > To: saag@ietf.org > Subject: Re: [saag] suggested text for opportunistic definition >=20 > Viktor Dukhovni writes: >=20 > > On Mon, Jun 16, 2014 at 04:11:30PM -0400, Derek Atkins wrote: > > > >> > I could remove the two words "are fragile", if they are seen too > >> > judgemental and not essential to make the point. > >> > >> I think that's a good start. I would reword the last sentence to read: > >> > >> Trust on first use (TOFU) key management models (as with saved SS= H > >> fingerprints and various certificate pinning approaches) provide > >> key continuity across multiple sessions but require user > >> intervention when key continuity fails. > >> > >> For the record, I have 285 entries in my SSH known hosts file. While > >> not in the millions, it's still a decent sample IMHO. I find I need t= o > >> change keys.... rarely. And normally only at my own doing so I know t= o > >> expect it. I think I've had to change keys less than a half-dozen > >> times. > > > > I should perhaps emphasize that the goal of this sentence was not > > to claim that TOFU is a poor fit for SSH, but rather that the > > approach is not generally suited to all applications. For example, > > I don't see it working well for email... All in the context of > > explaining that we don't have a silver-bullet for Internet-scale > > authentication, and so ubiquitous security needs to make authentication > > optional. > > > > Should I make it explicit that the remark is intended to suggest > > that TOFU is not *universally* applicable to all application domains? > > I was hoping to get away with a concise statement for what is a > > minor point in an argument that is itself deliberately concise. > > > > I want to stay on focus and not deep-dive into any tangential topics. >=20 > Fair enough. >=20 > I did see another wordsmithing option thrown out (after I sent my > suggestion) that also tends to help in the same direction. >=20 > I'm not trying to bog you down in minutia. Mostly I just want to make > sure that TOFU doesn't get thrown out entirely just because it does > require manual intervention when key continuity fails and because the > the initial contact isn't protected. As you say there are multiple use > cases for different solutions, and for some use cases TOFU is "good > enough". >=20 > Thanks, >=20 > -derek >=20 > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Jun 17 12:30:20 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C01A00C0 for ; Tue, 17 Jun 2014 12:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APtpA7pp9lZV for ; Tue, 17 Jun 2014 12:30:17 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F281A014E for ; Tue, 17 Jun 2014 12:30:17 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s5HJTdGJ002893; Tue, 17 Jun 2014 12:30:15 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1mjgjyssef-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 17 Jun 2014 12:30:15 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Tue, 17 Jun 2014 12:30:14 -0700 From: Paul Lambert To: Eliot Lear , ianG , "saag@ietf.org" Date: Tue, 17 Jun 2014 12:30:12 -0700 Thread-Topic: [saag] suggested text for opportunistic definition Thread-Index: Ac+KYo+eXTpr07UOSyyWh80KBircuA== Message-ID: References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <539E30F3.1050306@iang.org> <539E8791.4070901@cisco.com> In-Reply-To: <539E8791.4070901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-17_07:2014-06-17,2014-06-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406170233 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/0yN4iLiWfwMgi4QL9eWtqZ3FR88 Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 19:30:19 -0000 >On 6/16/14, 1:49 AM, ianG wrote: >> On 15/06/2014 17:43 pm, Viktor Dukhovni wrote: > >>> How would you like to express this better? I did not mean to >>> disparage TOFU. SSH works well enough because it is not used to >>> connect to arbitrary hosts, any one user generally only logs in to >>> a relatively small set of systems (as compared with web sites they >>> visit, domains they might send email to, ...). >>> >>> So I am not trying to disparage TOFU, merely suggest that it does >>> not generally scale to authenticating any peer on the Internet. TOFU could be secure and scale when we include out-of-band validation. I also don=B9t feel this is black-and-white with =B3trust=B2. As you learn more about a key, it could have more attributes that would enable different usage models of the key. This would be a "trust it more as you learn more" model. > >Just to come back to this point, I like the examination of design >space. Here's something to keep in mind: we are increasing the number >of devices we have in our homes, and that is an area that at least today >is not well served by X.509-based certificates. TOFU or something like >it seems more important, because you're not looking for certification >that Eliot Lear is THE Eliot Lear who has paid a few bucks for a cert, >but just that I happen to be the same guy who wanted to configure the >printer/thermostat/refrigerator/... the last time 'round. And add to >the mix a lack of DNS, use of mDNS/Bonjour, and it really is its own >thing. Even ssh-style TOFU does serve us well there. Now a perfectly >reasonable thing to say might be that the fundamental problem is the >lack of unified name space, No. =20 > but rather than waiting for that, perhaps a >few words around this problem space and appropriate solutions might be >useful. SSH does not require a =B3name space=B2. The hash of the key is a unique identifier. Bitcoin does not need a unique name space, it hashes keys. Keys and hashes of keys are a universally unique name space. Keys and ids of keys (hash) should come first and subsequent interactions may associate a name to the key. This could be by X.509, DNSEC or manual entry. Paul > >Eliot > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From nobody Tue Jun 17 13:37:37 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3423B1A0168 for ; Tue, 17 Jun 2014 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UassaquY1ioW for ; Tue, 17 Jun 2014 13:37:36 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 986331A010F for ; Tue, 17 Jun 2014 13:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=328; q=dns/txt; s=iport; t=1403037456; x=1404247056; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1tBVkR9XX9s2LFX8dNS07/XKQm/Fx6gZNFSubjpcWak=; b=TREoUcjT9hosoD5rGBK9mXMTpXY53bPCmdLmv+A+hfI8qVa/utGQkpdN Gh7SzXWTg8O90YOLgO0LzwYpWN3JMzt346XmPeiWv90sQo79rzrnsSg1z MX00mbEoYpkk90KOtWDSVecErQKPjLqdK4zf7WrrStH6TMfQtPZQR8TTt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigGAEWmoFOtJssW/2dsb2JhbABahyWnFwEBAQEBAQUBmSYBgSV1hAMBAQEEIw8BRRELGAICBRYLAgIJAwIBAgFFBgEMCAEBiD6rQZ8XF4EqhDmJGoJ3gUwBA5pDk1iDQjs X-IronPort-AV: E=Sophos;i="5.01,496,1400025600"; d="scan'208";a="84870499" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Jun 2014 20:37:34 +0000 Received: from ELEAR-M-C3ZS.CISCO.COM ([10.61.208.85]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5HKbX6w020432; Tue, 17 Jun 2014 20:37:33 GMT Message-ID: <53A0A70D.4070505@cisco.com> Date: Tue, 17 Jun 2014 22:37:33 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Paul Lambert , ianG , "saag@ietf.org" References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <539E30F3.1050306@iang.org> <539E8791.4070901@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/K3pJkUIzyiUXsc6_eNnPgSat7cM Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:37:37 -0000 Paul, On 6/17/14, 9:30 PM, Paul Lambert wrote: > > SSH does not require a ³name space². The hash of the key is a unique > identifier. Sure. Are you proposing that we consider local naming models with that approach? NDN has something similar. FWIW, I am NOT suggesting we address that in this program. Eliot From nobody Tue Jun 17 13:49:23 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1571A0154 for ; Tue, 17 Jun 2014 13:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLZErYWE8lL9 for ; Tue, 17 Jun 2014 13:49:20 -0700 (PDT) Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92C11A010F for ; Tue, 17 Jun 2014 13:49:20 -0700 (PDT) Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id B0EA36D495; Tue, 17 Jun 2014 16:49:16 -0400 (EDT) Message-ID: <53A0A9CB.4010603@iang.org> Date: Tue, 17 Jun 2014 21:49:15 +0100 From: ianG User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: saag@ietf.org References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <20140616203328.GF8358@mournblade.imrryr.org> <25a2bba2e5a6454bb7d26fabb7854ad2@BL2PR03MB290.namprd03.prod.outlook.com> In-Reply-To: <25a2bba2e5a6454bb7d26fabb7854ad2@BL2PR03MB290.namprd03.prod.outlook.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/saag/zx01MS6F39MysPnDxCx7-4tS6ZI Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jun 2014 20:49:22 -0000 On 17/06/2014 20:08 pm, Orit Levin (LCA) wrote: > I think that it IS important to capture in a short paragraph how (1) TOFU differs from "OS" and (2) under what circumstances it is (still) applicable. In which case we need to do the same for all systems? There is a section at bottom "Terminology" where this might be better placed than the rather open discussion at top. > Just having a statement such as "TOFU is not generally suited to all applications" will raise more questions than provides answers. I agree. Drop the statement. It's a designer's issue to decide what the best method is, surely... Beyond scope? > Since we have the experts, the energy, and a couple of good text suggestions, please, let's capture their essence in the document. By doing that we might avoid repeating this debate again and again. It somewhat depends on whether this document is about TOFU or whether it is about opportunistic encryption. I suppose someone could write another document about TOFU... While we're at it, on further reading, I think also the phrase 'leap of faith' should be expunged. It is a pejorative used by the supporters of one system to criticise another system. Problem is, in TOFU there is a small and tractable leap of faith within the acceptable reach of most all sysadms, whereas in the competing system there is a religion's worth of faith which defies rationalisation by any user at the coalface. The pejorative backfires. (Yeah, I know, TOFU was probably a pejorative as well, but I like it, it sounds much better than others, and has found widespread acceptance.) iang > Thanks a lot, > Orit. > >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Derek Atkins >> Sent: Tuesday, June 17, 2014 10:39 AM >> To: saag@ietf.org >> Subject: Re: [saag] suggested text for opportunistic definition >> >> Viktor Dukhovni writes: >> >>> On Mon, Jun 16, 2014 at 04:11:30PM -0400, Derek Atkins wrote: >>> >>>>> I could remove the two words "are fragile", if they are seen too >>>>> judgemental and not essential to make the point. >>>> >>>> I think that's a good start. I would reword the last sentence to read: >>>> >>>> Trust on first use (TOFU) key management models (as with saved SSH >>>> fingerprints and various certificate pinning approaches) provide >>>> key continuity across multiple sessions but require user >>>> intervention when key continuity fails. >>>> >>>> For the record, I have 285 entries in my SSH known hosts file. While >>>> not in the millions, it's still a decent sample IMHO. I find I need to >>>> change keys.... rarely. And normally only at my own doing so I know to >>>> expect it. I think I've had to change keys less than a half-dozen >>>> times. >>> >>> I should perhaps emphasize that the goal of this sentence was not >>> to claim that TOFU is a poor fit for SSH, but rather that the >>> approach is not generally suited to all applications. For example, >>> I don't see it working well for email... All in the context of >>> explaining that we don't have a silver-bullet for Internet-scale >>> authentication, and so ubiquitous security needs to make authentication >>> optional. >>> >>> Should I make it explicit that the remark is intended to suggest >>> that TOFU is not *universally* applicable to all application domains? >>> I was hoping to get away with a concise statement for what is a >>> minor point in an argument that is itself deliberately concise. >>> >>> I want to stay on focus and not deep-dive into any tangential topics. >> >> Fair enough. >> >> I did see another wordsmithing option thrown out (after I sent my >> suggestion) that also tends to help in the same direction. >> >> I'm not trying to bog you down in minutia. Mostly I just want to make >> sure that TOFU doesn't get thrown out entirely just because it does >> require manual intervention when key continuity fails and because the >> the initial contact isn't protected. As you say there are multiple use >> cases for different solutions, and for some use cases TOFU is "good >> enough". >> >> Thanks, >> >> -derek >> >> -- >> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory >> Member, MIT Student Information Processing Board (SIPB) >> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH >> warlord@MIT.EDU PGP key available >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Thu Jun 19 04:19:29 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD5F1A0375 for ; Thu, 19 Jun 2014 04:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.372 X-Spam-Level: X-Spam-Status: No, score=-0.372 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnJFSWt-WBy2 for ; Thu, 19 Jun 2014 04:19:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 757871A0372 for ; Thu, 19 Jun 2014 04:19:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s5JBIewV014860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Jun 2014 14:18:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s5JBIct8014349; Thu, 19 Jun 2014 14:18:38 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21410.50958.406088.478724@fireball.kivinen.iki.fi> Date: Thu, 19 Jun 2014 14:18:38 +0300 From: Tero Kivinen To: Paul Lambert In-Reply-To: References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <539E30F3.1050306@iang.org> <539E8791.4070901@cisco.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 32 min X-Total-Time: 42 min Archived-At: http://mailarchive.ietf.org/arch/msg/saag/FcsAJw57A-Sp711qmI7Eyv7SbRY Cc: "saag@ietf.org" Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 11:19:26 -0000 Paul Lambert writes: > SSH does not require a =B3name space=B2. The hash of the key is a un= ique > identifier. This is incorrect. SSH do require name space. The name space is stored on the client database where it maps the user interface selection to the public key of the host (or hash of the public key, but I think all implementations actually store the full public key). I.e. when you write "ssh fireball.acr.fi" your ssh client will do local "database lookup" and find the public key for identifier fireball.acr.fi, and will get some public key back. Then when it makes connection to the remote host, it will verify that the public key is same than what was stored in the local database with the same name I used on the command line. If I use command "ssh fireball.kivinen.iki.fi" or "ssh 2001:1bc8:100d::2" it will connect to the same host, but use different local database identifier when fetching the public key. This database lookup based on the user interface selection of the user is critical for the security of the system. I.e. if I type "ssh fireball", and my search path happens to be "acr.fi" the client must not do database lookup based on the expanded "fireball.acr.fi". It must do database lookup based on the identifier I typed in on the command line, i.e. "fireball", and get public key based on that. That public key might be the same than what was stored for the "fireball.acr.fi". If I use same "ssh fireball" on environment where the dns search path is for example "hacker.org", the ssh client still needs to use "fireball" as identifier, not "fireball.hacker.org", so I will notice when I connect to different host I expected it to connect as it has wrong key. So to claim that SSH does not require name space is incorrect, as you need to have name -> public key mapping on your local setup. When using GUI the public key is stored to the stored profile or similar for the host you are connecting to. For example the clients who do dns lookups and store more keys to the database than what was given on the command line (like both name user typed in and the IP-addresses of the hosts), are unsecure and should not be used, as now local database stores keys which user have not typed in, but instead trusts data from dns. Oh, I just noticed openssh seems to be that kind of vulnerable implementation. Openssh seems to do dns lookup based on the name user types in and does dns lookup and stores both the name and IP-address to the database. I.e. if hacker manages to trick me to connect to test.hacker.org and returns ip-address of 83.145.195.1 from the dns to me, and reroutes those packets going to that ip-address to them this will cause the openssh to store to the database an entry which says "test.hacker.org,83.145.195.1" as a key with test.hacker.org public key. Now if I ever use "ssh 83.145.195.1" (for example because hacker next broke the dns and I had to revert to ip-address to connect back to home) they will be able to hijack that connection. I assume it will connect to my own host at home, and either uses the public key I have stored on the database or ask me to verify the public key. But instead hacker can hijack that connection and forward it again to test.hacker.org and the openssh will happily accept the public key from there.=20 It would be ok to store the both the name typed on the command line and then add extra selector for the ip-address. The ip-address would only be used if there are multiple keys for the same host name. I.e. where you have name like www.iki.fi, which have three ip-address and three different hosts and three different public keys, so when I connect to the www.iki.fi first time, and it selects one of the ip-addresses it stores the www.iki.fi for the key and adds extra selector saying that this key is for ip-address x out of x,y, and z, so if I get different key when connecting to www.iki.fi using ip-address y, it could tell me that. Openssh seems to have some kind of safeguards against this attacks, as it seems it will not store the ip-address every time, perhaps it checks that it will only store ip-address if it is not yet stored to the database or something, so perhaps it is not that easy to use this attack. --=20 kivinen@iki.fi From nobody Tue Jun 24 03:16:55 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8101B282A for ; Tue, 24 Jun 2014 03:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjYUIQSdGE_O for ; Tue, 24 Jun 2014 03:16:52 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C76A41A0146 for ; Tue, 24 Jun 2014 03:16:51 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s5OAGndt002763; Tue, 24 Jun 2014 03:16:49 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1mq3f8ry21-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 24 Jun 2014 03:16:49 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::4561:8e1c:d59b:f770%17]) with mapi; Tue, 24 Jun 2014 03:16:48 -0700 From: Paul Lambert To: Tero Kivinen Date: Tue, 24 Jun 2014 03:16:47 -0700 Thread-Topic: [saag] suggested text for opportunistic definition Thread-Index: Ac+PlWgPiNl4FYVDTq2ak8QPPNUAug== Message-ID: References: <535C4DE5.2080207@cs.tcd.ie> <20140427043658.GF27883@mournblade.imrryr.org> <535CFA14.5020200@cs.tcd.ie> <20140504085609.GO27883@mournblade.imrryr.org> <539D9920.7080406@cs.tcd.ie> <20140615164333.GM8358@mournblade.imrryr.org> <539E30F3.1050306@iang.org> <539E8791.4070901@cisco.com> <21410.50958.406088.478724@fireball.kivinen.iki.fi> In-Reply-To: <21410.50958.406088.478724@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 acceptlanguage: en-US Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-24_10:2014-06-24,2014-06-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406240115 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/GIjtE4YhqdWXP0YMCelYQHaPJUA Cc: "saag@ietf.org" Subject: Re: [saag] suggested text for opportunistic definition X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 10:16:53 -0000 DQoNCk9uIDYvMTkvMTQsIDQ6MTggQU0sICJUZXJvIEtpdmluZW4iIDxraXZpbmVuQGlraS5maT4g d3JvdGU6DQoNCj5QYXVsIExhbWJlcnQgd3JpdGVzOg0KPj4gU1NIIGRvZXMgbm90IHJlcXVpcmUg YSCp+G5hbWUgc3BhY2Wp9y4gIFRoZSBoYXNoIG9mIHRoZSBrZXkgaXMgYSB1bmlxdWUNCj4+IGlk ZW50aWZpZXIuDQo+DQo+VGhpcyBpcyBpbmNvcnJlY3QuIFNTSCBkbyByZXF1aXJlIG5hbWUgc3Bh Y2UuIFRoZSBuYW1lIHNwYWNlIGlzIHN0b3JlZA0KPm9uIHRoZSBjbGllbnQgZGF0YWJhc2Ugd2hl cmUgaXQgbWFwcyB0aGUgdXNlciBpbnRlcmZhY2Ugc2VsZWN0aW9uIHRvDQo+dGhlIHB1YmxpYyBr ZXkgb2YgdGhlIGhvc3QgKG9yIGhhc2ggb2YgdGhlIHB1YmxpYyBrZXksIGJ1dCBJIHRoaW5rIGFs bA0KPmltcGxlbWVudGF0aW9ucyBhY3R1YWxseSBzdG9yZSB0aGUgZnVsbCBwdWJsaWMga2V5KS4N Cg0KWWVzLCBtdWRkbGVkIHRoaW5raW5nIG9uIG15IHBhcnQuICBISVAgd291bGQgb2YgYmVlbiBh IGJldHRlciBleGFtcGxlDQpmb3Igc2hvd2luZyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGVzY2Fw ZSB0aGUgbmVlZCBmb3INCmNvb3JkaW5hdGVkIG5hbWUgc3BhY2VzLg0KDQpKdXN0IGFzIGEgdGhv dWdodCBleHBlcmltZW50IC0gd2hhdCBkb2VzIFNTSCBsb29rIGxpa2Ugd2hlbg0KWW91IHVzZSBJ UHY2IHdpdGggYSBISVQ/DQoNClBhdWwNCg0KPg0KPkkuZS4gd2hlbiB5b3Ugd3JpdGUgInNzaCBm aXJlYmFsbC5hY3IuZmkiIHlvdXIgc3NoIGNsaWVudCB3aWxsIGRvDQo+bG9jYWwgImRhdGFiYXNl IGxvb2t1cCIgYW5kIGZpbmQgdGhlIHB1YmxpYyBrZXkgZm9yIGlkZW50aWZpZXINCj5maXJlYmFs bC5hY3IuZmksIGFuZCB3aWxsIGdldCBzb21lIHB1YmxpYyBrZXkgYmFjay4gVGhlbiB3aGVuIGl0 IG1ha2VzDQo+Y29ubmVjdGlvbiB0byB0aGUgcmVtb3RlIGhvc3QsIGl0IHdpbGwgdmVyaWZ5IHRo YXQgdGhlIHB1YmxpYyBrZXkgaXMNCj5zYW1lIHRoYW4gd2hhdCB3YXMgc3RvcmVkIGluIHRoZSBs b2NhbCBkYXRhYmFzZSB3aXRoIHRoZSBzYW1lIG5hbWUgSQ0KPnVzZWQgb24gdGhlIGNvbW1hbmQg bGluZS4NCj4NCj5JZiBJIHVzZSBjb21tYW5kICJzc2ggZmlyZWJhbGwua2l2aW5lbi5pa2kuZmki IG9yICJzc2gNCj4yMDAxOjFiYzg6MTAwZDo6MiIgaXQgd2lsbCBjb25uZWN0IHRvIHRoZSBzYW1l IGhvc3QsIGJ1dCB1c2UgZGlmZmVyZW50DQo+bG9jYWwgZGF0YWJhc2UgaWRlbnRpZmllciB3aGVu IGZldGNoaW5nIHRoZSBwdWJsaWMga2V5LiBUaGlzIGRhdGFiYXNlDQo+bG9va3VwIGJhc2VkIG9u IHRoZSB1c2VyIGludGVyZmFjZSBzZWxlY3Rpb24gb2YgdGhlIHVzZXIgaXMgY3JpdGljYWwNCj5m b3IgdGhlIHNlY3VyaXR5IG9mIHRoZSBzeXN0ZW0uDQo+DQo+SS5lLiBpZiBJIHR5cGUgInNzaCBm aXJlYmFsbCIsIGFuZCBteSBzZWFyY2ggcGF0aCBoYXBwZW5zIHRvIGJlDQo+ImFjci5maSIgdGhl IGNsaWVudCBtdXN0IG5vdCBkbyBkYXRhYmFzZSBsb29rdXAgYmFzZWQgb24gdGhlIGV4cGFuZGVk DQo+ImZpcmViYWxsLmFjci5maSIuIEl0IG11c3QgZG8gZGF0YWJhc2UgbG9va3VwIGJhc2VkIG9u IHRoZSBpZGVudGlmaWVyDQo+SSB0eXBlZCBpbiBvbiB0aGUgY29tbWFuZCBsaW5lLCBpLmUuICJm aXJlYmFsbCIsIGFuZCBnZXQgcHVibGljIGtleQ0KPmJhc2VkIG9uIHRoYXQuIFRoYXQgcHVibGlj IGtleSBtaWdodCBiZSB0aGUgc2FtZSB0aGFuIHdoYXQgd2FzIHN0b3JlZA0KPmZvciB0aGUgImZp cmViYWxsLmFjci5maSIuDQo+DQo+SWYgSSB1c2Ugc2FtZSAic3NoIGZpcmViYWxsIiBvbiBlbnZp cm9ubWVudCB3aGVyZSB0aGUgZG5zIHNlYXJjaCBwYXRoDQo+aXMgZm9yIGV4YW1wbGUgImhhY2tl ci5vcmciLCB0aGUgc3NoIGNsaWVudCBzdGlsbCBuZWVkcyB0byB1c2UNCj4iZmlyZWJhbGwiIGFz IGlkZW50aWZpZXIsIG5vdCAiZmlyZWJhbGwuaGFja2VyLm9yZyIsIHNvIEkgd2lsbCBub3RpY2UN Cj53aGVuIEkgY29ubmVjdCB0byBkaWZmZXJlbnQgaG9zdCBJIGV4cGVjdGVkIGl0IHRvIGNvbm5l Y3QgYXMgaXQgaGFzDQo+d3Jvbmcga2V5Lg0KPg0KPlNvIHRvIGNsYWltIHRoYXQgU1NIIGRvZXMg bm90IHJlcXVpcmUgbmFtZSBzcGFjZSBpcyBpbmNvcnJlY3QsIGFzIHlvdQ0KPm5lZWQgdG8gaGF2 ZSBuYW1lIC0+IHB1YmxpYyBrZXkgbWFwcGluZyBvbiB5b3VyIGxvY2FsIHNldHVwLg0KPg0KPldo ZW4gdXNpbmcgR1VJIHRoZSBwdWJsaWMga2V5IGlzIHN0b3JlZCB0byB0aGUgc3RvcmVkIHByb2Zp bGUgb3INCj5zaW1pbGFyIGZvciB0aGUgaG9zdCB5b3UgYXJlIGNvbm5lY3RpbmcgdG8uDQo+DQo+ Rm9yIGV4YW1wbGUgdGhlIGNsaWVudHMgd2hvIGRvIGRucyBsb29rdXBzIGFuZCBzdG9yZSBtb3Jl IGtleXMgdG8gdGhlDQo+ZGF0YWJhc2UgdGhhbiB3aGF0IHdhcyBnaXZlbiBvbiB0aGUgY29tbWFu ZCBsaW5lIChsaWtlIGJvdGggbmFtZSB1c2VyDQo+dHlwZWQgaW4gYW5kIHRoZSBJUC1hZGRyZXNz ZXMgb2YgdGhlIGhvc3RzKSwgYXJlIHVuc2VjdXJlIGFuZCBzaG91bGQNCj5ub3QgYmUgdXNlZCwg YXMgbm93IGxvY2FsIGRhdGFiYXNlIHN0b3JlcyBrZXlzIHdoaWNoIHVzZXIgaGF2ZSBub3QNCj50 eXBlZCBpbiwgYnV0IGluc3RlYWQgdHJ1c3RzIGRhdGEgZnJvbSBkbnMuDQo+DQo+T2gsIEkganVz dCBub3RpY2VkIG9wZW5zc2ggc2VlbXMgdG8gYmUgdGhhdCBraW5kIG9mIHZ1bG5lcmFibGUNCj5p bXBsZW1lbnRhdGlvbi4NCj4NCj5PcGVuc3NoIHNlZW1zIHRvIGRvIGRucyBsb29rdXAgYmFzZWQg b24gdGhlIG5hbWUgdXNlciB0eXBlcyBpbiBhbmQNCj5kb2VzIGRucyBsb29rdXAgYW5kIHN0b3Jl cyBib3RoIHRoZSBuYW1lIGFuZCBJUC1hZGRyZXNzIHRvIHRoZQ0KPmRhdGFiYXNlLiBJLmUuIGlm IGhhY2tlciBtYW5hZ2VzIHRvIHRyaWNrIG1lIHRvIGNvbm5lY3QgdG8NCj50ZXN0LmhhY2tlci5v cmcgYW5kIHJldHVybnMgaXAtYWRkcmVzcyBvZiA4My4xNDUuMTk1LjEgZnJvbSB0aGUgZG5zIHRv DQo+bWUsIGFuZCByZXJvdXRlcyB0aG9zZSBwYWNrZXRzIGdvaW5nIHRvIHRoYXQgaXAtYWRkcmVz cyB0byB0aGVtIHRoaXMNCj53aWxsIGNhdXNlIHRoZSBvcGVuc3NoIHRvIHN0b3JlIHRvIHRoZSBk YXRhYmFzZSBhbiBlbnRyeSB3aGljaCBzYXlzDQo+InRlc3QuaGFja2VyLm9yZyw4My4xNDUuMTk1 LjEiIGFzIGEga2V5IHdpdGggdGVzdC5oYWNrZXIub3JnIHB1YmxpYw0KPmtleS4NCj4NCj5Ob3cg aWYgSSBldmVyIHVzZSAic3NoIDgzLjE0NS4xOTUuMSIgKGZvciBleGFtcGxlIGJlY2F1c2UgaGFj a2VyIG5leHQNCj5icm9rZSB0aGUgZG5zIGFuZCBJIGhhZCB0byByZXZlcnQgdG8gaXAtYWRkcmVz cyB0byBjb25uZWN0IGJhY2sgdG8NCj5ob21lKSB0aGV5IHdpbGwgYmUgYWJsZSB0byBoaWphY2sg dGhhdCBjb25uZWN0aW9uLiBJIGFzc3VtZSBpdCB3aWxsDQo+Y29ubmVjdCB0byBteSBvd24gaG9z dCBhdCBob21lLCBhbmQgZWl0aGVyIHVzZXMgdGhlIHB1YmxpYyBrZXkgSSBoYXZlDQo+c3RvcmVk IG9uIHRoZSBkYXRhYmFzZSBvciBhc2sgbWUgdG8gdmVyaWZ5IHRoZSBwdWJsaWMga2V5LiBCdXQg aW5zdGVhZA0KPmhhY2tlciBjYW4gaGlqYWNrIHRoYXQgY29ubmVjdGlvbiBhbmQgZm9yd2FyZCBp dCBhZ2FpbiB0bw0KPnRlc3QuaGFja2VyLm9yZyBhbmQgdGhlIG9wZW5zc2ggd2lsbCBoYXBwaWx5 IGFjY2VwdCB0aGUgcHVibGljIGtleQ0KPmZyb20gdGhlcmUuIA0KPg0KPkl0IHdvdWxkIGJlIG9r IHRvIHN0b3JlIHRoZSBib3RoIHRoZSBuYW1lIHR5cGVkIG9uIHRoZSBjb21tYW5kIGxpbmUNCj5h bmQgdGhlbiBhZGQgZXh0cmEgc2VsZWN0b3IgZm9yIHRoZSBpcC1hZGRyZXNzLiBUaGUgaXAtYWRk cmVzcyB3b3VsZA0KPm9ubHkgYmUgdXNlZCBpZiB0aGVyZSBhcmUgbXVsdGlwbGUga2V5cyBmb3Ig dGhlIHNhbWUgaG9zdCBuYW1lLiBJLmUuDQo+d2hlcmUgeW91IGhhdmUgbmFtZSBsaWtlIHd3dy5p a2kuZmksIHdoaWNoIGhhdmUgdGhyZWUgaXAtYWRkcmVzcyBhbmQNCj50aHJlZSBkaWZmZXJlbnQg aG9zdHMgYW5kIHRocmVlIGRpZmZlcmVudCBwdWJsaWMga2V5cywgc28gd2hlbiBJDQo+Y29ubmVj dCB0byB0aGUgd3d3LmlraS5maSBmaXJzdCB0aW1lLCBhbmQgaXQgc2VsZWN0cyBvbmUgb2YgdGhl DQo+aXAtYWRkcmVzc2VzIGl0IHN0b3JlcyB0aGUgd3d3LmlraS5maSBmb3IgdGhlIGtleSBhbmQg YWRkcyBleHRyYQ0KPnNlbGVjdG9yIHNheWluZyB0aGF0IHRoaXMga2V5IGlzIGZvciBpcC1hZGRy ZXNzIHggb3V0IG9mIHgseSwgYW5kIHosDQo+c28gaWYgSSBnZXQgZGlmZmVyZW50IGtleSB3aGVu IGNvbm5lY3RpbmcgdG8gd3d3LmlraS5maSB1c2luZw0KPmlwLWFkZHJlc3MgeSwgaXQgY291bGQg dGVsbCBtZSB0aGF0Lg0KPg0KPk9wZW5zc2ggc2VlbXMgdG8gaGF2ZSBzb21lIGtpbmQgb2Ygc2Fm ZWd1YXJkcyBhZ2FpbnN0IHRoaXMgYXR0YWNrcywgYXMNCj5pdCBzZWVtcyBpdCB3aWxsIG5vdCBz dG9yZSB0aGUgaXAtYWRkcmVzcyBldmVyeSB0aW1lLCBwZXJoYXBzIGl0DQo+Y2hlY2tzIHRoYXQg aXQgd2lsbCBvbmx5IHN0b3JlIGlwLWFkZHJlc3MgaWYgaXQgaXMgbm90IHlldCBzdG9yZWQgdG8N Cj50aGUgZGF0YWJhc2Ugb3Igc29tZXRoaW5nLCBzbyBwZXJoYXBzIGl0IGlzIG5vdCB0aGF0IGVh c3kgdG8gdXNlIHRoaXMNCj5hdHRhY2suDQo+LS0gDQo+a2l2aW5lbkBpa2kuZmkNCg0K From nobody Fri Jun 27 11:48:08 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA31A1B28CB for ; Fri, 27 Jun 2014 11:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX24o3v7TrB9 for ; Fri, 27 Jun 2014 11:48:03 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [209.135.209.4]) by ietfa.amsl.com (Postfix) with ESMTP id AD4901B27B9 for ; Fri, 27 Jun 2014 11:48:03 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 425DA9A4411 for ; Fri, 27 Jun 2014 14:47:53 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 0qhiEogNO9Vy for ; Fri, 27 Jun 2014 14:47:52 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-144-77.washdc.fios.verizon.net [96.255.144.77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 9A71B9A440C for ; Fri, 27 Jun 2014 14:47:52 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jun 2014 14:47:41 -0400 References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> To: IETF SAAG Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nEycc3b25ozubq85TBJ9OivGc5s Subject: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 18:48:06 -0000 Thanks for the lively discussion of the -00 version of this document. = Please review and comment on the updated version. Russ > A new version of I-D, draft-iab-crypto-alg-agility-01.txt > has been successfully submitted by Russell Housley and posted to the > IETF repository. >=20 > Name: draft-iab-crypto-alg-agility > Revision: 01 > Title: Guidelines for Cryptographic Algorithm Agility > Document date: 2014-06-27 > Group: iab > Pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-iab-crypto-alg-agility-01.txt > Status: = https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/ > Htmlized: = http://tools.ietf.org/html/draft-iab-crypto-alg-agility-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-iab-crypto-alg-agility-01 >=20 > Abstract: > Many IETF protocols may use of cryptographic algorithms to provide > confidentiality, integrity, or non-repudiation. Communicating peers > must support the same cryptographic algorithm or algorithms for = these > mechanisms to work properly. This memo provides guidelines for > ensuring that such a protocol has the ability to migrate from one > algorithm to another over time. From nobody Fri Jun 27 12:25:40 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA2B1A0024 for ; Fri, 27 Jun 2014 12:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZdKMaotJo7q for ; Fri, 27 Jun 2014 12:25:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0E11A000D for ; Fri, 27 Jun 2014 12:25:36 -0700 (PDT) Received: from BLUPR03MB424.namprd03.prod.outlook.com (10.141.78.152) by BLUPR03MB423.namprd03.prod.outlook.com (10.141.78.150) with Microsoft SMTP Server (TLS) id 15.0.959.24; Fri, 27 Jun 2014 19:25:34 +0000 Received: from BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) by BLUPR03MB424.namprd03.prod.outlook.com ([10.141.78.152]) with mapi id 15.00.0959.000; Fri, 27 Jun 2014 19:25:34 +0000 From: Christian Huitema To: Russ Housley Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AQHPkjhbW+BHfts2f0iTrTOHT38rpJuFUzQQ Date: Fri, 27 Jun 2014 19:25:33 +0000 Message-ID: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0255DF69B9 x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(21056001)(85852003)(92566001)(74316001)(2656002)(79102001)(76482001)(83072002)(77982001)(99396002)(80022001)(95666004)(20776003)(101416001)(33646001)(46102001)(81542001)(4396001)(74502001)(54356999)(76176999)(81342001)(50986999)(86362001)(85306003)(31966008)(105586002)(87936001)(64706001)(76576001)(99286002)(106356001)(83322001)(107046002)(74662001)(106116001)(24736002)(3826002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB423; H:BLUPR03MB424.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/saag/Xheg3avdKlk5n_qc0AHfAek-8Cw Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 19:25:39 -0000 Am I the only one who believes that the draft would be stronger if it also = discussed the "pitfalls of agility?" The poster child for that is probably = TLS. The protocol includes a negotiation capability, so that the parties ca= n chose from a list of enumerated options. In theory, that's very nice. As = time passes, better options become available and can be negotiated, providi= ng for better security. But in practice, there are issues: downgrading atta= cks, code bloat, unclear rules for how to choose the "best" option, difficu= lty to remove obsolete options... As a design rule, it seems that "few good= options" is better than "unfettered negotiation." There are counter arguments, e.g. national governments insisting that their= communications be secured via homemade crypto. These type of deployments u= se the negotiation capability to choose a nonstandard algorithm, which woul= d go against the "few good options" guideline. So there is clearly room for= debate. I think it would be nice if the draft reflected that debate. -- Christian Huitema From nobody Fri Jun 27 13:43:14 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700D81A011D for ; Fri, 27 Jun 2014 13:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.651 X-Spam-Level: X-Spam-Status: No, score=-0.651 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUREOX3AsuPw for ; Fri, 27 Jun 2014 13:43:12 -0700 (PDT) Received: from BLU004-OMC2S23.hotmail.com (blu004-omc2s23.hotmail.com [65.55.111.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23FFA1A0114 for ; Fri, 27 Jun 2014 13:43:12 -0700 (PDT) Received: from BLU181-W31 ([65.55.111.71]) by BLU004-OMC2S23.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Fri, 27 Jun 2014 13:43:11 -0700 X-TMN: [zC9fVihQ4Uy0c6qL8e9CRkza4ZIPZPIk6ybw613Vrmw=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_6d953824-95d6-4e9a-99b1-465ab74ce4fe_" From: Bernard Aboba To: Christian Huitema Date: Fri, 27 Jun 2014 13:43:10 -0700 Importance: Normal In-Reply-To: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com>, , <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2014 20:43:11.0436 (UTC) FILETIME=[690660C0:01CF9248] Archived-At: http://mailarchive.ietf.org/arch/msg/saag/iP8KL5vY4LeceubeJB2EZy1yhT8 Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 20:43:13 -0000 --_6d953824-95d6-4e9a-99b1-465ab74ce4fe_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian said:=20 "Am I the only one who believes that the draft would be stronger if it also= discussed the "pitfalls of agility?"=20 [BA] Not just pitfalls - but also advice on how to properly design for cryp= to-agility.=20 One of the reasons to have crypto-agility is to make it possible to transit= ion from weak algorithms to stronger ones.=20 Yet while such a transition is in progress=2C by definition it is necessary= to still be willing to negotiate a known weak algorithm. =20 However=2C tolerance for weak algorithms cannot go on forever - or else cry= pto-agility just becomes a mechanism for enabling downgrade attacks.=20 At some point=2C you have got to remove support for the weak algorithms ent= irely=2C or at least refuse to negotiate them.=20 Even trickier is when the mechanism protecting the cryptographic negotiatio= n is itself weak - and not negotiable.=20 The IETF has presumably gone through these kind of design problems multiple= times=2C so some "best practices" could be culled from all the (painful) e= xperience. = --_6d953824-95d6-4e9a-99b1-465ab74ce4fe_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Christian said: =3B=

"Am I the only one who believes that the draft wo= uld be stronger if it also discussed the "pitfalls of agility?" =3B
=

[BA] Not just pitfalls - but also advice on how t= o properly design for crypto-agility. =3B

One = of the reasons to have crypto-agility is to make it possible to transition = from weak algorithms to stronger ones. =3B

Yet= while such a transition is in progress=2C by definition it is necessary to= still be willing to negotiate a known weak algorithm.  =3B
<= br>
However=2C tolerance for weak algorithms cannot go on forever= - or else crypto-agility just becomes a mechanism for enabling downgrade a= ttacks. =3B

At some point=2C you have got to r= emove support for the weak algorithms entirely=2C or at least refuse to neg= otiate them. =3B

Even trickier is when the mec= hanism protecting the cryptographic negotiation is itself weak - and not ne= gotiable. =3B

<= /div>
The IETF has presumably gone t= hrough these kind of design problems multiple times=2C so some "best practi= ces" could be culled from all the (painful) experience. =3B
= --_6d953824-95d6-4e9a-99b1-465ab74ce4fe_-- From nobody Fri Jun 27 14:15:38 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6848B1A0190 for ; Fri, 27 Jun 2014 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBbJU6zhyQrE for ; Fri, 27 Jun 2014 14:15:36 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ED61A018F for ; Fri, 27 Jun 2014 14:15:36 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s5RLFZY1032499; Fri, 27 Jun 2014 14:15:35 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0b-0016f401.pphosted.com with ESMTP id 1mr9khpt2a-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 27 Jun 2014 14:15:35 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 27 Jun 2014 14:15:27 -0700 From: Paul Lambert To: Christian Huitema , Russ Housley Date: Fri, 27 Jun 2014 14:15:26 -0700 Thread-Topic: [saag] draft-iab-crypto-alg-agility-01.txt Thread-Index: AQHPkjhbW+BHfts2f0iTrTOHT38rpJuFUzQQgAAERqA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01AA4483A9A@SC-VEXCH2.marvell.com> References: <20140627184432.32486.99544.idtracker@ietfa.amsl.com> <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> In-Reply-To: <9faf7ec8ebef4dd4b69504c251832887@BLUPR03MB424.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-27_06:2014-06-27,2014-06-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270229 Archived-At: http://mailarchive.ietf.org/arch/msg/saag/sQ297MpC2XUEwhbScbRZXmHycmU Cc: IETF SAAG Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 21:15:37 -0000 ]-----Original Message----- ]From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Christian Huitema ]Sent: Friday, June 27, 2014 12:26 PM ]To: Russ Housley ]Cc: IETF SAAG ]Subject: Re: [saag] draft-iab-crypto-alg-agility-01.txt ] ]Am I the only one who believes that the draft would be stronger if it ]also discussed the "pitfalls of agility?"=20 +1 I am very much in favor of "diversity", but share your concerns of the dangers of "agility" ]The poster child for that is ]probably TLS.=20 While not an IETF protocol, the problems of IEEE 802.11=20 security algorithm diversity is another example: - interoperability problems are common because of the ability to mix different key management and=20 traffic algorithms (this is a good reason to have 'cipher suites' versus a 'Chinese Menu' approach) - not all of the diversity of options make sense to users - polices for multiple algorithms are not combined in a way that supports upward support to better algorithms (e.g. giving user choice of TKIP or AES versus AES or TKIP) - implementations are continually pulled down to the lowest=20 common denominator - WEP has been very difficult if not impossible to remove from=20 products since service providers want the broad3st=20 interoperability=20 ]The protocol includes a negotiation capability, so that ]the parties can chose from a list of enumerated options. In theory, ]that's very nice.=20 Not always. How do we control the usage policies to ensure that the "good" algorithm is used for important traffic and the "bad" algorithm might be used for other less important traffic. ]As time passes, better options become available and ]can be negotiated, providing for better security. But in practice, there ]are issues: downgrading attacks, code bloat, unclear rules for how to ]choose the "best" option, difficulty to remove obsolete options...=20 Exactly ]As a ]design rule, it seems that "few good options" is better than "unfettered ]negotiation." Yes.=20 Paul ] ]There are counter arguments, e.g. national governments insisting that ]their communications be secured via homemade crypto. These type of ]deployments use the negotiation capability to choose a nonstandard ]algorithm, which would go against the "few good options" guideline. So ]there is clearly room for debate. I think it would be nice if the draft ]reflected that debate. ] ]-- Christian Huitema ] ] ]_______________________________________________ ]saag mailing list ]saag@ietf.org ]https://www.ietf.org/mailman/listinfo/saag From nobody Sun Jun 29 14:59:07 2014 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092C11A0030; Sun, 29 Jun 2014 14:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alR9GJ6PkXaK; Sun, 29 Jun 2014 14:58:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64B21A002B; Sun, 29 Jun 2014 14:58:59 -0700 (PDT) Received: from [192.168.123.7] (unknown [23.242.155.89]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 967B822E1F4; Sun, 29 Jun 2014 17:58:52 -0400 (EDT) Message-ID: <53B08C20.30805@seantek.com> Date: Sun, 29 Jun 2014 14:58:56 -0700 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: urn-nid@ietf.org, saag@ietf.org, apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/saag/UQ7gsxNf9VwBJJpQZu5psgm8HcI Subject: [saag] draft-seantek-certspec-03; request review and URN assignment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 21:59:01 -0000 Hello URN/Apps folks, and SAAG folks: A new version of the Internet-Draft draft-seantek-certspec (03) has been = posted to the IETF repository. I would like to notify this list for comme= ntary, and utlimately to apply for the URN NID 'cert'. Compared to 02 last year, this version addresses concerns raised both on = and off the lists. The ABNF is tighter. URNBIS work is referenced more co= nsistently, instead of the legacy RFC 2141. issuersn (issuer and serial n= umber) is given extensive consideration, and is both more restrictive (in= the strict grammar in Section 5.3.1) and more well-defined (in the relax= ed grammar for human input in Appendix A). Appendix B now represents the = state-of-the-art for mandatory LDAP attributes. Kind regards, Sean ************** A new version of I-D, draft-seantek-certspec-03.txt has been successfully submitted by Sean Leonard and posted to the IETF repository. Name: draft-seantek-certspec Revision: 03 Title: A Uniform Resource Name (URN) Namespace for Certificates Document date: 2014-06-29 Group: Individual Submission Pages: 21 URL:http://www.ietf.org/internet-drafts/draft-seantek-certspec-03.txt Status:https://datatracker.ietf.org/doc/draft-seantek-certspec/ Htmlized:http://tools.ietf.org/html/draft-seantek-certspec-03 Diff:http://www.ietf.org/rfcdiff?url2=3Ddraft-seantek-certspec-03 Abstract: Digital certificates are used in many systems and protocols to identify and authenticate parties. This document describes a Uniform= Resource Name (URN) namespace that identifies certificates. These URNs can be used when certificates need to be identified by value or reference.